Bug #4509
closedosmo-pcu rejects 8-bit RACH requests rejected on new MS when on "egprs only" mode
100%
Description
As seen by a WIP ttcn3 test (branch pespin/pcu-cap-egprs), which sends a 8-bit RACH req and then tries to use Packet Resource Request to submit RAcapabilities in order to get an EGPRS context, as explained in spec 3GPP TS 04.60 sec "7.1.3 TBF establishment using two phase access".
/* FIXME: properly encode RA (see TS 24.060, table 11.2.5.2) */ private function f_establish_tbf(out GsmRrMessage rr_imm_ass, uint8_t bts_nr := 0, uint16_t ra := oct2int('3A'O), uint8_t is_11bit := 0, PCUIF_BurstType burst_type := BURST_TYPE_0, TimingAdvance ta := 0) runs on RAW_PCU_Test_CT return boolean { var uint32_t fn; /* FIXME: ask the BTS component to give us the current TDMA fn */ fn := 1337 + ta; /* Send RACH.ind */ log("Sending RACH.ind on fn=", fn, " with RA=", ra, ", TA=", ta); BTS.send(ts_PCUIF_RACH_IND(bts_nr := bts_nr, trx_nr := 0, ts_nr := 0, ra := ra, is_11bit := is_11bit, burst_type := burst_type, fn := fn, arfcn := 871, qta := ta * 4)); /* Expect Immediate (TBF) Assignment on TS0/AGCH */ return f_pcuif_rx_imm_ass(rr_imm_ass, tr_IMM_TBF_ASS(?, ra, fn), bts_nr); } ok := f_establish_tbf(rr_imm_ass); /* Send PACKET RESOURCE REQUEST to upgrade to EGPRS * (see 3GPP TS 04.60 "7.1.3.1 Initiation of the Packet resource request procedure") */ f_tx_rlcmac_ul_block(ts_RLC_UL_CTRL_ACK(valueof(ts_RlcMacUlCtrl_PKT_RES_REQ(tlli, ms_racap))), 0); f_rx_rlcmac_dl_block_exp_pkt_ul_ass(dl_block, sched_fn);
It fails during f_establish_tbf when using "egprs only" mode, because an Imm ass Reject is sent by PCU. gsmtap log:
172 19:34:53.895756 Apr 22, 2020 19:34:53.895756000 CEST 172.18.13.101 33969 172.18.13.10 4729 GSMTAP 220 RACH request received: sapi=1 qta=0, ra=0x3a, fn=1337, cur_fn=4, is_11bit=0 173 19:34:53.895800 Apr 22, 2020 19:34:53.895800000 CEST 172.18.13.101 33969 172.18.13.10 4729 GSMTAP 225 MS requests UL TBF on RACH, so we provide one: ra=0x3a Fn=1337 qta=0 is_11bit=0: 174 19:34:53.895827 Apr 22, 2020 19:34:53.895827000 CEST 172.18.13.101 33969 172.18.13.10 4729 GSMTAP 193 Not accepting non-EGPRS phone in EGPRS-only mode 175 19:34:53.895852 Apr 22, 2020 19:34:53.895852000 CEST 172.18.13.101 33969 172.18.13.10 4729 GSMTAP 211 No PDCH resource sending Immediate Assignment Uplink (AGCH) reject 176 19:34:53.895886 Apr 22, 2020 19:34:53.895886000 CEST 172.18.13.101 33969 172.18.13.10 4729 GSMTAP 289 Sending data request: trx=0 ts=0 sapi=2 arfcn=0 fn=0 cur_fn=4 block=0 data=4d 06 3a 10 3a 09 6b 14 3a 09 6b 14 3a 09 6b 14 3a 09 6b 14 0b 2b 2b
Attached find the pcap generated by ttcn3 env.
So looking at osmo-pcu, the interesting parts seem to be located in bts.cpp BTS::rcv_rach(), which calls:
sb = is_single_block(m_bts.force_two_phase, ra, burst_type, is_11bit);
which seems to decide whether a single block is required or not based on some information (force_two_phase is not set, but can be configured through VTY "two-phase-acces"). In this case, a single block is not selected, and fails later during call to tbf = tbf_alloc_ul_tbf(&m_bts, NULL, -1, 0, ms_class, true);
which of course fails because egprs_ms_class passed is 0.
So as far as I understand from the spec reference listed above, it should be possible for this scenario to work. Maybe I need to send some specific value in the RACH request so that single block is selected in order to sent PACKET RESOURCE REQUEST? If that's not the case, then osmo-pcu needs to be fixed to accept the RACH request to allow the MS to upgrade its MS class afterwards.
Files
Related issues
Updated by fixeria about 4 years ago
If I remember correctly, keith reported a similar behavior in the IRC (not sure if there is any ticket).
... spec 3GPP TS 04.60 sec "7.1.3 TBF establishment using two phase access".
TS 04.60 (or TS 44.060) mostly describes the establishment procedures for configurations where PBCCH (and thus PRACH) is present (despite it has been deprecated a while ago, and should not be used nowadays). I would recommend to additionally check out 3GPP TS 44.018, in particular section 3.5.2 "Packet access procedure using CCCH".
So as far as I understand from the spec reference listed above, it should be possible for this scenario to work.
Yep, I also think we should not reject phones just because egprs_ms_class is not known. Even in case of 11 bit EGPRS Packet Channel Request, egprs_ms_class is not always included (depending on its type). Maybe we should just do a regular GPRS assignment in that case? AH, damn, it's 'egprs-only' mode...
Maybe I need to send some specific value in the RACH request so that single block is selected in order to sent PACKET RESOURCE REQUEST?
See 3GPP TS 44.018, table 9.1.8.1 "CHANNEL REQUEST message content". The value '3A'O was picked randomly, because back then in September I had almost no knowledge about GPRS and its RLC/MAC. So '3A'O ('00111010'B) is not even a valid packet Access Burst :/ Looking at the table, it matches '0011xxxx'B - "Answer to paging".
So I would try sending '01110xxx'B (single block packet access), or one of '011110xx'B | '01111x0x'B | '01111xx0'B (one phase packet access). Good luck!
Updated by pespin about 4 years ago
Apparently we receive System Information 13 from BTS to PCU through the pcuif, so we can also gain information in osmo-pcu regarding what's allowed:
3GPP TS 04.08 version 7.21.0 "10.5.2.37b SI 13 Rest Octets"
Also in TS 04.60 (7.1.2.1 Initiation of the packet access procedure):
EGPRS TBF mode capable MSs shall monitor the GPRS Cell Options IE on the PBCCH (PSI1/PSI13) for the cell's EGPRS capability. In the GPRS Cell Options IE it is also indicated if the EGPRS PACKET CHANNEL REQUEST is supportedin the cell.
Updated by laforge about 4 years ago
On Thu, Apr 23, 2020 at 03:35:22PM +0000, pespin [REDMINE] wrote:
Apparently we receive System Information 13 from BTS to PCU through the pcuif,
yes, this is among other things needed so we can send it to individual MS over PACCH
once the TBF duration exceeds a certain time. This is required as the MS is not able
to read SI13 from the BCCH while it is in an active TBF.
Updated by pespin over 3 years ago
- Related to Feature #4544: concurrent operation of GPRS and EGPRS mode added
Updated by pespin over 3 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
"egprs only" vty command has been deprecated and is nowadays a NO-OP in current master, so this has been implicitly fixed by all later changes related to #4544.
Closing the ticket.