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

Tue Dec 6 10:12:26 UTC 2016

Hi David,

Your cherry pick approach is probably fine, but in case you want to use
Paul's branch you probably need to check out and recompile srsLTE next
branch too.

On Tue, 6 Dec 2016 at 11:10 David Rupprecht <david.rupprecht at rub.de> wrote:

> 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 <087%20981%203473> | 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 <+49%20234%203223508>
> Web: www.infsec.rub.de
> _______________________________________________
> srslte-users mailing list
> srslte-users at lists.softwareradiosystems.com
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20161206/fa13b32d/attachment.htm>