Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.228  Word version:  18.4.0

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

 

5.16  IMS messaging concepts and procedures |R6|p. 192

5.16.0  Generalp. 192

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.
Up

5.16.1  Immediate Messagingp. 192

5.16.1.0  Generalp. 192

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

5.16.1.1  Procedures to enable Immediate Messagingp. 193

5.16.1.1.0  Generalp. 193
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.
RFC 3428 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 RFC 3428.
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.
Up
5.16.1.1.1  Immediate messaging procedure to registered Public User Identityp. 193
Reproduction of 3GPP TS 23.228, Fig. 5.47: Immediate Messaging procedure to registered Public User Identity
Up
Step 1.
UE#1 generates the multimedia content intended to be sent to UE#2.
Step 2.
UE#1 sends the MESSAGE request to P-CSCF#1 that includes the multimedia content in the message body.
Step 3.
P-CSCF#1 forwards the MESSAGE request to S-CSCF#1 along the path determined upon UE#1's most recent registration procedure.
Step 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.
Step 5.
S-CSC#1 forwards the MESSAGE request to I-CSCF#2.
Step 6.
I-CSCF#2 performs Location Query procedure with the HSS to acquire the S-CSCF address of the destination user (S-CSCF#2).
Step 7.
I-CSCF#2 forwards the MESSAGE request to S-CSCF#2.
Step 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.
Step 9.
S-CSCF#2 forwards the MESSAGE request to P-CSCF#2 along the path determined upon UE#2's most recent registration procedure.
Step 10.
P-CSCF#2 forwards the MESSAGE request to UE#2. After receiving the MESSAGE UE#2 renders the multimedia content to the user.
Step 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.
Up
5.16.1.1.2  Immediate messaging procedure to unregistered Public User Identityp. 194
Reproduction of 3GPP TS 23.228, Fig. 5.48: Immediate messaging to unregistered Public User Identity, service control invoked
Up
Step 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.
Step 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.
Step 7.
I-CSCF#2 forwards the MESSAGE request to S-CSCF#2.
Step 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.
Step 9-12.
The MESSAGE request is acknowledged with an appropriate acknowledgement response. The acknowledgement response traverses the transaction path back to UE#1.
Up

5.16.1.2  Immediate messages with multiple recipientsp. 195

IMS users shall be able to send a single immediate message to multiple recipients, as specified in TS 22.340. 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.
Up

Up   Top   ToC