[srslte-users] UE attached but without IP

Thu Feb 14 11:56:08 UTC 2019

Hey Eduardo,

That is strange, let me see if I can replicate this behavior. As for the
video, you should be able to stream 800kbps over the link at MCS 10 easily,
I think the capacity at MCS 10 with 50 prbs is about 5 MS/s.

Can you send the terminal output at the enodeb?

Thanks,
Justin

____
Justin Tallon Ph.D.

Software Radio Systems (SRS)
http://www.softwareradiosystems.com

+353-86-067-0753 | justin.tallon at softwareradiosystems.com

On Thu, Feb 14, 2019 at 12:51 PM Eduardo Garro Crevillen <
edgarcre at iteam.upv.es> wrote:

> You can find attached the enb and ue logs with the mcs=15. It didn't
> work though.
>
> Regarding the video bitrate, we have encoded with 800 kbps.
>
> Thanks, Eduardo.
>
> Justin Tallon <justin.tallon at softwareradiosystems.com> escribió:
>
> > Hey Eduardo!
> >
> > Just looking at the logs I am seeing
> >
> > 11:10:28.161679 [PHY1] [I] [03258] PMCH: l_crb=50, tbs=999, mcs=10,
> crc=OK,
> > snr=42.6 dB, n_iter=1, dec_time=  93 us
> >
> > which indicates the mcs is still set to 10?  can you try
> > set this pmch_item->pmch_cfg_r9.data_mcs_r9 = 15,  then make clean, make
> > etc ?
> >
> > Also, what is the rate of the video you are trying to send?
> >
> > Thanks,
> > Justin
> >
> >
> > ____
> > Justin Tallon Ph.D.
> >
> > Software Radio Systems (SRS)
> > http://www.softwareradiosystems.com
> >
> > +353-86-067-0753 | justin.tallon at softwareradiosystems.com
> >
> >
> > On Thu, Feb 14, 2019 at 11:35 AM Eduardo Garro Crevillen <
> > edgarcre at iteam.upv.es> wrote:
> >
> >> Hi Justin,
> >>
> >> I have re-run with this setup:
> >> enb: sudo srsenb enb_mbms.conf --enb.n_prb 50 --log.all_level info
> >> --expert.enable_mbsfn true
> >> ue: sudo srsue ue_mbms.conf --log.all_level info --expert.mbms_service
> >> = 0 --expert.average_subframe_enabled = false
> >>
> >>
> >> I have just tried to attached the log files, but SRS mail server
> >> rejected because it was too big. You can try to download from the
> >> below dropbox link.
> >>
> >>
> >>
> https://www.dropbox.com/s/twofvsbzen0pgn5/log%20files%20all_layers%20info.zip?dl=0
> >>
> >> Kind regards, Eduardo.
> >>
> >> Justin Tallon <justin.tallon at softwareradiosystems.com> escribió:
> >>
> >> > Hey Eduardo!
> >> >
> >> > Could you repeat the experiment with two changes, first could you set
> the
> >> > log level to "info" in both the enb and ue. (all_level = info in the
> >> conf)
> >> > and second could you set the n_prb = 50 in the enodeb?
> >> >
> >> > Thanks,
> >> > Justin
> >> > ____
> >> > Justin Tallon Ph.D.
> >> >
> >> > Software Radio Systems (SRS)
> >> > http://www.softwareradiosystems.com
> >> >
> >> > +353-86-067-0753 | justin.tallon at softwareradiosystems.com
> >> >
> >> >
> >> > On Thu, Feb 14, 2019 at 10:24 AM Eduardo Garro Crevillen <
> >> > edgarcre at iteam.upv.es> wrote:
> >> >
> >> >> Hi Justin!
> >> >>
> >> >> You can find in the attachment a zip file with logs, traces and
> pcaps of
> >> >> enb and ue with the default mbms  configuration and by modifying the
> >> >> sf_alloc_info = 62 field in SIB13 (i.e. with 5 subframes allocated to
> >> mbms).
> >> >>
> >> >> Hope it helps, Eduardo.
> >> >>
> >> >> Justin Tallon <justin.tallon at softwareradiosystems.com> escribió:
> >> >>
> >> >> > Hey Eduardo,
> >> >> >
> >> >> > Can you send me on your logs enb & ue and also the console trace?
> >> >> >
> >> >> > Thanks,
> >> >> > Justin
> >> >> > ____
> >> >> > Justin Tallon Ph.D.
> >> >> >
> >> >> > Software Radio Systems (SRS)
> >> >> > http://www.softwareradiosystems.com
> >> >> >
> >> >> > +353-86-067-0753 | justin.tallon at softwareradiosystems.com
> >> >> >
> >> >> >
> >> >> > On Wed, Feb 13, 2019 at 6:11 PM Eduardo Garro Crevillen <
> >> >> > edgarcre at iteam.upv.es> wrote:
> >> >> >
> >> >> >> Hello Justin!
> >> >> >>
> >> >> >> Thank you for your kind help.
> >> >> >>
> >> >> >> We have tried to send the video with your *ffmpeg/ffplay*
> >> configuration
> >> >> >> and it didn't work either. However, after routing both PCs with
> the
> >> >> >> following sentences, we were able to start playing the video:
> >> >> >>
> >> >> >> srseNB: *sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev
> sgi_mb*
> >> >> >> srsUE: *sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev
> >> tun_srsue*
> >> >> >>
> >> >> >> However, as you can see in the attached photo, the data rate was
> not
> >> >> >> enough and the video was received quite pixelled. We have tried to
> >> >> increase
> >> >> >> the multicast data rate by increasing the number of RBs to 100
> >> >> (--enb.n_prb
> >> >> >> = 100), by assigning more subframes to PMCH (sf_alloc_info = 64 in
> >> >> SIB13),
> >> >> >> and/or by increasing the MTCH MCS (data_mcs_r9=25 in
> >> >> >> srsLTE/srsenb/src/upper/rrc.cc), but none of them has helped.
> >> >> >>
> >> >> >> We will really appreciate if you can guide us on how to increase
> the
> >> >> >> multicast data rate in order to receive a stable video stream.
> >> >> >>
> >> >> >> Kind regards, Eduardo.
> >> >> >>
> >> >> >>
> >> >> >> Justin Tallon <justin.tallon at softwareradiosystems.com> escribió:
> >> >> >>
> >> >> >> > Hey Eduardo!
> >> >> >> >
> >> >> >> > I have responded inline below!
> >> >> >> >
> >> >> >> > Regards,
> >> >> >> > Justin
> >> >> >> > ____
> >> >> >> > Justin Tallon Ph.D.
> >> >> >> >
> >> >> >> > Software Radio Systems (SRS)
> >> >> >> > http://www.softwareradiosystems.com
> >> >> >> >
> >> >> >> > +353-86-067-0753 | justin.tallon at softwareradiosystems.com
> >> >> >> >
> >> >> >> >
> >> >> >> > On Tue, Feb 12, 2019 at 11:42 AM Eduardo Garro Crevillen <
> >> >> >> > edgarcre at iteam.upv.es> wrote:
> >> >> >> >
> >> >> >> >> Thank you Justin for your help,
> >> >> >> >>
> >> >> >> >> I guess then if we modify this value, which is currently
> >> hard-coded
> >> >> with
> >> >> >> >> mcs=10 to a higher values and compile the code again we will be
> >> able
> >> >> to
> >> >> >> >> transmit higher bitrates.
> >> >> >> >>
> >> >> >> > Yes, this will work.
> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> > On the other hand, let me give you a little background of our
> work
> >> >> with
> >> >> >> >> srsLTE and why we are asking about it. We (UPV) are
> collaborating
> >> >> within
> >> >> >> >> 5G-Xcast project with IRT (Jordi Gimenez in cc) in a potential
> >> eMBMS
> >> >> >> >> Proof-of-Concept. We found that SRSLTE supported it from last
> >> >> September
> >> >> >> >> (18.09), so we decided to start from that version.
> >> >> >> >>
> >> >> >> > Nice to hear of someone using it!
> >> >> >> >
> >> >> >> >
> >> >> >> >> After checking that socat message worked fine, we tried to
> >> >> >> >> transmit/receive a video stream with two different PCs using
> >> srsLTE
> >> >> and
> >> >> >> by
> >> >> >> >> means of VLC like this:
> >> >> >> >>
> >> >> >> >> - We first stream the video from srsEPC/srsMBMS/srseNB PC with
> >> VLC to
> >> >> >> >> rtp://239.255.1.1:6000.
> >> >> >> >> - We next check that running a second VLC in the same PC we are
> >> able
> >> >> to
> >> >> >> >> receive the video on the same IP address.
> >> >> >> >> - Then we try to receive the video stream at srsUE PC reading
> at
> >> the
> >> >> >> same
> >> >> >> >> ip address. However, we are not currently able to do it.
> >> >> >> >>
> >> >> >> >> We found that the problem was because the default interfaces
> were
> >> not
> >> >> >> the
> >> >> >> >> "sgi_mb" and "tun_srsue" in srsenb and srsue PCs,
> respectively. We
> >> >> >> looked
> >> >> >> >> for how to the transmit the video stream over a specific
> >> interface in
> >> >> >> VLC,
> >> >> >> >> but we failed. We then found how to route all multicast IP
> >> address to
> >> >> >> >> "sgi_mb" with: *sudo route add -net 224.0.0.0 netmask 240.0.0.0
> >> dev
> >> >> >> >> sgi_mb* and running a *tcpdump* on the srsue we could see the
> >> >> multicast
> >> >> >> >> packets. However, we don't know how to play the video as the
> same
> >> >> route
> >> >> >> in
> >> >> >> >> srsue but to "tun_srsue" didn't work. We will really
> appreciate if
> >> >> you
> >> >> >> can
> >> >> >> >> help us how to solve this issue.
> >> >> >> >>
> >> >> >> > try this, I have used this in the past to get video over eMBMS
> >> >> >> > @UE
> >> >> >> > ffplay udp://tun_srsue@239.255.1.1:23000
> >> >> >> > @MBMS-GW
> >> >> >> > ffmpeg -i <video.mp4> -v 0 -vcodec h264 -f mpegts udp://
> >> >> >> > sgi_mb at 239.255.1.1:23000
> >> >> >> >
> >> >> >> > you will need to download ffmpeg/ffplay to do this, I hope that
> is
> >> >> not a
> >> >> >> > problem.
> >> >> >> >
> >> >> >> >
> >> >> >> >>
> >> >> >> >> The question related with the MCS configuration came from the
> >> >> >> >> discontinuous multicast packet extracted with tcpdump, so we
> >> tried to
> >> >> >> >> increase this value but we didn't find where it was configured.
> >> >> Another
> >> >> >> >> problem we have suffered is that when the srsuE passes to RRC
> IDLE
> >> >> >> state,
> >> >> >> >> no more MBMS packets can be received (even coming back to RRC
> >> >> CONNECTED
> >> >> >> >> with pings), so that we have to restart both srsenb and srsue
> >> every
> >> >> >> time.
> >> >> >> >>
> >> >> >> > It is possible that the service is brought down after you enter
> an
> >> RRC
> >> >> >> IDLE
> >> >> >> > state, you could try restarting the service with
> >> "mbms_service_start 0
> >> >> >> > 4321" in the command line of the UE. In any case, if this
> happens
> >> >> again,
> >> >> >> > send me the logs and I can have a look at them and see what's
> going
> >> >> on.
> >> >> >> >
> >> >> >> >
> >> >> >> >>
> >> >> >> >> Kind regards, Eduardo.
> >> >> >> >>
> >> >> >> >> Justin Tallon <justin.tallon at softwareradiosystems.com>
> escribió:
> >> >> >> >>
> >> >> >> >> > Hey Eduardo,
> >> >> >> >> >
> >> >> >> >> > The data MCS is currently hardcoded in the
> >> >> >> rrc::configure_mbsfn_sibs() in
> >> >> >> >> > srsenb/src/upper/rrc.cc.
> >> >> >> >> >
> >> >> >> >> > The reason being the parameters set in this function are
> meant
> >> to
> >> >> be
> >> >> >> set
> >> >> >> >> by
> >> >> >> >> > the M2/M3 interface between the MCE and the eNodeB and this
> >> >> interface
> >> >> >> was
> >> >> >> >> > not ready at the time of the last release. We hope to have
> all
> >> >> these
> >> >> >> >> values
> >> >> >> >> > configurable through this interface in the next release. In
> >> terms
> >> >> of
> >> >> >> the
> >> >> >> >> > signaling MCS, they can only be specific values 2, 7, 13 or
> 19.
> >> >> >> >> represented
> >> >> >> >> > as n2, n7 etc. (see picture below).
> >> >> >> >> >
> >> >> >> >> > If have any issues getting up and running with eMBMS, let me
> >> know!
> >> >> >> >> >
> >> >> >> >> > Thanks,
> >> >> >> >> > Justin
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > [image: image.png]
> >> >> >> >> > ____
> >> >> >> >> > Justin Tallon Ph.D.
> >> >> >> >> >
> >> >> >> >> > Software Radio Systems (SRS)
> >> >> >> >> > http://www.softwareradiosystems.com
> >> >> >> >> >
> >> >> >> >> > +353-86-067-0753 | justin.tallon at softwareradiosystems.com
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > On Tue, Feb 12, 2019 at 12:57 AM Eduardo Garro Crevillen <
> >> >> >> >> > edgarcre at iteam.upv.es> wrote:
> >> >> >> >> >
> >> >> >> >> >> As I mentioned earlier, we are now trying to transmit a
> >> multicast
> >> >> >> >> >> content through MBMS.
> >> >> >> >> >>
> >> >> >> >> >> We found this instructions in November 2018 thread:
> >> >> >> >> >>
> >> >> >> >> >> """
> >> >> >> >> >> #@MBMS-GW
> >> >> >> >> >> echo "Hello! I am a multicast packet!" | socat STDIO
> >> >> >> >> >> UDP4-DATAGRAM:239.255.1.1:6000
> >> >> >> >> >>
> >> >> ,bind=172.16.0.254,ip-multicast-if=172.16.0.254,ip-multicast-ttl=64
> >> >> >> >> >> #@UE
> >> >> >> >> >> socat STDIO
> >> >> >> >> >> UDP4-RECV:6000,bind=239.255.1.1,ip-add-membership=
> 239.255.1.1:
> >> >> >> tun_srsue
> >> >> >> >> >> """
> >> >> >> >> >>
> >> >> >> >> >> We have succesfully checked that the multicast message is
> seen
> >> in
> >> >> the
> >> >> >> >> >> srsUE. Next, we have tried to send a video content making
> use
> >> of
> >> >> VLC,
> >> >> >> >> >> but we have not been able yet. We would also like to know
> how
> >> to
> >> >> >> >> >> configure the PMCH MCS, since it is not specified in the
> >> enb.conf
> >> >> >> >> >> files. We have found that in sib.conf.mbsfn there is a
> >> >> >> signalling_mcs,
> >> >> >> >> >> but its default value is "n2", instead of an integer number
> >> >> {0-28}.
> >> >> >> >> >>
> >> >> >> >> >> Thanks again, Eduardo.
> >> >> >> >> >>
> >> >> >> >> >> Eduardo Garro Crevillen <edgarcre at iteam.upv.es> escribió:
> >> >> >> >> >>
> >> >> >> >> >> > Hello again,
> >> >> >> >> >> >
> >> >> >> >> >> > We have been finally able to run properly srsLTE over the
> >> >> bittium
> >> >> >> >> >> > phone. After several configurations we decided to modify
> the
> >> epc
> >> >> >> apn
> >> >> >> >> >> > from 'srsapn' to 'ims' and it worked. I guess that as
> Pedro
> >> >> >> >> >> > mentioned, the Bittium always sent this apn_name
> regardless
> >> of
> >> >> >> >> >> > providing other alternatives.
> >> >> >> >> >> >
> >> >> >> >> >> > For connecting to internet we later masquerade the local
> >> network
> >> >> >> >> >> > interface with the Wi-Fi interface by running the
> >> >> >> >> >> > ./srsepc_if_masq.sh <IF_NAME>. Again, thanks Pedro for
> your
> >> help
> >> >> >> >> >> > with the issue.
> >> >> >> >> >> >
> >> >> >> >> >> > We now are dealing with the MBMS feature, but I will
> create a
> >> >> new
> >> >> >> >> >> > thread for this.
> >> >> >> >> >> >
> >> >> >> >> >> > Kind regards, Eduardo.
> >> >> >> >> >> >
> >> >> >> >> >> > Eduardo Garro Crevillen <edgarcre at iteam.upv.es> escribió:
> >> >> >> >> >> >
> >> >> >> >> >> >> Hi Pedro again,
> >> >> >> >> >> >>
> >> >> >> >> >> >> I have found one option within phone settings to
> >> enable/disable
> >> >> >> the
> >> >> >> >> >> >> VoLTE IMS. Nevertheless, the mobile is still not able to
> >> get an
> >> >> >> IP.
> >> >> >> >> >> >> I attach two new log and pcap files with VoLTE IMS
> activated
> >> >> and
> >> >> >> >> >> >> deactivated. If you take a look both configurations say
> at
> >> some
> >> >> >> >> >> >> time that there is and integrity failure (Integrity check
> >> >> failure.
> >> >> >> >> >> >> Algorithm=EIA1), and the errors start from that moment.
> >> >> However,
> >> >> >> if
> >> >> >> >> >> >> I change from EIA1 to EIA2 is still not working?
> >> >> >> >> >> >>
> >> >> >> >> >> >> Any other option to check?
> >> >> >> >> >> >>
> >> >> >> >> >> >> Pedro Alvarez <pedro.alvarez at softwareradiosystems.com>
> >> >> escribió:
> >> >> >> >> >> >>
> >> >> >> >> >> >>> Eduardo,
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> The problem does not seem to be in the OP/OPc, AMF,
> etc.,
> >> >> since
> >> >> >> the
> >> >> >> >> >> >>> phone accepts the authentication/security-mode-command.
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> The problem seems to be in the APN settings. You are
> >> replying
> >> >> to
> >> >> >> ESM
> >> >> >> >> >> >>> information request with the APN name == "ims".
> >> >> >> >> >> >>> Can you try to see why you are sending "ims" as the APN
> >> name?
> >> >> Any
> >> >> >> >> >> >>> setting on the phone to disable IMS?
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> You do not need to set apnuser/apnpass.
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> Regards,
> >> >> >> >> >> >>> Pedro
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> On Thu, Feb 7, 2019 at 12:55 PM Eduardo Garro Crevillen
> >> >> >> >> >> >>> <edgarcre at iteam.upv.es> wrote:
> >> >> >> >> >> >>>>
> >> >> >> >> >> >>>> Hello Pedro,
> >> >> >> >> >> >>>>
> >> >> >> >> >> >>>> We have checked that the same apn configuration (apn =
> >> >> srsapn)
> >> >> >> is
> >> >> >> >> in
> >> >> >> >> >> >>>> both, the epc.conf and in Bittium. We don't know if we
> >> need
> >> >> to
> >> >> >> >> >> >>>> configure something else, e.g. apnuser/apnpass. Since
> >> these
> >> >> >> fields
> >> >> >> >> are
> >> >> >> >> >> >>>> not defined in epc.conf, we have left blank in our
> mobile.
> >> >> May
> >> >> >> be
> >> >> >> >> the
> >> >> >> >> >> >>>> problem caused because of a bad USIM <-> user_db.csv
> >> >> >> >> configuration? We
> >> >> >> >> >> >>>> have been reading previous question were an AMF = 8000
> was
> >> >> >> >> >> >>>> recommended, but we are using 9001. In addition,
> another
> >> >> comment
> >> >> >> >> was
> >> >> >> >> >> >>>> that milenage algorithm is not supported for opc in
> >> previous
> >> >> >> srsLTE
> >> >> >> >> >> >>>> releases.
> >> >> >> >> >> >>>>
> >> >> >> >> >> >>>> Kind regards, Eduardo.
> >> >> >> >> >> >>>>
> >> >> >> >> >> >>>> PS: In case it helps, we have succusfully connected
> with a
> >> >> >> virtual
> >> >> >> >> >> >>>> srsUE (ue.conf), but Bittium is not able to connect.
> >> >> >> >> >> >>>>
> >> >> >> >> >> >>>> Pedro Alvarez <pedro.alvarez at softwareradiosystems.com>
> >> >> >> escribió:
> >> >> >> >> >> >>>>
> >> >> >> >> >> >>>>> Can you double check if the APN configuration matches
> in
> >> the
> >> >> >> EPC
> >> >> >> >> >> >>>>> and the UE?
> >> >> >> >> >> >>>>>
> >> >> >> >> >> >>>>> On Thu, Feb 7, 2019 at 10:59 AM Eduardo Garro
> Crevillen
> >> >> >> >> >> >>>>> <edgarcre at iteam.upv.es> wrote:
> >> >> >> >> >> >>>>>>
> >> >> >> >> >> >>>>>>
> >> >> >> >> >> >>>>>> Hello everyone,
> >> >> >> >> >> >>>>>>
> >> >> >> >> >> >>>>>> We have just started trying to implement the srsLTE
> >> suite.
> >> >> We
> >> >> >> are
> >> >> >> >> >> >>>>>> using the srsepc, the srsenb which is connected to a
> >> USRP
> >> >> B210
> >> >> >> >> and
> >> >> >> >> >> >>>>>> a sysmocom USIM inside a Bittium phone as UE.
> However,
> >> >> >> although
> >> >> >> >> it
> >> >> >> >> >> >>>>>> seems that the UE is correctly attached, it does not
> get
> >> >> any
> >> >> >> IP
> >> >> >> >> >> >>>>>> address. In the attachment you can find the .log and
> >> .pcap
> >> >> >> files.
> >> >> >> >> >> >>>>>> Taking a look to the epc.log it seems that there is
> an
> >> >> error
> >> >> >> in
> >> >> >> >> the
> >> >> >> >> >> >>>>>> NAS authentication protocol. We have thought that
> there
> >> >> was a
> >> >> >> >> >> >>>>>> problem with the USIM data. However, we have checked
> >> >> several
> >> >> >> >> times
> >> >> >> >> >> >>>>>> that the IMSI, OPC and K are correctly included
> within
> >> the
> >> >> >> >> >> >>>>>> ue_db.csv. This the included line:
> >> >> >> >> >> >>>>>>
> >> >> >> >> >> >>>>>>
> >> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> ue4,901700000000004,99728e5d250001ba5f322c82d002db86,opc,b8993ca66ce802c03a2c16d237e90cd1,9001,0000000012fa,7
> >> >> >> >> >> >>>>>>
> >> >> >> >> >> >>>>>> Maybe there is an error regarding the SQN or the QCI?
> >> >> Since we
> >> >> >> >> have
> >> >> >> >> >> >>>>>> not found any message on the mailing list archives
> >> talking
> >> >> >> about
> >> >> >> >> >> >>>>>> these problem, we kindly ask for your help.
> >> >> >> >> >> >>>>>>
> >> >> >> >> >> >>>>>> Kind regards, Eduardo
> >> >> >> >> >> >>>>>>
> >> >> >> >> >> >>>>>> -----------------------------------------
> >> >> >> >> >> >>>>>> Eduardo Garro Crevillén, R&D Engineer
> >> >> >> >> >> >>>>>> Universitat Politècnica de València
> >> >> >> >> >> >>>>>> iTEAM Research Institute
> >> >> >> >> >> >>>>>> Mobile Communications Group
> >> >> >> >> >> >>>>>> -----------------------------------------
> >> >> >> >> >> >>>>>> _______________________________________________
> >> >> >> >> >> >>>>>> srslte-users mailing list
> >> >> >> >> >> >>>>>> srslte-users at lists.softwareradiosystems.com
> >> >> >> >> >> >>>>>>
> >> >> >> >>
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
> >> >> >> >> >> >>>>
> >> >> >> >> >> >>>>
> >> >> >> >> >> >>>>
> >> >> >> >> >> >>>> -----------------------------------------
> >> >> >> >> >> >>>> Eduardo Garro Crevillén, R&D Engineer
> >> >> >> >> >> >>>> Universitat Politècnica de València
> >> >> >> >> >> >>>> iTEAM Research Institute
> >> >> >> >> >> >>>> Mobile Communications Group
> >> >> >> >> >> >>>> -----------------------------------------
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> -----------------------------------------
> >> >> >> >> >> >>  Eduardo Garro Crevillén, R&D Engineer
> >> >> >> >> >> >>  Universitat Politècnica de València
> >> >> >> >> >> >>  iTEAM Research Institute
> >> >> >> >> >> >>  Mobile Communications Group
> >> >> >> >> >> >> -----------------------------------------
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> > -----------------------------------------
> >> >> >> >> >> >   Eduardo Garro Crevillén, R&D Engineer
> >> >> >> >> >> >   Universitat Politècnica de València
> >> >> >> >> >> >   iTEAM Research Institute
> >> >> >> >> >> >   Mobile Communications Group
> >> >> >> >> >> > -----------------------------------------
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> -----------------------------------------
> >> >> >> >> >>    Eduardo Garro Crevillén, R&D Engineer
> >> >> >> >> >>    Universitat Politècnica de València
> >> >> >> >> >>    iTEAM Research Institute
> >> >> >> >> >>    Mobile Communications Group
> >> >> >> >> >> -----------------------------------------
> >> >> >> >> >> _______________________________________________
> >> >> >> >> >> srslte-users mailing list
> >> >> >> >> >> srslte-users at lists.softwareradiosystems.com
> >> >> >> >> >>
> >> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
> >> >> >> >> >>
> >> >> >> >>
> >> >> >> >> -----------------------------------------
> >> >> >> >>   Eduardo Garro Crevillén, R&D Engineer
> >> >> >> >>   Universitat Politècnica de València
> >> >> >> >>   iTEAM Research Institute
> >> >> >> >>   Mobile Communications Group
> >> >> >> >> -----------------------------------------
> >> >> >> >>
> >> >> >>
> >> >> >> -----------------------------------------
> >> >> >>   Eduardo Garro Crevillén, R&D Engineer
> >> >> >>   Universitat Politècnica de València
> >> >> >>   iTEAM Research Institute
> >> >> >>   Mobile Communications Group
> >> >> >> -----------------------------------------
> >> >> >>
> >> >>
> >> >> -----------------------------------------
> >> >>   Eduardo Garro Crevillén, R&D Engineer
> >> >>   Universitat Politècnica de València
> >> >>   iTEAM Research Institute
> >> >>   Mobile Communications Group
> >> >> -----------------------------------------
> >> >>
> >>
> >>
> >>
> >> -----------------------------------------
> >>    Eduardo Garro Crevillén, R&D Engineer
> >>    Universitat Politècnica de València
> >>    iTEAM Research Institute
> >>    Mobile Communications Group
> >> -----------------------------------------
> >>
>
>
>
> -----------------------------------------
>    Eduardo Garro Crevillén, R&D Engineer
>    Universitat Politècnica de València
>    iTEAM Research Institute
>    Mobile Communications Group
> -----------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190214/de34ba80/attachment.htm>