Cellular Network Infrastructure » Radio Access Network » OsmoPCU

The 3GPP specifications permit 8PSK only in downlink and GMSK only in uplink.

Could you please add the exact spec. reference to this ticket?

Ensure and test that ocmo-pcu can actually deal with 8PSK only in downlink.

AFAIR, OsmoPCU derives the Coding Scheme from the length of a given MAC block, so it should be easy to implement a test case in TTCN-3. The only relatively complex part is the process of EGPRS TBF establishment - we may need to implement additional RLC/MAC message types.

Sample related CS/MCS tables (with modulation format):
https://www.electronics-notes.com/articles/connectivity/2g-gprs/coding.php
https://www.electronics-notes.com/articles/connectivity/2g-gsm-edge/modulation-coding-schemes-mcs.php

I have been studying osmo-pcu code for a while on how the (M)CS are selected/modified in both UL and DL, and documented it a bit better in the code:
https://gerrit.osmocom.org/c/osmo-pcu/+/16317 Clarify (M)CS related VTY attributes

So the summary is, currently DL and UL (M)CS values are calculated separately with different methods, and each direction uses its own (VTY) input parameters to compute the right one based on link signal, etc.:

Downlink:

cs downgrade-threshold <1-10000> //Downgrade downlink (M)CS if there's less than X octets to transmit (optimization)
cs threshold <0-100> <0-100> // Downgrade or upgrade (or keep) downlink (M)CS based on error rate

Uplink:

cs link-quality-ranges cs1 <0-35> cs2 <0-35> <0-35> cs3 <0-35> <0-35> cs4 <0-35>
mcs link-quality-ranges mcs1 <0-35> mcs2 <0-35> <0-35> mcs3 <0-35> <0-35> mcs4 <0-35> <0-35> mcs5 <0-35> <0-35> mcs6 <0-35> <0-35> mcs7 <0-35> <0-35> mcs8 <0-35> <0-35> mcs9 <0-35>
mcs <1-9> [<1-9>]  // "Initial MCS value to be used (default 1)\n" "Use a different initial MCS value for the uplink" 
mcs max <1-9> [<1-9>] // "Maximum MCS value to be used\n" "Use a different maximum MCS value for the uplink" 

• Enabling EGPRS (usual way)
• mcs <whatever> <whatever less than 5>
• mcs max <whatever> <whatever less than 5>
• Configure mcs link-quality-ranges accordingly, so that mcs4 is <whatever> 35

fixeria wrote:

AFAIR, OsmoPCU derives the Coding Scheme from the length of a given MAC block, so it should be easy to implement a test case in TTCN-3. The only relatively complex part is the process of EGPRS TBF establishment - we may need to implement additional RLC/MAC message types.

Indeed. in pdch.h gprs_rlcmac_pdch::rcv_block():

GprsCodingScheme cs = GprsCodingScheme::getBySizeUL(len);
...
    if (mcs_is_gprs(cs))
        return rcv_block_gprs(data, len, fn, meas, cs);

    if (mcs_is_edge(cs))
        return rcv_data_block(data, len, fn, meas, cs);

And according gprs_rlcmac_pdch::rcv_data_block(), "These are always data blocks, since EGPRS still uses CS-1 for control blocks", so we only need to care about EGPRS for data block, control blocks are the same.

GprsCodingScheme GprsCodingScheme::getBySizeUL(unsigned size)
{
    switch (size) {
        case 23: return GprsCodingScheme(CS1);
        case 27: return GprsCodingScheme(MCS1);
        case 33: return GprsCodingScheme(MCS2);
        case 34: return GprsCodingScheme(CS2);
        case 40: return GprsCodingScheme(CS3);
        case 42: return GprsCodingScheme(MCS3);
        case 49: return GprsCodingScheme(MCS4);
        case 54: return GprsCodingScheme(CS4);
        case 61: return GprsCodingScheme(MCS5);
        case 79: return GprsCodingScheme(MCS6);
        case 119: return GprsCodingScheme(MCS7);
        case 143: return GprsCodingScheme(MCS8);
        case 155: return GprsCodingScheme(MCS9);
    }

    return GprsCodingScheme(UNKNOWN);
}

