3GPP TR 32.833 V0.6.

0 (2011-06)
Technical Report

3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; Study on Management of Converged Networks (Release 10)

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.

Release 10

3GPP TR 32.833 V0.6.0 (2011-06)

Keywords
FMC, wireline, wireless

3GPP Postal address 3GPP support office address

650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet
http://www.3gpp.org

Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.
2010, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC). All rights reserved. UMTS is a Trade Mark of ETSI registered for the benefit of its members 3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTE is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners GSM and the GSM logo are registered and owned by the GSM Association

3GPP

Release 10

3GPP TR 32.833 V0.6.0 (2011-06)

Contents
Contents....................................................................................................................................................3 Foreword...................................................................................................................................................5 Introduction...............................................................................................................................................5 1 Scope......................................................................................................................................................6 2 References..............................................................................................................................................6 3 Definitions, symbols and abbreviations..................................................................................................7
3.1 Definitions..............................................................................................................................................................7 3.2 Symbols..................................................................................................................................................................7 3.3 Abbreviations.........................................................................................................................................................7

4 Definition of the Problem Space............................................................................................................9 5 Fixed-Mobile Convergence (FMC) Use Cases.....................................................................................11

5.1 Use Cases for common Radio and Transport Management.................................................................................11 5.1.1 Example Deployment Scenario.........................................................................................................................11 5.1.2 FM UC with alarm from underlying transport network....................................................................................11 5.1.3 CM UC addition of new radio network resources............................................................................................12 5.1.4 PM UC supporting PM data correlation from radio and transport networks....................................................13 5.1.5 UC common Management of Radio and underlying Transport Networks.......................................................13 5.1.6 UC Ethernet VLAN provisioning.....................................................................................................................15 5.1.7 UC Alarm monitoring.......................................................................................................................................15 5.2 Use Cases for Converged Networks Management...............................................................................................16 UC Femto Access Management.................................................................................................................................16 5.3 Use Cases for Customer Facing Services Management.......................................................................................17

6 Potential Relationships to other SDOs and Industry Fora...................................................................18 7 Evaluation of Management Convergence Options...............................................................................18
7.1 Facilities...............................................................................................................................................................18 7.1.1 Import facility....................................................................................................................................................18 7.1.1.1 Case 1 usage (case-reference)........................................................................................................................18 7.1.1.2 Case 2 usage (case-derivative).......................................................................................................................18 Case 3 usage (case-containment)...............................................................................................................................19 7.2 Option 1................................................................................................................................................................19 7.2.1 Use ATM transport network case to illustrate the design pattern.....................................................................19 7.2.1.1 Define generic TP (terminating point) and specific TP IOCs in [2]..............................................................19 7.2.1.2 Associate specific link with specific TP in specific NRM IRPs....................................................................20 7.2.2 Apply the design pattern (discussed in 7.1.1) for S1-MME reference point....................................................21 7.3 Option 2................................................................................................................................................................22 7.3.1 Context 22 7.3.2 Procedure 22

8 Management Convergence Recommendations.....................................................................................23 Annex A: Name-Containment Class diagram from TS 32.622 [12]..........................................24 Annex B: Containment Diagram from M4 Network View CMIP MIB Specification.............25 Annex C: Brief description of FNM.....................................................................................................26
6.1 Relations between fragments and Umbrella........................................................................................................26

3GPP

Release 10

3GPP TR 32.833 V0.6.0 (2011-06)

Annex D: Network Management related TISPAN Standards...........................................................27 Annex E: Change history.............................................................................................................28

3GPP

Release 10

3GPP TR 32.833 V0.6.0 (2011-06)

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

Introduction
[Editors Note] TBD.

3GPP

Release 10

3GPP TR 32.833 V0.6.0 (2011-06)

1 Scope
[Editors Note] TBD. The present document

