S6m AVPs
S6m (application id: 16777310)
The S6m interface is an integral component of the Diameter protocol architecture, specifically designed for Machine-Type Communication (MTC) systems. S6m reference point establishes communication between the Machine-Type Communication Interworking Function (MTC-IWF) and the Home Subscriber Server (HSS). This interface plays a critical role in managing the lifecycle, authentication, authorization, and service requests for MTC devices within the network.
Architecture of the S6m Interface
In the broader MTC architecture, the S6m interface operates alongside other key interfaces:
- S6n: Connects the MTC-AAA (Authentication, Authorization, and Accounting) server with the HSS, enabling authentication and mapping of external identifiers.
- S6t: Connects the Service Capability Exposure Function (SCEF) with the HSS, facilitating configuration and reporting of monitoring events and communication patterns.
The S6m interface allows the MTC-IWF to perform various operations, including retrieving subscriber information, requesting routing data, and authorizing service capability requests. This is essential for ensuring that MTC devices can effectively communicate and function within the network, even under conditions that differ from traditional human-to-human communication models.
The S6m interface is designed to support the following key functions:
- Retrieving Subscription Information: The MTC-IWF uses the S6m interface to access detailed subscription data for a UE stored in the HSS. This data is necessary for managing the UE's interaction with the network, particularly in scenarios where the device may have limited or specialized communication needs.
- Requesting Routing Information: The interface allows the MTC-IWF to request routing information from the HSS, including the addresses of the serving nodes (such as MSC, MME, or IP-SM-GW) that support SMS delivery to the UE. This ensures that messages and commands are correctly routed through the network.
- Retrieving Identifiers: The S6m interface facilitates the retrieval of the IMSI (International Mobile Subscriber Identity) of the UE, as well as any external identifiers linked to specific applications or services. These identifiers are crucial for mapping various identities associated with a single UE.
- Authorizing Service Capability Requests: When a Service Capability Server (SCS) requests to trigger a specific service for a UE, the MTC-IWF uses the S6m interface to authorize this request with the HSS. The HSS evaluates the request against the UE’s subscription data and either approves or denies the service initiation.
S6m interface workflow:
Initiation of Subscriber Information Retrieval:
- The MTC-IWF initiates a request to the HSS through the S6m interface to retrieve subscriber information. This may include translating an external identifier (e.g., MSISDN) to the IMSI of the UE or fetching routing details for service delivery.
Request for Routing Information:
- Once the subscriber information is retrieved, the MTC-IWF may request routing information to determine the address of the UE's serving node, such as the MSC or MME. This information is crucial for directing SMS or other services to the correct network destination.
Retrieval of Identifiers:
- The MTC-IWF retrieves the IMSI and any associated external identifiers from the HSS, ensuring that the UE is correctly identified within the network and that all associated services are properly managed.
Authorization of Service Requests:
- The MTC-IWF sends a service capability request to the HSS via the S6m interface for authorization. The HSS verifies the request based on the UE’s subscription data and decides whether to grant or deny the requested service. This step ensures that only authorized services are executed for the UE.
Response Handling:
- The HSS processes the request and sends a response back to the MTC-IWF. If approved, the service is initiated; if denied, the MTC-IWF may notify the requesting entity (e.g., SCS) of the denial, potentially triggering alternative actions.
For complete technical specification of S6m interface in Diameter protocol please refer to: [3GPP TS 29.336]
package com.mobius.software.telco.protocols.diameter.primitives.s6m
|
Name |
AVP Code |
Data Type |
Vendor |
|
Additional-Serving-Node |
2406 |
Grouped |
3GPP |
|
Provides details about an additional serving node to be used for T4-triggering procedures, particularly in the context of user location management and trace activation. The AVP structure is defined as follows: SGSN-Name (Optional): FQDN of the SGSN serving the subscriber. SGSN-Realm (Optional): Diameter realm of the SGSN (used for routing in Diameter). SGSN-Number (Optional): ISDN-formatted address of the SGSN. MME-Name (Optional): FQDN of the MME serving the subscriber. MME-Realm (Optional): Diameter realm of the MME. MME-Number-for-MT-SMS (Optional): ISDN number of the MME used specifically for MT-SMS delivery. MSC-Number (Optional): ISDN address of the MSC currently serving the subscriber. Additional AVPs (Optional, Multiple): Reserved for future extensibility or vendor-specific attributes. Allowed Combinations (as per 3GPP [TS 29.173]): a) SGSN-Number b) SGSN-Name + SGSN-Realm + SGSN-Number Used when the HSS supports the "Gdd in SGSN" feature and has received the "Gdd in SGSN" indication over S6a or Gr interface from the SGSN (cf. 3GPP [TS 29.272] and 3GPP [TS 29.002]). c) MME-Name + MME-Realm + MME-Number-for-MT-SMS d) MSC-Number e) MSC-Number + MME-Name + MME-Realm |
|||
|
External-Identifier |
3111 |
UTF8String |
3GPP |
|
Used on various 3GPP interfaces, including S6m, S6n, and S6t, to convey an external identifier for a user. On the S6m/S6n interfaces, it specifically contains an external identifier for the UE (User Equipment). On the S6t interface, it can represent either an individual UE identifier or a group identifier, as indicated by the accompanying Type-Of-External-Identifier AVP. For all use cases, the format and definition of the external identifier are specified in 3GPP [TS 23.003]. |
|||
|
HSS-Cause |
3109 |
Unsigned32 (Bitmask) |
3GPP |
|
Reports cause information from the Home Subscriber Server (HSS) regarding a user’s status or service availability. Bitmask Definition: Bit 0: Absent Subscriber: Indicates that no serving node is currently registered in the HSS for the user or the user is known to be unreachable for non-priority triggers. Bit 1: Teleservice Not Provisioned: Indicates that the required teleservice(s) for the triggered action are not provisioned for the user in the HSS/HLR. Bit 2: Call Barred: Indicates that there is an active barring condition for the user, preventing the requested triggering method from being delivered. Notes: This may be caused because there is not any serving node currently registered in HSS for the user, or because the user is known to be absent in all suitable registered serving nodes (based on MNRF, MNRG and UNRI flags) and the trigger delivery is requested with "non-priority". Bits not defined in this table shall be cleared by the HSS and discarded by the receiving node, MTC-IWF. |
|||
|
IP-SM-GW-Name |
3101 |
DiameterIdentity |
3GPP |
|
Used to carry the unique Diameter identity of the IP Short Message Gateway (IP-SM-GW). This AVP ensures that network entities can correctly identify and route Diameter messages to the IP-SM-GW associated with a particular user or service. For further details on the encoding of this AVP, see IETF [RFC 3588]. |
|||
|
IP-SM-GW-Number |
3100 |
OctetString |
3GPP |
|
Contains the ISDN number of the IP-SM-GW in international number format as described in [ITU-T Rec E.164]. It shall be encoded as a TBCD-string. See 3GPP [TS 29.002] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan. |
|||
|
IP-SM-GW-Realm |
3112 |
DiameterIdentity |
3GPP |
|
Specifies the realm of the IP Short Message Gateway (IP-SM-GW). For further details on the encoding of this AVP, see IETF [RFC 3588]. |
|||
|
SCS-Identity |
3104 |
OctetString |
3GPP |
|
Contains the identity of the Service Capability Server (SCS) or UE originating a service request toward the MTC-IWF on the Tsp interface. The encoding of the SCS-Identity AVP is defined per SCS service. For the device triggering service, the SCS-Identity AVP shall contain the ISDN number of the SCS in international ISDN number format as described in [ITU-T Rec E.164]. It shall be encoded as a TBCD-string. See 3GPP [TS 29.002] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan. |
|||
|
Service-Data |
3107 |
Grouped |
3GPP |
|
Contains service-specific data relevant to device-triggering requests handled by the MTC-IWF. The AVP structure is defined as follows: T4-Data (Optional): Contains information specific to T4-triggering. Implementations may also include additional AVPs within the Service-Data. |
|||
|
Service-ID |
855 |
Enumerated |
3GPP |
|
Identifies the specific service requested by the SCS on the S6m interface. Enumerated Values: SMS_MO (1): Indicates a mobile-originated SMS service request from the UE (identified by IMSI and application port) for delivery to the SCS. |
|||
|
Service-Parameters |
3105 |
Grouped |
3GPP |
|
Contains the service-specific parameters associated with a requested service on the S6m interface. The AVP structure is defined as follows: T4-Parameters (Optional): Holds information pertinent to T4-triggering, if applicable. Application-Port-Identifier (Optional): Specifies the port identifier used by the application for signaling or data transmission. |
|||
|
Serving-Node |
2401 |
Grouped |
3GPP |
|
Used to identify the current serving node for a subscriber. It is primarily employed in T4-triggering and location services, enabling proper message routing and node identification within the network. The AVP structure is defined as follows: SGSN-Name (Optional): Fully Qualified Domain Name (FQDN) of the Serving GPRS Support Node (SGSN). SGSN-Realm (Optional): Diameter realm of the SGSN for routing purposes. SGSN-Number (Optional): ISDN address of the SGSN (TBCD-encoded as per E.164). MME-Name (Optional): FQDN of the Mobility Management Entity (MME). MME-Realm (Optional): Diameter realm of the MME. MME-Number-for-MT-SMS (Optional): ISDN address of the MME for Mobile-Terminated SMS delivery. MSC-Number (Optional): ISDN address of the Mobile Switching Center (MSC). IP-SM-GW-Number (Optional): ISDN number of the IP Short Message Gateway (IP-SM-GW). IP-SM-GW-Name (Optional): FQDN of the IP-SM-GW. IP-SM-GW-Realm (Optional): Diameter realm of the IP-SM-GW. Additional AVPs (Optional, Multiple) included for extensibility or vendor-specific purposes. Allowed Parameter Combinations: a) SGSN-Number b) SGSN-Name + SGSN-Realm + SGSN-Number. Used when the HSS supports the "Gdd in SGSN" feature and has received the "Gdd in SGSN" indication over S6a or Gr interface from the SGSN (cf. 3GPP [TS 29.272] and 3GPP [TS 29.002]). c) MME-Name + MME-Realm + MME-Number-for-MT-SMS d) MSC-Number e) MSC-Number + MME-Name + MME-Realm f) IP-SM-GW-Number g) IP-SM-GW-Number + IP-SM-GW-Name + IP-SM-GW-Realm |
|||
|
SIR-Flags |
3110 |
Unsigned32 (Bitmask) |
3GPP |
|
Contains a bitmask used to indicate specific interface context information in Subscriber Information Request (SIR) messages. Bitmask Definition: 0: S6m/S6n Indicator: When set to 1, it indicates the SIR message is sent over the S6m interface (source node is MTC-IWF). When set to 0, it indicates the SIR message is sent over the S6n interface (source node is MTC-AAA). Note: All other bits not defined in the specification must be cleared by the sender (either MTC-IWF or MTC-AAA) and disregarded by the receiving HSS. |
|||
|
T4-Data |
3108 |
Grouped |
3GPP |
|
Used to carry information about the network node(s) serving the targeted user for SMS delivery. This includes details such as the names or numbers of the serving nodes (e.g., MSC or MME, SGSN, IP-SM-GW) which are responsible for triggering the delivery. The AVP structure is defined as follows: HSS-Cause (Optional): Indicates the reason or cause as determined by the HSS. Depending on its value, it can affect the presence of other AVPs. Serving-Node (Optional): Contains information about the primary network node serving the subscriber. This AVP should be absent if the HSS-Cause indicates conditions like Absent Subscriber, Teleservice Not Provisioned, or Call Barred. Additional-Serving-Node (Optional, Multiple): May include one or more AVPs carrying information about other nodes involved. It is only present if the Serving-Node AVP is also present. When the HSS-Cause indicates Absent Subscriber (via its respective flag), both the Serving-Node and Additional-Serving-Node AVPs shall not be present. Similarly, if the HSS-Cause indicates Teleservice Not Provisioned or Call Barred, these node-related (Serving-Node and Additional-Serving-Node) AVPs should not be included. |
|||
|
T4-Parameters |
3106 |
Grouped |
3GPP |
|
Carries parameters related to T4 procedures in the Diameter protocol. The AVP structure is defined as follows: Priority-Indication (Optional): This field, represented by an enumerated type, indicates the priority level for the SMS session handling. It allows the network to apply specific processing rules based on the message priority. SM-RP-SMEA (Optional): This parameter contains a byte buffer that typically includes session or message-related information for Short Message Relay Protocol (SM-RP) signaling. Its presence provides additional context for processing SMS sessions in the network. This AVP may also include additional AVPs as needed. |
|||
|
User-Identifier |
3102 |
Grouped |
3GPP |
|
Encapsulates various identifiers used by the User Equipment (UE). The AVP structure is defined as follows: User-Name (Optional): Typically includes the IMSI of the UE when applicable, serving as a primary identifier in many cases. MSISDN (Optional): Contains the mobile station international subscriber directory number, providing an additional identifier for the UE. External-Identifier (Optional): Offers an external reference identifier that may be used for integration with external systems. LMSI (Optional): Carries a byte buffer representing the Local Mobile Subscriber Identifier, used in scenarios where further differentiation of the UE is needed. This AVP shall contain at least one of the identifiers used by the UE, i.e., it shall not be empty. The IMSI of the UE shall be included (when applicable) in the User-Name AVP. |
|||
Start innovating with Mobius
What's next? Let's talk!