ETSI TS 129 202 V16.0.0 (2020-07)

Universal Mobile Telecommunications System (UMTS); Signalling System No. 7 (SS7) signalling transport in core network; Stage 3 (3GPP TS 29.202 version 16.0.0 Release 16)

RTS/TSGC-0429202vg00

General Information

• Status: Not Published
• Technical Committee: 3GPP CT 4 - MAP/CAMEL/GTP/BCH/SS/TrFO/IMS/GUP/WLAN (formely CN4)
• Current Stage: 12 - Completion
• Completion Date: 23-Jul-2020

Standards Content (Sample)

ETSI TS 129 202 V16.0.0 (2020-07)






TECHNICAL SPECIFICATION
Universal Mobile Telecommunications System (UMTS);
Signalling System No. 7 (SS7)
signalling transport in core network;
Stage 3
(3GPP TS 29.202 version 16.0.0 Release 16)

---------------------- Page: 1 ----------------------
3GPP TS 29.202 version 16.0.0 Release 16 1 ETSI TS 129 202 V16.0.0 (2020-07)



Reference
RTS/TSGC-0429202vg00
Keywords
UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2020.
All rights reserved.

DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3GPP TS 29.202 version 16.0.0 Release 16 2 ETSI TS 129 202 V16.0.0 (2020-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI

---------------------- Page: 3 ----------------------
3GPP TS 29.202 version 16.0.0 Release 16 3 ETSI TS 129 202 V16.0.0 (2020-07)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 6
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 Introduction . 6
5 Protocol architectures . 7
5.1 Protocol architecture in the case of MTP-based SS7 signalling transport network . 7
5.2 Protocol architecture in the case of IP-based SS7 signalling transport network . 7
5.2.1 M3UA . 7
5.2.2 MTP3-M2PA . 7
5.3 Protocol architecture in the case of ATM-based SS7 signalling transport network . 8
Annex A (Normative):  The use of M3UA in 3GPP networks . 9
A.1 Scope . 9
A.2 Introduction . 9
A.3 Protocol conformance to RFC 4666 . 10
Annex B (Informative):  The use of M2PA in 3GPP networks . 18
B.1 Scope . 18
B.2 Introduction . 18
B.3 Protocol conformance to RFC 4165 . 18
Annex C (informative): Change history . 23
History . 24

ETSI

---------------------- Page: 4 ----------------------
3GPP TS 29.202 version 16.0.0 Release 16 4 ETSI TS 129 202 V16.0.0 (2020-07)
Foreword
rd
This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.

ETSI

---------------------- Page: 5 ----------------------
3GPP TS 29.202 version 16.0.0 Release 16 5 ETSI TS 129 202 V16.0.0 (2020-07)
1 Scope
The present document defines the possible protocol architectures for transport of SS7 signalling protocols in Core
Network.
2 References
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.
2.1 Normative references
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] ITU-T Recommendation Q.701: "Functional description of the message transfer part (MTP) of
signalling system No. 7".
[3] ITU-T Recommendation Q.702: "Signalling data link".
[4] ITU-T Recommendation Q.703: "Signalling link".
[5] ITU-T Recommendation Q.704: "Signalling network functions and messages".
[6] ITU-T Recommendation Q.705: "Signalling network structure".
[7] ITU-T Recommendation Q.706: "Message transfer part signalling performance".
[8] RFC 2960: "Stream Control Transmission Protocol".
[9] ITU-T Recommendation G.804: "ATM cell mapping into Plesiochronous Digital Hierarchy
(PDH)".
[10] ITU-T Recommendation I.112: "Vocabulary of terms for ISDNs".
[11] ITU-T Recommendation I.361: "B-ISDN ATM layer specification".
[12] ITU-T Recommendation I.363.5: "B-ISDN ATM Adaptation Layer specification: Type 5 AAL".
[13] ITU-T Recommendation Q.2110: "B-ISDN ATM adaptation layer - Service specific connection
oriented protocol (SSCOP)".
[14] ITU-T Recommendation Q.2140: "B-ISDN ATM adaptation layer - Service specific coordination
function for signalling at the network node interface (SSCF at NNI)".
[15] ITU-T Recommendation Q.2210: "Message transfer part level 3 functions and messages using the
services of ITU-T Recommendation Q.2140".
[17] RFC 3309: "SCTP Checksum Change".
[18] RFC 4666:Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer
(M3UA)".
ETSI

