4a Architecture Requirements
23.2043GPPRelease 17Stage 2Support of Short Message Service (SMS) over generic 3GPP Internet Protocol (IP) accessTS
4a.1 General
The SMS-IP architecture supports the following:
– Notification shall be sent to the HSS that a previously unreachable UE is now reachable.
– Functionality is required to be able to select the domain for message delivery between IMS and CS/PS, and to have the message delivered to the selected domain.
– Functionality is required to determine whether to transform the message format or not, and to perform the transformation of the message format when determined.
– The interworking function shall generate the appropriate charging-related information and provide the appropriate online charging mechanism (if it is applied for the Short Message Service and/or SIMPLE IM services and/or CPM based services) for the interworking services.
4a.2 Transport-level interworking
For transport-level interworking , the architecture allows for the following:
– A registration and de-registration mechanism shall be supported where UEs are required to explicitly indicate their ability to send and receive encapsulated Short Messages.
– It shall provide for the transport of Short Message Service TP layer PDUs (TS 23.040 [2]) and associated RP layer information.
4a.3 Service-level interworking
For service-level interworking, the architecture allows for the following:
– The service-level interworking is a value added service which requires service subscription. In addition, it shall also take the operator’s policy, if available, into account, e.g. checking on the barring setting of the subscriber to determine whether to provide this interworking or not, so the service authorisation shall be supported before the interworking is executed.
– The service-level interworking applies as a fallback only if the users cannot communicate with each other using their chosen messaging service according to the user preference and operator policy. The location of the interworking service can be in the originating network and in the terminating network.
– The service-level interworking shall support interworking between OMA SIMPLE IM service as defined in OMA-TS-SIMPLE_IM-V1_0 [12] and Short Message Service, as defined in the TS 23.040 [2] and in the current specification.
– The service-level interworking shall support interworking between OMA CPM service as defined in OMA-TS-CPM_Conv_Fnct-V1_0 [17] and Short Message Service, as defined in the TS 23.040 [2] and in the current specification.
– The service-level interworking shall take the capability of the terminating UE into account when possible.
– The service level interworking shall be transparent to the end user.
– The service-level interworking shall minimize the impact on the IMS architecture.
– The service-level interworking shall not impact existing functionality of the Short Message Service as described in TS 23.040 [2] or of the SIMPLE IM service enabler as described in OMA-TS-SIMPLE_IM-V1_0 [12] or of the CPM service enabler as described in OMA TS CPM_Conv_Fnct-V1_0 [17]. Existing security mechanisms for the SIMPLE IM service, the Converged IP Messaging service and the Short Message Service shall be reused.
– The interworking function shall be aware if the message should be interworked or not, e.g. specific types of Short Messages such as an over the air configuration message, shall not be interworked at service-level, but shall be instead transported as a Short Message via IMS, CS or PS.
– If an SMS user requests an SMS status report that the message was delivered to the recipient, then an SMS status report shall be generated when the message is delivered using Instant Message.
– If an IMS user requests a notification that the message was delivered to the recipient and the Instant Message is interworked to Short Message on the originating side, an SMS status report shall be interworked to a delivery notification when the message is delivered.
– The interworking functionality shall be executed in the following cases:
– Originating network:
– The sender is an IM user or a CPM user who has subscribed to the interworking function and the recipient is not routable in IMS;
– The operator policy on the originating side has been set to send the Instant Messages via Short Message Service.
– Terminating network:
– The user preferences and/or the operator policy of the recipient have been set to receive the incoming Instant Messages via Short Message Service;
– The received message is a Short Message and the recipient is an IM user or a CPM user and has subscribed to the interworking service.
NOTE: For ensuring the integrity of the response messages from the IM UE or the CPM UE, it is strongly recommended that in networks where the IP-SM-GW is deployed, no intermediate nodes modify or terminate the message between the IP-SM-GW and the terminating IM UE or CPM UE. If intermediate nodes are deployed, they can send response messages that do not reflect the final response from the IM UE or CPM UE. Final responses from the IM UE or CPM UE are necessary to ensure correct charging and delivery reports on the Short Message Service side.
4a.4 SMS without MSISDN
For SMS without MSISDN interworking, the architecture allows for the following in addition to clause 4a.2:
– It shall provide for the transport of Mobile Terminating Short Message Service to UE without the need of MSISDN in the UE’s IMS subscription profile.
– It shall provide for the transport of Mobile Originating Short Message Service from IMS UE that supports MSISDN-less SMS operation to other IMS UE.
4a.5 SMS without MSISDN interworking with Non-supporting MSISDN-less SMS UE
This version of the specification does not require the support of SMS communication between IMS UE that supports MSISDN-less SMS operation as defined in this specification and non-supporting MSISDN-less SMS UE.
NOTE: It is up to implementation on the IMS network that supports the MSISDN-less SMS operation to determine how to interwork with non-supporting MSISDN-less SMS UE if required.