Content for TS 36.443 Word version: 18.0.0

3.1 Definitions 3.2 Abbreviations 4.1 Procedure Specification Principles 4.2 Forwards and Backwards Compatibility 4.3 Specification Notations 5.1 M2AP procedure modules 5.2 Parallel transactions
...

1 Scope p. 7

The present document specifies the E-UTRAN radio network layer signalling protocol for the M2 interface. The M2 Application Protocol (M2AP) supports the functions of the M2 interface by signalling procedures defined in this document. M2AP is developed in accordance to the general principles stated in TS 36.401 and TS 36.300.

2 References p. 7

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 36.401: "E-UTRAN Architecture Description".

[3]

TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2".

[4]

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

[5]

ITU-T Recommendation X.691 (07/2002): "Information technology - ASN.1 encoding rules - Specification of Packed Encoding Rules (PER) ".

[6]

ITU-T Recommendation X.680 (07/2002): "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation".

[7] Void

[8]

TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description".

[9]

TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)".

[10] Void

[11]

TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRAN); Radio Resource Control (RRC) Protocol Specification".

[12]

TS 36.211: "Evolved Universal Terrestrial Radio Access (E-UTRAN); Physical Channels and Modulation".

[13]

TS 36.445: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); M1 Data Transport".

[14]

TS 29.281: "General Packet Radio Service (GPRS); Tunnelling Protocol User Plane (GTPv1-U)".

[15]

TS 23.203: "Policy and charging control architecture".

3 Definitions, symbols and abbreviations p. 8

3.1 Definitions p. 8

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.

Elementary Procedure:

M2AP consists of Elementary Procedures (Eps). An Elementary Procedure is a unit of interaction between eNBs and the MCE. These Elementary Procedures are defined separately and are intended to be used to build up complete sequences in a flexible manner. If the independence between some Eps is restricted, it is described under the relevant EP description. Unless otherwise stated by the restrictions, the Eps may be invoked independently of each other as standalone procedures, which can be active in parallel. The usage of several M2AP Eps together or together with Eps from other interfaces is specified in stage 2 specifications (e.g. TS 36.300 and TS 23.246).

An EP consists of an initiating message and possibly a response message. Two kinds of Eps are used:

Class 1: Elementary Procedures with response (success and/or failure).
Class 2: Elementary Procedures without response.

For Class 1 Eps, the types of responses can be as follows:

Successful:

A signalling message explicitly indicates that the elementary procedure successfully completed with the receipt of the response.

Unsuccessful:

A signalling message explicitly indicates that the EP failed.
On time supervision expiry (i.e. absence of expected response).

Successful and Unsuccessful:

One signalling message reports both successful and unsuccessful outcome for the different included requests. The response message used is the one defined for successful outcome.

Class 2 Eps are considered always successful.

eNB MBMS M2AP ID:

Unique identity, referencing the MBMS-service-associated logical M2-connection within an eNB.

MCE MBMS M2AP ID:

Unique identity, referencing the MBMS-service-associated logical M2-connection within an MCE.

MBMS E-RAB:

denotes both, the data bearer established between the eNB and the UE(s) to transport MBMS data and the MBMS M1 data bearer.

MBMS-service-associated signalling:

When M2AP messages associated to one MBMS service uses the MBMS-service-associated logical M2-connection for association of the message to the respective MBMS service in eNB and EPC.

MBMS-service-associated logical M2-connection:

The MBMS-service-associated logical M2-connection uses the identities eNB MBMS M2AP ID and MCE MBMS M2AP ID. For a received M2AP message the MCE identifies the associated MBMS E-RAB based on the MCE MBMS M2AP ID IE and the eNB identifies the associated MBMS-RAB based on the eNB MBMS M2AP ID IE.

3.2 Abbreviations p. 9

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.

MCCH

Multicast Control Channel

PMCH

Physical Multicast Channel

SC-PTM

Single Cell Point to Multipoint

4 General p. 9

4.1 Procedure Specification Principles p. 9

The principle for specifying the procedure logic is to specify the functional behaviour of the terminating node exactly and completely. Any rule that specifies the behaviour of the originating node shall be possible to be verified with information that is visible within the system.

The following specification principles have been applied for the procedure text in clause 8:

