itu-t technical report · 2016. 12. 8. · of itu (23 september 2016) mstr-nreg telecom network...

I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n

ITU-T Technical Report TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU

(23 September 2016)

MSTR-NREG Telecom Network Registration

MSTR-NREG (2016-09) i

Summary

This technical report is a tutorial for how to register transmission network resources and

connections across all technologies.

This technical report illustrates how resources and connections within the transport network can be

registered.

This technical report provides both a short guide and more detailed tutorial for all the domains.

Keywords

Telecom Network Registration

Change Log

This document contains Version 1 of the ITU-T Technical Report on “Telecom Network

Registration” approved at the ITU-T Study Group 2 meeting held in Geneva, 14-23 September

2016.

Editor: Arve Meisingset

Telenor ASA/ Movinpics AS

Norway

Tel: +47 9139 2863

Email: [email protected]

mailto:[email protected]

MSTR-NREG (2016-09) ii

CONTENTS

20

1 SCOPE ..................................................................................................................................................................... 1

2 REFERENCES ........................................................................................................................................................ 2

3 TERMS AND DEFINITIONS ............................................................................................................................... 2

3.1 TERMS DEFINED ELSEWHERE................................................................................................................................. 2 3.2 TERMS DEFINED HERE ........................................................................................................................................... 2

4 ABBREVIATIONS ................................................................................................................................................. 3

5 BACKGROUND ..................................................................................................................................................... 3

6 OVERVIEW ............................................................................................................................................................ 4

7 TERMINOLOGY ................................................................................................................................................... 6

8 NOTATION ............................................................................................................................................................. 9

9 SHORT GUIDE .................................................................................................................................................... 11

9.1 ADMINISTRATIVE DOMAIN .................................................................................................................................. 12 9.2 PHYSICAL NETWORK DOMAIN ............................................................................................................................ 12 9.3 LOGICAL NETWORK DOMAIN.............................................................................................................................. 14 9.4 INDOOR DOMAIN ................................................................................................................................................. 16 9.5 ROUTING OF TRAILS ............................................................................................................................................ 18 9.6 ORDERS............................................................................................................................................................... 18

10 ADMINISTRATIVE DOMAIN ........................................................................................................................... 20

10.1 COUNTRIES..................................................................................................................................................... 20 10.2 OPERATORS .................................................................................................................................................... 21 10.3 GEOGRAPHICAL AREAS .................................................................................................................................. 23 10.4 ADDRESSES .................................................................................................................................................... 25 10.5 LOCAL IDENTIFIERS ........................................................................................................................................ 25

11 PHYSICAL NETWORK DOMAIN .................................................................................................................... 27

11.1 NODES ............................................................................................................................................................ 27 11.2 CROSS-COUPLING SITES .................................................................................................................................. 31 11.3 MULTIPOINT PHYSICAL RESOURCES ............................................................................................................... 36 11.4 PHYSICAL LEGS .............................................................................................................................................. 39 11.5 PHYSICAL SERIES............................................................................................................................................ 41 11.6 PHYSICAL BRANCHES ..................................................................................................................................... 44 11.7 LEG CONNECTIONS ......................................................................................................................................... 45 11.8 SERIES CONNECTIONS ..................................................................................................................................... 46 11.9 BRANCH CONNECTIONS .................................................................................................................................. 48 11.10 MULTIPOINT CONNECTIONS ............................................................................................................................ 49

12 LOGICAL NETWORK DOMAIN BETWEEN CROSS-COUPLING SITES ............................................... 49

12.1 SITE RELATIONSHIPS ...................................................................................................................................... 49 12.2 PHYSICAL LINKS ............................................................................................................................................. 52 12.3 PHYSICAL LINK CONNECTIONS ....................................................................................................................... 58 12.4 TRAILS BETWEEN CROSS-COUPLING SITES ..................................................................................................... 61 12.5 TERMINATIONS ............................................................................................................................................... 64 12.6 MULTIPOINT TRAILS ....................................................................................................................................... 65 12.7 TRAIL MULTIPLEX CHANNELS......................................................................................................................... 69 12.8 TRAIL SECTIONS ............................................................................................................................................. 70 12.9 ASSOCIATIONS ............................................................................................................................................... 72

13 LOGICAL NETWORK DOMAIN INSIDE CROSS-COUPLING SITES ...................................................... 73

13.1 EXCHANGES ................................................................................................................................................... 73 13.2 LOCATIONS .................................................................................................................................................... 74 13.3 POSITIONS ...................................................................................................................................................... 76 13.4 EQUIPMENT ITEMS .......................................................................................................................................... 79 13.5 COMPONENT ITEMS ........................................................................................................................................ 81 13.6 PORT ITEMS .................................................................................................................................................... 83 13.7 EQUIPMENT IDENTITY .................................................................................................................................... 86

MSTR-NREG (2016-09) iii

20 13.8 TRAILS WITHIN CROSS-COUPLING SITES ......................................................................................................... 86

14 ORDERS FOR THE LOGICAL NETWORK DOMAIN ................................................................................. 88

14.1 ORDERS .......................................................................................................................................................... 88

MSTR-NREG (2016-09) 1

Technical Report ITU-T MSTR-NREG

Technical Report ITU-T

Telecom Network Registration

Summary

This technical report is a tutorial for how to register transmission network resources and

connections across all technologies.

This technical report illustrates how resources and connections within the transport network can be

registered.

1 Scope

This technical report defines a terminology for registration of the topology of the

telecommunication transmission network across all technologies.

The technical report prescribes how to identify each individual resource of the transmission

network. The identification scheme covers:

International connections

Connections between national Operators

Transport network within each Operator

Access network within each Operator

The technical report applies international standards, and extends these for domains that are internal

to one Operator only.

The technical report provides Local identifiers, which may be used for identifications according to

regional standards or use of company specific codes. Also, the Local identifiers may be used to

refer to logical resources within transmission equipment, such as end-points and connections within

the Telecommunication Management Networks (TMN).

The technical report presents the data as they are to be perceived by human users at their human-

computer interface. Also, the identifiers are shown in schematic network graphs.

The technical report is based on and presents the data structures of the transmission network, with

entities, relationships and their identifying attribute groups. The data structures cover both the

logical and physical transmission network.

The technical report prescribes how to register transmission resources and connections both

between transmission stations and inside stations. The technical report does not cover switching

resources and traffic circuits. However, switching equipment may be registered as of transmission

equipment.

This technical report aims at educating the network Operators and their partners on managing their

telecommunication network. The primary audience of this technical report is

1. Users of network inventories

However, there is a large set of people with related roles, who will benefit from knowledge of the

contents of this technical report. These are:

2. Network planners

3. Network managers

4. Network technicians

5. Telecommunication students

MSTR-NREG (2016-09) 2

6. Data designers and data administrators of Operation Support Systems (OSS)

7. Standards developers of Operation Support Systems (OSS)

8. Developers of Operation Support Systems (OSS)

Managers of telecommunication networks within a telecom Operator should read the technical

report to understand what entities the management is about, and what challenges there are with

current registration.

Managed service providers should read the technical report of the same reason.

2 References

[1] ITU. ITU-T M.1400-M.1999. Designations and Information Exchange.

http://www.itu.int/ITU-T/recommendations/index.aspx?ser=M

[2] ITU. ITU-T M.1401. Formalization of interconnection designations among operators'

telecommunication networks. http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=8854.

Geneva 07/2006.

[3] ITU. ITU-T M.1400. Designations for interconnections among operators' networks.

http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11903. Geneva 04/2015.

[4] ITU. ITU-T M.3160. Generic, protocol-neutral management information model.

http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=9551. Geneva 11/2008.

[5] ATIS. http://www.atis.org/

[6] ATIS Specification ATIS-0300097 (2013), Structure for the Identification of

Telecommunications Connections for Interconnection Exchange. ATIS Specification ATIS-

0300097 (2013).

[7] ITU. List of ITU Carrier Codes (ICCs). https://www.itu.int/oth/T0201.

[8] NECA. Company Codes (OCNs). https://www.neca.org/Code_Administration.aspx.

[9] ITU. ITU-T M.1404. Formalization of orders for interconnections among operators'

networks. http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=9093. Geneva 08/2007.

[10] ITU. ITU-T Z.351. Data oriented human-machine interface specification technique –

Introduction. http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=3187. Geneva 3/1993.

[11] ITU. ITU-T Z.352. Data oriented human-machine interface specification technique – Scope,

approach and reference model. http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=3188.

Geneva 3/1993.

[12] ITU. ITU-T Z.601. Data architecture of one software system. http://www.itu.int/ITU-

T/recommendations/rec.aspx?rec=9061. Geneva 2/2007.

3 Terms and definitions

3.1 Terms defined elsewhere

This Technical Report uses the following terms defined elsewhere:

None.

3.2 Terms defined here

This Technical Report defines the following terms:

Each subsection of clauses 10-14 defines a term.

http://www.itu.int/ITU-T/recommendations/index.aspx?ser=M

http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=8854



http://www.atis.org/

https://www.itu.int/oth/T0201

https://www.neca.org/Code_Administration.aspx






MSTR-NREG (2016-09) 3

4 Abbreviations

ATIS Alliance for Telecommunications Industry

BSS

CC

CTP

ICC

IP

ISO

ME

NE

NEC

NECA

NEM

NLD

OSS

TTP

UID

Business Support Systems

Country Code

Connection Termination Point

ITU Carrier Code

Internet Protocol

International Organization for Standardization

Managed Element

Network Element

Network Element Complex

National Exchange Carrier Association

Network Element Manager systems

Network Layer Domain

Operation Support Systems

Trail Termination Point

Unique item identification

5 Background

Rec M.1401 is a formalization of M.1400 - Designations for interconnections among operators'

networks [3]. M.1401 provides a modern documentation, using data structures, while M.1400 uses a

more than 50 years old, textual and tabular style. M.1401 improves the understanding, but does not

fully replace M.1400. M.1400 contains code sets which are not defined in M.1401.

M.1400 is the lingua franca for communication between telecom operators about international

connections.

M.1400 has also been extended to apply for communication between national operators, but its use

for this purpose is very limited, as each operator may apply its own designations. This lack of use of

standards is unfortunate, as it does not allow automatic interchange of data between operators, e.g.

for provisioning of trails between networks and for root-cause analysis of alarms and failures of

shared networks.

Some operators are using M.1400 for registration of their internal transport network. This, in

particular, applies for the incumbent fixed line operators. Mobile operators have little knowledge of

these standards, and each has varying degree of registration and data quality. These challenges are

increasing when using shared networks of several collaborating telecom operators and when using

managed service partners who register the networks in their own way.

The current technical report extends the usages indicated above, to also cover registration of access

networks. Registration of access networks is purely within the domain of each Operator, but here

we indicate how this may be done if using or extending the current standards.

MSTR-NREG (2016-09) 4

Also, ITU-T Recommendations only cover registration of the logical network domain, and do not

cover the physical network domain. However, this technical report covers the physical network

domain, as well. See later on these domains.

Some Operators are using ATIS standards to register the network domains mentioned above. These

standards are developed independently of the ITU-T Recommendations, but ITU-T

Recommendations are to some extent extended to allow for common use if this is agreed bilaterally

between the involved Operators. Clause 11 of this technical report on the Physical network domain

builds on ATIS standards, but ATIS standards are not presented in this technical report.

Also, Network Element Management (NEM) systems are using other ITU-T Recommendations for

identification logical resources within and between equipment. The M.1400 series

Recommendations cover only the outside physical view of the equipment. The inside logical view

and the outside physical view do not always comply. Hence, the network inventories need to

manage the mappings between the two views. Recommendations for the internal logical view of

NEM systems are not presented in this technical report. Each NEM vendor has its own

interpretation of the NEM Recommendations, and it has become a complex task to map to the

various implementations. We have introduced Local identifiers to deal with the mapping to the

NEM view.

If a telecommunication student is going to learn about network management, this technical report

tells what transmission network entities he may need to manage. And the technical report could

provide the contents of a course. However, the student will need more background before starting

on this course. Understanding of the various management domains is needed. Also, the student will

need background on management tasks and architectures.

6 Overview

This technical report aims at

help understanding

help communication

teach terminology

teach identification

teach registration

of the telecommunication network. The target readers are people who are, or want to become,

experts on managing the telecommunication network.

The technical report will not teach the various management tasks and not teach about software tools

to manage the network. Rather, we teach the data structures, which will be common for both human

users and software applications.

The data structure will define the recommended common terminology to be used for network

design, construction, configuration, operation and use. The technical report will not teach the

various technologies that are used throughout the network. Rather, the data structure defines the

topological structure of the network, independently of what technology to be used.

We will illustrate the data structure and its instantiation by using various technologies, but the

particular technology to be used will only appear as attributes of the topological entities of the

network. We will use one common example throughout most of the sections, but in some sections

we also add other examples.

The data structure defines a common terminology across multiple technologies. This means that the

same entity classes are used to denote radio links, satellite communication, coax cables, twisted pair

cables and optical fiber cables. This harmonization of the terminology allows experts on various

technologies to talk together across the technology borders. But the harmonization also creates a

MSTR-NREG (2016-09) 5

challenge, as it does not allow each technologist to speak the specialist language about his

technology.

This tension between the general topology language and the specialized technology language will

create challenges, as the various professions will need to master both. The specialist technology

language will be used for implementation within each constrained domain, while the topology

language will be used as the lingua franca for communication across all management domains.

Above, we have used the expressions data structure, language and terminology in a colloquial way.

We will clarify the meanings in the next clause.

We may split the telecommunication network into four domains

Service platforms

Traffic platforms

Logical transmission network

Physical transmission network

Below the physical transmission network, we may find geographical and site information. Above

the service platform, we may find customer, service, charging and billing management, and still

other domains. Parallel to the four bulleted domains, we may find performance management, alarm

surveillance etc.

This technical report is addressing the logical and physical transmission network. M.1401 only

covers the logical network. This technical report extends the coverage with including the physical

network.

We will start with the physical network, as this will explain the underlying technology. However,

the identification of both physical and logical resources will depend on identification of Country,

Operator and Cross-coupling site, which are all presented under

Clause 10 Administrative domain

And then

Clause 11 Physical network domain

Presentation of the Logical network domain we will split into two parts

Clause 12 Logical network domain between Cross-coupling sites

Clause 13 Logical network domain inside Cross-coupling sites

The expression Physical network domain refers to physical resources between Cross-coupling sites,

such as cables, radio links, satellite hops etc. The expression Logical network domain refers to the

topological resources which are created above the physical resources.

The Logical network domain is created by both physical resources, such as equipment and cross-

couplings, inside Cross-coupling sites, and of software within this equipment. Therefore, the

Logical network domain covers physical resources inside Cross-coupling sites, and logical

resources seen by the inventory software, such as links, trails and termination points seen from the

software. These distinctions may be difficult to follow, but this is how reality is, and these

distinctions must be understood.

Data of the Logical network domain will be used in

Clause 14 Orders for the Logical network domain

In addition to the vertical partitioning into domains, as indicated above, the network may be

horizontally partitioned into

Core network, which provides communication services on top of the Logical and Physical

networks

MSTR-NREG (2016-09) 6

Transport network, which connects intelligent nodes, e.g. switches and routers, in the

network

Access network, which reach out from the intelligent nodes to the customers

The terminology recommended in this technical report applies both for the transport and access

network.

The ITU-T Recommendations for identification of resources only apply for the transport network,

and not for the access network. However, with more intelligent nodes in the network, the transport

network is growing, and goes all the way to the mobile base stations. The old fixed line access

network was large and complex, but is now diminishing. In this technical report, we indicate

identification for the access network, as well. To cover both transport and access networks increases

the complexity of the technical report, but this is the complexity that a real Operator has to deal

with.

The ITU-T M.1400 series Recommendations only apply for international and national

communication between telecommunication Operators, and do not apply for the internal network of

the Operators. But the incumbent Operators are using these ITU-T Recommendations, or a variant

of them, for their internal transport network.

What then about Internet Protocol (IP) networks? If IP is used to define transport resources, they are

