Project

General

Profile

Actions

Bug #2400

open

transmit SI13 on PACCH during long TBFs

Added by laforge over 6 years ago. Updated almost 4 years ago.

Status:
Stalled
Priority:
High
Assignee:
Target version:
-
Start date:
07/25/2017
Due date:
% Done:

20%

Spec Reference:

Description

5.5.1.3.3
SI13 reception failure If the mobile station has not received the SI13 or the PSI13 message within the 
last 60 s, a SI13 reception failure has occurred. An SI13 reception failure shall result in a cell reselection.

5.5.2.1.3 System information on PACCH (and other logical channels)

The network may broadcast PSI and SI messages on PACCH. In particular, if a mobile station is busy in packet 
transfer mode or MAC-Shared state and thus unable to receive the relevant blocks on the broadcast channels 
(PBCCH or BCCH) for a period longer than 15 seconds, the following requirements apply: [...]
- If PBCCH is not present in the cell, the network may broadcast the PSI13 message on PACCH such that the 
mobile station may receive the PSI13 messages at least every 15 s.

So basically this means that on a TBF that has a duration longer than 60s since the last SI13 was received on BCCH, a spec-compliant MS shall start cell re-selection, which will of course interrupt the transmission. We hence must periodically schedule SI13 in PACCH.


Files


Checklist

  • periodically schedule SI13 for busy TBF
  • send SI13: BTS
  • recv SI13: PCU
  • check that SI13 is removed from PCU after GPRS being disabled at BSC

Related issues

Related to OsmoPCU - Bug #3284: GPRS cell re-selection appears sticky in packet transfer / packet idle modeNew05/23/2018

Actions
Related to OsmoPCU - Bug #3472: GPRS connection is in a state where pdp-context is active, but data TX cannot initiate from Network side.Closedkeith08/18/2018

Actions
Related to OsmoSGSN - Bug #4506: MediaTek MT6*** will not initiate Packet AccessClosedkeith04/20/2020

Actions
Actions #1

Updated by laforge over 6 years ago

  • Description updated (diff)
Actions #2

Updated by laforge over 6 years ago

  • Description updated (diff)
Actions #3

Updated by mqng2 over 6 years ago

  • Status changed from New to Feedback

I have seen an issue with the Lenovo A916 smartphone.

If the phone does not use Internet right after PDP context ACT, the phone will be unable to use the Internet.

It is also applied in case the phone waits for an amount of time after a Web page loaded 100%.

Do you think the problem with this phone is related to this issue?

Actions #4

Updated by laforge over 6 years ago

  • Status changed from Feedback to New

mqng2 wrote:

Do you think the problem with this phone is related to this issue?

No, I don't think so, sorry.

Actions #5

Updated by laforge over 6 years ago

  • Assignee set to msuraev
Actions #6

Updated by mqng2 over 6 years ago

  • Status changed from New to Feedback

laforge wrote:

mqng2 wrote:

Do you think the problem with this phone is related to this issue?

No, I don't think so, sorry.

Some input:

I wrote a small script to periodically ping the Lenovo A916 phone every 30 seconds. The phone does not go to state of unable to use the data service.

From this experiment, it looks like there is a timer expired somewhere that forces the phone into unable state...

Actions #7

Updated by laforge over 6 years ago

Hi Minh,

On Fri, Aug 18, 2017 at 07:03:35PM +0000, mqng2 [REDMINE] wrote:

I wrote a small script to periodically ping the Lenovo A916 phone every 30 seconds. The phone does not go to state of unable to use the data service.

From this experiment, it looks like there is a timer expired somewhere that forces the phone into unable state...

I'm not doubting that you are experiencing a problem. But it is clearly
unrelated to this ticket, as this ticket is about TBFs that are
established for longer than 15 seconds, i.e. when there is continuous
data transfer so the TBF is never closed. If you ping every 30s, then
for sure the TBF is closed after every ping and thus it is unrelated.

Feel free to file a different issue, preferrably with protocol traces of
Gb and Um (GSMTAP) as well as the detailed log output of osmo-pcu and
indicating the specific version of the PCU using which the problem was
observed.

Actions #8

Updated by mqng2 over 6 years ago

laforge wrote:

Hi Minh,

On Fri, Aug 18, 2017 at 07:03:35PM +0000, mqng2 [REDMINE] wrote:

I wrote a small script to periodically ping the Lenovo A916 phone every 30 seconds. The phone does not go to state of unable to use the data service.

From this experiment, it looks like there is a timer expired somewhere that forces the phone into unable state...

