Project

General

Profile

Bug #4338

Add EGPRS tests toTTCN3 PCU_Tests_RAW

Added by pespin 3 months ago. Updated 29 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
-
Start date:
12/23/2019
Due date:
% Done:

10%

Spec Reference:

Description

I create this ticket to document process of adding some sample test validating EGPRS against osmo-pcu.
Probably the easiest would be to start and create a TC_mo_mt_ping_egprs().

When the mobile station has received the PACKET UPLINK ASSIGNMENT message it shall respond with a PACKET RESOURCE REQUEST message in the first allocated radio block.
A mobile station supporting EGPRS shall indicate the EGPRS capability in the MS Radio Access Capability 2 IE of the PACKET RESOURCE REQUEST message. 

https://issuu.com/leliwa/docs/signalling_in_gprs_egprs_chapter_03/30 page 44-45/68.

That's two-phase access to get EGPRS TBF:
  • MS sends RACH on CCCH asking for UL TBF
  • Network sends IMM ASS on AGCH/PCH providing PDCH + TLLI + TFI
  • MS sends PACKET RESOURCE REQUEST on PDCH assigned with "MS Radio Access Capability 2" IE stating it supports EGPRS
  • The network should send an PACKET UPLINK ASSIGNMENT with updated CS
  • MS answers with PACKET CONTROL ACK
  • MS can now send whatever data.

TS 44.060 sec Table 11.2.16.1: PACKET RESOURCE REQUEST information elements

osmo-pcu.cfg osmo-pcu.cfg 782 Bytes fixeria, 03/04/2020 07:05 PM
offending_UL_RR.pcap offending_UL_RR.pcap 121 Bytes keith, 03/05/2020 08:29 PM

Related issues

Related to OsmoPCU - Feature #4286: Support configuration using 8PSK on dowlink while staying GMSK-only on uplinkNew11/28/2019

Related to OsmoPCU - Feature #1559: EGPRS/GPRS multiplexing on single PDCHNew02/23/2016

Related to OsmoPCU - Bug #1548: 11bit RACH supportStalled02/23/2016

Related to OsmoPCU - Feature #1529: Support MCS 5-9 in uplinkNew02/22/2016

History

#1 Updated by pespin 3 months ago

  • Description updated (diff)

#2 Updated by pespin 3 months ago

  • Related to Feature #4286: Support configuration using 8PSK on dowlink while staying GMSK-only on uplink added

#3 Updated by pespin 3 months ago

  • Description updated (diff)

#4 Updated by pespin 3 months ago

The interesting IE for PACKET RESOURCE REQUEST is: TS 44.060 sec 12.30 MS Radio Access Capability 2

That one basically redirects to TS 24.008 sec 10.5.5.12a MS Radio Access capability

In there there seems to be some configs related to 8PSK support per band, etc.

Regarding TTCN3: RLCMAC_CSN1_Types.ttcn has "type record PacketResourceReq", "resource_req, msg_type = PACKET_RESOURCE_REQUEST;"

That record contains:

    /* 11.2.16 Packet Resource Request */
    type record PacketResourceReq {
        BIT1            acc_type_presence,
        RlcAccessType        acc_type optional,
        BIT1            id_type,
        PacketResourceReqID    id,
        BIT1            ms_rac2_presence,
        MSRadioAccCap2        ms_rac2 optional,
        ChannelReqDescription    ch_req_desc,
        BIT1            change_mark_presence,
        BIT2            change_mark optional,
        BIT6            C_val,
        BIT1            sign_var_presence,
        BIT6            sign_var optional,
        ILevels            I_levels
        /* TODO: additional contents for further Releases (starting from 1999) */
    } with {
        variant (acc_type) "PRESENCE(acc_type_presence = '1'B)" 
        variant (id) "CROSSTAG(gtfi, id_type = '0'B; tlli, id_type = '1'B)" 
        variant (ms_rac2) "PRESENCE(ms_rac2_presence = '1'B)" 
        variant (change_mark) "PRESENCE(change_mark_presence = '1'B)" 
        variant (sign_var) "PRESENCE(sign_var_presence = '1'B)" 
    };

But the interesting IE is not yet implemented, so we need to add support for it TTCN3, then create a new templates in RLCMAC_Types.ttcn:

    /* 12.30 MS Radio Access Capability 2 (feature bitmask)
     * (value part, see 3GPP TS 24.008, 10.5.5.12a) */
    type union MSRadioAccCap2 {
        /* TODO: see table 10.5.146/3GPP TS 24.008 */
        bitstring        other
    };

#5 Updated by laforge 3 months ago

