Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.284  Word version:  17.0.0

Top   Top   Up   Prev   Next
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… 
14 Interactions with Other Network Features and Services  14.1 Customised Applications for Mobile network Enhanced Logic (CAMEL)  14.2 IST  14.3 Operator Determined Barring (ODB)  14.4 DTMF  14.5 OR  14.6 Providing tones or announcements  14.6.1 General  14.6.2 Handling of tones or announcements during an LCLS call  14.6.2.1 GMSC Server or intermediate node requiring temporary send access to apply tone or announcement  14.6.2.2 oMSC Server  14.6.2.3 tMSC Server  14.6.2.4 BSS  14.6.2.5 Example of Playing Mid-Call Announcement/Tone  14.6.2.6 Examples with Uplink Bicasting of User Data  14.7 Global Text Telephony  14.8 Emergency Calls  14.9 Subscriber and equipment trace  14.10 Customized Alerting Tone  14.11 Tandem Free Operation (TFO)  14.12 Transcoder Free Operation (TrFO)  14.13 CS Data Calls  14.14 RTP Multiplexing  15 Tunnelling 
...

 

14  Interactions with Other Network Features and Services  p. 161

14.1  Customised Applications for Mobile network Enhanced Logic (CAMEL)  p. 161

No impact. There are no LCLS related requirements for Customised Applications for Mobile network Enhanced logic (CAMEL).
If LCLS is established for the call and a CAMEL service requires the insertion of Tones/Announcements, the LCLS procedures for Providing Tones or Announcements shall be applied as specified in clause 14.6.
If LCLS is established for the call and a CAMEL service requires the user-plane to be manipulated within the Core Network, the LCLS procedures for breaking LCLS shall be applied as specified in clause 7.2.
Up

14.2  IST  p. 161

No impact. There are no LCLS related requirements for Immediate Service Termination (IST).

14.3  Operator Determined Barring (ODB)  p. 161

No impact. There are no LCLS related requirements for Operator Determined Barring (ODB).

14.4  DTMF  p. 161

No impact. There are no LCLS related requirements for DTMF.
If LCLS is established for the call and a DTMF tone is required to be sent to the UE, the LCLS procedures for Providing Tones or Announcements shall be applied as specified in clause 14.6.

14.5  OR  p. 161

No impact. There are no LCLS related requirements for Optimal Routing (OR).

14.6  Providing tones or announcements  p. 161

14.6.1  General  p. 161

Tones or announcements may be applied at any time during the call establishment or mid-call. Also periodic tones may be applied during the call. Prior to answer, an LCLS compatible call is still connected through the core network and so any tones or announcements applied at this time are handled as for normal non-LCLS calls.
If a node wishes to apply periodic tones during the call it may either reject the LCLS entirely or may indicate that it requires send access in a certain direction. This is achieved during the LCLS negotiation phase as described in clause 4.2.
If the call is established and local switching is performed and at a later point in the call a (G)MSC Server needs to send a tone or announcement there are two options it may apply:
  • perform a (G)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, or
  • request temporary send access to the user plane as described in clause 14.6.2
    If a node (subsequent CN node or BSS) does not support the procedures described for requesting temporary send access then a full LCLS break shall occur.
Up

14.6.2  Handling of tones or announcements during an LCLS call  p. 162

14.6.2.1  GMSC Server or intermediate node requiring temporary send access to apply tone or announcement  p. 162

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.
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.
Up

14.6.2.2  oMSC Server  p. 162

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.
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.
Up

14.6.2.3  tMSC Server  p. 163

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.
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.
Up

14.6.2.4  BSS  p. 164

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.
Up

14.6.2.5  Example of Playing Mid-Call Announcement/Tone  p. 164

14.6.2.5.1  Connection Model  p. 164
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".
Copy of original 3GPP image for 3GPP TS 23.284, Fig. 14.6.2.5.1.1: Connection Model, Mid-Call Announcement/tone
Figure 14.6.2.5.1.1: Connection Model, Mid-Call Announcement/tone
(⇒ copy of original 3GPP image)
Up
14.6.2.5.2  Example Sequence  p. 165
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.
Copy of original 3GPP image for 3GPP TS 23.284, Fig. 14.6.2.5.2.1: Mid-Call Announcement/Tone Flow
Figure 14.6.2.5.2.1: Mid-Call Announcement/Tone Flow
(⇒ copy of original 3GPP image)
Up
Step 1.
The iMSC server identifies that mid-call announcement/tone needs to be played towards the oUE.
Step 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.
Step 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".
Step 4.
The oBSS confirms the requested configuration is enabled with the LCLS-Connect-Control Ack message.
Step 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.
Step 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.
Step 7.
The iMGW notifies the iMSC server when the announcement/tone is completed using the Announcement Completed or Tone Completed procedure.
Step 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.
Step 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".
Step 10.
The oBSS replies with the LCLS-Connect-Control Ack message indicating local switching with the requested LCLS configuration.
Step 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.
Up

