Cellular Network Infrastructure » Radio Access Network » OsmoPCU

I have started to work on this.
Currently trying to get a related ttcn3 test case working: https://gerrit.osmocom.org/#/c/8020/

I am still trying to get the PCU paging test to work.

Currently I am stuck trying to decode messages received on the L1 port in PCU_Tests.ttcn.
My modified test is expecting an RR message of type PAGING REQUEST 1.

The following is received on the pcu_sock by osmo-bts-virtual:

DPCU <0009> pcu_sock.c:480 Data request received: sapi=PCH arfcn=0 block=0 data=37 38 39 15 06 21 00 01 f4 27 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b

This packet gets added to the paging queue:

DPAG <0005> paging.c:266 Add IMM.ASS to queue (group=9)

The corresponding message received by TTCN3 is:

14:30:04.172259 5 L1CTL_PortType.ttcn:212 dec_L1ctlDlMessageLV(): Decoded @L1CTL_Types.L1ctlDlMessageLV: {
    len := 39,
    msg := {
        header := {
            msg_type := L1CTL_DATA_IND (3),
            flags := {
                padding := '0000000'B,
                f_done := false
            },
            padding := '0000'O
        },
        dl_info := {
            chan_nr := {
                u := {
                    ch0 := RSL_CHAN_NR_PCH_AGCH (18)
                },
                tn := 0
            },
            link_id := {
                c := FACCH_SDCCH (0),
                na := false,
                prio := SAPI0_PRIO_NORMAL (0),
                sapi := 0
            },
            arfcn := {
                pcs := false,
                arfcn := 871
            },
            frame_nr := 179740,
            rx_level := 63,
            snr := 63,
            num_biterr := 0,
            fire_crc := 0
        },
        payload := {
            data_ind := {
                payload := '1506210001F4272B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B'O
            }
        }
    }
}

It looks as if the message received on TTCN3's L1 port is in fact a copy of the pcu-sock message, doesn't it?
The first 3 bytes (37 38 39) of the pcu-sock message are now represented as a header part, and the remainder is in the payload.

Is this expected? I would say it is it not, since pcu-sock messages are certainly not valid L1 messages.

At which step in the chain should the PCU socket message be translated into RR?

Further investigation suggests that the payload is indeed correct (0x06 is the RR discriminator, 0x21 is the code for RR message PAGING TYPE1).

I have spotted one obvious problem in Titan's decoder: https://git.eclipse.org/r/#/c/124834/

Without the above patch, the decoder will decode the payload 1506210001F4272B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B
if I strip the leading '15'. However, it decodes it to an RR message of type interSystemToUTRAN_HandoverCommand which is not what is expected.

With the above patch applied, the decoder won't decode the payload anymore either in full or with leading '15' stripped. I am still unsure why. Could there be a problem with assumptions about byte order?

I have figured out the reason for the decoder problem. I am still unsure how to best fix it.

There is some disagreement about how the mobile identity in a type1 paging request should be coded.

3GPP TS 44.060 version 9.3.0 Release 9 page 334 says:

Mobile Identity (variable length octet string)
This octet string is the representation of the Mobile Identity.
It shall provide the international mobile subscriber identity, IMSI.
The encoding of this octet string is the value part (starting with octet 3)
of the type 4 information element Mobile Identity defined in 3GPP TS 44.018.

We are also told that the length of the octet string is given in a 4-bit field.

In our TTCN3 test suite, we have 3(!) distinct definitions for this structure:

