[srslte-users] MBMS

Justin Tallon justin.tallon at softwareradiosystems.com
Wed May 15 15:36:18 UTC 2019


Hey guys,

I had success today using the following commands:

@UE
sudo route add -net 239.255.1.0 netmask 255.255.255.0 dev tun_srsue
ffplay udp://tun_srsue@239.255.1.1:23000

@mbms-gw
sudo route add -net 239.255.1.0 netmask 255.255.255.0 dev sgi_mb
ffmpeg -re -i <video_path> -v 0 -vcodec h264 -f mpegts udp://
sgi_mb at 239.255.1.1:23000


 I hope this also works for you,

Cheers,
Justin
____
Justin Tallon Ph.D.

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

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


On Tue, May 14, 2019 at 6:15 PM Justin Tallon <
justin.tallon at softwareradiosystems.com> wrote:

> Hey guys,
> Thanks for the feedback, so do you see the same behaviour with iperf test
> we did previously?
>
> I was able to get 0% error at the application layer with this test.
>
> I'll have a look at these logs now.
>
>
> Justin
>
> Regards
>
> On Tue, 14 May 2019, 12:57 , <alibla at iteam.upv.es> wrote:
>
>> Hi Justin, All,
>>
>> We have noticed that the problem comes from the process of assembling the
>> PDU in a higher layer SDU (in the receiver).
>>
>> For example, in the attached logs, on the transmitter side , there are
>> 2130 SDU and 1167 PDUs. Meanwhile, on the receiver side, we can see the
>> almost the same PDUs (1123) but only 1364 SDUs.
>>
>> We have tested, sending the same video, through the unicast network and
>> we have received it correctly, visualizing it well.
>>
>> I think this information is useful, in order to identify the problem and
>> fix it.
>>
>> BR
>>
>> Alvaro
>>
>>
>>
>> *De:* Justin Tallon <justin.tallon at softwareradiosystems.com>
>> *Enviado el:* viernes, 10 de mayo de 2019 16:47
>> *Para:* Alvaro Ibañez Latorre <alibla at iteam.upv.es>
>> *CC:* JESÚS SANTIAGO FRANCO OROZCO <jesfraor at upv.edu.es>; Jesus Santiago
>> Franco Orozco <jesfraor at iteam.upv.es>; Jordi Gimenez <
>> jordi.gimenez at irt.de>; Manuel Fuentes (iTEAM-UPV) <mafuemue at iteam.upv.es>;
>> Eduardo Garro Crevillen <edgarcre at iteam.upv.es>
>> *Asunto:* Re: [srslte-users] MBMS
>>
>>
>>
>> Hey guys,
>>
>>
>> We usually test with iperf in our testing as it is automated and this
>> gives the % of packet errors at the application level.  I have not done a
>> video test in a while.
>>
>>
>>
>> One thing I would make sure is that the peak rate of the video is not
>> greater than the total bandwidth available.
>>
>>
>>
>>
>>
>> this is the commands I would use with the video.
>>
>>
>>
>> @UE
>>
>> ffplay udp://tun_srsue@239.255.1.1:23000
>>
>> @MBMS-GW
>>
>> ffmpeg -i ./home.mp4 -v 0 -vcodec h264 -f mpegts udp://
>> sgi_mb at 239.255.1.1:23000
>>
>>
>>
>> ____
>> Justin Tallon Ph.D.
>>
>> Software Radio Systems (SRS)
>> http://www.softwareradiosystems.com
>>
>> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>>
>>
>>
>>
>>
>> On Fri, May 10, 2019 at 2:32 PM <alibla at iteam.upv.es> wrote:
>>
>> Hi Justin, all
>>
>> We’ve tested with the new code and we’ve seen a great improvement, but
>> it’s not enough.
>>
>> We think the issues are related to the way we are transmitting the video
>> or real time issues.
>>
>> In the receiver side we are seeing the video well for a few seconds, but
>> then the image becomes pixelated, a piece of the image freezes, etc. The
>> problems we are experiencing may be due to the graphics card? Using tcpdump
>> on both sides we get on the transmitter side that 1900 UDP packets are
>> sent, 800 UDP packets out of 1900 have been dropped by kernel. On the
>> receiver side only 1000 are captured.
>>
>> Currently, we are testing ffmpeg and ffplay with different options.
>>
>> What are the instructions you’re using? Have you tested the same and are
>> you able to receive the video correctly?
>>
>> BR
>>
>> Alvaro
>>
>>
>>
>> *De:* Justin Tallon <justin.tallon at softwareradiosystems.com>
>> *Enviado el:* martes, 7 de mayo de 2019 10:17
>> *Para:* JESÚS SANTIAGO FRANCO OROZCO <jesfraor at upv.edu.es>
>> *CC:* Alvaro Ibañez Latorre <alibla at iteam.upv.es>; Jesus Santiago Franco
>> Orozco <jesfraor at iteam.upv.es>; Jordi Gimenez <jordi.gimenez at irt.de>;
>> Manuel Fuentes (iTEAM-UPV) <mafuemue at iteam.upv.es>; Eduardo Garro
>> Crevillen <edgarcre at iteam.upv.es>
>> *Asunto:* Re: [srslte-users] MBMS
>>
>>
>>
>> These results look strange, it doesn't appear to be functioning correctly
>> end-to-end.
>>
>>
>>
>> We have just pushed a new release of the code, I think the issues you are
>> seeing here should not be present in this version of the code.
>>
>>
>>
>> If you could pull this code and rerun this test that would be great!
>>
>>
>>
>> Thanks,
>> Justin.
>>
>>
>>
>>
>>
>> On Fri, 3 May 2019, 12:54 JESÚS SANTIAGO FRANCO OROZCO, <
>> jesfraor at upv.edu.es> wrote:
>>
>> Hi Justin, everybody
>>
>>
>>
>> I send you the results of iperf tool test
>>
>>
>>
>> kind regards
>>
>> Santi
>>
>>
>>
>>
>> ------------------------------
>>
>> *De:* Justin Tallon <justin.tallon at softwareradiosystems.com>
>> *Enviado:* jueves, 2 de mayo de 2019 20:47:00
>> *Para:* Alvaro Ibañez Latorre
>> *Cc:* Jesus Santiago Franco Orozco; Jordi Gimenez; Manuel Fuentes
>> (iTEAM-UPV); Eduardo Garro (iTEAM-UPV)
>> *Asunto:* Re: [srslte-users] MBMS
>>
>>
>>
>> Hey Guys,
>>
>>
>> I will have a look at these logs now, just to let you know. We are doing
>> a release with new code tomorrow which has many improvements and
>> optimizations including for eMBMS.
>>
>>
>> Can you try the following:
>>
>>
>>
>> @UE
>>
>> sudo route add -net 239.255.1.0 netmask 255.255.255.0 dev tun_srsue
>>
>> iperf -s -u -B 239.255.1.1 -i 1
>>
>>
>>
>> @mbms-gw
>>
>> sudo route add -net 239.255.1.0 netmask 255.255.255.0 dev sgi_mb
>>
>> iperf -u -c 239.255.1.1 -b 5M -T 64 -t 60
>>
>>
>>
>>
>>
>> and tell me the output if iperf at the UE?
>>
>>
>>
>> Regards,
>>
>> Justin
>>
>>
>>
>> ____
>> Justin Tallon Ph.D.
>>
>> Software Radio Systems (SRS)
>> http://www.softwareradiosystems.com
>>
>> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>>
>>
>>
>>
>>
>> On Thu, May 2, 2019 at 5:50 PM <alibla at iteam.upv.es> wrote:
>>
>> Hi again,
>>
>> This is a graphic example of our problem. In this case, the PC2 (on the
>> right) is the EPC+eNB and the PC1 (on the left) is the UE.
>>
>> As you can see in the video attached (IMG_7834.MOV) we are receiving a
>> video with poor quality and it does not play constantly.
>>
>> I’ve also attached the logs.
>>
>> BR
>>
>> Alvaro
>>
>>
>>
>> *De:* srslte-users <srslte-users-bounces at lists.softwareradiosystems.com> *En
>> nombre de *alibla at iteam.upv.es
>> *Enviado el:* jueves, 2 de mayo de 2019 17:19
>> *Para:* 'Justin Tallon' <justin.tallon at softwareradiosystems.com>
>> *CC:* 'srslte-users' <srslte-users at lists.softwareradiosystems.com>;
>> 'Jesus Santiago Franco Orozco' <jesfraor at iteam.upv.es>
>> *Asunto:* Re: [srslte-users] MBMS
>>
>>
>>
>> Hi Justin, all,
>>
>> We thought that our problem is related to Real time processing. In order
>> to check it, we have installed Low Latency kernel ( 4.15.0.49.51) in Ubuntu
>> 18.04 and disabled p-state and c-states, frecuency scaling and
>> hyperthreading (hyperthreading off).
>>
>> With these small changes, the video that we are transmitting is being
>> received (in PC2) with better quality, but still without displaying it
>> correctly.
>>
>> For example, with hyperthreading on, 5000 discards out of 20000 messages
>> and with hyperthreading off 700 out of 27000 messages.
>>
>> We are using the last commit available (Release 18.12 – commit
>> 429ee9019dcbf5bb261ac332425a9bc78b1e8a6c)
>>
>>
>>
>> What is your setup??? Are you able to send and receive a video correctly?
>>
>> If you ask, we can attach logs or any other information.
>>
>> BR
>>
>> Alvaro
>>
>>
>>
>> *De:* srslte-users <srslte-users-bounces at lists.softwareradiosystems.com> *En
>> nombre de *alibla at iteam.upv.es
>> *Enviado el:* jueves, 18 de abril de 2019 10:35
>> *Para:* 'Justin Tallon' <justin.tallon at softwareradiosystems.com>
>> *CC:* 'srslte-users' <srslte-users at lists.softwareradiosystems.com>;
>> 'Jesus Santiago Franco Orozco' <jesfraor at iteam.upv.es>
>> *Asunto:* Re: [srslte-users] MBMS
>>
>>
>>
>> Hi, Justin, All,
>>
>> I have test using the commit  6bea1814c9cebc35639f7ba0027750e370aada4d
>> with the corresponding commands.
>>
>> Unfortunately the behavior is the same.
>>
>> Find attached “SRS_MBMS.zip” with the commands (CMD.txt), Config files
>> and LOGs, from both sites.
>>
>> I have also included screenshots, so you can see the video we are
>> receiving.
>>
>> Thanks a lot for your continuous assistance and have a nice Easter
>> Holidays.
>>
>> BR
>>
>> Alvaro
>>
>>
>>
>> *De:* Justin Tallon <justin.tallon at softwareradiosystems.com>
>> *Enviado el:* martes, 16 de abril de 2019 14:22
>> *Para:* Alvaro Ibañez Latorre <alibla at iteam.upv.es>
>> *CC:* Jordi Gimenez <jordi.gimenez at irt.de>; srslte-users <
>> srslte-users at lists.softwareradiosystems.com>; Jesus Santiago Franco
>> Orozco <jesfraor at iteam.upv.es>; Manuel Fuentes (iTEAM-UPV) <
>> mafuemue at iteam.upv.es>; Eduardo Garro (iTEAM-UPV) <edgarcre at iteam.upv.es>
>> *Asunto:* Re: AW: [srslte-users] MBMS
>>
>>
>>
>> Hey guys,
>>
>>
>> Can you try a checkout of commit 6bea1814c9cebc35639f7ba0027750e370aada4d
>> and run experiment again.
>>
>>
>>
>>
>>
>> git checkout 6bea1814c9cebc35639f7ba0027750e370aada4d
>>
>> rm -r CMakeCache.txt
>>
>> make clean
>>
>> make -j8
>>
>>
>>
>>
>>
>> Let me know how it goes,
>> Justin
>>
>>
>>
>> ____
>> Justin Tallon Ph.D.
>>
>> Software Radio Systems (SRS)
>> http://www.softwareradiosystems.com
>>
>> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>>
>>
>>
>>
>>
>> On Tue, Apr 16, 2019 at 9:49 AM <alibla at iteam.upv.es> wrote:
>>
>> Hi, Justin, All,
>>
>> We are currently testing MBMS changing parameters, that are related to
>> the MCH table, which Jordi mentioned previously. There is a parameter in
>> SIB2, SubframeAllocationNumFrames, that is set to 1.
>>
>> we have test  with SubframeAllocationNumFrames=4 and UE does not connect
>> to the network anymore.
>>
>> I’ve attached the logs.
>>
>> As you said in a previous email, you can not reproduce the error in your
>> testbed, we wonder if the problem is related to the way we broadcast the
>> video, using ffmpeg and vlc.
>>
>> Can you share the instructions you use to stream the video?
>>
>> BR
>>
>> Alvaro
>>
>>
>>
>> *De:* Jordi Gimenez <jordi.gimenez at irt.de>
>> *Enviado el:* miércoles, 10 de abril de 2019 13:53
>> *Para:* Justin Tallon <justin.tallon at softwareradiosystems.com>
>> *CC:* Alvaro Ibañez Latorre <alibla at iteam.upv.es>; srslte-users <
>> srslte-users at lists.softwareradiosystems.com>; Jesus Santiago Franco
>> Orozco <jesfraor at iteam.upv.es>
>> *Asunto:* AW: AW: [srslte-users] MBMS
>>
>>
>>
>> Hi Justin,
>>
>>
>>
>> We were wondering in the allocation is not right:
>>
>> At the UE we have MCH table:
>> |0|1|1|1|0|0|1|1|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
>>
>> And MCCH table: |0|1|1|1|0|0|1|1|1|0|
>>
>> It looks like only 1 every four frames are allocating MCH data. Perhaps
>> this is the issue (?).
>>
>>
>>
>> Our configs here:
>> https://www.dropbox.com/s/aohbahbwenbadgz/Configs_10_04_19.tar.xz?dl=0
>>
>> The git_log with the commit number here:
>> https://www.dropbox.com/s/fgidievsffn2s59/git_log.txt?dl=0
>>
>>
>>
>> Thanks a lot!
>>
>>
>>
>> kR,
>>
>>
>>
>> Jordi
>>
>>
>>
>> --
>>
>> *Dr.-Ing. Jordi J. Gimenez*
>> Research Engineer – Funksysteme / Radio Systems
>>
>> Jordi.Gimenez at irt.de
>> Tel.: +49 (0)89 32399-341
>> Mob.: +49 1728417993
>>
>> Institut für Rundfunktechnik GmbH
>> Floriansmühlstraße 60, D-80939 München
>>
>> www.irt.de – lab.irt.de
>>
>>
>> R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
>> Managing director:  Michael Hagemeyer
>> Registration court: Munich Commercial Register No. B 5191
>>
>>
>>
>> This e-mail may contain confidential and/or legally protected
>> information. It is exclusively designated for the above mentioned natural
>> or legal person. Unauthorized distribution, copying and sharing is
>> prohibited. If you are not the intended recipient, please notify
>> immediately the sender and destroy this message.
>>
>>
>>
>> *Von:* Justin Tallon <justin.tallon at softwareradiosystems.com>
>> *Gesendet:* Mittwoch, 10. April 2019 00:33
>> *An:* Jordi Gimenez <jordi.gimenez at irt.de>
>> *Cc:* Alvaro Ibañez Latorre <alibla at iteam.upv.es>; srslte-users <
>> srslte-users at lists.softwareradiosystems.com>; Jesus Santiago Franco
>> Orozco <jesfraor at iteam.upv.es>
>> *Betreff:* Re: AW: [srslte-users] MBMS
>>
>>
>>
>> Hey Jordi,
>>
>> I see these packets getting discarded in your logs but I cannot replicate
>> this error on our testbed. Can you share the exact commit number you are
>> using as well as the exact conf files again?
>>
>>
>>
>> Thanks,
>> Justin
>>
>>
>> ____
>> Justin Tallon Ph.D.
>>
>> Software Radio Systems (SRS)
>> http://www.softwareradiosystems.com
>>
>> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>>
>>
>>
>>
>>
>> On Tue, Apr 9, 2019 at 8:00 PM Justin Tallon <
>> justin.tallon at softwareradiosystems.com> wrote:
>>
>> Hey Jordi,
>>
>>
>>
>> I will have a look at these logs and get back to you with anything I see.
>>
>>
>>
>>
>>
>> Regards,
>>
>> Justin
>>
>>
>>
>> On Tue, 9 Apr 2019, 19:20 Jordi Gimenez, <jordi.gimenez at irt.de> wrote:
>>
>> Hi Justin,
>>
>>
>>
>> We have tried retrieving the commit but with no success. I also updated
>> to the latest version (we saw a commit related to the SSS when using
>> extended CP from a few days ago) and even try to fix the ch_est issue with
>> this versoin but it is not working.
>>
>>
>>
>> We are attaching the logs of the UE and eNB. This time we register much
>> less crc=KO but at the UE practically all RLC PDUs seem to be discarded due
>> to an issue with the rx window for the unacknowledged mode (at least this
>> is what we are now trying to understand).
>>
>>
>>
>> You can access the logs here:
>>
>> -enb: https://www.dropbox.com/s/mq8jlt5phub46fi/enb.log?dl=0
>>
>> -ue: https://www.dropbox.com/s/tll902uyi8nwrb6/ue.log?dl=0
>>
>>
>>
>> Thanks a lot for your efforts which we very much appreciate.
>>
>>
>>
>> kR,
>>
>>
>>
>> Jordi
>>
>>
>>
>> *Von:* Justin Tallon <justin.tallon at softwareradiosystems.com>
>> *Gesendet:* Mittwoch, 3. April 2019 16:23
>> *An:* Alvaro Ibañez Latorre <alibla at iteam.upv.es>
>> *Cc:* Jordi Gimenez <jordi.gimenez at irt.de>; srslte-users <
>> srslte-users at lists.softwareradiosystems.com>; Jesus Santiago Franco
>> Orozco <jesfraor at iteam.upv.es>
>> *Betreff:* Re: AW: [srslte-users] MBMS
>>
>>
>>
>> Hey guys,
>>
>>
>>
>> Can you try reverting the following commit
>> (d4e72d71288a2d8c58459f5fa4aae5b509395758), recompiling and running your
>> experiment again?
>>
>>
>>
>> Let me know how it goes for you.
>>
>>
>>
>> Regards,
>>
>> Justin
>>
>> ____
>> Justin Tallon Ph.D.
>>
>> Software Radio Systems (SRS)
>> http://www.softwareradiosystems.com
>>
>> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>>
>>
>>
>>
>>
>> On Wed, Apr 3, 2019 at 12:53 PM Alvaro Ibañez Latorre <
>> alibla at iteam.upv.es> wrote:
>>
>> Hi Justin, all,
>> Any news about it?
>> BR
>> Alvaro
>>
>> Justin Tallon <justin.tallon at softwareradiosystems.com> escribió:
>>
>> > Hey guys,
>> >
>> > I am currently trying to reproduce this behavior on our testbed, it
>> seems
>> > that you are receiving many KOs at the PHY layer, ill let you know if I
>> > find similar here.
>> >
>> > Regards,
>> > Justin
>> > ____
>> > Justin Tallon Ph.D.
>> >
>> > Software Radio Systems (SRS)
>> > http://www.softwareradiosystems.com
>> >
>> > +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>> >
>> >
>> > On Thu, Mar 28, 2019 at 6:02 PM Alvaro Ibañez Latorre <
>> alibla at iteam.upv.es>
>> > wrote:
>> >
>> >> Hi Justin, Jordi, all,
>> >> We have also tested with the commands you suggested last week, but the
>> >> behaviour is still the same,
>> >> I've attached the ue logs.
>> >> BR
>> >> Alvaro
>> >>
>> >> Jordi Gimenez <jordi.gimenez at irt.de> escribió:
>> >>
>> >> > Hi Justin,
>> >> >
>> >> > I am attaching the log of the ue. We have tested your suggestions
>> >> > but the behavior is, unfortunately, the same.
>> >> >
>> >> > It was detected a quite low received power, although the reported
>> >> > SNR was OK. I have adjusted some radio parameters and also moved to
>> >> > a lower frequency band. Now the reported power looks fine to me. The
>> >> > mcs_index is 15, which should be fine.
>> >> >
>> >> > As you will see in the log there as some crc=KO in the PMCH, but I
>> >> > think not too many. We can also see the following message many
>> >> > times: [RLC ] [I] MRB1 SN: 14 outside rx window [25:0] – discarding
>> >> > Which worries me a bit more.
>> >> >
>> >> > Please let me know if you need more information. Thank you!
>> >> >
>> >> > kR,
>> >> >
>> >> > Jordi
>> >> >
>> >> > --
>> >> > Dr.-Ing. Jordi J. Gimenez
>> >> > Research Engineer – Funksysteme / Radio Systems
>> >> >
>> >> > Jordi.Gimenez at irt.de<mailto:Jordi.Gimenez at irt.de>
>> >> > Tel.: +49 (0)89 32399-341
>> >> > Mob.: +49 1728417993
>> >> > Institut für Rundfunktechnik GmbH
>> >> > Floriansmühlstraße 60, D-80939 München
>> >> > www.irt.de<http://www.irt.de/> – lab.irt.de<http://lab.irt.de/>
>> >> >
>> >> > R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
>> >> > Managing director:  Michael Hagemeyer
>> >> > Registration court: Munich Commercial Register No. B 5191
>> >> >
>> >> > This e-mail may contain confidential and/or legally protected
>> >> > information. It is exclusively designated for the above mentioned
>> >> > natural or legal person. Unauthorized distribution, copying and
>> >> > sharing is prohibited. If you are not the intended recipient, please
>> >> > notify immediately the sender and destroy this message.
>> >> >
>> >> > Von: Justin Tallon <justin.tallon at softwareradiosystems.com>
>> >> > Gesendet: Freitag, 22. März 2019 19:04
>> >> > An: Jordi Gimenez <jordi.gimenez at irt.de>
>> >> > Cc: Alvaro Ibañez Latorre <alibla at iteam.upv.es>; srslte-users
>> >> > <srslte-users at lists.softwareradiosystems.com>
>> >> > Betreff: Re: [srslte-users] MBMS
>> >> >
>> >> > Hey Jordi,
>> >> >
>> >> > Can you send on just the UE logs from this last test and also try
>> again
>> >> with
>> >> >
>> >> > average_subframe_enabled = false
>> >> > equalizer_mode      = zf
>> >> >
>> >> > I will also try to reproduce this in the lab to see if i can observe
>> >> > similar behaviour..
>> >> >
>> >> > Regards,
>> >> > Justin
>> >> >
>> >> > ____
>> >> > Justin Tallon Ph.D.
>> >> >
>> >> > Software Radio Systems (SRS)
>> >> > http://www.softwareradiosystems.com<
>> http://www.softwareradiosystems.com/
>> >> >
>> >> >
>> >> > +353-86-067-0753 |
>> >> > justin.tallon at softwareradiosystems.com<mailto:
>> >> justin.tallon at softwareradiosystems.com>
>> >> >
>> >> >
>> >> > On Fri, Mar 22, 2019 at 6:38 PM Jordi Gimenez
>> >> > <jordi.gimenez at irt.de<mailto:jordi.gimenez at irt.de>> wrote:
>> >> > Hi Justin,
>> >> >
>> >> > IRT is going together with UPV on this. I have tried your change.
>> >> > Unfortunately the behavior is the same.
>> >> > The version here is 18.12.
>> >> >
>> >> > I think the link is OK (we can transmit the text message without
>> >> > problems) and with sufficient TX and RX gain the are no reports of
>> >> > link-failure.
>> >> >
>> >> > At the UE screen what we get is an MP4 (or MPEGTS) with many
>> >> > discontinuities so that in the end many packets of the MPEG are
>> >> > missing and we cannot see the video. So we are not just experiencing
>> >> > artifacts in the video but a complete loss of many MPEG packets
>> >> > (looks like we are overflowing a buffer or there is a packet
>> >> > mismatch somewhere).
>> >> >
>> >> > We have also used rtptools to stream the video and generated an
>> >> > MPEGTS over RTP with very low data rate (just to ensure that we are
>> >> > not saturating the MBMS-GW input). The problem is, however, still
>> >> > the same.
>> >> > Another message that appears from time to time when executing the UE
>> is:
>> >> > PMCH 1 extract symbols error expecting 4500 symbols but got 48ßß,
>> lstart
>> >> 3
>> >> >
>> >> > This does not popup always but I am just mentioning it in case you
>> >> > think it could be related to the issue…
>> >> >
>> >> > Anyway, thanks a lot for your continuous assistance.
>> >> >
>> >> > Kind Regards,
>> >> >
>> >> > Jordi
>> >> >
>> >> >
>> >> > Dr.-Ing. Jordi J. Gimenez
>> >> > Research Engineer – Funksysteme / Radio Systems
>> >> >
>> >> > Jordi.Gimenez at irt.de<mailto:Jordi.Gimenez at irt.de>
>> >> > Tel.: +49 (0)89 32399-341
>> >> > Mob.: +49 1728417993
>> >> > Institut für Rundfunktechnik GmbH
>> >> > Floriansmühlstraße 60, D-80939 München
>> >> > www.irt.de<http://www.irt.de/> – lab.irt.de<http://lab.irt.de/>
>> >> >
>> >> > R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
>> >> > Managing director:  Michael Hagemeyer
>> >> > Registration court: Munich Commercial Register No. B 5191
>> >> >
>> >> > This e-mail may contain confidential and/or legally protected
>> >> > information. It is exclusively designated for the above mentioned
>> >> > natural or legal person. Unauthorized distribution, copying and
>> >> > sharing is prohibited. If you are not the intended recipient, please
>> >> > notify immediately the sender and destroy this message.
>> >> >
>> >> > Von: srslte-users
>> >> > <srslte-users-bounces at lists.softwareradiosystems.com<mailto:
>> >> srslte-users-bounces at lists.softwareradiosystems.com>> Im Auftrag von
>> >> Justin
>> >> > Tallon
>> >> > Gesendet: Freitag, 22. März 2019 12:36
>> >> > An: Alvaro Ibañez Latorre
>> >> > <alibla at iteam.upv.es<mailto:alibla at iteam.upv.es>>; srslte-users
>> >> > <srslte-users at lists.softwareradiosystems.com<mailto:
>> >> srslte-users at lists.softwareradiosystems.com>>
>> >> > Betreff: Re: [srslte-users] MBMS
>> >> >
>> >> > Hey Alvaro,
>> >> >
>> >> > Sorry for the delayed response, can you repeat the experiment with
>> >> > snr_estim_alg = none
>> >> > in the UE conf?
>> >> >
>> >> > also, can you tell me which version of the code you are using?
>> >> >
>> >> > Let me know how you get on!
>> >> > Justin
>> >> >
>> >> > ____
>> >> > Justin Tallon Ph.D.
>> >> >
>> >> > Software Radio Systems (SRS)
>> >> > http://www.softwareradiosystems.com<
>> http://www.softwareradiosystems.com/
>> >> >
>> >> >
>> >> > +353-86-067-0753 |
>> >> > justin.tallon at softwareradiosystems.com<mailto:
>> >> justin.tallon at softwareradiosystems.com>
>> >> >
>> >> >
>> >> > On Mon, Mar 18, 2019 at 9:48 AM Alvaro Ibañez Latorre
>> >> > <alibla at iteam.upv.es<mailto:alibla at iteam.upv.es>> wrote:
>> >> >
>> >> > Hi all,
>> >> > I'm testing MBMS, and I have some issues, in the ue's side, when i
>> try
>> >> > to receive a broadcasted video. Specifically i'm receiving a video
>> >> > with poor quality.
>> >> >
>> >> > My - Setup:
>> >> > 1 PC: EPC-eNB running in the same PC (i7 16gB RAM Ubuntu 18.04) ---
>> >> > with USRP B210
>> >> > 2 PC: UE in other PC(i5 32gB RAM Ubuntu 18.04) --- with USRP NI 2901.
>> >> >
>> >> > I'm running these commands:
>> >> >
>> >> > Initializing:
>> >> > EPC (PC 1):
>> >> >>> sudo srsLTE/srsepc/srsepc epc.conf
>> >> >>> sudo srsLTE/srsepc/srsmbms
>> >> >
>> >> > ENB (PC 1):
>> >> >>> sudo srsenb srsLTE/srsenb/enb_mbms.conf --expert.enable_mbsfn true
>> >> >>> sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev sgi_mb
>> >> >
>> >> > UE (PC 2):
>> >> >>> sudo srsLTE/srsue/srsue ue_mbms.conf --log.all_level info
>> >> >>> --expert.mbms_service 0 --expert.average_subframe_enabled false
>> >> >>> sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev tun_srsue
>> >> >
>> >> > In order to broadcast the video, I'm using VLC in PC 1. I'm using
>> >> > ffplay or VLC in PC2.
>> >> > VLC PC1 ---> Opening VLC an broadcasting the video --->
>> >> > :sout=#udp{dst=239.255.0.2:1234<http://239.255.0.2:1234>}
>> >> > :no-sout-all :sout-keep (string of
>> >> > generated emission)
>> >> > VLC PC2 ---> udp://@239.255.1.1:1234<http://239.255.1.1:1234>
>> >> > ffplay PC2 --> ffplay udp://@239.255.0.2:1234<
>> http://239.255.0.2:1234>
>> >> >
>> >> > With VLC in PC2 i'm not receiving anything, but with ffplay i can see
>> >> > the broadcasted video with poor quality. I've attached an image.
>> >> >
>> >> > I've tried sending an echo message:
>> >> > 1 PC: >>echo "Hello! I am a multicast packet!" | socat STDIO
>> >> > UDP4-DATAGRAM:239.255.0.2:6000<http://239.255.0.2:6000
>> >> >,bind=172.16.0.254,ip-multicast-if=172.16.0.254,ip-multicast-ttl=64
>> >> > 2 PC: >> socat STDIO
>> >> > UDP4-RECV:6000,bind=239.255.1.1,ip-add-membership=239.255.1.1:
>> tun_srsue
>> >> > In this case, I receive the message correctly.
>> >> >
>> >> > I've attached the config files and the logs from EPC,eNB and UE.
>> >> > Regards
>> >> > Alvaro
>> >> >
>> >> > _______________________________________________
>> >> > srslte-users mailing list
>> >> > srslte-users at lists.softwareradiosystems.com<mailto:
>> >> srslte-users at lists.softwareradiosystems.com>
>> >> > http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>> >>
>> >>
>> >>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190515/3ab42574/attachment.htm>


More information about the srsran-users mailing list