6.2 Basic Mobile Terminating Call

23.2843GPPLocal Call Local Switch (LCLS)Release 17Stage 2TS

6.2.1 Basic Mobile Terminating Call with BICC based CS core network

6.2.1.1 General

The basic mobile terminating call shall be established in accordance with 3GPP TS 23.205 [2]. The LCLS establishment may use forward or backward bearer establishment. The following clauses describe the additional requirements related to the LCLS functionality.

6.2.1.2 Actions at Intermediate Nodes (including GMSC)

6.2.1.2.1 Initial Addressing

If an intermediate node supports the LCLS feature and receives the LCLS-Negotiation Request IE and LCLS-Configuration-Preference IE from a preceding node in the IAM it may modify the LCLS-Configuration-Preference IE based on its own LCLS configuration requirements, and shall then forward the resulting LCLS-Configuration-Preference IE together with GCR IE and LCLS-Negotiation Request IE to the succeeding node. The rules for modifying the LCLS-Configuration-Preference IE are specified in the clause 4.2.

If LCLS is not permitted by the intermediate node based on its own LCLS requirements then it shall set the LCLS-Negotiation Request IE to value "LCLS not allowed". The intermediate node shall forward the LCLS-Negotiation Request IE, LCLS-Configuration-Preference IE and GCR IE to the succeeding node.

6.2.1.2.2 Backward LCLS Negotiation

If the intermediate node supports the LCLS feature and has sent the GCR IE, the LCLS-Negotiation Request IE and LCLS-Configuration-Preference IE within IAM message towards the succeeding node further action depends on the content of the first received backward message (APM message or ACM).

– If the intermediate node receives the first backward message (APM or ACM) without the LCLS-Negotiation Response IE it shall include the LCLS-Negotiation Response IE indicating "LCLS not supported by subsequent node into APM/ACM before forwarding the APM/ACM to the preceding node.

NOTE 1: This indicates to preceding nodes that the LCLS feature is not supported by the succeeding nodes except the intermediate node but that further LCLS negotiation can occur. Specifically this can arise due to subsequent call control signalling to other succeeding nodes, e.g. due to changed routing, handover or supplementary service interactions. If the intermediate node does not include any LCLS-Negotiation Result IE then it implicitly indicates to the preceding node that LCLS feature is not supported by the intermediate node and no further LCLS signalling is permitted for the call.

– When the received APM/ACM contains the LCLS-Negotiation Response IE then the forwarding MSC server shall forward the received LCLS-Negotiation Response IE and LCLS-Configuration-Preference IE to the preceding node.

If the intermediate node has forwarded LCLS-Negotiation Response IE in the first backward APM/ACM message and receives an APM which does not include LCLS Negotiation Response IE then the intermediate node shall handle the APM but shall not include any LCLS IE when passing on such APM’s; no changes to LCLS status shall result.

NOTE 2: APM is used for other services or applications and need not include LCLS IEs.

Other information elements shall be treated as specified in 3GPP TS 23.205 [2] and in 3GPP TS 23.231 [3].

6.2.1.2.3 Through-Connection

The procedure specified in 3GPP TS 23.205 [2] shall be applied.

6.2.1.2.4 LCLS Status Reporting within CN

If the LCLS status is received from its adjacent node, the MSC server shall update the LCLS status and shall pass on to the next node only if the LCLS status has changed. See also clause 4.5.

6.2.1.2.5 MGW/User plane

The MGW/user plane shall be established in accordance with 3GPP TS 23.205 [2].

6.2.1.3 Actions at Terminating Call side

6.2.1.3.1 Initial Addressing

If the tMSC server supports LCLS feature and receives the GCR IE, the LCLS-Negotiation Request IE and the LCLS-Configuration-Preference IE it may modify the LCLS-Configuration-Preference IE based on its own LCLS configuration requirements. The rules for modifying the LCLS-Configuration-Preference IE are specified in the clause 4.2 and in 3GPP TS 29.205 [6].

6.2.1.3.2 Backward LCLS Negotiation

If the tMSC server supports LCLS feature then it shall return the LCLS-Negotiation Response IE and the LCLS-Configuration-Preference IE to the preceding node in the APM or the ACM message.

6.2.1.3.3 Access Bearer Assignment

If the serving radio access is GERAN then when the tMSC server performs the access bearer assignment it shall include the GCR IE and the LCLS-Configuration IE (which is derived from the LCLS-Configuration-Preference IE) in the BSSAP Assignment Request message sent to the terminating BSS (see 3GPP TS 48.008 [7]).

If the tMSC server supports the optional "intra-Network call detection" procedure and determines that the Network ID within the GCR IE is not equal to the own (tMSC) Network ID, the tMSC server shall also include the "LCLS-Correlation-Not-Needed" IE in the Assignment Request message (see clause 4.3.2).

If the tMSC server supports the optional "intra-BSS call detection" procedure and determines that the BSS ID within the GCR IE is not equal to the terminating BSS ID, the tMSC server shall also include the "LCLS-Correlation-Not-Needed" IE in the Assignment Request message (see clause 4.3.3).

