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.237  Word version:  18.0.0

Top   Top   Up   Prev   Next
0…   4…   5…   5.4…   6…   6.2…   6.2.2…   6.3…   6.3.2…   6.3.2.1.3…   6.3.2.1.7…   6.3.2.1.9…   6.3.2.2…   6.3.2.3…   6.3.2.3.6…   6.3.3…   6.4…   6a…   6a.3…   6a.4…   6a.4.3…   6a.4.5…   6a.4.7…   6a.4a…   6a.5…   6a.6…   6a.7…   6a.8…   6a.9…   6a.10…   6a.11…   6c…   7…   A…   B…   C… 
6.3.2.1.7 PS - CS Access Transfer: PS to CS - Dual Radio, mid-call service with one inactive speech and video session  6.3.2.1.7a PS - CS Access Transfer: PS to CS - Single Radio, mid-call service with an incoming waiting call in alerting phase  6.3.2.1.7b PS - CS Access Transfer: PS to CS - Single Radio, mid-call service with an outgoing call in pre-alerting state or in alerting phase  6.3.2.1.7c PS - CS Access Transfer: PS to CS - Single Radio, mid-call service with an incoming call in alerting phase and a held session  6.3.2.1.8 PS - CS Access Transfer: Conferencing - for UEs not using ICS capabilities 
...

 

