Content for TS 23.284 Word version: 17.0.0

1… 4… 4.2… 4.3… 5 6… 6.3… 6.3.2 6.3.3 6.3.4 6.3.5 7… 7.2.4… 7.2.4.2 7.2.4.3 7.2.4.4 7.2.4.5 7.2.4.6 7.3… 7.3.4… 7.3.4.2 7.3.4.3 7.3.4.4 8… 8.2.3 8.3… 8.3.2 8.4… 8.4.1.1.7… 8.4.1.2… 8.4.2… 8.4.2.2… 8.4.5… 8.4.5.6 8.4.5.7 8.4.5.8… 9… 13… 13.4… 13.4.3… 13.4.4… 13.5… 13.6… 13.7… 14… 16… A… A.2…

4.3 LCLS Call Leg Correlation 4.3.1 General 4.3.2 Optional Intra-Network Call Detection 4.3.3 Optional Intra-BSS Call Detection 4.4 LCLS Connection Control 4.5 LCLS Status Reporting 4.5.1 LCLS BSS Status between BSS and Core Network 4.5.2 LCLS Status within the Core Network 4.6 User Plane when LCLS is Active 4.6.1 General 4.6.2 LCLS Configuration
...

4.3 LCLS Call Leg Correlation p. 18

4.3.1 General p. 18

LCLS call leg correlation is required in order to allow the BSS to identify that two call legs that are part of the same call are within the same BSS, and therefore can be correlated together to be a candidate for Local Call Local Switching.

The originating MSC server shall generate a Global Call Reference (GCR) Information Element which is a globally unique call identifier for the duration of the call and needs to be sent to all nodes in the routing path. The Global Call Reference is further detailed within clause 11.

The originating MSC server and the terminating MSC server shall include the GCR Information Element in the ASSIGNMENT REQUEST and HANDOVER REQUEST messages.

See Clause 6 for the detailed descriptions and related call flows for the call establishment procedures.

The GCR may additionally be signalled within the core network for supplementary service interaction with LCLS and Inter-MSC Handover, this is further detailed in Clause 13 and Clause 8 respectively.

On receipt of a GCR Information Element, if the BSS supports LCLS, the BSS shall store the GCR for each call leg until the call is released or that call leg is handed over to another BSS.

If the GCR and LCLS-Configuration Information Elements are included in the ASSIGNMENT REQUEST message, without the LCLS-Correlation-Not-Needed Information Element (see optional Intra-Network Detection, clause 4.3.2 and optional Intra-BSS Call Detection, clause 4.3.3), the BSS shall perform call leg correlation and send the LCLS-BSS-Status Information Element with the correct value within the ASSIGNMENT COMPLETE message.

If the GCR and LCLS-Configuration Information Elements are included in the HANDOVER REQUEST message, the BSS shall perform call leg correlation and send the LCLS-BSS-Status Information Element with the correct value within the HANDOVER COMPLETE messages.

If the GCR, LCLS-Configuration and LCLS-Correlation-Not-Needed Information Elements are included (see optional Intra-Network Call Detection, clause 4.3.2 and optional Intra-BSS Call Detection, clause 4.3.3) in the ASSIGNMENT REQUEST message, the BSS shall either:

not perform any call leg correlation, but only store the GCR for the assigned call leg and send the LCLS-BSS-Status Information Element with the value "Call Not Possible to be Locally Switched" within the ASSIGNMENT COMPLETE;

ignore the LCLS-Correlation-Not-Needed Information Element, store the GCR and perform call leg correlation, and send the LCLS-BSS-Status Information Element with the correct value within the ASSIGNMENT COMPLETE message.

4.3.2 Optional Intra-Network Call Detection p. 19

4.3.2.1 General p. 19

As an option during call establishment, the tMSC server or the tBSS may utilise the Network ID within the Global Call Reference in order to determine whether the call is an intra-network call (e.g. compare the Network ID within the GCR with the Network ID of the tMSC server).

4.3.2.2 Intra-Network Call Detection within the tMSC server p. 19

The terminating MSC-Server may perform an intra-network call detection as follows:

if the Network ID in the GCR is the same as the Network ID of the terminating MSC-Server it means that the call is an intra-network call and the terminating MSC-Server shall proceed as for the case if no Intra-Network Call Detection is performed i.e. including the GCR and LCLS-Configuration Information Elements, but not including the LCLS-Correlation-Not-Needed Information Element, within the ASSIGNMENT REQUEST message.
if the Network ID in the GCR is different from the Network ID of the terminating MSC-Server it means that the call is not an intra-network call and the terminating MSC-Server shall include GCR, LCLS-Configuration, and LCLS-Correlation-Not-Needed Information Elements within the ASSIGNMENT REQUEST message.

4.3.2.3 Intra-Network Call Detection within the tBSS p. 19

When receiving a GCR Information Element the tBSS may perform intra-network call detection as follows:

