Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.280  Word version:  17.5.0

Top   Top   Up   Prev   None
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…

 

B  Service continuity for MC serviceWord‑p. 263

B.1  Service continuity between on-network MC service and UE-to-network relay MC service

This annex describes how TS 23.237 mechanisms for IMS service continuity can be used to provide service continuity between on-network MC service and UE-to-network relay MC service. For illustration, MCPTT AS is considered as the MC service.
Only the procedure for service continuity from on-network MCPTT service to UE-to-network relay MCPTT service is described in Figure B.1-1. The procedure for service continuity in the opposite direction is identical.
(not reproduced yet)
Figure B.1-1: Service continuity from on-network to UE-to-network relay
Up
As illustrated in Figure B.1-1:
  • Initially UE-1 has a direct connection to the network (on-network MCPTT service). It is registered with the SIP core and is engaged in a SIP session with the MCPTT Application Server (solid lines SIP‑1 and MCPTT‑1 in Figure B.1-1).
  • When UE-1 realises that it is losing connection to the network, or after the connection to the network has been lost, UE-1 discovers a UE-to-network relay (UE-R) and establishes a PC5 connection with UE-R. UE-1 registers with the SIP core over the target access leg and enters UE-to-network relay MCPTT service by transferring the media streams over the target leg (dashed lines SIP‑1 and MCPTT‑1 in Figure B.1-1).
  • The SIP session is anchored at a Service Centralisation and Continuity Application Server (SCC AS) before and after the handover, as described in TS 23.237.
Depicted in Figure B.1-2 is the call flow for service continuity when the UE switches from on-network MCPTT service to UE-to-network MCPTT relay service.
(not reproduced yet)
Figure B.1-2: Service continuity when UE switches from on-network MCPTT service to UE-to-network relay MCPTT service
Up
Step 0.
UE-1 has a direct connection to the network and is engaged in a SIP session with the MCPTT AS (on-network MCPTT service). The SIP session is anchored at a Service Centralisation and Continuity Application Server (SCC AS) and a Session transfer Identifier (STI) is assigned for the anchored SIP session, as described in TS 23.237.
Step 1.
UE-1 realises that it is losing connection to the network or has completely lost it.
Step 2.
UE-1 (in the role of remote UE) performs ProSe UE-to-network relay discovery over PC5 and establishes a secure point-to-point link with the relay (UE-R) over PC5. As part of this process the remote UE is mutually authenticated at PC5 layer with either the relay or with the network as specified in TS 23.303. In the process UE-1 is also assigned an IP address/prefix by the relay.
Step 3.
UE-1 registers with the SIP core over the UE-to-network relay leg.
Step 4.
In order to transfer the media streams of the SIP session UE-1 sends an INVITE message on the new access leg towards the SCC AS. The INVITE message includes the STI identifying the session to be transferred. The SCC AS identifies the session based on STI and updates the session over the remote access leg i.e. towards the MCPTT AS.
Step 5.
The procedure is completed when all media streams have been transferred on the access leg relayed via UE-R. At this point UE-1 may deregister the on-network leg if it still has direct network connection (not shown in the Figure).
Up

C  Application Priority |R17|Word‑p. 266

C.1  Use of application priorities

Different communications between two or more MC service users need to be distinguished in their urgency in order to appropriately or less preferably allocate 3GPP system transport resources. Also simultaneous incoming communications to a MC service user requires an indication of the urgency in order to preferentially join the communication in accordance with the urgency.
To make this distinction of urgencies, the MC service system necessarily supports different types of priorities and corresponding levels within each priority category representing the relative importance of a request at the application level. The use of application priority allows the MC service system to decide whether a communication establishment or modification request can be accepted or needs to be rejected (e.g. in case of transport resource limitations), or it allows the MC service client to rank simultaneous incoming communication for presentation to an MC service user. Hence the application priority can also be used to decide which existing transport resources (e.g. bearers) to pre-empt during resource limitations. Such pre-emption capability information defines whether a communication can obtain transport resources that were already assigned to another communication with a lower priority level. The pre-emption vulnerability information defines whether a communication can lose the resources assigned to it in order to admit a communication with higher priority level.
The following types of application priorities are provided by the MC service system:
(not reproduced yet)
Figure C.1.-1: Types of application priorities in the MC service system
Up
Communication priority involves a combination of the type of call/communication, the role of the requesting MC service user, and the predefined/requested priority of the initiating MC service user and/or group.
Presentation priority involves the determination of which communications, from within multiple simultaneous possible, are the highest priority to present to the MC service user either audibly or visibly. An example would be a private call received at the same time as an emergency call on a monitored group. This category can be configured uniquely for each MC service user.
Floor priority involves the determination of who can transmit within a communication at a particular time. This is essentially the priority of the MC service user according to its profile, and possibly modified by its role and/or mode of service (e.g. using emergency or imminent peril call). This category is used, for example, to determine the ordering of the floor control queue within an established communication.
Up

$  Change historyWord‑p. 268

Up   Top