2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 3GPP TS 32.712: "Telecommunication management; Configuration Management (CM); Transport Network (TN) Network Resource Model (NRM) Integration Reference Point (IRP); Information Service (IS)". 3GPP TS 32.742: "Telecommunication management; Configuration Management (CM); Signalling Transport Network (STN) interface Network Resource Model (NRM) Integration Reference Point (IRP); Information Service (IS)". 3GPP TS 32.762: "Telecommunication management; Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Network Resource Model (NRM) Integration Reference Point (IRP); Information Service (IS)". 3GPP TS 32.752: "Telecommunication management; Evolved Packet Core (EPC) Network Resource Model (NRM) Integration Reference Point (IRP); Information Service (IS)". ITU-T X.680 OSI networking and system aspects Abstract Syntax Notation One (ASN.1) 3GPP TS 32.642: "Telecommunication management; Configuration Management (CM); UTRAN network resources Integration Reference Point (IRP); Network Resource Model (NRM)". ATM Forum, Technical Committee, Network Management, M4 Network View CMIP MIB Specification: CMIP Specification for the M4 Interface, Sep, 1995 3GPP TS 32.622: "Telecommunication management; Configuration Management (CM); Generic network resources Integration Reference Point (IRP); Network Resource Model (NRM)". ITU-T Y.2091: Terms and definitions for Next Generation Networks S5vTMFa081 FMC federated network model (FNM) v1.1

[1] [2]

[3]

[4]

[5] [9] [10] [11] [12] [13] [14]

3GPP

Release 10

3GPP TR 32.833 V0.6.0 (2011-06)

3 Definitions, symbols and abbreviations

3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. eNodeB Fixnet NodeB LTE equivalent to the BTS Fixed network UMTS equivalent to the BTS

In ITU-T, a definition is provided for Fixed Mobile Convergence (FMC) which applies in general to references to FMC in this specification. fixed mobile convergence [ITU-T Q.1762]: In a given network configuration, the capabilities that provide services and application to the end-user regardless of the fixed or mobile access technologies being used and independent of the user's location. In the NGN environment, it means providing NGN services to end-users regardless of the fixed or mobile access technologies being used (Rec. Y.2091)

3.2 Symbols
For the purposes of the present document, the following symbols apply: None

3.3 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [x] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905 [1]. AAA AN ATM BNG BRAS BSC BTS DNS DSL DSLAM DWDM Eth FMC FN FNO GE GGSN HLR IMS IP LTE MME MPLS MWR NM P-GW PDH Authentication, Authorization and Accounting Access Network Asynchronous Transfer Mode Broadband Network Gateway Broadband Remote Access Server (synonym BNG) Base Station Controller Base Transceiver Station Directory Name Service Digital Subscriber Line Digital Subscriber Line Access Multiplexer Dense Wavelength Division Multiplexing Ethernet Fixed-Mobile Convergence Fixed Network Fixed Network Operator Gigabit Ethernet Gateway GPRS Support Node Home Location Register IP Multimedia Subsystem Internet Protocol Long Term Evolution Mobile Management Entity Multiprotocol Label Switching Microwave Radio Network Management PDN Gateway Plesiochronous Digital Hierarchy

3GPP

Release 10

3GPP TR 32.833 V0.6.0 (2011-06)

PON RG RNC SGSN SeGW S-GW SHD TP UC WDM

Passive Optical Network Residential Gateway Radio Network Controller Serving GPRS Support Node Security Gateway Serving Gateway Synchronous Digital Hierarchy Terminating Point Use Case Wavelength Division Multiplexing

3GPP

Release 10

3GPP TR 32.833 V0.6.0 (2011-06)

4 Definition of the Problem Space

[Editors Note] Describe here what is meant with Management Convergence. What are the different areas to be looked at? Follow a use case driven approach. Services offered to end users use resources from networks of multiple technologies typically operated by more that just one type of network service operator. Management of these services and these networks face several challenges. One of the challenges is that the management standards for these technologies are defined at different standardization fora and alike. Another challenge is that different parts of the network are also managed by separate management systems that do not communicate with each others and are usually also operated by different type of network service providers. The figures below try to present a holistic view towards fixed and mobile networks. The figures are informative and do not try to describe the whole complexity of the fixed and mobile networks. Also different roles such as fixed access provider, internet service provider, mobile network operator, transport provider are not considered. Instead the perspective is topology- and site oriented. The figures show the: most usual sites with typical interconnections typical functions/products within the sites

Figure 4.1: FMC Problem Space: Typical cites and interconnections in fixed and mobile networks