---------------------- Page: 6 ----------------------
3GPP TS 29.202 version 16.0.0 Release 16 6 ETSI TS 129 202 V16.0.0 (2020-07)
[19] RFC 4165: Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) -User Peer-to-Peer
Adaptation Layer (M2PA)".
2.2 Informative references
[16] RFC 2719: "Framework Architecture for Signalling Transport".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1] 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 [1].
(no further terms defined)
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] 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 [1].
AAL5 ATM Adaptation Layer type 5
ATM Asynchronous Transfer Mode
IP Internet Protocol
MTP Message Transfer Part
MTP1 Message Transfer Part layer 1
MTP2 Message Transfer Part layer 2
MTP3 Message Transfer Part layer 3
M2PA Message Transfer Part 2 -User Peer-to-Peer Adaptation Layer
M3UA MTP3-User Adaptation
PDH Plesiochronous Digital Hierarchy
SSCF Service Specific Coordination Function
SSCOP Service Specific Connection Oriented Protocol
SCCP Signalling Connection Control Part
SCTP Stream Control Transmission Protocol
SDH Synchronous Digital Hierarchy
TCAP Transaction Capabilities Application Part
4 Introduction
The Core Network enables the transport of SS7 signalling protocols between two entities by means of different
underlying networks (e.g. MTP-based, IP-based or ATM-based).
The transport of SS7 signalling protocol messages of any protocol layer that is identified by the MTP level 3 layer, in
SS7 terms, as a user part (MTP3-user) shall be accomplished in accordance with the protocol architecture defined in the
following sub-clauses. The list of these protocol layers includes, but is not limited to, Signalling Connection Control
Part (SCCP).
The transport of protocols which can be identified as SCCP-users, like for example TCAP, and in turn the transport of
TCAP-users like MAP and CAP, shall also be accomplished in accordance with the defined protocol architectures,
since their protocol messages are transferred as SCCP payload.
ETSI

---------------------- Page: 7 ----------------------
3GPP TS 29.202 version 16.0.0 Release 16 7 ETSI TS 129 202 V16.0.0 (2020-07)
5 Protocol architectures
5.1 Protocol architecture in the case of MTP-based SS7
signalling transport network
The transport of an MTP3-user signalling messages shall be accomplished in accordance with the relevant ITU-T
Recommendations [2], [3], [4], [5], [6], [7].
The protocol architecture applicable in the case of MTP-based SS7 signalling transport network is shown in Figure
5.1/1

MTP3-User
MTP3
MTP2
MTP1
Figure 5.1/1: Protocol architecture in the case of MTP-based SS7 signalling transport network
5.2 Protocol architecture in the case of IP-based SS7 signalling
transport network
5.2.1 M3UA
The transport of an MTP3-user signalling messages shall be accomplished in accordance with the architecture defined
by the "Framework Architecture for Signalling Transport" [16], by "Stream Control Transmission Protocol"[8] and by
the IETF document available in Annex A. An implementation of SCTP to this document shall use the checksum method
specified in RFC 3309 [17] instead of the method specified in RFC 2960 [8].
The M3UA protocol architecture applicable in the case of IP-based SS7 signalling transport network is shown in Figure
5.2/1

MTP3-User
M3UA
SCTP
IP
Figure 5.2/1: M3UA architecture in the case of IP-based SS7 signalling transport network
The definition of the use of M3UA in 3GPP core network is provided in Annex A to this specification.
5.2.2 MTP3-M2PA
An MTP3 signalling message can also be transported by M2PA, which shall be accomplished in accordance with IETF
RFC 4165[19].
The M2PA protocol architecture applicable in the case of IP-based SS7 signalling transport network is shown in Figure
5.2/2

MTP3
M2PA
SCTP
IP
ETSI

