Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 32.102  Word version:  16.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   8…   A…

 

8  3GPP Management Physical architecturesWord‑p. 24

A 3GPP Telecom Management Network will consist of many different management layers and many different building blocks. The complexity will vary greatly in detail because every organisation has different needs. The following clause will identify the most critical architectural issues and compliance conditions for a given 3GPP management interface. It should serve as fundamental requirements for any 3GPP entity (network element or management system) being a part of a 3GPP TMN.

8.1  Compliance ConditionsWord‑p. 24

For a 3GPP entity (management system or NE) to be compliant to a given management interface, all the following conditions shall be satisfied:
  1. It implements the management functionality specified in the relevant IRP Information Service specifications.
  2. It provides at least one of the IRP Solution Sets (were available) related to the valid Application Protocols specified by 3GPP Application Protocols for that interface, [2] annex C.
  3. It provides at least one standard networking protocol.
  4. In case the entity does not offer the management interface on its own, a Q Adapter shall be provided. This Q Adapter shall be provided independently of any other NE and/or management system.
  5. Support for Bulk Transfer Application Protocols specified by the relevant 3GPP management interface specifications applicable to that interface.
Up

8.2  Network Element (NE) management architectureWord‑p. 25

Figure 8.2 shows two possible options for management interface from the OS upper layers to NE. Option 1, provides access to the NE via element manager, and Option 2, provides a direct access. It is sufficient to provide one or the other.
Figure 8.2 does not imply and limit the realisation of any OS physical block (e.g. E-OS, N-OS) to just one logical layer. OS physical blocks may span more than one logical layer (ITU T Recommendation M.3010 [1]). Different types of network elements, different functional areas, operator and vendor preferences etc will put different constraints on the physical realisation of the OSFs. See further clause 9.
(not reproduced yet)
Figure 8.2: Network Element Management Architecture
Up
For a 3GPP entity (Network Element or management system) to be compliant to a given management interface the following conditions shall all be satisfied:
Item Compliance conditions
1 Implements relevant 3GPP IRP Information Service specifications.
For an interface illustrated by the dashed line in Figure 4 the object model is not standardised but it shall be open
2 Application protocol (e.g. SNMP,CORBA IIOP)
(Defined in TS 32.101, Annex A)
If 3GPP has specified one or more IRP Solution Sets corresponding to the IRP Information Services in item 1 then at least one of those IRP Solution Sets shall be supported.
(Defined in TS 32.101, Annex C)
3 Valid Network Layer Protocol
(see Annex B of TS 32.101)
4 Lower protocol levels required by Item 1, 2 and 3
Up

8.3  Subnetwork Management ArchitectureWord‑p. 27

(Example 3GPP RNC / NodeB)
An important special case of the network element management architecture is where one type of network element such as the RNC will need management information for co-ordination of a subnetwork of other types of network elements such as NodeB.
This management information shared between the RNC and NodeB will not reach the operators and is not considered to be a part of the 3GPP TMN. All other management information related to NodeB will transparently be transferred by the RNC towards the 3GPP TMN.
(not reproduced yet)
Figure 8.3: Subnetwork Management Architecture
Up
The same compliance conditions apply for the subnetwork management architecture as for the network element management architecture (see clause 8.2).

8.4  Operations Systems interoperability architectureWord‑p. 28

Interoperability between operations systems is an important issue in a 3GPP system. Different organisations may take different roles in a 3GPP system. The need to share information across corporate boundaries will be a consequence of this.
The heterogeneous, distributed and complex network of a 3GPP system will be a market for many different vendors. All operations systems have to interoperate and shall be able to share information. This is a critical issue in the management of third generation systems.
(not reproduced yet)
Figure 8.4: Operations Systems interoperability Architecture
Up
For a Operations System to be 3GPP TMN compliant the following conditions shall all be satisfied:
Item Compliance conditions
1 Implements relevant 3GPP IRP Information Service specifications.
2 Application protocol (e.g. SNMP,CORBA IIOP)
(Defined in TS 32.101, Annex A)
If 3GPP has specified one or more IRP Solution Sets corresponding to the IRP Information Services in item 1 then at least one of those IRP Solution Sets shall be supported.
(Defined in TS 32.101, Annex C)
3 Valid Network Layer Protocol
(see Annex B of TS 32.101)
4 Lower protocol levels required by Item 1,2 and 3
Up

8.5  Operations Systems intra-operability architectureWord‑p. 29