3GPP

Release 10

10

3GPP TR 32.833 V0.6.0 (2011-06)

Figure 4.2: Detailed FMC Problem Space: Typical functions and products in fixed and mobile networks It should be noted that sites and functions are not all mandatory but may vary due to specific implementations and operator demands. In contrast to many segmented and abstract/functional network presentations, this blueprint intends to help understanding networks and business close to real life. Consequently it might be useful as a basis for further end-to-end activities, improvements and decisions.

3GPP

Release 10

11

3GPP TR 32.833 V0.6.0 (2011-06)

5 Fixed-Mobile Convergence (FMC) Use Cases

[Editors Note] Identify here operational problems for which automated or semi-automated solutions can be provided.

5.1 Use Cases for common Radio and Transport Management

[Editors Note] Identify operational problems that can be solved and automated by a combined/common management of the radio and transport network

5.1.1 Example Deployment Scenario

The Figure 5.1.1.1 below shows a simplified example for a typical deployment scenario in today's networks. It depicts network elements of the radio network controlled by the mobile network operators (MNO) Element/Domain Managers (EM/DM) and network elements of the transport network controlled by the transport network operators (TNO) EM/DM. The MNO and the TNO may or may not be the same operator and there also may or may not be a common network management (NM) layer on top of the radio network and the transport network specific EMs/DMs. The use cases in the following sections are based on this deployment scenario.

Figure 5.1.1.1: Example deployment scenario for common radio and transport network use cases.

5.1.2 FM UC with alarm from underlying transport network

Scenario Radio network is operated by a Mobile Network Operator (MNO) and transport network by a Transport Network Operator (TNO). The MNO does not have control over the transport network. In a radio network alarm condition it is useful to know if there is an alarm condition also in the underlying transport network. Network Context The MNO manages transceiver type and controller type Network Elements (NE) of the radio network.

3GPP

Release 10

12

3GPP TR 32.833 V0.6.0 (2011-06)

The TNO manages the wireline mobile backhaul between the transceiver and the controller type NEs of the radio network. Transport network has edge nodes both at the transceiver and controller sides of the transport network. Edge node is assumed to be a gateway/interface node between the radio and the transport networks. Description The MNO detects alarms at a transceiver type NE and at a controller type NE. The MNO starts to identify the root cause for the problem. The potential problem may be in the radio network but alarms from the transceiver and the controller type of NEs rather indicate a possibility of a problem of mobile backhaul (transport network). The related transport network alarms would be needed for end to end investigation of the potential problem. Implications In order to solve the root cause for the radio network problem efficiently: o The MNO needs to get information on the alarms in the underlying transport network. o The MNO needs to be able to correlate the transport network alarms with the corresponding radio network alarms.

5.1.3 CM UC addition of new radio network resources

Scenario Radio network is operated by a Mobile Network Operator (MNO) and transport network by a Transport Network Operator (TNO). The MNO does not have control over the transport network. When new radio network resources are added configuration information needs to be transferred between the MNO and the TNO. Network Context The MNO manages transceiver type (e.g. NodeB) and controller type (e.g. RNC) Network Elements (NE) of the radio network. The TNO manages the wireline mobile backhaul between the transceiver and the controller type NEs of the radio network. Transport network has edge nodes both at the transceiver and controller sides of the transport network. Edge node is assumed to be a gateway/interface node between the radio and the transport networks. Description The MNO is managing a radio network with e.g. 80 transceiver type NEs and a required number of controller type NEs. The MNO wants to add 4 new transceiver type NEs using the same transport network. Implications In this scenario it is assumed that the radio network of the MNO is already using the transport network of the TNO for service offering. In order to add new radio network resources using the transport network: o The MNO and the TNO need to agree on a service level agreement (SLA) for the new radio resources. o When the new radio resources are available the MNO needs to provide the TNO with required information for configuration purposes. o The TNO needs to configure the transport network to satisfy the requirements set by the MNO.

3GPP

Release 10

13

3GPP TR 32.833 V0.6.0 (2011-06)

5.1.4 PM UC supporting PM data correlation from radio and transport networks

