Project

General

Profile

Feature #4286

Support configuration using 8PSK on dowlink while staying GSMK-only on uplink

Added by pespin 8 days ago. Updated 7 days ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
11/28/2019
Due date:
% Done:

0%

Spec Reference:

Description

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

The 3GPP specifications permit 8PSK only in downlink and GMSK only in uplink. The question is whether our implementation deals with this properly.

This behavior is completely 3GPP Compliant, as EGPRS specifies 9 MCS, only half of which are 8PSK while the others are GMSK. The choice of coding schemes is entirely under network control, so we can instruct the MS/UE to transmit always in GMSK only.

Scenario: an L1 may support transmitting 8PSK but not support it on the receiver side.

Given that most traffic is present mostly on the downlink, this may make a big difference if L1 has such limitations.

History

#1 Updated by fixeria 8 days ago

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.

#2 Updated by pespin 8 days ago

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" 

So, in order to avoid using 8PSK on the uplink while allowing it on the downlink, theoretically it should be possible to do so already by:
  • 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

#3 Updated by pespin 8 days ago

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.

#4 Updated by laforge 8 days ago

Thanks for your analysis.

On Thu, Nov 28, 2019 at 05:18:01PM +0000, pespin [REDMINE] wrote:

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.

feel free to go ahead with that. The goal here is to ensure this kind of configuration is continuously
tested so we don't accidentially break it.

#5 Updated by pespin 7 days ago

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/

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)