Bug #5696
openRLC/MAC: poll timeout when assigning a multi-slot DL TBF
0%
Description
One of my phones, Sony Ericsson K800i, fails to complete PDP Context Activation procedure. Thanks to TEMS, I found out that the phone never receives Activate PDP Context Accept message. Further analysis revealed that Activate PDP Context Request message from the phone triggers allocation of a multi-slot Downlink TBF, which includes TS6 and TS7. For some reason, the phone ACKnowledges allocation of Downlink TBF on TS7 instead of TS6, what confuses osmo-pcu and causes retransmissions of the PACKET_DOWNLINK_ASSIGNMENT message.
Files
Updated by fixeria over 1 year ago
I implemented a testcase reproducing this behavior. A PCAP file attached, quick summary below.
| PCAP Frame # | Timeslot # | Description |
|---|---|---|
| 1 | 0 | RACH.ind: the MS requests an Uplink TBF for sending Activate PDP Context Request |
| 2 | 0 | RR Immediate Assignment: the PCU allocates a single-slot TBF |
| 3 | 6 | RLC/MAC UL DATA: the MS sends Activate PDP Context Request (random payload in test) |
| 4 | 6 | RLC/MAC DL CTRL: Packet Uplink Ack from the PCU confirms receipt of the Uplink block |
| 5 | 6 | RLC/MAC DL CTRL: Packet Downlink Assignment: the PCU allocates a multi-slot DL TBF and polls the MS |
| 6 | 6 | RLC/MAC UL CTRL: Dummy Control Block: the MS sends a dummy block while the PCU expects an ACK here |
| 7 | 7 | RLC/MAC UL CTRL: Packet Control Ack for the MS ACKnowledges multi-slot DL TBF assignment |
| 8 | 6 | RLC/MAC DL CTRL: Packet Downlink Assignment: the PCU is confused and retransmits DL TBF assignment |
The PCU keeps sending Packet Downlink Assignment again and again, so Downlink TBF assignment never succeeds.
Updated by fixeria over 1 year ago
- Status changed from In Progress to Stalled
So the main problem here is that osmo-pcu sends Packet Downlink Assignment message on TS6 and then expects Packet Control Ack from the MS on the same timeslot, but for some reason the MS responds on TS7 instead. I don't know if this is a spec. conformant behavior, or a side-effect of the UL/DL latency caused by the scheduling advance. I also don't know if this is specific to SE K800i, Qualcomm based Android seems to work fine.
DL1IF DEBUG PDCH(bts=0,trx=0,ts=6) FN=34 Rx DATA.ind PDTCH: BER10k = 0, BTO = 0, Q = 0 (pcu_l1_if.cpp:475)
DRLCMACUL DEBUG PDCH(bts=0,trx=0,ts=6) Got RLC block, coding scheme: CS-1, length: 23 (23)) (pdch.cpp:959)
DRLCMAC DEBUG PDCH(bts=0,trx=0,ts=6) FN=34 +++++++++++++++++++++++++ RX : Uplink Control Block +++++++++++++++++++++++++ (pdch.cpp:887)
DCSN1 INFO csnStreamDecoder (type: Pkt UL Dummy Ctrl Block (3)): PayloadType = 1 | spare = 0 | R = 0 | MESSAGE_TYPE = 3 | TLLI = 0x00d187d5 | Padding = 0|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43| (gsm_rlcmac.c:5476)
DRLCMAC DEBUG PDCH(bts=0,trx=0,ts=6) FN=34 ------------------------- RX : Uplink Control Block ------------------------- (pdch.cpp:900)
DRLCMAC NOTICE PDCH(bts=0,trx=0,ts=6) Timeout for registered POLL (FN=34, reason=DL_ASS): TBF(TFI=0 TLLI=0x00d187d5 DIR=UL STATE=FLOW) (pdch_ul_controller.c:323)
DTBF NOTICE TBF(TFI=0 TLLI=0x00d187d5 DIR=UL STATE=FLOW) poll timeout for FN=34, TS=6 (curr FN 34) (tbf.cpp:547)
DTBF DEBUG TBF(TFI=0 TLLI=0x00d187d5 DIR=UL STATE=FLOW) N3105 0 => 1 (< MAX 8) (tbf.cpp:393)
DTBF INFO DL_ASS_TBF(UL-TFI_0)[0x55f394c913a0]{WAIT_ACK}: Received Event ASS_POLL_TIMEOUT (tbf.cpp:606)
DTBF NOTICE TBF(TFI=0 TLLI=0x00d187d5 DIR=UL STATE=FLOW) Timeout for polling PACKET CONTROL ACK for PACKET DOWNLINK ASSIGNMENT: |Assignment was on CCCH|Uplink data was received| (tbf_dl_ass_fsm.c:171)
DTBF INFO DL_ASS_TBF(UL-TFI_0)[0x55f394c913a0]{WAIT_ACK}: state_chg to SEND_ASS (tbf_dl_ass_fsm.c:175)
DL1IF DEBUG (bts=0,trx=0,ts=7) FN=34 Rx DATA.ind: sapi=5 arfcn=871 cur_fn=34 block=8 data=40 04 03 46 1f 57 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b (pcu_l1_if.cpp:460)
DL1IF DEBUG PDCH(bts=0,trx=0,ts=7) FN=34 Rx DATA.ind PDTCH: BER10k = 0, BTO = 0, Q = 0 (pcu_l1_if.cpp:475)
DRLCMACUL DEBUG PDCH(bts=0,trx=0,ts=7) Got RLC block, coding scheme: CS-1, length: 23 (23)) (pdch.cpp:959)
DRLCMAC DEBUG PDCH(bts=0,trx=0,ts=7) FN=34 +++++++++++++++++++++++++ RX : Uplink Control Block +++++++++++++++++++++++++ (pdch.cpp:887)
DCSN1 INFO csnStreamDecoder (type: Pkt Control Ack (1)): PayloadType = 1 | spare = 0 | R = 0 | MESSAGE_TYPE = 1 | TLLI = 0x00d187d5 | CTRL_ACK = 3 | Exist_AdditionsR5 = 0 | Padding = 43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43| (gsm_rlcmac.c:5476)
DRLCMAC DEBUG PDCH(bts=0,trx=0,ts=7) FN=34 ------------------------- RX : Uplink Control Block ------------------------- (pdch.cpp:900)
DRLCMAC NOTICE PDCH(bts=0,trx=0,ts=7) PACKET CONTROL ACK with unknown FN=34 TLLI=0x00d187d5 (TRX 0 TS 7) (pdch.cpp:348)
DRLCMAC NOTICE PDCH(bts=0,trx=0,ts=7) PACKET CONTROL ACK with unknown TBF corresponds to MS with IMSI , TA 0, uTBF (TFI=0, state=FLOW), dTBF (TFI=0, state=ASSIGN) (pdch.cpp:353)
Updated by fixeria over 1 year ago
Here is a testcase reproducing the problem:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/29628 pcu: f_pcuif_tx_data_ind(): make waiting behavior configurable
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/29629 pcu: add TC_dl_multislot_tbf_ack_wrong_ts reproducing OS#5696
it does not necessarily need to be merged, because the phone's behavior still looks odd to me.
Updated by pespin over 1 year ago
related specs: 3GPP TS 44.060 version 16.0.0 section 10.4.5 "Relative Reserved Block Period (RRBP) field":
If no uplink control timeslot is assigned to the mobile station and EFTA is not used at the time the RRBP field is
received, the mobile station shall transmit the uplink radio block on the same timeslot as the block where the RRBP was
received (in case of a BTTI configuration) or on the corresponding uplink PDCH pair to the downlink PDCH pair where
the block containing the RRBP was received (in case of a RTTI configuration). If EFTA is used at the time the RRBP
field is received however, the mobile station shall instead transmit the uplink radio block according to the uplink radio
block transmission order as described in Annex N regardless of the timeslot or PDCH-pair where the block containing
the RRBP was received.
If an uplink control timeslot is assigned to the mobile station, the mobile station shall transmit the uplink radio block on
this uplink control timeslot (in case of a BTTI configuration) or on the uplink PDCH pair the uplink control timeslot
belongs to (in case of an RTTI configuration).
A polled control message shall always be sent in the uplink block specified by the corresponding valid RRBP field of a
downlink RLC/MAC control block, and not in any other uplink block that may be allocated to the mobile station.
Updated by fixeria over 1 year ago
pespin wrote in #note-4:
related specs: 3GPP TS 44.060 version 16.0.0 section 10.4.5 "Relative Reserved Block Period (RRBP) field":
If no uplink control timeslot is assigned to the mobile station and EFTA is not used at the time the RRBP field is
received, the mobile station shall transmit the uplink radio block on the same timeslot as the block where the RRBP was
received (in case of a BTTI configuration) or on the corresponding uplink PDCH pair to the downlink PDCH pair where
the block containing the RRBP was received (in case of a RTTI configuration). If EFTA is used at the time the RRBP
field is received however, the mobile station shall instead transmit the uplink radio block according to the uplink radio
block transmission order as described in Annex N regardless of the timeslot or PDCH-pair where the block containing
the RRBP was received.
If an uplink control timeslot is assigned to the mobile station, the mobile station shall transmit the uplink radio block on
this uplink control timeslot (in case of a BTTI configuration) or on the uplink PDCH pair the uplink control timeslot
belongs to (in case of an RTTI configuration).A polled control message shall always be sent in the uplink block specified by the corresponding valid RRBP field of a
downlink RLC/MAC control block, and not in any other uplink block that may be allocated to the mobile station.
So AFAIU, osmo-pcu correctly expects the ACK on TS6, while K800i violates the part "... shall transmit the uplink radio block on the same timeslot as the block where the RRBP was received". I think the best would be to collect some RLC/MAC samples from K800i when it's talking to a commercial network (where we don't have UL/DL delay), and see how it behaves there.
Updated by pespin over 1 year ago
My understanding is that we are doing it properly in osmo-pcu yes.
