Feature #4597
closedLb interface and basic SMLC support
Added by laforge almost 4 years ago. Updated over 3 years ago.
100%
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
Files
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 |
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
Updated by laforge over 3 years 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.
Updated by laforge over 3 years ago
- Related to Feature #4598: Implement minimalistic SMLC added
Updated by laforge over 3 years 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.
Updated by laforge over 3 years 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
Updated by neels over 3 years ago
- Status changed from New to In Progress
Taking over.
(wondering why %Done says 100, but four checklist items are unchecked.)
Updated by neels over 3 years 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
Updated by fixeria over 3 years 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.
Updated by neels over 3 years 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().
Updated by neels over 3 years ago
- File location_services_ta.png location_services_ta.png added
- File location_services_ta2.png location_services_ta2.png added
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.
Updated by neels over 3 years 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.
Updated by neels over 3 years ago
- File BSSMAP-LE_Perf_Loc_Req.pcapng BSSMAP-LE_Perf_Loc_Req.pcapng added
- File BSSMAP-LE_Perf_Loc_Req.png BSSMAP-LE_Perf_Loc_Req.png added
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
Updated by fixeria over 3 years 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.
Updated by fixeria over 3 years 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!
Updated by neels over 3 years 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
Updated by laforge over 3 years 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.
Updated by neels over 3 years 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
Updated by neels over 3 years ago
- Status changed from In Progress to Resolved
- % Done changed from 70 to 100