Content for TS 23.228 Word version: 19.0.0

1… 3… 4… 4.2.4… 4.3… 4.4… 4.13… 4.16… 5… 5.2… 5.3… 5.4… 5.4.7… 5.4.8… 5.4a… 5.5… 5.5.3… 5.6… 5.6.3… 5.7… 5.7.3… 5.7.5… 5.7.8… 5.8… 5.10… 5.11… 5.11.3… 5.11.3.3 5.11.3.4 5.11.4… 5.11.5… 5.11.5.3… 5.11.6… 5.12… 5.16… 5.16.2… 5.19… 5.20… A… E… E.2.2… G… G.5… H I… J… K… L… M… M.3… N… P… Q… Q.2.5… R… S… T… U… U.2… V… W… X… Y… Z… AA… AA.3… AB… AC… AC.7… AC.7.2… AC.7.2.2 AC.7.2.3… AC.7.4… AC.9… AC.10…

5.16.2 Session-based Messaging 5.16.2.0 General 5.16.2.1 Architectural principles 5.16.2.2 Procedures to enable Session based Messaging 5.16.2.2.0 General 5.16.2.2.1 Session based messaging procedure to registered Public User Identity 5.16.2.2.2 Session based messaging procedure using multiple UEs 5.16.2.2.3 Session based messaging procedure with an intermediate node 5.16.2.2.4 Session based messaging release procedure 5.16.2.2.5 Session based messaging release procedure with an intermediate node 5.17 Refreshing sessions
...

5.16.2 Session-based Messaging p. 195

5.16.2.0 General p. 195

This clause describes architectural concepts and procedures for fulfilling the requirements for Session-based Messaging described in TS 22.340.

5.16.2.1 Architectural principles p. 195

Session-based IMS messaging communications shall as much as possible use the same basic IMS session delivery mechanisms (e.g. routing, security, service control) as defined in clause 4 and 5 of this document. For session based messaging the session shall include a messaging media component, other media components may also be included.

As the messaging media component usually does not require QoS beyond best-effort, use of the preconditions mechanism as defined in RFC 3312 is not required for session based messaging establishment that only includes a messaging media component.

Once the session containing a messaging media component is established, messages in the session are transported between the session participants as per the parameters defined in the messaging media component part of the session description (SDP).

The invited UE shall host the message session (accept a connection for the message session from the other endpoint). In order to host the message session the UE needs an appropriate IP-CAN bearer, on which it can accept the connection for the message media component. This IP-CAN bearer may be e.g. a general purpose bearer available prior to starting the session initiation or a dedicated bearer that is established during session establishment. Messages within a message session should be transported over a connection-oriented reliable transport protocol. Message sessions may be either established end to end between two UEs or may involve one or more intermediate nodes (e.g. a chat server for multi party chat or an Application Server to perform per message charging).

For addressing chat-group-type session based messaging the concept of Public Service Identities is used.

Session based messaging is available for users that are registered in the IMS.

The session based messaging shall be able to provide the following functionality:

Per-message-based charging, as well as content- and size-based charging.
Operator-controlled policy to be set on the size and content of the messages.
Support for indication of maximum message content size that a UA will accept to be received.
Support for a messaging media component as part of a session where other media components are also included.
Support for messaging-only sessions.

If charging mechanisms like charging based on the message content, message type or number of sent and/or received messages (see TS 22.340) are required, then an intermediate node (messaging AS) shall be involved, which is able to inspect the SIP signalling as well as the exchanged messages and their content. Such an intermediate node may also provide support for time- and/or volume based charging.

5.16.2.2 Procedures to enable Session based Messaging p. 196

5.16.2.2.0 General p. 196

IMS users shall be able to exchange session-based messages with each other by using the procedures described in this clause. These procedures shall allow the exchange of any type of multimedia content (subject to possible restrictions based on operator policy and user preferences/intent), for example but not limited to:

Pictures, video clips, sound clips with a format defined in the respective access specific documents.

5.16.2.2.1 Session based messaging procedure to registered Public User Identity p. 196

The following procedure shows the establishment of a message session between two registered UEs where the UEs are able to exchange messages end-to-end. The signalling flow is based on the general flow shown in clause 5.7a of this specification.

Reproduction of 3GPP TS 23.228, Fig. 5.48a: Message session establishment

Figure 5.48a: Message session establishment

Step 1-30.

These steps are identical to the steps 1 to 30 in the flow of clause 5.7a. After that the message session is established. For session based messaging the SDP offer in the first INVITE request may indicate the maximum message size UE#1 accepts to receive and the 200 OK (Offer response) to the INVITE request may indicate the maximum message size UE#2 accepts to receive.

For MPS for Messaging, the following exception at step 3 in the referenced flow applies: If P-CSCF#1 has received the MPS for Messaging indication for the UE as set (enabled), P-CSCF#1 sets the Resource-Priority information on the INVITE request to a value appropriate for MPS.

Step 31.

