[srslte-users] UE attached but without IP
Justin Tallon
justin.tallon at softwareradiosystems.com
Thu Feb 14 12:05:27 UTC 2019
Hey Eduardo,
In the latest UE logs i see the following
12:01:45.088594 [PHY0] [I] [03843] PMCH: l_crb=50, tbs=1764, mcs=15,
crc=OK, snr=37.1 dB, n_iter=1, dec_time= 98 us
so the MCS is currently 15.
Also I see,
12:01:46.367292 [MAC ] [I] [05122] MCH Sched Info: LCID: 1, Stop: 146, tti
is 5123
This Stop value indicates the number of subframes scheduled in an MCH
scheduling period. With your current configuration, the maximum number
should be 384 so you are not reaching the capacity of the current link so
this is not the issue most likely.
I do see some failed CRCs in the PMCH, perhaps you are saturating the
receiver as the snr is very high.
The video should still be making it through though? What do you observe at
the video output?
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:56 PM Justin Tallon <
justin.tallon at softwareradiosystems.com> wrote:
> 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/3eeb4060/attachment.htm>
More information about the srsran-users
mailing list