And I think related bits in our existing TTCN3 PCU infra:

private function f_tx_rlcmac_ul_block(template (value) RlcmacUlBlock ul_data, int16_t lqual_cb := 0)
runs on RAW_PCU_Test_CT {
    var octetstring data;
    /* Encode the payload of DATA.ind */
    data := enc_RlcmacUlBlock(valueof(ul_data));
    data := f_pad_oct(data, 23, '00'O); /* CS-1 */

    /* Enqueue DATA.ind (both TDMA frame and block numbers to be patched) */
    f_pcuif_tx_data_ind(data, lqual_cb);
}

So what'd be good: Creating several tests reusing TC_cs_lqual_ul_tbf and also allcoate DL tbfs, and with different values of VTY "cs link-quality-ranges" and "mcs max" test different conditions like the scenario I explained in the previous comment.

I am already working on TTCN3 test improvements. I submitted support to set (M)CS related parameters by test over VTY, and also submitted a commit for wireshark to describe related CS field correctly:
https://code.wireshark.org/review/#/c/35259/

And this is what osmo-pcu does with it (upon Rx):

        if (request->Exist_MS_Radio_Access_capability) {
            ms_class = Decoding::get_ms_class_by_capability(
                &request->MS_Radio_Access_capability);
            egprs_ms_class =
                Decoding::get_egprs_ms_class_by_capability(
                    &request->MS_Radio_Access_capability);
        }
        if (!ms_class)
            LOGP(DRLCMAC, LOGL_NOTICE, "MS does not give us a class.\n");
        if (egprs_ms_class)
            LOGP(DRLCMAC, LOGL_NOTICE,
                "MS supports EGPRS multislot class %d.\n",
                egprs_ms_class);
        ul_tbf = tbf_alloc_ul(bts_data(), trx_no(), ms_class,
            egprs_ms_class, tlli, ta, ms);

        if (!ul_tbf) {
            handle_tbf_reject(bts_data(), ms, tlli,
                trx_no(), ts_no);
            return;
        }

        /* set control ts to current MS's TS, until assignment complete */
        LOGPTBF(ul_tbf, LOGL_DEBUG, "change control TS %d -> %d until assinment is complete.\n",
            ul_tbf->control_ts, ts_no);

        ul_tbf->control_ts = ts_no;
        /* schedule uplink assignment */
        TBF_SET_ASS_STATE_UL(ul_tbf, GPRS_RLCMAC_UL_ASS_SEND_ASS);

        /* get capabilities */
        if (ul_tbf->ms())
            ul_tbf->ms()->set_egprs_ms_class(egprs_ms_class);

....

uint8_t Decoding::get_egprs_ms_class_by_capability(MS_Radio_Access_capability_t *cap)
{
    int i;

    for (i = 0; i < cap->Count_MS_RA_capability_value; i++) {
        if (!cap->MS_RA_capability_value[i].u.Content.Exist_Multislot_capability)
            continue;
        if (!cap->MS_RA_capability_value[i].u.Content.Multislot_capability.Exist_EGPRS_multislot_class)
            continue;
        return cap->MS_RA_capability_value[i].u.Content.Multislot_capability.EGPRS_multislot_class;
    }

    return 0;
}

See gsm_rlcmac.h "MS_Radio_Access_capability_t" and "Packet_Resource_Request_t".

set_egprs_ms_class() is simply storing the uint8_t into an internal field only acessed through public getter egprs_ms_class(), which is used in quite a lot of places in osmo-pcu code.

So we are interested in the EGPRS multislot class:

EGPRS Multi Slot Class:
 The presence of this field indicates EGPRS capability. Whether the MS is capable of 8-PSK modulation in uplink is indicated by the presence of 8-PSK Power Capability field. The EGPRS Multi Slot Class field is coded as the binary representation of the multislot class defined in 3GPP TS 45.002 [32].  The same multislot capability is applicable also for EGPRS2 if supported. The same multislot capability is applicable also for Downlink Multi Carrier configuration if supported.

Quick table with Multi Slot Class can be found here:
https://www.rfwireless-world.com/Terminology/GPRS-mobile-multislot-classes.html

So by default in osmo-pcu egprs multislot class is 0 which iiuc means it's disabled. So passing any class value != 0 should enable egprs afaiu.

