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… 
6a.11 Session Replication by remote party  6a.11.1 Session replication initiated by target UE  6a.11.2 Session replication initiated by source UE  6a.11.3 Session replication initiated by source UE (different subscription)  6a.11.4 Session replication initiated by target UE (different subscription)  6a.12 User authorisation and preferences 
...

 

6a.11  Session Replication by remote party |R10|  p. 164

6a.11.1  Session replication initiated by target UE  p. 164

The call flow in the Figure below shows the scenario where UE-2 requests replication of a session ongoing between UE-1 and a remote UE. After the replication procedure is complete, the sessions are independent.
Reproduction of 3GPP TS 23.237, Fig. 6a.11.1-1: Session replication initiated by target UE
Figure 6a.11.1-1: Session replication initiated by target UE
Up
Step 1.
UE-2 obtains information about the existing sessions and their media flows.
Step 2.
UE-2 uses the session information obtained and to send a session replication request towards the SCC AS. The request indicates that this request is for a session replication request.
Step 3.
The SCC AS performs authorization as specified in clause 6a.12; in particular, the SCC AS requests UE-1 to authorize the replication request or the SCC AS authorizes the request on behalf of UE-1 (e.g. pre-configured).
Step 4.
If the request is authorized, UE-2 creates a new session with the remote UE. When the new session is established, the state of the original media is replicated e.g. same playback state; same used media etc. is replicated. If the remote party does not support setting up a replicated session, the flow will fail.
Step 5.
A new session, where the media is a replica of Media-A, is established between UE-2 and the remote UE.
Up

6a.11.2  Session replication initiated by source UE  p. 165

The call flow in the Figure below shows the scenario where UE-1 requests replication of a session ongoing between UE 1 and a remote UE to UE-2. After the replication procedure is complete, the sessions are independent. As a pre-requisite, there exists a Session with Media-A on UE-1.
Reproduction of 3GPP TS 23.237, Fig. 6a.11.2-1: Session replication initiated by source UE
Figure 6a.11.2-1: Session replication initiated by source UE
Up
Step 1.
UE-1 requests to replicate current session to UE-2 by sending Session Replication Request to SCC AS. The Session Replication Request should contain enough information for the SCC AS to:
  • identify that the session replication source is UE-1;
  • identify that the session replication target is UE-2;
  • identify the remote party.
Step 2.
SCC AS performs authorization as specified in clause 6a.12; in particular, the SCC AS checks UE-1 is eligible to request session replication for UE under the same subscription.
Step 3.
SCC AS sends Session Replication request to controllee UE-2.
Step 4.
UE-2 responses to the Session Replication request.
Step 5.
UE-2 initiates a new session with the remote UE. When the new session is established, the state of the original media is replicated, e.g. same playback state, same used media, etc. is replicated. If the remote party does not support setting up a replicated session, the flow will fail.
Step 6.
A new session, where the media are replica of Media-A, is established between UE-2 and the remote UE.
Up

6a.11.3  Session replication initiated by source UE (different subscription)  p. 166

The call flow in the Figure below shows the scenario where UE-1 requests replication of a session ongoing between UE 1 and a remote UE to UE-2. After the replication procedure is complete, the sessions are independent. As a pre-requisite, there exists a Session Media-A on UE-1.
Reproduction of 3GPP TS 23.237, Fig. 6a.11.3-1: Session replication initiated by source UE, different subscriptions
Figure 6a.11.3-1: Session replication initiated by source UE, different subscriptions
Up
Step 1.
UE-1 requests to replicate current session to UE-2 by sending Session Replication Request to SCC AS-1. The Session Replication Request should contain enough information for the SCC AS to:
  • identify that the session replication source is UE-1;
  • identify that the session replication target is UE-2;
  • identify the remote party.
