Project

General

Profile

Bug #2400

transmit SI13 on PACCH during long TBFs

Added by laforge 6 months ago. Updated about 1 month 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.

History

#1 Updated by laforge 6 months ago

  • Description updated (diff)

#2 Updated by laforge 6 months ago

  • Description updated (diff)

#3 Updated by mqng2 5 months 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?

#4 Updated by laforge 5 months 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.

#5 Updated by laforge 5 months ago

  • Assignee set to msuraev

#6 Updated by mqng2 5 months 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...

#7 Updated by laforge 5 months 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.

#8 Updated by mqng2 5 months 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

#9 Updated by msuraev 5 months ago

  • Status changed from Feedback to New

#10 Updated by msuraev 5 months 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.

#11 Updated by msuraev 5 months 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

#12 Updated by msuraev 5 months 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?

#13 Updated by msuraev 5 months ago

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

#14 Updated by msuraev 5 months 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

#15 Updated by laforge 3 months ago

  • Priority changed from Normal to High

#16 Updated by laforge about 2 months 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.

#17 Updated by msuraev about 1 month ago

  • Status changed from In Progress to Stalled

Also available in: Atom PDF