Current status / summary:

I have been recently reworking all the CS/MCS code to work properly.
Once can speicify maximum UL and DL CS/MCS separately in osmo-pcu.cfg, so nowadays one simply needs to configure osmo-pcu using this VTY command:

DEFUN_ATTR(cfg_pcu_mcs_max,
       cfg_pcu_mcs_max_cmd,
       "mcs max <1-9> [<1-9>]",
       MCS_STR
       CS_MAX_STR
       "Maximum MCS value to be used\n" 
       "Use a different maximum MCS value for the uplink",
       CMD_ATTR_IMMEDIATE)

In this specific case, where we want 8PSK in DL but not in UL, one would set "mcs max 9 4". That's it. I have a high confidence this should be working fine with current osmo-pcu master.

I will add a new test to validate this specifcially, it should be easy now with all the infrastructure I have been adding recently to PCU_Tests.

Documentation on how to configure such a set up with osmo-pcu was recently added to osmo-pcu user manual: https://gerrit.osmocom.org/c/osmo-pcu/+/21943

Still TODO: Add TTCN3 to make sure such a setup works fine and to be safe against regressions.

Usual CS/MCS limitations are tested already by:

    execute( TC_cs_initial_ul() );
    execute( TC_cs_max_ul() );
    execute( TC_cs_initial_dl() );
    execute( TC_cs_max_dl() );
    execute( TC_mcs_initial_ul() );
    execute( TC_mcs_max_ul() );
    execute( TC_mcs_initial_dl() );
    execute( TC_mcs_max_dl() );

So using MCS1-9 during download while staying MCS1-4 in upload should already be covered implicitly by those tests.

I also did some manual tests using following osmo-pcu config, and it's working fine:

 mcs 9 4
 mcs max 9 4

The problem with that is basically this is applied globally to all BTS the PCU is serving. Since we acutally usually run osmo-pcu attached to a BTS, this is not usually a problem. However, in the event we end up running osmo-pcu attach to a BSC, it may be an issue, since we may want to actually configure that by BTS.

In that case, one would do that by setting the proper MCS bitmask in BTS/BSC passed through PCUIF in info_ind message. However, the main limitation right now in there is that there's no different bitmask for UL and DL, meaning one cannot set different allowed MCS on each direction, hence not being possible to configure 8-PSK in DL while keeping GMSK in UL.

In order to do so, we'd need to update the PCUIF proto to provide 2 bitmasks in info_ind, one for UL and one for DL.
Regarding this bitmask: it is also sent BSC->BTS over OML in IPA, but it doesn't support setting UL/DL (nanobts_attr_cell_get):

    if (bts->gprs.mode == BTS_GPRS_EGPRS) {
        buf[0] = 0x8f;
        buf[1] = 0xff;
    } else {
        buf[0] = 0x0f;
        buf[1] = 0x00;
    }
    msgb_tl16v_put(msgb, NM_ATT_IPACC_CODING_SCHEMES, 2, buf);

• PCUIF: Update proto to have 2 bitmask, 1 for UL, one for DL
• osmo-bsc: Add a per-bts "gprs (m)cs bitmask allowed cs1 cs2 cs3 ... (ul|dl|uldl)" command, where ul/dl speicifc ones are only used if PCU is connected to osmo-bsc directly through PCUIF.
• osmo-bts: In the case where osmo-pcu is attached to osmo-bsc, the osmo-bts can apply its own (hardcoed, negotatied with phy or vty configured) restrictions to the bitmask before sending it to osmo-pcu through PCUIF.

This way an osmo-bts using a phy supporting 8PSK only in DL can correctly tune the bitmask sent to osmo-pcu. In the case of osmo-bts-trx, the bitmask can be negotiated through TRXC.

laforge any comment/opinion on what is worth implementing regarding this topic in the near future is appreciated.

At least for small setups where osmo-pcu is attached to 1 BTS there's no real need for any of those thing stated above since applying the restrictions globally on osmo-pcu is fine.

pespin wrote:

At least for small setups where osmo-pcu is attached to 1 BTS there's no real need for any of those thing stated above since applying the restrictions globally on osmo-pcu is fine.

I think that's completely fine.