4 Main Concepts
23.2843GPPLocal Call Local Switch (LCLS)Release 17Stage 2TS
4.1 General
Local Call Local Switch provides the capability for the user plane to be locally switched (e.g. voice data in user plane is not backhauled to the CS core network) for calls that are generated and terminated by users that are served by the same BSS. The result is saving on transmission resource of the Abis and/or A interface.
Local Call Local Switch shall only be considered for a CS voice call and is transparent to the end user.
Figure 4.1.1 shows an example of Local Call Local Switching. It highlights only the main nodes and interfaces and differentiates between "originating" nodes and interfaces (oUE, oBTS, oMSC, oMGW, oAbis, oA) and "terminating" nodes and interfaces (tMSC, tMGW, tBTS, tUE, tAbis, tA). It also includes an Intermediate MSC server and MGW (iMSC, iMGW), which may be a (G)MSC server or other intermediate CN control node and its MGW.
Figure 4.1.1: Example of Local Call Local Switching
The "active" User Plane path is shown with a thick, solid blue line for the case that Local Switching is provided between two BTS’s, while the "inactive" User Plane path, i.e. the two Abis-links, the two A-links and the links within the Core Network are not carrying traffic and are therefore marked with thin, dotted blue lines. The Control Plane paths are shown in solid red lines.
Local Call Local Switch is attempted to be instantiated during call establishment. During this phase, negotiation for support of LCLS is performed within the Core Network and requests to correlate and connect the call legs are made to the BSS when LCLS is successfully negotiated. Interaction with existing supplementary services and handover/relocation are supported. Depending on the scenario this may require a break of an existing locally switched call where the voice data on user plane shall be routed via the core network, or a (re)establishment of a locally switched call where the voice data on user plane shall be locally switched in the BSS.
Local Call Local Switch may be supported on both TDM based A interface (AoTDM) and IP based A interface (AoIP).
Local Call Local Switch may be implemented on both a BICC based CS core network and a SIP-I based CS core network and therefore the main concepts that are defined within 3GPP TS 23.205 [2] and 3GPP TS 23.231 [3] respectively, also apply to Local Call Local Switch.
The MSC server is in charge of call control, supplementary services and gives permission (or denies) as to whether local switching may be applied. When the MSC server has granted the permission to apply LCLS, the BSC makes the final operation decision whether to establish LCLS (dependent on alignment of codecs, BTS’s supporting local switching, resource available, status of its BTS’s, the state of its radio legs).
4.2 LCLS Negotiation
4.2.1 General concept of LCLS negotiation
LCLS negotiation is required within the Core Network in order to determine if all of the MSC servers and intermediate nodes, including GMSC servers, in the call control path support and allow the activation of the LCLS functionality. LCLS negotiation may result in LCLS not being permitted for the following reasons:
– An MSC server node or intermediate node, including GMSC server node, has not been upgraded to support the LCLS functionality.
– It is prevented due to specific interactions e.g. Supplementary Services, operator determined restriction of LCLS, etc.
Additionally the LCLS negotiation may result in local call local switch being permitted but with certain configurations for user plane connectivity to the BSS depending on the network requirements, for example periodic signalling of pre-paid tones.
The LCLS negotiation Information Elements (LCLS-Negotiation Request, LCLS-Negotiation Response and LCLS-Configuration-Preference) are explicitly signalled on the Nc Interface. The LCLS-Negotiation Request IE and LCLS-Configuration-Preference IE are signalled during call establishment where the originating MSC server starts LCLS negotiation.
Depending on the support of LCLS, the MSC servers and intermediate nodes, including GMSC server, in the call control path may remove the LCLS-Negotiation Request IE and the LCLS-Configuration-Preference IE from further signalling on the Nc interface (e.g. if node does not support LCLS), or modify the contents of the LCLS-Negotiation Request IE (e.g. if LCLS is not allowed for the subscriber), or modify the LCLS-Configuration-Preference IE (e.g. if LCLS is allowed and bicasting is required during LCLS).
The following properties are signalled in the LCLS-Configuration-Preference Information Element for "LCLS is Allowed" to allow each node to indicate what level of user data connection it requires:
– Need_Receive_Forward = No/Yes; this indicates if the node needs to receive UL data from the originating UE.
– Need_Receive_Backward = No/Yes; this indicates if the node needs to receive UL data from the terminating UE.
– Need_Send_Forward = No/Yes; this indicates if the node needs to insert user data toward the terminating UE.
– Need_Send_Backward = No/Yes; this indicates if the node needs to insert user data toward the originating UE
The default value "No" means that no Core Network user data requirement exists. If a node receives the LCLS Negotiation Request IE and the LCLS-Configuration-Preference IE and if any of the parameters of the LCLS-Configuration-Preference IE is set to "Yes" it shall not change them; it may however change any parameter to "Yes". However in the backward direction, the received parameters of the LCLS Negotiation Response IE and the LCLS-Configuration-Preference IE shall not be modified.
The LCLS configuration preference that is negotiated on the core network path allows the oMSC server and the tMSC server to request the correct LCLS configuration from the BSS (see clause 4.6.2) on the originating and the terminating leg.
Table 4.2.1.1 shows all possible LCLS configuration preferences and the related LCLS configurations requested from the BSS on the originating and the terminating leg.
Table 4.2.1.1: Final LCLS configuration preference negotiated on the Core Network path and the related LCLS configuration requested from the BSS
|
Negotiated value of LCLS-Configuration-Preference IE |
Resulting LCLS configuration requested from oMSC to oBSS |
Resulting LCLS configuration requested from tMSC to tBSS |
||||
|---|---|---|---|---|---|---|
|
Need_ receive_ forward |
Need_ send_ backward |
Need_ receive_ backward |
Need_ send_ forward |
|||
|
1 |
No |
No |
No |
No |
connected both-way in the BSS |
connected both-way in the BSS |
|
2 |
No |
No |
No |
Yes |
connected both-way in the BSS |
connected both-way in the BSS and send access DL from the Core Network |
|
3 |
No |
No |
Yes |
No |
connected both-way in the BSS |
connected both-way in the BSS and bi-casted UL to the Core Network |
|
4 |
No |
No |
Yes |
Yes |
connected both-way in the BSS |
connected both-way in the BSS and bi-casted UL to the Core Network and send access DL from the Core Network |
|
5 |
No |
Yes |
No |
No |
connected both-way in the BSS and send access DL from the Core Network |
connected both-way in the BSS |
|
6 |
No |
Yes |
No |
Yes |
connected both-way in the BSS and send access DL from the Core Network |
connected both-way in the BSS and send access DL from the Core Network |
|
7 |
No |
Yes |
Yes |
No |
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 |
|
8 |
No |
Yes |
Yes |
Yes |
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 |
|
9 |
Yes |
No |
No |
No |
connected both-way in the BSS and bi-casted UL to the Core Network |
connected both-way in the BSS |
|
10 |
Yes |
No |
No |
Yes |
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, block local DL |
|
11 |
Yes |
No |
Yes |
No |
connected both-way in the BSS and bi-casted UL to the Core Network |
connected both-way in the BSS and bi-casted UL to the Core Network |
|
12 |
Yes |
No |
Yes |
Yes |
connected both-way in the BSS and bi-casted UL to 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 |
|
13 |
Yes |
Yes |
No |
No |
connected both-way in the BSS and bi-casted UL to the Core Network and send access DL from the Core Network |
connected both-way in the BSS |
|
14 |
Yes |
Yes |
No |
Yes |
connected both-way in the BSS and bi-casted UL to the Core Network and send access DL from the Core Network |
connected both-way in the BSS and send access DL from the Core Network, block local DL |
|
15 |
Yes |
Yes |
Yes |
No |
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 |
connected both-way in the BSS and bi-casted UL to the Core Network |
|
16 |
Yes |
Yes |
Yes |
Yes |
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 |
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 |
A Core Network node can optionally request that its related MGW isolates the access side termination from the network side termination in order to avoid any forwarding of data that it receives from another network entity (Core Network node or BSS). Isolation of the access termination is possible when user data need not be transported from the oBSS or the tBSS through the complete core network and in this case the LCLS configuration, which is sent to the oBSS or the tBSS based on the final LCLS configuration preference does not include the request to block local DL user data.
Figure 4.2.1.1 shows an example of how the user plane data can be configured as a result of the CN LCLS Negotiation. The precise LCLS configuration settings for each permutation of LCLS configuration preference options are specified in Table 4.2.1.1.
Figure 4.2.1.1: General concepts for LCLS configurations as a result of LCLS Negotiation.
Annex A provides further examples of LCLS negotiation in the CN and LCLS configuration in the BSS.
4.2.2 (void)
4.2.3 (void)
4.2.4 General concept of LCLS Configuration Preference Modification
LCLS Configuration preferences may be modified during an ongoing call.
The LCLS Configuration Change Request message may be signalled mid-call to attempt to establish LCLS or modify LCLS configuration preferences, for example for mid-call tones or announcements. Any core network node that requires change of the LCLS configuration preferences may initiate the LCLS Configuration Change Request.
Change of the LCLS configuration preferences may only be initiated after Answer.
NOTE 1: Prior to Answer message being returned the call is considered to be in the set-up phase and then subsequent LCLS Negotiation Response and LCLS-Configuration-Preference IEs can be sent within the call establishment messages (e.g. APM, ACM, CPG).
Only after the node has already handled the LCLS Negotiation procedure it may initiate a Change of the LCLS configuration preferences. If a node does not respond to the LCLS Negotiation then it shall not trigger a change of the LCLS configuration preferences at a later time in the call.
NOTE 2: Take Call Waiting for example, the call will trigger an LCLS Negotiation towards the called party since it is a call establishment from the calling parties perspective.
When receiving the LCLS Configuration Change Request message, the other nodes can only accept or reject the request without any modifications. If another node wishes to make further changes to the LCLS configuration preference settings it can initiate its own modification of the LCLS-Configuration-Preference IE settings after the ongoing change of the LCLS configuration preference procedure is completed.
The initiating node shall signal the LCLS Configuration Change Request message in the direction (originating leg or terminating leg or both – but only for Intermediate Node) that it requires the LCLS configuration preference settings to be changed.
If the intermediate node receives the LCLS Configuration Change Request message and it does not accept the requested changes to the LCLS configuration preferences it shall immediately return LCLS Configuration Change Request Acknowledge message indicating the same requested LCLS-Configuration-Preference IE settings and with the LCLS-Configuration-Change Result IE indicating rejection of the requested LCLS configuration change. Otherwise if the intermediate node accepts the requested changes to the LCLS configuration preferences it shall forward the received LCLS Configuration Change Request message containing the LCLS-Configuration-Change Request IE and the LCLS-Configuration-Preference IE to its subsequent (succeeding/preceding) node.
If the node which terminates the LCLS Configuration Change Request is the oMSC server or the tMSC server and it accepts the requested changes to the LCLS configuration preferences it shall return the LCLS Configuration Change Request Acknowledge message indicating the same requested LCLS configuration preferences and with the LCLS=Configuration-Change Result IE indicating acceptance of the LCLS Configuration Change Request.
If the node which terminates the LCLS Configuration Change Request is the oMSC server or the tMSC server and it does not accept the requested changes to the LCLS configuration preferences it shall return the LCLS Configuration Change Request Acknowledge message indicating the same requested LCLS configuration preferences and with the LCLS-Configuration-Change Result IE indicating rejection of the LCLS Configuration Change Request.
On receipt of the LCLS Configuration Change Request Acknowledge message from the succeeding/preceding node the intermediate node shall forward it to its subsequent (preceding/succeeding) node.
The change of the LCLS configuration preferences procedure is completed:
– for the node that receives the LCLS Configuration Change Request message when it sends the LCLS Configuration Change Request Acknowledge message;
– for the node which initiates the LCLS Configuration Change Request when it receives the LCLS Configuration Change Request Acknowledge message.
NOTE 3: If the node which initiates the LCLS Configuration Change Request receives the LCLS Configuration Change Request Acknowledge with the LCLS-Configuration-Change Result IE indicating rejection the node can trigger an LCLS Break as described in clause 7.2.1, specific applications such as insertion of tones or announcements will dictate this and are described in subsequent sections.
If LCLS Negotiation has occurred during call establishment and a handover occurs prior to answer which changes the LCLS configuration preferences (from a previously agreed "No" to a "Yes") then the node shall wait until after Answer before requesting the modification of the LCLS configuration preferences.
NOTE 4: Inter-MSC Handover during call establishment can result in an outstanding IAM – oMSC has sent IAM forward and then performs Inter-MSC Handover – which could result in the LCLS configuration preferences being out of alignment prior to Answer, the MSC can then defer sending the LCLS-Connect_Control request to its BSS if it wishes to prevent LCLS until it has performed a modification of the LCLS configuration preferences.
4.3 LCLS Call Leg Correlation
4.3.1 General
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.
NOTE: the inclusion of the LCLS-BSS-Status IE in the response indicates to the MSC server that the BSS supports LCLS.
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;
or
– 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
4.3.2.1 General
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
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.
NOTE: Intra-Network call detection within the tMSC server can minimize the processing in some BSS implementations.
4.3.2.3 Intra-Network Call Detection within the tBSS
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
4.3.3.1 General
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
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.
NOTE: Intra-BSS call detection within the tMSC server can minimize the processing in some BSS implementations.
4.3.3.3 Intra-BSS Call Detection within the tBSS
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
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
4.5.1 LCLS BSS Status between BSS and Core Network
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
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
4.6.1 General
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.
NOTE: During Handover procedures and LCLS Break procedures, the BSS may start to send the user plane data to the core network before all nodes in the routing path have updated their related LCLS status, see clauses 7 and 8.
4.6.2 LCLS Configuration
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.
NOTE: If BSS supports LCLS feature, then at least one of the LCLS configurations is required to be supported.
The usage of the LCLS Configuration IE is further detailed in clause 16.3.