7 Session based messaging requirements
22.3403GPPIP Multimedia Subsystem (IMS) messagingStage 1TS
7.1 General requirements
Network operators have different network configuration and commercial requirements. IMS Messaging shall be supported in a manner that meets the operator’s IMS requirements. Thus, an identified set of functionalities and formats shall be standardized to ensure interoperability across networks and terminals to support IMS Messaging.
The following general requirements shall be supported.
a) There shall be a mechanism to differentiate session based messages from other messaging types.
b) Within the capabilities of networks and terminals, the user shall have a consistent experience regardless of the access network e.g. 3GPP systems, fixed networks, the Internet.
c) Session based messaging shall support a minimum set of functionality to ensure interoperability between different terminals and networks.
d) Session based messaging shall be able to take into account the capabilities of the terminals participating in the messaging session. Specifically the terminal capabilities that may be taken into account at a minimum include:
1) Display capabilities (including screen size, number of colours, number of lines of text, etc);
2) Media content types supported (Audio, Video etc);
3) Media content formats supported (JPEG, GIF, etc);
4) Media Storage capacity;
5) Encryption/Security mechanisms supported
The capabilities of the user’s terminal may be reflected in the message filtering and corresponding actions as identified in clause 7.7.
e) It shall be possible to store in the ISIM a number of sets of configuration information to allow access to IMS Messaging services. One of these sets of configuration information is preset by the issuer of the ISIM. Such preset configuration information set shall only be configurable by issuer of the ISIM. The preset configuration information is selected unless otherwise specified by the user. It shall be possible to retain the configuration information when the UICC is used in different terminals.
f) It shall be possible for the subscribers to join to a session e.g. chat room.
g) It shall be possible for the subscribers to leave a session e.g. chat room.
h) It shall be possible to send a message to all the participants of a messaging session without specifying the individual participant’s addresses or using a message delivery list.
i) It shall be possible to invite new participants to the existing messaging session.
1) The invitations shall be semi permanent i.e. it is not required that invitee will act immediately.
2) It shall be possible to cancel the invitation by the inviter.
3) It shall be possible for the inviter to define the validity period of the invitation.
4) It shall be possible for the invitee to see the originator of the invitation unless the inviter has required hiding his public ID.
5) It shall be possible for the inviter to define the messaging session to which the invitation is made.
6) It shall be possible for the invitee to identify the messaging session to which he was invited.
j) It shall be possible for the recipient of the message to identify from which messaging session the message came from (for both public and private messages).
k) It shall be possible for the recipient to identify the sender (unless the sender has required hiding its public ID) of the message in addition to the messaging session from which the message came from.
l) It shall be possible for the sender to send a private message for a selected recipient.
m) It shall be possible for the recipient to determine if the message was send as a private message within a messaging session.
n) It shall be possible for the subscriber to request the message session properties e.g. list of active members.
o) It shall be possible for the subscriber to automatically receive updates containing the changes in message session properties e.g. change in the list of active members.
p) It shall be possible to utilize IMS Group Management 3GPP TS 22.250 [2] as appropriate.
q) It shall be possible for a subscriber in an IMS Messaging session to request and to receive an indication of when user is entering a message (“Is typing”). This request may apply to a specific user or users in the same session. Subject to privacy requirements, the corresponding indications will identify the persons who are entering a message.
r) It shall be possible for the network operator providing the IMS Messaging service to choose, wherever possible, the most suitable transport mechanism for carrying messages (e.g. signalling network, dedicated PDP context, other access technologies and so on…)
s) It shall be possible for the network operator providing the IMS Messaging service to choose, wherever possible, the parameters used (i.e. QoS)
t) The operator shall be able to enforce the use of the preferred transport mechanism and parameters both for UE originated and UE terminated messages.
7.2 Message content requirements
Following requirements are specific to content delivered with session based messaging.
a) Content size shall not be limited by technology.
b) It shall be possible to carry different media including text, images, video and audio. Media types shall be MIME encoded.
c) Session based messaging shall provide a minimum set of supported formats to ensure full interoperability between different terminals and networks (e.g. JPEG for pictures, AMR for speech, H.263 for video). The minimum set of supported formats shall be common to all IMS Messaging types. The minimum set of supported formats should be aligned with formats used in other 3GPP-defined services 3GPP TS 26.140 [5], 3GPP TS 26.234 [6].
d) Content formats shall be defined so that they enable interworking with 3GPP and Internet messaging solutions.
e) It shall be possible to compose message of either a single medium (e.g. voice) or multi-media (e.g. voice and video). The IMS Messaging service shall be able to support a request for media sequencing.
7.3 Management requirements
The following management requirements shall be supported.
a) IMS Messaging shall be able to support a request from the IMS service provider to enable/disable message delivery and submission.
b) IMS Messaging shall be able to support a request from the user to enable/disable message delivery and submission.
c) IMS Messaging shall be able to support the user to manage his user service profile related to IMS Messaging (e.g. customize his messaging environment within the capabilities of the terminal, network and messaging application). This could be unconditional or conditional e.g. depending on roaming conditions or operator restrictions.
d) It shall be possible for IMS service provider to configure messaging session environment e.g. in such a way that all incoming IMS Messages are stored in a network based repository.
e) It shall be possible for an authorized user or an IMS service provider enable session based messaging (e.g. create chat room) and thus become an administrator of messaging session.
f) It shall be possible for the administrator of a messaging session to control who is allowed to participate in the messaging session.
g) It shall be possible for the IMS service provider or administrator of a messaging session to disable messaging session (e.g. close a chat room).
h) It shall be possible for the administrator of the messaging session (to set properties related to the messaging session (e.g. the chat room name, topic, maximum number of active users).
7.4 Message delivery requirements
Following requirements define the message delivery.
a) Message delivery shall be immediate i.e. messages are transported by the IMS system to the recipient’s terminal (without notifications) subject to message filtering settings defined by the recipient or by the recipient’s IMS service provider.
b) It shall be possible for the sender to receive delivery acknowledgements (success/failure) for sent messages.
7.5 Storage requirements
Session Based Messaging shall support global storage of sessions (accessible to all participants) and personal storage (accessible to the user who requested the storage). For personal storage, all storage operations listed below are applicable. In the case of global storage, users will be able to list and retrieve messages, not delete messages or turn storage on or off.
The following storage requirements shall be supported.
a) It shall be possible for a participant to request to persistently store a sent Session Based Message or all messages associated with a session in a network based repository if the IMS service provider provides such application level service.
b) IMS Messaging shall be able to support a request from a user to retrieve one or more messages stored in a network based repository.
c) IMS Messaging shall be able to support a request from a user to delete one or more messages or sessions that are stored in a network based repository.
d) IMS Messaging shall be able to support a request from a user to view the list of messages and message related attributes, such as sender, recipient, subject and date/time, in a network based repository.
7.6 User privacy requirements
Following requirements define user privacy.
a) It shall be possible for the recipient to see the public ID of the sender of the message unless the sender has requested to hide it.
b) It shall be possible for the sender of the message to request to hide its public ID from the recipient (anonymous sender).
The sender’s public ID shall not be delivered to the recipient. The capability of public ID hiding is an IMS service provider and legislation issue and it may or may not be available. If the service is not available the message shall not be delivered to the recipient.
c) It shall be possible for the sender to use nickname when sending messages.
In case of nickname the recipient shall only be able to see the nickname but not the real address from which the message came from. It shall be possible to use nicknames for public and private messages. It shall be possible for the recipient to reply to the message sent with a nickname.
d) It shall be possible for a member of an IMS Messaging session to disable the reporting of the indication that they are entering a message (“Is Typing”) on a per session basis. Further granularity levels for this requirement is for further study.
7.7 Message Filtering
It shall be possible for a subscriber to set up, modify, and delete filters in the network of the subscriber’s IMS service provider, in order to control the treatment of a message by the network when a message is received. The filters shall also support the ability of the subscriber to specify the maximum size and type of message content etc that they are or are not willing to accept. The filters shall also support the ability of the subscriber to block (and unblock) messages from specific senders or anonymous senders.
Following specific requirements define the message filtering capabilities of the recipient.
a) It shall be possible to define specific message treatment based on following criteria
1) sender address (including anonymous senders);
2) message size;
3) message class (e.g. advertisement, private….);
4) message priority;
5) message content type (e.g. video, audio….);
6) message content format (e.g. mpeg, jpeg….);
7) message type (e.g. immediate message);
8) message subject; and
9) additional criteria maybe possible but are outside the scope of this document.
b) It shall be possible to specify the following message treatments in a filter:
1) Block the delivery of the message content.
2) Store the message content and notify recipient,
3) Store the message content for a specific time or until the recipient requests delivery.
4) Store and push the message content to recipient when available.
5) Redirect the message to another address.
6) Additional treatments maybe possible but are outside the scope of this document.
The IMS service provider shall also be able to set and control the filter settings either on behalf of the subscriber or based on policy.