5 Procedures applicable to use of BSSAP-LE

09.313GPPBase Station System Application Part LCS Extension (BSSAP-LE)Location Services (LCS)Release 1999TS

5.1 Location Request

The Location Request procedure is applicable to the Lb and Ls interfaces. Its purpose is to obtain a location estimate for a target MS that is already in dedicated mode. It is also used to provide an MS with LCS assistance data or with a deciphering key for LCS broadcast assistance data. The initiator of a location request may be either the serving BSC or the visited MSC for the MS. The procedure makes use of SCCP connection oriented signaling on the Lb and Ls interfaces.

5.1.1 Successful Operation

The initiator of the location request (VMSC or serving BSC) sends a BSSMAP-LE Perform Location Request to the SMLC associated with the current serving cell for the target MS. The message contains the following mandatory (M), conditional (C) and optional (O) information, where conditional parameters are required if available.

Location Type (M)

Cell Identifier (M)

Classmark Information Type 3 (C)

LCS Client Type (C)

Chosen Channel (C)

LCS Priority (C)

LCS QoS (C)

Requested GPS Assistance Data (C)

BSSLAP APDU (C)

If requested, the SMLC performs positioning of the target MS using a particular position method or a combination of more than one positioning method. If the Classmark Information Type 3 IE is not present, the SMLC shall instigate only network based positioning methods (e.g. TOA or TA but not GPS or E-OTD). Alternatively, if requested otherwise, the SMLC may provide positioning assistance data to the MS. The SMLC may invoke the following other BSSAP-LE procedures to perform these procedures:

connection oriented information transfer

connectionless information transfer

LMU connection establishment

LMU connection release

DTAP-LE information transfer

For an SMLC accessed over the Lb interface by a BSC initiator, additional procedures defined in 3GPP TS 04.08 and 3GPP TS 08.08 may also be performed. If a location estimate was requested and was subsequently obtained, the SMLC shall return a BSSMAP-LE Perform Location Response to the initiator of the location request (serving BSC or VMSC). This message contains the following mandatory, conditional and optional parameters.

Location Estimate (M)

Positioning Data (C)

Restrictions on the geographic shape encoded within the Location Estimate parameter may exist for certain LCS client types. The SMLC shall comply with any restrictions defined in GSM Release 99 and 3G Release 99 and, in a particular country, with any restrictions defined for a specific LCS client type in relevant national standards. For example, in the US, national interim standard TIA/EIA/IS-J-STD-036 restricts the geographic shape for an emergency services LCS client to minimally either an “ellipsoid point” or an “ellipsoid point with uncertainty circle and confidence” as defined in 3G TS 23.032.

If assistance data was instead requested for an MS and the SMLC was able successfully to transfer this to the MS, the SMLC shall return a BSSMAP-LE Perform Location Response to the initiator of the location request (serving BSC or VMSC). This message shall contain no parameters. The absence of an LCS Cause parameter in this case implies that the transfer was successful.

Otherwise, if a deciphering key was requested for LCS broadcast assistance data and the SMLC has access to the appropriate keys, the SMLC shall return a BSSMAP-LE Perform Location Response to the initiator of the location request (serving BSC or VMSC). This message contains the following mandatory parameters.

Deciphering Keys (M)

5.1.2 Unsuccessful Operation

If the SMLC is unable to obtain any of the location information requested or if requested LCS assistance data could not be transferred or requested deciphering keys for broadcast assistance data could not be returned, the SMLC shall return a BSSMAP-LE Perform Location Response to the initiator of the Location Request carrying the following parameters:

LCS Cause (M)

Positioning Data (O)

If assistance data or deciphering keys for a specific positioning method is not supported in the network or in the location area, the SMLC shall indicate this with LCS Cause value "Position method failure" accompanied with diagnostic value "Position Method Not Available in Network" or "Position Method Not Available in Location Area".

5.1.3 Abnormal Conditions

If an ongoing location request is preempted at the initiator by an inter-BSC handover or if the main signaling link to the target MS is lost or released or if there is a timeout waiting for the positioning response, the initiator shall send a BSSMAP-LE Perform Location Abort to the SMLC containing the following parameters.

LCS Cause (M)

