6.3.4 LCLS established, Basic Call Example with SIP-I based CS core network

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

Figures 6.3.4.1, 6.3.4.2, 6.3.4.3 and 6.3.4.4 show the message sequence example for the basic call establishment when call is locally switched. In this example the oUE and the tUE belong to the same BSS (marked as oBSS and tBSS) and the CN permits LCLS. The example is based on examples for the basic mobile originating call and for the basic mobile terminating call from 3GPP TS 23.231 [3].

Figure 6.3.4.1: Basic Call Establishment Flow when call is locally switched

1. Service Request handling.

2. Originating Call SETUP.

3. The oMSC server replies with a CALL PROCEEDING message to indicate that the call is being processed.

4. If the oMSC server supports LCLS it retrieves the oBSS ID and generates the Global Call Reference for the call.

5. The oMSC server selects the codec and requests the oMGW to select and provide the IP transport address and port for the network side bearer connection before sending the INVITE message.

6. The oMSC server sends the INVITE request with the initial SDP offer indicating that local preconditions have not been met, and with the encapsulated IAM message containing the GCR with encapsulated oBSS ID, the LCLS-Negotiation Request IE and the LCLS-Configuration-Preference IE.

7. The iMSC server confirms the reception of the INVITE request with a 100 Trying provisional response.

8. The iMSC server selects the codec and requests the iMGW to select and provide the IP transport address and port for the outgoing network side bearer termination.

9. If the iMSC server supports LCLS it may modify the LCLS-Negotiation Request IE and the LCLS-Configuration-Preference IE due to CAMEL, supplementary service requirements etc. before sending the INVITE request with the SDP offer and with the encapsulated IAM message containing the GCR with the encapsulated oBSS ID, the LCLS-Negotiation Request IE and the LCLS-Configuration-Preference IE.

10. The tMSC server confirms the reception of the INVITE request with 100 a Trying provisional response.

11. The tMSC server pages the tUE.

12. The tMSC server performs call Setup.

13. The tUE confirms the call.

14. The tMSC server selects the codec, provides to the tMGW the selected codec and the remote user plane IP address and port information that were received from the preceding node in the SDP offer and requests the tMGW to prepare for the network side bearer establishment.

15. After the tMGW has replied with the local IP address and port information the tMSC server includes in the SDP answer the user plane IP address and UDP port received from the tMGW, the selected codec and any additional accepted payload types. The tMSC server returns a 183 Session Progress provisional response with the SDP answer and if LCLS is supported with encapsulated APM message containing the LCLS-Negotiation Response IE and the LCLS-Configuration-Preference IE.

16. The iMSC server replies to succeeding node with the PRACK request to confirm the reception of the 183 Session Progress provisional response.

17. When the 183 Session Progress provisional response with the SDP answer is received the iMSC server requests the iMGW to configure the remote IP transport address and any additional negotiated payload types of the outgoing side bearer termination.

18. The tMSC server confirms the reception of the PRACK request with a 200 OK final response.

Figure 6.3.4.2: Basic Call Establishment when call is locally switched (continuation of figure 6.3.4.1)

19. The iMSC server selects the codec for the incoming side bearer termination, provides to the iMGW the selected codec and the remote user plane IP address and port information that were received from the preceding node in the SDP offer and requests the iMGW to prepare for the incoming side bearer establishment.
During the seizure of the outgoing side and the incoming side bearer termination the iMSC server will also request the iMGW to through-connect the bearer terminations so that the bearer will be bothway through-connected.

20. After the iMGW has replied with the local IP address and port information the iMSC server includes in the SDP answer the user plane IP address and UDP port received from the iMGW, the selected codec and any additional accepted payload types. The iMSC server sends the 183 Session Progress provisional response with the SDP answer and with encapsulated APM message containing the LCLS-Negotiation Response IE and the LCLS-Configuration-Preference IE to the preceding node.

21. The oMSC server replies to the succeeding node with the PRACK request to confirm the reception of the 183 Session Progress provisional response.

22. The oMSC server requests the oMGW to configure the remote user plane IP address and any additional negotiated payload types of the network side bearer termination.

23. The oMSC server requests the seizure of the access side bearer termination.
During the seizure of the network side or the access side bearer termination the oMSC server will also request the oMGW to through-connect the bearer terminations so that the bearer will be backward through-connected.

24. The iMSC server confirms the reception of the PRACK request with the 200 OK final response.

25. The oMSC server determines whether LCLS is allowed in the core network based on the returned LCLS-Negotiation IE and if so the oMSC server includes the LCLS-Configuration IE in the ASSIGNMENT REQUEST message along with the GCR IE.

26. The oBSS returns the ASSIGNMENT COMPLETE message with the LCLS-BSS-Status IE indicating "call not possible to be locally switched".

27. When the oMSC server receives the ASSIGNMENT COMPLETE message, it requests the oMGW to configure the remote user plane IP address and UDP Port for the access side bearer termination.

28. Since the access bearer assignment is completed the oMSC server sends the UPDATE request with the SDP offer indicating local preconditions met to the succeeding node.

29. The iMSC server forwards the UPDATE request to the succeeding node.

30. The tMSC server confirms the reception of the UPDATE request with the 200 OK final response.

