Project

General

Profile

Feature #4597

Lb interface and basic SMLC support

Added by laforge 6 months ago. Updated about 1 month ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
06/08/2020
Due date:
% Done:

100%

Spec Reference:

Description

In Location_Services, the LCS architecture is described.

This ticket is about the support in OsmoBSC in order to support LCS related messages on the AoIP interface, and to translate those into transactions on the to-be-introduced Lb interface towards an external SMLC.

  • Test suite (we typically follow test-driven development)
    • Implementation of BSSMAP-LE in TTCN-3 (Types, Templates)
    • Implementation of BSSLAP in TTCN-3 (Types, Templates)
    • Implementation of Lb interface test suite in TTCN-3, covering
      • BSSAP-LE PerformLocationRequest / Response (successful, timeout, unsuccessful)
      • BSSMAP-LE ConnectionOrientedInfo(BSSLAP TA Request) (successful, timeout, unsuccessful)
  • Add notion of Lb interface to SMLC (separate SCCP subsystem/user, configuration)
    • BSSAP-LE encoding/decoding
    • BSSLAP encoding/decoding
    • Related finite state machine + procedure
  • Extend A interface
    • encoding/decoding of LCS related BSSAP messages + IEs
    • related finite state machine + procedure
location_services_ta.png View location_services_ta.png 68.3 KB variant doing a Paging only after TA Request neels, 09/05/2020 12:07 PM
location_services_ta2.png View location_services_ta2.png 58 KB variant with early Paging, already sending TA in the first BSSMAP-LE message neels, 09/05/2020 12:25 PM
BSSMAP-LE_Perf_Loc_Req.pcapng BSSMAP-LE_Perf_Loc_Req.pcapng 416 Bytes apparently valid BSSMAP-LE Perf Loc Req that ttcn3 complains about neels, 09/08/2020 12:58 AM
BSSMAP-LE_Perf_Loc_Req.png View BSSMAP-LE_Perf_Loc_Req.png 260 KB image showing wireshark dissection of BSSMAP-LE_Perf_Loc_Req.pcapng neels, 09/08/2020 01:01 AM
4275
4276
4278

Checklist

  • Implementation of BSSMAP-LE in TTCN-3 (Types, Templates)
  • Implementation of BSSLAP in TTCN-3 (Types, Templates)
  • TTCN3 BSSAP-LE PerformLocationRequest / Response (successful, timeout, unsuccessful)
  • TTCN3 BSSMAP-LE ConnectionOrientedInfo(BSSLAP TA Request) (successful, timeout, unsuccessful)
  • Add notion of Lb interface to OsmoBSC (separate SCCP subsystem/user, configuration)
  • Extend A interface

Related issues

Related to OsmoSMLC - Feature #4598: Implement minimalistic SMLCResolved06/08/2020

History

#1 Updated by laforge 4 months ago

  • Assignee set to neels

#2 Updated by laforge 4 months ago

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.

#3 Updated by laforge 4 months ago

#4 Updated by laforge 3 months ago

  • % Done changed from 0 to 100

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.

#5 Updated by laforge 3 months ago

  • Checklist item Implementation of BSSMAP-LE in TTCN-3 (Types, Templates) added
  • Checklist item Implementation of BSSLAP in TTCN-3 (Types, Templates) added
  • Checklist item TTCN3 BSSAP-LE PerformLocationRequest / Response (successful, timeout, unsuccessful) added
  • Checklist item TTCN3 BSSMAP-LE ConnectionOrientedInfo(BSSLAP TA Request) (successful, timeout, unsuccessful) added
  • Checklist item Add notion of Lb interface to OsmoBSC (separate SCCP subsystem/user, configuration) added
  • Checklist item Extend A interface added

#6 Updated by neels 3 months ago

  • Status changed from New to In Progress

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

#7 Updated by neels 3 months ago

  • % Done changed from 100 to 30

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

#8 Updated by fixeria 3 months ago

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.

#9 Updated by neels 3 months ago

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().

#10 Updated by neels 3 months ago

4275
4276

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.

variant doing a Paging only after TA Request

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.

variant with early Paging, already sending TA in the first BSSMAP-LE message

#11 Updated by neels 3 months ago

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.

#12 Updated by neels 3 months ago

4278

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

#13 Updated by fixeria 3 months ago

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.

#14 Updated by fixeria 3 months ago

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!

#15 Updated by neels 2 months ago

  • % Done changed from 30 to 70

#16 Updated by neels 2 months ago

  • Checklist item Add notion of Lb interface to OsmoBSC (separate SCCP subsystem/user, configuration) set to Done
  • Checklist item Extend A interface set to Done

#17 Updated by laforge about 2 months ago

On Mon, Sep 07, 2020 at 10:29:30AM +0000, neels [REDMINE] wrote:

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.

That's a pity, but it would of course still work.

#18 Updated by neels about 1 month ago

  • Checklist item TTCN3 BSSAP-LE PerformLocationRequest / Response (successful, timeout, unsuccessful) set to Done
  • Checklist item TTCN3 BSSMAP-LE ConnectionOrientedInfo(BSSLAP TA Request) (successful, timeout, unsuccessful) set to Done

#19 Updated by neels about 1 month ago

  • Status changed from In Progress to Resolved
  • % Done changed from 70 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)