[srslte-users] UE attached but without IP

Wed Feb 13 17:11:13 UTC 2019

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
-----------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190213/1609e658/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: srslte-mbms.jpeg
Type: image/jpeg
Size: 2162666 bytes
Desc: not available
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190213/1609e658/attachment.jpeg>