Content for TS 23.284 Word version: 18.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.2 LCLS Negotiation 4.2.1 General concept of LCLS negotiation 4.2.4 General concept of LCLS Configuration Preference Modification
...

4.2 LCLS Negotiation p. 13

4.2.1 General concept of LCLS negotiation p. 13

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	Resulting LCLS configuration requested from oMSC to oBSS	Resulting LCLS configuration requested from tMSC to tBSS
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.

Copy of original 3GPP image for 3GPP TS 23.284, Fig. 4.2.1.1: General concepts for LCLS configurations as a result of LCLS Negotiation.

Figure 4.2.1.1: General concepts for LCLS configurations as a result of LCLS Negotiation.
(⇒ copy of original 3GPP image)

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 p. 17

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.

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.

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.

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.