Scenario Radio network is operated by a Mobile Network Operator (MNO) and transport network by a Transport Network Operator (TNO). The MNO does not have control over the transport network. MNO uses PM counters to analyse offered service level and the network status. Network Context The MNO manages transceiver type and controller type Network Elements (NE) of the radio network. The TNO manages the wireline mobile backhaul between the transceiver and the controller type NEs of the radio network. Transport network has edge nodes both at the transceiver and controller sides of the transport network. Edge node is assumed to be a gateway/interface node between the radio and the transport networks. Description MNO collects and analyses PM information from radio network. MNO sees a degrading trend of service level or an increasing trend of error level. The potential problem may be in the radio network but measurements from the transceiver and the controller type of NEs rather indicate a problem of mobile backhaul (transport network). The transport network PM would be needed for end to end investigation of the potential problem. Implications In order to have a good end to end view and supporting efficient decision making in radio network: MNO needs to get PM information from the transport network either regularly or per request.

5.1.5 UC common Management of Radio and underlying Transport Networks

Scenario Mobile network may use transport network (e.g. IP transport network etc.) to provide the transport function. For the converged network management which focuses on managing the mobile network should have a unified interface, to manage the mobile network and its supporting transport network. Network Context The mobile network and its supporting transport network. Implications The relation between mobile managed resource and transport managed resource needs to be known by the IRPManager.

Description The FMC management for common radio and transport management include that: 1. 2. 3. Monitoring and managing the alarms information of converged network which includes mobile network and its supporting transport network. Monitoring and managing the performance information of converged network which includes mobile network and its supporting transport network. Monitoring and managing the configuration information of converged network which includes mobile network and its supporting transport network.

3GPP

Release 10

14

3GPP TR 32.833 V0.6.0 (2011-06)

Converged network management (IRPManager)

Mobile network

Supporting transport network

Figure 5.1.1.1: Converged network management

3GPP

Release 10

15

3GPP TR 32.833 V0.6.0 (2011-06)

5.1.6 UC Ethernet VLAN provisioning

Scenario Operator, as a result of a planning exercise, realizes that additional infrastructure capacity is required to support service growth (e.g. to support new X2 links). The capacity, in the form of an Ethernet VLAN needs to be created and activated across a mix of wireline NEs and wireless NEs. The Ethernet VLAN is initially simply point to point. Network Context The Ethernet VLAN terminates in a wireless equipment and traverses several wireline equipments to terminate at wireline NE. Implications It would appear that at a minimum: The relation between wireless NE and wireline NE needs to be known to the IRPManager. Some configuration parameters need to be sent to the wireless NE.

Description As a result of the activation the IRPManager should be able to discover the Ethernet VLAN and its path related to the supported X2 link (as in our example). See more in 4.6.3.

5.1.7 UC Alarm monitoring

Scenario Operator needs to know if an alarmed radio resource, e.g. End Point instance, is related to or not related to any alarmed wireline resources. Network Context The wireline circuit, terminating at both ends in wireless NEs, traverses several wireline NEs. Implications It would appear that at a minimum: o Operator needs to know (e.g. the identifier of) the wireline network edge node resource (e.g. circuit identifier) that is related to the alarmed radio resource.

Description Knowing the wireline network edge node resource identifier, operator can discover the identifiers of all wireline resources supporting the alarmed wireless resources. Knowing their identifiers, operator can know if the identified wireline resources are in alarmed condition and if so, determine if the alarm condition is causing the alarm condition of the wireless resource.

3GPP

Release 10

16

3GPP TR 32.833 V0.6.0 (2011-06)

5.2 Use Cases for Converged Networks Management

[Editors Note] Describe here examples of converged networks like the ones specified by BBF and TISPAN. Based on this understanding identify operational problems and scenarios (aspects of mobile/core backhaul are addressed by 5.1).

UC Femto Access Management

Note: This is one possible use case scenario for femto access management. There are other possible scenarios as well. Scenario An operator operating both mobile and fixed networks offers for its customers a service where the end user can take at home into use a femto access point (Home Node B) to achieve better service quality over mobile networks. The femto access point is attached to an ADSL connection and connects to the operators mobile core via fixed network. The figure below illustrates the use case with a service flow example showing network elements and functions relevant for the scenario. This use case is derived from the Detailed FMC Problem Space (Figure x.x) but the network elements are limited here to the minimum relevant for the femto use case. There could be e.g. more network elements in between AN and BNG/BRAS (e.g. aggregation stages). Note that depending from the deployment the service flow could look different and also the network elements involved could be different.