GSM_RR_Types.ttcn:      type record MobileIdentityLV {
MobileL3_CommonIE_Types.ttcn:type record MobileIdentityLV
RLCMAC_CSN1_Types.ttcn: type record MobileIdentityLV {

GSM_RR_types:

        type record MobileIdentityLV {
                uint8_t         len,
                MobileIdentity  mi
        } with { variant (len) "LENGTHTO(mi)" };

RLCMAC_CSN1_Types:

        type record MobileIdentityLV {
                uint4_t                 len,
                octetstring             mobile_id
        } with { variant (len) "LENGTHTO(mobile_id)" };

MobileL3_CommonIE_Types:

type record MobileIdentityLV
{
  LIN1               lengthIndicator,
  MobileIdentityV    mobileIdentityV
} with { variant (lengthIndicator) "LENGTHTO (mobileIdentityV)"};

The PCU_Tests.ttcn file imports two of these definitions (from GSM_RR_Types and RLCMAC_CSN1_Types).
It is unclear to me how the encoder/decoder will behave for this type.

However, even if this ambiguity was resolved, the PCU paging test still wouldn't work.
This is because paging requests sent by osmo-pcu use a TLV IE data type for coding the P-TIMSI.
The coding used conforms to "10.5.1.4 Mobile Identity" in 3GPP TS 24.008 version 8.6.0 Release 8.
(My impression is that this contradicts "9.1.22 Paging request type 1" in 3GPP TS 44.018 version 10.3.0 Release 10, which explicitly states that MobileIndentify1 was an LV, not a TLV.)

The information element written by osmo-pcu matches the MobileIdentityTLV data structure of our TTCN3 tests. Two such type definitions exist:

GSM_RR_Types.ttcn:      type record MobileIdentityTLV {
MobileL3_CommonIE_Types.ttcn:type record MobileIdentityTLV

GSM_RR_Types:

        type record MobileIdentityTLV {
                uint8_t         tag,
                uint8_t         len,
                MobileIdentity  mi
        } with { variant (len) "LENGTHTO(mi)" };

MobileL3_CommonIE_Types:

type record MobileIdentityTLV
{
  BIT7               elementIdentifier,
  BIT1               spare1,
  MobileIdentityLV   mobileIdentityLV
};

One way of getting the decoder to work is to change the type of the mobileIdentity1 field in the definition of PDU_RRM_PagingReq_Type1_NW_MS:

type record PDU_RRM_PagingReq_Type1_NW_MS
{
  // L2 pseudo length is handled automatically by encoder/decoder
  BIT8              messageType, // '00100001'B;
  PageMode_V        pageMode,
  ChannelNeeded_V   channelNeeded,
  MobileIdentityLV mobileIdentity1,
  MobileIdentityTLV mobileIdentity2 optional,
  P1RestOctets      p1RestOctets
} with { variant "TAG ( mobileIdentity2, elementIdentifier = '0010111'B )" };   //'17'O

With mobileIdentity1 changed to MobileIdentityTLV (and a similar change to a template which uses this type), the paging request is properly decoded:
(EDIT: Well, not entirely: The values shown in mobileIdentity1 still don't look right).

14:19:49.063407 mtc PCU_Tests.ttcn:215 dec_PDU_ML3_NW_MS_backtrack(): Stream before decoding: '06210001F02B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B'O
14:19:49.063476 mtc PCU_Tests.ttcn:215 dec_PDU_ML3_NW_MS_backtrack(): Decoded @MobileL3_Types.PDU_ML3_NW_MS: {
    discriminator := '0110'B,
    tiOrSkip := {
        skipIndicator := '0000'B
    },
    msgs := {
        rrm := {
            pagingReq_Type1 := {
                messageType := '00100001'B,
                pageMode := {
                    pM := '00'B,
                    spare1_2 := '00'B
                },
                channelNeeded := {
                    channel1 := '00'B,
                    channel2 := '00'B
                },
                mobileIdentity1 := {
                    elementIdentifier := '0000001'B,
                    spare1 := '0'B,
                    mobileIdentityLV := {
                        lengthIndicator := 240,
                        mobileIdentityV := {
                            typeOfIdentity := '011'B,
                            oddEvenInd_identity := {
                                imei_sv := {
                                    oddevenIndicator := '1'B,
                                    digits := '2B2B2B2B2B2B2B2B'H,
                                    fillerDigit := '0010'B
                                }
                            }
                        }
                    }
                },
                mobileIdentity2 := omit,
                p1RestOctets := '2B2B2B2B2B2B2B2B'O ("++++++++")
            }
        }
    }
}

I still need to build a physical test setup for this issue.
I've been waiting for Neels to find time to help (since he has already built a similar setup) but he has been busy with more important tasks and is now on vacation.
Will poke again when he gets back.

I have a suitable test setup now. I've been distracted by other work during the past few weeks, but will eventually get back to this.

As a first step towards tearing this ball of hair apart, I suggest we rename one of the three definitions of MobileIdentityLV: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/11292

Having spent some more time working on this issue, I've got my paging test into a state where it passes. However, having done some further reading I am now quite sure that the test I am writing doesn't match the behaviour of actual networks.

Many details of how paging procedures work in circuit vs. packet switched situations still elude me.
It is hard for me to write a useful TTCN3 test which matches realistic expectations without investing a significant amount of time researching the specs.

Could someone help me with this?

Otherwise, I feel that I should punt on this task and leave it to someone else who can write basic but meaningful PCU paging tests first. Then I could go back to the original problem which this issue is actually about (encoding QoS parameters in PCU paging requests).

There is now a basic paging test which is passing with osmo-pcu from current master: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/9374

This issue is waiting for the above paging test to be merged.

above mentioned issue has been merged: adding a TC_paging test.
However, I cannot see any QoS being part of that test.
Setting to feedback to re-assign / reschedule urgency...