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