Cellular Network Infrastructure » Radio Access Network » OsmoBSC

I already implemented the BSSLAP and BSSMAP_LE encoder/decoder using TITAN RAW syntax in TTCN3, see https://git.osmocom.org/osmo-ttcn3-hacks/commit/?h=laforge/lcs&id=c22461905ea5e75806b6d33ee72682a4f972f44e

I would suggest to use the above and start with a test suite (e.g. BSC_Tests_LCS.ttcn) simulating the SMLC side, and then use that to drive the actual OsmoBSC side implementation.

The "final" fist version of the TTCN3 code + BSC_Tests integration is in https://gerrit.osmocom.org/q/topic:%22lcs%22+(status:open%20OR%20status:merged).

Handing over to neels for development of actual test logic in BSC_Tests_LCS.ttcn, as well as the following implementatin inside osmo-bsc.

Taking over.
(wondering why %Done says 100, but four checklist items are unchecked.)

Looking at 3GPP 43.059 9.3.1.1 MS in IDLE State

In IDLE state the MS may be paged or may request an originating (e.g. emergency) call. The paging response message
or CM Service Request, in each case respectively, received in COMPLETE_LAYER_3 message may contain location
information that includes the TA value. If available, the TA value and other location information shall be provided to
the SMLC by the requesting BSC along with the current serving cell ID in the BSSAP-LE Perform Location request.
This enables TA based positioning in the SMLC without any further interactions.

This indicates that the Complete Layer 3 may include a TA value. I can't find that. Emphasis on "may"?
Surely the BTS must know the TA to even be able to communicate in the first place;
It's just that I see no specified way to tell the BSC about the TA, besides a Measurement Report.

Here is a Paging Response packet dissection from Abis RSL:

Frame 7449: 91 bytes on wire (728 bits), 91 bytes captured (728 bits) on interface unknown, id 0
Ethernet II, Src: Sysmocom_00:00:0a (24:62:78:00:00:0a), Dst: LcfcHefe_d4:92:05 (c8:5b:76:d4:92:05)
Internet Protocol Version 4, Src: 192.168.178.68, Dst: 192.168.178.73
Transmission Control Protocol, Src Port: 59810, Dst Port: 3003, Seq: 2402, Ack: 1193, Len: 25
IPA protocol ip.access, type: RSL
    DataLen: 22
    Protocol: RSL (0x00)
Radio Signalling Link (RSL)
    0000 001. = Message discriminator: Radio Link Layer Management messages (1)
    .... ...0 = T bit: Not considered transparent by BTS
    .000 0110 = Message type: ESTablish INDication (0x06)
    Channel number IE 
        Element identifier: Channel Number (0x01)
        0010 1... = C-bits: SDCCH/4 + ACCH (sub-chan 1) (5)
        .... .000 = Time slot number (TN): 0
    Link Identifier IE 
        Element identifier: Link Identifier (0x02)
        00.. .... = channel type: Main signalling channel (FACCH or SDCCH) (0)
        ..0. .... = Not applicable (NA): Applicable
        ...0 0... = Priority: Normal Priority (0)
        .... .000 = SAPI: 0
    L3 Information IE
        Element identifier: L3 Information (0x0b)
        Length: 13
        Link Layer Service Data Unit (L3 Message)
