Project

General

Profile

Actions

Bug #1939

closed

implement packet idle/transfer mode including T3192

Added by lynxis about 7 years ago. Updated about 4 years ago.

Status:
Closed
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).

Actions #1

Updated by laforge about 7 years ago

  • Assignee set to lynxis
Actions #2

Updated by laforge over 6 years ago

  • Assignee changed from lynxis to 4368
Actions #3

Updated by laforge over 6 years ago

  • Priority changed from Normal to High
Actions #4

Updated by laforge over 5 years ago

Actions #5

Updated by laforge almost 5 years ago

  • Assignee changed from 4368 to lynxis
Actions #6

Updated by pespin over 4 years ago

  • Spec Reference set to 44.060

T3192 is defined in TS 44.060

Actions #7

Updated by pespin over 4 years ago

  • Spec Reference changed from 44.060 to 44.060, 44.018
Actions #8

Updated by pespin over 4 years 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;

Actions #9

Updated by pespin over 4 years 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.

Actions #10

Updated by laforge about 4 years ago

  • Status changed from Feedback to Closed
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)