Content for TS 29.405 Word version: 18.0.0

3.1 Definitions 3.2 Abbreviations 5.1 Introduction 5.2 IMSI and APN Information Retrieval Procedure 5.3 APN Information Retrieval Procedure 6.1 General 6.2 IP layer 6.3 Transport layer
...

1 Scope p. 6

The present document specifies the procedures and the Nq and Nq' Application Protocol (Nq-AP) messages used on the Nq/Nq' interfaces between the RAN Congestion Awareness Function (RCAF) and the Mobility Management Entity (MME) or the Serving GPRS Support Node (SGSN). The related stage 2 requirements are specified in TS 23.401 and TS 23.060.

2 References p. 6

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access".

[3]

TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2".

[4]

TS 29.303: "Domain Name System Procedures; Stage 3"

[5]

TS 23.003: "Numbering, addressing and identification".

[6]

RFC 791 (September 1981): "Internet Protocol".

[7]

RFC 2460 (December 1998): "Internet Protocol, Version 6 (IPv6) Specification".

[8]

RFC 4960 (September 2007): "Stream Control Transmission Protocol".

[9]

ITU-T Recommendation E.212: "The international identification plan for mobile terminals and mobile users".

[10]

TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)".

[11]

RFC 1035: "Domain Names - Implementation and Specification".

3 Definitions, symbols and abbreviations p. 6

3.1 Definitions p. 6

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

3.2 Abbreviations p. 7

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

RCAF

RAN Congestion Awareness Function

4 General Description p. 7

This document describes the procedures, messages and information elements over the Nq and Nq' interfaces between the MME/SGSN and the RCAF to transfer the IMSI/APN information associated to the eNodeB or E-UTRAN cells or UTRAN Service Area experiencing user plane congestion.

The Nq interface is located between the RCAF and the MME. The Nq' interface is located between the RCAF and the SGSN.

Both the Nq and the Nq' interfaces use the Nq-AP protocol. The Nq-AP protocol described in this document uses a Type, Length and Value (TLV) encoding of messages over an SCTP transport. The SCTP transport is described in clause 6. The Nq-AP messages and the Information Elements are described in clause 8 and 9 respectively.

5 Procedures for Nq-AP p. 7

5.1 Introduction p. 7

The Nq interface is used between the RCAF and MME for the IMSI and APN information retrieval procedures as specified in sub-clause 5.9.3 of TS 23.401.

The Nq' interface is used between the RCAF and SGSN for the APN information retrieval procedure as specified in sub-clause 6.17 of TS 23.060.

5.2 IMSI and APN Information Retrieval Procedure p. 7

5.2.1 General p. 7

The IMSI and APN information retrieval procedure is used between the RCAF and the MME over the Nq interface. The RCAF uses this procedure to retrieve from the MME:

the IMSIs that are currently in ECM-CONNECTED state and having active E-RABs under a given eNodeB or E-UTRAN cell;
for each IMSI the list of APNs currently having active PDN connections.

The RCAF selects the MME(s) serving a user plane congested eNodeB or an E-UTRAN cell through the DNS procedure as specified in subclause 5.4 of TS 29.303.

5.2.2 IMSI and APN Information Retrieval Procedure Initiation p. 7

5.2.2.1 Procedures in the RCAF p. 7

When the RCAF needs to retrieve the IMSI(s) / APN(s) information for a given user plane congested area, the RCAF shall send the NqAP-IMSI-APN-INFORMATION-REQUEST message towards the MME(s).

The RCAF shall include in the NqAP-IMSI-APN-INFORMATION-REQUEST message:

the Global eNodeB ID IE(s) if it requests the IMSI(s) and APN(s) for a given user plane congested area at an eNodeB level;
the ECGI IE(s) if it requests the IMSI(s) and APN(s) for a given user plane congested area at an E-UTRAN cell level.

5.2.2.2 Procedures in the MME p. 8

When the MME receives the NqAP-IMSI-APN-INFORMATION-REQUEST message from the RCAF, the MME shall report in the NqAP-IMSI-APN-INFORMATION-RESPONSE message, for each eNodeB or E-UTRAN cell requested by the RCAF, that has at least one subscriber:

the Macro eNodeB ID or Home eNodeB ID or the E-UTRAN cell ID in the RAN Entity value field of the RAN Entity Identifier IE for which the MME(s) report the IMSI and the APN information.
all the subscribers that are currently in ECM-CONNECTED state and having active E-RABs, except the subscribers involved in an Emergency call, under the given eNodeB or E-UTRAN cell in the Subscriber-Information IE. Multiple instances of the Subscriber-Information IE shall be included if there are multiple subscribers under the given eNodeB or E-UTRAN cell.
for each subscriber, the IMSI in the IMSI IE and APNs currently having active PDN connections in the APN IE. Multiple instances of the APN IE shall be included under a Subscriber-Information IE if the subscriber has active PDN connections towards multiple APNs.