On receipt of this message, the SMLC shall stop positioning of the target MS and may release any resources (e.g. LMUs) previously allocated. If the SMLC has not yet returned a BSSMAP-LE Perform Location Response to the initiator, it shall return this message containing an LCS Cause indicating an abort and, optionally, positioning data. The initiator shall then release the SCCP connection. If the SMLC cannot proceed with positioning due to some protocol violation or error condition (e.g. inter-BSC handover indication received from the serving BSC), it shall return a BSSMAP-LE Perform Location Response to the initiator containing an LCS cause and, optionally, positioning data. The initiator need not reply at the BSSAP-LE level to this message. However, the initiator may return a BSSMAP-LE perform Location Abort which shall not be treated as an error by the SMLC.

5.1.4 Overload

If the SMLC is in an overload condition, it may reject a BSSMAP-LE Perform Location request by returning a BSSMAP-LE Perform Location response containing an LCS Cause parameter indicating congestion. The initiator of the location service request (MSC or BSC) may reduce the frequency of future location service requests until rejection due to overload has ceased. In reducing the frequency of location service requests, an MSC or BSC shall reduce lower priority requests, to zero if necessary, before reducing the frequency of higher priority requests. An SMLC shall similarly reject location service requests of a lower priority, to zero if necessary, due to overload before rejecting location service requests of a higher priority. An SMLC in an overload condition may optionally employ the following procedures to alleviate overload:

a) Allow higher priority location service requests to preempt lower priority requests for which location service procedures are already in progress

b) Abort lower priority location service requests already in progress.

c) Reduce the supported QoS for lower priority requests for a location estimate – e.g. by reducing accuracy or increasing response time

d) Employ MS based positioning methods, where supported by the target MS and SMLC, rather than MS assisted or network based methods (except TA).

The priority of a location service request shall be defined according to the value in the LCS Priority parameter. If this parameter is absent in a BSSMAP-LE Perform Location request, the lowest priority shall be assumed.

5.2 Connection Oriented Information Transfer

The Connection Oriented Information transfer procedure is applicable to the Lb and Ls interfaces. It enables both way transfer of BSSLAP messages between an SMLC and the BSC serving a target MS. The initiator of the procedure can be either the BSC serving the target MS, the visited MSC for the target MS or the SMLC. The procedure is only valid while a location request procedure for the target MS is ongoing. The procedure makes use of SCCP connection oriented signaling on the Lb and Ls interfaces and uses the same SCCP connection as the location request procedure for the particular target MS.

5.2.1 Successful Operation

An SMLC, MSC or BSC with a BSSLAP message or message segment to transfer concerning a particular target MS sends a BSSMAP-LE Connection Oriented Information message to a recipient carrying the following parameters:

BSSLAP APDU (M)

Segmentation (C)

If the sender is an NSS based SMLC, the message is transferred to the VMSC for the target MS. The recipient MSC shall then transfer the message to the serving BSC using procedures defined in 3GPP TS 08.08.

If the sender is a BSS based SMLC, the message is transferred to the serving BSC for the target MS. The BSC shall then perform the positioning operation requested by the BSSLAP APDU (refer to 3GPP TS 08.71). If the BSSLAP APDU contains an RRLP APDU, the BSC shall transfer this to the target MS.

If the sender is a BSC or MSC and the intended recipient is the SMLC for a target MS, the message is transferred to the SMLC. The SMLC shall then perform interpretation of the BSSLAP APDU.

5.2.2 Abnormal Conditions

At an intermediate entity, if a received BSSMAP-LE Connection Oriented Information message contains unrecognized information or if the message cannot be sent on, the message shall be discarded.

At the receipient entity. if a received BSSMAP-LE Connectioin Oriented Information message contains invalid or unrecognized information as defined for BSSAP-LE, any ongoing positioning procedure shall be terminated and associated resources may be released. If the receipient is a BSC, the SMLC shall be notified – e.g. using a BSSLAP Reject or Abort. If the receipient is an SMLC, a new positioning attempt (e.g. using a different position method) may be started.

5.2.3 Segmentation

The Segmentation parameter shall not be included if the BSSLAP message is not segmented.