covered by this technical report. If they are used to define traffic connections, they are not covered.

Unfortunately, Recommendations for Network Element Management (NEM) have for a long time

been disconnected from the M.1400 series Recommendations. This may be due to that the M.1400

series were only known to telecom Operators, and not to vendors, who started out with their own

terminology for implementation of automatic management of digital cross-connects. This has

resulted in a terminology for NEMs which is different from the M.1400 series, and transformation

of identifiers are needed between systems of different domains. However, in later versions of ITU-T

Recommendation M.3160 Generic, protocol-neutral management information model [4], the

M.1401 terminology is incorporated, but this incorporation may not be implemented in current

software. Network inventories need to manage mappings between M.1400 identifiers and NEM

identifiers. A separate section in the current technical report on Local identifiers introduces this

mapping.

ATIS [5] has developed its own set of regional standards for designation of the network, and several

software products are based on these standards. ITU-T Recommendations are mainly implemented

in in-house software by each telecom operator.

In an attempt to harmonize ITU-T Recommendations and ATIS standards, the ITU-T M.1401 is

extended with Local identifiers, which may hold the ATIS identifiers of the resource. Also, we have

developed ATIS-0300097 (2013), Structure for the Identification of Telecommunications

Connections for Interconnection Exchange [6], which maps between ATIS and ITU-T terminology.

This standard also covers the physical network.

ITU is publishing ITU Carrier Codes at its web site [7]. This site is integrated with NECA’s site on

Company Codes [8].

7 Terminology

This technical report aims at explaining the network terminology as being seen by human users at

their human-computer interfaces. The terms may appear both as headings and values at the user

interfaces.

This technical report additionally explains the grammar for combing these terms into valid

statements. The grammar is expressed through containments and references.

MSTR-NREG (2016-09) 7

The combination of terms and their grammar make up the definition of the end user language. The

combination of terms and grammar is called a data structure. The expression data structure is used

for many other purposes, e.g. to define the structure of data in data bases. We use the data structure

to define the end user language. This is a different usage, with its own features and notation, even if

its resemblance to data base structures is evident.

ITU-T Recommendation M.1401 uses a particular formalism for defining the data. This technical

report uses a more colloquial style, and adds a lot of illustrations.

The particular data structure that defines the language used at the human-computer interface is

defined in an External terminology schema. This is one component of the Data transformation

architecture for IT systems, defined in ITU-T Recommendation Z.601 Data architecture of one

software system [12]. M.1401 defines the External terminology schema for interconnections among

operators' networks.

An External terminology schema defines classes that act as general prototypes/templates for the

data instances about a particular network. M.1401 documents a schema. A collection of instances is

called a population. This technical report will define the classes and show example instances.

Both schemata and populations may be documented in a graphical or alphanumerical notation. In

this technical report we will use only the graphical notation. We use the same notation for classes

and instances. Hence, the data are not classes or instances in an absolute way; they are only so

relative to each other.

Figure 7-1 shows a class diagram for the physical network domain.

Figure 7-1 External terminology schema for Physical Network Domain

The part to the left of the thick vertical dashed line belongs to the logical network domain, but we

have to show this part in order to cover the mappings between the physical and logical network

domains.

Figure 7-2 shows a class diagram for the logical network domain.

MSTR-NREG (2016-09) 8

Figure 7-2 External terminology schema for Logical Network Domain

The two above Figures are the two most important Figures of this technical report. When you have

understood these, you have understood the entire technical report. The two figures serve as a

summary of the entire technical report.

For each box and line in the two diagrams, we in this technical report may

show where we are in the diagram

state definition of each item

explain how each item is identified

show a drawing of physical resources

show an example instance diagram of these resources

show a schematic graph corresponding to the instance diagram

add explanations when needed

In the examples of identifiers, we have shown both headings and values. We have used no

abbreviation, even if use of abbreviations will be convenient in practical implementations. Also, we

have adjusted both texts and numbers to the left, even if implementations may do otherwise.

MSTR-NREG (2016-09) 9

8 Notation

This clause defines a graphic notation for defining data classes and show example data instances.

Also, a notation for schematic network graphs is provided.

In the class and instance diagrams, we will use the following notation:

Figure 8-1 Graphic notation

From Figure 8-1 we see that only entity classes are depicted in the class diagrams in Figures 7-1 and

7-2, and we will focus on entities and their relationships in this technical report, and not on

attributes and functions. The relationships are stated as

Containments, or

Two-way references

Containments tell that the contained class has a class label local to the superior class. An entity class

can only be local to one superior entity class. An attribute group class is local to its entity class or

another attribute group class. An attribute class is local to its entity class or its attribute group class.

Instances are created by taking copies of the class and its superior containment. If class B is

contained in class A, then an instance of a class B must be contained in an instance of class A. This

applies for entities, attribute groups and attributes.

Moreover, if class B is contained in class A, then the value of the identifying attribute (group) of an

instance of a class B shall be local to the value of the identifying attribute (group) in an instance of

class A. Hence, the containment shows how entities are identified local to each other. We will see

many examples of this in the texts on each entity class.

In the instance diagrams we will frequently only show identification values and skip attribute and

entity labels, as these will overload the drawings.

In this technical report, we will use only two-way references. Reference classes between entity

classes are copied into reference instances between entity instances.

MSTR-NREG (2016-09) 10

The copying described in the previous paragraphs is called an instantiation mechanism, and it

explains how the contents of populations are created.

We will additionally use the one-way schema reference in this technical report. We will explain this

reference when it will be needed.

The reader may find more explanation of the notation in Appendix III of [2]. If he wants to learn

about the background for the notation, he may read [12].

In the schematic graphs, we will use the following symbols:

Figure 8-2 Symbols for the Physical network domain

Figure 8-3 Symbols for the Logical network domain

MSTR-NREG (2016-09) 11

Figure 8-4 Symbols of resources within Cross-coupling sites

Note that the symbols for the schematic graphs are not standardized, so the Operator is free to use

any other symbols.

The schematic graphs provide a better visualization of the information already contained in the

instance diagrams.

9 Short guide

This clause is a short guide to the complete tutorial in this technical report.

The network registration is using the terminology depicted in the following two figures.

The physical network domain covers all outdoor technologies, such as cables, optical fibers, radio

links and satellite communication.

Figure 9-1 External terminology schema for Physical Network Domain

Reversed arrow heads tell that the subordinate item is identified within the scope of the superior

item. Two-way arrows are indicating references between items. The dashed line is indicating that

the items on its left side are referring to or overlapping with the logical network domain.

MSTR-NREG (2016-09) 12

The logical network domain covers direct connections between Cross-coupling sites. These

connections may be implemented by items from the physical network domain or by other items

from the logical network domain. Also, resources and connections within cross-coupling sites are

contained in this domain. See separate sections in the current document.

A Cross-coupling site is a Node where couplings and configurations may be based on cross-

coupling Orders. Other Nodes require construction Orders. Note that words with capital first letters

are according to the terminology presented in Figures.

Figure 9-2 External terminology schema for the Logical Network Domain

9.1 Administrative domain

Each Country is identified by an ISO 3166 alpha-3 code, called Country Code (CC).

An Operator must be legally recognized by the telecommunication Administration of the Country,

or delegation thereof. The Operator is assigned an ITU Carrier Code (ICC).

Cross-coupling sites are identified by the Operator. Identifiers of Cross-coupling sites, Operators

and Country can normally not be changed, as any change may affect registrations within related

Cross-coupling sites and Operators.

Trails and Physical links are registered within a Site relationship.. Site relationships are identified

by the identifiers of the two Cross-coupling sites in alphabetical order. Within an Operator, only the

local name of the Cross-coupling site may be used. In addition, a Cross-coupling site may have a

Local identifier, which allows for additional use of regional standards or business specific codes.

9.2 Physical Network Domain

We will use an example physical network, as being depicted in the following Figure.

MSTR-NREG (2016-09) 13

Figure 9-3 Picture of an example network

Nodes and Multipoint physical resources are identified as follows.

Figure 9-4 Example identification of pure Nodes within Multipoint physical resources

Cross-coupling sites are here indicated by quadrates. Pure Nodes are indicated by circles.

Multipoint resources are indicated by ellipses. Note that only OSLO1 and OSLO2 belong to the

transport network. Cross-coupling sites in the access network are in this example -informally

indicated by dashes in the identifiers - identified within the scope of their main distribution center.

Pure Nodes are informally identified within their Multipoint physical resource. Multipoint physical

resources are formally – indicated by commas - identified within some Cross-coupling site.

Note that for the physical network, there may not be any clear distinction between the transport and

the access network, as transport connections may be routed in the access network. The antenna in

OSLO1-6 may indicate a mobile base station. The physical transport network may be registered in a

similar way as of an access network.

Physical legs between Nodes are identified as follows.

Figure 9-5 Example schematic graph of Physical legs

MSTR-NREG (2016-09) 14

Physical legs are here depicted as a line with a filled in circle in each end. The Physical legs are

identified within their respective Multipoint physical resources, being depicted in the previous

Figure.

Nodes are depicted as a combination of a quadrat and a circle. The Nodes are identified in the

previous Figure.

Physical series are depicted as a line with a rotated filled quadrat in each end. Note that they are

identified within the scope of their Multipoint physical resource, as well.

Figure 9-6 Example Physical series

Physical branches are here depicted as a line with a filled arrow in each end. Note that they are

identified within the scope of their Multipoint physical resource, as well.

Figure 9-7 Example Physical branches

Note that Physical series are used to represent detailed splits of cables between the same two

destinations, while Physical branches only show splits to different Cross-coupling sites.

9.3 Logical Network Domain

A Site relationship between two Cross-coupling sites is created if there exist or is planned Physical

links or Trails between the two sites.

MSTR-NREG (2016-09) 15

Figure 9-8 Example Site relationships

Site relationships are in Figure 9-8 depicted with thick lines having hooked arrows in each end. A

dash in the middle of the identifier is used to indicate the split between the two parts of the Site

relationship identifier.

The Site relationship is used as a mandatory part of the identification of Trails and Physical links.

Hence, they are essential for registration of Trail multiplex channels and of Physical link

connections. Also, Site relationships provide overview of these resources between the two Cross-

coupling sites.

The Identifier of the Site relationship in the transport network of one Operator is an attribute group

of the identifiers of the two Cross-coupling sites in alphabetical sequence. Site relationships

between Cross-coupling sites in different Operators or Countries must include identifiers of the

Operator and Country in each end. These identifiers are called ICCs and Country Codes,

respectively, and they do not affect the alphabetical sequence.

A Physical link connects two Cross-coupling sites and is routed on a series of Physical branches.

Several Physical links may share the same Physical branch.

Figure 9-9 Example Physical links

In Figure 9-9, the Physical links are here depicted as thin lines with hooked arrows in each end.

Physical links are numbered within their Site relationship. Note that between OSLO1 and OSLO2

there are two Physical links within the same Site relationship.

A Trail connects two Cross-coupling sites and contains a series of Trail sections, which may be

Physical link connections, Trail multiplex channels, other Trails, Positions or Ports. Also a Trail

may be multiplexed into several Trail multiplex channels in parallel.

The next Figure depicts how Trails may be routed on Physical link connections.

MSTR-NREG (2016-09) 16

Figure 9-10 Routing of three Trails on Physical link connections

The Figure above illustrates the physical cross-couplings within Trails. The two-way arrows inside

Cross-coupling sites indicate cross-couplings between Trail sections within the Trails. The Trail

sections correspond here to Physical link connections. Physical link connections are depicted as one

thin line. Physical links consists of several Physical link connections in parallel.

And the following Figure depicts the three Trails.

Figure 9-11 Depiction of the three Trails

In Figure 9-11 Trails are depicted with thick lines. Trails within the transport network are identified

within their respective Site relationship. The Site relationships are shown in the previous Figure 9-

10.

Trails may be multiplexed into several Trail multiplex channels in parallel. This is not illustrated in

the current document.

Note that the identifiers of Trails and Physical links are independent of each other, and may overlap.

See ITU-T Recommendation Z.1400 on use of Function codes within the Trail Identifier.

9.4 Indoor Domain

The Logical network domain may also contain resources and connections inside Cross-coupling

sites.

The next Figure illustrates the construction of a cross-coupling rack. The rack consists of ten

blocks, and the tenth block has ten Positions. Cross-couplings are most often made between

Positions.

MSTR-NREG (2016-09) 17

Figure 9-12 Example instance diagram of Positions within Locations

A Position is numbered within its block, and a block is numbered within its superior Location or

Cross-coupling site.

The next Figure illustrates the construction of Equipment items.

Figure 9-13 Example instance diagram of Port items within Component items within

Equipment items

A Port item is identified within its Component item within its Equipment item within its Cross-

coupling site. Termination of a Port item is made by a reference to its Position.

MSTR-NREG (2016-09) 18

9.5 Routing of Trails

The next Figure shows a detailed routing of a Trail through all its Trail sections. The Trail goes

between PARIS1 and BERG2-5. Only the Identifier part of the full Trail Identifier is shown.

Countries, Operators and Cross-coupling sites of the Trail Identifier are not shown.

Trail

Identifier

9876543100 .

Trail section

Identifier Type A-end B-end Section Item

CC ICC Identifier CC ICC Identifier

0i O FRA ORAN PARIS1 RO4/RA8/BL4 4

1 T FRA ORAN PARIS1 NOR TELN OSLO1 315 4

1i O NOR TELN OSLO1 RO2/RA1/BL1 14

1ii O NOR TELN OSLO1 RO2/RA2/BL4 14

1a R NOR TELN OSLO1 AMPL3/CO2 P1

1b R NOR TELN OSLO1 AMPL3/CO2 P2

1iii O NOR TELN OSLO1 RO2/RA1/BL8 6


2 T NOR TELN BERG2 NOR TELN OSLO1 2 412

2i O NOR TELN BERG2 RO1/RA1/BL7 2


3 L NOR TELN BERG2 NOR |TELN BERG2-5 BERG2 C31-40 31

2i T NOR TELN BERG2-5 RA1/BL1 1

Figure 9-14 Internal and external Trail sections of a Trail

The following Trail section Types are used:

C – Trail multiplex channel

L – Physical link connection

O – Position

R – Port item

T – Trail

9.6 Orders

An Order may be split into several Messages, each going to different or same destination. This is

illustrated in the next Figure.

Order

Identifier

123

Message

Identifier Action

1 ESTABLISH

Trail

Identifier

9876543100 .

Trail section








Message

Identifier Action

MSTR-NREG (2016-09) 19

2 ESTABLISH

Trail

Identifier

9876543100 .

Trail section








Message

Identifier Action

3 ESTABLISH

Trail

Identifier

9876543100 .

Trail section







Figure 9-15. Cross-coupling Order split into three Messages, one for each cross-coupling

MSTR-NREG (2016-09) 20

10 Administrative domain

10.1 Countries

A Country is an area that is assigned a Country Code according to ISO 3166.

All telecommunication operators, sites and resources are identified within Countries. When defining

connections between sites in two Countries, you will have to identify both these Countries. This is

why Country is such an important notion for designation of telecommunication resources.

Figure 10-1 Schema of Countries

Each Country is identified by an ISO 3166 alpha-3 code called Country Code (CC). This is a three

letter alphabetic code assigned by the ISO 3166 Maintenance Agency.

The next figure shows an example layout.

Country

CC

NOR.

Figure 10-2 Example layout of Country Codes

MSTR-NREG (2016-09) 21

Figure 10-3 World map indicating Countries

Each Country has a telecommunication authority. This may be a ministry. In ITU, this authority

may be referred to as an Administration. An Administration is an agency of a government

designated to represent that government and its various interests in the ITU. Sometimes the

Administration is the telecommunication regulator of that country, sometimes the Administration is

another agency. The Administration acts to administrate the ITU international designations,

numbering, addressing, accounting, etc. in coordination with the ITU.

The Administration may delegate responsibilities to various entities. Examples hereof have been:

1. Regulatory responsibilities within a ministry (e.g., Japan, China etc. many in the Asia &

Pacific);