The information reported by the MME for each eNodeB or E-UTRAN cell shall be encoded as an instance of the RAN Associated Information IE.

For a single NqAP-IMSI-APN-INFORMATION-REQUEST message from the RCAF, the MME may send multiple NqAP-IMSI-APN-INFORMATION-RESPONSE messages.

There shall be no NqAP-IMSI-APN-INFORMATION-RESPONSE sent, if the MME does not find any subscriber under any of the requested eNodeB or E-UTRAN cell.

5.3 APN Information Retrieval Procedure p. 8

5.3.1 General p. 8

The APN information retrieval procedure is used between the RCAF and the SGSN over the Nq' interface. The RCAF uses this procedure to retrieve from the SGSN:

the APNs that are currently having PDP contexts activated for each IMSI provided by the RCAF.

The RCAF selects the SGSN(s) serving a user plane congested SAI through the DNS procedure as specified in subclause 5.5 of TS 29.303.

5.3.2 APN Information Retrieval Procedure Initiation p. 8

5.3.2.1 Procedures in the RCAF p. 8

When the RCAF needs to retrieve the APN(s) for the list of IMSI(s) experiencing RAN user plane congestion, the RCAF shall send the NqAP-APN-INFORMATION-REQUEST message towards the SGSN(s).

The RCAF shall include the following information in the NqAP-APN-INFORMATION-REQUEST message

the list of IMSI(s) in the IMSI IE. Multiple instances of the IMSI IE shall be included if there are multiple subscribers for which APN information needs to be queried from the SGSN.

5.3.2.2 Procedures in the SGSN p. 9

When the SGSN receives the NqAP-APN-INFORMATION-REQUEST message from the RCAF, the SGSN shall report in the NqAP-APN-INFORMATION-RESPONSE message, if there is at least one subscriber's information to report:

list of subscribers for which the APN information is provided by the SGSN, in the Subscriber-Information IE. Multiple instances of the Subscriber-Information IE shall be included if there are multiple subscribers for which the SGSN is reporting the APN information. Each instance of the Subscriber-Information IE contains:
- the IMSI of the subscriber encoded in the IMSI IE;
- the APNs currently having active PDP contexts with active RABs, encoded in the APN IE. Multiple instances of the APN IE shall be included under a Subscriber-Information IE if the subscriber has active PDP contexts towards multiple APNs. Emergency call APNs shall be excluded.
- If the subscriber does not have any PDP context with active RABs, then the SGSN shall not include that subscriber's information in the NqAP-APN-INFORMATION-RESPONSE.

In a pooled SGSN scenario each SGSN may have only a subset of IMSIs registered. An SGSN shall report the APN information only for the IMSIs it knows.

For a single NqAP-APN-INFORMATION-REQUEST message from the RCAF, the SGSN may send multiple NqAP- APN-INFORMATION-RESPONSE messages.

There shall be no NqAP-APN-INFORMATION-RESPONSE sent, if the SGSN does not find any requested subscriber attached.

6 Transport p. 9

6.1 General p. 9

This subclause specifies the standards for signalling transport to be used across Nq/Nq' interface. Nq/Nq' interface is a logical interface between the RCAF and the MME/SGSN. All the Nq-AP messages described in the present document require an SCTP association between the RCAF and the MME/SGSN.

6.2 IP layer p. 9

The RCAF shall support IPv6 (see RFC 2460) and IPv4 (see RFC 791).

6.3 Transport layer p. 9

SCTP (see RFC 4960) shall be supported as the transport layer of Nq-AP messages.

Semi-permanent SCTP associations shall be established between the RCAF and MME/SGSN, i.e. the SCTP associations shall remain up under normal circumstances when the RCAF needs to use the Nq-AP procedures towards the MME/SGSN.

The RCAF shall initiate establishment of the SCTP association.

Transport network redundancy can be achieved by SCTP multi-homing between two end-points, of which one or both is assigned with multiple IP addresses. SCTP end-points shall support a multi-homed remote SCTP end-point. For SCTP endpoint redundancy, an SCTP endpoint (in the RCAF or MME/SGSN) may send an INIT, at any time for an already established SCTP association, which the other SCTP endpoint shall handle as defined in RFC 4960.

RCAF and MME/SGSN shall support a configuration with a single SCTP association per RCAF/MME (or RCAF/SGSN) pair. Configurations with multiple SCTP endpoints per RCAF/MME (or RCAF/SGSN) pair may be supported.

