[srslte-users] srsUE error upon decoding the eMBMS signal from Amarisoft eNB

Justin Tallon justin.tallon at softwareradiosystems.com
Wed Oct 31 11:29:44 UTC 2018 

Hey Hassan!

just looking at your console output I notice you are using UHD 13
We recommend you use UHD 3.9.7 LTS.  You will need to install this from
github and choose this version from the correct branch. Also if you
installed UHD from binary you need to remove this first.

Repeat the test with this UHD version.

*apt-get --purge remove* uhd   (and all other uhd packages)
git clone https://github.com/EttusResearch/uhd.git
git checkout UHD.3.9.7-LTS
(follow build process in README)
sudo ldconfig
(then rebuild srslte completely)

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, Oct 30, 2018 at 3:42 PM <hassan.hamdoun at bt.com> wrote:

> Hi Justin,
>
>
>
> Finally got around to get some logs for PRACH error. Attached the eNB and
> UE logs during a PRACH error + stderror for your review
>
>
>
> It seems to me from eNB logs that the eNB thinks UE is connected as it
> starts sending PDCCH and control channel info to UE, however, the UE keeps
> sending PRACH request. I was expecting to see a Random Access Response(RAR)
> message in eNB logs but couldn’t find it!. But behaviour of eNB suggest
> that it is the UE side that is the problem as you can see clearly in
> STDerr(console0.log) that UE connect and send some data , then becomes idle
> and disconnects. But mostly the UE is not aware that it RACH has connected
> and hence keep trying RACH  with different Time Advance to eNB. UE also
> sees(from log) to increase its power with every attempt (PRACH: Transmitted
> preamble=38, tti=3724, CFO=-4.46 KHz, nof_sf=1, target_power=-96.0 dBm).
>
>
>
> This issues appears with/without eMBMS.
>
>
>
> Thanks
>
> Hassan
>
>
>
> *From:* Hamdoun,H,Hassan,TUA8 R
> *Sent:* 29 October 2018 14:56
> *To:* 'Justin Tallon' <justin.tallon at softwareradiosystems.com>
> *Subject:* RE: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> Thanks Justin,
>
>
>
> Will try to isolate the PRACH issues. Generally, would low SNR e a reason
> for this.I don’t fully understand how PRACH process works and what sort of
> parameters and their values (SNR, and what else?)I expect to see in the eNB
> to ensure a successful and reliable attach?
>
>
>
> Back to MCS issues, when we increase the MCS to 20 we get a lot of CRC
> issues, up to MCS 7 we are fine. We discovered some bugs in code and my
> colleague Jonathan has submitted issues to GIT. I am not sure whether
> increasing the MCS bring more issues because of the SDR/PC not handling the
> rate over USB3 or because we have internal issues in software to handle
> such throughput( MCS 20 with 1 MBMS subframe is 3 Mbps, MCS 7 is 0.5 Mbps)
>
>
>
> Thanks
>
> Hassan
>
> *From:* Justin Tallon [mailto:justin.tallon at softwareradiosystems.com]
> *Sent:* 26 October 2018 10:16
> *To:* Hamdoun,H,Hassan,TUA8 R <hassan.hamdoun at bt.com>
> *Subject:* Re: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> Hey Hassan!
>
>
>
> Good to hear you were able to get up and running!
>
>
>
> The timeout is caused by a lack of traffic going over the link, the best
> solution to this is to ping the gateway from the UE once you get attached.
>
>
>
> In terms of the attach issues, I would advise trying to isolate the issue,
> disable eMBMS and ensure you can attach successfully without it first.
>
>
>
>
>
>
>
> ____
> Justin Tallon Ph.D.
>
> Software Radio Systems (SRS)
> http://www.softwareradiosystems.com
>
> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>
>
>
>
>
> On Thu, Oct 25, 2018 at 6:06 PM <hassan.hamdoun at bt.com> wrote:
>
> Hi Justin,
>
> We managed to received MBMS fine and play video. Still have the PRACH
> attachement errors every ow and then, which seems a bit random and comes
> and goes arbitrarly.
>
> Comparing to what configs you provided and current one we have, Changing
> tx_gain or rx_gain doesn’t help much. I’ve also changed  pdsch_max_it=4 and
> snr_estim_algo=none, but don’t see much of a change, the same error occur
> from time to time. We have to close ue, re-run ue code again(sudo srsUE)
> and then we get a successful attachement. Sometimes a proper power cycle is
> needed from USRP 2901 to get it running again.
>
> I compared the ue config you gave me with original but I am not sure if I
> understand what parameter change will result in improving the UE
> attachement process?
>
> The error ( on stderror) we get is:
>
> Random Antenna Transmission: seq =xx, ra-nti=0x5,
>
> Random Antenna Transmission: seq =xx, ra-nti=0x5,
>
> Random Antenna Transmission: seq =xx, ra-nti=0x5,
>
> With seq changing every time. Attached stderr and log for this
>
>
>
> This error appears after a period of timeout or sometimes after UE has
> connected to eNB and runs for a while especially when there is no data from
> eNB.
>
> I am thinking the srsUE doesn’t like no data and idle links. Any pointers.
> I’ll with my colleague try to reproduce this and send stderror and logs in
> a way that captures this but it is quite arbitrary.
>
> Hassan
>
>
>
>
>
> *From:* Hamdoun,H,Hassan,TUA8 R
> *Sent:* 18 October 2018 10:56
> *To:* 'Justin Tallon' <justin.tallon at softwareradiosystems.com>
> *Subject:* RE: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> Hey Justin,
>
> Thanks for answers.
>
>
>
> The MCS isseus still persist. Apparently I found out the followings:
>
> 1.       Any MCS >7 on data and signalling , causes CRS errors on
> decoding PMCH channel
>
> 2.       It sees data and signalling MCS equal is better, again CRC
> errors starts to appear.
>
> 3.       When I added more subframes for MBMS i.e.e changes Amarisoft eNB
> configurations to subframe allocation e.g. 110000 from 10000, I get a
> significant number of CRC errors. Some investigations, led me to think
> there is something wrong with PMCH.c function especially the decoding on
> PMCH channel on which slot. What is the status of this PMCH.c code, does
> that code assume decoding PMCH on 1 slot only?
>
> 4.       Does CRC error relate to decoding of SIB2. I read somewhere in
> blogs about this for PDSCH channel. Not sure about PMCH?
>
>
>
> Regarding you points below regarding vlc, I’d to fiddle with data in order
> to pass it to VLC for playback due to fact that srsUE tunnels is a unicast
> tunnel. I am facing large packet loss, so answering MCS question and adding
> more subframes for PMCH will help me.
>
>
>
> I am using the srsUE GUI to check PDSCH constellation and despite high SNR
> received(>12 dB avg) constellation varies quite a lot. I am planning to try
> and find a way of plotting constellation of PMCH channel.
>
>
>
>
>
> Thanks . sorry for a lot of questions but it is getting interesting
>
>
>
>
>
> Hassan
>
> *From:* Justin Tallon [mailto:justin.tallon at softwareradiosystems.com
> <justin.tallon at softwareradiosystems.com>]
> *Sent:* 16 October 2018 15:37
> *To:* Hamdoun,H,Hassan,TUA8 R <hassan.hamdoun at bt.com>
> *Subject:* Re: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> Hey Hassan!
>
>
>
>
>
> Just to try address some of your previous questions.
>
>
>
> 1. you should not have to have the data and signalling mcs the same, i
> will look into this, why dont you try MCS 9 or 13 for both as these are
> also valid signalling mcs.
>
> 2. we do not restrict the MCS at all you can set it to any valid value,
> the signalling is limited to 2,7,9,13 and 19 as per the standard.
>
> 3. the TMGI of a broadcast is communicated through the mbms control
> channel MCCH that the UE pulls out if it is instructed to do so by SIB13.
>
> 4. To send a mbms broadcast service to a specific port, enter
> "mbms_service_start 0 4321" in the command line when the UE is running,
> then service 0 will be activated and the content will be put out on port
> 1234. To
>
> 5. To put the traffic coming out of the tun interface into VLC i would do
> the following open vlc -> media -> open network stream , and enter udp://@
> 172.16.0.2:1234 (do this when you have already activated the service by
> using command from answer 4)
>
>
>
> Let me know how it goes and ill try to help work out the problems as they
> arise!
>
>
>
> Sorry for the delay,
>
>
>
> Justin
>
>
>
>
> ____
> Justin Tallon Ph.D.
>
> Software Radio Systems (SRS)
> http://www.softwareradiosystems.com
>
> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>
>
>
>
>
> On Mon, Oct 15, 2018 at 8:02 PM Justin Tallon <
> justin.tallon at softwareradiosystems.com> wrote:
>
> Hey Hassan!
>
>
>
> Are you having trouble attaching to the Amarisoft eNodeB?
>
>
>
> Try this conf file (you will need to set the earfcn to whatever frequency
> you are using)
>
>
>
> send me the stdout and logs of this trying to attach to the amarisoft enb?
>
>
>
>
>
> Regards,
>
> Justin
>
> ____
> Justin Tallon Ph.D.
>
> Software Radio Systems (SRS)
> http://www.softwareradiosystems.com
>
> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>
>
>
>
>
> On Mon, Oct 15, 2018 at 6:45 PM <hassan.hamdoun at bt.com> wrote:
>
> Hey Justin,
>
> I look forward to your comprehensive response
>
>
>
> I am unable to generate logs for you as the PMCH decoding is no longer
> working. The UE keeps getting PRACH error
>
>
>
> Random Antenna Transmission: seq =xx, ra-nti=0x5
>
>
>
> I investigated what is happening at the eNB side I monitor things and I
> notice a UE ID linked to RNTI number, after some time I get a new UE ID
> with associated RNTI number and a MME-UE-ID. This then disappears. So I am
> guessing that the UE get assigned a random RNTI number in conjunction with
> some event and this get erased and then UE end up with a permanent RNTI
> number, right?
>
>
>
> This Random Access error persist and I have to stop srsUE and start again.
> In some cases, the UE responds and I get successful PMCH decoding but
> lately this seem to be very random and I am stuck in PRACH error for so
> long. I don’t know what is going on, nothing has changed
>
>
>
> Also the PMCH data I receive is continuous as Amarisoft eNB is
> transmitting all the time, now I don’t seem to get the actual data( see my
> previous email) as the pcaps don’t show data. So the general issue of
> pumping data from PMCH up the layers remain, given we can fix this annoying
> Random access error.
>
>
>
> Hassan
>
>
>
> *From:* Justin Tallon [mailto:justin.tallon at softwareradiosystems.com]
> *Sent:* 11 October 2018 12:29
> *To:* Hamdoun,H,Hassan,TUA8 R <hassan.hamdoun at bt.com>
> *Subject:* Re: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> Hey Hassan!
>
>
>
> Could you perhaps send me the full UE logs (with all_level = info
> phy_lib_level = none) and i will have a look?
>
>
>
> Also apologies for not responding to your previous email yet! It is on  my
> todo list I just wanted to provide a comprehensive response!
>
> ____
> Justin Tallon Ph.D.
>
> Software Radio Systems (SRS)
> http://www.softwareradiosystems.com
>
> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>
>
>
>
>
> On Thu, Oct 11, 2018 at 1:11 PM <hassan.hamdoun at bt.com> wrote:
>
> Hey Justin,
>
>
>
> I’ve also noticed from the logs that decoding of MCCH and MCH is
> successful but these is some discarding of Rx MRB1 data PDU SN that occurs
> frequently at RLC
>
>
>
>
>
> 17:28:27.527017 [PHY0] [I] [03731] PMCH: l_crb=50, tbs=277, mcs=2, crc=OK,
> snr=23.6 dB, n_iter=1, dec_time=  73 us
>
> 17:28:27.527068 [RLC ] [I] RX MRB1 Rx data PDU SN: 21
>
>              0000: d5 98 88 d0 37 78 17 7c 17 64 5a a3 b1 e7 cf e2
>
>              0010: e8 77 d6 ee e3 50 06 a6 4f ca e2 42 46 44 e9 18
>
> 17:28:27.527101 [RLC ] [I] MRB1 Discarding duplicate SN: 21
>
> 17:28:27.534635 [RRC ] [I] MEAS:  New measurement pci=1, rsrp=-65.9 dBm.
>
> 17:28:27.537275 [PHY0] [I] [03741] PMCH: l_crb=50, tbs=277, mcs=2, crc=OK,
> snr=22.8 dB, n_iter=1, dec_time= 134 us
>
> 17:28:27.537376 [RLC ] [I] RX MRB1 Rx data PDU SN: 22
>
>              0000: f6 0e b0 73 63 35 68 77 d0 f4 26 06 c7 82 24 31
>
>              0010: de 9b 7f 7e ce eb a4 10 20 a5 9f 32 dc 9d f4 17
>
> 17:28:27.537403 [RLC ] [I] MRB1 Discarding duplicate SN: 22
>
> 17:28:27.547139 [PHY0] [I] [03751] PMCH: l_crb=50, tbs=277, mcs=2, crc=OK,
> snr=23.6 dB, n_iter=1, dec_time= 120 us
>
> 17:28:27.547190 [RLC ] [I] RX MRB1 Rx data PDU SN: 23
>
>              0000: d7 b0 ea 00 10 10 40 21 1a 45 85 45 ae a1 5c f2
>
>              0010: 95 f8 ef f3 e7 8d 37 57 53 1c 65 49 2b 52 32 a5
>
> 17:28:27.547230 [RLC ] [I] MRB1 Discarding duplicate SN: 23
>
> 17:28:27.554641 [RRC ] [I] MEAS:  New measurement pci=1, rsrp=-65.8 dBm.
>
> 17:28:27.556981 [PHY0] [I] [03761] PMCH: l_crb=50, tbs=277, mcs=2, crc=OK,
> snr=22.0 dB, n_iter=1, dec_time= 110 us
>
> 17:28:27.557042 [RLC ] [I] RX MRB1 Rx data PDU SN: 24
>
>              0000: f8 0f b0 f5 fb fe 65 71 d7 e7 ef 51 44 bc 5a 4b
>
>              0010: 95 55 15 2e ac 1f 4f 15 45 4c 00 d0 f4 74 d5 ae
>
> 17:28:27.557054 [RLC ] [I] MRB1 Discarding duplicate SN: 24
>
> 17:28:27.567160 [PHY0] [I] [03771] PMCH: l_crb=50, tbs=277, mcs=2, crc=OK,
> snr=23.6 dB, n_iter=1, dec_time= 108 us
>
> 17:28:27.567226 [RLC ] [I] RX MRB1 Rx data PDU SN: 25
>
>              0000: d9 04 d4 05 80 09 d3 80 60 4c 86 42 8b c1 43 65
>
>              0010: fb 1f 48 5c 81 9a 43 3c 21 93 29 84 6f 5c cd 6b
>
> 17:28:27.567258 [RLC ] [I] MRB1 Discarding duplicate SN: 25
>
> 17:28:27.574618 [RRC ] [I] MEAS:  New measurement pci=1, rsrp=-65.8 dBm.
>
> 17:28:27.577015 [PHY0] [I] [03781] PMCH: l_crb=50, tbs=277, mcs=2, crc=OK,
> snr=22.0 dB, n_iter=1, dec_time= 118 us
>
> 17:28:27.577100 [RLC ] [I] RX MRB1 Rx data PDU SN: 26
>
>              0000: da 1d 77 a1 11 56 95 9f e5 97 63 b2 64 71 4c ba
>
>              0010: 89 e9 1d ae 24 f9 35 3a 2e b9 9c fa fa 83 39 c7
>
> 17:28:27.577142 [RLC ] [I] MRB1 Discarding duplicate SN: 26
>
> 17:28:27.587210 [PHY0] [I] [03791] PMCH: l_crb=50, tbs=277, mcs=2, crc=OK,
> snr=23.9 dB, n_iter=1, dec_time=  97 us
>
> 17:28:27.587277 [RLC ] [I] RX MRB1 Rx data PDU SN: 27
>
>              0000: db 19 80 b1 a4 56 e6 44 2c 7a 98 5f 06 31 77 32
>
>              0010: 3f 62 30 31 5b 16 6f 4a 5b 30 d1 49 2e 45 9b ea
>
> 17:28:27.587290 [RLC ] [I] MRB1 Discarding duplicate SN: 27
>
> 17:28:27.594663 [RRC ] [I] MEAS:  New measurement pci=1, rsrp=-65.9 dBm.
>
> 17:28:27.597013 [PHY0] [I] [03801] PMCH: l_crb=50, tbs=277, mcs=2, crc=OK,
> snr=22.0 dB, n_iter=1, dec_time=  71 us
>
> 17:28:27.597060 [RLC ] [I] RX MRB1 Rx data PDU SN: 28
>
>              0000: dc e8 53 23 a9 df aa 5c b5 4b 54 e9 2d 51 a2 89
>
>              0010: 08 0d aa 83 0a b1 11 b0 4c fd eb 13 56 f8 5e bd
>
> 17:28:27.597088 [RLC ] [I] MRB1 Discarding duplicate SN: 28
>
> 17:28:27.607141 [PHY0] [I] [03811] PMCH: l_crb=50, tbs=277, mcs=2, crc=OK,
> snr=22.7 dB, n_iter=1, dec_time=  82 us
>
> 17:28:27.607187 [RLC ] [I] RX MRB1 Rx data PDU SN: 29
>
>              0000: dd bf 8d 31 e7 44 00 e6 08 5c f9 79 f3 f9 0f 66
>
>              0010: b2 43 98 73 c9 0a 18 6e c3 5f 2a 8a e1 99 8a 1d
>
> 17:28:27.607199 [RLC ] [I] MRB1 Discarding duplicate SN: 29
>
> 17:28:27.614672 [RRC ] [I] MEAS:  New measurement pci=1, rsrp=-65.9 dBm.
>
> 17:28:27.617091 [PHY0] [I] [03821] PMCH: l_crb=50, tbs=277, mcs=2, crc=OK,
> snr=22.1 dB, n_iter=1, dec_time= 110 us
>
> 17:28:27.617136 [RLC ] [I] RX MRB1 Rx data PDU SN: 30
>
>              0000: fe 01 f0 a0 11 4c 52 da 5a 1a 04 d4 fe f7 98 cd
>
>              0010: 38 6f 9c 51 d2 44 06 1e af ca 0f 01 61 62 ca f5
>
> 17:28:27.617160 [RLC ] [I] MRB1 Discarding duplicate SN: 30
>
> 17:28:27.627171 [PHY0] [I] [03831] PMCH: l_crb=50, tbs=277, mcs=2, crc=OK,
> snr=23.8 dB, n_iter=1, dec_time=  98 us
>
> 17:28:27.627233 [RLC ] [I] RX MRB1 Rx data PDU SN: 31
>
>              0000: df ab d3 03 77 1d 01 9f 7d bc 73 d5 3d ad 02 7f
>
>              0010: 82 aa 6d d2 81 b0 72 35 e1 f0 4a 10 50 c8 da e0
>
> 17:28:27.627261 [RLC ] [I] MRB1 Discarding duplicate SN: 31
>
> 17:28:27.634701 [RRC ] [I] MEAS:  New measurement pci=1, rsrp=-65.8 dBm.
>
>
>
> ----- THIS PATTERNS KEEPS REPEATING
>
>
>
> My understanding is that RLC keeps segmenting packets into PDUs for MAC
> layer which I think is correct. What I don’t see is wha happends to packets
> after that, I expect them to be passed from RLC to PDCP and then IP? Right?
>
>
>
> How do I trace this ?
>
>
>
> Thanks
>
> Hassan
>
>
>
> *From:* Hamdoun,H,Hassan,TUA8 R
> *Sent:* 08 October 2018 17:39
> *To:* 'Justin Tallon' <justin.tallon at softwareradiosystems.com>
> *Subject:* RE: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> Hey Justin,
>
>
>
> Yes that works. srsUE seems to be sensitive to MCS and doesn’t like
> different MCS for data and signalling . So I’d try to upgrade to data_mcs
> and signalling_mc both to 7.
>
> A question any reason why data_mcs 7?
>
>
>
> The 3GPP spec I found ( Rel15) states that Data_mcs 7 is I_ TBS 7 ( with
> 50 PRBs that is 620 kbps) while data_mcs 2 is I_TBS 2 ( with 50 PRBs that
> is 22.1 kbps). srsUE documentations says it is Rel8/9 compliant, does this
> restrict MCS to 7 . Am not sure what is restriction here? And why I need to
> match the data_mcs and signalling_mc. Signal RF quality can be the blame,
> but not sure if this is the main reason and how to improve it.
>
>
>
>
>
> So now this seem to work fine, what I am trying to do next is to take the
> decoded MBMS data and present it to VLC on the UE for streaming video
> broadcasted by the eNB. For this I’d need to instruct the srsUE to located
> the broadcast on MBMS service 1 and play it. I am thinkg I’d need:
>
> 1.       A way to tell the srsUE the TMGI of the broadcast
>
> 2.       A way to hook to the MBMS broadcast from eNB on specific IP:port
>
> 3.       Given that I am using VLC to stream the video continuously, I
> can install VLC on srsUE PC, but how do I take output from srsUE and feed
> it to VLC- I need to be able to access the data coming from UE through the
> tunnel(created when setting up the UE)
>
>
>
> Guidance on how to achieve this is much appreciated?
>
>
>
> I am trying to look at the source code for the srsUE but cann’t seem to
> get my head around how the data decoded by PMCH on MBMS is used elsewhere
> in the code( esp at higher layers)
>
>
>
> Thanks
>
> Hassan
>
>
>
>
>
> *From:* Justin Tallon [mailto:justin.tallon at softwareradiosystems.com
> <justin.tallon at softwareradiosystems.com>]
> *Sent:* 04 October 2018 11:28
> *To:* Hamdoun,H,Hassan,TUA8 R <hassan.hamdoun at bt.com>
> *Subject:* Re: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> Hey Hassan,
>
>
>
> As an experiment, could you change data_mcs to 2 and also could you set
> phy_lib_level = none
>
> ____
> Justin Tallon Ph.D.
>
> Software Radio Systems (SRS)
> http://www.softwareradiosystems.com
>
> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>
>
>
>
>
> On Thu, Oct 4, 2018 at 12:10 PM <hassan.hamdoun at bt.com> wrote:
>
>
>
> Set in config files are   signalling_mcs: is 2 while dat MC is 7  below:
>
>
>
>   area_info_list: [
>
>     {
>
>       area_id: 1, /* 0-255 */
>
>       non_mbsfn_region_length: 2, /* 1-2. Number of CCH symbols */
>
>       mcch_config: {
>
>         mcch_repetition_period: 64, /* 32-256 frames (10 ms unit) */
>
>         mcch_offset: 0, /* 0-10 */
>
>         mcch_modification_period: 512, /* 512,1024 */
>
>         mcch_sf_alloc: '100000',
>
>         signalling_mcs: 2, /* 2, 7, 13, 19 */
>
>       },
>
>
>
> pmch_info_list: [
>
>         {
>
>           pmch_config: {
>
>             sf_alloc_count: 64, /* number of subframes per common alloc
> period */
>
>             data_mcs: 7, /* 0-28 */
>
>             mch_scheduling_period: 64, /* in frames, 8-1024, must be >=
> common */
>
>           },
>
>
>
> Hassan
>
> *From:* Justin Tallon [mailto:justin.tallon at softwareradiosystems.com]
> *Sent:* 04 October 2018 11:00
> *To:* Hamdoun,H,Hassan,TUA8 R <hassan.hamdoun at bt.com>
> *Subject:* Re: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> Looking at the logs it appears the UE is only pulling out the MCCH and
> then getting a crc fail on the MCCH.
>
>
>
> the MCS appears to be 7 but in those amarisoft configs we set the
> signalling mcs to 2 so it should be 2?
>
>
>
> did you change that to 7?
>
>
>
> 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, Oct 4, 2018 at 11:38 AM Justin Tallon <
> justin.tallon at softwareradiosystems.com> wrote:
>
> Hey Hassan!
>
> I tethered my phone and was then able to download, something about the
> firewall on the wifi i think.
>
>
>
> Let me have a look and get back to you!
>
>
>
> Thanks,
>
> Justin
>
>
>
> On Thu, 4 Oct 2018, 10:18 , <hassan.hamdoun at bt.com> wrote:
>
> The UE log file is too big to be attached. I tried zipping to various
> sizes but stil large.
>
> Why can’t you open the dropbox link?
>
>
>
> Hassan
>
>
>
> *From:* Hamdoun,H,Hassan,TUA8 R
> *Sent:* 04 October 2018 10:14
> *To:* 'Justin Tallon' <justin.tallon at softwareradiosystems.com>
> *Subject:* RE: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
>
>
> Here is the UE config file
>
>
>
> Hassan
>
> *From:* Hamdoun,H,Hassan,TUA8 R
> *Sent:* 03 October 2018 15:13
> *To:* 'Justin Tallon' <justin.tallon at softwareradiosystems.com>
> *Subject:* RE: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> The password is srsUE
>
>
>
> Hassan
>
>
>
> *From:* Hamdoun,H,Hassan,TUA8 R
> *Sent:* 03 October 2018 14:16
> *To:* Justin Tallon <justin.tallon at softwareradiosystems.com>
> *Subject:* Re: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> Apologies Justin. Here is the dropbox link again. Attached a 7z file,
> password is “srsUE”
>
> https://www.dropbox.com/sh/u0khtnoo6ktjc63/AAAXdUmQ0r8OUnXd86pZP5kka?dl=0
>
> [image:
> https://www.dropbox.com/static/images/spectrum-icons/generated/content/content-folder_dropbox-large.png]
> <https://www.dropbox.com/sh/u0khtnoo6ktjc63/AAAXdUmQ0r8OUnXd86pZP5kka?dl=0>
>
> srsUE
> <https://www.dropbox.com/sh/u0khtnoo6ktjc63/AAAXdUmQ0r8OUnXd86pZP5kka?dl=0>
>
> www.dropbox.com
>
> Shared with Dropbox
>
> Thanks
>
> Hassan
> ------------------------------
>
> *From:* Justin Tallon <justin.tallon at softwareradiosystems.com>
> *Sent:* 03 October 2018 13:54
> *To:* Hamdoun,H,Hassan,TUA8 R
> *Subject:* Re: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> Hey Hassan,
>
>
>
> that dropbox link does not work for me can you attach the files to an
> email?
>
>
>
> Thanks,
>
> Justin
>
> ____
> Justin Tallon Ph.D.
>
> Software Radio Systems (SRS)
> http://www.softwareradiosystems.com
>
> SRS | Software Radio Systems <http://www.softwareradiosystems.com/>
>
> www.softwareradiosystems.com
>
> Wireless machine to machine waveforms. Low-cost, low-energy protocol
> designs. Network integration and bridging solutions.
>
>
>
> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>
>
>
>
>
> On Wed, Oct 3, 2018 at 2:48 PM <hassan.hamdoun at bt.com> wrote:
>
> Hi Justin,
>
> Files are uploaded to folder "2018-10-03 Logs" in
> https://www.dropbox.com/sh/u0khtnoo6ktjc63/AAAXdUmQ0r8OUnXd86pZP5kka?dl=0
>
> [image:
> https://www.dropbox.com/static/images/spectrum-icons/generated/content/content-folder_dropbox-large.png]
> <https://www.dropbox.com/sh/u0khtnoo6ktjc63/AAAXdUmQ0r8OUnXd86pZP5kka?dl=0>
>
> srsUE
> <https://www.dropbox.com/sh/u0khtnoo6ktjc63/AAAXdUmQ0r8OUnXd86pZP5kka?dl=0>
>
> www.dropbox.com
>
> Shared with Dropbox
>
>
>
> Thanks
>
> Hassan
> ------------------------------
>
> *From:* Justin Tallon <justin.tallon at softwareradiosystems.com>
> *Sent:* 02 October 2018 15:04:11
> *To:* Hamdoun,H,Hassan,TUA8 R
> *Subject:* Re: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> Hey Hassan!
>
> Could you attach the ue.log and the ue.conf?
>
>
>
> 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, Oct 2, 2018 at 3:48 PM <hassan.hamdoun at bt.com> wrote:
>
> HI Justin,
>
>
>
> Applied your configurations and changed the
>
> average_subframe_enabled = false
>
> The error I was receiving disappeared but while the UE is attached to
> Amarisoft eNB and works over uncast fine. While the MBMS service is
> broadcasted  with  a 1Mbps video broadcasted on PMCH, the srsUE doesn’t
> seem to be connected to multicast service and I don’t see anything in the
> logs to indicate connection to PMCH.
>
>
>
> Can you advice how best to trace what is going on? How to check what MBMS
> services are received and decoded by UE?
>
>
>
> Thanks
>
>
>
> Kind Regards
>
> Hassan
>
> *From:* Hamdoun,H,Hassan,TUA8 R
> *Sent:* 26 September 2018 13:45
> *To:* 'Justin Tallon' <justin.tallon at softwareradiosystems.com>
> *Subject:* RE: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> Thank you Justin,
>
>
>
> Yes still having same issue. Will try configs and let you know
>
>
>
> Kind Regards
>
> Hassan
>
>
>
> *From:* Justin Tallon [mailto:justin.tallon at softwareradiosystems.com
> <justin.tallon at softwareradiosystems.com>]
> *Sent:* 26 September 2018 09:38
> *To:* Hamdoun,H,Hassan,TUA8 R <hassan.hamdoun at bt.com>
> *Subject:* Re: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> Hey Hassan!
>
>
>
> Sorry for the delay on this, if you are still having trouble could you try
> these configs for both amarisoft and the srsue?
>
>
>
> I hope this helps!
>
> ____
> Justin Tallon Ph.D.
>
> Software Radio Systems (SRS)
> http://www.softwareradiosystems.com
>
> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>
>
>
>
>
> On Fri, Sep 21, 2018 at 11:42 AM <hassan.hamdoun at bt.com> wrote:
>
> Hi Justin,
>
> Thank you.
>
>
>
> Yes I am  using the default Amarisoft configs , the only differences are :
>
> mme.conf. –added another sim info but it is not used at the moment
>
> enb.cfg- only [dl_earfcn] changed to 3025(band 7)
>
> mbmsgw.cfg  - [non_mbsfn_region_length] to  2 ( it was 1)
>
>
>
>
>
> Kind Regards
>
> Hassan
>
>
>
> *From:* Justin Tallon [mailto:justin.tallon at softwareradiosystems.com]
> *Sent:* 21 September 2018 10:31
> *To:* Hamdoun,H,Hassan,TUA8 R <hassan.hamdoun at bt.com>
> *Subject:* Re: [srslte-users] srsUE error upon decoding the eMBMS signal
> from Amarisoft eNB
>
>
>
> I will try reproduce what you are seeing here!
>
>
>
> in the meantime you could try setting
>
> average_subframe_enabled = false
>
>
>
> in the ue.conf
>
>
>
> It can sometimes cause problems!
>
>
>
> Thanks,
>
> Justin
>
>
> ____
> Justin Tallon Ph.D.
>
> Software Radio Systems (SRS)
> http://www.softwareradiosystems.com
>
> +353-86-067-0753 | justin.tallon at softwareradiosystems.com
>
>
>
> On Fri, Sep 21, 2018 at 11:18 AM, Justin Tallon <
> justin.tallon at softwareradiosystems.com> wrote:
>
> Hey Hassan!
>
>
>
> So I can assume you are using the default Amarisoft configs?
>
>
>
>
>
>
> ____
> Justin Tallon Ph.D.
>
> Software Radio Systems (SRS)
> http://www.softwareradiosystems.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20181031/91680913/attachment.htm>

More information about the srsran-users mailing list