2. A fully autonomous & independent regulator (e.g., the USA, the UK, Hong Kong)

3. A semi-autonomous independent regulator (e.g., Canada);

4. Industry self-regulation (e.g., some developing countries etc.);

5. No telecommunication-specific regulation (e.g., New Zealand)

The particular arrangement in each Country needs to be known in order to apply for license to

operate telecommunication networks and services, and to become registered as a recognized

operating agency, being assigned an ITU Carrier Code. See the subsequent section on Operator.

10.2 Operators

An Operator is an organization responsible for identification and management of

telecommunication resources. The Operator must be legally recognized by the telecommunication

Administration of the Country, or delegation thereof.

An Operator can be a network operator or service provider, but in this technical report we are

interested in the network management role only.

MSTR-NREG (2016-09) 22

Figure 10-4 Schema of Operators

Both the national authority and the Operators should note that each Operator would be registered as

a separate entity in each Country in which it operates, and is required to report country-specific

information to each national authority. This may or may not imply a need for a multinational

Operator to use different ITU Carrier Codes (ICC) in each Country. See on ICCs below. Multi-

national Operators are encouraged to ensure that they are registered in each Country in which they

operate.

Some Operators may have outsourced the management of their network to Managed service

partners. In most cases, the Managed service partner is not another Operator.

When using Managed service partners, the responsibility for the identification and management

remains by the Operator, and cannot be transferred to the partner carrying out the job. The Managed

service partner may be located in the same or another Country.

The Ownership of sites and resources may change during the lifetime of these sites and resources.

In these cases, the identifiers of these sites and resources shall remain unchanged. The purpose of

this rule is to avoid change of identifiers and registrations within related Operators. So if one

Operator takes over a site from another Operator in a Country, the entire site identifier shall remain

unchanged. However, if the location of a site is annexed by another Country, then the ICC of the

new Country shall be applied. I do not know how to deal with disputed areas, but expect that you

have to recognize the actual owner even when the annexation is not internationally recognized.

However, the new Country must be recognized and given an ICC; if not, the old ICC applies.

The effect of the two last paragraphs is that Operator, Manager and Owner may identify three

different entities. The registration needs to cater for all three options.

An Operator can only operate a network within one Country, and the Operator has received a

license for this operation from the regulator of this Country. See on national authority and regulator

in the preceding section on Country. The Operator within a Country may be a part of corporation

which may have Operators in several Countries. The corporation may even have several Operators

in one Country.

Each Operator in a Country shall be assigned an ICC. A request for an ICC is sent to the regulator,

who forwards this information to ITU, which assigns the ICC. The ICC is a six letter code that is

unique within the Country.

The ICC shall be used in all communication between Operators on management of their networks,

sharing of network resources and provisioning and reporting on connections between these

networks.

MSTR-NREG (2016-09) 23

A list of all ICCs worldwide appears at itu.int.

The ICC provides a unique identifier of an Operator within a Country. The assignment of ICCs may

be delegated to a lower-level regional administration (for example, a province).

The ICC is used as an indispensable part in the assignment of identifiers for interworking between

Operators. It is permissible that an Operator uses one ICC for assignment of identifiers, while other

operator codes are used for ordering, billing, etc.

ICC is a 1- to 6-character alphanumeric field.

See ITU-T Recommendation M.1401 Appendix I on registration of ICCs. Here you also will learn

about the particular arrangements in North America.

An Operator may register itself, its competitors and collaborators within the same or other

Countries. Not all of these may be recognized as Operators, but the Operator may treat them as

such, e.g. by prefixing the non-operator entities. Such entities may be the national defense, the

national railway etc., having their own network, and who may have network sharing with the

Operator. The Operator may need to register other Operators, e.g. when trails are routed through

these Operators’ network.

Country Operator

CC ICC

NOR. TELNOR.

TELIA .

SWE. TELNOR.

TELIA .

Figure 10-5 Example Operators in the same and different Countries

Note in the above Figure, TELNOR in NOR and TELNOR in SWE are two different Operators.

Also, the presentation may use global distinguished names.

Operator

CC ICC

NOR. TELNOR.

NOR. TELIA .

SWE. TELNOR.

SWE. TELIA .

Figure 10-6 Example use of global distinguished names

10.3 Geographical areas

A Geographical area is a geographical or administrative area defined by the authorities of that

Country.

From the definition, a Geographical area is not an area defined by the telecommunication Operator

for his convenience. The Geographical area is typically a town or municipality which helps an

outsider to locate the site.

Note that Geographical area is not the Address of the site.

MSTR-NREG (2016-09) 24

Figure 10-7 Schema of Geographical areas

A Geographical area is contained in one Country, and cannot cross Country borders.

A Geographical area may have references to all the Cross-coupling sites that are contained in this

area.

The Name of a Geographical area is spelled as given by the authorities in that Country, i.e., in a

national language of that Country. Note that different spellings dependent on the user are not

permissible. Geographical area Name has up to 12 characters. Upper- and lower-case letters are

permitted. Symbols that may be included in Geographical area Name are hyphen (-), underscore (_)

and space ( ). In case the spelling given by the authorities exceeds 12 characters is not unique with

12 characters only, the Administration in that Country is responsible for assigning a unique

identifier.

Country Geographical area

CC Identifier

NOR. BERGEN .

KRISTIANSAND.

OSLO .

Figure 10-8 Example Geographical areas within a Country

Geographical areas may also be presented with global distinguished names.

Geographical area

Name

CC Identifier

NOR. BERGEN .

NOR. KRISTIANSAND.

NOR. OSLO .

Figure 10-9 Example use of global distinguished names

Note that the Geographical area Name may appear in identifiers of Cross-coupling sites and of

Trails. Hence, these Names are used to identify telecommunication resources and connections.

MSTR-NREG (2016-09) 25

10.4 Addresses

An Address identifies a geographic location, which may contain a Cross-coupling site.

The Address will typically identify street and house number, and maybe floor and room number

where the Cross-coupling site is located.

Figure 10-10 Schema of Addresses

The Address identifier may use the format of a postal address, but it may not be the location to

where you send the mail. Also, Addresses may use co-ordinates.

The Address may use the Name of a Geographical area for its identification. However, the spelling

of the Address is not constrained in the same way as of Geographical area. Hence, there is no

formal relation between these two notions.

The Address will typically be local to country, but we leave this spelling of the country name to

each Operator. Therefore, we have no containment within Country.

Even if an Address gives a precise location, an Address may contain several Cross-coupling sites.

But a Cross-coupling site cannot span several Addresses. Each Cross-coupling site has only one

Address.

An Address may have references to all Cross-coupling sites located at this Address.

10.5 Local identifiers

This clause extends the identification scheme defined in the ITU-T M.1400 series

Recommendations.

The M.1401 Recommendation contains Local identifiers to many of its entity classes. The intention

is to allow use of identifiers from ATIS standards within an Operator or between Operators if this

agreed bilaterally between both Operators.

There may be other usages of Local identifiers, and there may be a need for more than one Local

identifier of the same entity instance. If so, the Local identifiers should be provided with a tag

which indicates their use. This tag may be a prefix.

One example such use may be that the Operator internally uses identifiers which deviate from the

ITU-T Recommendations, and may put this internal identifier into the Local identifier. For

communication between Operators, the Operator has to comply with the ITU-T Recommendations.

MSTR-NREG (2016-09) 26

A third use of Local identifiers is use of IP addresses. Both Equipment items and Component items

may have IP addresses.

A fourth use of Local identifiers is to manage mappings to identifiers used within Network Element

Management systems (NEMs). These identifiers address logical resources as being seen from the

software within the equipment. Equipment items, Component items and Port items may have such

addresses.

A Network Element (NE) is a collection of capabilities to perform network element functions.

Hence, an NE is a capability within the network. An NE may be distributed across several

Equipment items, or an Equipment item may contain several NEs.

A Managed Element (ME) is a collection of capabilities to perform element management functions.

An ME is a capability within the network management domain. An ME may be distributed across

several Equipment items, or an Equipment item may contain several MEs.

The ITU-T Recommendation M.3160 introduces MEs, but does not tell about any mapping to NEs.

We believe that the functional capability within equipment should be called NE and not ME.

Also, it would have been simpler to read M.3160 if it more clearly pointed out the inside software

view, as being distinct from the outside hardware view. The M.1400 series only cover this outside

view. The definition of ME is so abstract that it may denote both physical and software resources; in

the diagrams it seems sometimes to replace Cross-coupling site, which is confusing.

An ME is identified within a Network. It seems to be up to the manager to define the boundaries of

one Network, e.g. to be the network managed by one NEM. There seems to be no coordination of

identifiers across NEMs. M.3160 has added the notions of Country and Operator, but they are not

used in the identification of MEs and their resources. We recommend that an NE comprises the

network functionality of one equipment item.

A Local identifier of an equipment item or component item may refer to an NE. An NE may be

identified within a Network Element Complex (NEC), which may correspond to the network being

managed by one NEM.

An NE may address, manage, activate and use transmission resources. The network inventories will

have to map to and manage these resources across several NEs and several NEMs. Local identifiers

may be used for this purpose.

However, Local identifiers were originally defined only to deal with ATIS standards. In order to

deal with mappings to NEM resources, Local identifiers will have to be defined for most M.1401

entity classes.

In particular, the M.1401 Port item class has to be supplied with a Local identifier. This identifier

may refer to a Trail Termination Point (TTP) or Connection Termination Point (CTP). These are

identified within a Network Layer Domain (NLD) within a Network.

Sometimes the TTP or CTP identifiers are identical to the external Port identifier. Then no mapping

is needed. However, in some cases, there are deviations, which call for use of the Local identifier.

Use of Local identifiers is a minimal solution for managing data in multiple NEMs from a common

inventory. A more complete solution would be to include some of the NEM data structures in the

inventory, but this may not be easily done, as different NEMs may be having different structures

and use them differently.

MSTR-NREG (2016-09) 27

11 Physical Network Domain

11.1 Nodes

A Node is a site where couplings between transmission resources are made or can be made.

Figure 9.1 identifies the Node entity class in the External terminology schema for the Physical

network domain.

Figure 11-1 Node in the External terminology schema

A Node may be

1. One or more cable splits

2. One or more cable splices

3. A regenerator site

4. A junction box

5. A man hole where couplings are made

6. A satellite

7. An earth station

8. A mobile base station

9. A relay station

10. A radio terminal station

11. A coast radio station

12. A transmission station

13. A switching center

From the examples, we see that a coupling within a Node may be a splice, a cross-coupling, a piece

of equipment etc. We will soon come to a sub-categorization of these.

A Node may contain several of the above functions.

MSTR-NREG (2016-09) 28

Figure 11-2 Picture of an example network

Figure 11-3 Schematic graph of example network

Figure 11-4 Schematic graph of Nodes

Figure 11-5 Schematic graph of Pure nodes and Cross-coupling sites

Note that if only some pairs of a cable have amplifiers, regenerators etc., all pairs of the cable are

considered to be terminated and connected in this Node.

There may be many sites which are relevant for the registration of the telecommunication network,

but are not considered to be Nodes. Such sites are:

Telephone poles

Crossings and splits of cable ditches and tunnels

Terminations and splits of cable beds

Man holes with no couplings

Bends of ditches and tunnels

MSTR-NREG (2016-09) 29

A Node may contain a curled up cable. The curled up cable is not terminated in the other end. The

curled up cable does not belong to the telecommunication network, even if it may be connected to

it. Any topological connection in the telecommunication network is terminated in two or more

Nodes.

A chord from a terminating junction box to the customer equipment is not considered to be a part of

the telecommunication network. These resources outside the network are not being designated

according to guidelines for the telecommunication network, but they may be recorded in Business

Support Systems.

Sometimes it may be difficult to decide what is a single Node, and what should count as two

separate Nodes. Some cables are just rolled out through the location, and should not be considered

to be terminated in the Node. Several cables are connected one-by-one, but to no other cable. These

last cables may be considered to be terminated in the same Node.

Figure 11-6 Illustration of terminations in and bypassing of a Node

If you have to put in and register a third cable between two cables, then the two cables should be

registered as being terminated in different Nodes. Hence, different rooms and floors in the same

building may count as different Nodes, or they may not. You will find a more detailed discussion on

this topic under Cross-coupling site in Part 3 on the Logical Network Domain.

There are three kinds of Node roles:

pure Nodes

Cross-coupling sites

Exchanges

A Node may contain one Cross-coupling site.

A Node without a Cross-coupling site is a pure Node.

A Cross-coupling site may contain zero, one or more Exchanges.

A pure Node is a permanent installation. The pure Node is only changed through construction work.

This means that the work requires a Network plan.

A Cross-coupling site will contain semi-permanent connections and equipment. These may be

changed by issuing of Work orders. Read about Cross-coupling sites in a separate subsequent

section. Cross-couplings take place in Cross-coupling sites.

The primary purpose of Work orders is to carry out provisioning of trails. However, Work orders

may also be issued for repair, installation of equipment, configuration of equipment, cross-

couplings etc.

The semi-permanent connections may be created manually by a technician or by software for

network element management.

Exchanges carry out manual or automatic switching. The switching may happen in real time. The

switching is based on calls, or package arrivals, and will therefore not require Work order.

Both Nodes and Cross-coupling sites are identified within the scope of a telecom Operator.

However, Nodes and Cross-coupling sites have separate name spaces. If a Node contains a Cross-

MSTR-NREG (2016-09) 30

coupling site, the names may be the same, or they may be different. Most often, the same name is

used, since this will simplify the reference between the two.

The telecom Operator is free to use its own conventions for identifying pure Nodes. Some

Operators identify Nodes within the scope of their Multipoint physical resource, others use a

globally unique number etc.

Figure 11-7 Example identification of pure Nodes

Figure 11-8 Example identification of pure Nodes within Multipoint physical resources

Figure 11-7 may exemplify registration within a transport network. Figure 11-8 may exemplify

registration within an access network. Both registrations are in use in both network domains, and

different pairs in the same cable may be used for the transport and access network domains.

Note in Figure 11-8, pure Nodes are identified within Multipoint physical resources. This

containment is only informal, so the entire identifier of the Multipoint physical resource is repeated

in each pure Node Identifier. The informal containment does not allow pure Nodes to be listed

within Multipoint physical resources. So, an Operator is doing nothing wrong by leaving out the

Multipoint physical resource as a separate entity class.

The Multipoint physical resource, if registered, is identified within a superior Cross-coupling site.

This containment is formal. Therefore, the identifier of the Cross-coupling site is written before the

comma in the label of each Multipoint physical resource in the Figure. The full identifier with a

dash appears in each pure Node. The formal containment allows Multipoint physical resources to be

listed within their superior Cross-coupling site, even if this is not illustrated in the Figure. The

Figure contains four Multipoint physical resources having the local distinguished name A, and two

Multipoint physical resources having the local distinguished name B. The global distinguished

names are always globally unique within their class, i.e. the Multipoint physical resource is

identified by a Node Identifier plus Multipoint physical resource Identifier..

MSTR-NREG (2016-09) 31

The scope of a Node may change, as new resources are terminated in the Node, new equipment is

installed, etc. It will be beneficial if the identifier of the Node does not change during this transition,

but for pure Nodes, this is up to the choice made by the telecom Operator for his convenience.

A Node may terminate several

Physical legs

Physical series

Physical branches

11.2 Cross-coupling sites

A Cross-coupling site is a Node where couplings may be established through use of Work orders.

Figure 11-9 Schema for Cross-coupling sites

A Node may contain one Cross-coupling site only. If you have multiple Cross-coupling sites, you

will have one Node for each. Each of these Nodes will need to be registered if you want to manage

the physical telecommunication network.

Figure 11-10 Relation between Cross-coupling sites and Nodes

MSTR-NREG (2016-09) 32

A Cross-coupling site may contain zero, one or more Exchanges.

A Cross-coupling site will contain semi-permanent connections and equipment. These may be

changed by issuing of Work orders.

The primary purpose of Work orders is to carry out provisioning of trails. However, Work orders

