Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.280  Word version:  17.5.0

Top   Top   Up   Prev   Next
1…   5…   7…   7.4…   7.5…   8…   9…   10…   10.1.2…   10.1.3…   10.1.5…   10.2…   10.2.3…   10.2.5…   10.3…   10.7…   10.7.3…   10.7.3.7…   10.7.3.10…   10.8…   10.8.4…   10.9…   10.9.3…   10.9.3.8…   10.10…   10.11…   10.12…   10.13…   10.13.3…   10.14…   10.15…   10.15.3…   A…   B…

 

10.3  Pre-established session (on-network)Word‑p. 119

10.3.1  General

A pre-established session is a session established between an MC service client and the MC service server, on a per MC service basis, to exchange necessary media parameters needed for the definition of media bearers, allowing a faster set-up of MC service calls/sessions.
After a pre-established session is established, a media bearer carrying the media and media control messages is always active. The MC service client establishes one or more pre-established sessions to an MC service server after SIP registration, and prior to initiating any MC service related procedures (e.g. calls, sessions) to other MC service users. When establishing a pre-established session, the MC service client negotiates the media parameters, including establishing IP addresses and ports using interactive connectivity establishment (ICE) as specified in IETF RFC 5245 [22], which later can be used in MC service calls/sessions. This avoids the need to negotiate media parameters (including evaluating ICE candidates) and reserving bearer resources during the MC service call/session establishment that results in delayed MC service call/session establishment.
The use of pre-established session on the origination side is completely compatible with the use of on demand session on the termination side. The use of pre-established session on the termination side is completely compatible with the use of on demand session on the origination side.
The pre-established session may be modified by the MC service client and the MC service server using the SIP procedures for session modification.
The pre-established session may be released by the MC service client and the MC service server using the SIP procedures for terminating a SIP session.
Up

10.3.2  Procedures

10.3.2.1  General

The pre-established session can be established after MC service authorization for the user (see TS 23.379).
The pre-established session is a session establishment procedure between the MC service client and the MC service server to exchange necessary media parameters needed for the definition of the media bearers. After the pre-established session is established, the media bearer carrying the floor control messages is always active. Additionally, the MC service client is able to activate the media bearer carrying the voice whenever needed:
  • immediately after the pre-established session procedure; or
  • using SIP signalling when an MC service call is initiated.
Up

10.3.2.2  Pre-established session establishment

The pre-established session is a session between the MC service client and the MC service server in the MC system, and which may utilise other functional entities (e.g. a media distribution function, as defined in subclause 7.4.2.3.5, for means of obtaining media parameters and gathering ICE candidates). Figure 10.3.2.2-1 represents the pre-established session establishment flow.
(not reproduced yet)
Figure 10.3.2.2-1: Pre-established session establishment
Up
Step 1.
The MC service client within the MC service UE gathers ICE candidates.
Step 2.
The MC service client within the MC service UE sends a request to the MC service server to create a pre-established session.
Step 3.
MC service server performs necessary service control, obtains media parameters (e.g. by means of interacting with a media distribution function of the MC service server) and gathers ICE candidates.
Step 4.
MC service server sends a create pre-establish session response to the MC service client within the MC service UE.
Step 5.
ICE candidate pair checks take place e.g. between the MC service client within the MC service UE and a media distribution function of the MC service server.
Step 6.
If necessary the MC service client within the MC service UE sends a modify pre-established session request to the MC service server to update the ICE candidate pair for the pre-established session.
Step 7.
The MC service server sends a modify pre-established session response accepting the ICE candidate pair update.
The media sessions consist of at least an active media session carrying the media and media control messages and an inactive media session for the media.
Up

10.3.2.3  Pre-established session modificationWord‑p. 120
Figure 10.3.2.3-1 represents the pre-established session modification flow.
(not reproduced yet)
Figure 10.3.2.3-1: Pre-established session modification
Up
Step 1.
The MC service client within the MC service UE gathers ICE candidates, if necessary (e.g. depending on the information that needs to be updated).
Step 2.
The MC service client within the MC service UE sends a request to the MC service server to modify a pre-established session.
Step 3.
MC service server performs necessary service control, obtains any necessary media parameters (e.g. by means of interacting with a media distribution function of the MC service server) and gathers necessary ICE candidates.
Step 4.
MC service server sends a modify pre-establish session response to the MC service client within the MC service UE.
Step 5.
If necessary, ICE candidate pair checks take place e.g. between the MC service client within the MC service UE and a media distribution function of the MC service server.
Step 6.
If necessary the MC service client within the MC service UE sends a modify pre-established session request to the MC service server to update the ICE candidate pair for the pre-established session.
Step 7.
The MC service server sends a modify pre-established session response accepting the ICE candidate pair update.
Up