Please note that those templates were all written at a time where TITAN
didn't yet understand the 'L' / 'H' notation in the raw codec. I
requested that upstream and it has been implemented as part of TITAN for
quite some time (for sure the version we use already has it).

For many data types, this syntax is a precondition for describing the
RLC/MAC data types correctly. In absence of L/H logic, the offset of
the message in the packet determines whether '1'/'0' is sufficient for
decoding it or not.

For many GSM rest octets it didn't matter, as they always appear at a
fixed position in the packet. In GPRS and EGPRS, this luxury doesn't
exist.

#7 Updated by pespin 3 months ago

I have code in TTCN3 already sending the Packet Resource Request asking to use EGPRS (https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16677). I see the EGPRS Multislot class updated correctly in osmo-pcu, but it's still not enabling EGPRS for that TBF. TbfTest.cpp does something similar in test_tbf_egprs_two_phase_spb() -> establish_ul_tbf_two_phase_spb(), but in there the logs (TbfTest.err) show some differences and in there EGPRS is enabled for the TBF:

Modifying MS object, TLLI = 0x00000000, EGPRS MS class 0 -> 1    <<---- This one I get it too during TTCN3
TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL EGPRS) Enabled EGPRS, mode EGPRS  <<-- This one I don't get in TTCN3.

The difference seems to appear due to:

    if (egprs_ms_class > 0 && bts->egprs_enabled) {
        tbf->enable_egprs();
        setup_egprs_mode(bts, ms);
        LOGPTBF(tbf, LOGL_INFO, "Enabled EGPRS, mode %s\n", mode_name(ms->mode()));
    }

So in unit test TbfTest, it manually sets bts->egprs_enabled=1. The only way I see that param is modified is throught the VTY param "no egprs" (=0) and "egprs only" (=1). I am a bit surprised because over last months I have been using in osmo-bsc "gprs mode egprs" and I have no "egprs only" setting in my osmo-pcu.cfg, which seems not inline...

Looking at what "gprs mode egprs" does in osmo-bsc: It sets some enum to bts->gprs.mode = BTS_GPRS_EGPRS, which is then used when sending info_ind over pcu_sock #info_ind->flags |= PCU_IF_FLAG_MCS1;@ (same for MCS2, and so on).

However, it seems osmo-pcu is doing nothing with those flags (it does for CS, but not for MCS):

    for (i = 0; i < 9; i++) {
        if ((info_ind->flags & (PCU_IF_FLAG_MCS1 << i)))
            LOGP(DL1IF, LOGL_DEBUG, " Use MCS%d\n", i+1);
    }

In osmo-bsc, it is also used to tell MS that egprs is supported:

    case BTS_GPRS_EGPRS:
        si13_default.cell_opts.ext_info_present = 1;
        si13_default.cell_opts.ext_info.egprs_supported = 1;

So all in all, I was unaware I had to use the "egprs only" VTY cmd to enable EGPRS support in osmo-pcu. I fail to see though why is that command necessary and the bts->egprs_enabled is not set dynamically based on what's received during info_ind in pcu_sock (for instance, when any flag PCU_IF_FLAG_MCS* is received). Any thoughts from someone else on this?

TODO: Fix osmo-gsm-tester templates/osmo-pcu.cfg to have "no egprs" or "egprs only" based on whether egprs is enabled.

#8 Updated by fixeria 3 months ago

So all in all, I was unaware I had to use the "egprs only" VTY cmd to enable EGPRS support in osmo-pcu.
Any thoughts from someone else on this?

AFAIR, EDGE never worked for me out of the box, and I had to use that VTY option all the time...

#9 Updated by laforge 3 months ago

On Tue, Dec 24, 2019 at 03:43:00PM +0000, pespin [REDMINE] wrote:

So all in all, I was unaware I had to use the "egprs only" VTY cmd to enable EGPRS support in osmo-pcu. I fail to see though why is that command necessary

Because osmo-pcu supports either GPRS or EGPRS. That means, as soon as you turn on EGPRS,
you loose backwards compatibility to non-EGPRS phones. Due to that somewhat strange and unusual
(in terms of other implementations) behavior, it shouldn't happen dynamically/automatically,
but should be very explicit choice by the user. the "only" in the vty command also expresses
that.

I believe there are some ancient tickets about this. The reason for
lack of GPRS backwards compatibility was to first get GPRS and EGPRS by
themselves working reliably and tested, and then (if ever) implement the
backwards compatibility. I think the main problem is that there are
some parts of downlink PDCH which all (or at least all MS with active
TBF) need to be able to parse, and in a mixed GPRS + EGPRS cell you then
need to not only look at your own TBF/MS capabilities, but also at those
of all the other MS to determine if you can send such information in MCS
or if you must send it in CS. I think it already starts with things
like TFI and USF, which must be decoded by all MS with active TBF.