if the Network ID in the GCR is the same as the Network ID of the terminating BSS it means that the call is an intra-network call and the terminating BSS shall perform call leg correlation.
if the Network ID in the GCR is different from the Network ID of the terminating BSS it means that the call is not an intra-network call and the terminating BSS shall only store the GCR for the assigned call leg and does not need to perform call leg correlation.

The tBSS shall indicate the resulting outcome to the tMSC server in the LCLS-BSS-Status Information Element within the Assignment Complete.

4.3.3 Optional Intra-BSS Call Detection p. 19

4.3.3.1 General p. 19

As an option during call establishment, the tMSC server or tBSS may utilize the oBSS Node ID within the Call Reference ID of the GCR, in order to determine whether the call is an intra-BSS call (e.g. compare the oBSS Node ID with the tBSS Node ID) as described below.

NOTE:

After the oMSC server has generated the GCR IE, an Inter-BSS handover may occur at the originating side, therefore the encapsulated BSS ID is no longer the same as the BSS ID of the new Target BSS (see also clause 8.4.1.1). Due to that, the result of the "BSS ID Pre-Check" procedure may be incorrect leading to "LCLS-Correlation-Not-Needed" indication being sent to the tBSS whilst the new target BSS could in fact be the same as the tBSS. If the tBSS does not perform the correlation of the GCR then the information in the Assignment Complete message may also be inaccurate (the LCLS-BSS-Status IE may indicate "call not possible to be locally switched" instead of "call not yet locally switched"). If the tMSC server indicates "LCLS-Correlation-Not-Needed" and the Inter-BSS handover has occurred at the oUE into the same BSS as the tUE but after signalling the GCR IE and the tBSS does perform full GCR correlation then the LCLS-BSS-Status will indicate accurately that the call can be locally switched.

4.3.3.2 Intra-BSS Call Detection within the tMSC server p. 19

The terminating MSC-Server performs intra-BSS call detection as follows:

if the oBSS Node ID in the GCR is the same as the terminating BSS Node ID, the terminating MSC-Server shall proceed as for the case when no Intra-BSS Call Detection is performed i.e. including the GCR and LCLS-Configuration Information Elements, but not including the LCLS-Correlation-Not-Needed Information Element, in the ASSIGNMENT REQUEST message (if LCLS is otherwise allowed from CN point of view).
if the oBSS Node ID in the GCR is different from the terminating BSS Node ID, the terminating MSC-Server shall include the GCR, LCLS-Configuration, and LCLS-Correlation-Not-Needed Information Elements within the ASSIGNMENT REQUEST message.

4.3.3.3 Intra-BSS Call Detection within the tBSS p. 20

When receiving a GCR Information Element the tBSS may perform intra-BSS call detection as follows:

if the oBSS Node ID in the GCR is the same as the BSS Node ID of the terminating BSS the terminating BSS shall perform call leg correlation.
if the oBSS Node ID in the GCR is different from the BSS Node ID of the terminating BSS the terminating BSS shall only store the GCR for the assigned call leg and does not perform call leg correlation.

The tBSS shall indicate the resulting outcome to the tMSC server in the LCLS-BSS-Status Information Element within the ASSIGNMENT COMPLETE message.

4.4 LCLS Connection Control p. 20

LCLS connection control enables the Core Network to indicate to the BSS when the call is requested to be locally switched within the BSS or not. LCLS connection control is explicitly signalled on the A interface during Call Establishment, Handover and LCLS Break/(Re)Establishment using the LCLS_CONNECT_CONTROL message.

Within the LCLS_CONNECT_CONTROL message, the LCLS-Connection-Status-Control Information Element shall indicate whether the BSS is requested to:

establish local switching (connect);
do not establish local switching (this value is used for example in call hold to explicitly prevent LCLS connection);
bi-cast at handover (This is a temporary status of an LCLS connection which is being broken during handover. The setting applies to the call leg which is not being handed over. After handover has been completed and LCLS is broken, the BSS shall adopt the previous LCLS-Connection-Status-Control value i.e. "connect" unless explicitly changed by the MSC Server. This means that any subsequent handover of the previous call leg back into the same BSS will enable LCLS without any change of LCLS-Connection-Status to this call leg). The temporary status settings shall be cleared by the BSS if set during a handover and the handover fails or is rejected.
receive DL data at handover (This is a temporary status of an LCLS connection which is being broken during handover. The setting applies to the call leg which is not being handed over. After handover has been completed and LCLS is broken, the BSS shall adopt the previous LCLS-Connection-Status-Control value i.e. "connect" unless explicitly changed by the MSC Server. This means that any subsequent handover of the previous call leg back into the same BSS will enable LCLS without any change of LCLS-Connection-Status to this call leg). This setting does not change the UL bicasting and assumes the call leg to which it is applied is bicasting UL at handover in addition. The termporary status settings shall be cleared by the BSS if set during a handover and the handover fails or is rejected.
release LCLS for the locally switched call (Release LCLS).

LCLS through-connection is established when the BSS receives, on both call legs, the LCLS-Connection-Status-Control IE to allow and request LCLS to be established.

