Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.284  Word version:  18.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…

 

8.3  GSM to UMTSp. 76

8.3.1  Intra-MSC GSM to UMTS Relocationp. 76

8.3.1.1  Generalp. 76

When a call is locally switched through the BSS and an intra-MSC GSM to UMTS handover occurs, the LCLS shall be broken and the user plane shall be connected via the core network. The Intra-MSC GSM to UMTS relocation procedure specified in TS 23.205 and TS 23.231 shall be followed. The following clauses describe the additional requirements for intra-MSC GSM to UMTS handovers of LCLS related calls.
To this end the BSS which is in local switch which is serving the user equipment which is not moving to the RNC bicasts user data UL to the core network so that immediately the user equipment which is moving is attached to the RNC it can receive DL data from the core network.
During a Locally Switched (intra-BSS) Connection when no bicasting occurs there is no data transmission through the core network. In this release the use plane is kept active and therefore does not need to be re-activated when the LCLS is broken due to GSM to UMTS handover out of LCLS.
Up

8.3.1.2  Handover Requiredp. 76

When the MSC server receives the Handover Required message from the serving BSS, it requests the MGW to provide a binding reference and a bearer address using the Prepare Bearer procedure. The MSC server shall use the Change Flow Direction procedure to request the MGW to set the Handover Device to the initial state, see clause 8.4.1.1.3.

8.3.1.3  Iu Relocation Request Acknowledgep. 76

Upon receipt of the Relocation Request Acknowledge message, the MSC Server shall send to the adjacent call node the LCLS-Status-Change-Request message to indicate "LCLS Disconnection-Preparation-for handover".
When the far end MSC server receives the LCLS-Status-Change-Request message indicating LCLS Disconnection preparation-for-handover it shall send to the BSS the LCLS_Connect_Control message with the LCLS-Connection-Status-Control IE indicating "BicastatHandover". When the LCLS_Connect_Control acknowledge message is received from the BSS, the far end MSC server shall return the LCLS Status Change Request Acknowledge message indicating "LCLS Disconnection-Preparation-for-handover" and a Result code indicating LCLS Status Change Request accepted.
Up

8.3.1.4  Handover Command/Iu Relocation Detectp. 76

When the MSC server sends the Handover Command message or alternatively if it receives the Relocation Detect message, if the MSC server followed the MGW control procedures for a non-LCLS call and kept the Termination to the Serving BSS connected then it shall use the Change Flow Direction procedure to requests the MGW to set the Handover Device to intermediate state. However if the MSC server isolated TS and set TT to bothway through-connected then no MGW control procedure is required at this point.
Upon receipt of the Relocation Detect message the MSC Server shall send to the adjacent call node the LCLS-Status-Change-Request message with the LCLS-Status-Change-Request IE set to "Indicate DL data after Handover".
When the far end MSC server receives the LCLS-Status-Change-Request message with the LCLS-Status-Change-Request IE set to "Indicate DL data after Handover" it shall send to the BSS the LCLS_Connect_Control message with the LCLS-Connection-Status-Control IE indicating "DL Data_at_Handover" and after reception of the LCLS_Connect_Control acknowledge message from the BSS, return the LCLS-Status-Change-Request-Acknowledge message with "Indicate DL data after Handover" and a Result code indicating LCLS Status Change Request accepted.
Up

8.3.1.5  Iu Relocation Completep. 77

When the MSC server receives the Iu Relocation Complete message, it releases the A-interface line towards the serving BSS. The MSC server also requests the MGW to set the Handover Device to its final state by removing the bearer termination (TS) towards the serving BSS.
The MSC server shall send to the adjacent call node the LCLS-Status-Update message with the LCLS-Status IE indicating the LCLS is disconnected.
When the serving BSS receives Clear Command it shall release any local switch path. The serving BSS shall inform the far end MSC server that LCLS is broken with the LCLS-Notification message.
Up

8.3.1.6  Examplep. 77

