[srslte-users] MBMS

Justin Tallon justin.tallon at softwareradiosystems.com
Thu May 16 14:42:11 UTC 2019


Hey!

Thats good to hear.

I suspect it works without the -re command is that you are playing a higher
res video than I was, if you use a low res video it will send the entire
video as fast as possible and the buffering at some point will overflow.

Glad to hear you are up and running!

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 16, 2019 at 4:35 PM JESÚS SANTIAGO FRANCO OROZCO <
jesfraor at upv.edu.es> wrote:

> Hi Justin,all
>
>
>
>
>
> Yeah, it works  properly after “  the Commits on May 10, 2019”. We have
> tested without -re and we have got the same result great result.
>
>
>
> Another thing, we also have tested it changing the following parameters,
> and they don’t affect the video play.
>
>
>
> Kind regards
>
> Santi
>
>
>
> *De:* Justin Tallon <justin.tallon at softwareradiosystems.com>
> *Enviado el:* miércoles, 15 de mayo de 2019 17:36
> *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>; srslte-users <
> srslte-users at lists.softwareradiosystems.com>
> *Asunto:* Re: [srslte-users] MBMS
>
>
>
> 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/20190516/e1a7991d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 29213 bytes
Desc: not available
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20190516/e1a7991d/attachment.jpg>


More information about the srsran-users mailing list