The procedure text discriminates between:
1. Functionality which "shall" be executed
  The procedure text indicates that the receiving node "shall" perform a certain function Y under a certain condition. If the receiving node supports procedure X but cannot perform functionality Y requested in the REQUEST message of a Class 1 EP, the receiving node shall respond with the message used to report unsuccessful outcome for this procedure, containing an appropriate cause value.
2. Functionality which "shall, if supported" be executed
  The procedure text indicates that the receiving node "shall, if supported," perform a certain function Y under a certain condition. If the receiving node supports procedure X, but does not support functionality Y, the receiving node shall proceed with the execution of the EP, possibly informing the requesting node about the not supported functionality.
Any required inclusion of an optional IE in a response message is explicitly indicated in the procedure text. If the procedure text does not explicitly indicate that an optional IE shall be included in a response message, the optional IE shall not be included. For requirements on including Criticality Diagnostics IE, see clause 10 in TS 36.413.

4.2 Forwards and Backwards Compatibility p. 9

The forwards and backwards compatibility of the protocol is assured by mechanism where all current and future messages, and Ies or groups of related Ies, include ID and criticality fields that are coded in a standard format that will not be changed in the future. These parts can always be decoded regardless of the standard version.

4.3 Specification Notations p. 9

For the purposes of the present document, the following notations apply:

Procedure

When referring to an elementary procedure in the specification the Procedure Name is written with the first letters in each word in upper case characters followed by the word "procedure", e.g. E-RAB procedure.

Message

When referring to a message in the specification the MESSAGE NAME is written with all letters in upper case characters followed by the word "message", e.g. MESSAGE NAME message.

When referring to an information element (IE) in the specification the Information Element Name is written with the first letters in each word in upper case characters and all letters in Italic font followed by the abbreviation "IE", e.g. Information Element IE.

Value of an IE

When referring to the value of an information element (IE) in the specification the "Value" is written as it is specified in subclause 9.2 enclosed by quotation marks, e.g. "Value".

5 M2AP Services p. 11

The present clause describes the services an eNB offers to its associated MCE.

5.1 M2AP procedure modules p. 11

The M2 interface M2AP procedures may be sub-divided as follows:

M2AP MBMS session control procedures;
M2AP global procedures;

The M2AP session control procedures are related to MBMS services.

The Global Procedures module contains procedures that are not related to a specific MBMS service.

5.2 Parallel transactions p. 11

Unless explicitly indicated in the procedure specification, at any instance in time one protocol peer shall have a maximum of one ongoing M2AP procedure related to a certain MBMS service.

6 Services Expected from Signalling Transport p. 12

The signalling connection shall provide in sequence delivery of M2AP messages. M2AP shall be notified if the signalling connection breaks.

7 Functions of M2AP p. 13

The M2AP protocol provides the following functions:

MBMS Session Handling. This function supports start, stop and modify of an MBMS session, as well as configuration and modification of basic radio transmission parameters related to that service.
MBMS Scheduling Information. This function provides MCCH related information, and optional session suspension decision to the eNB.
Reporting of General Error Situations. This function allows reporting of general error situations, for which function specific error messages have not been defined.
Resetting the M2. This function is used to reset the M2 interface.
Setting up the M2. This function is used to exchange necessary data for the eNB for setup the M2 interface, provides basic configuration of radio parameters for transmission of MBMS data and implicitly perform an M2 Reset.
eNB and MCE Configuration Update functions are to update configuration data exchanged during setup of M2.
MBMS Service Counting. This function enables the MCE to perform counting and to receive the counting results for the MBMS service(s) per MBSFN area.
MBMS Overload Notification. This function enables the eNB to notify the MCE about the MBMS overload status.

The mapping between the above functions and M2 Eps is shown in the table below.

Table 1: Mapping between M2AP functions and M2AP Eps

Function	Elementary Procedure(s)
MBMS Session Handling	a) MBMS Session Start b) MBMS Session Stop c) MBMS Session Update
MBMS Scheduling Information	MBMS Scheduling Information
Reporting of General Error Situations	Error Indication
Resetting the M2	Reset
Setting up the M2	M2 Setup
Configuration Update	a) eNB Configuration Update b) MCE Configuration Update
MBMS Service Counting	a) MBMS Service Counting b) MBMS Service Counting Results Report
MBMS Overload Notification	MBMS Overload Notification