10.3.2.4  Pre-established session releaseWord‑p. 122
Figure 10.3.2.4-1 represents the MC service client within the MC service UE initiated pre-established session release flow and Figure 10.3.2.4-2 represents the MC service server initiated pre-established session release flow.
(not reproduced yet)
Figure 10.3.2.4-1: MC service client within the MC service UE initiated pre-established session release
Up
Step 1.
The MC service client within the MC service UE sends a request to the MC service server to release a pre-established session.
Step 2.
The MC service server sends a release pre-establish session response to the MC service client within the MC service UE.
Step 3.
The MC service server releases all resources for the pre-established session.
 
(not reproduced yet)
Figure 10.3.2.4-2: MC service server initiated pre-established session release
Up
Step 1.
The MC service server sends a request to the MC service client within the MC service UE to release a pre-established session.
Step 2.
The MC service client within the MC service UE sends a release pre-establish session response to the MC service server.
Step 3.
The MC service server releases all resources for the pre-established session.

10.4  Simultaneous session (on-network)Word‑p. 123

10.4.1  General

A simultaneous session is functionality whereby the MC service client can receive the media from multiple MC service calls/sessions over the same SIP session and media bearer(s) between the MC service client and the MC service server.

10.5  Use of UE-to-network relay

10.5.1  UE-to-network relay service authorization