6.3.2.1.7  PS - CS Access Transfer: PS to CS - Dual Radio, mid-call service with one inactive speech and video session |R9|  p. 68
Figure 6.3.2.1.7-1 PS to CS with one inactive speech and video session, using SCUDIF, provides an information flow for Access Transfer of multiple IMS sessions in PS to CS direction. The flow requires that the user is inactive in an IMS originating or terminating speech and video session using PS media at the time of initiation of Access Transfer to CS and that the use of network capabilities to support mid-call services during session transfer is possible. It also requires that SCUDIF feature is supported by the UE and the CS network.
Reproduction of 3GPP TS 23.237, Fig. 6.3.2.1.7-1: PS to CS with one inactive speech and video session, using SCUDIF
Figure 6.3.2.1.7-1: PS to CS with one inactive speech and video session, using SCUDIF
Up
Step 1.
Standard procedure as specified in clause 6.3.2.1.1 PS - CS Access Transfer: PS to CS is used for transferring the active voice session. The UE indicates SCUDIF support and provides two bearer capabilities (voice and multimedia) with voice preferred when initiating the transfer. Also, the SCC AS provides session state information on the inactive speech and video session including needed STI on the transferring-in leg to the MSC Server.
Step 2.
The MSC Server initiates session transfer towards SCC AS for the additional inactive speech and video session on behalf the UE.
Step 3.
The Source Access Leg associated with the inactive speech and video session is released as specified in clause 6.3.1.6.
Subsequently, the UE can switch between the speech and video session and the voice session with different bearer capabilities activated using SCUDIF feature as specified in TS 23.292.
If SCUDIF is not supported, the transfer can be performed as Figure 6.3.2.1.7-1 with the differences that in step 1 the UE initiates Access Transfer not using SCUDIF, and after the transfer redial mechanism can be used to switch between the speech and video call and the voice call as specified in TS 23.292.
Up
6.3.2.1.7a  PS - CS Access Transfer: PS to CS - Single Radio, mid-call service with an incoming waiting call in alerting phase |R10|  p. 69
Figure 6.3.2.1.7a-1 provides an information flow for Access Transfer of media of an IMS session in PS to CS direction for Access Transfers as specified in TS 23.216.
The flow requires that the user is active in an IMS originating or terminating session and an incoming waiting call is indicated to the user which is in call waiting state; procedures and capabilities specified in TS 23.216 are used for the switching of access networks at the transport layer.
Reproduction of 3GPP TS 23.237, Fig. 6.3.2.1.7a-1: PS-CS: PS to CS - Single Radio, mid-call service with an incoming waiting call in alerting phase
Figure 6.3.2.1.7a-1: PS-CS: PS to CS - Single Radio, mid-call service with an incoming waiting call in alerting phase
Up
Step 1-4.
Standard procedures are used to initiate a SIP session towards the UE, which has already an ongoing session. The UE is notifying the user for the incoming waiting session.
Step 5.
Procedures specified in TS 23.216 result in an INVITE to be sent with an STN-SR indicating use of Single Radio VCC procedures for Access Transfer to CS access. If the user is not IMS registered by the MSC Server, the MSC Server enhanced for SRVCC includes the C-MSISDN as calling party number. If the user is registered in the IMS by the MSC Server, then the MSC Server includes the GRUU into the session transfer request. The MSC Server indicates its capability to support mid-call services during session transfer.
Step 6.
Standard procedures are used at I/S-CSCF for routeing of the INVITE to the SCC AS.
Step 7.
The SCC AS uses the STN-SR to determine that Access Transfer using Single Radio VCC is requested. The SCC AS may retrieve the C-MSISDN from the HSS. The SCC AS identifies the correct anchored session. The SCC AS proceeds with the Access Transfer of the recently added active session with bi-directional speech for the UE by updating the Remote Leg with the media description and other information using the Remote Leg Update procedure as specified in clause 6.3.1.5.
Step 8.
The SCC AS provides session state information on the incoming waiting call in alerting state.
Step 9.
The S-CSCF forwards the session state information to the MSC Server.
Step 10.
The MSC Server receives the Session State Information which indicates one active and one session in alerting state. The MSC Server initiates Access Transfer towards SCC AS for the alerting session.
Step 11.
The MSC moves to the corresponding CS call state for the alerting session, e.g. Call Received in TS 24.008.
Step 11b.
In parallel to step 11, the UE has received the HO command as described in TS 23.216. The UE determines the local call states in the SIP sessions, and creates the corresponding CS call states. The UE continues to indicate the user about for the incoming waiting call.
Step 12.
The user answers the waiting call and the UE locally swaps the active call with the waiting call.
Step 12b.
UE has one active and one held call.
Step 13.
The UE uses the standard procedure to send the CS set call hold for the previously active call to MSC. The UE uses the standard procedure to send the CS connect message for the alerting call to MSC as e.g. described in TS 24.008.
Step 13b.
The MSC has one active and one held call for the UE.
Step 14.
The MSC notifies the SCC AS the user has swapped the two sessions, i.e. the user has answered the previously alerting call, and put the previously active call on hold.
Step 15.
Standard procedures are used at S-CSCF for routeing of the notification to the SCC AS.
Step 16.
The SCC AS creates the corresponding SIP request to the remote end and updates the remote leg.
Up
6.3.2.1.7b  PS - CS Access Transfer: PS to CS - Single Radio, mid-call service with an outgoing call in pre-alerting state or in alerting phase |R10|  p. 71
Figure 6.3.2.1.7b-1 provides an information flow for Access Transfer of media of an IMS session in PS to CS direction for Access Transfers as specified in TS 23.216.
The flow requires that the user has a held IMS originating or terminating session and an outgoing IMS session in early dialogue phase (i.e. pre-alerting or alerting); procedures and capabilities specified in TS 23.216 are used for the switching of access networks at the transport layer. The Held session is being transferred (step 5-7) first by the network prior to the alerting session (step 10).
Reproduction of 3GPP TS 23.237, Fig. 6.3.2.1.7b-1: PS-CS: PS to CS - Single Radio, mid-call service with an outgoing call in pre-alerting or in alerting phase
Figure 6.3.2.1.7b-1: PS-CS: PS to CS - Single Radio, mid-call service with an outgoing call in pre-alerting or in alerting phase
Up
Step 1-4.
Standard procedures are used to initiate a SIP session from the UE, which has already an IMS session (held). The remote end is either alerting the user for the incoming voice session or the call is in pre-alerting state and announcements may be played the UE. Access bearer for voice or video is setup during this step for the UE.
Step 5.
Procedures specified in TS 23.216 result in an INVITE to be sent with an STN-SR indicating use of Single Radio VCC procedures for Access Transfer to CS access. If the user is not IMS registered by the MSC Server, the MSC Server enhanced for SRVCC includes the C-MSISDN as calling party number. If the user is registered in the IMS by the MSC Server, then the MSC Server includes the GRUU into the session transfer request. The MSC Server indicates its capability to support mid-call services during session transfer.
Step 6.
Standard procedures are used at I/S-CSCF for routeing of the INVITE to the SCC AS.
Step 7.
The SCC AS uses the STN-SR to determine that Access Transfer using Single Radio VCC is requested. The SCC AS may retrieve the C-MSISDN from the HSS. The SCC AS identifies the correct anchored session (i.e. the held session). The SCC AS proceeds with the Access Transfer of the held session for the UE by updating the Remote Leg with the media description and other information using the Remote Leg Update procedure as specified in clause 6.3.1.5.
Step 8.
The SCC AS provides Session State Information that the outgoing speech call in early dialog state (e.g. pre-alerting state or alerting state) and other session information as specified in clause 6.3.2.1.4a.
Step 9.
The S-CSCF forwards the Session State Information to the MSC Server.
Step 10.
The MSC Server receives the Session State Information which indicates one held session and one session in early dialog state. The MSC Server initiates Access Transfer towards SCC AS for the alerting or pre-alerting session.
Step 11.
The MSC moves to the corresponding CS call state, e.g. Call Delivered or Mobile Originating Call Proceeding state specified in TS 24.008.
Step 11b.
In parallel to step 11, the UE has received the HO command as described in TS 23.216. The UE determines the local call state in the SIP session, and creates the corresponding CS call state, e.g. Call Delivered in TS 24.008 for the alerting state, or Mobile Originating Call Proceeding for the pre-alerting state. The UE ensures that the same ring back tone or announcement if any is played to the end user.
Step 12.
The remote end answers to the call.
Step 13.
The SCC AS notifies the MSC the remote end has answered the call.
Step 14.
Standard procedures are used at S-CSCF for routeing of the notification to the MSC.
Step 15.
The MSC uses the standard procedure to send the CS connect message to UE as e.g. described in TS 24.008.
Step 16.
The MSC has one active and one held call for the UE.
Step 17.
The UE has one active and one held call.
Up
6.3.2.1.7c  PS - CS Access Transfer: PS to CS - Single Radio, mid-call service with an incoming call in alerting phase and a held session |R10|  p. 73
Figure 6.3.2.1.7c-1 provides an information flow for Access Transfer of media of an IMS session in PS to CS direction for Access Transfers as specified in TS 23.216.
The flow requires that the user has a held IMS originating or terminating session and an incoming call in alerting state; procedures and capabilities specified in TS 23.216 are used for the switching of access networks at the transport layer. The Held session is being transferred (step 5-7) first by the network prior to the alerting session (step 10).
Reproduction of 3GPP TS 23.237, Fig. 6.3.2.1.7c-1: PS-CS: PS to CS - Single Radio, mid-call service with an incoming call in alerting phase
Figure 6.3.2.1.7c-1: PS-CS: PS to CS - Single Radio, mid-call service with an incoming call in alerting phase
Up
Step 1-4.
Standard procedures are used to initiate a SIP session towards the UE, which has already an IMS session (held). The UE is notifying the user for the incoming session.
Step 5.
Procedures specified in TS 23.216 result in an INVITE to be sent with an STN-SR indicating use of Single Radio VCC procedures for Access Transfer to CS access. If the user is not IMS registered by the MSC Server, the MSC Server enhanced for SRVCC includes the C-MSISDN as calling party number. If the user is registered in the IMS by the MSC Server, then the MSC Server includes the GRUU into the session transfer request. The MSC Server indicates its capability to support mid-call services during session transfer.
Step 6.
Standard procedures are used at I/S-CSCF for routeing of the INVITE to the SCC AS.
Step 7.
The SCC AS uses the STN-SR to determine that Access Transfer using Single Radio VCC is requested. The SCC AS may retrieve the C-MSISDN from the HSS. The SCC AS identifies the correct anchored session (i.e. the held session). The SCC AS proceeds with the Access Transfer of the held session for the UE by updating the Remote Leg with the media description and other information using the Remote Leg Update procedure as specified in clause 6.3.1.5.
Step 8.
The SCC AS provides session state information that the incoming speech call in alerting state and other session information as specified in clause 6.3.2.1.4a.
Step 9.
The S-CSCF forwards the session state information to the MSC Server.
Step 10.
The MSC Server receives the Session State Information which indicates one held and one session in alerting state. The MSC Server initiates Access Transfer towards SCC AS for the alerting session.
Step 11.
The MSC moves to the corresponding CS call state for the alerting session, e.g. Call Received in TS 24.008.
Step 11b.
In parallel to step 11, the UE has received the HO command as described in TS 23.216. The UE determines the local call states in the SIP sessions, and creates the corresponding CS call states. The UE continues to indicate the user about for the incoming call.
Step 12.
The user answers the incoming call and the UE locally swaps the active call with the incoming call.
Step 12b.
UE has one active and one held call.
Step 13.
The UE uses the standard procedure to send the CS connect message for the alerting call to MSC as e.g. described in TS 24.008.
Step 13b.
The MSC has one active and one held call for the UE.
Step 14.
The MSC notifies the SCC AS the user has answered the call.
Step 15.
Standard procedures are used at S-CSCF for routeing of the notification to the SCC AS.
Step 16.
The SCC AS creates the corresponding SIP request to the remote end and updates the remote leg.
Up
6.3.2.1.8  PS - CS Access Transfer: Conferencing - for UEs not using ICS capabilities |R10|  p. 75
When the UE is using a conference service and Access Transfer between PS and CS access networks happens, the conference information should be provided by the SCC AS.
The following procedures require that the use of network capabilities to support MSC Server assisted mid-call feature during Access Transfer is supported by the UE and the network according to clause 6.3.2.1.1a, clause 6.3.2.1.4a or clause 6.3.2.1.6 for PS to CS Access Transfer, and according to clause 6.3.2.1.2a for CS to PS Access Transfer. They further require that the MSC Server is enhanced for ICS as specified in TS 23.292.
When the UE in an on-going conference performs Access Transfer from PS to CS, the SCC AS shall provide the conference information (i.e. conference URI, identifier of all participants, etc.) to the MSC Server on the Target Access Leg. When the MSC Server receives the conference information, it shall create a conference state in CS access network (i.e. call in MPTY). When multiple multi-media sessions including a conference exist, if the active session being transferred or the selected additional session to be transferred is a conference call, the conference information shall also be included in the session state information to be sent by the SCC AS to the MSC Server. The MSC Server enhanced for ICS using the conference information then performs conference control on behalf of the UE as specified in clause 7.6.2.8 of TS 23.292. The MSC Server not enhanced for ICS performs conference control as specified in clause 7.6.3.6 of TS 23.292 after the Access Transfer from PS to CS.
MSC Server enhanced for ICS or the MSC Server not enhanced for ICS may subscribe the conference related events in IMS after the access transfer from PS to CS and when the MSC server receives the conference related events, it should inform the UE of the events.
When the UE in an on-going conference performs Access Transfer from CS to PS, the SCC AS shall provide the conference information (i.e. conference URI, etc.) to the UE on the Target Access Leg. When multiple sessions including a conference exist, if the active session being transferred or the additional held session is a conference call, the conference information shall also be included in the Session State Information to be sent by the SCC AS to the UE. The UE then uses the conference information to control the conference in PS domain as specified in TS 24.147.
Up

Up   Top   ToC