[srslte-users] UE attached but without IP

Tue Feb 12 11:12:02 UTC 2019

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
> -----------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190212/dcee0c73/attachment.htm>