8.3.1.6.1  Connection Modelp. 77
Figure 8.3.1.6.1.1 shows the network model for Intra-MSC GSM to UMTS Handover, where the call leg pertinent to the UE-1 is handed over from the serving BSS-1 to the Target RNC. BSS-1 is the same as BSS-2 when LCLS is established for the call. The bearer termination T2 is used for the bearer towards BSS-2, which is not affected by this handover. Bearer termination TS is used for the bearer towards BSS-1 and the bearer terminations T1 and TA are used for the bearer towards the succeeding/preceding MGW. Bearer termination TT is for the bearer termination towards the Target RNC. The colours and line types used in the Figure are defined differently from TS 23.205 to indicate LCLS specific issues.
Copy of original 3GPP image for 3GPP TS 23.284, Fig. 8.3.1.6.1.1: Network model for Intra-MSC GSM to UMTS Handover that breaks LCLS
Up
8.3.1.6.2  Basic Sequence for GSM to UMTS Handover that breaks Local Switchingp. 81
Figure 8.3.1.6.2.1 shows the signalling flow for GSM to UMTS handover that breaks Local Switching.
Copy of original 3GPP image for 3GPP TS 23.284, Fig. 8.3.1.6.2.1: Intra-MSC GSM to UMTS Handover that terminates Local Switching
Up
Step 1.
The Handover Required message is received from BSS-1 requesting an intra-MSC GSM to UMTS handover. The call is currently locally switched so the MSC-1 server can know that the GSM to UMTS handover at one end will break local switch (the local switch is not broken in the serving BSS (BSS-1) until the UE-1 has moved from BSS-1 and the MSC-1 server has sent the Clear Command message to the BSS-1).
Step 2.
In this example the Anchor MSC-1 server requests from its MGW-1 the seizure of the bearer termination TT towards the Target RNC and through-connects it bothway to TA. Additionally it isolates the old serving Termination TS. This makes the GSM to UMTS handover more efficient than current non-LCLS GSM to UMTS handovers as immediately when the UE-1 is handed over to the target RNC it will be able to send UL user data to the UE-2.
Step 3.
Anchor MSC-1 server sends the Iu Relocation Request message to the target RNC.
Step 4.
The target RNC returns the Iu Relocation Request Acknowledge message.
Step 5.
Anchor MSC-1 server shall send the LCLS-Status-Change-Request message to the succeeding MSC server asking it to prepare for LCLS disconnection due to handover to trigger the far end MSC-2 server to send the LCLS-Connect-Control message to BSS-2.
Step 5a.
The far end MSC-2 server requests the BSS-2 to start sending data UL with the LCLS_Connect_Control message and the LCLS-Connection-Status-Control IE indicating "BicastatHandover", see Figure 8.3.1.6.1.1 Connection Model 2. This triggers the BSS-1 to bicast the user plane data in the same way as the Access MGW-1 would be doing in a non-LCLS inter-BSS handover. At this point the BSS-1 shall send any DL data it receives directly to the served UE. Since the BSS-1 cannot receive DL data at the same time as it receives local data (TS is isolated) this will minimise the break in user plane data even more than for existing non-LCLS handover.
Step 5b.
BSS-2 sends the LCLS_Connect_Control_Ack message with the LCLS-BSS-Status IE set to "the call is locally switched with requested LCLS configuration".
Step 6.
Anchor MSC-1 server triggers the Handover Command message. When the UE-1 moves to the Target RNC in this example it can immediately send UL data through the CN to the UE-2 and also can receive DL data from the UE-2 via the CN since the MGW-1 topology for TA, TT is already bothway connected. This is a change from the current non-LCLS solution but is more efficient since the non-LCLS solution needs to set this to one-way DL only until it receives Iu Relocation Detect message.
Step 7.
MSC-2 Server sends LCLS-Status-Change-Request-Acknowledgement.
Step 8.
UE-1 is detected at the target RNC. BSS-1/BSS-2 may continue to send the user plane data locally until the Clear Command message is received.
Step 8a.
The MSC-1 Server sends LCLS-Status-Change-Request to indicate that UE-1 has been detected in the target BSS and user data is now being sent through the CN and DL to the distant UE-2.
Step 8b.
The MSC-2 Server signals to the BSS-2 that DL data received from the CN is now real user data coming from the UE-1.
Step 8c.
The BSS-2 sends the LCLS_Connect_Control_Ack message with the LCLS-BSS-Status IE set to "the call is locally switched with requested LCLS configuration".
Step 8d.
Acknowledgement back through the CN that the indication for DL data after Handover Detect has been delivered.
Step 9.
When the MSC-1 Server receives the Iu Relocation Complete message MSC-1 Server knows that the call is not possible to be locally switched.
Step 10.
MSC-1 server requests the old serving BSS-1 to clear the old call leg. BSS-1 stops sending locally the user data from UE-1, LCLS is broken.
Step 11.
Serving BSS-2 informs the MSC-2 server that LCLS is broken via LCLS_Notification message.
Step 12.
Clearing of the old call leg to the Serving BSS-1 is completed.
Step 13.
The termination TS to the old serving BSS-1 is removed from the Access MGW-1.
Step 14.
Anchor MSC-1 server informs succeeding CN nodes that LCLS is disconnected.
Up

Up   Top   ToC