Project

General

Profile

Bug #1939

implement packet idle/transfer mode including T3192

Added by lynxis over 2 years ago. Updated 25 days ago.

Status:
Feedback
Priority:
High
Assignee:
Target version:
-
Start date:
02/04/2017
Due date:
% Done:

0%

Spec Reference:
44.060, 44.018

Description

At the moment there is no implementation of packet idle or packet transfer mode.
The PCU should use the packet mode to decide on which way to assign a (DL) TBF.
idle -> CCH
transfer -> PDCH

T3192 define the time between releasing TBF and scanning the paging channel (CCH in our case).

History

#1 Updated by laforge over 2 years ago

  • Assignee set to lynxis

#2 Updated by laforge about 2 years ago

  • Assignee changed from lynxis to sysmocom

#3 Updated by laforge almost 2 years ago

  • Priority changed from Normal to High

#4 Updated by laforge about 1 year ago

#5 Updated by laforge 6 months ago

  • Assignee changed from sysmocom to lynxis

#6 Updated by pespin 25 days ago

  • Spec Reference set to 44.060

T3192 is defined in TS 44.060

#7 Updated by pespin 25 days ago

  • Spec Reference changed from 44.060 to 44.060, 44.018

#8 Updated by pespin 25 days ago

IIUC, in our case T3192 is submitted to MS by osmo-bsc through osmo-bts on BCCH SI (osmo-bsc.git rest_octects.c:encode_t3192()).
In osmo-pcu we receive from BTS related T3191 and T3193. Specially related seems to be timer T3193, which by definition needs to be greater than T3192:

T3193:Wait for reuse of TFI after reception of the final PACKET DOWNLINK ACK/NACK from the mobile station for this TBF. This timer is used on the network side to define when timer T3192 on the mobile station side has surely expired so that the TFI can be reused. Its value is network dependent.

T3193 is currently started during tbf::release() (where tbf state is set to GPRS_RLCMAC_WAIT_RELEASE), and its callback is set to destroy it with tbf_timeout_free(). However, in gprs_rlcmac_dl_tbf::append_data() I see if tbf in state GPRS_RLCMAC_WAIT_RELEASE, then reuse it, but I don't see T3193 being stopped or restarted... that sounds like a bug. On the other hand, that looks like implementing what this ticket describes as missing, so I'm a bit confused.

Related field we send in osmo-pcu towards the MS is "CONTROL_ACK", which is controlled by this variable:

block->u.Packet_Downlink_Assignment.CONTROL_ACK         = tbf->was_releasing; // NW establishes no new DL TBF for the MS with running timer T3192

which in turn is set by:

src/tbf_dl.cpp
509:            old_tbf->was_releasing = old_tbf->state_is(GPRS_RLCMAC_WAIT_RELEASE);
519:            was_releasing = state_is(GPRS_RLCMAC_WAIT_RELEASE);
src/tbf.cpp
1284:   new_dl_tbf->was_releasing = was_releasing;

#9 Updated by pespin 25 days ago

  • Status changed from New to Feedback

Closer look up shows not stopping T3191 is fine because function establish_dl_tbf_on_pacch() called during append_data() actually allocates a new tbf so it's expected that the timer is left there to free the old one.

So all in all I'm not sure if there needs to be something else done for this ticket. Setting as feedback to let lynxis comment on it.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)