14.6.2 Handling of tones or announcements during an LCLS call
23.2843GPPLocal Call Local Switch (LCLS)Release 17Stage 2TS
14.6.2.1 GMSC Server or intermediate node requiring temporary send access to apply tone or announcement
A GMSC Server or intermediate node wishing to insert a tone or announcement may signal LCLS Configuration Change Request message with LCLS-Configuration-Preference IE setting "Need Send Backward = yes" if it needs to insert a tone or announcement towards the originating subscriber or "Need Send Forward = yes" if it needs to insert a tone or announcement towards the terminating subscriber. When GMSC Server sends the LCLS Configuration Change Request message it shall start LCLS_configuration_modification timer.
NOTE: The (G)MSC Server or intermediate node only needs to signal the LCLS Configuration Change Request message in the direction in which it wishes to apply the tone or announcement. The other LCLS-Configuration-Preference IE settings remain unchanged.
When the (G)MSC receives the LCLS Configuration Change Request Acknowledge message it shall stop the LCLS_configuration_modification timer. If the received LCLS-Configuration-Change Result IE indicates acceptance of the requested LCLS Configuration change it shall proceed to insert its tone or announcement as per a normal call handling.
Otherwise, if the received LCLS-Configuration-Change Result IE indicates the requested LCLS Configuration change is rejected or if the LCLS_configuration_modification timer expires, the (G)MSC Server shall perform an intermediate node initiated LCLS break as described in clause 7.2.3 and when the LCLS break is complete shall apply the tone or announcement. On the completion of the tone or announcement if LCLS break occurred the LCLS may be re-established as described in clause 7.3.3.
On completion of the tone or announcement if LCLS break was not required the (G)MSC Server may signal LCLS-Configuration Change Request message with LCLS-Configuration-Preference IE indicating "Need Send Backward= no" or "Need Send Forward = no" towards preceding/succeeding node respectively. If the (G)MSC Server sends the LCLS Configuration Change Request message it shall start the LCLS_configuration_modification timer. At reception of the LCLS Configuration Change Request Acknowledge message the (G)MSC Server shall stop the LCLS_configuration_modification timer. If the LCLS_configuration_modification timer expires, the (G)MSC Server shall perform an intermediate node initiated LCLS break as described in clause 7.2.3.
The appropriate LCLS configurations which result from the new LCLS-Configuration-Preference settings are specified in Table 4.2.1.1.
14.6.2.2 oMSC Server
An oMSC Server wishing to insert a tone or announcement towards the terminating UE may signal LCLS Configuration Change Request message with LCLS-Configuration-Preference IE set to "Need Send Forward = yes". When oMSC Server sends the LCLS Configuration Change Request message it shall start LCLS_configuration_modification timer.
NOTE: The other LCLS-Configuration-Preference settings remain unchanged.
When the oMSC Server receives the LCLS Configuration Change Request Acknowledge message it shall stop the LCLS_configuration_modification timer. If the received LCLS-Configuration-Change Result IE indicates acceptance of the requested LCLS Configuration change then it shall proceed to insert its tone or announcement as per a normal call handling. Otherwise, if the received LCLS-Configuration-Change Result IE indicates the requested LCLS configuration change is rejected or if the LCLS_configuration_modification timer expires, the oMSC Server shall perform a MSC initiated LCLS break as described in clause 7.2.1 and once the LCLS break is complete then begin applying the tone or announcement. On the completion of the tone or announcement LCLS may be re-established as described in clause 7.3.1.
On completion of the tone or announcement (without LCLS Break) in the forward direction the oMSC Server may signal the LCLS Configuration Change Request message to succeeding node with the LCLS-Configuration-Preference IE indicating "Need Send Forward = no". If the oMSC Server sends the LCLS Configuration Change Request message it shall start the LCLS_configuration_modification timer. At reception of the LCLS Configuration Change Request Acknowledge message the oMSC Server shall stop the LCLS_configuration_modification timer. If the LCLS_configuration_modification timer expires, the oMSC Server shall perform an intermediate node initiated LCLS break as described in clause 7.2.1.
If the oMSC Server wishes to insert a tone or announcement only towards its locally served UE it does not need to request any change to the LCLS configuration preferences in the Core Network and may send the LCLS-Connect-Control message to the oBSS containing the appropriate LCLS-Configuration IE settings as specified in Table 4.2.1.1 and if supported by the oBSS, the oMSC, oMGW shall begin applying the tone or announcement. On completion of the tone or announcement the oMSC shall return the LCLS Configuration to the previous setting.
If the oMSC Server receives LCLS-BSS-Status indicating that the oBSS does not support the requested LCLS-Configuration then the oMSC Server shall initiate LCLS Break towards the oBSS and succeeding node, as described in clause 7.2.1. On completion of the tone or announcement after LCLS Break LCLS may be re-established as described in clause 7.3.1.
If the oMSC Server receives the LCLS Configuration Change Request message with LCLS-Configuration-Preference IE indicating "Need Send Backward= yes" it shall send LCLS-Connect-Control message containing the appropriate LCLS-Configuration IE settings as specified in Table 4.2.1.1 and if supported by the oBSS it shall return the LCLS Configuration Change Request Acknowledge with a LCLS-Configuration-Change Result IE indicating success to the succeeding node.
If the oMSC Server receives LCLS-BSS-Status indicating that the oBSS does not support the requested LCLS-Configuration then the oMSC Server shall return the LCLS Configuration Change Request Acknowledge message to the succeeding node with a LCLS-Configuration-Change Result IE indicating that the request is rejected.
14.6.2.3 tMSC Server
A tMSC Server wishing to insert a tone or announcement towards the originating UE may signal LCLS Configuration Change Request message with LCLS-Configuration-Preference IE set to "Need Send Backward = yes". When tMSC Server sends the LCLS Configuration Change Request message it shall start LCLS_configuration_modification timer.
NOTE: The other LCLS-Configuration-Preference IE settings remain unchanged.
When the tMSC Server receives the LCLS Configuration Change Request Acknowledge message it shall stop the LCLS_configuration_modification timer. If the received LCLS-Configuration-Change Result IE indicates acceptance of the requested LCLS Configuration change then it shall proceed to insert its tone or announcement as per a normal call handling. Otherwise, if the received LCLS-Configuration-Change Result IE indicates the requested LCLS Configuration change is rejected or if the LCLS_configuration_modification timer expires, the tMSC Server shall perform a MSC initiated LCLS break as described in clause 7.2.1 and once the LCLS break is complete then begin applying the tone or announcement (on the completion of the tone or announcement LCLS may be re-established as described in clause 7.3.1).
If the LCLS Configuration Change Request was successful, on completion of the tone or announcement the tMSC Server may signal the LCLS Configuration Change Request to the preceding node to return the LCLS configuration preference to the previously agreed value. If the tMSC Server sends the LCLS Configuration Change Request message it shall start the LCLS_configuration_modification timer. At reception of the LCLS Configuration Change Request Acknowledge message the tMSC Server shall stop the LCLS_configuration_modification timer. If the LCLS_configuration_modification timer expires, the tMSC Server shall perform an intermediate node initiated LCLS break as described in clause 7.2.1.
If the tMSC Server wishes to insert a tone or announcement only towards its locally served UE it does not need to request any change to the LCLS configuration preferences in the Core Network and may send the LCLS-Connect-Control message to the tBSS containing the appropriate LCLS-Configuration IE settings as specified in Table 4.2.1.1 and if supported by the tBSS it shall begin applying the tone or announcement. On completion of the tone or announcement the tMSC shall return the LCLS Configuration to the previous setting.
If the tMSC Server receives LCLS-BSS-Status indicating that the tBSS does not support the requested LCLS-Configuration then the tMSC Server shall initiate LCLS Break towards the tBSS and preceding nodes, as described in clause 7.2.1.On completion of the tone or announcement after LCLS Break the tMSC Server may may re-establish LCLS (with the previous LCLS Configuration) as described in clause 7.3.1.
If the tMSC Server receives the LCLS Configuration Change Request message with the LCLS-Configuration-Preference IE indicating "Need Send Forward = yes" it shall send LCLS-Connect-Control message containing the appropriate LCLS-Configuration IE settings as specified in Table 4.2.1.1 and if supported by the tBSS it shall return the LCLS Configuration Change Request Acknowledge message with a LCLS-Configuration-Change Result IE to the preceding node.
If the tMSC Server receives LCLS-BSS-Status indicating that the tBSS does not support the requested LCLS-Configuration then the tMSC Server shall return the LCLS Configuration Change Request Acknowledge message to the preceding node with a LCLS-Configuration-Change Result IE indicating that the request is rejected.
14.6.2.4 BSS
When the BSS receives a LCLS-Connect-Control message containing a LCLS-Configuration IE set to:
– "connected both-way in the BSS and send access DL from the Core Network" and it supports this configuration it shall return LCLS-BSS-Status indicating that the requested LCLS configuration is supported and from then on detect any incoming data packets and insert them in the stream towards the locally served UE.
– "connected both-way in the BSS and send access DL from the Core Network, block local DL" and it supports this configuration it shall return LCLS-BSS-Status indicating that the requested LCLS configuration is supported and it shall block the local DL path from the opposite call leg. When detecting user data packets from the Core Network, the BSS shall insert this user data in the stream towards the locally served UE.
– "connected both-way in the BSS and bi-casted UL to the Core Network and send access DL from the Core Network" and it supports this configuration it shall return LCLS-BSS-Status indicating that the requested LCLS configuration is supported. When detecting user data packets from the Core Network, the BSS shall insert this user data in the stream towards the locally served UE and send UL user data 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" and it supports this configuration it shall block the local DL path from the opposite call leg and return LCLS-BSS-Status indicating that the requested LCLS configuration is supported. From then on it shall insert the data packets coming from the Core Network for that call leg in the stream towards the locally served UE and send UL user data to the Core Network.
If the BSS does not support the requested LCLS-Configuration it shall return LCLS-BSS-Status indicating that the requested configuration is not supported; the LCLS configuration is kept as it was prior to receiving the LCLS-Connect-Control message.
14.6.2.5 Example of Playing Mid-Call Announcement/Tone
14.6.2.5.1 Connection Model
Figure 14.6.2.5.1.1 shows the network model where the iMSC server requests the iMGW to play the announcement/tone directly on the bearer termination T3 (used towards the preceding oMGW) from which the signal shall be sent towards the oUE. The bearer termination T4 is used for the bearer towards the succeeding tMGW (i.e. towards the tUE). Before the start of mid-call announcement/tone procedure the call was locally switched with the LCLS Configuration set to "connected both-way in the BSS".
Connection Model 1: Locally switched call
Connection Model 2: Locally switched call, playing of Announcement/tone
Figure 14.6.2.5.1.1: Connection Model, Mid-Call Announcement/tone
14.6.2.5.2 Example Sequence
Figure 14.6.2.5.2.1 shows the message sequence example for providing the oUE with an announcement/tone. In the example the iMSC server requests the iMGW to play an announcement/tone and to notify the announcement/tone completion.
Figure 14.6.2.5.2.1: Mid-Call Announcement/Tone Flow
1. The iMSC server identifies that mid-call announcement/tone needs to be played towards the oUE.
2. The iMSC server modifies the LCLS-Configuration-Preference IE due to the announcement/tone it needs to play towards the oUE and sends LCLS Configuration Change Request message towards the preceding node with the LCLS-Configuration-Change Request IE indicating a request to change the LCLS Configuration and with the modified LCLS-Configuration-Preference IE indicating "Need Send Backward = yes". When LCLS Configuration Change Request message is sent the iMSC server starts LCLS_configuration_modification timer.
NOTE: Other values for the initially agreed LCLS-Configuration-Preference IE for receive or send access are unmodified.
3. The oMSC server informs the oBSS the user plane data needs to be provided to the oUE from the CN by sending the LCLS-Connect-Control message containing LCLS-Configuration IE set to "connected both-way in the BSS and send access DL from the Core Network".
4. The oBSS confirms the requested configuration is enabled with the LCLS-Connect-Control Ack message.
5. The oMSC server confirms the oBSS is prepared for the reception of announcement/tone by sending the LCLS Configuration Change Request Acknowledge message with a LCLS-Configuration-Change Result IE indicating acceptance of the requested LCLS Configuration change.
6. At reception of the LCLS Configuration Change Request Acknowledge message the iMSC server stops the LCLS_configuration_modification timer. Since the received LCLS-Configuration-Change Result IE indicates that requested send access is enabled the iMSC server provides the iMGW with the announcement/tone identification and requests the iMGW to notify the announcement/tone completion using the Play Announcement or Send Tone procedure.
7. The iMGW notifies the iMSC server when the announcement/tone is completed using the Announcement Completed or Tone Completed procedure.
8. The iMSC server signals to the preceding node the send access is not needed anymore by sending the LCLS Configuration Change Request message with the LCLS-Configuration-Change Request IE indicating a request to change the LCLS Configuration and with the LCLS-Configuration-Preference IE indicating "Need Send Backward = no" and starts LCLS_configuration_modification timer.
9. The oMSC server notifies the oBSS with the LCLS-Connect-Control message that no user plane data from the CN will be provided that is the LCLS-Configuration IE is set to "connected both-way in the BSS".
10. The oBSS replies with the LCLS-Connect-Control Ack message indicating local switching with the requested LCLS configuration.
11. The oMSC server confirms the oBSS has returned the LCLS connection to the status prior to the announcement/tone by sending the LCLS Configuration Change Request Acknowledge message with the LCLS-Configuration-Change Result IE indicating acceptance of the requested LCLS Configuration change. At reception of the LCLS Configuration Change Request Acknowledge message the iMSC server stops the LCLS_configuration_modification timer.
14.6.2.6 Examples with Uplink Bicasting of User Data
14.6.2.6.1 Connection Model
Figure 14.6.2.6.1.1 shows the network model for the locally switched call with bicasting of user data to the Core Network where the oMSC server requests the oMGW to play the announcement/tone towards the originating UE. The dashed line in green represents call control signalling. Non-dotted lines represent the bearer carrying real user plane data: the solid line in turquoise represents the data from the originating UE and the solid line in yellow represents the data from the terminating UE. The solid line in blue represents an announcement played to the originating UE. The bearer termination T1 is used for the bearer towards the oBSS and the bearer termination T2 is used for the bearer towards the succeeding iMGW (i.e. towards the tUE). The announcement is applied directly on the bearer termination T1 from which the signal shall be sent towards the originating UE.
If the oMSC server requires receiving UL data from the originating UE and the terminating UE and was sent a LCLS Configuration Preference IE set to "Need_Receive_Backward = yes; Need_Receive_Forward = yes" to the succeeding node then when it needs to send the DL data to the originating UE the oMSC server will require from the oBSS to connect LCLS with bicasting UL and with DL send access and to block local DL. Connection model 2a is applied when the oBSS supports the required LCLS configuration and the announcement is played towards the originating UE.
If the oMSC server requires receiving UL data from the originating UE and the terminating UE but was sent the LCLS Configuration Preference IE set to "Need_Receive_Backward = yes, Need_Receive_Forward = no" to the succeeding node and was received the LCLS Configuration Preference IE set to "Need_Receive_Forward = no" then it may configure its oMGW to isolate the access side termination (T1) from the network side termination (T2). When the oMSC server needs to send the DL data to the originating UE it requests the oBSS to connect LCLS with bicasting UL and with DL send access. Connection model 2b applies when the oBSS supports the required LCLS configuration and then the oBSS inserts the announcement from the Core Network towards the originating UE.
Connection Model 1: Locally switched call with bicasting of user data to CN
Connection Model 2a: Locally Switched Call with Bicasting of User Data to CN and with Blocked Local DL Data, Playing of Announcement/tone
Connection Model 2b: Locally Switched Call with Bicasting of User Data to CN and Isolation of Access Side, Playing of Announcement/tone
Figure 14.6.2.6.1.1: Connection Model, LCLS with UL Bicasting and Mid-Call Announcement/tone
14.6.2.6.2 Example Sequences with Uplink Bicasting of User Data
Figure 14.6.2.6.2.1 shows the message sequence example for providing the originating UE with an announcement/tone. In the example the call is locally switched with bicasting of user data to the Core Network. The oMSC server requests the oBSS to connect LCLS with bicasting UL and with DL send access and to block local DL. The oMSC server requests the oMGW to play an announcement/tone and to notify the announcement/tone completion.
Figure 14.6.2.6.2.1: Mid-Call Announcement/Tone Flow with Block Local Data Request
1. The oMSC server identifies that mid-call announcement/tone needs to be played towards the oUE.
2. The oMSC server informs the oBSS the user plane data needs to be provided to the oUE from the CN by sending the LCLS-Connect-Control message containing LCLS-Configuration IE set to "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".
3. The oBSS confirms the requested configuration is enabled with the LCLS-Connect-Control Ack message.
4. At reception of the LCLS-Connect-Control Ack message indicating that requested LCLS configuration is supported the oMSC server provides the oMGW with the announcement/tone identification and requests the oMGW to notify the announcement/tone completion using the Play Announcement or Send Tone procedure.
5. The oMGW notifies the oMSC server when the announcement/tone is completed using the Announcement Completed or Tone Completed procedure.
6. The oMSC server notifies the oBSS with the LCLS-Connect-Control message that DL send access is no longer needed that is the LCLS-Configuration IE is set to "connected both-way in the BSS and
bi-casted UL to the Core Network".
7. The oBSS replies with the LCLS-Connect-Control Ack message indicating local switching with the requested LCLS configuration.
14.6.2.6.3 Example Sequence when Access Side Termination is isolated in MGW
Figure 14.6.2.6.3.1 shows the message sequence example for providing the originating UE with an announcement/tone. Since other CN nodes didn’t requested receiving UL data from the originating UE the oMSC server may configure its oMGW to isolate the access side termination from the network side termination. In the example the oMSC server requests the oMGW to play an announcement/tone and to notify the announcement/tone completion.
Figure 14.6.2.6.3.1: Mid-Call Announcement/Tone Flow when Access Side Termination is Isolated in MGW
1. The oMSC server identifies that mid-call announcement/tone needs to be played towards the oUE.
2. If the LCLS negotiation indicated that any succeeding node does not require the UL data from the oUE then the oMSC server requests the oMGW to isolate the access side termination T1 from the network side termination T2.
NOTE 1: the MOVE command (Isolate Bearer termination procedure) is not required if T1 has been already moved from the context oC during the call establishment procedure.
NOTE 2: The MSC server can also use the Change Through-Connection procedure and requests the MGW to change the through-connection of the bearer to inactive instead of using of the Isolate Bearer termination procedure, see 3GPP TS 23.205 [2].
3. The oMSC server informs the oBSS the user plane data needs to be provided to the oUE from the CN by sending the LCLS-Connect-Control message containing LCLS-Configuration IE set to "connected both-way in the BSS and bi-casted UL to the Core Network and send access DL from the Core Network".
4. The oBSS confirms the requested configuration is enabled with the LCLS-Connect-Control Ack message.
5. At reception of the LCLS-Connect-Control Ack message indicating that requested LCLS configuration is supported the oMSC server provides the oMGW with the announcement/tone identification and requests the oMGW to notify the announcement/tone completion using the Play Announcement or Send Tone procedure.
6. The oMGW notifies the oMSC server when the announcement/tone is completed using the Announcement Completed or Tone Completed procedure.
7. The oMSC server notifies the oBSS with the LCLS-Connect-Control message that DL send access is no longer needed that is the LCLS-Configuration IE is set to "connected both-way in the BSS and bi-casted UL to the Core Network".
8. The oBSS replies with the LCLS-Connect-Control Ack message indicating local switching with the requested LCLS configuration.
9. The oMSC server may send to the oMGW request to move the access side termination T1 to context oC with the network side termination T2.
NOTE 3: Steps 9 is optional and not needed if step 2 is not performed.
NOTE 4: If the MSC server has used the Change Through-Connection procedure in step 2 instead of the Isolate Bearer termination procedure then the MSC server will use the Change Through-Connection procedure to request the MGW to change the through-connection of the bearer to be both-way through-connected.