GSM A-I/F DTAP - Paging Response
    Protocol Discriminator: Radio Resources Management messages (6)
        .... 0110 = Protocol discriminator: Radio Resources Management messages (0x6)
        0000 .... = Skip Indicator: No indication of selected PLMN (0)
    DTAP Radio Resources Management Message Type: Paging Response (0x27)
    .... 0000 = Spare: 0x00
    Ciphering Key Sequence Number
        ...0 .... = Spare: 0x00
        .... .000 = Ciphering Key Sequence Number: 0
    Mobile Station Classmark 2
        Length: 3
        0... .... = Spare: 0
        .10. .... = Revision Level: Used by mobile stations supporting R99 or later versions of the protocol (2)
        ...1 .... = ES IND: Controlled Early Classmark Sending option is implemented in the MS
        .... 0... = A5/1 algorithm supported: encryption algorithm A5/1 available
        .... .000 = RF Power Capability: class 1 (0)
        0... .... = Spare: 0
        .1.. .... = PS capability (pseudo-synchronization capability): PS capability present
        ..01 .... = SS Screening Indicator: Capability of handling of ellipsis notation and phase 2 error handling  (1)
        .... 1... = SM capability (MT SMS pt to pt capability): Mobile station supports mobile terminated point to point SMS
        .... .0.. = VBS notification reception: no VBS capability or no notifications wanted
        .... ..0. = VGCS notification reception: no VGCS capability or no notifications wanted
        .... ...0 = FC Frequency Capability: The MS does not support the E-GSM or R-GSM band
        1... .... = CM3: The MS supports options that are indicated in classmark 3 IE
        .0.. .... = Spare: 0
        ..0. .... = LCS VA capability (LCS value added location request notification capability): LCS value added location request notification capability not supported
        ...0 .... = UCS2 treatment: the ME has a preference for the default alphabet
        .... 0... = SoLSA: The ME does not support SoLSA
        .... .1.. = CMSP: CM Service Prompt: Network initiated MO CM connection request supported for at least one CM protocol
        .... ..1. = A5/3 algorithm supported: encryption algorithm A5/3 available
        .... ...0 = A5/2 algorithm supported: encryption algorithm A5/2 not available
    Mobile Identity - TMSI/P-TMSI (0xb75712f5)
        Length: 5
        1111 .... = Unused: 0xf
        .... 0... = Odd/even indication: Even number of identity digits
        .... .100 = Mobile Identity Type: TMSI/P-TMSI/M-TMSI (4)
        TMSI/P-TMSI: 0xb75712f5

It's just that I see no specified way to tell the BSC about the TA, besides a Measurement Report.

JFYI: RSL CHANnel ReQuireD contains a mandatory Timing Advance IE.

fixeria wrote:

It's just that I see no specified way to tell the BSC about the TA, besides a Measurement Report.

JFYI: RSL CHANnel ReQuireD contains a mandatory Timing Advance IE.

ah, excellent.

I see 3GPP TS 48.058 8.5.3 CHANNEL REQUIRED containing an "Access Delay" (9.3.17).

"The Access Delay field contains the delay of the access burst as measured by BTS. The delay is expressed as defined
for the Timing Advance TA in 3GPP TS 45.010 but with the range extended to 8 bits, i.e. the six least significant bits of
the field correspond to the Timing Advance except for GSM 400 where all the 8 bits are used."

So at the time of processing the Paging Response, the BSC should already have up-to-date TA from the Channel Required just before that.
And we indeed store that in lchan->rqd_ta in rsl_rx_chan_rqd().

The BSSMAP-LE PERFORM LOCATION REQUEST message is sent from BSC to SMLC.
It has a mandatory Cell Identifier IE: "This parameter gives the current cell location of the target MS."
However, in case of an IDLE MS, the BSC does not know the current cell location.

Before that, there is a BSSMAP PERFORM LOCATION REQUEST from MSC to BSC, which has a Cell Identifier IE.
When the MS is attached, the MSC can thus send the last seen Cell Identifier to the BSC.
However, that Cell Identifier IE on the A interface is optional.

So, the spec allows a situation where the MSC did not pass a Cell Identifier,
and the BSC cannot comply with the mandatory Cell Identifier to be sent to the SMLC, when the MS is IDLE.

The idea is that later on, the SMLC tells the BSC to return a TA value, after which the BSC does a Paging.
Now it seems to me that the BSC should instead do a Paging even before first contacting the SMLC,
so that the Paging Response indicates the current cell of the MS.