may also be issued for repair, installation of equipment, configuration of equipment, cross-

couplings etc.

A cross-coupling within a Cross-coupling site is typically made on the basis of a cross-coupling or

routing order. Hence, the cross-couplings are considered to be semi-permanent. Junctions which

contain permanent cross-couplings or permanently installed equipment only, are not Cross-coupling

sites. Note that this permanently installed equipment outside Cross-coupling sites may still be

subject to automatic surveillance by management functions.

The semi-permanent connections may be created manually by a technician or by software for

network element management. The cross-couplings may be provided by automated management,

e.g., in digital cross-connect or SDH network matrixes, or the cross-connect can be made manually

as in a fibre matrix. However, a Cross-coupling site typically may contain more than a single piece

of such Equipment items, and the individual Equipment item should not be registered as a Cross-

coupling site.

A Cross-coupling site may be

1. A junction box

2. A satellite

3. An earth station

4. A satellite

5. A mobile base station

6. A radio terminal station

7. A coast radio station

8. A transmission station

9. A switching center

If a multiplexer is placed at a site, then a Cross-coupling site is defined at this Node.

A satellite is defined as a Cross-coupling site if its configuration may be remotely controlled, which

is the normal case.

A radio reflector station may or may not be defined as a Cross-coupling site. We have experience

that some network planning tools make it most convenient to treat these as Cross-coupling sites, as

well.

Note that junction boxes are sometimes placed outside the cable ditch. Still they are treated as

Cross-coupling sites.

Control stations may be placed outside the main transmission route, but since they are connected to

the transmission network, they may be registered as Cross-coupling sites, as well.

The following items are not Cross-coupling sites:

An exchange

An address

A room for technicians

A building without transmission equipment

An organization unit

An office

A retailer shop

A local area

MSTR-NREG (2016-09) 33

Cross-coupling sites are needed for registering of the logical telecommunication network.

Cross-coupling sites cannot overlap, and one Cross-coupling site cannot have several Identifiers.

However, a Cross-coupling site may have one or more Local identifiers.

A Local identifier may be used internally by the Operator, or be used bilaterally between Operators,

when they both agree to do so.

The Local identifier was originally added to the ITU-T Recommendations for covering

identification by ATIS standards. The attribute may be used for other identification, as well. If so,

the value therein should be tagged somehow with information on the type of identifier, e.g. by use

of a prefix.

The Identifier is the only identification that shall be used between Operators when bilateral

agreements to use Local names are not made. So, use of the Identifier requires no prior agreement.

The Identifier of the Cross-coupling site is created by or on behalf of the Operator of the Cross-

coupling site. The Identifier is unique within the scope of this Operator.

The full identification of a Cross-coupling site will consist of CC of the Country, ICC of the

Operator, and the Identifier of the Cross-coupling site. If the information is given within a Country,

or within an Operator, information on this context may be skipped.

The next Figure shows a listing of Cross-coupling sites within ab Operator.

Country Operator Cross-coupling site

CC ICC Identifier

NOR. TELNOR. BERGEN1 .

BERGEN2 .

KRISTIANSAND1 .

OSLO1 .

OSLO1-1 .

OSLO1-2 .

OSLO1-3 .

OSLO2 .

Figure 11-11 Listing of Cross-coupling sites


CC ICC Identifier Local identifier

NOR. TELNOR. BERG1 . BERGEN1 .

BERG2 . BERGEN2 .

KRS1 . KRISTIANSAND1 .

OSL1 . OSLO1 .

OSL1-1 . OSLO1-1 .

OSL1-2 . OSLO1-2 .

OSL1-3 . OSLO1-3 .

OSL2 . OSLO2 .

Figure 11-12 Example use of Local identifiers

Identifiers of Cross-coupling sites shall not change during changes to the network. Also, if

ownership of the Cross-coupling site is changed, the Operator information shall remain unchanged.

The purpose of this rule is to avoid dependent changes through several Operators.

The impact of the previous paragraph is that the owner of a Cross-coupling site may be different

from the original owner, after whom, the site is identified. Therefore, the actual owner of the Cross-

coupling site is given in a separate reference to the owner Operator. This reference may by default

MSTR-NREG (2016-09) 34

be set to the same Operator as of the Cross-coupling site’s superior Operator. Later, this reference

may be changed.

Country Operator Cross-coupling site Owner

CC ICC Identifier ICC

NOR. TELNOR. BERG1 . TELIA . .

Figure 11-13 Example changed ownership

Note that the recommended data structure has no place holder for information on Managed service

partner of the Cross-coupling site. If this is needed, it will have to be added. The Managed service

partner may or may not be a recognized network Operator. A network Operator will need to own its

own network, and be recognized by the regulator.

If equipment and terminations from several Operators appear in the same Cross-coupling site, the

Identifier shall remain the same, and be assigned by the original owner of the site.

A Cross-coupling site may contain a reference to the Geographical area to which it belongs.

Country Operator Cross-coupling site Geographical area

CC ICC Identifier Identifier

NOR. TELNOR. BERG1 . BERGEN .

Figure 11-14 Example reference to Geographical area

A Cross-coupling site may contain a reference to the Address at which it is located.

A Cross-coupling site may have references to all Physical links being terminated at the site. See the

section on Physical links.

Information about Cross-coupling sites may be shared between several Operators. This is the reason

for having more strict control over this name space than of Nodes, which are managed by one

Operator only. The sharing of information can be just be due to that a Trail is terminated in the site,

or is routed through the site.

The Identifier of a Cross-coupling site is alphanumeric, and may have up to 18 characters. The

Identifier may start with the Name of the Geographical area, which can have up to 12 characters.

However, the Operator is free not to use this part. In other cases, the Operator defines Geographical

areas such that only this part is used. Or the Operator uses a combination of the Name of the

Geographical area and Site detail. Site detail may be up to 6 alphanumeric characters. The Name of

Geographical area plus Site detail may be put into one field, and may not need to be split on

separate fields.

For internal use within an Operator, a shorter field is often used for the Identifier, e.g. 6 or 12

characters. However, the full length of 18 characters may be needed for Identifiers of Cross-

coupling sites in other Countries or of other Operators. The use of shorter Identifiers may be due to

a wish of using less space on screens, e.g. for Trail Identifiers, which include Identifiers of both

terminating Cross-coupling sites.

If a short Identifier is used, a full length Identifier may be stored in a Local identifier.

Note that the ITU-T Recommendations are developed for communication between Operators in

different Countries, and are extended to cover communication between Operators in the same

Country. These usages typically involve Cross-coupling sites in the transport networks. However,

MSTR-NREG (2016-09) 35

an Operator may use the same data definitions for its access network, as well. If it gives a number to

each junction box, the 6 characters will allow for identification 1 million junction boxes. If letters

are used, as well, this will allow for much more identifiers.

In the transport network, the Identifier of a Cross-coupling site is independent of the Identifier of

any other Cross-coupling site, except that all Identifiers will need to be unique within the Operator

within this Country.

In the access network, it may be convenient to introduce some structure on the identifiers, as the

network is perceived to be a kind of tree, even if some connections deviate from the pure tree

structure. Hence,

a. A junction box may identified within the scope of the main distribution frame,

b. A junction box may be identified within the scope of its superior junction box,

c. A junction box may be identified within the scope of some superior junction box, not

necessarily the closest, or

d. A junction box is identified independently from other junction boxes

Figures 9.7 and 9.8 shows an example of use of the approach in bullet a.

All these approaches are in use by some Operators, despite the lack of a formal tree structure

between the Cross-coupling sites. Suffixes, maybe at several levels, are used to indicate this

informal tree structure. The Identifiers of the Cross-coupling sites are typically kept unchanged

even if the structure of the network is changed.

In the access network, some Operators add information on capacities to the Identifier of the junction

box, i.e. of the Cross-coupling site:

i. The Identifier of the main junction box may contain information on the main or first cable

going out to this site

ii. The Identifier of other junction boxes may contain information on the set of plinths or first

plinth having cables out to this site


CC ICC Identifier

NOR. TELNOR. BERG1 A101-150.

Figure 11-15 Example identification of main junction box


CC ICC Identifier

NOR. TELNOR. BERG1 A101-150 E15.

Figure 11-16 Example identification of other junction box

The two above example shows that more than 12 characters may be needed for the local Identifier.

We have seen up to 28 characters being used for the Cross-coupling site Identifier.

The Cross-coupling site allows termination of a Trail, e.g., in an exchange, at a subscriber's

premises or other. In case of termination of the Trail, e.g., at the subscriber's premises or in an

international transmission center, the Operator's network is considered to exist at one side of the

Cross-coupling site only, i.e., the Operator's network may not include the connection between the

Cross-coupling site and the customer's equipment.

The Cross-coupling site allows cross-couplings to route a Trail through that node, and the Cross-

coupling site allows cross-couplings between Trails within that Cross-coupling site. The cross-

MSTR-NREG (2016-09) 36

coupling may use internal equipment, termination points and internal Trails which are associated to

the routed Trail.

A Cross-coupling site cannot be geographically distributed over more than one building.

However, it is also permissible to define several Cross-coupling sites at the same Address.

In this case, separate Trails and other resources may be defined to route Trails between these Cross-

coupling sites at the same Address. You cannot do cross-couplings directly between resources in

different Cross-coupling sites. Hence, a Cross-coupling site states a capability of what may be

cross-coupled.

11.3 Multipoint physical resources

A Multipoint physical resource comprises all Physical branches which can be reached by passing

through pure Nodes without passing through any Cross-coupling site.

Figure 11-17 Schema of Multipoint physical resources

See on Physical branch in a subsequent section.

The Multipoint physical resource entity class may not be used in some implementations. However,

the notion may still be useful both to understand the network and to prescribe and understand the

registration of it.

A Multipoint physical resource is a kind of network domain that is defined from the topology of the

physical telecommunication network, and is not defined from any other administrative purpose.

Hence, all Multipoint physical resources can be found by studying the graph of the physical

telecommunication network.

The topology of a Multipoint physical resource may be a star, a ring or other.

Figure 11-18 Example Multipoint physical resources

MSTR-NREG (2016-09) 37

In the above Figure, the Multipoint physical resources (ellipses) are identified within their

immediately superior Cross-coupling site. The containment is shown in the following data instance

diagram.

Figure 11-19 Identification of Multipoint physical resources within immediately superior

Cross-coupling sites

In order to make the above Figure simple, we have not shown entity class and attribute labels, and

not Operator and Country.

Identification of a Multipoint physical resource using relative distinguished names is shown in the

following Figure.

Country Operator Cross-coupling site Multipoint physical resource


NOR. TELNOR. OSLO1-2. A .

Figure 11-20 Example identification of a Multipoint physical resource

If using global distinguished names, the identification may look as follows.

Multipoint physical resource


NOR. TELNOR. OSLO1-2. A .

Figure 11-21 Example identification of a Multipoint physical resource

In the old cable network of twisted pairs, we had constructions called ring cables and in-out cables.

In these constructions, the cable was opened up and a few pairs taken out and cut. Hence, these cuts

have to be managed within a Cross-coupling site. As many pairs will pass through untouched, we

will also consider the Multipoint physical resource to continue through these Cross-coupling sites.

Physical branches will end in the Cross-coupling site, but the site will not be the end of the

Multipoint physical resource, as it continues outside the Cross-coupling site. See also a subsequent

section on Physical links.

The definition of Multipoint physical resources implies that they may have to be redefined if the

topology is changed. For Cross-coupling sites, their Identifier remains unchanged if the Operator

changes. For Multipoint physical resources, the Identifier changes with changing topology, but

remains unchanged with changing Operators.

Multipoint physical resources are identified by an Identifier of up to 5 digits.

MSTR-NREG (2016-09) 38

The Multipoint physical resource is identified within the scope of a Cross-coupling site within an

Operator within a Country. The identification within the scope of a particular Cross-coupling site

reduces the number of items within the name space. Which Cross-coupling site to use is up to the

Operator to choose. Often, the network has a kind of tree structure, and the Operator choses a

Cross-coupling site that is immediately superior to the Multipoint physical resource, for example

a. The Cross-coupling site from where the Multipoint physical resource is going out

b. The main distribution frame

c. Or other

Here, as well, identifiers of Operator and Country may be left out when not needed.

The previous Figures illustrate identification according to bullet a. Here follows identification

according to bullet b.

Figure 11-22 Identification of Multipoint physical resources within the main distribution

frame

Figure 11-23 Instance diagram of Multipoint physical resources within the main distribution

frame

Identification of a Multipoint physical resource using relative distinguished names is shown in the

following Figure.

Country Operator Cross-coupling site Multipoint physical resource


NOR. TELNOR. OSLO1 . E .

Figure 11-24 Example local identification of a Multipoint physical resource

If using global distinguished names, the identification may look as follows.

MSTR-NREG (2016-09) 39

Multipoint physical resource


NOR. TELNOR. OSLO1 . E .

Figure 11-25 Example global identification of a Multipoint physical resource

Note that the previous examples are identifying the same resource as previously in this clause, but

now with a different identification approach, even if the entity classes and attribute classes are the

same.

Multipoint physical resources are not important for understanding and use of the network

information, but they are used for identification of Physical branches, Physical series and Physical

legs. And they give overview of which Physical links are implemented through these means. So, the

a Multipoint physical resource gives you a handle on a collection of closely related information,

which will be explained in subsequent sections.

When routing Trails, only the Physical links will be used out of these notions. The others are used

for implementing the physical network.

11.4 Physical legs

A Physical leg is the shortest parallel collection of connections between sites in the

telecommunication network. A Physical leg connects two Nodes.

Figure 11-26 Schema of Physical legs

A Physical leg is the collection of

1. Parallel connections within a cable

2. Parallel connections within a series of telephone poles

3. Parallel connections between two radio terminal or link stations

4. Parallel connections between an earth station and a satellite transponder

Note that if cables are hanged up in telephone poles, each cable is considered to be a separate

Physical leg.

Connections from a base station to the customer’s mobile equipment are not Physical legs, and are

not contained in Physical legs. Curled up cables, which are not terminated in the other end, are not

Physical legs.

MSTR-NREG (2016-09) 40

Figure 11-27 Example Physical legs

A Physical leg may be

A coil section

A regenerator section

An amplifier section

A connection between branching nodes

A radio hop between antennas, or reflectors

A hop up to or down from a satellite

A termination cable, as full size cables may not go to the termination rack

One out of more smaller cables that are used to prolong a large cable

From the above, a Physical leg comes from one cable drum, and cannot come from two drums. So a

Physical leg is a technological unit that is used as a topological entity. When the cable is on the

drum, or is not terminated in Nodes in both ends, it is not a Physical leg.

A Physical leg is always terminating in two Nodes.

Between two Nodes there may be several parallel Physical legs.

Many Physical legs may branch out from the same Node. There may not be connections between all

Physical legs out of a Node. However, the Nodes may also just provide connections between two

Physical legs, without any branching. And the Node may only have one Physical leg, and is thus

terminating the network, like a junction box at the subscribers’ premises.

Physical legs are identified by an Identifier within the scope of their Multipoint physical resource.

The Identifier may have 4 characters.

Cross-coupling site Multipoint physical resource Physical leg

Identifier Identifier Identifier

OSLO1 . E . 1 .

Figure 11-28 Identification of a Physical leg

A Physical leg may have a reference to the Physical series to which it belongs.

MSTR-NREG (2016-09) 41

Figure 11-29 Example schematic graph of Physical legs

Figure 11-30 Data instance diagram of the example schematic graph

In the above figure, entity and attribute classes are not shown. The lower part shows Multipoint

physical resources. The upper part shows Physical legs and their terminations in Nodes.

The Identifier of the Physical leg is independent of the Physical series, but some Operators chose to

identify the Physical legs within the Physical series within the Multipoint physical resource of

which they both belong.

So, if the Physical series is identified by the letter a within a Multipoint physical resource, then the

Physical legs may be identified by a1, a2 etc. in the same Multipoint physical resource. See a

subsequent section on Physical series.

Cross-coupling site Multipoint physical resource Physical leg


OSLO1 . E . a1 .