---------------------- Page: 8 ----------------------
3GPP TS 29.202 version 16.0.0 Release 16 8 ETSI TS 129 202 V16.0.0 (2020-07)
Figure 5.2/2: M2PA architecture in the case of IP-based SS7 signalling transport network
The definition of the use of M2PA in 3GPP core network is provided in Annex B to this specification.
5.3 Protocol architecture in the case of ATM-based SS7
signalling transport network
The transport of an MTP3-user signalling messages shall be accomplished in accordance with the relevant ITU-T
Recommendations [9], [10], [11], [12], [13], [14], [15]
The protocol architectures applicable in the case of ATM-based SS7 signalling transport network are shown in Figure
5.3/1.
ATM over SDH
MTP3-User
MTP3 B
SSCF
SSCOP
AAL5
ATM

ATM over PDH
MTP3-User
MTP3 B
SSCF
SSCOP
AAL5
G.804

Figure 5.3/1: Protocol architectures in the case of
ATM-based SS7 signalling transport network
ETSI

---------------------- Page: 9 ----------------------
3GPP TS 29.202 version 16.0.0 Release 16 9 ETSI TS 129 202 V16.0.0 (2020-07)
Annex A (Normative):
The use of M3UA in 3GPP networks
A.1 Scope
This annex defines the application of M3UA in 3GPP core networks. The purpose of the Annex is to ensure the
interoperability of different implementations of M3UAs used by different operators and vendors. This is achieved by:
- Clarifying certain concepts which are used in RFC 4666;
- Defining those features in RFC 4666 for which support is mandatory;
- Defining those features in the RFC 4666 for which support is optional;
- Defining those features in RFC 4666 which shall not be used;
The specification is intended for interfaces between network domains, however, it can also be used inside one network
domain, and constitutes a minimum set of M3UA requirements to be supported between IP nodes and between IP nodes
and SGW nodes in a 3GPP network.
A.2 Introduction
M3UA may be used on a number of interfaces in a 3GPP core network. The annex is intended for the interface called A
and C in figure 1. A is the Interface between two IP nodes that are equipped with SCTP, M3UA and a M3UA user.
Examples of M3UA user are BICC, H.248, SCCP and ISUP. The interface can be used inside one network domain but
also to interconnect network domains. Interface B can be used between network domains and inside network domains.
Interface B is not in the scope for this annex, however, use of Q.701-Q.705 or Q.2210 on interface B is already
standardised; in addition, M2PA is also endorsed for interface B in accordance with Annex B. Interface C is the
interface between a node including SCTP, M3UA and a M3UA user and a node including SCTP, M3UA and
M3UAsignalling gateway functions. This interface is inside one network domain.
Interfaces A and C are similar. The main difference is that interface C shall also allow for interworking with the SS 7
network and therefore provides functions for the interworking.
The signalling gateways in this picture are pure MTP3/3B-M3UA signaling gateways. They do not include any M3UA
users. Still there could be a node including an M3UA user (e.g. SCCP functions) and a M3UA signalling gateway
functions. In that case, the node will support all the interfaces A, B and C.
ETSI

---------------------- Page: 10 ----------------------
3GPP TS 29.202 version 16.0.0 Release 16 10 ETSI TS 129 202 V16.0.0 (2020-07)

Figure 1: Use of M3UA in 3GPP core network
A.3 Protocol conformance to RFC 4666
A minimum implementation shall support sections marked mandatory in the table below. It shall be possible to
configure all implementations to interoperate (no error messages returned) with the minimum set.
The table below makes comment to the sections in RFC 4666. In the comment column the following terms are used:
- Mandatory: When support of text in a section is marked mandatory:
- On an information element, message or message class, it means that a receiver shall understand the
information element, message or message class and carry out the requested action.
- For a procedure, it means that the procedure is mandatory to be carried out by the involved network elements.
- Optional: When support of the text in a section is marked optional the feature involved is only guaranteed to
work between peer entities which are subject to a bilateral agreement between operators of those entities. If one
end uses an optional message or information element and the other does not support it, then either a silent
discard takes place of an information element as a part of the message or the message is discarded and an error
message is returned. This is described as part of the handling of the optionality in the table.
- Excluded: This means that the feature shall not be used in a 3GPP environment
Descriptive text means that the section does not include any requirements for this specification.
Note: The word "heading" means that the section consists only of subordinate sections.
The comments column also defines the behaviour of a minimum implementation if it does not support a message or an
information element in a mandatory message.
ETSI