Step 2.
SCC AS-1 identify UE-2 is not under the same subscription as UE-1. It forwards the request to S-CSCF-2 that serves UE-2 together with the information of session on UE-1. S-CSCF-2 further forwards the request to SCC AS-2 that serves UE-2.
Step 3.
SCC AS-2 performs authorization as specified in clause 6a.12, then sends Session Replication request together with UE-1 session information to UE-2.
Step 4.
UE-2 decides to accept or reject the Session Replication request.
Step 5.
If the request is accepted by UE-2, UE-2 initiates a new session with the remote UE. When the new session is established, the state of the original media is replicated, e.g., same playback state, same used media, etc. is replicated.
Step 6.
SCC AS-2 sends Media Replication result to UE-1. A new session, where the media are replica of Media-A, is established between UE-2 and the remote UE.
Up

6a.11.4  Session replication initiated by target UE (different subscription)  p. 167

The call flow in the Figure below shows the scenario where UE-2 requests replication of a session ongoing between UE-1 and a remote UE. UE-1 and UE-2 belongs to different subscriptions. After the replication procedure is complete, the sessions are independent.
Reproduction of 3GPP TS 23.237, Fig. 6a.11.4-1: Session replication initiated by target UE, different subscriptions
Figure 6a.11.4-1: Session replication initiated by target UE, different subscriptions
Up
Step 1.
UE-2 obtains information about the existing sessions and their media flows. This information will be sent by the AS serving UE-1 i.e. SSC AS-1 and relayed to UE-1 by SCC AS-2.
Step 2.
UE-2 uses the session information obtained and to send a session replication request towards the SCC AS-2, which relays the request to SCC AS-1. The request indicates that this request is for a session replication request.
Step 3.
The SCC AS-1 performs authorization as specified in clause 6a.12; in particular, the SCC AS-1 requests UE-1 to authorize the replication request or the SCC AS-1 authorizes the request on behalf of UE-1 (e.g. pre-configured).
Step 4.
If the request is authorized, UE-2 creates a new session with the remote UE. When the new session is established, the state of the original media is replicated e.g. same playback state; same used media etc. is replicated. If the remote party does not support setting up a replicated session, the flow will fail.
Step 5.
A new session, where the media is a replica of Media-A, is established between UE-2 and the remote UE.
Up

6a.12  User authorisation and preferences |R10|  p. 168

There are two different kinds of authorization in the IUT architecture:
Authorization by the SCC AS. The SCC AS responsibilities includes:
  • checking that the subscription allows the requested operation
  • enforcing network based user preferences, e.g. check whether other UEs shall be allowed to retrieve session information related to the UE.
  • enforcing restrictions provided by the remote party network. The SCC AS shall reject requests for Inter-UE Transfer operations on sessions where the remote party is served by a network that has expressed preferences to restrict Inter-UE transfer actions on on-going sessions between the remote party and an IUT user served by the SCC AS.
Authorization of incoming request by the UE. The UE based authorization includes:
  • authorization through end-user interaction, e.g. the end user authorizes requests for IUT Media Control Related Procedures by pressing a button on the device.
  • automatic authorization by UE configuration, e.g. the UE automatically authorizes requests for IUT Media Control Related Procedures from a specific device.
The UE based authorization is considered to be a local implementation of the UE.
If the user requires configuring IUT authorisation and preference settings to the SCC AS, this shall be possible via the Ut interface. The information that can be configured includes:
  • UEs authorised by the user to perform the IUT Media Control Related Procedures; and
  • authorisation for the SCC AS to preferentially route incoming session invitations from the remote party towards Controller capable UE(s). The user may additionally define criteria to determine whether to preferentially route incoming session invitations from the remote party towards Controller capable UE(s). It shall be possible to apply, for example, the following criteria and combinations of the following criteria to the incoming request:
    • Calling party identity (Public User Identity);
    • Called party identity used;
    • Identification of the Service (Service Identifier); and
    • Media types being offered in the incoming request.
The SCC AS shall take in account operator policy and the above user preferences when determining:
  • whether the UE is authorised to perform the Controller UE functions, and
  • whether to preferentially route incoming session requests from a remote party towards Controller capable UE(s).
Up

6b  Void

Up   Top   ToC