If the size of an embedded BSSLAP message is too large to fit into one BSSMAP-LE message, the sending entity divides the BSSLAP message to a necessary number of BSSMAP-LE messages each containing a BSSLAP APDU IE and a Segmentation IE. In the BSSLAP APDU IE it includes as many octets as possible.

The segmentation IE contains a segment number field and an indication of the final segment. Message identification shall not be used. The order number of a segment in the Segment Number field in the Segmentation IE is incremented by one starting from zero, i.e. the value is 0 for the first segment, 1 for the next and so on. The receiving entity may use the segment number in order to recognize the start of a new BSSLAP message and verify that all segments were reliably transferred.

In case of handover interrupting the information transfer procedure, the exception procedures described in 3GPP TS 03.71 shall be used.

5.3 Connectionless Information Transfer

The Connectionless Information transfer procedure is applicable to the Lb, Ls and Lp interfaces. It enables both way transfer of LLP messages between an SMLC and a Type B LMU. The procedure also enables both way transfer of SMLCPP messages between two SMLCs. The initiator of the procedure can be a BSC, MSC or SMLC. The procedure makes use of SCCP connectionless signaling.

5.3.1 Successful Operation

An SMLC, MSC or BSC needing to transfer an LLP message concerning a Type B LMU or an SMLCPP message sends a BSSMAP-LE Connectionless Information message to a recipient carrying the following parameters:

Source Entity (M)

Destination Entity (M)

APDU (M)

Segmentation (C)

Return Error Request (O)

The source entity identifies the sender. The recipient entity identifies the final destination. The Segmentation IE provides segmentation and message identification for a segmented APDU. The Return Error Request may be included to request notification in the event of unsuccessful transfer and indicate the type of notification needed. If the recipient entity is not the final destination, the recipient shall transfer the BSSMAP-LE Connectionless Information message to either the final destination or an intermediate MSC or BSC capable of onward transfer to the final destination.

5.3.2 Unsuccessful Operation

If the message cannot be transferred by an intermediate entity or destination entity (e.g. reassembly of a segmented message fails) and the Return Error Request is not included, the message shall be discarded. If the Return Error Request is included, the intermediate or destination entity shall, depending on the Return Error Request type, send a BSSMAP-LE Connectionless Information message to, or towards, the original source containing the following parameters:

Source Entity (M)

Destination Entity (M)

APDU (C)

Segmentation (C)

Return Error Cause (M)

The Source entity shall indicate the Destination Entity in the original received message. The Destination Entity shall indicate the Source Entity in the original message. The Return Error cause shall indicate the reason for unsuccessful transfer. The APDU and Segmention IEs shall, depending on the the Return Error Request type, contain any originally received APDU and Segmentation IEs, respectively.

If a received BSSMAP-LE Connectionless Information message containing a Return Error Cause cannot be transferred by an intermediate entity, it shall be discarded with no return error message.

5.3.3 Abnormal Conditions

At an intermediate entity, if a received BSSMAP-LE Connectionless Information message contains unrecognized or invalid information, the message shall be discarded.

At the recipient entity. if a received BSSMAP-LE Connectioinless Information message contains invalid or unrecognized information as defined for BSSAP-LE, the message shall be discarded.

5.3.4 Segmentation

The Segmentation parameter shall not be included if the APDU is not segmented.

If the size of an APDU containing an embedded SMLCPP message is too large to fit into one BSSMAP-LE message, the sending entity divides the SMLCPP message to a necessary number of BSSMAP-LE messages each containing an APDU IE and a Segmentation IE. In the APDU IE it includes as many octets as possible

The segmentation IE contains a segment number, an indication of the final segment and the message ID. The order number of a segment in the Segment Number field in the APDU IE is incremented by one starting from zero, i.e. the value is 0 for the first segment, 1 for the next and so on. The receiving entity recognizes that a segment is missing or duplicated, when:

– There is more than one segment with the same segment number and same Message ID.

– The segment number does not increase by steps of one starting from zero.

If the recipient recognizes a missing or duplicated element, it shall discard the entire message (i.e. all received segment with the message ID).

The message identity in the Message ID field in the APDU IE is used to recognize a particular message to which that segment belongs. The sending entity can select any of the available values (0-65535) that is not currently used between it and the receiving entity.