---------------------- Page: 11 ----------------------
3GPP TS 29.202 version 16.0.0 Release 16 11 ETSI TS 129 202 V16.0.0 (2020-07)
Section number in M3UA RFC Comments
Abstract Descriptive text
1.Introduction Descriptive text
1.1 Scope Descriptive text
1.2 Terminology Descriptive text.
1.3 M3UA overview Descriptive text.
1.4 Functional area Descriptive text.
1.5 Sample Configurations Descriptive text

1.6 Definition of M3UA Descriptive text
Boundaries
2 Conventions Descriptive text
3. M3UA Protocol Elements Mandatory
3.1 Common message header Mandatory
3.1.1 M3UA Protocol Version: The version number field shall be set to 1
3.1.2 Message classes and types The values are classified as follow
0-4 Mandatory
5-8 Excluded
9 Optional (Routing Key Management (RKM) Messages)
10 to 255 Excluded

3.1.2 (Management (MGMT) The values are classified as follow
message) 0 Mandatory
1 Optional (Notify). When received and not supported the message maybe
silently discarded.
2-255 Excluded
3.1.2 (Transfer messages) The values are classified as follow
0 Excluded
1 Mandatory
2 to 255 Excluded

3.1.2 (Signalling network The values are classified as follow
management (SSNM) messages) 0 Excluded
1-6 Mandatory

7- 255 Excluded.

3.1.2 (ASP State Maintenance The values are classified as follow
(ASPSM) Messages) 0 Excluded
1-6 Mandatory
7-255 Excluded

3.1.2 (ASP Traffic Maintenance The values are classified as follow
(ASPTM) Messages) 0 Excluded
1-4 Mandatory
5 to 255 Excluded

3.1.2 (Routing key management Optional
(RKM)) messages If any of these messages is received and not supported an error message with
the error code 0x04 (Unsupported message type) shall be sent
3.1.3 Reserved Mandatory
3.1.4 Message length Mandatory
ETSI

---------------------- Page: 12 ----------------------
3GPP TS 29.202 version 16.0.0 Release 16 12 ETSI TS 129 202 V16.0.0 (2020-07)
Section number in M3UA RFC Comments
3.2 Variable Length Parameter The values are classified as follows
Format Common Parameters:
0x0000-- 0x0003, 0x0005, 0x0008, 0x000a, 0x000e, 0x000f, 0x0010 0x0014—
0x01ff Excluded

0x0007, 0x0009, 0x000c and 0x0012 Mandatory

0x0004 optional (INFO String) if received and not supported the message is
processed but the optional information element is silently discarded,