Figure 5.2.1.1: Femto use case service flow with relevant network elements

Network context When managing the femto access service the operator needs to ensure that the network elements belonging to both mobile and fixed networks are able to provide the necessary service quality and resources. The most relevant network elements from management point of view specific for this scenario are:

3GPP

Release 10

17

3GPP TR 32.833 V0.6.0 (2011-06)

At home premises o o a femto access point (Home Node B) typically managed by mobile network management systems a Residential Gateway (RG) typically managed by fixed network management systems

At local office o a Access Network node (AN) typically managed by fixed network management systems

At the central office o a Broadband Network Gateway (BNG), typically managed by fixed network management systems

At mobile control cite o a Femto Gateway (Home Node B Gateway), typically managed by the mobile network management systems

Here it is assumed that the underlying network infrastructure has been already configured so that the service offering can take place. Not all the relevant network elements are considered in this use case, e.g. the IP-Core switch as well as several other network elements at the mobile control and the mobile core site. Implications The relation between the abovementioned network elements in mobile and fixed networks need to be know to the operators management systems. Description From management point of view the operator needs to monitor these relevant network elements and also needs to be able to e.g. correlate any alarms between them.

5.3 Use Cases for Customer Facing Services Management

[Editors Note] Describe here examples of customer facing services

3GPP

Release 10

18

3GPP TR 32.833 V0.6.0 (2011-06)

6 Potential Relationships to other SDOs and Industry Fora

[Editors Note] Identify here potentially applicable definitions of other SDOs and Industry Fora for possible reuse by 3GPP to enable Management Convergence (e.g. models/specifications already available and related to the FMC use cases listed in section 5; potential SDOs/Industry Fora: ITU-T, MEF, IETF, BBF, TMF).

7 Evaluation of Management Convergence Options

[Editors Note] Identify and evaluate here potential Management Convergence Options (e.g. identify applicable external models and how to interact with such; identify additions to 3GPP specifications if no external methods exist). Reference [14] defines the overall architecture of a Federated Network Model (FNM). It identifies the major components (called models) and their relations among them. Refer to Annex C for ease of reference. Section 7.1 describes the types of relation (called facilities) that can be used in R0, R1, R2, R3, R4, etc. Section 7.2 illustrates usage of these facilities in R0, R1, R2, etc. The author of a particular model (e.g. author of the 3GPP wireless NW concrete model), when relating its classes with classes of other models, need not use all facilities identified in Section 7.1 However, the author must, when relating its classes with classes of other models, use the facilities identified in Section 7.1.

7.1 Facilities
The facilities identified here are used for stage 2 (e.g. IS) platform-independent-model level usage. They are not used in stage 3 (e.g. SS) platform-specific-model level usage.

7.1.1 Import facility

This facility allows a model, e.g. the 3GPP wireless NW concrete model such as EUTRAN NRM IRP IS to use a network resource modelled class defined elsewhere, e.g. in Umbrella model or other concrete model. There are three such usage cases.

7.1.1.1

Case 1 usage (case-reference)

This facility allows a class defined in one model to refer (point to) class defined in another model. Suppose model-A has class-A1; model-X has class-X1 and class-A1 needs to point to class-X1. Do: In Model-A IS, imports model-X::class-X1. In Model-A IS, Class-A1 has an attribute that contains the Distinguished Name of model-X::class-X1. In Model-A SS, not to define any definition of model-X::class-X1.

7.1.1.2

Case 2 usage (case-derivative)

This facility allows a class defined in one model to derive itself from a class defined in another model. Suppose model-A has class-A4; model-X has class-X1 and class-A4 needs to be a derivative of class-X1. Do:

3GPP

Release 10

19

3GPP TR 32.833 V0.6.0 (2011-06)

