[srslte-users] UE attached but without IP

Thu Feb 14 09:23:49 UTC 2019

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
-----------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190214/fbf156b0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pcap and log files.zip
Type: application/zip
Size: 1380225 bytes
Desc: not available
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190214/fbf156b0/attachment.zip>