Figure 11-31 Identification of a Physical leg

11.5 Physical series

A Physical series is a series of Physical legs between two branching Nodes or to a terminating

Node.

MSTR-NREG (2016-09) 42

Figure 11-32 Schema of Physical series

A Physical series contains one or more Physical legs, and the Physical series may contain references

to these Physical legs.

Figure 11-33 Example Physical series

To register the network down to the details of Physical legs may be very time consuming.

Therefore, the Operator may choose to register the detailed topology only. This is accomplished by

registering Physical series.

A Physical series may go between

Two Nodes that contain Cross-coupling sites, and never through a Cross-coupling site

Two branching Nodes

One Node containing a Cross-coupling site, and a branching Node

MSTR-NREG (2016-09) 43

Figure 11-34 Example Physical legs within Physical series

In the above Figure, the Physical series are depicted in the lower part. They are contained in

Multipoint physical resources, and have references to Physical legs. The Identifiers of the Physical

legs contain the Identifier of their Physical series. Therefore, we have not depicted the references

between Physical series and Physical legs. We have duplicated the Nodes into the lower part, to

show termination of the Physical series in Nodes, without creating a lot of lines to the upper part.

A Physical series may additionally terminate in a Node where the technology is changed. This Node

may not be a branching Node, and may not contain a Cross-coupling site.

Note that terminating cables, and parallel cables that prolong larger cables, are registered as

separate Physical series. So by registering Physical series, all the topology is registered, but some of

the technical details are left out.

Physical series are identified by an Identifier of maximum 3 characters within a Multipoint physical

resource. Note that a Physical series will never pass through more than one Multipoint physical

resource.

Cross-coupling site Multipoint physical resource Physical series


OSLO1 . E . a .

Figure 11-35 Identification of a Physical series

MSTR-NREG (2016-09) 44

The Physical series will additionally have a reference to a Physical branch. Some Operators may

use its identification as a part of the Identifier of the Physical series. Suppose the Physical branch is

identified by an A within its Multipoint physical resource, and the Physical series by an a, then the

full Identifier of the Physical series become Aa within that Multipoint physical resource.

The approach used in the previous paragraph may be extended to cover Physical legs as well. Their

Identifier may then have the value Aa1 within the Multipoint physical resource.

11.6 Physical branches

A Physical branch is the greatest collection of Physical series and Physical legs in series or parallel

between two branching Nodes, or to a terminating Node.

Figure 11-36 Schema of Physical branches

The Physical branches give an overview of the branching of the physical network between Cross-

coupling sites without going into details. The terminating Nodes are leaf Nodes of the network, and

will contain a Cross-coupling site. The branching Nodes may or may not contain a Cross-coupling

site.

In the Figure below, there is a one-to-one correspondence between Physical branches and Physical

series, but in general the relation is one-to-many, as Physical series show a more detailed structure.

A Physical series is implemented by physical cable sections in series. A Physical branch may

contain several Physical series in parallel between two nodes. Physical series may create a mask

network between Cross-coupling sites, while Physical branches create a star network.

Figure 11-37 Example Physical branches

MSTR-NREG (2016-09) 45

A Physical branch may contain references to the Physical links which are routed on this Physical

branch. Note that there may be several parallel Physical links on the same Physical branch using

different Branch connections. See a separate section on Physical links.

A Physical branch may contain references to Physical series in parallel or series which implement

the Physical branch.

Note that parallel Physical series between two Nodes are grouped into the same Physical branch.

Also, series of Physical series may be grouped into the same Physical branch.

A Physical branch is identified by an Identifier of up to 2 characters within a Multipoint physical

resource.

The Operator is free to assign values the way it wants to its Physical branches, Physical series and

Physical legs in a Multipoint physical resource. Some Operators chose to make these Identifiers

dependent on each other:

e.g. A for a Physical branch

e.g. Aa for a Physical series in that Physical branch

e.g. Aa1 for a Physical leg in that Physical series

Cross-coupling site Multipoint physical resource Physical branch


OSLO1 . E . A .

Figure 11-38 Identification of a Physical branch

11.7 Leg connections

A Leg connection is a set of one or two parallel connectors which are meant to be used together to

implement a Trail through a Physical leg.

Figure 11-39 Schema of Leg connections

A Leg connection may be a twisted cable pair.

A Leg connection may be a coax tube having an inner and an outer connector.

For a radio link, a Leg connection may be the termination point on a wave guide to the antenna.

MSTR-NREG (2016-09) 46

Figure 11-40 Example Leg connections with cross-couplings

Note that the references for cross-couplings shown in Figure X can be very tedious to establish if

they are done by hand one-by-one. A proper software tool can put in a series of such references in

one operation.

Leg connections are identified by an identifier of maximum 4 characters within a Physical leg. The

Identifier is numeric, 1, 2, 3 etc.

Cross-coupling site Multipoint physical resource Physical leg Leg connection

Identifier Identifier Identifier Number

OSLO1 . E . a1 . 1 .

. . . 2 .

. . . 3 .

Figure 11-41 Identification of a Leg connections

There may be a cross-coupling between two or more Leg connections belonging to Physical legs

being terminated in the same Node. The cross-coupling is represented by references between the

Leg connections.

If some Leg connections of a Physical branch are terminated, i.e. being cut, in the Node, then all

Leg connections of the Physical branch are considered to be terminated, and need to be represented

as cross-connections by references, even if the Leg connections are just rolled through the Node.

11.8 Series connections

A Series connection is a series of one or more connected Leg connections through a Physical series.

MSTR-NREG (2016-09) 47

Figure 11-42 Schema of Series connections

Series connections are identified by an Identifier of maximum 4 characters within a Physical series.

The Identifier is numeric, 1, 2, 3 etc.

All Series connections within a Physical series are considered to be terminated and possibly cross-

coupled in the same two Nodes.

Figure 11-43 Example Series connections

A Series connection may contain references to all Leg connections that implement the Series

connection.

A Series connection may contain a reference to the Branch connection to which it belongs.

Cross-coupling site Multipoint physical resource Physical series Series connection


OSLO1 . E . a . 1 .

. . . 2 .

. . . 3 .

. . . 4 .

Figure 11-44 Identification of a Series connections

MSTR-NREG (2016-09) 48

11.9 Branch connections

A Branch connection is a series of one or more connected Series connection through a Physical

branch.

Figure 11-45 Schema of Branch connections

A Branch connection may contain references to the Physical link connections which are routed on

this Branch connection. In case there is no Multipoint resource connection, the reference is to only

one Physical link connection.

Figure 11-46 Example Branch connections

Branch connections are identified by an Identifier of maximum 4 characters within a Physical

branch. The Identifier is numeric, 1, 2, 3 etc.

All Branch connections within a Physical branch are considered to be terminated and possibly

cross-coupled in the same two Nodes.

A Branch connection may contain references to all Series connections that implement the Branch

connection.

A Branch connection may contain a reference to the Link connections to which it belongs.

MSTR-NREG (2016-09) 49

Cross-coupling site Multipoint physical resource Physical branch Branch connection


OSLO1 . E . A . 1 .

. . . 2 .

. . . 3 .

. . . 4 .

Figure 11-47 Identification of a Branch connections

11.10 Multipoint connections

A Multipoint connection is a tree, star or network of one or more Branch connection through a

Multipoint physical resource.

A Multipoint connection is terminated at three or more Cross-coupling sites. A Multipoint

connection is not terminated at two sites only. Multipoint connections are typically designed to

allow for multiplexing such that different channels are terminated at each site.

Multipoint connections are not covered by our data structure for the physical network domain, as

similar functionality may be obtained by appropriate use of Multipoint Trails within the logical

network domain.

Multipoint connections are, if registered, identified by numbering within the scope of the Multipoint

physical resource to which they belong.

12 Logical Network Domain between Cross-coupling sites

12.1 Site relationships

A Site relationship is a combination of exactly two Cross-coupling sites. The two Cross-coupling

sites may be different or the same. The last case is used in case of identification of internal Trails

within a Cross-coupling site.

Figure 12-1 Schema of Site relationships

A Site relationship between two Cross-coupling sites is created if there exist or is planned Physical

links or Trails between the two sites.

MSTR-NREG (2016-09) 50

Figure 12-2 Example Site relationships

The Site relationship is used as a mandatory part of the identification of Trails and Physical links.

Hence, they are essential for registration of Trail multiplex channels and of Physical link

connections. Also, Site relationships provide overview of these resources between the two Cross-

coupling sites.

An Identifier of a Site relationship is an attribute group that uniquely identifies the Site relationship.

The scope of the identification may be global in case of international Trails, which means that all

fields are required to be filled in. The scope may be a Country in case of inter-operator Trails within

that Country, which means that the two Country Codes may be left out. The scope may be the

Operator in case of intra-operator Trails, which means that the two ICCs may be left out, and only

the two Cross-coupling site Identifiers are filled in.

The Identifier of a Site relationship is an attribute group that uniquely identifies the Site

relationship. The attribute group is defined as follows:

Identifier

A-end

The A-end of the Identifier is an attribute group uniquely identifying the Site relationship's

subordinate A-end site.

o Country Code

Country Code identifies (recursively superior) Country of the Site relationship's A-

end site.

o ICC

ICC identifies the (superior) Operator of the Site relationship's A-end site.

o Site

Site contains the Identifier of the Cross-coupling site referenced by the Site

relationship's A-end site.

B-end

The B-end of the Identifier is uniquely identifying the Site relationship's subordinate B-end

site.

o Country Code

Country Code identifies (recursively superior) Country of the Site relationship's B-

end site.

o ICC

ICC identifies the (superior) Operator of the Site relationship's B-end site.

o Site

Site contains the Identifier of the Cross-coupling site referenced by the Site

MSTR-NREG (2016-09) 51

relationship's B-end site.

Figure 12-3 shows the Site relationship Identifiers. A dash separates a A-end and B-end parts.

Figure 12-3 Site relationship Identifiers

Additionally, a Site relationship may have a Local identifier.

Within the Identifier, the two Site-s are given in alphabetical sequence. Country Code and ICC

come with each Site Identifier, independently of alphabetical sequence. Note that these sequences

are independent of transmission directions or traffic directions of resources within the Site

relationship. Use of the alphabetical sequence gives a clear guidance on the writing, such that no

uncertainty can appear.

Aliases of Cross-coupling site Identifiers are not permitted for communication between Operators

of different Countries. However, Operators may exchange Local identifiers that are local to a

specific Operator, country or region.

A Local identifier is specific to an Operator, country or region. Such use of Local identifiers would

be subject to national regulation and/or bilateral agreement between Operators, as stated in ITU-T

Rec. M.1400.

Local identifiers have a similar structure as of Identifiers, but the content is different.

The Site relationship Identifier contains the Identifiers of the two Cross-coupling sites which it

relates. In addition, Site relationship contains references to the same two Cross-coupling sites.

These references may be derived automatically from the Identifier of the Site relationship.

A Site relationship may contain lists of all Physical links and Trails contained in the Site

relationship, and the Site relationship Identifier is used to create global distinguished names of

these. Also, the Site relationship may contain information on free Link connections, capacity, faults

etc. Hence, the Site relationships are used to find resources and navigate through the Logical

network domain. See more on the contained entity classes in subsequent sections.

The following Figure shows a global distinguished name of a Site relationship.

Site relationship

Identifier

A-end B-end


NOR. TELNOR. OSLO1-2. NOR. TELNOR. OSLO1-5.

Figure 12-4 Global distinguished name of a Site relationship

MSTR-NREG (2016-09) 52

And the following Figure gives a relative distinguished name:

Site relationship

Identifier

A-end B-end

Identifier Identifier

OSLO1-2. OSLO1-5.

Figure 12-5 Relative distinguished name of a Site relationship

12.2 Physical links

A Physical link represents a set of parallel physical transport resources between two Cross-coupling

sites. The physical transport resources are called Physical link connections.

Figure 12-6 Schema of Physical links

All Physical link connections in a Physical link shall be routed in the same Physical branches. A

Physical branch connects either two Cross-coupling sites or two junctions where the pairs of the

Physical branch are split into pairs of Physical branches leading to two or more different Cross-

coupling sites. Physical branches represent one layer of the physical network, and Physical links

represent the layer at which resources are allocated to route Trails of multiplex groups or other

usages.

Figure 12-7 Example Physical links

MSTR-NREG (2016-09) 53

A Physical links is identified within its respective Site relationship, being depicted in Figure 12-7.

A Physical link is terminated in exactly two Cross-coupling sites, which allows for termination of

Physical link connections and cross-couplings between Physical link connections. A Physical link

cannot terminate in a junction that requires construction work to provide the couplings.

Note that attributes of physical resources are different from attributes of logical resources and Trail

notions.

In the above Figure, we see that there are not as many Physical links as of Site relationships, as

some of the Site relationships are for Trails. It is not illustrated in the Figure, but there may be

several parallel Physical links between two Cross-coupling sites.

A Physical link is using some Branch connections in a series of Physical branches. More than one

Physical link may use different Branch connections in the same Physical branch. Hence, the

mapping between Physical links and Physical branches is many-to-many.

Figure 12-4 Schema of references between Physical links and Physical branches

Figure 12-5 Example references between Physical links and Physical branches

MSTR-NREG (2016-09) 54

The Identifier of a Physical link uniquely identifies the Physical link within the Site relationship.

The Identifier may have maximum 12 alphanumeric characters.

Note that Physical links are identified independently from Trail Identifiers within the same Site

relationship. This allows cable and radio resources to be identified independently from Trails and

the concerns of customers in the use of Trail Identifiers. Hence, a Physical link Identifier and a Trail

Identifier may look the same, but will identify different entities.

The following Figure gives a relative distinguished name of a Physical link:

Site relationship Physical link


A-end B-end


OSLO1-2. OSLO1-5. 1 .

Figure 12-6 Relative distinguished name of a Physical link

The above identification scheme may work fine for the transport network. However, for the

transport network much less than 12 characters are needed for the Identifier, as most often there are

very few Physical links between two Cross-coupling sites. Hence, 2 or 3 characters may be

sufficient.

The identification challenges are different for the access network. Here, often the Physical link is

given the same Identifier as of the Cross-coupling site it terminates in. So, rather than 1 in the above

example, the Physical link Identifier would be OSLO1-5. This Identifier is identical to the Identifier

of the B-end. Therefore, the relative distinguished name of the Physical link may in this case be

reduced to:



A-end

Identifier

OSLO1-2. OSLO1-5.

Figure 12-7 Relative distinguished name of a Physical link in the access network

Now, there may be several parallel Physical links from one site out to another. As long as the

Physical link is given a unique Identifier within the scope of the A-end, the same naming scheme as

in the previous Figure may be applied.

In general, if different technologies are used between the same two Cross-coupling sites, e.g. a radio

connection, symmetrical pairs, coax connections and optical fibres, they are all defined as different

Physical links, even if some of them may appear in the same cable.

Some Operators define a Physical link to correspond to the blocks on which the pairs are terminated

in both ends. They then assign the block number in the A-end as part of the Identifier of the

Physical link.

MSTR-NREG (2016-09) 55



A-end

Identifier

OSLO1 A101-150. B17 .

Figure 12-8 Relative distinguished name of a Physical link in the access network

If the first Physical link to be terminated at the B-end is B15, then the full relative distinguished

name will be



A-end B-end


OSLO1 A101-150. OSLO1 A101-150B15. B17 .

Figure 12-9 Full relative distinguished name of the Physical link

ITU-T Recommendation M.1401 does not talk about Local identifier for Physical link, but we think

that this should be allowed.

In the above example, several Physical links are defined through the same Physical branch. Hence,

in this case, the mapping between Physical links and Physical branches need to be many-to-many.

Note that every Physical link has a direction, given by the Site relationship, where the A-end

Identifier comes first in the alphabet. This also applies for a connection between two sites at the

same level of the network. Hence, neither the transport nor the access network needs to have a pure

hierarchical star structure.

Different Operators use different conventions for identification of their Physical links. Some use

very long Identifiers, as indicated with the access network examples; others may do with much less.