Within the SCTP association established between one RCAF and one MME/SGSN, both RCAF and MME/SGSN shall reserve several stream identifiers, based on the INIT message exchange for the sole use of Nq-AP procedures.

The registered port number for Nq-AP is 36424.

The payload protocol identifier to be used for Nq-AP is 0.

7 Error Handling p. 10

7.1 General p. 10

This subclause specifies procedures for the handling of unknown, unforeseen, and erroneous protocol data by the receiving entity (i.e. the MME or the RCAF). These procedures are called "error handling procedures". If a protocol error is detected by the receiving NqAP entity, it should log the event including the erroneous message and may include the error in a statistical counter.

7.2 Message too short p. 10

When the receiving entity receives a message that is too short to contain a complete message type information element, the receiving entity shall ignore that message.

7.3 Unknown or unforeseen message type p. 10

The entity receiving a message with a message type that is not defined or is not implemented, it shall ignore the message.

The entity receiving a message that is not defined to be received by that entity (e.g. the message is sent in the wrong direction) shall treat the message as unknown message and shall ignore the message.

7.4 Missing mandatory information element p. 10

When the entity receiving a request message diagnoses a "missing mandatory information element" error, the receiving entity shall ignore the message and shall return a corresponding response message with the cause IE set to "Mandatory IE missing", together with the type of the missing mandatory IE.

When the entity receiving a response message diagnoses a "missing mandatory information element" error, it shall ignore the message.

7.5 Information elements unknown or unforeseen in the message p. 10

The receiving entity shall ignore all information elements unknown or unforeseen in a message.

7.6 Out of sequence information elements p. 10

The receiving entity shall ignore all information elements that are out of sequence.

7.7 Repeated information elements p. 10

If an information element is repeated in a message in which repetition of the information element is not specified, the receiving entity shall only handle the contents of the information element appearing first and shall ignore all subsequent repetitions of the information element. When repetition of information elements is specified, the receiving entity shall only handle the contents of specified repeated information elements. If a limit on the repetition of information elements is specified and the limit is exceeded, the receiving entity shall handle the contents of information elements appearing first up to the limit of repetitions and shall ignore all subsequent repetitions of the information element.

7.8 Syntactically incorrect mandatory information element. p. 11

On receipt of a message, which contains a syntactically incorrect mandatory information element, the receiver shall ignore the message and shall return a corresponding response message with the cause IE set to "Mandatory IE incorrect", together with the type of the offending mandatory IE.

7.9 Syntactically incorrect optional information elements p. 11

The receiving entity shall treat all optional information elements that are syntactically incorrect in a message as not present in the message.

7.10 Conditional information element errors p. 11

When the entity receiving a request message diagnoses a "missing conditional information element" error, the receiving entity shall ignore the message and shall return a corresponding response message with the cause IE set to "Conditional IE missing", together with the type of the missing conditional IE.

When the entity receiving a request message diagnoses an "unexpected conditional information element" error or when it receives a message containing at least one syntactically incorrect conditional information element which is required to be present in the message, the receiving entity shall ignore the message and shall return a corresponding response message with the cause IE set to "Conditional IE incorrect", together with the type of the offending conditional IE.

When the entity receiving a response message diagnoses a "missing conditional information element" error, "unexpected conditional information element" error or when it receives a response message containing at least one syntactically incorrect conditional information element which is required to be present in the message, it shall ignore the message.

When the entity receives a message containing a syntactically incorrect conditional information element, which is not required to be present in the message, nor required to be absent in the message, then the receiving entity shall ignore that information element.

7.11 Information elements with semantically incorrect contents p. 11

When an information element with semantically incorrect contents is received, the foreseen reactions of the procedural part of the present specification are performed.

If however no such reactions are specified, the receiving entity shall ignore that information element and treat the rest of the message. If the semantically incorrect information element in a request message is a mandatory information element, then the receiving entity shall return a corresponding response message with the cause IE set to "Mandatory IE incorrect", together with the type of the offending mandatory IE. If the semantically incorrect information element in a response message is a mandatory information element, then the receiving entity shall ignore the message.

7.12 NqAP Message of Invalid Length p. 11

If an NqAP entity receives a Request message within an IP/SCTP packet of a length that is inconsistent with the value specified in the Length field of the NqAP message header, then the receiving NqAP entity should log the error and shall send the Response message with the Cause IE value set to "Invalid Length".

If an NqAP entity receives a Response message within an IP/SCTP packet of a length that is inconsistent with the value specified in the Length field of the NqAP message header, then the receiving NqAP entity should log the error and shall silently discard the message.