(not reproduced yet)
Figure 8.5: Operations Systems intra-operability Architecture
Up
OS-QInternal indicates an internal flow and is not standardised.
OS-QExternal indicates an external flow and shall to be compliant to a given 3GPP Management Interface satisfy the following conditions:
Item Compliance conditions
1 Implements relevant 3GPP IRP Information Service specifications.
2 Application protocol (e.g. SNMP,CORBA IIOP)
(Defined in TS 32.101, Annex A)
If 3GPP has specified one or more IRP Solution Sets corresponding to the IRP Information Services in item 1 then at least one of those IRP Solution Sets shall be supported.
(Defined in TS 32.101, Annex C)
3 Valid Network Layer Protocol
(see Annex B of TS 32.101)
4 Lower protocol levels required by Item 1,2 and 3
Up

8.6  Enterprise management System interconnection architectureWord‑p. 30

The business enterprise layer has in the second-generation systems a very low degree of standardisation. Operators have legacy systems or more IT influenced systems often adopted to every organisations different needs. Enterprise management systems are not a part of a 3GPP TMN.
(not reproduced yet)
Figure 8.6: Enterprise management Systems interconnection architecture
Up
OS-QExteral indicates an external flow and shall to be compliant to a given 3GPP management interface satisfy the following conditions:
Item Compliance conditions
1 Implements relevant 3GPP IRP Information Service specifications.
2 Application protocol (e.g. SNMP,CORBA IIOP)
(Defined in TS 32.101, Annex A)
If 3GPP has specified one or more IRP Solution Sets corresponding to the IRP Information Services in item 1 then at least one of those IRP Solution Sets shall be supported.
(Defined in TS 32.101, Annex C)
3 Valid Network Layer Protocol (see Annex B of TS 32.101)
4 Lower protocol levels required by Item 1,2 and 3
IFX indicates an external flow and shall to be compliant to a given 3GPP management interface satisfy the following condition:
Item Compliance conditions
1Not standardised but open
Up

9  TMN applicationsWord‑p. 31

Telecom management applications can be implemented in many different ways depending on constraints presented in previous clauses. The TMN application - the operations systems component (OSC) -is the physical realization of one or more OSFs needed to support the operational processes. An up-to-date Operations System would be assembled from one or more OS components which expose standardized interfaces to allow for more flexible and agile OSs.
To identify and specify the design criteria that will allow re-usable application components to be developed across multiple telecom business scenarios are important issues to fulfil the basic 3GPP Management requirement. "To minimise the costs of managing a PLMN such that it is a small component of the overall operating cost".
The implication of the top down approach in the standardising work of 3G is that consistent operational management processes are required irrespective of vendor equipment.
Generic and re-usable management applications are required to facilitate:
  • Reduced management application development costs.
  • Simplification of operational processes and associated reduction in costs.
  • Reduced time to deploy new services as management systems already exist.
  • Consistent representation of basic information.The complexity and heterogeneous nature of a 3GPP system calls for easy integration (plug&play) of HW/SW.
Up

9.1  Management function blocksWord‑p. 31

A management function is the smallest part of a business process (or management service), as perceived by the user of the process (or service). A management function block is the smallest deployable unit of management functionality. Figure 9.1 illustrates the different types of optional management function blocks. For example physical views and mapping to 3GPP PLMN management interfaces, see subclause 9.2 and 9.3. The OSF specializations/decompositions reflect the high level processes identified in ITU-T TMN Enhanced Telecom Operations Map(eTOM), M.3050.x series, ref[20]., See further M.3060/Y.2401 ref [16].
(not reproduced yet)
Figure 9.1: Management function blocks in M.3060/Y.2401 [16]
Up

9.2  Management physical blocksWord‑p. 32

Figure 9.2-1 illustrates example implementations of physical views. The OS physical block realizes OSFs, of which a great variety is available. Some will be consequence of 3GPPs decision to base the management processes on Enhanced Telecom Operations Map [2],[9],[20], others on enabling support for the management of Next Generation Networks [16], [17].
(not reproduced yet)
Figure 9.2-1: An example implementation of a physical view in M.3060/Y.2401 [16]
Up
The physical architecture may flatten the functional Management Layers into a single, unified management layer for the co-management of several functional Management Layers to facilitate a unified handling of e.g. alarms and performance data. There is great flexibility in the design of Next Generation Network Operations Systems with this concept, see further Annex 1. The flexibility can enable co-management of multiple functional layers as presented in Figure 9.2-2. The interfaces depicted in fig. 9.2-1 and 9.2-2 are in the 3GPP PLMN management architecture mapped to the Itf-N or Itf-P2P interface between an IRPManager and IRPAagent, as shown in fig. 9.3.
(not reproduced yet)
Figure 9.2-2: Co-management of multiple functional management layers in M.3060/Y.2401 [16]
Up