The next example depicts two earth stations having satellite communication to an oil rig.

Figure 12-10 Satellite communication between earth stations

The two earth stations, the oil rig and the satellite are all represented as Cross-coupling sites. Hence,

they are all connected by Physical links.

MSTR-NREG (2016-09) 56

Figure 12-11 Physical links connecting Cross-coupling sites

In-out cables is an old use of cables, where one cable may be rolled out up a valley from an

exchange. Junction boxes are placed along the cable, but only some pairs are taken into the box at

each site. If there is no customer connected to the pair, it continues through the junction box. If

there is a customer, the pair is cut, and the customer is connected to it. If there is one more

customer, he is connected to the end continuing up the valley. At the end of the cable, the first half

of the pairs is connected to the other half. Hence, each unused pair is forming a ring. When cut, you

have two pairs back to the exchange. One connection takes the shortest route. The other takes the

longest route.

Figure 12-12 Depiction of an in-out cable

An in-out cable is best represented with one Physical branch between each two Nodes. The Physical

branch contains Branch connections for each pair in the cable. Before customer Trails are added, all

Branch connections are cross-coupled as described in the previous paragraph.

The Operator may define a Physical link for each Physical branch, and a Physical link connection

for each Branch connection. And the cross-couplings in the Cross-coupling sites will be similar to

that of the Nodes. Software may help to generate and copy the cross-couplings, such that not all

have to be inserted by hand. This representation of the network will be very flexible to use, but will

be difficult to overview and manage. Every customer Trail will have to be routed on a series of

Physical link connections.

MSTR-NREG (2016-09) 57

Figure 12-13 Representation of a tapped cable

An alternative representation is to define a Physical link from the exchange to the Cross-coupling

site where the pairs are to be used. There will be one Physical link for the short path, and one

Physical link for the long path. In this case, each customer Trail will be routed on one Physical link

connection only. This representation will be easier to overview and use. But it will not be as flexible

as the first alternative, as the contents of Physical links will have to be redefined if the pairs are

used differently from what was planned.

Figure 12-14 Alternative representation of a tapped cable

Note that each pair may be used in both directions, and the other half of the pairs may be in-out, as

well, even if this is not shown in this example.

In the alternative representation, no usage of the pairs is planned in the junction box to the right, so

it may not be defined as a Cross-coupling site. Two pairs are planned to be used in the first junction

box to the left, one in the second and one in the third.

Ring cable is an old use of cables, which is similar to in-out cables. Here a cable is rolled out in a

ring from an exchange throughout a town and back to the same exchange. Here, all pairs are in-out,

and not the half of them, as of in-out cables.

Figure 12-15 Depiction of a ring cable

MSTR-NREG (2016-09) 58

The representation considerations are similar to that of in-out cables. The purpose is efficient use of

the cable pair resources. When using modern technology, the same goal is achieved by using

multiplexing of multipoint Trails, as of SDH hierarchies.

12.3 Physical link connections

A Physical link connection represents a physical resource between two Cross-coupling sites and can

be allocated to a single Trail. The resource may represent a single fibre, a pair, a set of two pairs or

other, which is planned to be used as a section of a Trail.

Figure 12-16 Schema of Physical link connections

A Physical link connection is implemented as a series of one or more Branch connections.

Some Trails require more than one Physical link connection in parallel, e.g. one for sending, one for

receiving, and one for signalling. In these cases, the Trail has to be split into parallel Trails, like

when doing multiplexing, and each of the parallel Trails is routed on a series of Physical link

connections. See more on this under Trails.

Some Operators avoid registering the parallel Trails by skipping registration of the parallel Physical

link connections. Hence, they register only the lowest number of the used Physical link connections,

e.g. 1, 4, 7 etc.

MSTR-NREG (2016-09) 59

Figure 12-17 Schema of references between Physical link connections and Branch connections

Figure 12-18 Example Physical link connections

All Physical branch connections are cross-coupled in the pure Node at the left hand side of the

above Figure. Therefore, they all result in Physical link connections. But only, only two to two

Physical branch connections are cross-coupled in the pure Node at the right hand side of the above

Figure. Therefore, these result in two Physical link connections only.

The next Figure shows an instance diagram the Physical link connections in their proper Physical

links.

MSTR-NREG (2016-09) 60

Figure 12-19 Example instance diagram of Physical link connections

The upper part of the above Figure shows Site relationships and their terminations in Cross-

coupling sites. The Identifier of the Site relationship is shown with a comma between the A-end and

B-end. In the middle of the Figure, we see Physical links contained in their respective Site

relationships. At the bottom of the Figure, we see Physical link connections and their cross-

couplings.

A Physical link connection is identified by a Number within the Physical link. The Number has

maximum 4 digits.

Site relationship Physical link Physical link connection

Identifier Identifier Number

A-end B-end


OSLO1-2. OSLO1-5. 1 . 4 .

Figure 12-20 Relative distinguished name of a Physical link connection

The Physical link connection may consist of two connectors. The data structure does not cover these

connectors. In case they need to be registered, they are each treated as one Physical link connection,

and are given suffixes like 4a and 4b.

Some incumbent Operators have an old network of symmetrical cable pairs. Occasionally, two

connectors from different pairs are used together, maybe because there are faults on the other

connectors. In this case, one Trail is routed on each connector, and the two Trails are grouped as if

using multiplexing.

MSTR-NREG (2016-09) 61

Some Operators may also have cases where one pair is split in a pure Node, and is terminated in

two or more Cross-coupling sites. This is called a tapped cable, even if the tapping is only applied

for some of the pairs. A Physical link connection is registered to each Cross-coupling site, and

Multipoint trail is registered to cover a Trail on each Physical link connection. See more on this

under Multipoint trails.

12.4 Trails between Cross-coupling sites

In this clause, we will define Trails between Cross-coupling sites. In a later section, we will

additionally define Trails within Cross-coupling sites.

A Trail provides a transport of signals between two Cross-coupling sites. The Cross-coupling site

Positions may be located in Cross-coupling sites within different Countries, by different Operators,

the same Operator, or within one and the same Cross-coupling site – in case of internal Trails. Also,

the Trail may be terminated at the customer premises, i.e., outside the Cross-coupling site.

Figure 12-21 Schema of Trails

The Trail may be routed via several connected Cross-coupling sites. The routing and involved

cross-couplings of the Trail are established on a semi-permanent basis based on a cross-coupling

order. However, switching to alternate Trails may be provided dynamically. See the section on

Associations.

A Trail may be routed on other Trails, e.g., each Operator may define a separate Trail Identifier for

the routing within its domain, while a common inter-operator Trail is defined for the total routing.

Also, the detailed routing within a Cross-coupling site may be defined in a separate internal Trail.

A Trail may be involved as a part of a multipoint Trail, e.g., a ring. In this case, no Trail should be

defined to pass the branching points. However, Trails routed on subordinate Trail multiplex

channels may be routed through the branching points. These last Trails are illustrated in the section

on Multipoint trails.

Multipoint trails may also be used to represent Multipoint physical resources. See both these

sections.

A Trail may be multiplexed into several parallel Trail multiplex channels.

The Trail may be established as a means to configure the Operator's network or be established to

provide a service or product to a customer.

The Trail may provide:

MSTR-NREG (2016-09) 62

a transmission system functionality, e.g., a coax system between two pieces of line

termination equipment;

a multiplex group capacity, e.g., an SDH link;

a reserve functionality, e.g., an alternate routing for a multiplex group;

a traffic capacity, e.g., for routing of traffic between two (neighbour) Exchanges;

a user functionality, e.g., a leased line between two customers.

Note that Trails are semi-permanent, which means that Trails do not comprise temporary dialled

circuits, which directs traffic over a series of Trails. Also, Trails are not permanent cable resources

between two (neighbour) junction boxes. Dialled circuits are switched dynamically, and cable

resources are installed permanently. Dialled circuits are established on the basis of a call attempt per

call, per file transfer or per packet and are not established based on a coupling order. Cable

resources are established based on construction plans and not on coupling orders.

Trails are identified within Site relationships. The Identifier may have up to 12 alphanumeric

characters. ITU-T Recommendation M.1400 provides detailed guidelines for design of this

Identifier for international Trails and national Trails between Operators. An Annex of the

Recommendation shows all recommended Function codes to be used in the Identifiers.

Site relationship Trail


A-end B-end


FRA. FRTE. PARIS/BA. GBR. TBTPLC. LONDON/KB. Z21 .

Figure 12-22 Identification of an international Trail

For internal Trails within an Operator, the Operator is free to choose his own conventions, both for

the transport and the access network. Several Operators use only a serial number, or they use

different number series for different kinds of Trails.



A-end B-end


OSLO1. OSLO1-5. 1 .

Figure 12-23 Identification of a national Trail

Note that for Trails, the B-end is required, and cannot be suppressed, like for Physical links.

Note that the Identifier of the Trail's superior Site relationship is independent of the identifiers of

the Exchanges, Locations or Equipment in which the Trail is terminated.

Note also that the Identifier of the superior Site relationship is independent of traffic or transmission

direction of the Trail.

The Identifier is local to the Site relationship. However, when communicating with Business

Support Systems (BSS) within the Operator organization, it may be inconvenient to communicate

Site relationships. Therefore, a number that is globally unique within the Operator may be used as

the Identifier. Typically, this number is used for private leased lines and for fixed line phone

service. In the Operation Support Systems (OSS), the Site relationship is added to this Identifier.

MSTR-NREG (2016-09) 63



A-end B-end


OSLO1. OSLO1-5. 9876543100 .

Figure 12-24 Identification by use of a global number

Note that the term “global” in the title of Figure 22.4 only means globally unique within the

Operator, and does not mean “worldwide”.

Trail

Identifier

9876543100 .

Figure 12-25 Identification for communication with BSS

In addition to the above, a Trail may have a Local identifier. Trails being managed by Network

Element Managers will have identifiers which are different from the M.1400 identifiers, as being

described above. Therefore, two identifiers are needed. Sometimes the other identifier can be

derived automatically; sometimes not.

If a private leased line is going between countries or between Operators, the Operator may use the

global number for the local part, and the standardized Identifier for the international and inter-

Operator part.

Figure 12-26 Routing of three Trails on Physical link connections

Note that in the previous Figure there may be more than three Trails, as some Trails may contain

only one Physical link connection, or be internal to a Cross-coupling site. Hence, you cannot from

this topology see what is a Trail. You may also need to know the usage in order to decide if there is

a Trail or not.

MSTR-NREG (2016-09) 64

Figure 12-27 Depiction of the three Trails

The above Figure shows that a Trail is terminated in two Cross-coupling sites. For internal Trails,

the two sites are one and the same.

A Trail may contain zero or several Trail multiplex channels in parallel.

A Trail may contain a series of Trail sections, which specifies the routing of the Trail.

A Trail may itself be a Trail section of some other Trail.

A Trail may be terminated at Positions in Locations in Cross-coupling sites.

A Trail may have Terminations in Cross-coupling sites; these Terminations may tell about

transmission direction.

A Trail may have Associations to other to other Trails, e.g. about reserves. The Associations have a

direction; therefore, they are superior Associations and Subordinate associations. A Trail may be

involved in several Associations.

A Trail may have several Controllers listed in falling priority. Note that Controller indicates

responsibility for maintenance and not ownership.

See more on these topics in subsequent sections.

12.5 Terminations

A Trail's Termination indicates termination in a Cross-coupling site. A Trail will normally have two

Terminations.

Figure 12-28 Schema of Terminations

MSTR-NREG (2016-09) 65

A Termination associates the Trail with a Cross-coupling site. The termination states nothing about

terminations at Positions or Port items in this site. A Trail has zero, one or two Terminations.

Note that a Trail is terminated in two ends. The Termination entities relate the Trail to two Cross-

coupling sites, but the Trail may continue to a customer outside these Cross-coupling sites. Also,

the Trail may only be a Trail section of a longer Trail. Hence, in the ends of the current Trail there

may be cross-couplings to other Trails, Trail multiplex channels, Physical link connections or Port

items.

A Termination has no separate identification. A Termination is found by combining the identifiers

of the Trail and the Cross-coupling site.

A Termination's Direction indicates transmission direction of the Trail. The Direction can be

S(ender), R(eceiver) or T(wo-way). If the Direction is S(ender), then the Direction of the other

Termination is R(eceiver) and vice versa. If the D(irection) is T(wo-way), then the Direction of the

other Termination is T(wo-way), as well.

The following Figure shows example Terminations of a Trail.

Trail

Identifier

9876543100 .

Termination Cross-coupling site

Direction Identifier

T OSLO1

T OSLO1-5

Figure 12-29 Example two-way Termination of a Trail

12.6 Multipoint trails

A Multipoint trail is a connected set of Trails that are connecting three or more endpoints. A

Multipoint trail can reside within one Cross-coupling site, or it may connect two or more Cross-

coupling sites.

Figure 12-30 Schema of Multipoint trails

MSTR-NREG (2016-09) 66

The Identifier of a Multipoint trail uniquely identifies the Multipoint trail within the scope of an

Operator. This means that if the resources of a Multipoint trail are shared between Operators, each

Operator may create its own Multipoint trail and assign its own Identifier to its Multipoint trail.

This scheme is different from Identifiers of Trails within the Multipoint trail, as they are identified

locally to Site relations.

If the two Operators share a Multipoint trail, they are likely to share some of its Trails. These Trails

will have to be identified according to agreed standards, while the Trails local to each Operator may

not. However, use of channels within shared Trails will have to be coordinated and agreed among

the Operators.

The Identifier of a Multipoint trail may have up to 26 alphabetic and/or numeric characters. Some

Operators use the identifier of one of the contained Trails as the identifier of the Multipoint trail.

But note that these are two different entities, each belonging to a different entity class.

A Local identifier is specific to an Operator, country or region. Such use of Local identifiers would

be subject to national regulation and/or bilateral agreement between Operators, as stated in ITU-T

Rec. M.1400.

A Multipoint trail's will have references to one or more Trails being contained in it.

A Multipoint trail may have any structure of Trails, such as trees, stars and rings. The Trails tell

what end points are connected for signalling. Hence, given a Multipoint trail, you cannot deduce the

Trails from its topology. The Trails come from usage, and are implemented by filtering and

multiplexing within the Multipoint trail.

We will now depict a tapped cable. This topic was already introduced in the section on Physical

links.

The top part of the following Figure depicts a cable network between an exchange and two junction

boxes. Two pairs in these cables are tapped, such that they both go to both junction boxes. This is

not shown in this part of the Figure.

The second part is a schematic graph of Physical branches and Physical links for this network.

The third part depicts the implementation of Link connections with the couplings within the pure

Node.

The fourth part depicts the Physical link connections. The two cable pairs become four Physical link

connections if each connection may be used in both Cross-coupling site.

The bottom part depicts the Trails, and since they are branching off to two sites, the four Trails are

grouped into two Multipoint trails.

We could further elaborate on this example, by splitting the Trails into Trail multiplex channels and

let each terminate in one junction box only. However, it is the Multipoint trail which provides the

overview of which channels are used where. So if the channel characteristics are stated on the Trail,

the Trail multiplex channels are not needed in this case.

MSTR-NREG (2016-09) 67

Figure 12-31 Representation of a tapped cable

The Multipoint trail notion may be used to indicate network structures, such as SDH rings, where

resources have to be seen together when being managed.

The next example shows an SDH ring. The top part of the next Figure depicts the ring.

The bottom part depicts its representation.

The ring is represented as a Multipoint trail. Each connection between two neighbour termination

points is defined as a Trail. Figure 12-32 shows eight Trails in the Multipoint trail.

You may define Trail multiplex channels in each Trail.

Figure 12-32 Representation of a SDH ring

MSTR-NREG (2016-09) 68

The next Figure depicts the Trails being used in the SDH ring. The Figure shows six Trails. In

principle, they are independent and are not parts of a Multipoint trail.

Figure 12-33 Trails being used in the ring

SDH rings typically have 100% reserves, with the reserve being routed in the opposite direction via

the ring. See this in the section on Associations.

