Feature #4286
closedSupport configuration using 8PSK on dowlink while staying GMSK-only on uplink
Added by pespin over 4 years ago. Updated over 3 years ago.
100%
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.
Related issues
Updated by fixeria over 4 years 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.
Updated by pespin over 4 years 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
Updated by pespin over 4 years 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.
Updated by laforge over 4 years 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.
Updated by pespin over 4 years 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/
Updated by pespin over 4 years ago
- Related to Bug #4338: Add EGPRS tests toTTCN3 PCU_Tests_RAW added
Updated by pespin over 4 years ago
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.
Updated by pespin over 4 years ago
- Subject changed from Support configuration using 8PSK on dowlink while staying GSMK-only on uplink to Support configuration using 8PSK on dowlink while staying GMSK-only on uplink
Updated by fixeria over 4 years ago
- Related to Feature #1529: Support MCS 5-9 in uplink added
Updated by pespin over 4 years ago
- Related to Feature #4488: have uplink/downlink tests for all CS/MCS added
Updated by pespin over 4 years ago
- Related to Feature #4510: Support EGPRS RLC/MAC blocks in ttcn3 added
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
- % Done changed from 0 to 80
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.
Updated by pespin over 3 years ago
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.
Updated by pespin over 3 years ago
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);So, I deally we should:
- 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.
Updated by laforge over 3 years ago
- Status changed from Feedback to Resolved
- % Done changed from 80 to 100
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.