[srslte-users] srsUE USIM Support => Late Warnings

David Rupprecht david.rupprecht at rub.de
Tue Dec 6 10:10:34 UTC 2016


Hi Paul,

when I just complied (with srsLTE lib version release 1.4) the branch I
got the following error:

/home/david/srsUE/ue/src/phy/phch_worker.cc:433:78: error: too many
arguments to function ‘int srslte_pdsch_decode(srslte_pdsch_t*,
srslte_pdsch_cfg_t*, srslte_softbuffer_rx_t*, cf_t*, cf_t**, float,
uint8_t*)’
In file included from /usr/local/include/srslte/srslte.h:96:0,
                 from /home/david/srsUE/ue/hdr/phy/phch_worker.h:31,
                 from /home/david/srsUE/ue/src/phy/phch_worker.cc:29:
/usr/local/include/srslte/phch/pdsch.h:125:16: note: declared here
 SRSLTE_API int srslte_pdsch_decode(srslte_pdsch_t *q,

Unfortunately, I did not found a srsLTE lib version with a correct
arguments. However, when I cherry picked your commit on the
release_001_004 tag it complied and it looks like the SIM support is
working properly. I still do not get a connection to the network.
However, the late waring do not occur anymore. I think I have to dig a
bit deeper. As soon as I have some news, I will let you know.

Best regards,
David



On 05.12.2016 15:02, Paul Sutton wrote:
> Hi David,
> 
> I've just pushed a branch which decouples the RLC from the PDCP in the
> DL path called "dl_decouple".
> Can you try it out and let me know how it goes?
> 
> Best regards,
> Paul
> 
> On 05/12/16 11:21, David Rupprecht wrote:
>> Hi Paul,
>>
>> thanks for your answer.
>>
>> Just for understanding: The NAS layer does *not* run in a separate yet?
>> The DSP threads in the PHY layer call directly the upper layer functions
>> without any decoupling and as the NAS layer takes so long the calling
>> DSP thread blocks the further process?
>>
>> Just a short question to the message path. Considering the schematic
>> picture [1], the DL_INFO message comes from the MAX DEMUX over the RLC
>> layer to the NAS layer. However, looking at the code the RRC unit calls
>> nas->write_pdu(). So for me the RRC_DL_INFO message uses a path with the
>> RRC unit?
>>
>> For handing off the message to a separate thread. I think I have two
>> options:
>> - Running the whole NAS unit in a separate thread using and define an
>> inter thread communication.
>> - Starting a new thread when receiving the an authentication request for
>> handling just this message.
>>
>> Which option would you recommend?
>>
>> Best regards,
>> David
>>
>> [1]
>> http://www.softwareradiosystems.com/wp-content/uploads/2015/08/srsue_layer.png
>>  05.12.2016 10:33, Paul Sutton wrote:
>>> Hi David,
>>>
>>> Have you tried handing off the message to a separate thread at the NAS
>>> layer?
>>> In the srsUE receive path, our high-priority DSP threads push messages
>>> all the way up through the stack. It looks like the hard USIM delay is
>>> blocking one of these threads for 43ms, resulting in RF timing misses.
>>> We have multiple DSP threads in a pool which can take up the slack at
>>> lower bandwidths but, as this is a 20MHz carrier, we can't afford to
>>> lose one for them for that long.
>>>
>>> Best regards,
>>> Paul
>>>
>>>
>>> On 05/12/16 09:07, David Rupprecht wrote:
>>>> Dear all,
>>>>
>>>> I have implemented USIM Support for the srsUE using the PCSClib.
>>>> Unfortunately, the communication with the SIM Card takes to long (43 us
>>>> in the log) and the Authentication Response can not be sent correctly
>>>> indicated by RF late warnings with a crash.
>>>>
>>>> My question is, can I some how delay the Authentication Response? To my
>>>> understanding that should be specification conform, as the communication
>>>> on the NAS layer independent of the RF layer. Do you have any advises
>>>> concerning this problem?
>>>>
>>>> Best regards,
>>>> David
>>>>
>>>>
>>>> _______________________________________________
>>>> srslte-users mailing list
>>>> srslte-users at lists.softwareradiosystems.com
>>>> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>>> -- 
>>> ________________________________________________________________
>>> Paul Sutton Ph.D.
>>>
>>> Software Radio Systems (SRS)
>>> http://www.softwareradiosystems.com
>>>
>>> +353-87-9813473 | paul at softwareradiosystems.com
>>>
>>> PGP Key ID: 3B4A5292
>>> Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292
>>> ________________________________________________________________ 
>>>
> 

-- 
M.Sc. David Rupprecht

Ruhr-University Bochum
Research Group Information Security
Universitätsstraße 150
ID 2/130
44780 Bochum / Germany

Phone: +49 234 / 32 - 23508
Web: www.infsec.rub.de



More information about the srsran-users mailing list