Project

General

Profile

Bug #2404

PAGING-PS doesn't use QoS parameters from BSSGP

Added by laforge 11 months ago. Updated 1 day ago.

Status:
In Progress
Priority:
Low
Assignee:
Target version:
-
Start date:
07/29/2017
Due date:
% Done:

0%

Estimated time:
Spec Reference:

Description

The BSSGP PAGING PS message contains mandatory QoS parameters. However, we don't actually encode those when generating the PCH paging message in Encoding::write_paging_request()

History

#1 Updated by laforge 8 months ago

  • Assignee set to msuraev

#2 Updated by laforge 4 months ago

  • Assignee changed from msuraev to stsp

#3 Updated by stsp about 2 months ago

  • Status changed from New to In Progress

#4 Updated by stsp about 2 months ago

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

#5 Updated by stsp 4 days ago

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 is a PCU_IF_MSG_DATA_REQ message with SAPI PCU_IF_SAPI_PCH.
The first few bytes are partly based on the IMSI used by the test ("01234567"H) and identify the paging group.

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?

#6 Updated by stsp 1 day ago

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?

#7 Updated by stsp 1 day ago

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 ("++++++++")
            }
        }
    }
}

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)