I'm not doubting that you are experiencing a problem. But it is clearly
unrelated to this ticket, as this ticket is about TBFs that are
established for longer than 15 seconds, i.e. when there is continuous
data transfer so the TBF is never closed. If you ping every 30s, then
for sure the TBF is closed after every ping and thus it is unrelated.

Feel free to file a different issue, preferrably with protocol traces of
Gb and Um (GSMTAP) as well as the detailed log output of osmo-pcu and
indicating the specific version of the PCU using which the problem was
observed.

A new ticket for this issue has created here https://osmocom.org/issues/2455

Actions #9

Updated by msuraev over 6 years ago

  • Status changed from Feedback to New
Actions #10

Updated by msuraev over 6 years ago

  • Status changed from New to In Progress

Note to self: spec references 3GPP TS 44.060 §5.5.2.1.3, §11.2.25 and 3GPP TS 44.018 §10.5.2.37b.

There's already PCU_IF_SAPI_BCCH and BTS-side code which updates SI13 with the data received from PCU (is this even spec compliant?) but no PCU-side code.

The difference between SI13 and PSI13 is 2-bit PAGE_MODE field in the beginning of the PSI13 message (which is ignored by MS on PACCH) - the SI13 has H (CSN1) value so it could be copied as is.

Actions #11

Updated by msuraev over 6 years ago

  • Checklist item propagate SI13 from BTS to PCU added
  • Checklist item periodically schedule SI13 for busy TBF added
  • % Done changed from 0 to 20
Actions #12

Updated by msuraev over 6 years ago

  • Status changed from In Progress to Feedback

Does "mobile station is busy in packet transfer mode" in the spec refers to UL, DL or both?

Actions #13

Updated by msuraev over 6 years ago

  • Checklist item deleted (propagate SI13 from BTS to PCU)
  • Checklist item send SI13: BTS added
  • Checklist item recv SI13: PCU added
Actions #14

Updated by msuraev over 6 years ago

  • Checklist item check that SI13 is removed from PCU after GPRS being disabled at BSC added
  • Checklist item recv SI13: PCU set to Done
Actions #15

Updated by laforge over 6 years ago

  • Priority changed from Normal to High
Actions #16

Updated by laforge over 6 years ago

  • Status changed from Feedback to In Progress

If it's not explicitly specified, it of course applies to both uplink or downlink transfer mode. It's quite clear: Is it busy in packet transfer, or is it idle? Please avoid re-assigning tickets to "feedback" for bogus questions. Thanks.

Actions #17

Updated by msuraev over 6 years ago

  • Status changed from In Progress to Stalled
Actions #18

Updated by laforge about 6 years ago

  • Assignee changed from msuraev to 4368
Actions #19

Updated by laforge almost 6 years ago

  • Assignee changed from 4368 to lynxis
Actions #20

Updated by laforge almost 6 years ago

  • Related to Bug #3284: GPRS cell re-selection appears sticky in packet transfer / packet idle mode added
Actions #21

Updated by laforge over 5 years ago

Actions #22

Updated by laforge over 5 years ago

  • Assignee changed from lynxis to msuraev
Actions #23

Updated by laforge almost 5 years ago

  • Assignee changed from msuraev to lynxis
Actions #24

Updated by laforge over 4 years ago

lynxis, is this something that osmith could take over from you?

Actions #25

Updated by lynxis over 4 years ago

  • Assignee changed from lynxis to osmith

Sure. Btw. I'ven't seen this problematic in my test cases. But for sure, it only covers one particular firmware and phone.

Actions #26

Updated by fixeria over 4 years ago

5.5.2.1.3 System information on PACCH (and other logical channels)

I think I have seen something in my RLC/MAC captures from a commercial network, please see the attachment.

Unfortunately, Wireshark is not able to decode those PACKET_SERVING_CELL_DATA messages, but I already have a draft change implementing that. The payload of a PACKET_SERVING_CELL_DATA message consists of segments:

  • one such message may contain one or more segments;
  • every segment has a small header with PD (Protocol Discriminator) and the length field;
  • a segment may be continued in the next message (if it doesn't fit):
    • special length value '11111'B indicates that;
  • PACKET_SERVING_CELL_DATA has a fixed length of 19 octets,
    • after the last segment there can be a terminator (another segment with length 0) and optional '2B'O padding.
Actions #28

Updated by fixeria about 4 years ago

  • Related to Bug #3472: GPRS connection is in a state where pdp-context is active, but data TX cannot initiate from Network side. added
Actions #29

Updated by laforge almost 4 years ago

  • Assignee changed from osmith to fixeria
Actions #30

Updated by keith over 3 years ago

  • Related to Bug #4506: MediaTek MT6*** will not initiate Packet Access added
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)