Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092016-11-09T12:27:17ZOpen Source Mobile Communications
Redmine OsmoPCU - Bug #1838 (Stalled): Nokia E52 doest reply to PUAN message properlyhttps://osmocom.org/issues/18382016-11-09T12:27:17Zarvind.sirsikar
<p>When we indicate MS that we have Nack in receiving window(in PUAN). Nokia E52 MS doesn’t honor that and keeps sending the new RLC blocks even when it crosses its transmit window in UL. causing the reception of RLC blocks outside RLC window.</p>
<p>below is PCU log snippet for one such example:</p>
<p>encoding.cpp:676 - EGPRS URBB, len = 11, SSN = 671, ESN_CRBB = 670, SNS = 2048, WS = 64, V(Q) = 670, V(R) = 682, BOW, EOW</p>
<p>message = 40 24 01 1f 3e 90 00 92 f0 8d 35 3e ff c3 2b 2b 2b 2b 2b 2b 2b 2b 2b</p>
<p>Below is the decoded message.</p>
<pre><code>EGPRS_AckNack<br /> 1... .... = ACKNACK: (Union)<br /> Desc<br /> .000 1101 0... .... = ACKNACK Dissector length: 26<br /> Desc<br /> .0.. .... = FINAL_ACK_INDICATION: False<br /> ..1. .... = BEGINNING_OF_WINDOW: 1<br /> ...1 .... = END_OF_WINDOW: 1<br /> .... 0101 0011 111. = STARTING_SEQUENCE_NUMBER: 671<br /> .... ...0 = CRBB Exist: 0<br /> 1111 1111 110. .... = URBB_BITMAP: 2046</code></pre>
<p>Other MS like LG F70 and Lenovo K4 note behaves properly for this kind of PUAN with nacked bits present in it.<br />further investigation needs to be done</p> OsmoPCU - Bug #1834 (Closed): Extended (11-bit) RACH is not properly handledhttps://osmocom.org/issues/18342016-10-25T08:52:11Zarvind.sirsikar
<p>Currently 11 bit Rach is tested with NuRAN 1.0.<br />But with NURAN LC1.5 and osmo-trx doesn't support the 11 bit RACH.</p> OsmoPCU - Bug #1833 (Resolved): UPLINK MCS gets reduced from MCS9->MCS6 when good radio condition...https://osmocom.org/issues/18332016-10-25T08:49:54Zarvind.sirsikar
<p>During EGPRS UL testing with osmo-trx setup, it is seen that MCS gets reduced very fast even when radio condition is good. Same issue is present for GPRS testing as well.</p>
<p>This condition exists only with osmo-trx setup.</p> OsmoPCU - Bug #1831 (Stalled): No handling for padding octets(LI 127) for EGPRS. row 3rd of Table...https://osmocom.org/issues/18312016-10-21T08:00:10Zarvind.sirsikar
<p>While testing DL TBF, First 2(BSN 0 and BSN1) RLC blocks were prepared properly. But while filling the 3rd RLC block(BSN 2), instead of LI 127 we see LI present as 47(decimal). Please refer below logs. Brief information is below</p>
<p>MCS > 6<br />Number of LLC present in DL TBF > 2 with size 74 each</p>
<p><abbr title="TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS">TBF</abbr> append len(74)<br /><abbr title="TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS">TBF</abbr> append len(74)<br /><abbr title="TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS">TBF</abbr> downlink (V(A)==0 .. V(S)==0)<br />- Sending new block at BSN 0, CS=MCS-6<br />- Dequeue next LLC for <abbr title="TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS">TBF</abbr> (len=74)<br />-- Chunk with length 74 would exactly fit into space (74): just copy it, and we are done. The next block will have to start with an empty chunk<br />data block (BSN 0, MCS-6): 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a <br />- need_padding 0 spb_status 0 spb 0(BSN1 0 BSN2 <del>1)<br /></del> Copying data unit 0 (BSN 0)<br />msg block (BSN 0, MCS-6): 07 00 00 50 80 c0 00 41 81 c1 01 42 82 c2 02 43 83 c3 03 44 84 c4 04 45 85 c5 05 46 86 c6 06 47 87 c7 07 48 88 c8 08 49 89 c9 09 4a 8a ca 0a 4b 8b cb 0b 4c 8c cc 0c 4d 8d cd 0d 4e 8e ce 0e 4f 8f cf 0f 50 90 d0 10 51 91 d1 11 52 92 12 <br /><abbr title="TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS">TBF</abbr> downlink (V(A)==0 .. V(S)==1)<br />- Sending new block at BSN 1, CS=MCS-6<br />-- Chunk with length 0 is less than remaining space (74): add length header to to delimit LLC frame<br />Complete DL frame for <abbr title="TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS">TBF</abbr>len=74<br />- Dequeue next LLC for <abbr title="TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS">TBF</abbr> (len=74)<br />-- Chunk with length 74 larger than space (73) left in block: copy only remaining space, and we are done<br />data block (BSN 1, MCS-6): 01 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 <br />- need_padding 0 spb_status 0 spb 0(BSN1 1 BSN2 <del>1)<br /></del> Copying data unit 0 (BSN 1)<br />msg block (BSN 1, MCS-6): 07 40 00 40 40 80 c0 00 41 81 c1 01 42 82 c2 02 43 83 c3 03 44 84 c4 04 45 85 c5 05 46 86 c6 06 47 87 c7 07 48 88 c8 08 49 89 c9 09 4a 8a ca 0a 4b 8b cb 0b 4c 8c cc 0c 4d 8d cd 0d 4e 8e ce 0e 4f 8f cf 0f 50 90 d0 10 51 91 d1 11 52 12 <br /><abbr title="TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS">TBF</abbr> downlink (V(A)==0 .. V(S)==2)<br />- Sending new block at BSN 2, CS=MCS-6<br />-- Chunk with length 1 is less than remaining space (74): add length header to to delimit LLC frame<br />Complete DL frame for <abbr title="TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS">TBF</abbr>len=74<br />-- Empty chunk, added LLC dummy command of size 71, drained_since=0<br />-- Chunk with length 71 is less than remaining space (72): add length header to to delimit LLC frame<br />-- No space left, so we are done.<br />Complete DL frame for <abbr title="TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS">TBF</abbr>len=71<br />data block (BSN 2, MCS-6): 02 8f 4a 43 c0 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <br />- need_padding 0 spb_status 0 spb 0(BSN1 2 BSN2 <del>1)<br /></del> Copying data unit 0 (BSN 2)<br />- Scheduling Ack/Nack polling, because is was requested explicitly (e.g. first final block sent).<br /><abbr title="TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS">TBF</abbr>: Scheduling polling at FN 21 TS 4<br />Polling scheduled in this TS 4<br /><abbr title="TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS">TBF</abbr> Scheduled Ack/Nack polling on FN=21, TS=4<br />msg block (BSN 2, MCS-6): 0f 80 00 80 c0 a3 d2 10 70 c0 ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca ca 0a</p> OsmoPCU - Bug #1811 (Closed): [EGPRS] PCU sends packet of size > 1510https://osmocom.org/issues/18112016-09-02T10:36:41Zarvind.sirsikar
<p>During intensive UL tests. We see less throughout at the receiver.</p>
<p>As per initial analysis, improper handling of row number 4 of Table 10.4.14a.1 in 44.060(Related to LI handling). Which causes the incorrect LLC pdu and dropped at SGSN.</p> OsmoPCU - Bug #1808 (Closed): EGPRS: No recalculation of window size in gprs_rlcmac_tbf::updatehttps://osmocom.org/issues/18082016-08-30T09:31:50Zarvind.sirsikar
<p>When DL data is triggered without MS/tbf context at PCU, It allocates single TS with X(In our case it is 64)Window size. When PCU recalculates the Number of DL Time Slots to 4. It keeps old calculated Window size X(in our case 64) itself. Causing the poor DL throughput.</p> OsmoPCU - Bug #1807 (Closed): PCU dosent come up when logging is enabled and written to osmo-pcu....https://osmocom.org/issues/18072016-08-30T06:41:03Zarvind.sirsikar
<p>Needs analysis.</p> OsmoPCU - Bug #1806 (Closed): GPRS: Frequent MS stalled in intensive UL testshttps://osmocom.org/issues/18062016-08-25T10:03:17Zarvind.sirsikar
<p>UL window in PCU gets stalled and the call gets disturbed when intensive test is done over UL. Whether the issue is seen in EGPRS also is<br />not know yet.</p> OsmoPCU - Bug #1805 (Closed): PCU: CSN1 doesnt decode EPDAN correctly for EPDAN without ACKNACK D...https://osmocom.org/issues/18052016-08-25T03:54:43Zarvind.sirsikar
<p>EX:</p>
<p>Below is the hex stream collected over the air<br />"40 20 b ff d1 61 0 3e e 51 9f ff ff fb 80 0 0 0 0 0 0 0 0"</p>
<p>last byte of URBB is decoded as 0xea( which is incorrect) intead of ox00.</p> OsmoPCU - Bug #1793 (Closed): EGPRS PCU: wrong encoding of EGPRS PUAN message https://osmocom.org/issues/17932016-08-09T11:04:00Zarvind.sirsikar
<p>Hi All,</p>
<p>static void write_packet_ack_nack_desc_egprs function is written incomplete causing wrong encoding of PUAN. currently this function is written assuming there is no gap between VR and <abbr title="I guess or manual error while coding">VQ</abbr>.</p>
<p>urbb_len variable is always calculated to be 0( except some corner cases)causing incomplete information in PUAN. The issue is severe when tested with bad radio condition causing MS stalled in UL and there by call instability.</p>
<p>Thanks,<br />Aravind Sirsikar</p> OsmoPCU - Bug #1792 (Rejected): 2 MS tests: Issue with TS allocation for DL in PCUhttps://osmocom.org/issues/17922016-08-09T10:54:07Zarvind.sirsikar
<p>Hi All,</p>
<p>When 4 TS is configured for DL and testing 2 MSs it was found that 1st MS gets 4 TS where as next MS gets 3 TS. causing issue with DL traffic fairness between MSs.</p>
<p>issue is traced to "static int find_multi_slots" function which considers both UL/DL capacity for TS calculation causing 2 TS allocation for UL and 3 for DL.</p>
<p>as of now</p>
<p>if (capacity <= max_capacity) condition in same function is modified to</p>
<p>if (rx_window < max_dl_slots) to concentrate only on DL.</p>
<p>Thanks,<br />Aravind Sirsikar</p> OsmoPCU - Bug #1791 (Closed): Issue with padding case in DL/ULhttps://osmocom.org/issues/17912016-08-09T10:46:41Zarvind.sirsikar
<p>It is seen when MCS8->(MCS6,MCS3) re transmission is triggered from MS/PCU there is an issue with the data traffic. The same issue is discussed with NuRAN team and they have provided fix in L1 firmware. Fix will be provided in next release.</p> OsmoPCU - Bug #1790 (Rejected): Issue with Long Run 2 - Issue with Periodic routing area update r...https://osmocom.org/issues/17902016-08-09T10:40:53Zarvind.sirsikar
<p>Hi All,</p>
<p>This issue is seen with continuous traffic at PCU in DL. After t3312 expires MS will try Periodic routing area procedure(GMM RA UPDATE REQUEST) and SGSN will reply back with "ROUTING AREA UPDATE ACCEPT" but it is not received by <abbr title="May be because there is enough data in PCU for DL and this signalling message is not prioritized">MS</abbr>. resulting in re transmission of "ROUTING AREA UPDATE ACCEPT" and finally trying with RACH and PCU gets print like</p>
<p>bts.cpp:1226 Got RACH from TLLI=0xda425459 while <abbr title="TFI=0 TLLI=0xda425459 DIR=DL STATE=RELEASING EGPRS">TBF</abbr> still exists. Release pending DL TBF=0</p>
<p>causing break in DL traffic(with TCP traffic the issue is severe. causing disconnection of TCP traffic). This issue is show stopper.</p>
<p>Currently t3312 is set with high value in osmo-sgsn.cfg to avoid this condition.</p>
<p>Thanks,<br />Aravind Sirsikar</p> OsmoPCU - Bug #1789 (Closed): Issue with Long Run 1 - incorrect handling of EGPRS Ack/Nackhttps://osmocom.org/issues/17892016-08-09T10:32:46Zarvind.sirsikar
<p>There are two major issues found when we recieve EGPRS Ack/Nack without "ACKNACK Dissector length" field in it.</p>
<p>1) CSN1 decoder doesn't decode the values properly.<br />2) gprs_rlcmac_dl_tbf::update_window function is not written according to 9.1.8.2.4 of 44.060.</p>
<p>Simulated Example(hex dump is captured in real OTA testing):</p>
<p><abbr title="1176">VA</abbr> <abbr title="1288">VS</abbr>.<br />EPDAN received is "40 20 b ff d1 61 0 3e e 51 9f ff ff fb 80 0 0 0 0 0 0 0 0"</p>
<p>causes wrong decoding at <abbr title="Not displayed below">CSN1</abbr>along with error print in PCU as</p>
<p><sup>[[0;m^M</sup>[[0;33m<0002> tbf_dl.cpp:388 - ack range is out of V(A) = 1176 ..V(S) = 1288 range <abbr title="TFI=0 TLLI=0xd1f7028f DIR=DL STATE=FLOW EGPRS">TBF</abbr> Free TBF! num_blocks = 113 dist = 2047 behind_last_bsn = 1289 first_bsn = 1176</p>
<p>Refer issue 2 above: When EPDAN is reported with out of window the status of bsns out of the window needs to be ignored. But in current implementation of gprs_rlcmac_dl_tbf::update_window it is not honored and DL TBF is getting freed causing instability in DL traffic.</p> OsmoPCU - Bug #1759 (Stalled): Wrong calculation of DL window size for DL assignmenthttps://osmocom.org/issues/17592016-06-28T10:27:21Zarvind.sirsikar
<p>Hi,</p>
<p>When we create DOWNLINK TBF without existing UPLINK TBF i.e DL assignment on PCH case, The calculation of window size is found to be incorrect.</p>
<p>Description:<br /> 4 time slots is configured for DL and osmo-pcu.cfg is configured as window-size 64 104.</p>
<pre><code>When we try to do IPERF in DL direction, PCU allocates window-size as 160 but configures 4 time slots<br /> as seen by PCU VTY. Below is the result of VTY output.</code></pre>
<pre><code>DL TBFs<br /> TBF: TFI=0 TLLI=0xf73d2ece (valid) DIR=DL IMSI=901555000001280<br /> created=1095 state=0000000a 1st_TS=4 1st_cTS=6 ctrl_TS=6 MS_CLASS=0/1<br /> TS_alloc=4 5 6! 7 CS=MCS-9 WS=160 V(A)=12 V(S)=12 nBSN=138</code></pre>
<pre><code>But we see proper calculation of window-size when DL assignement is done on PACCH. as seen by VTY interface below</code></pre>
<pre><code>DL TBFs<br /> TBF: TFI=0 TLLI=0xf73d2ece (valid) DIR=DL IMSI=901555000001280<br /> created=1095 state=0000000a 1st_TS=4 1st_cTS=6 ctrl_TS=6 MS_CLASS=0/1<br /> TS_alloc=4 5 6! 7 CS=MCS-9 WS=480 V(A)=138 V(S)=139 nBSN=138</code></pre>
<p>Thanks,<br />Aravind Sirsikar</p>