SA application example for 3GPP Air Ciphering LTE

Ranjit Neelakandan

Hi,

I am using CCS Version: 6.0.1.00040 on TI 6614 EVM and salld version is 1.0.8.0 for LTE 3gpp.

I am using "SA_BasicExample_exampleProject" project for testing 3GPP Air Ciphering LTE(test6.c). After having successfully passed this test for 84 byes, when the SDU size is increased to 1024 I find that the length of received decrypted SDU is 512 bytes as shown below. Could you please let me know how this possible?

Console print:

[C66xx_0]

------- SA Unit Test Starting ---------
Instantiating SALLD ... DONE

Initialization of the PA, PA cpdma, QM and CPPI DONE
Make sure the setup matches what is expected DONE
saTestInit() DONE
Before Task_create()
Instantiating SALLD Channel 0 ...
DONE

Opening SALLD Channel 0 ...
SALLD Channel 0: General Configuration
SALLD Channel 0: Key Configuration
SALLD Channel 0: Enable Tx
SALLD Channel 0: Enable Rx
SALLD channel 0: Register SA Info
DONE

Routing Pkt to SA: BufPtr = 0x1081cdc0, pkt at 0x0080c9e8, size = 1024
hd->buffLen:512
MIPs consumed for SA: 118830
Receive Pkt from PA/SA
Software Info: 0x44440000, 0x00004444, 0x00000000
Packet of size 512 received at 0x1081bdc0
Receive TxPkt from PA/SA
Software Info: 0x44400000, 0x00004440, 0x00000000
Packet of size 512 received at 0x1081bfc0
SALLD channel 0: Send Null Packet
SALLD channel 0: Send Null Packet
Chan 0 (Air Ciphering) Statistics:
----------------------------------------------------
numPktsToAirHi =       0x00000000
numPktsToAirLo =       0x00000001
numPktsFromAirHi =     0x00000000
numPktsFromAirLo =     0x00000001
numAuthFail =         0
toAirCount-C =        0x00002000
fromAirCount-C =      0x00002000
Closing SALLD Channel 0 ...
SALLD channel 0: Send Null Packet
SALLD channel 0: UnRegister Sw Info
SALLD channel 0: Send Null Packet
DONE

Task_create() DONE
Task_stat() DONE
SA 3GPP LTE test: PASSED
verifyTestFramework: Expected 16 entry count in linked buffer queue 1 (903), found 13
topLevelTest (C:/ti/salld_1_0_8_0/packages/ti/drv/sa/example/SaBasicExample/src/c66x/bios/testMain.c:302): verifyTestFramework returned error after test SA 3GPP LTE test. Exiting.

Test summary:
   Tests Passed: 1
   Tests Failed: 0
   Tests not run: 0

------- SA Unit Test Complete ---------

Thanks and Regards,

Shabrin

over 9 years ago

0 Javier Malave-Bonet over 9 years ago

TI__Expert 5805 points

Hi Shabrin,

I will be discussing this with the example designer and will get back to you as soon as I can. There may be some sort of truncation going on due to byte alignment requirements of the Snow 3G F8 algorithm. But, I don't want to say anything definitive until I have taken a deeper look at that particular example with its developer.

Regards,

Javier

0 Javier Malave-Bonet over 9 years ago in reply to Javier Malave-Bonet

TI__Expert 5805 points

Hi Shabrin,

After discussing with the example developer he mentioned "It is most likely just a simple multi-buffer issue. The maximum buffer size in the received flow is 512, therefore, there will be two buffers/descriptors for packet size = 1024. The test case needs to be enhanced to handle multiple buffers."

I think this is a good starting point.

Regards,
Javier

0 Javier Malave-Bonet over 9 years ago in reply to Javier Malave-Bonet

TI__Expert 5805 points

Hi Shabrin,

Were you able to resolve the issue with the above recommendation?

Regards,
Javier

0 Ranjit Neelakandan over 9 years ago in reply to Javier Malave-Bonet

Prodigy 240 points

Sorry for the delayed response Javier.

Yes we could resolve the issue. The code does support for higher than 512 bytes.

With some manipulation of the buffer allocated, we could resolve the issue.

regards,

Ranjit

0 Tony Liu1 over 9 years ago in reply to Ranjit Neelakandan

Intellectual 640 points

Dear Ranjit,

Would you share more information on how to do "some manipulation of the buffer allocated"? Thanks.

Best regards,

Tony

0 Ranjit Neelakandan over 9 years ago in reply to Tony Liu1

Prodigy 240 points

Hi Tony,

In SA, depending on the input length qnum is chosen. For length>=1024 and length>=512, qnum chosen are 905 and 904 respectively. But for 1024 input length, at final output queue pop It was taking 904 queue(can support max 512 buffer length). That's the reason even if the input length is 1024 output length was 512.

Regards,
Shabrin

0 Tony Liu1 over 9 years ago in reply to Ranjit Neelakandan

Intellectual 640 points

Dear Shabrin,

Thanks for your reply.

I still have some questions below. Hope you can answer.

Q1: For 1024 input length, why was It taking 904 queue(can support max 512 buffer length) at final output queue pop? It should take 905 queue.

Q2: How do you fix the problem to support input length >=1024?

Thanks a lot.

Tony

0 Ranjit Neelakandan over 9 years ago in reply to Tony Liu1

Prodigy 240 points

Hi Tony,

Q1: Yes it should take 905 queue for input length>=1024, but SA is giving 904 queue address instead of 905(I suspect there might be some address mapping issue internally in SA hardware for 905 queue) .

Q2: To fix the problem, I changed code so that only one queue supports any input length instead of using different queues for different sizes.

Regards,
Shabrin

Processors

Processors forum

SA application example for 3GPP Air Ciphering LTE