0x0006 optional (Routing Context if received and not supported the message is
processed but the optional information element is silently discarded,
0x000b optional (Traffic Mode Type) if received and not supported the message
is processed but the optional information element is silently discarded,

0x0011 (ASP Identifier) if received and not supported the message is processed
but the optional information element is silently discarded,

0x0012 Affected point code is mandatory. The support of value 0 in the mask
field is mandatory. All other values is outside the scope of this annex.

0x0013 (Correlation ID) if received and not supported the message is processed
but the optional information element is silently discarded,

3.2 Variable Length Parameter
The values are classified as follows
Format M3UA Specific
Parameters 0x0201, 0x0202, 0x0203, 0x0211, 0x020d and 0x0214 to 0xffff Excluded

0x0204--0x0205, 0x0210 Mandatory

0x0200 optional (Network Appearance) if received and not supported the
message is processed but the optional information element is silently discarded,

0x0206 Optinal (Concerned Destination). If received and not supported the
message is processed but the optional information element is silently discarded.

0x0207 (Routing Key), 0x0208 (Registration Result), 0x0209 (Deregistration
Result) 0x020a (Local Routing Key Identifier), 0x020b (Destination Point Code),
0x020c (Service Indicators) 0x020d (Subsystem Numbers), 0x020e (Originating
Point Code List), 0x020f (Circuit Range), 0x0212 (Registration Status), 0x0213
(Deregistration Status) are parameters in optional message, and therefore no
action is specified.

3.3 Transfer messages These messages are mandatory at the interfaces A and C.

3.3.1 Payload Data Message The parameters Network Appearance, Routing Context, Correlation ID are
(DATA) optional
The parameter Protocol data is mandatory.
3.4 SS7 signalling network Heading
management messages
3.4.1 Destination Unavailable The message is mandatory at the interface C.
(DUNA) The parameters Network Appearance, Routing Context, and INFO String are
optional
The parameter Affected Point Code is mandatory

3.4.2 Destination Available The message is mandatory at the interface C
(DAVA) The parameters Network Appearance, Routing Context, and INFO String are
optional.
The parameter Affected Point Code is mandatory

3.4.3 Destination State Audit The message is mandatory at the interface C
(DAUD) The parameters Network Appearance, Routing Context, and INFO String are
optional.
The parameter Affected Point Code is mandatory

ETSI

---------------------- Page: 13 ----------------------
3GPP TS 29.202 version 16.0.0 Release 16 13 ETSI TS 129 202 V16.0.0 (2020-07)
Section number in M3UA RFC Comments
3.4.4 Signalling Congestion (SCON) The message is mandatory at the interface C
The parameters Network Appearance, Routing Context, Congestion Indications
and INFO String are optional
The parameter Affected point code is mandatory.

3.4.5 Destination User Part The message is mandatory at the interfaces A and C.
The parameters Network Appearance, Routing Context, and INFO String are
Unavailable (DUPU)
optional.

The parameters Affected point code and User/Cause are mandatory

3.4.6 Destination Restricted This message is mandatory.
(DRST) message
3.5 ASP State Maintenance These messages are mandatory at the interfaces A and C.
(ASPSM) Messages

3.5.1 ASP Up message The ASP Identifier and Info String parameters are optional
3.5.2 ASP Up Acknowledgement The Info String parameter is optional.
Message
3.5.3 ASP Down message The Info String parameter is optional.
3.5.4 ASP Down The Info String parameter is optional.
Acknowledgement message

3.5.5 Heartbeat message The message is mandatory.
3.5.6 Heartbeat The message is mandatory
Acknowledgement message
3.6 Routing Key Management These messages are optional at the interfaces A and C.
messages

3.7 ASP Traffic Maintenance These messages are mandatory at the interfaces A and C.

(ASPTM) Messages
3.7.1 ASP Active message The parameters Traffic Mode Type, Routing Context and INFO String are
optional.
3.7.2 ASP Active The Traffic Mode Type, Routing Context and INFO String are optional.
Acknowledgement message
3.7.3 ASP inactive message The parameters Routing Context and INFO String are optional.
3.7.4 ASP Inactive The parameters Routing Context INFO String are optional.
Acknowledgement
3.8 Management (MGMT) Heading
Messages
3.8.1 Error message The message is mandatory at the interfaces A and C
3.8.2 Notify message The message is optional at the interfaces A and C

4 Procedure The application of a particular procedure at a certain interface is detailed in the
following sections

4.1 Procedures to Support the Heading
M3UA-User

4.1.1 Receipt of Primitives from The procedure is mandatory at the interfaces A and C.
the M3UA-User

4.1.2 Receipt of Primitives from This section is outside the scope of this annex.
the Layer Management

4.2 Procedures to Support the The procedures are mandatory at the interfaces A and C
Management of SCTP
Associations
4.2.1 Receipt of M3UA Peer The two first paragraphs are outside the scope of this annex.
Management Messages Last paragraph is mandatory.
4.3 AS and ASP State The procedure is mandatory at the interfaces A and C.
Maintenance
4.3.1 ASP States Mandatory

4.3.2 AS States Mandatory

ETSI

---------------------- Page: 14 ------------
...