5.16 IMS messaging concepts and procedures

23.2283GPPIP Multimedia Subsystem (IMS)Release 18Stage 2TS

5.16.0 General

This clause describes architectural concepts and procedures for providing Messaging in the IM CN Subsystem. The service enablers for Messaging and possible reuse of IMS service enablers within this context as well security and charging expectations, addressing, privacy, content handling and limitations, filtering, media types and message lengths, etc. are to be further studied.

Any ISIM or, for UEs supporting only non-3GPP accesses and containing IMC, any IMC related architectural requirements would be studied as part of overall IMS Messaging.

5.16.1 Immediate Messaging

5.16.1.0 General

This clause describes architectural concepts and procedures for fulfilling the requirements for Immediate Messaging described in TS 22.340 [29a].

5.16.1.1 Procedures to enable Immediate Messaging

5.16.1.1.0 General

IMS users shall be able to exchange immediate messages with each other by using the procedure described in this clause. This procedure 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 annex.

If the message size exceeds the size limit for MESSAGE requests, the UE shall use alternative means to deliver the content of the Immediate Message. Session based messaging specified in clause 5.16.2 provides such means.
IETF RFC 3428 [43] presents guidelines for the selection of transport mechanism for an Immediate Message. The message size limitations described above are meant to be applicable for Immediate Messages sent over end-to-end congestion safe transport, i.e. are not necessarily equal to the limitations specified for MESSAGE over congestion-unsafe transport by IETF RFC 3428 [43].

NOTE: The actual size limit is part of stage-3 design.

If the size limit for a terminating MESSAGE request is exceeded, the network may refuse the request or respond to the sender with an indication that the size of the message is too large.

The sender UE can include an indication in the message regarding the length of time the message will be considered valid.

5.16.1.1.1 Immediate messaging procedure to registered Public User Identity

Figure 5.47: Immediate Messaging procedure to registered Public User Identity

1. UE#1 generates the multimedia content intended to be sent to UE#2.

2. UE#1 sends the MESSAGE request to P‑CSCF#1 that includes the multimedia content in the message body.

3. P‑CSCF#1 forwards the MESSAGE request to S‑CSCF#1 along the path determined upon UE#1’s most recent registration procedure.

4. Based on operator policy S‑CSCF#1 may reject the MESSAGE request with an appropriate response, e.g. if content length or content type of the MESSAGE are not acceptable. S‑CSCF#1 invokes whatever service control logic is appropriate for this MESSAGE request. This may include routing the MESSAGE request to an Application Server, which processes the request further on.

5. S-CSC#1 forwards the MESSAGE request to I‑CSCF#2.

6. I‑CSCF#2 performs Location Query procedure with the HSS to acquire the S‑CSCF address of the destination user (S‑CSCF#2).

7. I‑CSCF#2 forwards the MESSAGE request to S‑CSCF#2.

8. Based on operator policy S‑CSCF#2 may reject the MESSAGE request with an appropriate response, e.g. if content length or content type of the MESSAGE are not acceptable. S‑CSCF#2 invokes whatever service control logic is appropriate for this MESSAGE request. This may include routing the MESSAGE request to an Application Server, which processes the request further on.
For example, the UE#2 may have a service activated that blocks the delivery of incoming messages that fulfil criteria set by the user. The AS may then respond to the MESSAGE request with an appropriate error response.

9. S‑CSCF#2 forwards the MESSAGE request to P‑CSCF#2 along the path determined upon UE#2’s most recent registration procedure.

10. P‑CSCF#2 forwards the MESSAGE request to UE#2. After receiving the MESSAGE UE#2 renders the multimedia content to the user.

11–16. UE#2 acknowledges the MESSAGE request with a response that indicates that the destination entity has received the MESSAGE request. The response traverses the transaction path back to UE#1.

5.16.1.1.2 Immediate messaging procedure to unregistered Public User Identity

Figure 5.48: Immediate messaging to unregistered Public User Identity, service control invoked

1-5. The same actions apply as for when the Public User Identity is registered, see step 1-5 in clause 5.16.1.1.1.

6. I‑CSCF#2 interacts with the HSS as per the terminating procedures defined for unregistered Public User Identities in clause 5.12.1. If the Public User Identity has no services related to unregistered state activated the interaction with HSS would be as per the procedure defined in clause 5.12.2.

7. I‑CSCF#2 forwards the MESSAGE request to S‑CSCF#2.

8. Based on operator policy S‑CSCF#2 may reject the MESSAGE request with an appropriate response, e.g. if content length or content type of the MESSAGE are not acceptable or the UE#2 does not have a service activated that temporarily hold the MESSAGE request in the network.

S‑CSCF#2 invokes whatever service control logic appropriate for this MESSAGE request. This may include routing the MESSAGE request to an Application Server, which processes the request further on.

For example, the UE#2 may have a service activated that allows delivery of any pending MESSAGE request. The AS may then hold the MESSAGE request and deliver the MESSAGE request when the UE#2 becomes reachable. In this case, depending on user settings UE#2 controls the delivery of the pending MESSAGEs.

9-12. The MESSAGE request is acknowledged with an appropriate acknowledgement response. The acknowledgement response traverses the transaction path back to UE#1.

5.16.1.2 Immediate messages with multiple recipients

IMS users shall be able to send a single immediate message to multiple recipients, as specified in TS 22.340 [29a]. The following means are supported to achieve this:

– A PSI identifying a new group is created in the appropriate Application Server, and members are added to this group (e.g. by the user via the Ut interface or by the operator via O&M mechanisms). Immediate messages addressed to this PSI will be routed to the AS hosting the PSI, and this AS shall create and send immediate messages addressed to a group member of the group identified by the PSI.

– The user can send an immediate message by indicating the individual addresses (Public User Identities for IMS recipients) of the intended recipients as part of the immediate message. The AS of the user shall then create and send immediate messages addressed to each one of the intended recipients.

5.16.2 Session-based Messaging

5.16.2.0 General

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

5.16.2.1 Architectural principles

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 IETF RFC 3312 [41] is not required for session based messaging establishment that only includes a messaging media component.

NOTE: Pre-conditions mechanism may still be required for session establishment with additional media components that require the establishment of additional IP‑CAN bearers.

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 [29a]) 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

5.16.2.2.0 General

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

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.

Figure 5.48a: Message session establishment

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.

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

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

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

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.

NOTE: Interactions between MRFC and MRFP are not shown in the flows below since these interactions are not standardized. An optional ringing response from MRFC/AS to the UE is not shown in the following procedure.

Figure 5.48b: Session based messaging using a chat server

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.

2. P‑CSCF forwards the INVITE request to the S‑CSCF.

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

4. S‑CSCF forwards the INVITE request to the MRFC/AS.

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.

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

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

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

13. UE#1 sends a message towards MRFP/AS.

14. MRFP/AS acknowledges the message.

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.

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

A3. UE#2 acknowledges the 200 OK with an ACK.

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

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

A6. The recipients acknowledge the message towards MRFP/AS.

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

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.

Figure 5.48c: Session based messaging with an intermediate node

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.

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

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.

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.

5. The AS sends the INVITE request to the S‑CSCF.

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

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.

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.

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.

12, 13 and 15. The AS accepts the message session with a 200 OK response. The 200 OK response traverses back to UE#1.

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

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

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

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

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

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.

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

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.

Figure 5.48d: Message session release procedure

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.

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.

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

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.

Figure 5.48e: Message session release procedure with intermediate node

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.

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

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

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