UE#1 establishes a reliable end-to-end connection with UE#2 to exchange the message media.

Step 32.

UE#1 generates the message content and sends it to UE#2 using the established message connection.

Step 33.

UE#2 acknowledges the message with a response that indicates that UE#2 has received the message. The response traverses back to UE#1. After receiving the message UE#2 renders the multimedia content to the user.

Further messages may be exchanged in either direction between UE#1 and UE#2 using the established connection. The size of the messages exchanged within the session shall be within the size limits indicated by UE#1 and UE#2 respectively.

5.16.2.2.2 Session based messaging procedure using multiple UEs p. 197

Session based messaging between more than two UEs require the establishment of a session based messaging conference.

Within session based messaging conferences including multiple UEs (e.g. multiparty chat conferences) an MRFC/MRFP or an IMS AS shall be used to control the media resources.

When MRFC/MRFP are used, then conferencing principles are used to provide the chat service:

MRFP must be able to establish message connections with all involved parties.
MRFC/MRFP must be able to receive messages from conference participants and to distribute messages to all or some of the participants.
In order to enable the UE managing information related to the session based messaging conference the MRFC may be co-located with an IMS AS.
MRFC/MRFP roles and interactions with an AS are described in more detail in clauses 4.7, 5.14.1 and 5.14.2.
The interface for session based messaging between MRFC and MRFP is not standardised in this release. When an AS is used, then the IMS service control architecture is used to provide the chat service. Both signalling and user plane are then supported by the AS. For more details, see clause 4.2.

The following flow shows the originating session based messaging set up using an intermediate server for a chat service. In this case the intermediate chat server is addressed by the UE#1 using a PSI. It is assumed that UE#1 is the first UE entering the chat session.

Reproduction of 3GPP TS 23.228, Fig. 5.48b: Session based messaging using a chat server

Figure 5.48b: Session based messaging using a chat server

Step 1.

UE #1 sends the SIP INVITE request addressed to a conferencing or chat PSI to the P-CSCF. The SDP offer indicates that UE#1 wants to establish a message session and contains all necessary information to do that. The SDP offer may indicate the maximum message size UE#1 accepts to receive.

Step 2.

P-CSCF forwards the INVITE request to the S-CSCF.

For MPS for Messaging, before forwarding, if the P-CSCF has received the MPS for Messaging indication for the UE as set (enabled), the P-CSCF sets the Resource-Priority information on the INVITE request to a value appropriate for MPS.

Step 3.

S-CSCF may invoke service control logic for UE#1.

Step 4.

S-CSCF forwards the INVITE request to the MRFC/AS.

Step 5. 6. and 8.

MRFC/AS acknowledges the INVITE with a 200 OK, which traverses back to UE#1. The 200 OK (Offer response) may indicate the maximum message size the host of the PSI accepts to receive.

Step 7.

Based on operator policy P-CSCF may instruct PCRF/PCF to authorize the resources necessary for this session.

Step 9.-11.

UE#1 acknowledges the establishment of the messaging session with an ACK towards MRFC/AS.

Step 12.

UE#1 establishes a reliable end-to-end connection with MRFP/AS to exchange the message media.

Step 13.

UE#1 sends a message towards MRFP/AS.

Step 14.

MRFP/AS acknowledges the message.

Step A1.