If the terminating BSS supports LCLS and receives the Assignment Request message containing the GCR IE and the LCLS-Configuration IE, the BSS shall store the GCR against the Assigned Call leg and check if it can support the requested LCLS-Configuration. Unless the BSS supports the optional "intra-Network call detection" procedure (see clause 4.3.2) or optional "intra-BSS call detection" procedure (see clause 4.3.3) it shall perform a correlation of the received GCR to see if another call leg has been assigned with the same GCR and report the outcome in the LCLS-BSS-Status IE returned to the tMSC server in the Assignment Complete message.

If the terminating BSS does not support LCLS then the GCR IE and the LCLS-Configuration IE will be ignored and no LCLS-BSS-Status IE will be returned in the Assignment Complete message. The tMSC server shall continue the call establishment as for normal Non-LCLS call.

6.2.1.3.4 LCLS Through-Connection

If the terminating BSS determines that the call is local and can be locally switched it shall not through-connect the two parties unless explicitly indicated to do so by receiving the LCLS-Connection-Status-Control IE set to "Connect" for both call legs.

When the tMSC server receives "answer" from the terminating UE it shall send the BSSAP message LCLS-Connect-Control containing the LCLS-Connection-Status-Control IE set to "Connect" and send the ANM message with the LCLS-Status IE indicating "LCLS is feasible but not yet connected" to the preceding MSC server.

If the BSS has received the LCLS-Connection-Status-Control IE set to "Connect" for both call legs associated to the LCLS call it shall locally switch the user plane between the two call legs and report the through-connection via LCLS-BSS-Status IE set to "the call is locally switched with requested LCLS configuration" in the LCLS-Connect-Control Acknowledge message. The CN user plane shall be kept through-connected as described in the clause 4.6.

If the call is not yet locally switched when returning the LCLS-Connect-Control Acknowledge message but becomes locally switched at a later time (for example due to the LCLS-Connection-Status-Control IE requesting "Connect" at the second call leg) the BSS shall report the change in status via LCLS-BSS-Status IE set to "the call is locally switched with requested LCLS configuration" within the LCLS-Notification message as specified in 3GPP TS 48.008 [7].

6.2.1.3.5 LCLS Status Reporting

During the LCLS call establishment and ongoing call any change to the LCLS connection status is reported by the BSS to the core network and only if it results in a change of the LCLS status in the core network the updated LCLS status shall be signalled by the tMSC server to the preceding node. See also clause 4.5.

6.2.1.3.6 MGW/User plane

The MGW/user plane shall be established in accordance with 3GPP TS 23.205 [2].

6.2.2 Basic Mobile Terminating Call with SIP-I based CS core network

6.2.2.1 General

The basic mobile terminating call shall be established in accordance with 3GPP TS 23.231 [3]. The LCLS principles using introduced in the clause 6.2.1 for BICC protocol messages should also apply to SIP-I signalling cases.

6.2.2.2 Actions at Intermediate Nodes (including GMSC)

6.2.2.2.1 Initial Addressing

If an intermediate node supports the LCLS feature and receives the GCR IE, the LCLS-Negotiation Request IE and the LCLS-Configuration-Preference IE included within the encapsulated IAM message from a preceding node in the SIP-I INVITE request it may modify the LCLS-Configuration-Preference IE based on its own LCLS configuration requirements, and shall then forward the initial INVITE request with the resulting LCLS-Configuration-Preference IE together with GCR IE and LCLS-Negotiation Request IE included within the encapsulated IAM message to the succeeding node.

6.2.2.2.2 Backward LCLS Negotiation

On the receipt of the 183 Session Progress provisional response the intermediate node shall apply the Backward LCLS Negotiation procedure specified in the clause 6.2.1.2.2.

6.2.2.2.3 Through-Connection

See clause 6.2.1.2.3.

6.2.2.2.4 LCLS Status Reporting within CN

See clause 6.2.1.2.4.

6.2.2.2.5 MGW/User plane

See clause 6.2.1.2.5.

6.2.2.3 Actions at Terminating Call side

6.2.2.3.1 Initial Addressing

See clause 6.2.1.3.1.

6.2.2.3.2 Backward LCLS Negotiation

If the tMSC server supports LCLS feature then it shall return the final LCLS-Negotiation Response IE and LCLS-Configuration-Preference IE included within the encapsulated APM message to the preceding node in the SIP-I 183 Session Progress provisional response.

6.2.2.3.3 Access Bearer Assignment

See clause 6.2.1.3.3.

6.2.2.3.4 LCLS Through-Connection

The tMSC server shall apply the LCLS Through-Connection procedure specified in the clause 6.2.1.3.4. The LCLS-Status IE indicating "LCLS is feasible but not yet connected" shall be included in the ANM message encapsulated in the 200 OK final response to the initial INVITE.

6.2.2.3.5 LCLS Status Reporting

See clause 6.2.1.3.5.

6.2.2.3.6 MGW/User plane

See clause 6.2.1.3.6.