31. When the tMSC server receives the SDP offer indicating remote preconditions met it requests the seizure of the access side bearer termination.
If not requested during the seizure of network side bearer termination (step 14) the tMSC server will request the tMGW to through-connect the bearer terminations so that the bearer will be backward through-connected.

32. The iMSC server forwards the 200 OK (UPDATE) final response to the preceding node.

33. If the tMSC server supports the optional "intra-Network call detection" procedure it compares its own Network ID with the Network ID received within the Global Call Reference IE.
If the tMSC server supports the optional "intra-BSS call detection" procedure it compares the BSS ID of the selected terminating BSS with the oBSS ID received within the Global Call Reference IE at this step. Since the oUE and the tUE belong to the same BSS the call continues the same way as for the basic LCLS establishment without this pre-check.

Figure 6.3.4.3: Basic Call Establishment when call is locally switched (continuation of figure 6.3.4.2)

34. The tMSC server sends the ASSIGNMENT REQUEST message containing the GCR IE and the LCLS-Configuration IE if LCLS is permitted in the core network.

35. a) The tBSS performs the GCR correlation. Since the GCR correlation has identified the call as an intra BSS call and LCLS is allowed in the BSS, the tBSS returns the ASSIGMENT COMPLETE message with the LCLS-BSS-Status IE indicating "Call not yet locally switched".

b) Since the GCR correlation has identified the call as an intra BSS call and LCLS is allowed in the BSS, the oBSS signals the LCLS status change to the oMSC server by sending the LCLS_NOTIFICATION message with the LCLS-BSS-Status IE set to "Call not yet locally switched".

36. The tUE reports alerting.

37. The tMSC server requests the tMGW to provide a ring-back tone.

38. The tMSC server sends a 180 Ringing provisional response with the encapsulated ACM message to the preceding node.

39. The iMSC server replies to succeeding node with the PRACK request to confirm the reception of the 180 Ringing provisional response.

40. The iMSC server transfers the 180 Ringing provisional response with the encapsulated ACM message to the preceding node.

41. The oMSC server replies to succeeding node with the PRACK request to confirm the reception of the 180 Ringing provisional response.

42. The tMSC server confirms the reception of the PRACK request with the 200 OK final response.

43. The oMSC server reports alerting.

44. The IMSC server confirms the reception of the PRACK request with the 200 OK final response.

45. The tUE answers the call.

46. The tMSC server returns the CONNECT ACKNOWLEDGE message to the tUE.

47. The tMSC server indicates to the tBSS that this call leg is ready to be locally switched by sending the LCLS_CONNECT_CONTROL message.

48. The tBSS returns the LCLS_CONNECT_CONTROL_ACK message with the LCLS-BSS-Status IE set to "Call not yet locally switched" since the BSS has not received the same order from the oMSC server.

49. When the tMSC server receives the Connect message it requests the tMGW to stop providing ring-back tone to the calling party and requests to bothway through-connect the bearer.

50. The tMSC server returns the 200 OK (INVITE) final response with the encapsulated ANM message with the LCLS-Status IE indicating "LCLS is feasible but not yet connected".

51. The oMSC server receives the 200 OK (INVITE) final response with the encapsulated ANM message with the LCLS-Status IE indicating "LCLS is feasible but not yet connected".

Figure 6.3.4.4: Basic Call Establishment when call is locally switched (continuation of figure 6.3.4.3)

52. The oMSC server replies to the succeeding node with the ACK request to confirm the reception of the 200 OK final response.

53. The oMSC server request the oMGW to bothway through-connect the bearer.

54. The iMSC server transfers the ACK request to the succeeding node.

55. The oMSC server reports Answer/Connect to the oUE.

56. The oUE returns the CONNECT ACKNOWLEDGE message to the oMSC server.

57. The oMSC server requests the oBSS to connect LCLS since the received 200 OK (INVITE) final response indicated "LCLS is feasible but not yet connected".

58. a) Since the BSS has received the through connect request for both call legs the oBSS returns the LCLS_CONNECT_CONTROL_ACK message with the LCLS-BSS-Status IE set to "call is locally switched with requested LCLS configuration".

b) The tBSS signals the LCLS status change to the tMSC server by sending the LCLS_NOTIFICATION message with the LCLS-BSS-Status IE set to "call is locally switched with requested LCLS configuration".

c) If the oMSC server supports the option to configure its Access MGW to isolate the access side termination from the network side termination and LCLS negotiation indicated that no succeeding node requires 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.

d) If the tMSC server supports the option to configure its Access MGW to isolate the access side termination from the network side termination and LCLS negotiation indicated that no preceding node requires the UL data from the tUE then the tMSC server requests the tMGW to isolate the access side termination T4 from the network side termination T3.

NOTE: 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].

59. The oMSC server signals the change of the LCLS status through the Core Network by sending the INFO request with the encapsulated APM message with the LCLS-Status IE set to "LCLS connected".

60. The iMSC server returns the 200 OK (INFO) final response to the preceding node.

61. The iMSC server transfers the change of the LCLS status to the succeeding node.

62. The tMSC server returns the 200 OK (INFO) final response to the preceding node.