In Model-A IS, imports model-X::class-X1. In Model-A IS, Class-A4 inherits from the imported class. In Model-A SS, the authors decide, on case by case basis, if its SS should define its imported class (i.e. ignoring the fact that the imported class SS exists somewhere else) or not.

Case 3 usage (case-containment)

This facility allows a class defined in one model to contain (or to be name-contained by) a class defined in another model. Suppose model-A has class-A4; model-X has class-X1 and class-A4 needs to name-contain (or to be name-contained by) class-X1. Do: In Model-A IS, imports model-X::class-X1. In Model-A IS, class-A4 name-contains (or to be name-contained by) the imported class. In Model-A SS, the authors decide, on case by case basis, if its SS should define a definition of the imported class (i.e. ignoring the fact that the imported class SS exists somewhere else) or not.

7.2 Option 1
7.2.1 Use ATM transport network case to illustrate the design pattern
7.2.1.1 Define generic TP (terminating point) and specific TP IOCs in [2]

Replace the Figure 4.2.1.1: Transport Network NRM Containment/Naming and Association diagram in [2] with the one below (cardinality not shown):
<<InformationObjectClass>> ManagedElement
(from TS 32.622)

<<InformationObjectClass>> TransportNetworkInterface

R2 <<InformationObjectClass>> GenericPTP R1 <<InformationObjectClass>> GenericCTP {XOR} R3

<<InformationObjectClass>> ExternGenericCTP

<<InformationObjectClass>> GenericCTP

Figure 7.1.1.1.1: Transport Network NRM Containment/Naming and Association diagram

3GPP

Release 10

20

3GPP TR 32.833 V0.6.0 (2011-06)

The GenericCTP (generic channel termination point) and GenericPTP (generic path termination point) are potential IOCs that can/should be aligned with TMF SID based TerminationPoint class (which is based on ITU-T M3100). The R1 represents a multiplexing relationship (as defined today), i.e. multiple CTPs are multiplexed onto one PTP. The R2, R3 represent a different type (not same type as R1) of relations that are not yet defined by Release 10 of [2]. When two CTPs are related, it means that the information (e.g. bits) coming out of one CTP is received by the related CTP (and vise versa). So, if RNCFunction has (via a TransportNetworkInterface) an ATMChannelTerminationPoint-A which is related to another ATMChannelTerminatedPoint-X, most probably the latter is not that of NodeBFunction. The latter can be an ATMChannelTerminationPoint of an element (e.g. ATM switch) of the ATMNetwork (see Annex A of [2].) Today, a MIB can contain IOC instances of names using ExternXyz or Xyz. All the instances whose names using Xyz are within the management scope of the IRPAgent maintaining the MIB. The ExternXyz instances are representation of entities that are outside the management scope of the subject IRPAgent. For the FMC work, we would extend the capability (or semantics) of ExternXyz to represent entities that are modelled (or defined) by another SDOs specification and whose definition is recommended for use by 3GPP to support FMC network management. We suggest the following attributes that are essential for this ExternXyz
Attribute name id externalEntityId Read Qualifier M M Write Qualifier M M Comments DN of the IOC instance Identification of the entity represented by ExternalXyz. The identification is primarily useful for the external domain manager managing that external entity. If the external domain manager is IRP compliant, then this attribute carries a DN. If the external DM is IRP compliant, this carries an IRPVersion. If it is not, then it is a string whose precise syntax is TBD (we have to first identify the SDO involved and understand its way of naming/identifying model specifications.)

modelSpecificationId

7.2.1.2

Associate specific link with specific TP in specific NRM IRPs

Add the ATMChannelTerminationPoint IOC in Figure 6.2.1.4 of [3]. Make an association between it and IubLink as in Figure 7.1.1.2.1.
<<InformationObjectClass>> ATMChannelTerminationPoint
(from TS 32 712)

associatedWith

<<InformationObjectClass>> IubLink

Figure 7.1.1.2.1: Association between ATMChannelTerminationPoint and IubLink

3GPP

Release 10

21

3GPP TR 32.833 V0.6.0 (2011-06)

