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… 
6 Call Establishment  6.1 Basic Mobile Originating Call  6.1.1 Basic Mobile Originating Call with BICC based CS core network  6.1.2 Basic Mobile Originating Call with SIP-I based CS core network  6.2 Basic Mobile Terminating Call  6.2.1 Basic Mobile Terminating Call with BICC based CS core network  6.2.2 Basic Mobile Terminating Call with SIP-I based CS core network 
...

 

6  Call Establishment  p. 23

6.1  Basic Mobile Originating Call  p. 23

6.1.1  Basic Mobile Originating Call with BICC based CS core network  p. 23

6.1.1.1  General  p. 23

The basic mobile originating call shall be established in accordance with TS 23.205. 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  p. 23

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 TS 29.205. 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 TS 29.205, together with the Supported Codecs List IE for OoBTC as specified in TS 23.153 in the IAM message to the succeeding call control node.
Up

6.1.1.3  Access Bearer Assignment  p. 23

6.1.1.3.1  Assignment performed after LCLS Negotiation through Core Network  p. 23
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 TS 48.008).
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.
Up
6.1.1.3.2  Assignment performed before LCLS Negotiation  p. 23
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  p. 23
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.
Up

6.1.1.4  Backward LCLS Negotiation  p. 24

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

6.1.1.5  LCLS Through-Connection  p. 24

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

6.1.1.6  LCLS Status Reporting  p. 24

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

6.1.1.7  MGW/User plane  p. 24

The MGW/user plane shall be established in accordance with TS 23.205.

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

6.1.2.1  General  p. 25

The basic mobile originating call shall be established in accordance with TS 23.231. 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  p. 25

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

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

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

6.1.2.5  LCLS Through-Connection  p. 25

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

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

The MGW/user plane shall be established in accordance with TS 23.205.

6.2  Basic Mobile Terminating Call  p. 25

6.2.1  Basic Mobile Terminating Call with BICC based CS core network  p. 25

6.2.1.1  General  p. 25

The basic mobile terminating call shall be established in accordance with TS 23.205. 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)  p. 26

6.2.1.2.1  Initial Addressing  p. 26
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.
Up
6.2.1.2.2  Backward LCLS Negotiation  p. 26
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.
  • 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.
Other information elements shall be treated as specified in TS 23.205 and in TS 23.231.
Up
6.2.1.2.3  Through-Connection  p. 26
The procedure specified in TS 23.205 shall be applied.
6.2.1.2.4  LCLS Status Reporting within CN  p. 26
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  p. 26
The MGW/user plane shall be established in accordance with TS 23.205.

6.2.1.3  Actions at Terminating Call side  p. 27

6.2.1.3.1  Initial Addressing  p. 27
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 TS 29.205.
6.2.1.3.2  Backward LCLS Negotiation  p. 27
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  p. 27
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 TS 48.008).
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.
Up
6.2.1.3.4  LCLS Through-Connection  p. 27
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 TS 48.008.
Up
6.2.1.3.5  LCLS Status Reporting  p. 28
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  p. 28
The MGW/user plane shall be established in accordance with TS 23.205.

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

6.2.2.1  General  p. 28

The basic mobile terminating call shall be established in accordance with TS 23.231. 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)  p. 28

6.2.2.2.1  Initial Addressing  p. 28
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.
Up
6.2.2.2.2  Backward LCLS Negotiation  p. 28
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  p. 28
See clause 6.2.1.2.3.
6.2.2.2.4  LCLS Status Reporting within CN  p. 28
See clause 6.2.1.2.4.
6.2.2.2.5  MGW/User plane  p. 28
See clause 6.2.1.2.5.

6.2.2.3  Actions at Terminating Call side  p. 28

6.2.2.3.1  Initial Addressing  p. 28
See clause 6.2.1.3.1.
6.2.2.3.2  Backward LCLS Negotiation  p. 28
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  p. 29
See clause 6.2.1.3.3.
6.2.2.3.4  LCLS Through-Connection  p. 29
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  p. 29
See clause 6.2.1.3.5.
6.2.2.3.6  MGW/User plane  p. 29
See clause 6.2.1.3.6.

Up   Top   ToC