|
TECHNICAL SPECIFICATION
Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS);
LTE;
Telecommunication management;
Configuration Management (CM);
Name convention for Managed Objects
(3GPP TS 32.300 version 16.0.0 Release 16)
---------------------- Page: 1 ----------------------
3GPP TS 32.300 version 16.0.0 Release 16 1 ETSI TS 132 300 V16.0.0 (2020-08)
Reference
RTS/TSGS-0532300vg00
Keywords
GSM,LTE,UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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:
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
If you find errors in the present document, please send your comment to one of the following services:
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 32.300 version 16.0.0 Release 16 2 ETSI TS 132 300 V16.0.0 (2020-08)
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 .
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 32.300 version 16.0.0 Release 16 3 ETSI TS 132 300 V16.0.0 (2020-08)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 5
Introduction . 5
1 Scope . 7
2 References . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.1.1 Void . 8
3.1.2 Void . 8
3.1.3 Managed Object and Network Resource . 8
3.1.4 Name . 8
3.1.5 Name space . 8
3.1.6 Global Root and Local Root . 9
3.1.7 Distinguished Name and Relative Distinguished Name . 9
3.2 Abbreviations . 9
4 System overview . 10
4.1 System context . 10
5 Name Convention for Managed Objects . 10
6 Representations of Distinguished Name (DN) . 11
7 String Representation of DN . 12
7.A Overview . 12
7.B Allowed character sets . 12
7.1 Converting DN from ASN.1 to String . 12
7.1.1 Rule for one-string DN . 12
7.1.1.1 Converting RDNSequence . 12
7.1.1.2 Converting RelativeDistinguishedName . 13
7.1.1.3 Converting AttributeTypeAndValue . 13
7.1.2 Rule for multi-string DN . 13
7.1.2.1 Converting RDNSequence . 13
7.1.2.2 Converting RelativeDistinguishedName . 13
7.1.2.3 Converting AttributeTypeAndValue . 13
7.2 Character syntax . 14
7.3 EBNF of DN String Representation . 14
7.4 Maximum size of DN string . 17
8 Examples of DN in string representation . 18
9 Usage Scenario . 19
9.1 DN prefix usage . 19
Annex A (normative): Mapping of RDN AttributeType to Strings . 20
Annex B (normative): Rule for MO Designers regarding AttributeType interpretation . 21
Annex C (informative): DN Prefix and Local Distinguished Name (LDN) . 23
Annex D (informative): Interpreting EBNF [13] . 25
Annex E (informative): IOC/MOC name recommendation . 27
ETSI
---------------------- Page: 4 ----------------------
3GPP TS 32.300 version 16.0.0 Release 16 4 ETSI TS 132 300 V16.0.0 (2020-08)
Annex F (informative): Change history . 28
History . 29
ETSI
---------------------- Page: 5 ----------------------
3GPP TS 32.300 version 16.0.0 Release 16 5 ETSI TS 132 300 V16.0.0 (2020-08)
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.
Introduction
Configuration Management (CM), in general, provides the operator with the ability to assure correct and effective
operation of the 3G network as it evolves. CM actions have the objective to control and monitor the actual configuration
on the Network Elements (NEs) and Network Resources (NRs), and they may be initiated by the operator or by
functions in the Operations Systems (OSs) or NEs.
CM actions may be requested as part of an implementation programme (e.g. additions and deletions), as part of an
optimisation programme (e.g. modifications), and to maintain the overall Quality of Service (QoS). The CM actions are
initiated either as single actions on single NEs of the 3G network, or as part of a complex procedure involving actions
on many resources/objects in one or several NEs.
Background
Traditionally, multiple name conventions have been used by different vendors' NEs, or even within the same vendor, to
name network resources. The following problems have thus arisen:
- Different classes of NE have used different name conventions. Network Management applications, when
interfacing with these NEs, have been required to understand multiple name conventions to manage the NEs.
- Network management applications (e.g. Fault Management application), when interfacing with other
applications (e.g. Configuration Management application, trouble ticket system) have been required to
understand multiple name conventions.
- When a customer purchased multiple classes of NEs from the same or different vendors, the customer was
confronted with multiple name conventions.
- Without a name convention, it is difficult to integrate IRP conformant vendors' resource name space (see
subclause 3.1.5 for definition of name space) into the customer's Enterprise name space.
Benefits
The benefits of using the subject name convention to name 3G network resources for network management purposes are
as follows:
- A resource name is guaranteed to be unambiguous in that it refers to, at most, one network resource.
Unambiguous naming of managed network resources is necessary for interoperability among managing
applications and systems.
ETSI
---------------------- Page: 6 ----------------------
3GPP TS 32.300 version 16.0.0 Release 16 6 ETSI TS 132 300 V16.0.0 (2020-08)
- The resource name syntax is specified such that management applications can be designed with assurance that its
name-parsing algorithm needs not be modified in the future. We can derive this benefit only if the subject name
convention is widely accepted.
The root and upper portions of the name hierarchy are based on name infrastructure of Domain Name System (DNS)
(see IETF RFC 2247 [5]). The subject name convention can naturally fit in DNS and can integrate well with other
hierarchical naming systems, such as ITU-T Recommendation X.500 [2].
ETSI
---------------------- Page: 7 ----------------------
3GPP TS 32.300 version 16.0.0 Release 16 7 ETSI TS 132 300 V16.0.0 (2020-08)
1 Scope
A more detailed background and introduction of the IRP concept is given in 3GPP TS 32.150 [16].
To perform network management tasks, co-operating applications require identical interpretation of names assigned to
network resources under management. Such names are required to be unambiguous as well. The present document
recommends one name convention for network resources under management in the IRP context.
To facilitate integration of network management information obtained via multiple IRPs based on different
IRP Solution Set technologies, identical network resource name semantics shall be conveyed in all IRPs. The present
document specifies one such name convention.
The present document also specifies an IOC/MOC name recommendation (see annex E) in order to avoid potential
problems with valid characters in some programming languages.
In this document, the name convention and name recommendation (see annex E) are specified for MO instances whose
MO class stereotype is IOC. These specifications are also for MO instances whose MO class stereotype is Support IOC
(SupportIOC).
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.
[1] Void.
[2] ITU-T Recommendation X.500 (1993): "Information technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and services".
[3] T. Howes, ISBN 1-57870-070-1: "Understanding and Deploying LDAP Directory Services".
[4] IETF RFC 1737 (1994): "Functional Requirements for Uniform Resource Names".
[5] IETF RFC 2247 (1998): "Using Domains in LDAP/X.500 Distinguished Names".
[6] IETF RFC 1035 (1987): "Domain names - implementation and specification".
[7] IETF RFC 2253 (1997): "Lightweight Directory Access Protocol (v3): UTF-8 String
Representation of Distinguished Names".
[8] 3GPP TS 32.111-2: "Telecommunication management; Fault Management; Part 2: Alarm
Integration Reference Point (IRP): Information Service (IS)".
[9] 3GPP TS 32.622: " Telecommunication management; Configuration Management (CM); Generic
network resources Integration Reference Point (IRP): Network Resource Model (NRM)".
[10] Void.
[11] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements".
[12] 3GPP TS 32.102: "Telecommunication management; Architecture".
ETSI
---------------------- Page: 8 ----------------------
3GPP TS 32.300 version 16.0.0 Release 16 8 ETSI TS 132 300 V16.0.0 (2020-08)
[13] ISO/IEC 14977: "Information technology – Syntactic metalanguage – Extended BNF".
[14] ISO/IEC 646: "Information technology – ISO 7-bit coded character set for information
interchange".
[15] ISO/IEC 10646: "Information technology – Universal multiple-octet Coded Character Set (UCS)".
[16] 3GPP TS 32.150: "Integration Reference Point (IRP) Concept and definitions".
[17] 3GPP2 S.S0028-E "OAM&P for cdma2000 (Overview, 3GPP R7 Delta Specification, 3GPP2
Network Resource Model IRP)" .
[18] MEF Technical Specification MEF 7.1, Phase 2 EMS-NMS Information Model, October 2009.
[19] ATM Forum, Technical Committee, Network Management, M4 Network View CMIP MIB
Specification. .
[20] 3GPP TS 32.103: "Integration Reference Point (IRP) overview and usage guide".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TS 32.101 [11] ,
3GPP TS 32.102 [12] and 3GPP TS 32.150 [16] apply. This subclause defines terms essential for understanding of
name convention in the IRP context.
3.1.1 Void
3.1.2 Void
3.1.3 Managed Object and Network Resource
In the context of the present document, a Managed Object (MO) is a software object that encapsulates the manageable
characteristics and behaviour of a particular network resource. Examples of network resource are switch, scanner for
monitoring performance data, cell, site, transmission links, satellite, operator profile, etc. In the present document, MO
sometimes is referred to as MO instance.
3.1.4 Name
In the context of the present document, a name is restricted to the identification of a MO, that is, a software object
representing a real network resource.
3.1.5 Name space
A name space is a collection of names. This name convention uses a hierarchical containment structure, including its
simplest form - the one-level, flat name space. This name convention does not support an arbitrarily connected name
space, or graph structure, in which a named object can be both child and parent of another named object.
Figure 1 shows some examples of supported and unsupported name spaces (this figure is from T. Howes,
ISBN 1-57870-070-1 [3] and it provides useful information on name space design).
ETSI
---------------------- Page: 9 ----------------------
3GPP TS 32.300 version 16.0.0 Release 16 9 ETSI TS 132 300 V16.0.0 (2020-08)
Supported
Unsupported
Figure 1: Examples of supported and unsupported name spaces
3.1.6 Global Root and Local Root
Names in name space are organised in hierarchy. An MO instance that contains another one is referred to as the superior
(parent), whereas the contained MO instance is referred to as the subordinate (child).
In modern network management, it is expected that the Enterprise name space be partitioned for implementations in
multiple managed system (see annex C for reasons of name space partitioning). The parent of all MO instances in a
single managed system is called the Local Root. The ultimate parent of all MO instances of all managed systems is
called the Global Root.
3.1.7 Distinguished Name and Relative Distinguished Name
A Distinguished Name (DN) is used to uniquely identify a MO within a name space. A DN is built from a series of
"name components", referred to as Relative Distinguished Names (RDNs). ITU-T Recommendation X.500 [2] defines
the concepts of DN and RDN in detail, using ASN.1, in the following way:
DistinguishedName ::= RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET SIZE (1.MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {type AttributeType, value AttributeValue}
The present document references this ASN.1 structure but it only uses single-valued (not multi-valued) RDN.
From a DN of a MO, one can derive the DN of its containing MO, if any. This containment relation is the only relation
carried by the DN. No other relation can be carried or implied by the DN.
See annex B for a rule for MO designers to avoid ambiguity concerning the AttributeType of a DN string.
See annex C for discussion of DN prefix.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASN.1 Abstract Syntax Notation One
BER Basic Encoding Rules
CM Configuration Management
DC Domain Component
DN Distinguished Name
DNS Domain Name Service
EBNF Extended Backus-Naur Form
FM Fault Management
IETF Internet Engineering Task Force
IOC Information Object Class
IRP Integration Reference Point
ETSI
---------------------- Page: 10 ----------------------
3GPP TS 32.300 version 16.0.0 Release 16 10 ETSI TS 132 300 V16.0.0 (2020-08)
IS Information Service
LDN Local Distinguished Name
MO Managed Object
MOC Managed Object Class
MOI Managed Object Instance
NE Network Element
NR Network Resource
NRM Network Resource Model
PM Performance Management
QoS Quality of Service
RDN Relative Distinguished Name
SS Solution Set
TMN Telecommunications Management Network
4 System overview
4.1 System context
Situations under which MO (representing network resource) names are used are as follows:
a) MO names cross various Integration Reference Points (IRPs).
EXAMPLE 1: In the context of Alarm IRP 3GPP TS 32.111-2 [8], IRPAgent notifies IRPManager of the alarm
condition of a network resource. The DN of the MO, representing alarmed network resource,
encoded as specified in the present document, is carried in the Managed Object Instance
parameter of the notification.
EXAMPLE 2: In the context of Generic Network Resources IRP: NRM, 3GPP TS 32.622 [9], IRPAgent notifies
IRPManager of the creation of new object. The DN of the newly created object, encoded as
specified in the present document, is carried in the notification.
EXAMPLE 3: In the context of Generic Network Resources IRP: NRM, 3GPP TS 32.622 [9], IRPManager
requests IRPAgent to search for a particular object by specifying the start point of the search. The
DN of the base object, upon which the search begins downward hierarchically, is carried in the
request.
b) Co-operating management applications need to exchange information that includes MO (representing network
resource) names.
EXAMPLE 4: A Fault Management (FM) application may request a trouble ticket system to open a new trouble
ticket reporting the alarmed condition of a network resource by specifying, among other things, the
MO name representing the alarmed network resource. The DN of the MO, encoded as specified in
the present document, is included in the request.
EXAMPLE 5: A Performance Management (PM) system that produces reports on performance of network
resources. The DNs of the MOs, representing the reported network resources, encoded as specified
in the present document, are printed on the report.
5 Name Convention for Managed Objects
Network resources shall be named using the naming conventions in ITU-T Recommendation X.500 [2] with one
restriction listed below. Central to the X.500 naming convention is the concept of the Distinguished Name (DN) (see
subclause 3.1.7).
The restriction is that this IRP name convention does not support multi-value RDN. Only single-value RDN is
supported.
ETSI
---------------------- Page: 11 ----------------------
3GPP TS 32.300 version 16.0.0 Release 16 11 ETSI TS 132 300 V16.0.0 (2020-08)
6 Representations of Distinguished Name (DN)
A DN can be encoded and represented in many ways. The present document specifies one representation. Future work
on IRP specifications may require the definition(s) of other representation(s).
The DN is encoded using the string representation.
The DN string representation encoding scheme:
- shall be used for DNs exchanged through all IRP SS technologies,
- is in itself IRP SS technology neutral, and
- is subject to IRP SS technology specific handling, such as escaping, if required by such a technology.
ETSI
---------------------- Page: 12 ----------------------
3GPP TS 32.300 version 16.0.0 Release 16 12 ETSI TS 132 300 V16.0.0 (2020-08)
7 String Representation of DN
7.A Overview
This clause specifies the string representation of DN. This work is based on IETF RFC 2253 [7]. A DN string
representation, using the string-encoding scheme specified in the present document, is also a valid DN string according
to IETF RFC 2253 [7].
The string-encoding scheme specified in the present document imposes further restrictions as compared to IETF
RFC 2253 [7]. The most important restrictions are:
- Multi-valued RDN is not supported in the subject name convention.
- The asterisk character (see clause 7.2 bullet 3) is used to denote wildcard. The asterisk character shall not be
used in DN .
7.B Allowed character sets
Subject to further restrictions described in the present document, the allowed characters for the string representation of
DN are:
- Characters of ISO/IEC 646 [14] International Reference Version (IRV) coded character set, and
- Characters of standard coded character sets supporting and extending ISO/IEC 646 [14] IRV coded character set,
i.e. ISO/IEC 10646 [15] coded character set.
NOTE 1: ISO/IEC 646 [14] IRV coded character set is the international equivalent to the ANSI X3.4 ASCII coded
character set.
NOTE 2: The character set of ISO/IEC 646 [14] IRV corresponds to the subset of characters that range from
U+0000 to U+007F in the character set of ISO/IEC 10646 [15].
NOTE 3: The ISO/IEC 646 [14] IRV characters specifically referenced in this specification are further identified
using ISO/IEC 10646 [15] character short identifier notation form "U+XXXX".
7.1 Converting DN from ASN.1 to String
Subclause 7.1.1 defines the algorithm to convert an ASN.1 structured representation to one-string DN representation.
Subclause 7.1.2 defines the algorithm to convert an ASN.1 structured representation to multi-string DN representation.
CORBA SS uses one-string DN representation. XML SS uses both one-string and multi-string DN representations.
7.1.1 Rule for one-string DN
7.1.1.1 Converting RDNSequence
If the RDNSequence is an empty sequence, the result is the empty or zero length string.
Otherwise, the output consists of the string encoding of each RDN in the RDNSequence (according to subclause
7.1.1.2), starting with the first element of the sequence and moving forward toward the last element.
The encoding of adjacent RDNs are separated by a comma character (',', U+002C), to be consistent with IETF
RFC 2253 [7].
White spaces adjacent to the comma character shall be ignored.
ETSI
---------------------- Page: 13 ----------------------
3GPP TS 32.300 version 16.0.0 Release 16 13 ETSI TS 132 300 V16.0.0 (2020-08)
7.1.1.2 Converting RelativeDistinguishedName
When converting from an R
...