9.3  IRP concept enabling TMN applicationsWord‑p. 33

3GPP has developed the interface concept "Integration Reference Point" (IRP) to promote the wider adoption of standardized management interfaces in telecommunication networks. The concept is presented in TS32.150 [5]. These IRPs are provided by an IRPAgent and managed via an IRPManager. The IRPs are the prime enabler of flexibility in the design of management physical blocks (OSs).
In the context of management of Next Generation Networks the IRPAgent and IRPManager represents the provider reference point and respectively the consumer reference point, respectively. See figure 9.3.
The IRP concept may be mapped to all of the management physical blocks. The 3GPP PLMN Management Architecture will focus on those functions, methods and interfaces that the new challenges of 3GPP Telecom Management may require. The detailed and final standardization requirements will be targeted in other 32.*** series and 28.*** series of standards.
(not reproduced yet)
Figure 9.3: IRPAgent and IRPManager using NGN principles
Up

10Void

11  Implementation aspectsWord‑p. 34

PLMN operators might categories and organise its operation systems in many different ways as:
  • A national fault and performance OS.
  • A national charging, billing and accounting OS.
  • Regional configuration OS.
  • Regional fault, performance and configuration OS.
  • etc.
This geographical dependent categorisation may change after time and the growth of the network. A physical architecture based on an open system design and re-usable application components would ease the work to adopt such structural changes. A management system build for a PLMN shall provide the possibility of layering the applications.
Up

12  3GPP TMN ConformanceWord‑p. 35

The goal of TMN conformance (see ITU-T Recommendation M.3010 [1]) is to increase the probability that different implementations within a TMN will be able to interwork, that TMNs in different service/network provider's administrations and customer's system will be able to interwork as much as agreed on.
TMN conformance are testable conditions.
It is only the requirements on the external behaviour that have to be met by the conformance statements.
To finally guarantee interoperability the purchaser/user shall be able to test and verify that any two systems, claiming any type of TMN conformance, interoperate. Interoperability testing shall include:
  • Testing of the interface protocols;
  • The shared/exposed information over those interfaces;
  • The interface functionality of the system.
A 3GPP TMN conformant entity shall support necessary information to support such interoperability testing namely:
  • Statements made by the supplier of an implementation or system claimed to conform to a given specification, stating which capabilities and options have been implemented.
  • Detailed information to help determine which capabilities are testable and which are un-testable.
  • Information needed in order to be able to run the appropriate test.
  • The system interface documentation shall list the documents that define the specified information models with the inclusion of the version number and date.
  • Necessary information about vendor supplied extensions of a standardised interface
The interface specification shall be documented, publicly available and licensable at reasonable price on a non-discriminatory basis.
Specific conformance guidelines shall be included in the different IRP solution sets. A 3GPP TMN conformant entity must support information stated in those conformance guidelines.
Up

13  TMN planning and design considerationsWord‑p. 36

A TMN should be designed such that it has the capability to interface with several types of communications paths to ensure that a framework is provided which is flexible enough to allow for the most efficient communications:
  • Between one NE and other elements within the TMN;
  • Between a WS and other elements within the TMN;
  • Between elements within the TMN;
  • Between TMNs.
The basis for choosing the appropriate interfaces, however, should be the functions performed by the elements between which appropriate communications are performed. The interface requirements are specified in terms of function attributes needed to provide the most efficient interface.
Up

13.1  Function attributesWord‑p. 36

  1. Reliability - The capability of the interface to ensure that data and control are transferred such that integrity and security are maintained.
  2. Frequency - How often data is transferred across the interface boundary (Normal behaviour).
  3. Quantity - The amount of data that is transferred across the interface during any transaction.
  4. Priority - Indicates precedence to be given to data in case of competition for network resources with other functions.
  5. Availability - Determines the use of redundancy in the design of the communications channels between interfacing elements.
  6. Delay - Identifies the amount of buffering that may be tolerable between interfacing elements. This also impacts communications channel designs.
Table 13.1 suggests a possible ranges for these function attributes.
Attributes Requirements Nature of attributes
Performance or grade of service (P)Delay (speed)Short
Medium
Long
Objective of design and control (acceptable/unacceptable but available/unavailable)
Reliability (accuracy)High Medium Low
AvailabilityHigh
Medium
Low
Characteristics of TMN traffic (C)QuantityLarge
Medium
Small
Condition or parameter of design
FrequencyOften continuous
Periodic
Sparse
PriorityHigh
Medium
Low
Up