The next Figure shows a WDM configuration. Here also, Multipoint trails represent the structure

that will have to be managed as one whole.

Figure 12-34 WDM structure

We will represent this WDM structure as a Multipoint trail, as shown in the next Figure.

Figure 12-35 Multipoint trail

Each Trail being contained in the Multipoint trail will have a set of Trail multiplex channels. See

next clause. The Multipoint trail tells that if some other Trail is routed on a series of channels

through the structure, the same channel cannot be used of another trail along parts of the same

route. But the same channel may be used along a route that has no overlap with the first one. For

managing this, we propose to extend M.1401 with Multipoint trails containing Multipoint trail

MSTR-NREG (2016-09) 69

channels. We propose two Multipoint trail channels for each channel, e.g. 1a and 1b. If one of them

is taken, the other may be used, if their routings are disjoint. Hence, each are routed on Trail

multiplex channels no 1 in different Trails and Equipment items.

The Multipoint trail channels within the Multipoint trail give a complete overview of its channels

and use. All these potential channels could be defined in each Trail contained in the Multipoint trail.

It seems to be a better practice to define only those trail multiplex channels being used in each Trail.

12.7 Trail multiplex channels

A Trail may be split into several parallel Trail multiplex channels. The Trail multiplex channels in a

Trail may have different capacities. All Trail multiplex channels in a Trail have the same routing, as

the routing is assigned to Trails only, and not to Trail multiplex channels.

Figure 12-36 Schema of Trail multiplex channels

Each Trail multiplex channel is terminated in the same multiplex Equipment item as of the superior

Trail. The Trail may be terminated at the higher capacity side of the Equipment item, while the

Trail multiplex channels are terminated at the lower capacity side. Also, Trail multiplex channels

and Trails may be terminated at connection termination points or Trail termination points inside the

Equipment item, as may be the case in SDH network matrixes.

Trail multiplex channels may be implemented by different technologies, like frequency

multiplexing, pulse code multiplexing, etc.

Trail multiplex channels are numbered within their superior Trail. The identifier is a 4 digit

Number.

Site relationship Trail Trail multiplex channel

Identifier Identifier Number

A-end B-end


OSLO1. OSLO1-5. 1 . 1 .

Figure 12-37 Identification of a Trail multiplex channel

MSTR-NREG (2016-09) 70

Note that this naming scheme is different from naming of linkConnections within links within

layerNetworkDomains of Recommendation M.3160. However, the scheme does not prohibit

definition of a Trail for each link, as long as all linkConnections have the same routing.

A Trail multiplex channel may be allocated as a Trail section of one or more other Trails.

A Trail multiplex channel may be terminated at a Position in a Location in a Cross-coupling site.

The following example illustrates a multiplex hierarchy of two levels.

The top part of the Figure depicts the multiplexers and their interconnections.

The bottom part shows the representation, using Trails and Trail multiplex channels.

Figure 12-38 Representation of a multiplex hierarchy

Here we have depicted Trail sections, as well. They will be introduced in the next clause.

Sometimes, line termination equipment is placed in front of the multiplexers. In this case, a separate

Trail may be defined for the line, and another Trail may be defined between the multiplexers.

Figure 12-39 Representation of line termination

Alternatively, we may have only one Trail between the multiplexers, and include the line

termination equipment in the routing of this one Trail.

Some Operators also distinguish between the multiplex group and the Trail on which it is routed. In

this case, the group is another Trail.

12.8 Trail sections

A Trail section is any element that makes up the routing of a Trail.

MSTR-NREG (2016-09) 71

Figure 12-40 Schema of Trail sections

Trail sections are connected in series to define the routing of a Trail.

A Trail section represents a routing element corresponding to a Physical link connection, a Trail

multiplex channel, a Trail, a Position or Port item.

Each Trail section may refer to one or more of these elements in parallel, but each Trail section

should only refer to elements of one of these classes.

Example of a two-pair circuit: The Trail is defined as a series of Trail sections, each of these Trail

sections refers to two cable pairs. This representation gives only an informal picture of which pair is

connected to which pair.

Example of diverse routing of a two-pair circuit: Each single-pair circuit is represented as a Trail.

The two Trails are associated through an Association. New values of the Association Kind attribute

should be created to represent this association.

Another alternative for diverse routing of a two-pair circuit: Split a Trail into two Trail multiplex

channels. Associate a single-pair Trail to each Trail multiplex channel. Create a routing of each

single-pair Trail.

A Trail section is contained in some Trail.

A Trail section may have an Identifier that uniquely identifies the Trail section within the Trail. The

Identifier has maximum 2 alphanumeric characters. The numbering starts from the A-end. The Trail

sections corresponding to Physical link connections, Trail multiplex channels and Trails may be

numbered 1, 2, 3 etc. The Trail sections corresponding to Positions and Port items may be

alphabetic within the number, e.g. 1a, 1b etc. This may simplify both reading and selection.

Users may do both selection and projection of Trail sections within a Trail. Selection means that

only Trail sections within a geographical area may be listed. Projection means showing of some

attributes only.

Note that the cross-couplings between Trail sections are not shown in the data structure, but may

easily be added. Also, attributes showing the status of the couplings may be added.

Trail sections are the means to route Trails. So, in a way, this clause is the most important notion in

the technical report. The other notions identify topological resources on which the Trail is routed.

Trail section is a role of these other resources. This role glues them all together into becoming a

Trail.

MSTR-NREG (2016-09) 72

We now take an example where a customer Trail is routed on a Physical link in the access network,

then on a Trail multiplex channel in the transport network, and finally on an international Trail to

some other Operator. This is illustrated in the following Figure, where Trail sections are indicated

by dashed lines.

Figure 12-41 Routing of a customer Trail

We will now show a screen shot of this routing. This screen shot shows the identifier of the

customer Trail, and then lists the Trail sections from the A-end to the B-end of the Trail. We

number the Trail sections from the A-end. We do not list the Identifiers of the Physical link

connection and the two Trails corresponding to the Trail sections. Rather, we show this information

as derived data within the Trail sections themselves. For this purpose, we introduce two new

attributes, Section and Type. We introduce an attribute Type to tell what class of entity is

referenced. The values are T for Trail and L for Physical link.

Trail

Identifier

9876543100 .

Trail section



1 T FRA ORANPARIS1 NOR TELN OSLO1 315 4



Figure 12-42 Trail sections of a Trail

Note that for the customer Trail, we have used a local identifier within Norway even if the Trail is

routed all the way to Paris. But the contained international Trail has the correct full name. The full

customer Trail name within the Operator TELN within the Country NOR is therefore as shown

below.



A-end B-end


BERG2-5. OSLO1. 9876543100 .

Figure 12-43 Identification of the customer Trail within the Operator Telenor in Norway

12.9 Associations

An Association defines an ordered or unordered relationship between a Trail and some other Trails.

The ordering is indicated by the Superior trail reference.

MSTR-NREG (2016-09) 73

Figure 12-44 Schema of Associations

The Kind attribute of the Association is indicating the usage of the Association. Kind is a 2-

character field, adjusted to the left. S indicates reserve. In this case, Superior trail indicates the main

Trail, and Trail indicates the reserve trail.

An Association's Superior trail is a role of a Trail that controls the Association. In case of an

ordered relationship, the Association will have one and only one Superior trail. In case of an

unordered relationship, the Association will have no Superior trail.

An Association's Trail is a role of a Trail being controlled by the Association. An Association must

have one or more Trails.

SDH rings are typically applied to offer 100% reserves. If each Trail in the ring has 16 Trail

multiplex channels, only 8 of them are used for routing of customer Trails. The 8 other Trail

multiplex channels are used for reserves. If one customer Trail is routed between two Cross-

coupling sites A and B. A reserve is routed the other way around the ring between A and B. And an

Association with the Kind S is created between the two Trails. This is illustrated in the next Figure.

Figure 12-45 Reserves in SDH rings

13 Logical Network Domain inside Cross-coupling sites

13.1 Exchanges

An Exchange is an entity that directs individual calls, packages or cells.

MSTR-NREG (2016-09) 74

Figure 13-1 Schema of Exchanges

Exchanges can be switches, concentrators or routers. Exchanges can be customer exchanges or

transit exchanges. Intelligent Network servers and Operation Support System servers are not

Exchanges and are not Cross-coupling sites. A Cross-coupling site may contain several Exchanges

of various types.

The number No uniquely identifies an Exchange within the scope of a Cross-coupling site. No has

maximum 2 digits. The managing Operator of the superior Cross-coupling site decides the

numbering.

Country Operator Cross-coupling site Exchange

CC ICC Identifier No

NOR. TELNOR. BERGEN1 . 1 .

Figure 13-2 Identification of an Exchange

Note that it is permissible to define a Cross-coupling site for each Exchange or a set of Exchanges

at the same Address. In this case, separate Trails and other resources are required to route Trails

between these Cross-coupling sites at the same Address. See also under Cross-coupling site.

An Exchange may have references to the collection of Equipment items which implement the

Exchange. Note that the Equipment items are identified independently of the Exchange. Hence, a

Trail may be terminated at a Port item, within a Component item within an Equipment item, which

has a reference to an Exchange. This is the only way to state that a Trail is terminated in an

Exchange. This is so, because our data structure only deals with transmission resources.

If we would extend the data structure to cover traffic resources and traffic directions, then it would

be convenient to introduce Traffic trails being terminated in Exchanges.

13.2 Locations

A Location is a subdivision of a Cross-coupling site. It is an entity in which resources, such as

Exchanges, Equipment items and termination points, are placed.

MSTR-NREG (2016-09) 75

Figure 13-3 Schema of Locations

It should be noted that the term Location is here given a particular meaning local to Cross-coupling

site, and that this definition may not apply for the generic or colloquial term location.

A Location can be

a room

a frame

a rack

a block

a shelf or

a slot in a shelf,

and these may contain subordinate Locations recursively.

The Identifier of a Location uniquely identifies a Location within a superior Location or Cross-

coupling site. The Identifier may consist of both digits and letters. The Identifier has maximum 4

characters.

Country Operator Cross-coupling site Location


NOR. TELNOR. BERGEN1 . R102.

Figure 13-4 Identification of a room

Country Operator Cross-coupling site Location Location Location

CC ICC Identifier Identifier Identifier Identifier

NOR. TELNOR. BERGEN1 . RO102. Ra . RA2 .

Figure 13-5 Identification of a rack

Note that the global distinguished name shows the full hierarchy of superior Locations. There exists

more compact ways to present the Location hierarchy than shown in the last Figure. This will not be

discussed here.

The Location Identifier is assigned by the Operator of the Cross-coupling site. Note that other

Operators renting or using the space are not free to assign their own identifier.

MSTR-NREG (2016-09) 76

Note that the class label will always be Location, even when Locations at many levels are shown,

such as in Figure 29.3. However, the values may or may not indicate if the Location is a room,

frame or other. We have no standard abbreviations for these, but the Operator is advised to invent

such abbreviations.

If the Location is a block, then its superior is a rack, and its superior is a frame, and its superior is a

room. But any of these may not have any superior Location, as e.g. a junction box may only have a

block or a rack of blocks.

If a Location is a slot, then its superior is a shelf, and its superior is a rack, and its superior is a

frame, and its superior is a room.

Slots and shelf-s are used for placement of Component items or Equipment items only. Racks,

frames and rooms may be used for these purposes, or for blocks having Positions.

The manufacturer of the Location, e.g. of a frame, may assign a Unique item identification (UID) to

a Location. This UID shall not be stored in the Identifier.

A Location may contain references to the Equipment items or Component items placed in this

Location.

A Location may alternatively contain subordinate Locations or Positions. Positions make up the leaf

nodes of the Location hierarchy. Positions are the means for termination of transmission resources.

See the subsequent section on Positions.

A Location's Equipment identity is a role of an Equipment identity to which the Location belongs.

Equipment identity is a classification from the manufacturer of equipment. And Locations may be

seen as being equipment as seen from the manufacturer, but may not be seen to be so by the

Operator.

Location items are illustrated as dotted rectangles. The Location hierarchy is illustrated as dotted

rectangles within dotted rectangles.

Figure 13-6 Illustration of Locations

13.3 Positions

A Position is a unit that is used to enter terminations and cross-couplings. The Position can be an

individual pin, a pair of pins or a group of pins, depending on the design, planned or actual use of

the Position.

MSTR-NREG (2016-09) 77

Figure 13-7 Schema of Positions

A Position is assigned a unique Identifier within the scope of its superior Location. The Identifier

may, e.g., indicate a group of pins, e.g. 3, or an individual pin, e.g. 3a. The Identifier has maximum

4 characters.

Country Operator Cross-coupling site Location Position

CC ICC Identifier Identifier Identifier

NOR. TELNOR. OSLO1-5 . BL15. 1 .

2 .

3 .

4 .

5 .

Figure 13-8 Example identification of Positions

A Physical link connection, a Trail multiplex channel or a Trail may be terminated at a Position.

Also a Port item may be terminated at a Position, or a Position is terminated at a Port item. The term

“termination” may be confusing, as it is not globally unique, and it may not indicate a final

termination.

We used the term Termination for the relation between a Trail and the Cross-coupling sites in its

end points. But this Trail may continue out to the customer or via other resources and Trails. And

we use the term termination on a Position of external resources to the Cross-coupling site, and of

internal resources. And in all these cases, the “termination” may not be the final destination.

Normally only one of the above entities is terminated at a particular Position.

Cross-couplings between these Positions are indicated by references between the Positions. Note

that the cross-coupling or termination is assigned no direction. The cross-couplings and

terminations are two-way references which are maintained by software in the inventory system.

In addition to the above, termination of Branch connections, Series connections and Leg

connections may appear at the same Positions as of Physical link connections. Software within the

inventory system may help to create series of these terminations.

Positions are illustrated as short pins within Location rectangles.

MSTR-NREG (2016-09) 78

Figure 13-9 Example illustration of Positions within Locations

Figure 13-10 Example instance diagram of Positions within Locations

In the previous Figure, local names of Positions and Locations are shown.

We are now ready to state terminations on Positions.

Physical link

A-end B-end Identifier


BERG2 . BERG2-5 . C1-10 .

Physical link connection Position ‘Location ‘Location ‘Location

Number Identifier Identifier Identifier Identifier

31 . 1 BL1 RA1 RO15

Figure 13-11 Termination of a Physical link connection

MSTR-NREG (2016-09) 79

Trail



OSLO1 . BERG2 . 412 .

Position ‘Location ‘Location ‘Location

Identifier Identifier Identifier Identifier

2 BL1 RA2 RO15

Figure 13-12 Termination of a Trail

Trail



OSLO1 . BERG2 . 16 .

Trail multiplex channel Position ‘Location ‘Location ‘Location

Identifier Identifier Identifier Identifier Identifier

5 . 7 BL5 RA1 RO15

Figure 13-13 Termination of a Trail multiplex channel

Note the use of reverse local names, indicated by the ‘-symbol in the headings of these examples.

Hence, a Position is contained in a block Location, which is contained in a rack Location, which is

contained in a room Location.

Note that Link connections, Trail multiplex channels and Trails are terminated at positions in two

Cross-coupling sites. The Identifier of the Cross-coupling site is not shown in the above Figures.

13.4 Equipment items

An Equipment item provides a collection of functions and is considered as a unit from a placement

point of view in a Location.

Figure 13-14 Schema of Equipment items

An Equipment item may be an Exchange, taking up a whole room, it may be a part of an Exchange,

it may be transmission equipment, and it may be an individual circuit card.

MSTR-NREG (2016-09) 80

Also, non-telecommunication equipment may be registered as Equipment items, like battery packs,

generators etc., e.g. to show the use of space and to provide a complete inventory. However, the

data structure is not specialized for this usage.

Note that racks are not registered as Equipment items, as they are managed as Locations.

An Equipment item may have a Location, and can only have one Location.

Note that an Equipment item may have a Location in the same rack as of a block of Positions.

Therefore, both are placed in Locations, and there is no separate notion of equipment holder.

Several Equipment items may have a reference to one and the same Exchange to which they belong.

