A.1 T6a/b and T7 interfaces

29.1283GPPMobility Management Entity (MME) and Serving GPRS Support Node (SGSN) interfaces for interworking with packet data networks and applicationsRelease 17TS

A.1.1 General

The Diameter overload control mechanism is an optional feature over the T6a/b and T7 interface, which may be applied to the traffic of requests commands sent to the SCEF and/or to the traffic of request commands sent to the MME or SGSN.

It is recommended to make use of the IETF RFC 7683 [9] on the T6a/b and T7 interface where:

– when applied to the traffic of request commands sent to the SCEF, the SCEF shall behave as a reporting node while the MME/SGSN, and as an alternative the IWK-SCEF shall behave as a reacting node;

– when applied to the traffic of request commands sent to the MME or SGSN, the MME or SGSN shall behave as a reporting node while the SCEF, and as an alternative the IWK-SCEF, shall behave as a reacting node.

A.1.2 SCEF behaviour

The SCEF requests traffic reduction from the MME/SGSN and the IWK-SCEF when it is in an overload situation, by including OC-OLR AVP in answer commands as described in IETF RFC 7683 [9].

The SCEF identifies that it is in an overload situation by implementation specific means. For example, the SCEF may take into account the traffic over the T6a/b interfaces or other interfaces, the level of usage of internal resources (CPU, memory), the access to external resources etc.

The SCEF determines the specific contents of the OC-OLR AVP in overload reports and the SCEF decides when to send OC-OLR AVPs by implementation specific means.

The SCEF may decide to deactivate Monitoring events to reduce the number of Reporting-Information-Requests sent for reporting monitoring events.

The SCEF shall apply required traffic reduction according to the OC-OLR AVPs received in answer commands from the MME to subsequent applicable requests, as per IETF RFC 7683 [9].

Requested traffic reduction is achieved by the SCEF by implementation specific means. It may in particular implement throttling of MT non-IP data messages.

A.1.3 MME/SGSN behaviour

The MME or SGSN requests traffic reduction from the SCEF when it is in an overload situation, by including OC-OLR AVP in answer commands as described in IETF RFC 7683 [9].

The MME or SGSN identifies that it is in an overload situation by implementation specific means.

The MME or SGSN shall apply required traffic reduction according to the OC-OLR AVPs received in answer commands from the SCEF to subsequent applicable requests, as per IETF RFC 7683 [9].

Requested traffic reduction is achieved by the MME or SGSN by implementation-specific means. It may in particular implement:

– throttling of monitoring event reports or stop reporting with prioritization (e.g. prioritisation on the type of events, or that one-time reporting takes priority over continuous reporting, …);

– throttling of new T6a/b connection establishment messages;

– throttling of MO non-IP data messages.

A.1.4 IWK-SCEF behaviour

The IWK-SCEF, when acting as a reacting node towards the SCEF shall apply required traffic reduction received in answer commands from the SCEF to subsequent applicable requests received from the MME or SGSN, as per IETF RFC 7683 [9]. In this case the IWK-SCEF does not forward OC-OLR AVPs to the MME or SGSN.

The IWK-SCEF, when acting as a reacting node towards the MME or SGSN, shall apply required traffic reduction received in answer commands from the MME or SGSN to subsequent applicable requests received from the SCEF, as per IETF RFC 7683 [9]. In this case the IWK-SCEF does not forward OC-OLR AVPs to the SCEF.

Requested traffic reduction is achieved by the IWK-SCEF by implementation specific means. For example, it may implement throttling of monitoring event report with prioritization, throttling of MO data or MT data messages.

Annex B (normative):
Diameter message priority mechanism