13.2  Functional characteristicsWord‑p. 37

Each major type of telecommunications equipment has functional characteristic needs that can be used to describe the complexity of the interface.
There are, however, a basic group of TMN application functions that cross all major types of telecommunications equipment. There are also unique TMN application functions that are performed by specific categories of major telecommunications equipment. Alarm surveillance is an example of the former, whereas billing information collection is an example of the latter.
Functional characteristics of the elements within a TMN, e.g. OS, DCN and MD also describe the complexity of interfaces between these elements.
Up

13.3  Critical attributesWord‑p. 37

Attribute values for a given function are generally consistent across the network elements.
When considering a single interface, it is important to identify the controlling attribute ranges for the design of the interface.
If there are conflicting attribute values for different functions in a given network element, more than one instance of an interface may be needed.
Overall TMN attribute values for the interfacing of elements within the TMN depend on the type and number of functions performed within these elements. In this case the functions are not consistent across TMN elements, but are controlled by the individual TMN design of an Administration.
Up

13.4  Protocol selectionWord‑p. 37

In many cases, more than one protocol suite will meet the requirements for the network element or TMN element under consideration. It is the approach for the 3GPP Telecom management standardisation to concentrate on protocol independent information models, allowing the mapping to several protocol suites.
The rationale behind this is:
  • The blurring of Information and Telecommunication technologies in a 3GPP system, it is required to work on a more open approach (acknowledging the market status and foreseen evolutions).
  • The lifecycle of information flows is 10 to 20 years, while the protocols is 5 to 10 years.
  • The developments on automatic conversion allows for a more pragmatic and open approach.
The choice of the individual protocol from the recommended family will be left open to the vendors and operators.
To provide the most efficient interface care should be taken to select the protocol suite that optimises the relationship between the total cost to implement that protocol suite, the functional attributes and the data communications channels that carry the information across the interface.
Up

13.5  Communications considerationsWord‑p. 37

DCN architectures should be planned and designed to ensure that their implementation provides appropriate degrees of availability and network delay while minimising cost.
One should consider the selection of communications architectures, e.g. star, multipoint, loop, tree, etc.
The communications channels, e.g. dedicated lines, circuit-switched networks and packet networks used in providing the communications paths, also play an important role.

14  Mediation/IntegrationWord‑p. 38

The increase in the need to incorporate a hybrid set of technologies, multiple protocols and heterogeneous resources requires the availability of open management interfaces between the management systems and the different network resources. These interfaces require an underlying mechanism to mediate - interpret, translate, and handle data - between the various data representations and protocols. A set of Technology Integration Points [10] can be identified.
Software components on the open market as automatic conversion applications, gateways, mediation applications will be valuable products to fulfil the challenging task to incorporate multiple protocols and heterogeneous resources.
Figure 14.1 summarises Technology Integration Points for some example technologies:
(not reproduced yet)
Figure 14.1: Example of Technology Integration Points [10]
Up
Essentially, figure 14.1 indicates that from the technologies selected, a number of technology areas will need to be integrated. These are:
  • Internet/Web based services;
  • Object Request Broker (CORBA) based services;
  • Telecom based Manager/Agent services (e.g. CMIP/GDMO and SNMP/SMI).
In order to provide adequate points of integration between these areas of technology, a number of Integration Points (IPs) have been identified - as outlined in table 14.1:
Managed Objects (GDMO/SMI) Management Services (CMISE/SNMP) Java Objects Web Browser (HTTP/HTML) TMN Agent
CORBA Objects IP1IP4IP3
CORBA Services IP2
TMN Manager IP5
IP1
Provides mapping of objects defined in CORBA/IDL to managed objects defined in GDMO or SMI.
IP2
Provides mapping of appropriate CORBA Services to CMIS and SNMP services.
IP3
Provides a mapping of Web Browser technology access to CORBA objects (for situations where this may be needed as an addition to/replacement of Browser access to a database).
IP4
Provides a mapping between Java based objects and CORBA objects.
IP5
Provides a high level convenient programming interface for the rapid development of TMN based manager/agent interactions. It also provides a convenient point of integration if it is necessary to separate out the two sides of the manager/agent interface from the point of view of technology selection. For example, allowing the manager role to perhaps be supported in a Web-based environment, but giving a good point of integration with a TMN based agent.
Up

Up   Top   ToC