The detailed call flows and procedures for signalling of the LCLS-Connection-Status-Control IE during Call Establishment, LCLS Break/(Re)Establishment, and Handover are defined in clauses 6, 7, and 8 respectively.

The LCLS_CONNECT_CONTROL message and the usage of the LCLS-Connection-Status-Control IE are further detailed in clause 16.3.

4.5 LCLS Status Reporting p. 21

4.5.1 LCLS BSS Status between BSS and Core Network p. 21

LCLS BSS status is required between the BSS and the Core Network in order to keep the originating MSC server and the terminating MSC server updated of the LCLS status in the respective BSS.

The LCLS-BSS-Status Information Element is used to indicate whether:

the call is locally switched with requested LCLS configuration
the call is local but not yet locally switched (this indicates that the call has been correlated but not locally switched)
the call is not possible to be locally switched (this indicates that the call has been determined not to be a local call)
the call is no longer locally switched
the requested LCLS-Configuration is not supported

The inclusion of the LCLS-BSS-Status Information Element in responses to the MSC server indicates support of LCLS feature by the BSS. The usage of the LCLS-BSS-Status Information Element is further detailed in clause 16.3.

The LCLS-BSS-Status IE is explicitly signalled on the A interface during Call Establishment, LCLS Break/(Re)Establish LCLS, and Handover procedures. See clauses 6, 7 and 8 respectively.

The LCLS-BSS-Status IE is also signalled explicitly in the LCLS_NOTIFICATION message on the A interface, triggered by the BSS to notify the core network of any LCLS status changes in the BSS, e.g. BSS Initiated LCLS Break. The LCLS_NOTIFICATION message is further detailed in clause 16.3.

4.5.2 LCLS Status within the Core Network p. 21

LCLS status is required within the Core network in order to update all of the (G)MSC server and intermediate nodes in the call control path of the LCLS status of the call.

LCLS-Status Information Element is explicitly signalled on the Nc interface during Call Establishment, LCLS Break/(Re)Establish, and Handover procedures when the LCLS status changes from before and after handover. See clauses 6, 7, and 8 respectively. The LCLS-Status is either indicated as changed status (LCLS-Status IE) to a change in the BSS or it may be indicated as request to change the LCLS-Status (LCLS-Status-Change IE) due to handover or supplementary service invocation for example.

The LCLS-Status IE can indicate the following statuses:

the call is LCLS connected;
the call is not LCLS connected;
the call is LCLS feasible but not yet connected.

The LCLS-Status-Change IE can indicate the following statuses:

LCLS is to be released;
LCLS is to be released due to handover;
LCLS is to be re-connected after LCLS break;
Indicate DL data after handover - Handover Detected.

The MSC Servers shall only generate or forward the LCLS Status IE through the CN if there is a change to the current CN status (i.e. there is not a one to one mapping of the LCLS-BSS Status and the LCLS Status in the CN). The usage of these elements: the LCLS Status IE signalled in the LCLS_STATUS_UPDATE message and the LCLS-Status-Change IE which is signalled in the LCLS_STATUS_CHANGE_REQUEST message and LCLS_STATUS_CHANGE_REQUEST ACKNOWLEDGEMENT message is further detailed in clause 16.1.

4.6 User Plane when LCLS is Active p. 22

4.6.1 General p. 22

When LCLS has been established for a call, the voice data on the user plane is locally switched within the BSS. When the call is locally switched the core network shall assume that no user plane data will be received from the BSS for the duration of the locally switched call unless explicitly requested via the LCLS-Configuration IE.

When user plane data is required to be inserted by the core network, e.g. supplementary services, unless previously negotiated via the LCLS-Negotiation IE (see clause 4.2) an LCLS Break procedure shall precede the insertion of user plane data.

4.6.2 LCLS Configuration p. 22

LCLS configuration is required in order to allow the Core Network to indicate to the BSS the LCLS connection preference.

The LCLS Configuration Information Element is explicitly signalled on the A interface on a per call leg basis during Call Establishment and Handover procedures or at any time during the call using the LCLS_CONNECT_CONTROL message. See clauses 6 and 8 respectively. It is used to indicate if the local call shall be:

connected both-way in the BSS (basic LCLS connection)
connected both-way in the BSS and bi-casted UL to the Core Network
connected both-way in the BSS and send access DL from the Core Network (BSS may combine or replace local DL data with DL data from the Core Network)
connected both-way in the BSS and send access DL from the Core Network, block local DL
connected both-way in the BSS and bi-casted UL to the Core Network and send access DL from the Core Network (BSS may combine or replace local DL data with DL data from the Core Network)
connected both-way in the BSS and bi-casted UL to the Core Network and send access DL from the Core Network, block local DL (BSS shall block local DL data but continue send UL data locally)

If the BSS does not support a certain configuration this shall be indicated with the LCLS-BSS-Status IE set to "requested LCLS configuration is not supported" to the MSC Server.

The usage of the LCLS Configuration IE is further detailed in clause 16.3.