Bug #2400
open
transmit SI13 on PACCH during long TBFs
Added by laforge almost 7 years ago.
Updated almost 4 years ago.
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
- Description updated (diff)
- Description updated (diff)
- 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?
- 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.
- 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...
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.
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
- Status changed from Feedback to New
- 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.
- 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?
- Priority changed from Normal to High
- 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.
- Status changed from In Progress to Stalled
- Assignee changed from msuraev to 4368
- Assignee changed from 4368 to lynxis
- Related to Bug #3284: GPRS cell re-selection appears sticky in packet transfer / packet idle mode added
- Assignee changed from lynxis to msuraev
- Assignee changed from msuraev to lynxis
lynxis, is this something that osmith could take over from you?
- 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.
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.
- Related to Bug #3472: GPRS connection is in a state where pdp-context is active, but data TX cannot initiate from Network side. added
- Assignee changed from osmith to fixeria
- Related to Bug #4506: MediaTek MT6*** will not initiate Packet Access added
Also available in: Atom
PDF
