Cellular Network Infrastructure » Radio Access Network » OsmoPCU

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.