6.1 Basic Mobile Originating Call

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

6.1.1 Basic Mobile Originating Call with BICC based CS core network

6.1.1.1 General

The basic mobile originating 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.1.1.2 Initial Addressing

If the oMSC server supports the LCLS feature it shall generate a Global Call Reference (GCR) IE. The GCR IE is derived from the ITU-T Global Call Reference IE [5] and specified in detail in the clause 16 and in 3GPP TS 29.205 [6]. If the serving radio access is GERAN the Call Reference ID field of the GCR IE contains the originating BSS ID.

The oMSC server shall then include the GCR IE, LCLS-Negotiation Request IE and LCLS-Configuration-Preference IE indicating the preferences for LCLS as defined in the clause 4.2, clause 16 and in 3GPP TS 29.205 [6], together with the Supported Codecs List IE for OoBTC as specified in 3GPP TS 23.153 [4] in the IAM message to the succeeding call control node.

6.1.1.3 Access Bearer Assignment

6.1.1.3.1 Assignment performed after LCLS Negotiation through Core Network

On receipt of the APM from the succeeding MSC server containing the LCLS-Negotiation Response IE, indicating local call connection is permitted, the oMSC server shall continue with the basic call establishment and if the serving radio access is GERAN shall include the GCR IE and the LCLS-Configuration IE (which is derived from the LCLS-Configuration-Preference IE) in the originating BSSAP Assignment Request message (see 3GPP TS 48.008 [7]).

If the serving radio access is UTRAN the oMSC server shall save the LCLS-Negotiation Response IE and LCLS-Configuration-Preference IE but proceed with the call establishment as described in TS 23.205 [2].

6.1.1.3.2 Assignment performed before LCLS Negotiation

After generation of the GCR IE the oMSC initiates the access bearer assignment on the originating side and includes the GCR IE and the preliminary LCLS-Configuration IE (the final configuration can be different due to the following LCLS negotiation through the core network) in the originating BSSAP Assignment Request message.

6.1.1.3.3 oBSS behavior

If the originating BSS supports LCLS and receives the Assignment Request message containing the GCR IE and the LCLS-Configuration IE the originating BSS shall store the GCR IE against the Assigned Call leg and shall check if it can support the requested LCLS-Configuration. The originating BSS shall report the outcome in LCLS-BSS-Status IE returned to the MSC server in the Assignment Complete message.

If the originating 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 oMSC server shall continue the call establishment as for a Non-LCLS call.

6.1.1.4 Backward LCLS Negotiation

At reception of an APM, ACM or CPG message with the LCLS-Negotiation Response IE and the LCLS-Configuration-Preference IE the oMSC server shall check whether a new value of the LCLS-Configuration-Preference settings require the change of the requested LCLS configuration and if so the oMSC server shall include the updated LCLS-Configuration IE in the BSSAP message LCLS Connect Control to the BSS, see clause 6.1.1.5. If the LCLS-Negotiation Response IE indicates "LCLS Not Allowed" or "LCLS not supported by subsequent node" then the oMSC Server shall not permit LCLS connection unless any subsequent LCLS negotiation results in LCLS being feasible.

NOTE 1: The oMSC can still signal the GCR to the BSS in order to avoid a subsequent Assignment to pass the GCR if LCLS becomes feasible at a later time during the call.

At reception of an unsolicited APM message without LCLS-Negotiation Response IE then the oMSC shall handle the APM but not change the LCLS-Configuration or any LCLS behaviour.

NOTE 2: APM is used for other services or applications and need not include LCLS-Negotiation Response IE.

If the first backward message (APM or ACM) does not contain the LCLS-Negotiation Response IE then the oMSC Server shall not proceed with further LCLS signalling for this call.

NOTE 3: This indicates to the oMSC server that the LCLS feature is not supported by succeeding node.

6.1.1.5 LCLS Through-Connection

If the originating 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 oMSC server receives the ANM from the succeeding MSC server with the LCLS-Status IE indicating "LCLS is feasible but not yet connected" it shall send the BSSAP message LCLS-Connect-Control to the originating BSS containing the LCLS-Connection-Status-Control IE set to "Connect". If the value of the required LCLS Configuration is not the same as the value requested within the Assignment Request message, the oMSC Server shall also include the LCLS Configuration IE in the LCLS-Connect-Control message.

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 the 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 the 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].

NOTE: This should not occur at the oMSC server for normal call establishment as the oMSC server should always be the last (second) node sending the LCLS-Connect-Control message to the BSS.

6.1.1.6 LCLS Status Reporting

When the oMSC server receives the LCLS-Connect-Control Acknowledge message from the originating BSS with the LCLS-BSS-Status IE set to "the call is locally switched with requested LCLS configuration" it shall inform the succeeding MSC server with the APM message containing the LCLS Status IE set to "LCLS connected".

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 oMSC server to the succeeding nodes. See also clause 4.5.

6.1.1.7 MGW/User plane

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

6.1.2 Basic Mobile Originating Call with SIP-I based CS core network

6.1.2.1 General

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

6.1.2.2 Initial Addressing

The oMSC server shall send the initial SIP-I INVITE request with the GCR IE, LCLS-Negotiation Request IE and LCLS-Configuration-Preference IE included within the encapsulated IAM message if the LCLS feature is supported. If an access bearer assignment has not been completed the initial SDP offer shall indicate that the local preconditions have not been met.

6.1.2.3 Access Bearer Assignment

On receipt of the SIP-I 183 Session Progress provisional response from the succeeding MSC server containing the LCLS-Negotiation Response IE and LCLS-Configuration-Preference IE included within the encapsulated APM message, the oMSC server shall continue with the basic call establishment as specified in the clause 6.1.1.3.

6.1.2.4 Backward LCLS Negotiation

At reception of the SIP-I 183 Session Progress provisional response with the LCLS-Negotiation Response IE and LCLS-Configuration-Preference IE included within the encapsulated APM message the oMSC server shall check the value of the LCLS-Negotiation Response IE and the LCLS-Configuration-Preference IE as specified in the clause 6.1.1.4.

If the first 183 Session Progress provisional response does not contain the LCLS Negotiation Response IE then the oMSC Server shall not proceed with further LCLS signalling for this call.

NOTE: This indicates to the oMSC server that LCLS feature is not supported by succeeding node.

6.1.2.5 LCLS Through-Connection

On the reception of the 200 OK final response to the initial INVITE with the encapsulated ANM message containing LCLS-Status IE the oMSC server shall apply the LCLS Through-Connection procedure specified in the clause 6.1.1.5.

6.1.2.6 LCLS Status Reporting

The oMSC server shall send the SIP-I INFO request containing the LCLS Status IE included within the encapsulated APM message to the succeeding MSC server when LCLS Status Reporting needs to be performed according to procedure described in the clause 6.1.1.6.

6.1.2.7 MGW/User plane

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