11 Interworking
22.3403GPPIP Multimedia Subsystem (IMS) messagingStage 1TS
11.1 General
It should be possible for the IMS Messaging subscriber to send/receive messages to/ from subscribers of 3GPP defined messaging services (SMS, EMS, MMS). Optionally, it should be possible to send/receive messages to/from users of fixed Internet messaging service (e.g. SMTP and SIMPLE based services).
11.2 Requirements for SMS-Immediate Messaging service-level interworking
These requirements shall be considered for SMS-Immediate Messaging service-level interworking:
– it shall be possible for a user to send an Immediate Message or an SMS message to another user without having to know which messaging client the receiving user has;
– The user experience shall be consistent with the SMS and Immediate Messaging service level expectations to as large an extent as possible. If the recipient is not available and deferred messaging is offered then the message shall be kept until delivery is possible or the message expires;
– When interworking from an SMS message to an Immediate Message, the network should deliver all content types in an SMS message to equivalent IMS content types where they exist;
– When interworking from an Immediate Message to an SMS message, the network should deliver all content types in an Immediate Message to equivalent SMS content types where they exist;
– When interworking from an Immediate Message to an SMS message and a form of anonymity has been requested by the sending party and the operator of the interworking function cannot identify the sending party, subject to operator policy, interworking shall be suppressed for that message. Subject to operator policy and / or the ability to identify the sending party, the sending party may be informed that the message could not be delivered.
– When interworking from an Immediate Message to an SMS message, it shall be possible for the sender of the Immediate message to request to hide its public ID from the recipient (e.g. be an anonymous sender). In this case the sender’s public ID may not be delivered to the recipient subject to operator policy.
– Based on operator policy, it shall be possible for e.g., an SMS system or data download message such as an over the air configuration message, to be prevented from being interworked at a service level to an Immediate Message, but to instead by transported as an SMS message via IMS, CS or PS;
– If a user is registered to receive SMS service, then the SMS message should be delivered as an SMS message via IMS, CS or PS transport instead of via service-level interworking, subject to operator and user preferences;
– If a user is registered to receive Immediate Messaging service, then the Immediate Message should be delivered that way instead of via service-level interworking, subject to operator and user preferences;
– If an SMS user requests an SMS status report, then an SMS status report should be generated when the message is delivered using Immediate Messaging;
– If an IMS user requests a notification that the message was delivered to the recipient, an SMS status report should be generated when the message is delivered to the SMS user’s client;
– It shall be possible to generate the appropriate charging-related information and provide the appropriate online charging mechanism (if it is applied for the SMS and/or Immediate Messaging services) for the interworking services.
11.3 Requirements for SMS-Session based Messaging service-level interworking
These requirements shall be considered for SMS-Session based messaging service-level interworking:
- Pre Release 10 UE shall be supported by SMS-Session based messaging service-level interworking.
- it shall be possible for a session based messaging user to send a messaging session invitation to an SMS user;
- When interworking from a Session based message to an SMS message, the network should deliver all content types in the Session based message to equivalent SMS content types where they exist;
- When interworking from an SMS message to a Session based message, the network should deliver all content types in an SMS message to equivalent Session based message content types where they exist;
- If an SMS user requests an SMS status report, then an SMS status report should be generated when the message is delivered using Session based message and a success or failure delivery notification has been received from the Session based message user;
- If a Session based message user requests a notification that the message was delivered to the recipient, an SMS status report should be generated when the message is delivered to the SMS user’s client; an SMS status report should be communicated to a Session based message user as a delivery notification;
- A session invitation sent towards an SMS user is handled in one of 3 ways (dependent on service provider policies):
1) The session invitation is accepted by the network on behalf of the SMS user.
2) The session invitation is denied by the network on behalf of the SMS user.
3) The SMS user is asked for consent for accepting the session invitation:
– The session invitation will be delivered as an SMS message to the SMS user; the appropriate instructions should be included to guide the SMS user how to react (join/reject) the session invitation.
– The SMS user will send back a response in an SMS message according to the embedded instruction if included.
- The user experience shall be consistent with the SMS and Session based messaging service level expectations to as large an extent as possible;
- For session based messaging the session based connectivity should be maintained for the SMS user so that the SMS user could:
– participate in the session (i.e. exchange messages)
– exit the session (no more message exchange) according to the instruction embedded in the SMS message.
– When interworking a session invitation from a Session based messaging service to an SMS message and a form of anonymity has been requested by the sending party and the operator of the interworking function cannot identify the sending party, subject to operator policy, interworking shall be suppressed for that session invitation. Subject to operator policy and / or the ability to identify the sending party, the sending party may be informed that the session invitation could not be delivered.
– When interworking a session invitation from a Session based messaging service to an SMS message, it shall be possible for the sender of the session invitation to request to hide its public ID from the recipient (e.g. be an anonymous sender). In this case the sender’s public ID shall not be delivered to the recipient subject to operator policy.
- It shall be possible to generate the appropriate charging-related information and provide the appropriate online charging mechanism (if it is applied for the SMS and/or Session based messaging services) for the interworking services. Such charging related information shall take into account the one-to-many relationship of messages sent to a session.
Annex A (informative):
Change history
|
Change history |
|||||||||||
|
TSG SA# |
SA Doc. |
SA1 Doc |
Spec |
CR |
Rev |
Rel |
Cat |
Subject/Comment |
Old |
New |
Work Item |
|
22.abc |
Produced during IMS Messaging interim SWG meeting 23rd-24th September, Reading, UK |
0.0.0 |
IMSM |
||||||||
|
S1-021873 |
22.abc |
Revisions on the requirements mainly due to new document structure |
0.0.0 |
0.1.0 |
IMSM |
||||||
|
S1-022052 |
22.340 |
TS number updated, introduction, scope and definitions added, remaining issues (except the one concerning storage requirements in session based messaging and one in interworking) marked with editor’s notes resolved |
0.1.0 |
0.2.0 |
IMSM |
||||||
|
12 /12/02 |
SP-18 |
SP-020671 |
22.340 |
Raised to version 2.0.0 for presentation for approval at SA #18 |
0.2.0 |
2.0.0 |
IMSM |
||||
|
12 /12/02 |
SP-18 |
SP-020671 |
22.340 |
Approved at SA #18 |
2.0.0 |
6.0.0 |
IMSM |
||||
|
SP-19 |
SP-030032 |
S1-030260 |
22.340 |
0001 |
– |
Rel-6 |
D |
CR to 22.340 on required message formats for IMS messaging |
6.0.0 |
6.1.0 |
IMSM-TS |
|
SP-27 |
SP-050062 |
S1-050255 |
22.340 |
0002 |
– |
Rel-6 |
F |
Removal of Deferred Messaging Requirements |
6.1.0 |
6.2.0 |
IMSM-TS |
|
SP-30 |
SP‑050654 |
22.340 |
– |
– |
Rel7 |
– |
Raised to Rel-7 to allow reference by TISPAN |
6.2.0 |
7.0.0 |
FBI |
|
|
SP-35 |
SP-070124 |
S1-070262 |
22.340 |
0004 |
1 |
Rel-8 |
B |
CR0004 on 22.340 for SMS – IM service level interworking reqs |
7.0.0 |
8.0.0 |
MESSIW |
|
SP-39 |
SP-080038 |
S1-080282 |
22.340 |
0005 |
2 |
Rel-8 |
C |
Addition of Privacy requirements when Service Level interworking is performed |
8.0.0 |
8.1.0 |
SLIMS |
|
SP-39 |
SP-080038 |
S1-080279 |
22.340 |
0006 |
2 |
Rel-8 |
F |
Clarification on storage requirements |
8.0.0 |
8.1.0 |
SLIMS |
|
SP-45 |
SP-090485 |
S1-093269 |
22.340 |
0007 |
2 |
Rel-10 |
B |
Enhancements for CPM-SMS Interworking |
8.1.0 |
10.0.0 |
CPM_SMS |
|
2012-09 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-11 by MCC |
10.0.0 |
11.0.0 |
|
|
2014-10 |
Updated to Rel-12 by MCC |
11.0.0 |
12.0.0 |
||||||||
|
2015-12 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-13 by MCC |
12.0.0 |
13.0.0 |
|
|
2017-03 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-14 by MCC |
13.0.0 |
14.0.0 |
|
|
2018-06 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-15 by MCC |
14.0.0 |
15.0.0 |
|
|
SA#88e |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-16 by MCC |
15.0.0 |
16.0.0 |
|
|
2022-03 |
– |
– |
– |
– |
– |
– |
– |
Updated to Rel-17 by MCC |
16.0.0 |
17.0.0 |
|