7.2.2 Apply the design pattern (discussed in 7.1.1) for S1-MME reference point
This section is an illustration on using the design pattern (discussed in 7.1.1) for links used in Reference Point S1-MME. Add the XyzChannelTerminationPoint IOC in Figure 6.2.1.3 of [5]. Make an association between it and Link-ENB_MME as follows. Note that the name XyzCTP used here is simply a place-holder-name for now. This IOC is either defined by SA5 in [2] or will be defined by an SDO (yet to be identified) and recommended for use in [2]. This exact name of this IOC will be decided later.

<<InformationObjectClass>> MMEFunction

S1-MME ref point

<<InformationObjectClass>> Link_ENB_MME

associatedWith <<InformationObjectClass>> XyzCTP

(from T S 32 712)

<<InformationObjectClass>> ENBFunction
(from TS 32.762)

Figure 7.1.2.1: Extended EPC NRM Containment/Naming and Association_2

3GPP

Release 10

22

3GPP TR 32.833 V0.6.0 (2011-06)

7.3

Option 2

7.3.1 Context
The following is a description of the context under which such pattern use is appropriate: IRPAgent-A has a management scope (responsibility) over mobile and transport network resources. The mobile network resource model is developed and maintained by 3GPP/SA5 while the transport network resource model is developed and maintained by another organization.

The approach is to use SubNetwork IOC to name-contain the transport network resource model. Using a hypothetical ATM transport network resource as an example, the ATM transport network resource model would take the place of the <<ProxyClass>>Any (of [13]). See Appendix A for ease of reference.

7.3.2

Procedure

