Internet Engineering Task Force (IETF) E. McMurry Request for Comments: 7068 B. Campbell Category: Informational Oracle ISSN: 2070-1721 November 2013 Diameter Overload Control Requirements
AbstractWhen a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by advising clients to reduce traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively severe overload condition. The existing Diameter mechanisms are not sufficient for managing overload conditions. This document describes the limitations of the existing mechanisms. Requirements for new overload management mechanisms are also provided. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7068.
Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction ....................................................4 1.1. Documentation Conventions ..................................4 1.2. Causes of Overload .........................................5 1.3. Effects of Overload ........................................6 1.4. Overload vs. Network Congestion ............................6 1.5. Diameter Applications in a Broader Network .................7 2. Overload Control Scenarios ......................................7 2.1. Peer-to-Peer Scenarios .....................................8 2.2. Agent Scenarios ...........................................10 2.3. Interconnect Scenario .....................................14 3. Diameter Overload Case Studies .................................15 3.1. Overload in Mobile Data Networks ..........................15 3.2. 3GPP Study on Core Network Overload .......................16 4. Existing Mechanisms ............................................17 5. Issues with the Current Mechanisms .............................18 5.1. Problems with Implicit Mechanism ..........................18 5.2. Problems with Explicit Mechanisms .........................18 6. Extensibility and Application Independence .....................19 7. Solution Requirements ..........................................20 7.1. General ...................................................20 7.2. Performance ...............................................21 7.3. Heterogeneous Support for Solution ........................22 7.4. Granular Control ..........................................23 7.5. Priority and Policy .......................................23 7.6. Security ..................................................23 7.7. Flexibility and Extensibility .............................24 8. Security Considerations ........................................25 8.1. Access Control ............................................25 8.2. Denial-of-Service Attacks .................................26 8.3. Replay Attacks ............................................26 8.4. Man-in-the-Middle Attacks .................................26 8.5. Compromised Hosts .........................................27 9. References .....................................................27 9.1. Normative References ......................................27 9.2. Informative References ....................................27 Appendix A. Contributors ..........................................29 Appendix B. Acknowledgements ......................................29
RFC6733] node is said to be overloaded when it has insufficient resources to successfully process all of the Diameter requests that it receives. When a node becomes overloaded, it needs to be able to gracefully reduce its load, typically by advising clients to reduce traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively severe overload condition. The existing mechanisms provided by Diameter are not sufficient for managing overload conditions. This document describes the limitations of the existing mechanisms and provides requirements for new overload management mechanisms. This document draws on the work done on SIP overload control ([RFC5390], [RFC6357]) as well as on experience gained via overload handling in Signaling System No. 7 (SS7) networks and studies done by the Third Generation Partnership Project (3GPP) (Section 3). Diameter is not typically an end-user protocol; rather, it is generally used as one component in support of some end-user activity. For example, a SIP server might use Diameter to authenticate and authorize user access. Overload in the Diameter backend infrastructure will likely impact the experience observed by the end user in the SIP application. The impact of Diameter overload on the client application (a client application may use the Diameter protocol and other protocols to do its job) is beyond the scope of this document. This document presents non-normative descriptions of causes of overload, along with related scenarios and studies. Finally, it offers a set of normative requirements for an improved overload indication mechanism. RFC2119], with the exception that they are not intended for interoperability of implementations. Rather, they are used to describe requirements towards future specifications where the interoperability requirements will be defined. The terms "client", "server", "agent", "node", "peer", "upstream", and "downstream" are used as defined in [RFC6733].
Network-initiated traffic flood: Certain access network events can precipitate floods of Diameter signaling traffic. For example, operational changes can trigger avalanche restarts, or frequent radio overlay handovers can generate excessive authorization requests. Failure of a Diameter proxy may also result in a large amount of signaling as connections and sessions are reestablished. Subscriber-initiated traffic flood: Large gatherings of subscribers or events that result in many subscribers interacting with the network in close time proximity can result in Diameter signaling traffic floods. For example, the finale of a large fireworks show could be immediately followed by many subscribers posting messages, pictures, and videos concentrated on one portion of a network. Subscriber devices such as smartphones may use aggressive registration strategies that generate unusually high Diameter traffic loads. DoS attacks: An attacker wishing to disrupt service in the network can cause a large amount of traffic to be launched at a target element. This can be done from a central source of traffic or through a distributed DoS attack. In all cases, the volume of traffic well exceeds the capacity of the element, sending the system into overload.
Network congestion issues are better handled by the transport protocols. Diameter uses TCP and the Stream Control Transmission Protocol (SCTP), both of which include congestion management features. Analysis of whether those features are sufficient for transport-level congestion between Diameter nodes and of any work to further mitigate network congestion is out of scope for both this document and the work proposed by it.
internal load-balancing and overload management so that it appears as a single Diameter node. That is, other Diameter nodes can treat it as a single, monolithic node for the purposes of overload management. These scenarios do not illustrate the client application. As mentioned in Section 1, Diameter is not typically an end-user protocol; rather, it is generally used in support of some other client application. These scenarios do not consider the impact of Diameter overload on the client application. Figure 1 illustrates the simplest possible Diameter relationship. The client and server share a one-to-one peer-to-peer relationship. If the server becomes overloaded, either because the client exceeds the server's capacity or because the server's capacity is reduced due to some resource dependency, the client needs to reduce the amount of Diameter traffic it sends to the server. Since the client cannot forward requests to another server, it must either queue requests until the server recovers or itself become overloaded in the context of the client application and other protocols it may also use. +------------------+ | | | | | Server | | | +--------+---------+ | | +--------+---------+ | | | | | Client | | | +------------------+ Figure 1: Basic Peer-to-Peer Scenario
Figure 2 shows a similar scenario, except in this case the client has multiple servers that can handle work for a specific realm and application. If Server 1 becomes overloaded, the client can forward traffic to Server 2. Assuming that Server 2 has sufficient reserve capacity to handle the forwarded traffic, the client should be able to continue serving client application protocol users. If Server 1 is approaching overload, but can still handle some number of new requests, it needs to be able to instruct the client to forward a subset of its traffic to Server 2. +------------------+ +------------------+ | | | | | | | | | Server 1 | | Server 2 | | | | | +--------+-`.------+ +------.'+---------+ `. .' `. .' `. .' `. .' +-------`.'--------+ | | | | | Client | | | +------------------+ Figure 2: Multiple-Server Peer-to-Peer Scenario Figure 3 illustrates a peer-to-peer scenario with multiple Diameter realm and application combinations. In this example, Server 2 can handle work for both applications. Each application might have different resource dependencies. For example, a server might need to access one database for Application A and another for Application B. This creates a possibility that Server 2 could become overloaded for Application A but not for Application B, in which case the client would need to divert some part of its Application A requests to Server 1, but the client should not divert any Application B requests. This requires that Server 2 be able to distinguish between applications when it indicates an overload condition to the client. On the other hand, it's possible that the servers host many applications. If Server 2 becomes overloaded for all applications, it would be undesirable for it to have to notify the client separately for each application. Therefore, it also needs a way to indicate that it is overloaded for all possible applications.
+---------------------------------------------+ | Application A +----------------------+----------------------+ |+------------------+ | +----------------+ | +------------------+| || | | | | | | || || | | | | | | || || Server 1 | | | Server 2 | | | Server 3 || || | | | | | | || |+--------+---------+ | +-------+--------+ | +-+----------------+| | | | | | | | +---------+-----------+----------+-----------+ | | | | | | | | | | | Application B | | +----------+----------------+-----------------+ ``-.._ | | `-..__ | _.-'' `--._ | _.-'' ``-._ | _.-'' +-----`-.-''-----+ | | | | | Client | | | +----------------+ Figure 3: Multiple-Application Peer-to-Peer Scenario
Figure 4 illustrates a simple Diameter agent scenario with a single client, agent, and server. In this case, overload can occur at the server, at the agent, or both. But in most cases, client behavior is the same whether overload occurs at the server or at the agent. From the client's perspective, server overload and agent overload are the same thing. +------------------+ | | | | | Server | | | +--------+---------+ | | +--------+---------+ | | | | | Agent | | | +--------+---------+ | | +--------+---------+ | | | | | Client | | | +------------------+ Figure 4: Basic Agent Scenario Figure 5 shows an agent scenario with multiple servers. If Server 1 becomes overloaded but Server 2 has sufficient reserve capacity, the agent may be able to transparently divert some or all Diameter requests originally bound for Server 1 to Server 2. In most cases, the client does not have detailed knowledge of the Diameter topology upstream of the agent. If the agent uses dynamic discovery to find eligible servers, the set of eligible servers may not be enumerable from the perspective of the client. Therefore, in most cases the agent needs to deal with any upstream overload issues in a way that is transparent to the client. If one server notifies the agent that it has become overloaded, the notification should not be passed back to the client in a way that the client could mistakenly perceive the agent itself as being overloaded. If the set
of all possible destinations upstream of the agent no longer has sufficient capacity for incoming load, the agent itself becomes effectively overloaded. On the other hand, there are cases where the client needs to be able to select a particular server from behind an agent. For example, if a Diameter request is part of a multiple-round-trip authentication, or is otherwise part of a Diameter "session", it may have a Destination-Host Attribute-Value Pair (AVP) that requires that the request be served by Server 1. Therefore, the agent may need to inform a client that a particular upstream server is overloaded or otherwise unavailable. Note that there can be many ways a server can be specified, which may have different implications (e.g., by IP address, by host name, etc). +------------------+ +------------------+ | | | | | | | | | Server 1 | | Server 2 | | | | | +--------+-`.------+ +------.'+---------+ `. .' `. .' `. .' `. .' +-------`.'--------+ | | | | | Agent | | | +--------+---------+ | | | +--------+---------+ | | | | | Client | | | +------------------+ Figure 5: Multiple-Server Agent Scenario
Figure 6 shows a scenario where an agent routes requests to a set of servers for more than one Diameter realm and application. In this scenario, if Server 1 becomes overloaded or unavailable while Server 2 still has available capacity, the agent may effectively operate at reduced capacity for Application A but at full capacity for Application B. Therefore, the agent needs to be able to report that it is overloaded for one application but not for another. +--------------------------------------------+ | Application A +----------------------+----------------------+ |+------------------+ | +----------------+ | +------------------+| || | | | | | | || || | | | | | | || || Server 1 | | | Server 2 | | | Server 3 || || | | | | | | || |+---------+--------+ | +-------+--------+ | +--+---------------+| | | | | | | | +----------+----------+----------+-----------+ | | | | | | | | | | | Application B | | +----------+-----------------+----------------+ | | | ``--.__ | _. ``-.__ | __.--'' `--.._ | _..--' +----``-+.''-----+ | | | | | Agent | | | +-------+--------+ | | +-------+--------+ | | | | | Client | | | +----------------+ Figure 6: Multiple-Application Agent Scenario
IR.34] is an Inter-Operator IP Backbone that provides a roaming interconnection network between mobile operators and service providers. IPX is also used to transport Diameter signaling between operators [IR.88]. Figure 7 shows two network operators with an interconnect network between them. There could be any number of these networks between any two network operators' networks. +-------------------------------------------+ | Interconnect | | | | +--------------+ +--------------+ | | | Server 3 |------| Server 4 | | | +--------------+ +--------------+ | | .' `. | +------.-'--------------------------`.------+ .' `. .-' `. ------------.'-----+ +----`.------------- +----------+ | | +----------+ | Server 1 | | | | Server 2 | +----------+ | | +----------+ | | Network Operator 1 | | Network Operator 2 -------------------+ +------------------- Figure 7: Two-Network Interconnect Scenario The characteristics of the information that an operator would want to share over such a connection are different from the information shared between components within a network operator's network. For example, network operators may not want to convey topology or operational information; this would in turn limit how much overload and loading information can be sent. For the interconnect scenario shown in Figure 7, Server 2 may want to signal overload to Server 1, to affect traffic coming from Network Operator 1. This case is distinct from those internal to a network operator's network, where there may be many more elements in a more complicated topology. Also, the elements in the interconnect network may not support Diameter overload control, and the network operators may not want the interconnect network to use overload or loading information. They may only want the information to pass through the interconnect
network without further processing or action by the interconnect network, even if the elements in the interconnect network do support Diameter overload control. TR23.843]. The root causes of the HLR overload events were manifold but included hardware failure and procedural errors. The result was high signaling traffic load on the HLR and HSS. The 3GPP architecture [TS23.002] makes extensive use of Diameter. It is used for mobility management [TS29.272], the IP Multimedia Subsystem (IMS) [TS29.228], and policy and charging control [TS29.212], as well as other functions. The details of the architecture are out of scope for this document, but it is worth noting that there are quite a few Diameter applications, some with quite large amounts of Diameter signaling in deployed networks. The 3GPP specifications do not currently address overload for Diameter applications or provide a load control mechanism equivalent to those provided in the more traditional SS7 elements in the Global System for Mobile Communications (GSM); see [TS29.002]. The capabilities specified in the 3GPP standards do not adequately address the abnormal condition where excessively high signaling traffic load situations are experienced. Smartphones, which comprise an increasingly large percentage of mobile devices, contribute much more heavily, relative to non-smartphones, to the continuation of a registration surge, due to their very aggressive registration algorithms. Smartphone behavior contributes to network loading and can contribute to overload conditions. The aggressive smartphone logic is designed to: a. always have voice and data registration, and b. constantly try to be on 3G or LTE data (and thus on 3G voice or Voice over LTE (VoLTE) [IR.92]) for their added benefits. Non-smartphones typically have logic to wait for a time period after registering successfully on voice and data.
The aggressive smartphone registration is problematic in two ways: o first, by generating excessive signaling load towards the HSS that is ten times the load from a non-smartphone, and o second, by causing continual registration attempts when a network failure affects registrations through the 3G data network. TR23.843]. This enumerates several causes of overload in mobile core networks, including portions that are signaled using Diameter. [TR23.843] is a work in progress and is not complete. However, it is useful for pointing out scenarios and the general need for an overload control mechanism for Diameter. It is common for mobile networks to employ more than one radio technology and to do so in an overlay fashion with multiple technologies present in the same location (such as 2nd or 3rd generation mobile technologies, along with LTE). This presents opportunities for traffic storms when issues occur on one overlay and not another as all devices that had been on the overlay with issues switch. This causes a large amount of Diameter traffic as locations and policies are updated. Another scenario called out by this study is a flood of registration and mobility management events caused by some element in the core network failing. This flood of traffic from end nodes falls under the network-initiated traffic flood category. There is likely to also be traffic resulting directly from the component failure in this case. A similar flood can occur when elements or components recover as well. Subscriber-initiated traffic floods are also indicated in this study as an overload mechanism where a large number of mobile devices are attempting to access services at the same time, such as in response to an entertainment event or a catastrophic event. While this 3GPP study is concerned with the broader effects of these scenarios on wireless networks and their elements, they have implications specifically for Diameter signaling. One of the goals of this document is to provide guidance for a core mechanism that can be used to mitigate the scenarios called out by this study.
RFC3539] ensures that transaction responses occur at a certain rate even when there is otherwise little or no other Diameter traffic. The explicit mechanism can involve specific protocol error responses, where an agent or server tells a downstream peer that it is either too busy to handle a request (DIAMETER_TOO_BUSY) or unable to route a request to an upstream destination (DIAMETER_UNABLE_TO_DELIVER) perhaps because that destination itself is overloaded to the point of unavailability. Another explicit mechanism, a DPR (Disconnect-Peer-Request) message, can be sent with a Disconnect-Cause of BUSY. This signals the sender's intent to close the transport connection and requests that the client not reconnect. Once a Diameter node learns via one of these mechanisms that an upstream peer has become overloaded, it can then attempt to take action to reduce the load. This usually means forwarding traffic to an alternate destination, if available. If no alternate destination is available, the node must either reduce the number of messages it originates (in the case of a client) or inform the client to reduce traffic (in the case of an agent). Diameter requires the use of a congestion-managed transport layer, currently TCP or SCTP, to mitigate network congestion. It is expected that these transports manage network congestion and that issues with transport (e.g., congestion propagation and window management) are managed at that level. But even with a congestion- managed transport, a Diameter node can become overloaded at the Diameter protocol or application layers due to the causes described in Section 1.2, and congestion-managed transports do not provide facilities (and are at the wrong level) to handle server overload. Transport-level congestion management is also not sufficient to address overload in cases of multi-hop and multi-destination signaling.
RFC6733] indicates that the sending client should attempt to send the request to a different peer. It makes no suggestion that the receipt of a DIAMETER_TOO_BUSY response should affect future Diameter messages in any way. The Authentication, Authorization, and Accounting (AAA) Transport Profile [RFC3539] recommends that a AAA node that receives a "Busy" response failover all remaining requests to a different agent or server. But while the Diameter base specification explicitly depends on [RFC3539] to define transport behavior, it does not refer to [RFC3539] in the description of behavior on receipt of a DIAMETER_TOO_BUSY error. There's a strong likelihood that at least some implementations will continue to send Diameter requests to an upstream peer even after receiving a DIAMETER_TOO_BUSY error.
BCP 41 [RFC2914] describes, among other things, how end-to-end application behavior can help avoid congestion collapse. In particular, an application should avoid sending messages that will never be delivered or processed. The DIAMETER_TOO_BUSY behavior as described in the Diameter base specification fails at this, since if an upstream node becomes overloaded, a client attempts each request and does not discover the need to failover the request until the initial attempt fails. The situation is improved if implementations follow the [RFC3539] recommendation to keep state about upstream peer overload. But even then, the Diameter specification offers no guidance on how long a client should wait before retrying the overloaded destination. If an agent or server supports multiple realms and/or applications, DIAMETER_TOO_BUSY offers no way to indicate that it is overloaded for one application but not another. A DIAMETER_TOO_BUSY error can only indicate overload at a "whole server" scope. Agent processing of a DIAMETER_TOO_BUSY response is also problematic as described in the base specification. DIAMETER_TOO_BUSY is defined as a protocol error. If an agent receives a protocol error, it may either handle it locally or forward the response back towards the downstream peer. If a downstream peer receives the DIAMETER_TOO_BUSY response, it may stop sending all requests to the agent for some period of time, even though the agent may still be able to deliver requests to other upstream peers. DIAMETER_UNABLE_TO_DELIVER errors, or using DPR with cause code BUSY, also have no mechanisms for specifying the scope or cause of the failure, or the durational validity. The issues with error responses described in [RFC6733] extend beyond the particular issues for overload control and have been addressed in an ad hoc fashion by various implementations. Addressing these in a standard way would be a useful exercise, but it is beyond the scope of this document.
Similarly, the scopes to which overload information may apply may include cases that have not yet been considered. Extensibility in this area will also be important. The basic mechanism is intended to be application independent, that is, a Diameter node can use it across any existing and future Diameter applications and expect reasonable results. Certain Diameter applications might, however, benefit from application- specific behavior over and above the mechanism's defaults. For example, an application specification might specify relative priorities of messages or selection of a specific overload control algorithm. Section 5 and supporting the scenarios described in Section 2. These requirements are stated primarily in terms of individual node behavior to inform the design of the improved mechanism; solution designers should keep in mind that the overall goal is improved overall system behavior across all the nodes involved, not just improved behavior from specific individual nodes.
REQ 5: Diameter allows nodes to determine their peers via dynamic discovery or manual configuration. The solution MUST work consistently without regard to how peers are determined. REQ 6: The solution designers SHOULD seek to minimize the amount of new configuration required in order to work. For example, it is better to allow peers to advertise or negotiate support for the solution, rather than to require that this knowledge be configured at each node.
REQ 14: Some scenarios that result in overload involve a rapid increase of traffic with little time between normal levels and levels that induce overload. The solution SHOULD provide for rapid feedback when traffic levels increase. REQ 15: The solution MUST NOT interfere with the congestion control mechanisms of underlying transport protocols. For example, a solution that opened additional TCP connections when the network is congested would reduce the effectiveness of the underlying congestion control mechanisms.
that this requirement was expressed at a high level so as to not preclude any particular solution. Is is expected that the solution will address this in more detail. REQ 28: The solution MUST NOT depend on being deployed in environments where all Diameter nodes are completely trusted. It SHOULD operate as effectively as possible in environments where other nodes are malicious; this includes preventing malicious nodes from obtaining more than a fair share of service. Note that this does not imply any responsibility on the solution to detect, or take countermeasures against, malicious nodes. REQ 29: It MUST be possible for a supporting node to make authorization decisions about what information will be sent to peer nodes based on the identity of those nodes. This allows a domain administrator who considers the load of their nodes to be sensitive information to restrict access to that information. Of course, in such cases, there is no expectation that the solution itself will help prevent overload from that peer node. REQ 30: The solution MUST NOT interfere with any Diameter-compliant method that a node may use to protect itself from overload from non-supporting nodes or from denial-of-service attacks.
REQ 33: The solution MUST provide a default algorithm that is mandatory to implement. REQ 34: The solution SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the solution. RFC6733] lacks end-to-end security, making it difficult for non-adjacent nodes to verify the authenticity and ownership of load and overload information. Authentication of load and overload information helps to alleviate several of the security issues listed in this section. This document includes requirements intended to mitigate the effects of attacks and to protect the information used by the mechanism. This section discusses potential security considerations for overload control solutions. This discussion provides the motivation for several normative requirements described in Section 7. The discussion includes specific references to the normative requirements that apply for each issue.
from seeing overload information. Note that this implies a certain amount of configurability on the nodes supporting the Diameter overload control mechanism.
REQs 27, 28, and 29 imply a need to prevent man-in-the-middle attacks on the overload control solution. A transport using Transport Layer Security (TLS) and/or IPsec may be desirable for this purpose. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003. [RFC5390] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", RFC 5390, December 2008. [RFC6357] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design Considerations for Session Initiation Protocol (SIP) Overload Control", RFC 6357, August 2011. [TR23.843] 3GPP, "Study on Core Network (CN) overload solutions", TR 23.843 1.2.0, Work in Progress, October 2013.
[IR.34] GSMA, "Inter-Service Provider IP Backbone Guidelines", IR 34 9.1, May 2013. [IR.88] GSMA, "LTE Roaming Guidelines", IR 88 9.0, January 2013. [IR.92] GSMA, "IMS Profile for Voice and SMS", IR 92 7.0, March 2013. [TS23.002] 3GPP, "Network Architecture", TS 23.002 12.2.0, June 2013. [TS29.272] 3GPP, "Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol", TS 29.272 12.2.0, September 2013. [TS29.212] 3GPP, "Policy and Charging Control (PCC) over Gx/Sd reference point", TS 29.212 12.2.0, September 2013. [TS29.228] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents", TS 29.228 12.0.0, September 2013. [TS29.002] 3GPP, "Mobile Application Part (MAP) specification", TS 29.002 12.2.0, September 2013.