#10 Updated by pespin 3 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10
  • I added support to enable EGPRS through VTY at the start of the test to be able to test both "egprs only" and "no egprs" behaviors, and added a test which reproduces 8-bit rach requests are rejected during "egprs only" mode:
    https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16687
Current situation / TODO:
  • Test TC_mo_ping_pong_egprs currently fails because f_establish_tbf() fails when using "is_11bit := 1, burst_type := BURST_TYPE_1". The problem afaiu is that tr_IMM_TBF_ASS() doesn't match 11-bit RA correctly, because tr_compute_ReqRef() and f_compute_ReqRef() don't support decoding 11-bit RA sent back by osmo-pcu (we support sending them already through PCUIF because there we simply fill a struct we send over the unix socket). I'd welcome some hints on how to add support for it.
  • I'd expect osmo-pcu to accept non-11 bit RACH (how's it called?) even if egprs is enabled because it can later on announce edge capabilities (through sending PACKET RESOURCE REQUEST), but I guess it's one of the shortcomings of current implementation.

#11 Updated by pespin 2 months ago

laforge wrote:

On Tue, Dec 24, 2019 at 03:43:00PM +0000, pespin [REDMINE] wrote:

So all in all, I was unaware I had to use the "egprs only" VTY cmd to enable EGPRS support in osmo-pcu. I fail to see though why is that command necessary

Because osmo-pcu supports either GPRS or EGPRS. That means, as soon as you turn on EGPRS,
you loose backwards compatibility to non-EGPRS phones. Due to that somewhat strange and unusual
(in terms of other implementations) behavior, it shouldn't happen dynamically/automatically,
but should be very explicit choice by the user. the "only" in the vty command also expresses
that.

I believe there are some ancient tickets about this.

Found it: #1559

#12 Updated by pespin 2 months ago

  • Related to Feature #1559: EGPRS/GPRS multiplexing on single PDCH added

#13 Updated by pespin 2 months ago

  • Related to Bug #1548: 11bit RACH support added

#14 Updated by pespin 2 months ago

#15 Updated by keith about 1 month ago

pespin I wonder if these log entries are related to this ticket;

csn1.c:253 csnStreamDecoder: error NEED_MORE BITS TO UNPACK (-5) at I_LEVEL (idx 160)
csn1.c:1441 csnStreamDecoder: error NEED_MORE BITS TO UNPACK (-5) at EGPRS_TimeslotLinkQualityMeasurements (idx 164): End AdditionsR99

If I comment the two related return ProcessError() lines and return 0 in line 1441, things actually go ahead and "work".

Stopping in csn1.cpp:253, I can see:

(gdb) p pDescr 
$1 = (const CSN_DESCR *) 0x66efd0 <CSNDESCR_InterferenceMeasurementReport_t+48>
(gdb) p *pDescr 
$2 = {type = 2, i = 4, descr = {ptr = 0x0, value = 0}, offset = 4, may_be_null = 0, sz = 0x4561b4 "I_LEVEL", value = 0, aux_fn = 0x0}
(gdb) p remaining_bits_len 
$3 = 3

Breaking at line 1441:

(gdb) p pDescr 
$6 = (const CSN_DESCR *) 0x670230 <CSNDESCR_PRR_AdditionsR99_t+144>
(gdb) p *pDescr
$7 = {type = 3, i = 0, descr = {ptr = 0x66f040 <CSNDESCR_EGPRS_TimeslotLinkQualityMeasurements_t>, value = 6746176}, offset = 24, 
  may_be_null = 0, sz = 0x456728 "EGPRS_TimeslotLinkQualityMeasurements", value = 0, aux_fn = 0x0}
(gdb) p remaining_bits_len 
$8 = -1

EDIT: The above is with a HTC "Desire 628 dual sim" phone model. At the same time, this config and version don't exhibit this error with iPhone 5c for example.

Further edit, maybe a full backtrace helps to see the context, and when this happens. (It's before I even get an MM context with this phone)

(gdb) bt
#0  csnStreamDecoder (ar=0x7fffffffde30, pDescr=0x670230 <CSNDESCR_PRR_AdditionsR99_t+144>, vector=0x793540, 
    readIndex=0x7fffffffded8, data=0x7924f8) at csn1.c:1442
#1  0x000000000043f14b in csnStreamDecoder (ar=0x7fffffffdee0, pDescr=0x6706f0 <CSNDESCR_Packet_Resource_Request_t+816>, 
    vector=0x793540, readIndex=0x7fffffffded8, data=0x792410) at csn1.c:471