Alternatively, the BSC could require the MSC to communicate the current Cell Identifier where the MS is attached.

I wonder whether it is anyway preferable to verify that the MS answers to a Paging first, to reduce SMLC traffic,
or whether doing an unconditional Paging on Location Request from the MSC potentially wastes spectrum capacity.
For TA Positioning, we need to Page an IDLE MS anyway. Is the same true for all other positioning methods?

I'm deciding back and forth about where to hook the Paging, can anyone contribute an opinion?

There is another aspect to this: if we always Page before contacting the SMLC, then we already know the TA,
and we can attach a BSSLAP APDU indicating the TA already to the first BSSMAP-LE Perform Loc Req towards the SMLC.
In that case, the SMLC may never need to send a TA Request to the BSC -- all information is already present.
So, if we first Page, we always send the TA along with the first request to the SMLC,
and hence in practice we will never see any BSSLAP requests from SMLC to BSC at all.
Then, supporting a TA Request message in OsmoBSC is pretty much obsolete, and the only place where we'd see one is in the test suite.

Another aspect respective to Paging an IDLE MS:
The Perform Location Request from the MSC can contain the IMSI to indicate the subscriber.
But there is no TMSI IE.
That means that a Location Services related Paging must always be by IMSI (or by IMEI) identity.
To me it seems that the idea of Location Services is to locate an MS that is already active on Layer 3,
because these aspects about Paging seem odd and not thought through.

I get a ttcn3 decoding error for a valid BSSMAP-LE Perform Location Request message.
OsmoBSC sends a valid message (verified by wireshark and manually), but when titan decodes it, I get:

00:47:14.864225 8 BSSAP_LE_Emulation.ttcn:519 Message enqueued on BSSAP_LE from VirtSMLC-SCCP(7) @SCCPasp_Types.ASP_SCCP_N_CONNECT_ind : {
    calledAddress := {
        addressIndicator := {
            pointCodeIndic := '1'B,
            ssnIndicator := '1'B,
            globalTitleIndic := '0000'B,
            routingIndicator := '1'B
        },
        signPointCode := '00000010111110'B,
        subsystemNumber := 252,
        globalTitle := omit
    },
    callingAddress := {
        addressIndicator := {
            pointCodeIndic := '1'B,
            ssnIndicator := '1'B,
            globalTitleIndic := '0000'B,
            routingIndicator := '1'B
        },
        signPointCode := '00000010111011'B,
        subsystemNumber := 250,
        globalTitle := omit
    },
    qualityOfService := omit,
    userData := '000E2B44010005080062F2240017002A'O,
    connectionId := 7555610,
    importance := omit
} id 2
00:47:14.864341 8 BSSAP_LE_CodecPort.ttcn:233 dec_PDU_BSSAP_LE(): Stream before decoding: '000E2B44010005080062F2240017002A'O
00:47:14.865800 8 BSSAP_LE_CodecPort.ttcn:233 Dynamic test case error: While RAW-decoding type '@BSSAP_LE_Types.PDU_BSSAP_LE': Can not decode type '@BSSAP_LE_Types.PDU_BSSAP_LE', because invalid message was received
00:47:14.865855 8 BSSAP_LE_CodecPort.ttcn:233 setverdict(error): none -> error

The ttcn3 coding does also look perfectly fine to me.
If anyone knows how to debug such a situation, assistance would be welcome

Hi Neels,

The ttcn3 coding does also look perfectly fine to me.

I parsed the octetstring by hand on paper, and everything looks correct.

If anyone knows how to debug such a situation, assistance would be welcome

I am currently using TITAN 7.1.pl1, and it also fails to decode this octetstring.

Applying these changes makes decoding work for me:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20015 library/BSSAP_LE_Types: fix wrong field order in PDU_BSSAP_LE
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20016 library/BSSAP_LE_Types: fix: add missing FIELDLENGTH attributes

good luck!