A.4 IWF related to the S6a/S6a+D interface between MME and HSS
29.3053GPPInterWorking Function (IWF) between MAP based and Diameter based interfacesRelease 17TS
A.4.1 Introduction
3GPP TS 23.272 [2] has specified the "SMS in MME" architecture option, where an IWF, named S6a/S6a+D IWF, between the S6a interface with SMS subscription data on the MME side and the S6a interface without SMS subscription data plus the MAP-based D interface for SMS subscription on the MME side is defined. This S6a/S6a+D IWF is described in the following subclauses.
A.Z.2 Interworking scenario
This interworking scenario is illustrated in the figure A.4.2.1-1 where an IWF is placed between a MME supporting a Diameter based S6a interface with the SMS in MME feature and a HSS supporting a S6a interface without the SMS feature and a MAP D interface where the IWF emulates a VLR limited to the support of SMS teleservice.
This IWF scenario, according to 3GPP TS 23.272 [4], may be used for roaming cases between the HSS in the home PLMN and the MME in the visited network.
Figure A.4.2-1 S6a/S6a+D for SMS interworking scenario with one IWF
The S6a interface without SMS between the IWF and the HSS may be replaced by a MAP Gr interface without SMS between a S6a/Gr + D IWF and the HSS as illustrated in the figure A.4.2-2. The mapping of procedures described in clause A.4.4 and the mapping of parameters described in clause A.4.5 shall apply by replacing the commands transferred between the IWF and the HSS over S6a by the corresponding ones over the Gr interface in compliance with the clauses 6, 7, 8.
Figure A.4.2-2 S6a/Gr+D for SMS interworking scenario with one IWF
The IWF shall be configured as a MSC-VLR in the HSS over the D interface. Only the SMS teleservice will be available on the D interface.
A.4.3 General considerations
A.4.3.1 Procedures covered
The MAP procedures on the D interface to be supported by the IWF are:
– the procedures involved in the support of SMS teleservice:
– MAP-UPDATE-LOCATION
– MAP-CANCEL-LOCATION
– MAP-INSERT-SUBSCRIBER-DATA
– MAP-DELETE-SUBSCRIBER-DATA
– MAP-READY-FOR-SM
– the procedures not linked to the SMS teleservice as such:
– MAP-PURGE
– MAP-RESET
Other MAP procedures of the D interface between a VLR and the HSS shall not be supported by the IWF.
NOTE 1: Some MAP general procedures that are not linked to the SMS service does not need to be handled over the MAP D interface, as they will be normally handled with equivalent procedures by the HSS over the S6 interface, e.g. for MAP-PROVIDE-SUBSCRIBER-INFO, MAP-ACTIVATE/DEACTIVATE-TRACE-MODE or MAP-RESTORE-DATA.
NOTE 2: It is considered that proper configuration of HSS will avoid the HSS to attempt to use procedures not supported by the IWF.
The following S6a procedures defined in 3GPP TS 29.272 [5] shall be supported by the IWF.
– Update Location
– Cancel Location
– Purge UE
– Insert Subscriber Data
– Delete Subscriber Data
– Authentication Information Retrieval
– Reset
– Notification
The Authentication Information Retrieval procedure can be simply relayed by the IWF as having no interaction with a MAP procedure on the D interface.
A.4.4 The mapping of procedures
A.4.4.1 Common aspects
In the S6a, ULR and NOR commands requests received from MME with the SMS in MME feature bit set , the IWF may remove it in the corresponding command transferred to the HSS.
In the S6a ULA, NOA commands that the IWF transfers to the MME, the IWF shall set the SMS in MME feature bit if it was set in the associated ULR or NOR request.
In the S6a commands IDR, DSR that the IWF transfers to the MME, the IWF shall set the SMS in MME feature bit if it was set in the previous ULR received from the MME.
In the S6a, IDA, DSA answers received from MME with the SMS in MME feature bit set, the IWF may remove it in the corresponding command transferred to the HSS.
The IWF shall support MAP version V3 and should support fallback to version V1 or V2.
A.4.4.2 Update Location
The mapping of the Update Location procedure is shown in figure A.4.4.2-1:
Figure A.4.4.2-1: Mapping of the Update Location procedure
1. The IWF receives a ULR from the MME with the SMS in MME feature bit set and a request to be registered for MT-SMS.
2. The IWF stores the SMS related information (SMS Register Request, SMS only indication, MME number for MT-SMS), sends the ULR to the HSS where the IWF may clear the SMS in MME feature bit and remove the information related to SMS.
3. The HSS answers with a ULA.
4. If the ULA is successful and has the SMS in MME feature bit cleared and the received Network Access Mode (NAM) is PS + CS, the IWF sends a MAP updateLocation to the HSS with the MME Number for MT SMS. Otherwise the IWF skips to the step 8.
5. The HSS sends a MAP insertSubscriberData with the CS subscription data of the user.
6. If the IWF receives the SMS teleservice in insertSubscriberData and
if the SMS Register Request is "SMS in MME required",
or if the SMS Register Request is "No preference" and a "SMS only indication" was received in step 2,
or if the SMS Register Request is "No preference" and no SMS only indication" was received in step 2 and no other CS teleservices than the SMS teleservice have been received,
then the IWF sends an insertSubscriberDataAck in which the IWF returns the received CS teleservices other than the SMS teleservice, if any;
otherwise the IWF sends an insertSubscriberDataAck in which the IWF returns the received CS teleservices including the SMS teleservice.
If the IWF has not received the SMS teleservice in insertSubscriberData, the IWF sends an insertSubscriberDataAck where the IWF returns the received CS teleservices
7 The HSS sends a MAP updateLocationAck.
8. If the ULA received in step 3 is successful and the received Network Access Mode (NAM) is PS, the IWF sends the received ULA with the SMS in MME feature bit set and the indication that MME is not registered for SMS.
NOTE: The use of SMS in MME is not possible in this IWF case when the user has no CS subscription for the SMS teleservice.
If the IWF receives the SMS teleservice in insertSubscriberData and
if the SMS Register Request is "SMS in MME required",
or if the SMS Register Request is "No preference" and a "SMS only indication" was received in step 2,
or if the SMS Register Request is "No preference" and no SMS only indication" was received in step 2 and no other CS teleservices than the SMS teleservice have been received in step 5,
then the IWF sends the ULA received in step 3 in which the IWF sets the SMS in MME feature bit and indicates that the MME is registered for SMS and includes the SMS subscription data;
otherwise the IWF sends the ULA received in step 3 in which the IWF sets the SMS in MME feature bit and indicates that the MME is not registered for SMS and does not include any SMS subscription data.
NOTE: the MSC registration is not cancelled because it has been indicated that SMS teleservice is not supported. Further it is assumed that the MME will perform an SGs association which will initiate a Location Update via a VLR
If the IWF has not received the SMS teleservice in insertSubscriberData, the IWF sends the ULA received in step 3 in which the IWF indicates that the MME is not registered for SMS.
If the ULA received in step 4 is unsuccessful, the IWF sends the ULA received in step 3 unchanged.
If in step 7, the IWF receives an updateLocation answer with a MAP error, the IWF sends the ULA received in step 3 unchanged with the indication that MME is not registered for SMS.
A.4.4.3 Cancel Location
A.4.4.3.1 Cancel Location over S6a
The mapping of the Cancel Location over S6a procedure is shown in figure A.4.4.3.1-1:
Figure A.4.4.3.1-1: Mapping of the Cancel Location over S6a procedure
1. The IWF receives a CLR from the HSS.
2. The IWF send the CLR unchanged to the MME.
3. The IWF, if it has been registered by the HSS over the MAP D interface shall send a MAP purgeMS message to the HSS.
4. the IWF receives a purgeMSAck from the HSS.
5. the IWF receives a CLA from the MME.
6. the IWF sends the CLA unchanged to the MME.
The steps 3/4 and the step 5 may occur in parallel.
A.4.4.3.2 Cancel Location over MAP D
The mapping of the Cancel Location over MAP D procedure is shown in figure A.4.4.3.2-1:
Figure A.4.4.3.2-1: Mapping of the Cancel Location over MAP D procedure
1. The IWF receives a CancelLocation from the HSS
2. If the MME is registered for SMS, the IWF sends an IDR to the MME with the indication to remove the MME registration for SMS; otherwise the IWF skips to the step 4.
3. The IWF receives an IDA.
4. The IWF sends a CancelLocation Ack to the HSS.
A.4.4.4 Purge
The mapping of the Purge procedure is shown in figure A.4.4.4-1:
Figure A.4.4.4-1: Mapping of the Purge procedure
1. The IWF receives a PUR message from the MME.
2a. The IWF sends the PUR message unchanged to the HSS.
3a. The IWF receives PUA from the HSS.
2b. The IWF, if it has been registered by the HSS over the MAP D interface, sends a MAP purgeMS message to the HSS.
3b. The IWF receives a MAP purgeMSAck message from the HSS.
4. The IWF sends PUA to the MME.
The steps 2a/3a and 2b/3b may occur in parallel.
A.4.4.5 Insert Subscriber Data
A.4.4.5.1 Insert Subscriber Data over S6a
If the IWF receives an IDR from the HSS, the IWF sends the IDR unchanged to the MME apart the possible setting of the SMS in MME feature bit as described in subclause A.4.4.1.
A.4.4.5.2 Insert Subscriber Data over MAP D
The mapping of the Insert Subscriber Data over MAP D procedure is shown in figure A.4.4.5.2-1:
Figure A.4.4.5.2-1: Mapping of the Insert Subscriber Data over MAP D procedure
1. The IWF receives a (stand alone) MAP InsertSubscriberData message from the HSS.
2. If the MAP InsertSubscriberData does not contain any data related to SMS, the IWF ignores the received data data and skips to the step 4
If the MAP InsertSubscriberData contains data related to SMS, the IWF maps them into an IDR towards the MME and ignores the other received data data.
3. The IWF receives IDA from the MME.
4. The IWF sends InsertSubscriberData Ack to the HSS.
5. Steps 1 to 4 may be repeated several times for InsertSubscriberData. The repetition may be in burst mode or in acknowledge mode.
6. The HSS closes the MAP dialogue.
A.4.4.6 Delete Subscriber Data
A.4.4.6.1 Delete Subscriber Data over S6a
If the IWF receives a DSR from the HSS, the IWF sends the DSR unchanged to the MME apart the possible setting of the SMS in MME feature bit as described in subclause A.4.4.1
A.4.4.6.2 Delete Subscriber Data over MAP D
The mapping of the Delete Subscriber Data over MAP D procedure is shown in figure A.4.4.6.2-1:
Figure A.4.4.6.2-1: Mapping of the Delete Subscriber Data over MAP D procedure
1. The IWF receives a MAP DeleteSubscriberData message from the HSS.
2. If the MAP DeleteSubscriberData does not contain any data related to SMS, the IWF ignores the received data data. The IWF skips to step 4.If the MAP DeleteSubscriberData contains data related to SMS, the IWF maps them into a DSR towards the MME and ignores the other received data data .
3. The IWF receives DSA from the MME.
4. The IWF sends DeleteSubscriberData Ack to the HSS.
5 If the SMS subscription is withdrawn, the IWF sends an IDR to the MME with the indication to remove the MME registration for SMS. Otherwise the procedure is terminated.
6. The IWF receives an IDA from the MME.
7. The IWF sends a PurgeMS to the HSS.
8. The IWF receives a Purge MS Ack from the HSS.
A.4.4.7 Reset
The mapping of the Reset procedure is shown in figure A.4.4.7-1:
Figure A.4.4.7-1: Mapping of the Reset over S6a procedure
When there is a reset from HSS, the reset shall normally occur on both the S6a interface and the MAP D interface. The procedure handling may also apply when only a RSR is received on the S6a interface and no Reset message over the MAPD interface.
NOTE: It is out of the scope to address the handling of a Reset message received over the MAP D interface without receiving a RSR over the S6a interface.
1a. The IWF receives a RSR from the HSS, the IWF stores this information
1.b The IWF should receive a MAP Reset from the HSS.
2. The IWF sends a RSR unchanged to the MME.
3. The IWF receives a RSA from the MME.
4. The IWF sends the RSA unchanged to the HSS.
A.4.4.8 Notification
The mapping of the Notification procedure is shown in figure A.4.4.8-1:
Figure A.4.4.8-1: Mapping of the Notification Procedure
1. The IWF receives a NOR message from the MME.
2a. If the NOR message contains notifications other than the Ready for SM from MME notification, the IWF sends a NOR message with the Ready for SM flag cleared, the Alert Reason information element removed and unchanged for the other notifications to the HSS.
3a. The IWF receives a NOA if a NOR was sent in step 2a.
2b. If the Ready for SM from MME flag is set in the NOR received in step 1, the IWF sends a MAP ReadyForSM message to the HSS.
3b. The IWF receives a MAP ReadyForSM Ack message, if a MAP ReadyForSM message was sent in step 2b.
4 If the NOR and/or the MAP ReadyForSM Ack messages received from the HSS are successful, the IWF sends a successful NOA to the MME.
The steps 2a/3a and 2b/3b may occur in parallel.
If one of the NOA or ReadyForSM answer from the HSS is successful and the other unsuccessful, the NOA sent to MME should be with an unsuccessful result mapped from the received error.
A.4.5 The mapping of parameters
A.4.5.1 Unchanged AVPs
Many commands between the MME and the IWF are not specific to SMS and are transferred over the S6a interface between the IWF and the HSS. Unless otherwise stated in the following A.4.5 subclauses, the AVPs received by the IWF in a Diameter command are transferred unchanged in the Diameter command sent by the IWF.
A.4.5.2 Mapping of Parameters for the Update Location procedure
A.4.5.2.1 ULR mapping to ULR
When the IWF receives a ULR from the MME with the SMS in MME feature bit set, the IWF generates a ULR towards the HSS where:
– the feature bit "SMS in MME" shall not be set;
– the MME-Number-for-MT-SMS AVP, the SMS-Only AVP and the SMS-Register-Request AVP shall be removed.
A.4.5.2.1 ULR mapping to UpdateLocationArg
When the IWF needs to construct a MAP-UpdateLocation message as a result of receiving an ULR command (see sections A.Z.4.2 step 4), the IWF shall open a MAP dialogue in application context version 3 and populate sub-parameters of UpdateLocationArg as described below:
– imsi in UpdateLocationArg shall be populated with the value of the User-Name AVP received within ULR.
– msc-Number in UpdateLocationArg shall be populated with the value of the MME-Number-for-MT-SMS AVP within ULR,
– vlr-Number in UpdateLocationArg shall be populated with a value locally assigned to the IWF and consistent with SS7 routing principles.
– mme-DiameterAddress in UpdateLocationArg shall be present and be populated as follows
– diameter-Name shall be populated with the value received in the Origin-Host AVP within ULR;
– diameter-Realm shall be populated with the value received within the Origin-Realm AVP within ULR.
Other parameters defined for UpdateLocationArg shall be absent.
A.4.5.2.2 InsertSubscriberDataArg mapping to ULA
When the IWF needs to construct an ULA command as a result of receiving a successful ULA and a successful UpdateLocation Ack, the IWF shall behave as described in subclause A.Z.4.2 step 8 and in particular:
– Teleservice-List AVP shall only contain the TS-Code AVPs related to the short message teleservice with the values received in the corresponding Ext-TeleserviceCode parameters in the InsertSubscriberDataArg.
– Call-Barring-Info AVPs shall be present if call barring SS-code and SS-status parameters were present within the Call Barring Information List parameter within the InsertSubscriberDataArg and the SS-Code AVP and SS-Status AVP within the Call-Barring-Info AVPs shall be populated with the values of the received call barring SS-code and SS-status parameters within the Call Barring Information List parameter within the InsertSubscriberDataArg.
– Operator-Determined-Barring AVP shall be present if an odb-GeneralData parameter within SubscriberData parameter within InsertSubscriberDataArg was present with values related to call barring which shall be mapped to the corresponding flags within Operator-Determined-Barring AVP.
NOTE: ODB values in the ULA received from HSS are transferred unchanged in the ULA sent to the MME.
A.4.5.2.2 Mapping to InsertSubscriberDataRes
When the IWF needs to construct a MAP-InsertSubscriberData Ack message as a result of receiving an InsertSubscriberDataArg message (see subclause A.Z.4.2, step 6), the IWF shall populate sub-parameter of InsertSubscriberDataRes as follows:
– ss-List in InsertSubscriberDataRes shall include the ssCodes that have been received within InsertSubscriberDataArg and for which the corresponding flag of the Feature-List AVP is not set in the IDA.
– teleserviceList in InsertSubscriberDataRes shall include all teleserviceCodes that have been received within InsertSubscriberDataArg except those related to the short message teleservice.
– bearerServiceList in InsertSubscriberDataRes shall include all bearerServiceCodes that have been received within InsertSubscriberDataArg.
– odb-GeneralData in InsertSubscriberDataRes shall include all odb categoties that have been received within InsertSubscriberDataArg and that are not supported by the MME as indicated within the Supported-Feature AVP within ULR.
Other sub parameters in InsertSubscriberDataRes shall be absent.
– For InsertSubscriberData Error: Values other than SUCCESS within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate MAP error.
A.4.5.3 Mapping of Parameters for the Cancel Location procedure
A.4.5.3.1 CLR mapping to PurgeMSArg mapping to
When the IWF needs to construct a MAP-PurgeMS message as a result of receiving CLR command (see subclause A4.4.3.1 step 3), the IWF shall open a MAP dialogue in application context version 3 and populate sub-parameters of PurgeMS-Arg as described below:
– imsi in PurgeMS-Arg shall be populated with the imsi value of the User-Name AVP received within CLR.
– vlr-Number in PurgeMS-Arg shall be populated with the value given in the previous Update Location procedure.
– sgsn-Number and extensionContainer in PurgeMS-Arg shall be absent.
A.4.5.3.2 CancelLocationArg mapping to IDR
When the IWF needs to construct an IDR as a result of receiving a CancelLocation message (see subclause A.4.4.3.2 step 2), the IWF shall populate AVPs of DSR as described below:
IDR-Flags AVP:
– Remove SMS Registration flag shall be set to 1.
– Other flags shall be set to 0.
Subscription-Data AVP shall be included empty.
A.4.5.3.3 IDA mapping to CancelLocationRes/Error
When the IWF needs to construct a MAP-CancelLocation Ack message as a result of receiving an IDA command (see subclause A.4.4.3.2 step 4), the IWF shall populate sub-parameters of CancelLocationRes/Error as described below:
CancelLocationRes:
– extensionContainer in CancelLocationRes shall be absent.
CancelLocation Error:
– Values other than SUCCESS within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate MAP error.
A.4.5.4 Mapping of Parameters for the Purge Procedure
A.4.5.4.1 PUR mapping to PurgeMS-Arg
When the IWF needs to construct a MAP-PurgeMS message as a result of receiving a PUR command (see subclause A.4.4.4 step 2b), the IWF shall open a MAP dialogue in application context version 3 and populate sub-parameters of PurgeMS-Arg as described below:
– imsi in PurgeMS-Arg shall be populated with the imsi value of the User-Name AVP received within PUR.
– vlr-Number in PurgeMS-Arg shall be populated with the value given in the previous Update Location procedure.
– sgsn-Number and extensionContainer in PurgeMS-Arg shall be absent.
A.4.5.4.2 PurgeMS-Res / Error mapping to PUA
The Result-Code / Experimental-Result AVP and the other AVPs of the PUA sent by the IWF to the MME, shall be the same as those received in the PUA from the HSS and are not dependent of the PurgeMS Ack message received over MAP D.
A.4.5.5 Mapping of Parameters for the Insert Subscriber Data Procedure
A.4.5.5.1 InsertSubscriberDataArg mapping to IDR
When the IWF needs to construct an IDR as a result of receiving a InsertSubscriberData message, the IWF shall behave as described in subclause A.Z.4.2 step 8. In particular:
– Teleservice-List AVP, shall be present if short message related Ext-TeleserviceCode parameters were received and shall contain the TS-Code AVPs related to the short message teleservice with the values received in the corresponding Ext-TeleserviceCode parameters.
– Call-Barring-Info AVPs shall be present if call baring SS-code and SS-status parameters were present within the Call Barring Information List parameter within the InsertSubscriberDataArg and the SS-Code AVP and SS-Status AVP within the Call-Barring-Info AVPs shall be populated with the values of the received call barring SS-code and SS-status parameters within the Call Barring Information List parameter within the InsertSubscriberDataArg.
A.4.5.5.2 IDA mapping to InsertSubscriberDataRes/Error
When the IWF needs to construct a MAP-InsertSubscriberData Ack message as a result of receiving an IDA command (see subclause A.Z.4.5.2, step 4), the IWF shall populate sub-parameter of InsertSubscriberDataRes as follows:
ss-List in InsertSubscriberDataRes shall include the ssCodes that have been received within InsertSubscriberDataArg and for which the corresponding flag of the Feature-List AVP is not set in the IDA.
Other sub parameters in InsertSubscriberDataRes shall be absent.
For InsertSubscriberData Error: Values other than SUCCESS within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate MAP error.
A.4.5.6 Mapping of Parameters for the Delete Subscriber Data Procedure
A.4.5.6.1 DeleteSubscriberDataArg mapping to DSR
When the IWF needs to construct a DSR command as a result of receiving a MAP-DeleteSubscriberData message (see subclause A.4.4.6.2 step 2), the the IWF shall populate AVPs of DSR as described below:
– User-Name AVP shall be populated with the value received within the imsi parameter of DeleteSubscriberDataArg.
– Supported-Features AVP shall be absent.
– DSR-Flags AVP: Flags shall be set as follows:
– SMS Withdrawal shall be set to 1 if the SS-Code list parameter was present within DeleteSubscriberDataArg and the service codes are related to short message services; otherwise shall be set to 0.
– other flags shall be set to 0.
A.4.5.6.2 DSA mapping to DeleteSubscriberDataRes/Error
When the IWF needs to construct a MAP-DeleteSubscriberData Ack message as a result of receiving a DSA command (see subclause A.4.4.6.2 step 4), the IWF shall populate sub-parameters of DeleteSubscriberDataRes/Error as described below:
DeleteSubscriberDataRes:
– No sub-parameter shall be present in DeleteSubscriberDataRes.
DeleteSubscriberData Error:
Values other than SUCCESS within the Result-Code / Experimental-Result AVP shall be mapped onto an appropriate MAP error.
A.4.5.7 Mapping of Parameters for the Reset Procedure
A.4.5.7.1 Reset mapping to RSR
When the IWF needs to construct a RSR command as a result of receiving a RSR and a MAP Reset message (see subclause A.4.4.7 step 2), the IWF shall send the RSR received from HSS unchanged and ignore the sub-parameters of the MAP Reset message.
A.4.5.8 Mapping of Parameters for the Notification Procedure
A.4.5.8.1 NOR mapping to ReadyForSM-Arg
When the IWF needs to construct a MAP-ReadyForSM message as a result of receiving a NOR command (see subclause A.Z.4.8 step 2b), the IWF shall open a MAP dialogue in application context version 3 and populate sub-parameters of ReadyForSMArg as described below:
– imsi in ReadyForSMArg shall be populated with the value of the User-Name AVP received within NOR.
– alertReason in ReadyForSMArg shall be populated with the value of the Alert-Reason AVP received within NOR.
– alertReasonIndicator in ReadyForSMArg shall be absent.
– additionalAlertReasonIndicator in ReadyForSMArg shall be absent.
– extensionContainer in ReadyForSMArg shall be absent.
– maximumUeAvailabilityTime in ReadyForSMArg shall be present and populated with the value received within the Maximum-UE-Availability-Time AVP, when present, within NOR .
Annex B (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2008-12 |
CT#42 |
CP-080711 |
Version 1.0.0 approved in CT#42 |
8.0.0 |
|||
|
2009-03 |
CT#43 |
CP-090056 |
0001 |
Supported RAT Type |
8.1.0 |
||
|
CP-090056 |
0002 |
Trace |
|||||
|
CP-090056 |
0004 |
Context Identifier for Update or Removal of PDN GW |
|||||
|
CP-090044 |
0005 |
2 |
Ready For SM |
||||
|
CP-090044 |
0006 |
Handling LCS Subscription Data |
|||||
|
CP-090056 |
0007 |
1 |
Requesting-Node-Type mapping |
||||
|
CP-090056 |
0008 |
Parameter mapping correction |
|||||
|
CP-090044 |
0010 |
2 |
Handling SMS Subscription Data |
||||
|
2009-06 |
CT#44 |
CP-090308 |
0011 |
Parameter Mapping |
8.2.0 |
||
|
CP-090380 |
0013 |
3 |
User Data Download |
||||
|
2009-09 |
CT#45 |
CP-090545 |
0014 |
Notification of SMS over IP Non-Delivery for E-UTRAN and UE Reachability |
8.3.0 |
||
|
CP-090545 |
0015 |
Removal of User Data Handling Principles |
|||||
|
CP-090545 |
0016 |
2 |
Cancel Location for Initial Attach |
||||
|
2009-12 |
– |
– |
– |
– |
Update to Rel-9 version (MCC) |
9.0.0 |
|
|
2011-03 |
CT#51 |
CP-110082 |
0018 |
1 |
UE SRVCC Capability Support for IWF |
10.0.0 |
|
|
2011-06 |
CT#52 |
CP-110380 |
0020 |
1 |
Parameter Mapping for MDT |
10.1.0 |
|
|
2011-09 |
CT#53 |
CP-110584 |
0021 |
2 |
Add vSRVCC updates to the IWF function |
11.0.0 |
|
|
2012-03 |
CT#55 |
CP-120024 |
0026 |
1 |
Mapping of Parameters for Insert Subscriber Data |
11.1.0 |
|
|
CP-120025 |
0022 |
1 |
Mapping of Parameters for Cancel Location |
||||
|
2012-06 |
CT#56 |
CP-120240 |
0023 |
3 |
Mapping of CSG ID and Local Time for NPLI |
11.2.0 |
|
|
2012-09 |
CT#57 |
CP-120473 |
0029 |
4 |
SMS in MME/SGSN |
11.3.0 |
|
|
CP-120473 |
0032 |
1 |
SMS in MME IWF General |
||||
|
CP-120480 |
0034 |
1 |
Local Time Zone |
||||
|
2012-12 |
CT#58 |
CP-120714 |
0038 |
4 |
Clarification on EPS Info |
11.4.0 |
|
|
CP-120732 |
0033 |
5 |
SMS in MME S6c IWF |
||||
|
CP-120732 |
0035 |
3 |
SMS in MME IWF error cases for SGd |
||||
|
CP-120732 |
0036 |
5 |
SMS in MME S6a/S6a+D IWF |
||||
|
CP-120732 |
0037 |
– |
SMS in MME SGd IWF |
||||
|
2013-06 |
CT#60 |
CP-130278 |
0045 |
1 |
Parameter Mapping of SS Status for Call Barring |
11.5.0 |
|
|
2013-09 |
CT#61 |
CP-130450 |
0048 |
– |
MME Diameter address mapping |
11.6.0 |
|
|
2013-09 |
CT#61 |
CP-130463 |
0046 |
2 |
CancelLocation requesting reattach |
12.0.0 |
|
|
CP-130456 |
0047 |
1 |
IWF description for Gdd support |
||||
|
2013-12 |
CT#62 |
CP-130614 |
0050 |
4 |
Parameter Mapping for S6aS6d-Indicator in NOR |
12.1.0 |
|
|
CP-130617 |
0055 |
– |
Parameter Mapping for MME Initiated Removal of MME Registration for SMS |
||||
|
CP-130623 |
0051 |
1 |
S6c support for HSS and SMS Router |
||||
|
CP-130623 |
0056 |
1 |
Figures about IWF description for Gdd support |
||||
|
CP-130800 |
0052 |
2 |
IWFs with SMS for IMS UE without MSISDN |
||||
|
CP-130643 |
0053 |
1 |
Forwarding of Diameter based SRI for SMS |
||||
|
2014-09 |
CT#65 |
CP-140506 |
0058 |
1 |
P-CSCF Restoration Indication |
12.2.0 |
|
|
2015-06 |
CT#68 |
CP-150263 |
0060 |
1 |
Access Restriction Data per PLMN |
13.0.0 |
|
|
2015-12 |
CT#70 |
CP-150784 |
0061 |
1 |
Introducing IMSI-Group ID List |
13.1.0 |
|
|
2016-03 |
CT#71 |
CP-160030 |
0062 |
– |
Alert procedure from MME/SGSN to SMS-GMSC for MT SMS to UE using eDRX |
13.2.0 |
|
|
2017-03 |
CT#75 |
– |
– |
– |
Update to Rel-14 version (MCC) |
14.0.0 |
|
|
2017-12 |
CT#78 |
CP-173036 |
0063 |
– |
Mapping of ext-AccessRestrictionData in IWF |
15.0.0 |
|
|
2018-03 |
CT#79 |
CP-180012 |
0068 |
– |
Correction of DIAMETER_ERROR_SYSTEM_FAILURE |
15.1.0 |
|
|
2020-07 |
CT#88e |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
|
Change history |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
|
2008-12 |
CT#42 |
CP-080711 |
Version 1.0.0 approved in CT#42 |
1.0.0 |
8.0.0 |
||
|
2009-03 |
CT#43 |
CP-090056 |
0001 |
Supported RAT Type |
8.0.0 |
8.1.0 |
|
|
CP-090056 |
0002 |
Trace |
|||||
|
CP-090056 |
0004 |
Context Identifier for Update or Removal of PDN GW |
|||||
|
CP-090044 |
0005 |
2 |
Ready For SM |
||||
|
CP-090044 |
0006 |
Handling LCS Subscription Data |
|||||
|
CP-090056 |
0007 |
1 |
Requesting-Node-Type mapping |
||||
|
CP-090056 |
0008 |
Parameter mapping correction |
|||||
|
CP-090044 |
0010 |
2 |
Handling SMS Subscription Data |
||||
|
2009-06 |
CT#44 |
CP-090308 |
0011 |
Parameter Mapping |
8.1.0 |
8.2.0 |
|
|
CP-090380 |
0013 |
3 |
User Data Download |
||||
|
2009-09 |
CT#45 |
CP-090545 |
0014 |
Notification of SMS over IP Non-Delivery for E-UTRAN and UE Reachability |
8.2.0 |
8.3.0 |
|
|
CP-090545 |
0015 |
Removal of User Data Handling Principles |
|||||
|
CP-090545 |
0016 |
2 |
Cancel Location for Initial Attach |
||||
|
2009-12 |
– |
– |
– |
– |
Update to Rel-9 version (MCC) |
8.3.0 |
9.0.0 |
|
2011-03 |
CT#51 |
CP-110082 |
0018 |
1 |
UE SRVCC Capability Support for IWF |
9.0.0 |
10.0.0 |
|
2011-06 |
CT#52 |
CP-110380 |
0020 |
1 |
Parameter Mapping for MDT |
10.0.0 |
10.1.0 |
|
2011-09 |
CT#53 |
CP-110584 |
0021 |
2 |
Add vSRVCC updates to the IWF function |
10.1.0 |
11.0.0 |
|
2012-03 |
CT#55 |
CP-120024 |
0026 |
1 |
Mapping of Parameters for Insert Subscriber Data |
11.0.0 |
11.1.0 |
|
CP-120025 |
0022 |
1 |
Mapping of Parameters for Cancel Location |
||||
|
2012-06 |
CT#56 |
CP-120240 |
0023 |
3 |
Mapping of CSG ID and Local Time for NPLI |
11.1.0 |
11.2.0 |
|
2012-09 |
CT#57 |
CP-120473 |
0029 |
4 |
SMS in MME/SGSN |
11.2.0 |
11.3.0 |
|
CP-120473 |
0032 |
1 |
SMS in MME IWF General |
||||
|
CP-120480 |
0034 |
1 |
Local Time Zone |
||||
|
2012-12 |
CT#58 |
CP-120714 |
0038 |
4 |
Clarification on EPS Info |
11.3.0 |
11.4.0 |
|
CP-120732 |
0033 |
5 |
SMS in MME S6c IWF |
||||
|
CP-120732 |
0035 |
3 |
SMS in MME IWF error cases for SGd |
||||
|
CP-120732 |
0036 |
5 |
SMS in MME S6a/S6a+D IWF |
||||
|
CP-120732 |
0037 |
– |
SMS in MME SGd IWF |
||||
|
2013-06 |
CT#60 |
CP-130278 |
0045 |
1 |
Parameter Mapping of SS Status for Call Barring |
11.4.0 |
11.5.0 |
|
2013-09 |
CT#61 |
CP-130450 |
0048 |
– |
MME Diameter address mapping |
11.5.0 |
11.6.0 |
|
2013-09 |
CT#61 |
CP-130463 |
0046 |
2 |
CancelLocation requesting reattach |
11.6.0 |
12.0.0 |
|
CP-130456 |
0047 |
1 |
IWF description for Gdd support |
||||
|
2013-12 |
CT#62 |
CP-130614 |
0050 |
4 |
Parameter Mapping for S6aS6d-Indicator in NOR |
12.0.0 |
12.1.0 |
|
CP-130617 |
0055 |
– |
Parameter Mapping for MME Initiated Removal of MME Registration for SMS |
||||
|
CP-130623 |
0051 |
1 |
S6c support for HSS and SMS Router |
||||
|
CP-130623 |
0056 |
1 |
Figures about IWF description for Gdd support |
||||
|
CP-130800 |
0052 |
2 |
IWFs with SMS for IMS UE without MSISDN |
||||
|
CP-130643 |
0053 |
1 |
Forwarding of Diameter based SRI for SMS |
||||
|
2014-09 |
CT#65 |
CP-140506 |
0058 |
1 |
P-CSCF Restoration Indication |
12.1.0 |
12.2.0 |
|
2015-06 |
CT#68 |
CP-150263 |
0060 |
1 |
Access Restriction Data per PLMN |
12.2.0 |
13.0.0 |
|
2015-12 |
CT#70 |
CP-150784 |
0061 |
1 |
Introducing IMSI-Group ID List |
13.0.0 |
13.1.0 |
|
2016-03 |
CT#71 |
CP-160030 |
0062 |
– |
Alert procedure from MME/SGSN to SMS-GMSC for MT SMS to UE using eDRX |
13.1.0 |
13.2.0 |
|
2017-03 |
CT#75 |
– |
– |
– |
Update to Rel-14 version (MCC) |
13.2.0 |
14.0.0 |
|
2017-12 |
CT#78 |
CP-173036 |
0063 |
– |
Mapping of ext-AccessRestrictionData in IWF |
14.0.0 |
15.0.0 |
|
2018-03 |
CT#79 |
CP-180012 |
0068 |
– |
Correction of DIAMETER_ERROR_SYSTEM_FAILURE |
15.0.0 |
15.1.0 |
|
2020-07 |
CT#88e |
– |
– |
– |
Update to Rel-16 version (MCC) |
15.1.0 |
16.0.0 |
|
2022-04 |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
16.0.0 |
17.0.0 |