The MC service shall support the capability for UE-to-network relay to restrict the relayed group communication on a per group basis.
To meet the above requirement, ProSe (as specified in TS 23.303) can be used with an appropriate relay service code as per the following:
  • To restrict connection from only the membership of allowed MC service groups, UE-to-network relay UE is provisioned with relay service code(s) associated with allowed MC service group(s). The UE-to-network relay performs the access control as follows:
    1. The UE broadcasts which MC service group(s) is/are authorized to connect to the network over this UE-to-network relay by including the related relay service code(s) in the UE-to-Network Relay Discovery Announcement message (as specified in TS 23.303); or
    2. The UE determines whether to respond to a remote UE's broadcasting message by checking if the relay service code carried in the UE-to-Network Relay Discovery Solicitation message is within the list of allowed relay service codes.
  • To find a permitted UE-to-network relay, a remote UE is provisioned with the relay service code(s) associated MC service group(s) which the MC service user belongs to. The remote UE performs the UE-to-network relay selection as follows:
    1. The remote UE determines if it is allowed to connect to a particular UE-to-network relay by checking whether the relay service code(s) associated with its MC service group(s) is/are carried in UE-to-Network Relay Discovery Announcement message (as specified in TS 23.303; or
    2. The remote UE includes the relay service code(s) associated with its MC service group(s) in Network Relay Discovery Solicitation message (as specified in TS 23.303).
Up

10.5.2  UE-to-network relay MC service

The ProSe UE-to-network relay provides a purely layer 3 IP data routing service, when the remote UE loses the coverage of cellular network and the MC service user on the remote UE requires to access the MC service via a ProSe UE-to-network relay.
The application layer signalling for the MC service user on a remote UE are identical to the application layer signalling for the MC service user on an on network UE.

10.6  General user authentication and authorization for MC services

10.6.1  Primary MC system |R15|

The user authentication process shown in Figure 10.6.1-1 may take place in some scenarios as a separate step independently from a SIP registration phase, for example if the SIP core is outside the domain of the MC service server.
A procedure for user authentication is illustrated in Figure 10.6.1-1. Other alternatives may be possible, such as authenticating the user within the SIP registration phase.
(not reproduced yet)
Figure 10.6.1-1: MC service user authentication and registration with Primary MC system, single domain
Up
Step 1.
In this step the identity management client begins the user authorization procedure. The MC service user supplies the user credentials (e.g. biometrics, secureID, username/password) for verification with the identity management server. This step may occur before or after step 3. In a MC system with multiple MC services, a single user authentication as in step 1 can be used for multiple MC service authorizations for the user.
Step 2.
The signalling user agent establishes a secure connection to the SIP core for the purpose of SIP level authentication and registration.
Step 3.
The signalling user agent completes the SIP level registration with the SIP core (and an optional third-party registration with the MC service server(s)).
Up

10.6.2  Interconnection partner MC system |R15|Word‑p. 124
Where communications with a partner MC system using interconnection are required, user authorization takes place in the serving MC system of the MC service user, using the MCX user service authorization procedure specified in TS 33.180.

10.6.3  Migration to partner MC system |R15|

10.6.3.1  General

The following subclauses describe the procedure used for user authentication and service authorization when migrating to a partner MC system.
To enable migration, the inter-domain MCX user service authorization procedures specified in TS 33.180 are used.

10.6.3.2  Information flows for migrated service authorizationWord‑p. 125
10.6.3.2.1  Migration service authorization request
Table 10.6.3.2.1-1 describes the information flow migration service authorization request sent from the MC service client of the migrating MC service user to the partner MC service server, and from the partner MC service server to the primary MC service server of the migrating MC service user.
Information element Status Description
MC service ID (see NOTE 1)MThe MC service ID of the migrating MC service user provided by the partner MC system.
MC service IDMThe MC service ID of the migrating MC service user in the primary MC system of the MC service user.
MC service user profile index (see NOTE 2)MThe MC service user profile index of the selected MC service user profile.
Up
10.6.3.2.2  Migration service authorization response
Table 10.6.3.2.2-1 describes the information flow migration service authorization response sent from the primary MC service server of the migrating MC service user to the partner MC service server of the migrating MC service user, and from the partner MC service server to the MC service client of the migrating MC service user. This information flow is sent individually addressed on unicast or multicast.
Information element Status Description
MC service ID (see NOTE)MThe MC service ID of the migrating MC service user provided by the partner MC system.
MC service ID (see NOTE)MThe MC service ID of the migrating MC service user in the primary MC system of the MC service user.
ResultMSuccess or failure of the migration MC service authorization request
Up

10.6.3.3  Procedure

The procedure for service authorization for migration to a partner MC system is shown in Figure 10.6.3.3-1.
Pre-conditions
  • The MC service user wishes to migrate to the partner MC system.
  • The MC service client has been configured with an MC service user profile that contains the necessary parameters needed for connectivity with the partner MC system.
  • A user authentication process has taken place which has supplied the necessary credentials to the MC service client to permit service authorization to take place in the partner system.
(not reproduced yet)
Figure 10.6.3.3-1: Service authorization for migration to partner MC system
Up
Step 1.
The MC service client requests migration service authorization with the partner MC service server indicating the selected MC service user profile to be used during migrated MC service. The MC service client provides both the MC service ID provided during user authentication in the partner MC system, and the MC service ID of the MC service user in the primary MC system of the MC service user.
Step 2.
The partner MC service server performs an initial authorization check to verify that the MC service user is permitted to migrate to the partner MC system from the primary MC system of the MC service user.
Step 3.
The partner MC service server identifies the primary MC system of the MC service user of the MC service client by use of the MC service ID of the MC service user in the primary MC system of the MC service user, which was presented by the MC service client in step 1, and sends a migration service authorization request to the gateway server in the partner MC system.
Step 4.
The partner MC system gateway server identifies the primary MC system of the MC service user from the MC service ID presented in step 3, and forwards the migration service authorization request to the gateway server of the primary MC system.
Step 5.
The gateway server in the primary MC system of the MC service user identifies the primary MC service server of the MC service user from the MC service ID presented in step 3, and forwards the migration service authorization request to that MC service server.
Step 6.
The primary MC service server of the MC service user performs an authorization check, to verify that migration is permitted to that partner MC system by this MC service user using the indicated MC service user profile.
Step 7.
The primary MC service server marks the MC service user as having migrated, and records the partner MC system as the migrated MC system.
Step 8.
The primary MC service server sends a migration service authorization response to the gateway server in the primary MC system.
Step 9.
The gateway server in the primary MC system sends the migration service authorization response to the gateway server in the partner MC system.
Step 10.
The gateway server in the partner MC system sends the migration service authorization response to the partner MC service server.
Step 11.
The partner MC service server sends the migration service authorization response to the MC service client, confirming that successful migration and service authorization has taken place.
Up

Up   Top   ToC