14.6.2.6  Examples with Uplink Bicasting of User Data |R17|  p. 167

14.6.2.6.1  Connection Model  p. 167
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.
Copy of original 3GPP image for 3GPP TS 23.284, Fig. 14.6.2.6.1.1: Connection Model, LCLS with UL Bicasting and Mid-Call Announcement/tone
Figure 14.6.2.6.1.1: Connection Model, LCLS with UL Bicasting and Mid-Call Announcement/tone
(⇒ copy of original 3GPP image)
Up
14.6.2.6.2  Example Sequences with Uplink Bicasting of User Data  p. 168
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.
Copy of original 3GPP image for 3GPP TS 23.284, Fig. 14.6.2.6.2.1: Mid-Call Announcement/Tone Flow with Block Local Data Request
Figure 14.6.2.6.2.1: Mid-Call Announcement/Tone Flow with Block Local Data Request
(⇒ copy of original 3GPP image)
Up
Step 1.
The oMSC server identifies that mid-call announcement/tone needs to be played towards the oUE.
Step 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".
Step 3.
The oBSS confirms the requested configuration is enabled with the LCLS-Connect-Control Ack message.
Step 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.
Step 5.
The oMGW notifies the oMSC server when the announcement/tone is completed using the Announcement Completed or Tone Completed procedure.
Step 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".
Step 7.
The oBSS replies with the LCLS-Connect-Control Ack message indicating local switching with the requested LCLS configuration.
Up
14.6.2.6.3  Example Sequence when Access Side Termination is isolated in MGW  p. 170
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.
Copy of original 3GPP image for 3GPP TS 23.284, Fig. 14.6.2.6.3.1: Mid-Call Announcement/Tone Flow when Access Side Termination is Isolated in MGW
Figure 14.6.2.6.3.1: Mid-Call Announcement/Tone Flow when Access Side Termination is Isolated in MGW
(⇒ copy of original 3GPP image)
Up
Step 1.
The oMSC server identifies that mid-call announcement/tone needs to be played towards the oUE.
Step 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.
Step 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".
Step 4.
The oBSS confirms the requested configuration is enabled with the LCLS-Connect-Control Ack message.
Step 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.
Step 6.
The oMGW notifies the oMSC server when the announcement/tone is completed using the Announcement Completed or Tone Completed procedure.
Step 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".
Step 8.
The oBSS replies with the LCLS-Connect-Control Ack message indicating local switching with the requested LCLS configuration.
Step 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.
Up

14.7  Global Text Telephony  p. 171

LCLS shall not be allowed for Global Text Telephony.

14.8  Emergency Calls  p. 171

LCLS shall not be allowed for Emergency Calls.

14.9  Subscriber and equipment trace  p. 171

No impact. There are no LCLS related requirements for Subscriber and Equipment Trace.

14.10  Customized Alerting Tone  p. 171

14.10.1  Audio CAT  p. 171

No impact. There are no LCLS related requirements for Audio CAT.

14.10.2  Multimedia CAT  p. 171

LCLS shall not be allowed for multimedia calls.

14.11  Tandem Free Operation (TFO)  p. 171

No impact. There are no LCLS related requirements for Tandem Free Operation (TFO).
LCLS may be activated for calls that use TFO, but the TFO operation is interrupted for the time that the call is locally switched. If LCLS is broken in the middle of a call, the TFO operation may resume, if still applicable.

14.12  Transcoder Free Operation (TrFO)  p. 172

No impact. There are no LCLS related requirements for Transcoder Free Operation (TrFO).

14.13  CS Data Calls  p. 172

LCLS shall not be allowed for CS Data Calls.

14.14  RTP Multiplexing  p. 172

No impact. There are no LCLS related requirements for RTP Multiplexing.

15  Tunnelling  p. 172

The tunnelling procedures shall be applied in accordance with TS 23.205.

Up   Top   ToC