Most Equipment items are transmission equipment, and belong to no Exchange.

An Equipment item may have a reference to an Equipment identity, which is a categorization of the

equipment from the manufacturer.

An Equipment item is assigned a unique Identifier within the scope of its superior Cross-coupling

site. Room identification may or may not be a part of the Equipment item Identifier. Also, the

Identifier may include letters which indicate the kind of equipment. There is no international

standard for the design of the Identifier.

The Equipment item Identifier has maximum 8 alphanumeric characters.

Country Operator Cross-coupling site Equipment item


NOR. TELNOR. BERGEN1 . SDH4 .

Figure 13-15 Identification of an Equipment item

The Operator of the Cross-coupling site assigns the Equipment item Identifier.

Different pieces of Equipment items within a Cross-coupling site may be owned or used by

different entities. But it is the Operator of the Cross-coupling site who assigns the Equipment item

Identifier, and not the owner of the Equipment item.

Aliases of Equipment item Identifiers are not permitted for communication between Operators.

However, Operators may exchange additional Equipment item identifiers that are local to a specific

Operator.

The manufacturer may assign a Unique item identification (UID) to an Equipment item. Note that

the UID shall not be put into the Identifier.

The Equipment item may contain any number of Component items.

An Equipment item is illustrated as a rectangle containing one or more Component rectangles.

MSTR-NREG (2016-09) 81

Figure 13-16 Example arrangement of Equipment items

The following Figure shows what Equipment items are placed in which Location.

Cross-coupling site

Identifier

BERG1

Location Location Location Equipment item

Identifier Identifier Identifier Identifier

RO15 RA1 SDH3

Figure 13-17 Example Location with an Equipment item

M.1401 does not define a Local identifier for Equipment items, but we think that this should be

added. The Local identifier may refer to the Network Elements within the Equipment item. A

Network Element is a set of capabilities to perform functions within the telecommunication

network.

M.1401 does not have a recursive relation from Equipment item to Equipment item to state

hierarchies of Equipment items. Such a relation may be added, but we are uncertain about the need.

The relation would allow grouping of Equipment items which belong together, and it would allow

definition of Equipment items inside an Equipment item. But this grouping or decomposition would

indicate functional groupings or splits, which is not the purpose of the Equipment item. Equipment

item is a piece of hardware. The functionality is indicated by the reference to Network Elements, or

in the decomposition into Component items. Also, Trails and Trail multiplex channels between

Equipment items indicate functionality.

13.5 Component items

A Component item is a separate unit, e.g., a circuit card, within an Equipment item.

MSTR-NREG (2016-09) 82

Figure 13-18 Schema of Component items

A Component item may have one and only one specified Location.

A Component item may have any number of Port items, which may provide inputs, outputs or both.

A Component item is assigned a unique Identifier within the scope of the superior Equipment item.

The Identifier has maximum 3 characters. Letters may indicate kind of component.

Country Operator Cross-coupling site Equipment item Component item

CC ICC Identifier Identifier Identifier

NOR. TELNOR. BERGEN1 . SDH4 . 1 .

Figure 13-19 Identification of a Component item

A Component item may have a reference to an Equipment identity, which is a categorization of the

equipment component from the manufacturer.

The manufacturer may assign a Unique item identification (UID) to a Component item.

Component items are illustrated as rectangles. See the small rectangles within Equipment item

rectangles in the previous section.

The following Figure shows a Location, shelf 10, containing a Component item.

Cross-coupling site

Identifier

BERG1

Location Location Location Component item

Identifier Identifier Identifier Equipment item Identifier

Identifier

RO15 RA1 SHE10 SDH3 S3

Figure 13-20 A Location containing a Component item

Note that the following Figure shows a Location containing an Equipment item which contains a

Component item. The Location of the Component item is not shown.

MSTR-NREG (2016-09) 83

Cross-coupling site

Identifier

BERG1

Location Location Location Equipment item Component item

Identifier Identifier Identifier Identifier Identifier

RO15 RA1 SDH3 S3

Figure 13-21 A Location containing an Equipment item containing a Component item

M.1401 does not define a Local identifier for Component items. This Local identifier may be added,

if the Local identifier of Equipment item is not sufficient. The Local identifier may refer to the

Network Elements within the Component item. A Network Element is a set of capabilities to

perform functions within the telecommunication network.

13.6 Port items

A Port item defines a functional unit of a Component item of an Equipment item. The Port item can

be sender, receiver, or bidirectional. It may also be possible to modify the function of a Port item.

Figure 13-22 Schema of Port items

A Port item has no Location, like what Component items and Equipment items may have.

A Port item's Equipment identity is a role of an Equipment identity to which the Port item belongs.

Note that the reference is to Equipment identity, and not to Equipment item.

A Port item may have a reference to a Position that terminates the Port item.

A Port item may have a reference to a Trail section in a Trail. The Trail section plays the role of the

Port item in that Trail. Note that the reference between Port items and Trail sections states nothing

about terminations.

A Port item is assigned a unique Identifier within the scope of its superior Component item within

an Equipment item within a Cross-coupling site. The Identifier has maximum 3 characters. Letters

may indicate the function of the Port item.

MSTR-NREG (2016-09) 84

Country Operator Cross-coupling site Equipment item Component item Port item

CC ICC Identifier Identifier Identifier Identifier

NOR. TELNOR. BERGEN1 . SDH4 . 1 . 1 .

Figure 13-23 Identification of a Port item

A Port item has not a Unique item identification (UID), like of Component items and Equipment

items.

Port items are illustrated as small circles within Component items within Equipment items.

Figure 13-24 Example illustration of Port items within Component items within Equipment

items

Figure 13-25 Example instance diagram of Port items within Component items within

Equipment items

In the previous Figure, the items are given local names.

The next Figure shows termination of Port items on Positions in a cross-coupling rack in a room.

MSTR-NREG (2016-09) 85

Figure 13-26 Termination of Port items

Note that the term “termination” only indicates a connection to the Position, and the Position may

not be, and most often is not, the final termination of a Trail being routed via the Port item.

We are now ready to state termination of Port items on Positions in the Cross-coupling site.

Cross-coupling site

Identifier

BERG1

Equipment item Component item Port item Position ‘Location ‘Location ‘Location

Identifier Identifier Identifier Identifier Identifier Identifier Identifier

SDH3 S1 1 2 BL10 RA1 RO15

Figure 13-27 Termination of Port items

Note that in the previous Figure we have used reversed local naming to show the Locations of the

Positions, because the Port item is related to the Position, and not to the Room. The reversed local

naming is indicated by the ‘-symbol in the headings.

References the other way, from Positions to Port items are shown in the next Figure.

Cross-coupling site

Identifier

BERG1

Location Location Location Position Port item ‘Component item ‘Equipment item

Identifier Identifier Identifier Identifier Identifier Identifier Identifier

RO15 RA1 BL10 2 1 S1 SDH3

Figure 13-28 Termination of Positions

Note that Position is the only resource that can be terminated directly at a Port item. The only way

to connect Physical link connections, Trail multiplex channels and Trails to Port items is indirectly

via Positions or via use of Trail sections. Trail sections are not terminated at a Port item, but a Trail

section may take the role of a Port item in a Trail.

Note that Equipment items may have Component items and Port items both at the station/channel

side and at the line/Trail side.

We believe that Port item should have a Local identifier that refers to terminations defined in

Network Element Managers. Sometimes, the Port item Identifier and the termination identifier

MSTR-NREG (2016-09) 86

inside the NEM are identical, and then the reference is not needed. At other times, they are

different, and the reference is needed. This reference is not yet defined in M.1401.

M.1401 has no recursive reference from Port item to Port item for defining direct cross-couplings.

M.1401 should be extended with such a reference for cross-coupling and strapping of optical

equipment, as in this case, the Port items are not terminated at Positions in cross-coupling racks.

The optical Equipment item may contain multiplexing at several levels. These levels are indicated

by Trails and Trail multiplex channels. However, the technician has to configure the equipment, and

the recursive relation is for this purpose. We assume that the identifiers of the Port items tell to what

level they belong.

13.7 Equipment identity

An Equipment identity is a category of equipment instances that may be characterized by a

combination of:

manufacturer name;

manufacturer part number;

manufacturer equipment version number;

equipment category number;

substitutability (upward/downward compatible replacement).

An Equipment identity may categorize a set of Equipment items, Component items, Port items, or

Locations, but an Equipment identity cannot categorize items belonging to more than one of these

classes simultaneously.

Figure 13-29 Schema of Equipment identity

An Equipment identity has a Code that uniquely identifies a type of manufactured

telecommunications network equipment or an assignable entity within a type of equipment. This

code is assigned on behalf of the manufacturer.

13.8 Trails within Cross-coupling sites

In this clause, we will define Trails within Cross-coupling sites. In a previous section, we have

defined Trails between or within Cross-coupling sites.

A Trail provides a transport of signals between two Cross-coupling sites or within one and the same

site. The Cross-coupling site Positions may be located in Cross-coupling sites within different

Countries, by different Operators, the same Operator, or within one and the same Cross-coupling

MSTR-NREG (2016-09) 87

site – in case of internal Trails. Also, the Trail may be terminated at the customer premises, i.e.,

outside the Cross-coupling site.

Figure 13-30 Schema of internal and external Trails

A Trail may contain references to the Positions at which the Trail is terminated. Note that these

references are only to the Positions at the end-points of the Trail, and are not covering Positions

visited elsewhere by the routing of the Trail.

Note that the Trail sections may also cover the Positions which terminate the Trail. Therefore, the

references to the terminating Positions may not be strictly needed.

Internal Trails are identified in the same way as external Trails.



A-end B-end


OSLO1. OSLO1. 1 .

Figure 13-31 Identification of an internal Trail

The Trail may consist of Trail sections, which may be Physical link connections, Trail multiplex

channels, Trails, Port items or Positions. It is up to each Operator how to present the routing of the

Trail. Typically, he may consider the Trail section to be a superclass of the mentioned entity

classes, and define attributes of Trail section that show the routing in a unified and compact way,

rather than referring to each subclass. These attributes need not be physically stored in the Trail

section, but may be derived for presentation to the human user only

The Trail sections are presented in a sequence from the A-end to the B-end. The user may do

selection and projection, e.g. excluding Port items, Positions etc., according to his preferences.

We are now ready to extend our routing of the customer Trail in section 26 with terminations and

routing within the Cross-coupling sites. The Types are extended with R for Port items and O for

Positions.

MSTR-NREG (2016-09) 88

Trail

Identifier

9876543100 .

Trail section
















Figure 13-32 Internal and external Trail sections of a Trail

In the previous Figure, we start with the Position in Paris, via Positions and the Port items an

amplifier Equipment item in Oslo to the termination on a Position in a main junction box BERG2-5

in Bergen.

The Trail may be terminated in customer equipment in both ends. This information belongs to the

Business Support System domain, and is not covered by this technical report.

Note that Orders may be used to convey any Message about the network, and are not constrained to

routing of Trails.

14 Orders for the Logical Network Domain

14.1 Orders

This clause gives an overview on how Orders are defined and used for the Logical network domain.

The section is not a full tutorial on Orders.

The text in this clause is based on ITU-T M.1404. Formalization of orders for interconnections

among operators' networks [9].

An Order identifies a long transaction between System domains, organization (unit)s or users. A

long transaction means that it may visit several of these actors, or the same actor several times,

before the transaction terminates.

The Order is created and given an Identifier by an Operator whenever a request comes to the

Operator. The Order is only valid within the domain of this Operator, and across systems,

organizations and users of this Operator. So, the Order may be used towards the customers and

partner of the Operator, but these are free to define derived Orders within their domain, but have to

answer through the original Order. So, Orders may have derived Orders, and this reference between

Orders needs to be managed.

The Order at the Business Support Systems (BSS) side may be the original Order, and the

Operation Support Systems (OSS) Order may be a derived Order, or vice versa. Also, the OSS

Order may be split into several work Orders to separate destinations or installation companies. The

management of this work flow will not be addressed in this technical report.

MSTR-NREG (2016-09) 89

Orders may also be split into sub-orders, called Messages. A Message can be compared with a

statement, some may be short and simple, while others may be long and complex. Different

Messages may be sent on different paths through the domain of the Operator. Typically, a work

Order may contain only one Message or few Messages.

The Messages may contain data. The data are the same as what is described in the previous sections

of this technical report. The general schema of the data is also the same, except all classes are local

to the class Message. And each data instance (in an Order) is local to a Message instance.

The Messages bring information about events which are going to happen, and give reports on what

has happened. Hence, the Orders are means for the management of events, and they identify who

will do and has done what. Therefore, the Orders are essential means to ensure data quality. The

Orders give a full overview of what is planned to happen, and of what has happened.

It is possible to define an approved network plan to be an Order. Most Operators choose to

distinguish network plans from Orders. Hence, they attach network states concerning deployment

and implementation to the entities in the Main register, while their use and configuration are

controlled by the Orders.

It is also possible to define Message templates that allows for only a subset of the generic data

structure of a Message. Hence, you may have one Message class for provisioning, one for trouble-

ticketing, one for notification of customers, one for orders to partners etc.

MSTR-NREG (2016-09) 90

Above, we have explained the data structure of the Order register. The previous parts of the

technical report explain the data structures of the Main registers. They are both shown in the Figure

below.

Figure 14-1 Combined data structure of Order and Main register

In the Figure, the Main register is depicted to the left, and the Order register to the right. Note that

Orders are contained in the Operator.

The brown dashed diagonal arrows depict the time dimension of each entity in the Main register.

All mentioning of this entity instance in various Orders are listed under this entity instance. And if

you look up on an entity instance within an Order, you find a reference to the current status of this

entity instance in the Main register.

Note that this data structure of Orders is not constrained to routing of Trails. This data structure

allows statement of any fact or change that can appear in the Main register. You may issue Orders

about Cross-coupling sites, Trails, Physical links, Equipment items etc.

In the above Figure, we have not shown a data structure for data flow. This could also be a topic for

a larger report on Orders. You may find appropriate data structures for this in documentation of

Work flow engines. But note that the entire work flow may be defined as a database application,

and a process engine is not needed.

The following Figure shows a Message to create its routing of the Trail in Bergen.

S

S

Oper

ator

Exch

ange

Addr

ess

Equi

pmen

t item

Locat

ion

Coun

try

Locat

ion

Trail

Geog

raphi

cal

area

Positi

on

Physi

cal

link

Asso

ciatio

n

Multi

point

trail

Site

relati

onshi

p

Cros

s-

coupl

ing

site

Com

pone

nt

item

Trail

multi-

plex

chan

nel

Physi

cal

link

conn

ectio

n

Port

item

Trail

secti

on

Termi

natio

n

Equi

pmen

t

identi

ty

S

Exch

ange

Addr

ess

Equi

pmen

t item

Locat

ion

Locat

ion

Trail

Geog

raphi

cal

area

Positi

on

Physi

cal

link

Asso

ciatio

n

Multi

point

trail

Site

relati

onshi

p

Cros

s-

coupl

ing

site

Com

pone

nt

item

Trail

multi-

plex

chan

nel

Physi

cal

link

conn

ectio

n

Port

item

Trail

secti

on

Oper

ator

Coun

try

Termi

natio

n

Equi

pmen

t

identi

ty

Mess

age

Order

MSTR-NREG (2016-09) 91

Order

Identifier

123

Message

Identifier Request

C Create the cross-coupling in BERG2

Trail

Identifier

9876543100 .

Trail section








Figure 14-2 Example Message

Note that we have not developed a complete Order notion in this technical report. Therefore the

Request only appears as informal text within the Message.

The Trail may be terminated in customer equipment in both ends. This information belongs to the

Business Support System domain, and is not covered by this technical report.

The primary purpose of Orders is to carry out provisioning of Trails. However, Orders may also be

issued for repair, installation of Equipment items, termination of Port items on Positions,

configuration of Equipment items, cross-couplings etc.

______________

itu-t technical report · 2016. 12. 8. · of itu (23 september 2016) mstr-nreg telecom network...

Documents