If an APDU segment is received with Return Errror cause IE (due to invocation of the return error option), reassembly does not apply and the APDU segment and error cause maybe returned to the original source application.

5.4 LMU Connection Establishment

The LMU Connection Establishment procedure is applicable to the Ls interface. Its purpose is to establish a signaling connection between an SMLC and Type A LMU via the visted MSC for the LMU. The procedure can be initiated by either the SMLC or MSC. The procedure makes use of SCCP connection oriented signaling on the Ls interface.

5.4.1 LMU Connection Establishment initiated by the SMLC

5.4.1.1 Successful Operation

The SMLC sends a BSSMAP-LE LMU Connection Request message to the VMSC for the LMU. This message contains the following parameters.

IMSI (M)

Sender Address (O)

Security (C)

The IMSI identifies the LMU. The sender address, if included, identifies the SMLC. The Security parameter shall be included if authentication or ciphering of the LMU are required. On receipt of this message, the MSC shall attempt to establish a signalling link to the LMU (refer to 3GPP TS 03.71). Authentication and ciphering shall be invoked if requested by the SMLC. Once the signaling link has been established, the MSC shall return a BSSMAP-LE LMU Connection Accept to the SMLC with the following parameters.

Call Number (O)

The call number shall be included if the MSC has the capability to support signaling to an LMU using a traffic channel (refer to 3GPP TS 03.71).

5.4.1.2 Unsuccessful Operation

If the LMU is not recognized in the MSC (e.g. no VLR record) or a signaling link cannot be setup to the LMU (e.g. paging of the LMU fails) or authentication or ciphering cannot be performed when requested by the SMLC, any signaling link to the LMU shall be released, if not required for other MM or CM procedures and a BSSMAP-LE LMU Connection Reject shall be returned to the SMLC with the following parameters.

Reject Cause (M).

5.4.1.3 Abnormal Conditions

If the SMLC or MSC detects release of the SCCP connection on the Ls interface for an LMU, the connection establishment procedure shall be considered to have failed and any associated resources may be released.

5.4.2 LMU Connection Establishment initiated by the MSC

5.4.2.1 Successful Operation

The MSC shall initiate the LMU connection establishment procedure when no LMU connection to the SMLC currently exists and the MSC receives a CM Service Request from the LMU specifying the LCS service. The MSC shall then send a BSSMAP-LE LMU Connection Request message to the SMLC associated with either the IMSI or current cell location of the LMU. This message shall contain the following parameters.

IMSI (M)

Sender Address (M)

Call Number (C)

The IMSI identifies the LMU. The sender address identifies the MSC. The call number shall be included if the MSC has the capability to support signaling to an LMU using a traffic channel (refer to 3GPP TS 03.71). On receipt of this message, the SMLC shall return a BSSMAP-LE LMU Connection Accept to the MSC with the following parameters.

Security (C)

The Security parameter shall be included if authentication or ciphering of the LMU are required On receipt of this message, the MSC shall perform authentication and/or ciphering if requested by the SMLC and shall complete the establishment of an MM connection to the LMU to support LCS.

5.4.2.2 Unsuccessful Operation

If the LMU is not recognized in the SMLC or a signaling connection cannot be supported (e.g. due to congestion), a BSSMAP-LE LMU Connection Reject shall be returned to the MSC with the following parameters.

Reject Cause (M)

The MSC shall then reject the CM service request from the LMU.

5.4.2.3 Abnormal Conditions

If the SMLC or MSC detects release of the SCCP connection on the Ls interface for an LMU, the connection establishment procedure shall be considered to have failed and any associated resources may be released.

5.5 LMU Connection Release

The LMU Connection Release procedure is applicable to the Ls interface. Its purpose is to release a signaling connection between an SMLC and Type A LMU. The procedure can be initiated by either the SMLC or MSC. The procedure makes use of SCCP connection oriented signaling on the Ls interface.

5.5.1 LMU Connection Release initiated by the SMLC

5.5.1.1 Successful Operation

The SMLC sends a BSSMAP-LE LMU Connection Release message to the VMSC for the LMU. This message contains the following parameters.