To illustrate the use of this pattern we use a hypothetical case when UTRAN link resources [10] are supported by ATM transport services, defined by the ATM model [11] (see Appendix B), originally designed in ATM Forum but now maintained by BBF. 1) Create a new TS and in this hypothetical case, the ATM NRM IRP. 2) In the new TS, make Import statements to import all relevant Managed Object Class (see Note) definitions and their corresponding Name Bindings found in [11], in particular, those of vcLayerNetworkDomain and vpLayerNetworkDomain. Note 1: The term Managed Object Class in [11] encompasses the meaning of the two terms used in IRP Framework, namely Managed Object Class and Information Object Class. 3) In the new TS, declare (e.g. draw in the Class Diagram) vcLayerNetworkDomain and vpLayerNetworkDomain classes to be name-contained by SubNetwork IOC. 4) Make sure the ATMChannelTerminationPoint IOC of [10] has all the attributes of atmNetworkCTP MANAGED OBJECT CLASS of [11]. Note 2: The ATMCHannelTerminationPoint IOC does not exist in current version of [10]. It will be present in future version when Option 1 (described in section 4.1 and 4.2 of [4] is implemented in [10].

3GPP

Release 10

23

3GPP TR 32.833 V0.6.0 (2011-06)

8 Management Convergence Recommendations

[Editors Note] Identify and evaluate here potential Management Convergence Options (e.g. identify applicable external models and how to interact with such; identify additions to 3GPP specifications if no external methods exist).

3GPP

Release 10

24

3GPP TR 32.833 V0.6.0 (2011-06)

Annex A: Name-Containment Class diagram from TS 32.622 [12]

Here is a class diagram extracted from [12].

+manager 0..n <<InformationObjectClass>> ManagementNode 0..n 1 <<names>> 0..n 0..n <<names>> 0..n <<InformationObjectClass>> MeContext 0..1 <<names>> <<names>> 1 1 0..1 <<names>> 0..1 <<names>> 1 0..n <<Informati onObjectClass>> SubNetwork 1 <<names>> 1 <<names>> 0..n <<ProxyClass>> Any ManagementScope

0..n <<names>> <<InformationObj ectClass>> Link

<<InformationObjectClass>> IRPAgent 1

0..n <<names>>

<<names>>

1..n <<SupportIOC>> ManagedGenericIRP

(from 32.312)

0..1 1

0..n 0..n +subordinate

<<Informati onObjectClass>> ManagedElement

<<ProxyClass>> Any 1 <<names>> <<Informati onObjectClass>> Top 1 0..n <<InformationObjectClass>> VsDataContainer 1 <<names>>

<<InformationObjectClass>> ManagedFunction

1 <<names>> 0..n <<ProxyClass>> Any <<InformationObjectCl ass>> EP_RP

An optional note that captures the constraints that this Any represents.

3GPP

Release 10

25

3GPP TR 32.833 V0.6.0 (2011-06)

Annex B: Containment Diagram from M4 Network View CMIP MIB Specification

The following is the Containment Diagram from [11].

3GPP

Release 10

26

3GPP TR 32.833 V0.6.0 (2011-06)

Annex C: Brief description of FNM

This Annex contains extracts from section 6 of [14] that briefly highlights the FNM architecture related to models for FNM NM management.

6 Elements of the FNM This section describes the two key elements of FNM in terms of fragment relations (6.1) and production of model definitions specifications (6.2). FNM is a Federation of Models for the purpose of End-to-End Management, consisting of an Umbrella Model and a series of Domain/Technology-specific Concrete Models. The Umbrella Model provides abstract definitions applicable across Domain/Technology-specific Concrete Models to enable end-to-end consistency of such definitions (it is described as abstract in the sense that its components are inherited by Domain/Technology-specific Concrete Models, and that it is not designed for the purpose of partial or full instantiation of its components and therefore not sufficient to provide meaningful network management service). Domain/Technology-specific Concrete Models are described as concrete models in the sense that their instantiation is necessary to provide meaningful management services. These Domain/Technology-specific Concrete Models inheriting common definitions from the Umbrella Model for the purpose of end-to-end consistency of management information semantics. In addition, these Domain/Technology-specific Concrete Models have defined relationships between each other to enable end-to-end monitoring and management of a converged network.

6.1 Relations between fragments and Umbrella

This section is a graphical representation of the FNM in terms of relation between fragments and the Umbrella. There are two areas under study currently: The definitions of the classes inside the Umbrella. The definitions of relation (R0) used between various classes in fragments and the Umbrella classes.

We aim to have identical R0 for use by all fragments. The relation is not symmetrical in that the Umbrella classes need not have knowledge of its usage by fragment classes. This would guarantee a form of consistency (e.g. resource management style, paradigm) for managing mobile managed resources, as well as other managed resources such as transport managed resources.
Umbrella model

R0 : Import / reference
R0
R0

R0

R0

R0

3GPP2 Wireless NM concrete model

BBF ATM NW & device concrete model

MTOSI wireline 3GPP wireless NW concrete model NW concrete model

MEF MET concrete model

Figure C.1: Relation between fragments and Umbrella

3GPP

Release 10

27

3GPP TR 32.833 V0.6.0 (2011-06)

Annex D: Network Management related TISPAN Standards

There are activities in TISPAN for Converged Management (NGN is equivalent to converged management). The following documents provide high level definitions and scenarios documented by TISPAN. These should be treated as references as work is progressed for converged management in 3GPP. 1. TR 188 004 is the starting point. It provides the NGN Management Vision. With the NGN network architecture and eTOM as given, it considers customer requirements, business requirements and regulatory aspects and derives a high level view on NGN management. 2. TS 188 003 provides NGN Management requirements. They are collected from a variety of sources and are consolidated into a set of unique requirements grouped into a number of classes 3. TS 188 001 specifies the NGN Management architecture.

4. TS 188 005-1 contains the requirements for the NGN Network Resource Model. -2 contains the NRM IS specification. All these docs are publicly available via http://pda.etsi.org/pda/queryform.asp

3GPP

Release 10

28

3GPP TR 32.833 V0.6.0 (2011-06)

Annex E: Change history

Change history
Date 2010-08 2010-10 2010-10 2010-12 2011-01 2011-03 2011-06 TSG # -------TSG Doc. -------CR -------Rev -------Subject/Comment Skeleton and material from S5-102223 Updates from Converged Management Ad-Hoc MCC/az Clean-ups Additions from S5-103109 and S5-103110 (SA5#74) Additions from S5-110505 (SA5#75) Additions from S5-111201, S5-111306 (SA5#76) Additions from S5-112089, S5-111870, S5-111871, S5-111872 (SA5#77) Old -0.1.0 0.2.0 0.2.1 0.3.0 0.4.0 0.5.0 New 0.1.0 0.2.0 0.2.1 0.3.0 0.4.0 0.5.0 0.6.0

3GPP