Another UE (UE#2) sends an INVITE request addressed to the same conferencing or chat PSI. The initial SDP indicates that the UE wants to establish a message session and contains all necessary information to do that.

Step A2.

MRFC/AS acknowledges the INVITE request with a 200 OK.

Step A3.

UE#2 acknowledges the 200 OK with an ACK.

Step A4.

UE#2 establishes a reliable end-to-end connection with MRFP/AS to exchange the message media.

Step A5.

MRFP/AS forwards the message to all recipients, e.g. all participants in the chat room.

Step A6.

The recipients acknowledge the message towards MRFP/AS.

Step B1. and C1.

Further INVITE requests from new possible participants may arrive at any time.

Further messages may be exchanged in either direction between the participating UEs using the established connection via the MRFC/MRFP or AS. The size of the messages exchanged within the session shall be within the size limits indicated by UE#1 and the host of the PSI respectively.

5.16.2.2.3 Session based messaging procedure with an intermediate node p. 200

The following procedure shows the originating session based messaging involving an intermediate node. An optional ringing response from AS to the UE or vice versa is not shown in the following procedure.

Reproduction of 3GPP TS 23.228, Fig. 5.48c: Session based messaging with an intermediate node

Figure 5.48c: Session based messaging with an intermediate node

Step 1.

UE#1 sends the SIP INVITE request addressed to UE#2, containing an initial SDP, to the P-CSCF. The SDP offer may indicate the maximum message size UE#1 accepts to receive.

Step 2.

The P-CSCF forwards the INVITE request to the S-CSCF along the path determined upon UE#1's most recent registration procedure.

Step 3.

Based on operator policy the S-CSCF may reject the INVITE request with an appropriate response. S-CSCF may invoke whatever service control logic is appropriate for this INVITE request. In this case the Filter Criteria trigger the INVITE request to be routed to an Application Server that acts as an intermediate node for the message session.

Step 4.

The S-CSCF forwards the INVITE request to the AS. The AS may modify the content of the SDP (such as IP address/port numbers). Based on operator policy the AS may either reject the session set-up or decrease the maximum message size indication.

Step 5.

The AS sends the INVITE request to the S-CSCF.

Step 6.

The S-CSCF forwards the INVITE request to the destination network. The destination network will perform the terminating procedure.

Step 7-8.

UE#2 or AS in the terminating network accepts the INVITE request with a 200 OK response. The 200 OK response is forwarded by the S-CSCF to the AS. The 200 OK (Offer response) may indicate the maximum message size UE#2 accepts to receive, possibly decreased by the AS.

Step 9-10.

The AS acknowledges the 200 OK response from the terminating network with an ACK, which traverses back to UE#2 or AS in the terminating network via the S-CSCF.

Step 11.

The AS initiates the establishment of a reliable end-to-end connection with UE#2 or the AS in the terminating network to exchange the message media. This step can take place in parallel with step 12.

Step 12, 13 and 15.

The AS accepts the message session with a 200 OK response. The 200 OK response traverses back to UE#1.

Step 14.

Based on operator policy P-CSCF may instruct PCRF/PCF to authorize the resources necessary for this session.

Step 16-18.

UE#1 acknowledges the 200 OK with an ACK, which traverses back to the AS.

Step 19.

UE#1 establishes a reliable end-to-end connection with the AS to exchange the message media.

Step 20.

UE#1 generates the message content and sends it to the AS using the established message connection.

Step 21.

The AS forwards the message content using the established message connection with the terminating network.

Step 22.

UE#2 or AS in the terminating network acknowledges the message with a response that indicates the reception of the message. The response traverses back to the AS.

Step 23.

The AS forwards the message response back to UE#1.

Further messages may be exchanged in either direction between UE#1 and the terminating network using the established message connection via the AS. The size of the messages exchanged within the session shall be within the size limits indicated by UE#1 and UE#2 respectively, possibly decreased by the AS.

5.16.2.2.4 Session based messaging release procedure p. 201

The following procedure shows the release of a message session, which was established between two UEs. It is assumed that UE#1 is the session host.

Reproduction of 3GPP TS 23.228, Fig. 5.48d: Message session release procedure

Figure 5.48d: Message session release procedure

Step 1-6.

UE#1 indicates its intent to terminate the message session by sending a BYE request to UE#2. UE#1 stops sending messages and tears down the message connection on the transport level and destroy local state for the message session. The UE#1 may use the IP-CAN bearer for some other services; hence it keeps the bearer activated.

Step 7-8.

UE#2 agrees to end the session and tear down the message connection on the transport level and destroy local state for the message session. The UE#2 may use the IP-CAN bearer for some other services; hence it keeps the bearer activated.

Step 9-13.

UE#2 acknowledges the BYE request by sending a 200 OK to UE#1, which traverses back the signalling path.

5.16.2.2.5 Session based messaging release procedure with an intermediate node p. 202

The following procedure shows the release of a message session, which was established between two UEs via an intermediate node. It is assumed that UE#1 is the session host.

Reproduction of 3GPP TS 23.228, Fig. 5.48e: Message session release procedure with intermediate node

Figure 5.48e: Message session release procedure with intermediate node

Step 1-4.

UE#1 indicates its intent to terminate the message session by sending a BYE request to UE#2, via the AS. UE#1 stops sending messages and tears down the message connection on the transport level and destroy local state for the message session. The UE#1 may use the IP-CAN bearer for some other services; hence it keeps the bearer activated.

Step 5.

The AS forwards the BYE request to the UE#2.

Step 6-9.

The AS tears down the message connection on the transport level and destroys local state for the message session. The AS acknowledges the BYE request by sending a 200 OK to UE#1, which traverses back the signalling path

Step 10.

The AS receives the acknowledgement from UE#2 to end the session.

5.17 Refreshing sessions |R6| p. 202

The active sessions in stateful network elements (e.g. CSCFs, ASs) may need to be refreshed periodically. This allows these stateful elements to detect and free resources that are being used by hanging sessions.

This SIP-level session refreshing mechanism is to be used to allow removing session state from the stateful elements of the session path upon unexpected error situations (e.g. loss of radio coverage, crash of application in the UE, etc…). The refreshing period is typically in the range of several tens of minutes / hours. The mechanism is intended as a complementary mechanism for the "Network initiated session release" described in clause 5.10.3. Whether the session refresh mechanism is used for a particular session is negotiated between the endpoints of the session upon session initiation.

IMS entities acting as User Agents as defined in RFC 3261 should support the refresh mechanism of SIP sessions. This includes support for the negotiation of the session refresh details upon session initiation, and the initiation of session refresh requests.