Release Cause (M)

On receipt of this message, the MSC shall release the main signaling link to the LMU unless required for other ongoing MM and CM procedures in the MSC. The MSC shall also initiate release of the SCCP connection to the SMLC for the LMU.

5.5.1.2 Abnormal Conditions

The SMLC may initiate release of the signaling connection to an LMU by initiating release of the SCCP connection for the LMU to the MSC. The MSC shall then release the main signaling link to the LMU unless required for other ongoing MM or CM procedures.

5.5.2 LMU Connection Release initiated by the MSC

5.5.2.1 Successful Operation

The MSC shall initiate release of an LMU connection to an SMLC if the main signaling link to the LMU is released. The MSC sends a BSSMAP-LE LMU Connection Release message to the SMLC for the LMU. This message contains the following parameters.

Release Cause (M)

On receipt of this message, the SMLC should initiate release of the SCCP connection to the MSC for the LMU.

5.5.2.2 Abnormal Conditions

The MSC may initiate release of the signaling connection between an SMLC and LMU by initiating release of the SCCP connection for the LMU to the SMLC.

5.6 DTAP-LE Information Transfer

The DTAP-LE Information transfer procedure is applicable to the Ls interface. It supports bothway LLP message transfer between an NSS based SMLC and Type A LMU. The procedure is only valid when a signaling connection between an SMLC and Type A LMU has been established. The procedure uses SCCP connection oriented signaling using the SCCP connection previously established between the SMLC and MSC when the signaling connection between the SMLC and LMU was established.

5.6.1 DTAP-LE Information Transfer Initiated by the SMLC

The SMLC initiates the procedure when it has an LLP message to transfer to a type A LMU. The message may first be segmented. The SMLC shall then transfer each LLP segment to the MSC inside a DTAP-LE REGISTER, FACILITY or RELEASE COMPLETE message. The usage of these messages is as defined in 3GPP TS 04.71. The MSC relays each DTAP-LE message to the LMU.

5.6.2 DTAP-LE Information Transfer Initiated by the MSC

The MSC initiates the procedure when a DTAP message is received from an LMU containing the LCS protocol discriminator. The MSC then relays the DTAP message to the SMLC.

5.7 Reset

The reset procedure is an optional procedure within a PLMN applicable to the Lb and Ls interfaces. It enables an SMLC, MSC or BSC that has undergone a failure with loss of memory of LMU signalling connections and location service transactions to indicate this to a partner entity (SMLC, MSC or BSC). The recipient entity can then release its own connection and transaction resources. The reset procedure may not be applicable when only a limited part of an SMLC, MSC or BSC has suffered a failure, since error recovery procedures specific to individual connections and transactions may then be used.

5.7.1 Normal Operation

In the event of a failure at an SMLC, MSC or BSC that results in the loss of LMU connection information and location service information, a Reset message may be sent to the partner SMLC, MSC or BSC across the Lb or Ls interface. The message carries no parameters and is sent using connectionless SCCP procedures. The sending entity shall ensure that all information on LMU connections and location service transactions to the other entity is reinitialized to indicate no existing connections and transactions.

On receiving a Reset message, the recipient SMLC, MSC or BSC shall clear all references and state information for LMU connections and location service transactions to the sending entity and shall release any associated resources including, in the case of a recipient MSC or BSC, any signaling connections or circuit connections to LMUs controlled by a sending SMLC. The recipient entity shall then return a Reset Acknowledge message.

For a reset on the Lb interface where the SMLC and BSC support circuit connections to LMUs (in addition to signaling connections), the entity that does not control assignment of circuits shall initiate blocking procedures (Block or Circuit Group Block procedure as defined in 3GPP TS 08.08) for all circuits that are locally blocked on its own side. The initiation of blocking may occur before sending or receipt, whichever applies, of the Reset Acknowledge.

5.7.2 Abnormal Conditions

If an initiating SMLC, MSC or BSC receives no response to a Reset message following an O&M administered time period, it shall resend the Reset message. For successive no response conditions, sending shall occur a maximum of “n” times, where “n” is an O&M administered parameter. Following “n” unsuccessful, reset attempts, the procedure shall be terminated and maintenance shall be informed.