#2  0x0000000000439f4d in decode_gsm_rlcmac_uplink (vector=0x793540, data=0x792410) at gsm_rlcmac.cpp:5027
#3  0x000000000042a5d7 in gprs_rlcmac_pdch::rcv_control_block (this=0x68de88 <s_bts+4264>, 
    data=0x7fffffffe136 "@\027\340q\227i\357&2\262Yd \006", data_len=23 '\027', fn=709804, meas=0x7fffffffe090, cs=...)
    at pdch.cpp:708
#4  0x000000000042b054 in gprs_rlcmac_pdch::rcv_block_gprs (this=0x68de88 <s_bts+4264>, 
    data=0x7fffffffe136 "@\027\340q\227i\357&2\262Yd \006", data_len=23 '\027', fn=709804, meas=0x7fffffffe090, cs=...)
    at pdch.cpp:852
#5  0x000000000042aa3d in gprs_rlcmac_pdch::rcv_block (this=0x68de88 <s_bts+4264>, 
    data=0x7fffffffe136 "@\027\340q\227i\357&2\262Yd \006", len=23 '\027', fn=709804, meas=0x7fffffffe090) at pdch.cpp:771
#6  0x000000000040ebfc in pcu_rx_data_ind_pdtch (trx_no=0 '\000', ts_no=7 '\a', 
    data=0x7fffffffe136 "@\027\340q\227i\357&2\262Yd \006", len=23 '\027', fn=709804, meas=0x7fffffffe090) at pcu_l1_if.cpp:287
#7  0x000000000040ef66 in pcu_rx_data_ind (data_ind=0x7fffffffe134) at pcu_l1_if.cpp:336
#8  0x00000000004110f9 in pcu_rx (msg_type=2 '\002', pcu_prim=0x7fffffffe130) at pcu_l1_if.cpp:731
#9  0x0000000000435fbd in pcu_sock_read (bfd=0x6968e0 <pcu_sock_state>) at osmobts_sock.cpp:141
#10 0x000000000043619b in pcu_sock_cb (bfd=0x6968e0 <pcu_sock_state>, flags=1) at osmobts_sock.cpp:196
#11 0x00007ffff70e4fd7 in ?? () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
#12 0x00007ffff70e5656 in osmo_select_main () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12
#13 0x000000000040470f in main (argc=1, argv=0x7fffffffe558) at pcu_main.cpp:355

#16 Updated by fixeria about 1 month ago

Hi keith!

csn1.c:253 csnStreamDecoder: error NEED_MORE BITS TO UNPACK (-5) at I_LEVEL (idx 160)
csn1.c:1441 csnStreamDecoder: error NEED_MORE BITS TO UNPACK (-5) at EGPRS_TimeslotLinkQualityMeasurements (idx 164): End AdditionsR99

Could you please attach a *.pcap withe the RLC/MAC packets triggering this?

#17 Updated by keith about 1 month ago

fixeria - Yep.. sorry, remind me how to get that, GSMTAP in the pcu?

#18 Updated by fixeria about 1 month ago

fixeria - Yep.. sorry, remind me how to get that, GSMTAP in the pcu?

Attaching a configuration example. Most likely, you can use it as-is.

#19 Updated by keith about 1 month ago

fixeria Thanks, yes I already refreshed my memory on this. :)

I do not know WTF is up with my systems, but after initially seeing the desired messages in the GSMTAP, I now cannot get GSMTAP to work again. I've tried sending to 127.0.0.1 and also to a remote host running wireshark, (-i) I've tried various combinations of all and few gsmtap-category. All to no avail. "dummy" category does work for some reason, otherwise, nothing that corresponds to the log (which by the way, also does not turn up, with log gsmtap active.)

It's highly bizarre, not to mention frustrating.

I even, in desperation, turned the damn thing off and turned it on again. :-/

I'll try again... but another day. Right now I need to get away from technology before something gets smashed to tiny pieces.

#20 Updated by keith 30 days ago

slightly less frustrating today, working with the lime-sdr on x86 rather than on ARM

Here is a pcap of a packet that causes "NEED_MORE BITS TO UNPACK"

Thanks!

#21 Updated by fixeria 29 days ago

Here is a pcap of a packet that causes "NEED_MORE BITS TO UNPACK"

Thanks, keith! Your packet uncovered another bug in the OsmoPCU's CSN.1 decoder:

https://gerrit.osmocom.org/c/osmo-pcu/+/17390 tests/rlcmac: add a new test vector for Packet Resource Request

that should be fixed by:

https://gerrit.osmocom.org/c/osmo-pcu/+/17391 csn1: fix csnStreamDecoder(): skip bits unhandled by serialize()

Please test and add V+1 in Gerrit if that helps.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)