METHOD AND ARRANGEMENT IN A COMMUNICATION NETWORK SYSTEM

TECHNICAL FIELD

The present invention relates to a method and an arrangement in a communication network system and, more particular to an arrangement allowing for facilitating communication network system management as well as a method for such facilitation.

BACKGROUND

A network consists of nodes and links. A large network consists of millions of such nodes and links for the purpose of transporting information among and provisioning of services to network users/subscribers. To satisfy such requirement, the network needs to be managed such that all nodes and links perform their functions as designed and planned.

In a network, the nodes (e.g. Network Element-1 (NE-1 ), Network Element-A (NE-A) of figure 2) may be packet data switches (physical nodes) or software processes

(applications) that perform a function. The links (e.g. NEs of figure 2) may be microwave links, submarine cables or simply representation of logical connections among nodes. In a cellular network, the nodes may be radio base stations, handsets etc and the links may be radio links, logical connections of Virtual Private Networks (VPNs), etc.

Further in a network, there are nodes that are not responsible for transporting information or provisioning of service for network user/subscribers. These nodes (e.g. Network Manager (NM) and Domain Manager (DM) of figure 2) manage the network. They install, configure and supervise the nodes and links. They monitor the network and if the network performance falls below some planned threshold, the network managers then initiate a recovery plan involving, for example, reconfigure the nodes, reconfigure user call routes, deactivate faulty nodes and activate backup nodes etc.

The network management architecture (i.e. organization of the NMs, DMs and NEs are subject of various international standardization bodies and organizations such as ITU-T, 3GPP, 3GPP2 and IETF. All these network management architectures share one basic principle in that the (real) nodes and (real) links are represented by software modules. The collection of the software modules is called Management Information Base (MIB) and

is stored and maintained in DMs, Each software module, representing the actual node or link, is called Managed Object Instances (MOIs). The collection of MOIs (i.e. the MID) is a virtual reality of the real nodes and links under management. Applications running in NMs and/or DMs would then manage (supervise and control) the real nodes and links by accessing and manipulating the MOIs.

The organization of the MOIs and the information contained in each MOI are based on a schema. Various international standard bodies publish these so-called schema or network resource model or object model.

In prior art, the MIB, which is a collection of software objects, called MOI, representing managed network resources, managed by DM (see MIB of DM-1 of figure 2) is based on the definition of a defined schema. This schema (or schema definition) cannot change at run time. Or put in another way, the MIB is a collection of MOIs that are instantiated (created) based on the definition of a schema. Such kind of MIB is large. When compared to smaller MIB, large MIB is more difficult to maintain in that:

• It takes more time to synchronize the information hold in the MIB with real network status

• It needs more processing power to satisfy MIB data retrieval, MIB data modification and MIB information search requests, from MIB users • It contains info that some users do not want and this necessitates these users to apply filter to information retrieved from the MIB. Filter processing takes time.

A schema is the data definition of a Managed Information Base (MIB). This definition is for all NEs classes and their relations. The definitions has to support all operational contexts and users (field engineer, network planners, head office operational staff, etc). Prior art schema cannot change at run time. As a consequence, the MIB which is an instantiation of all NEs of the managed network based on the schema definition would be large because it supports twenty-four hours availability seven days a week:

• for all kinds of network management data to satisfy all kinds of users; and, • for the entire network.

SUMMARY

Accordingly, one objective with the present invention is to provide an improved method and arrangement for facilitating communication network system management in which a

network management architecture comprises modules representing a virtual reality of network nodes and network links under management. Organization of said modules and information contained in said modules are based on a pre-determined network management schema, whereby said network nodes and said network links are managed by accessing and manipulating said modules

According to a first aspect of the present invention this objective is achieved through a method as defined in the characterising portion of claim 1 , which specifies that communication network system management is facilitated by a method which performs the steps of modifying said network management schema by reducing the amount of information in said modules and, using said modified network management schema for managing said communication network system.

According to a second aspect of the present invention this objective is achieved through an arrangement as defined in the characterising portion of claim 9, which specifies that communication network system management is facilitated by an arrangement comprising an interface for modifying said network management schema by reducing the amount of information in said modules and, a domain manager for using said modified network management schema for managing said communication network system.

Further embodiments are listed in the dependent claims.

Thanks to the provision of a method and arrangement, which provides a mechanism for modifying the schema at run time, the size of the MIB, visible to Managers, will be smaller and thus facilitating communication network system management.

Still other objects and features of the present invention will become apparent from the following detailed description considered in conjunction with the accompanying drawings. It is to be understood, however, that the drawings are designed solely for purposes of illustration and not as a definition of the limits of the invention, for which reference should be made to the appended claims. It should be further understood that the drawings are not necessarily drawn to scale and that, unless otherwise indicated, they are merely intended to conceptually illustrate the structures and procedures described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, wherein like reference characters denote similar elements throughout the several views:

Figure 1 shows an exemplary communication network architecture;

Figure 2 shows a context diagram according to the present invention;

Figure 3 is a class diagram according to the present invention;

Figure 4 is a flowchart showing the use of one operation provided for managers, which in this example is the use of activateMap(...);

Figure 5 shows another flowchart showing the use of one operation provided for managers, which in this example is the use of createMaplnStorage(...);

Figure 6 is a flowchart of the inventive method according to one embodiment of the invention.

DETAILED DESCRIPTION

Figure 1 depicts a communication network system including a Radio Access Network (RAN), such as the UMTS Terrestrial Radio Access Network (UTRAN) architecture, comprising at least one Radio Base Station (RBS) (or Node B) 15 (two are shown in figure 1 ) connected to one or more Radio Network Controllers (RNCs) 10. The RAN is connected to a Core network (CN) 12. The RAN and the CN 12 provide communication and control for a plurality of user equipments (UE) 18 that each uses downlink (DL) channels 16 and uplink (UL) channels 17. For the reason of clarity, only one uplink channel is denoted 17 and one downlink channel denoted 16. On the downlink channel 16, the RBS 15 transmits to each user equipment 18 at respective power level. On the uplink channel 17, the user equipments 18 transmit data to the RBS 15 at respective power level.

According to a preferred embodiment of the present invention, the communication network system is herein described as a WCDMA communication system. The skilled

person, however, realizes that the inventive method and arrangement works very well on other communications systems using network managements as well.

The communication system further comprises a network management architecture, shown in fig. 2, comprising nodes responsible of managing the network. These nodes install, configure and supervise the nodes and links of the communication system, as described earlier in the background section.

As can be seen in fig. 2, the network management architecture comprises network elements (NEs) 24 which are nodes (network resources) in the communication network system, such as the RNC 10 and the radio base stations 15 shown in fig. 1. The NEs 24 are managed via an interface 23 by a domain manager (DM-1 ) 22, which maintains a managed information base (MIB) 25 that is a collection of software objects called managed object instances (MOIs), each of which is a representation of the managed network resources 24 such as NE-1 , NE-Y. For clarity reasons only one DM is shown in fig. 2, but the skilled person realizes that the architecture may comprise more than one DM. The MIB users, the NMs 20 are represented by NM-1 , NM-2 and NM-3. The MIB 25, or more precisely, the software objects of the MIB 25 are accessible by NMs 20 via the interface-21 in fig. 2.

The organization of the MOIs and the information contained in each MOI are based on a network model or schema. As in prior art, the schema for the MIB 25 in fig. 2 is fixed, i.e. the schema does not change. The MIB schema defines different object classes representing objects in the real network. One example of an object class is cells, i.e. radio network cells. Each class has attributes, which is data describing the class. Example of attributes are: Id, i.e. the identification of the class; Frequency, i.e. which frequency the class uses; Maximum power, i.e. maximum allowed power to use; etc.

According to embodiments of the present invention, a mechanism for modifying the schema at run time is provided and also interactions/operations that may be used by Managers 20 to change the schema definition are provided. The schema is changed when the manager thinks that there is a need to change it, e.g. due to the dimensions discussed below.

The modification of the schema is restrictive in the sense that the change is only to reduce the capability of the schema and, thus, making the MIB visible to managers smaller. As one example: the MIB schema defines a class of object to have 16 attributes. At run time, the MIB schema definition can be modified in that the class of the object will have 9 attributes, instead of the 16 attributes defined originally. This is obtained by disabling or removing attributes from the MOI class definition in the schema. Another example: the MIB schema defines 100 MOI classes. At run time, the MIB schema definition can be modified in that 7 of the 100 MOI classes would not be used. The modification may not be an expansion, such as, to add a new MOI class to the schema or to add a new attribute to an MOI class

All MIB users (i.e. Managers 20) may not use all MIB information and therefore, the schema may be adjusted so that no maintenance is required for MIB information not required by MIB users. The schema modification is achieved along the following dimensions.

• Time: The traffic volume of some part of the network is highly correlated to time of day. In such case, the MIB portion representing a certain network part will use a full schema for the 'busy' hours and reduced schema for the rest of the day so that, abnormality of network operation during busy hour is quicker to detect and diagnose.

• Location: Some part of the network (e.g. a newly installed network segment) may require intensive monitoring while other parts, e.g. parts that are in-service for months and are fully operational according to plan, may require less intensive monitoring. In such case, the MIB portion representing the former part of the network would be the full schema definition and the MIB portion representing the latter part would be using a "reduced schema", i.e. a full schema applies to subnetwork-A while part of schema applies to subnetwork-B.

• Class based: e.g.: disable use of attribute-1 , attribute-6 of MSCFunction IOC; disable notification-7 and notification-2 from EUTRANFunction IOC. When modification is applied on "class based", then all instances of this class are modified.

• Instance based: e.g.: disable use of all VsDataContainer attributes for certain MSCFunctions; disable counter-5, KPI-xyz generation from certain radio base stations. When modification is applied on "instance based", then the specific instance is modified.

• Various combinations of the examples above.

The request to modify the schema is initiated by the manager 20, i.e. when the manager 20 thinks that it is necessary, e.g. due to the dimensions listed above.

According to an embodiment of the invention, all users of the managers of the MIB (e.g. operators, planners of a network operator) have an agreed plan on how to configure the MIB. If a Manager changes the MIB, the changed MIB will be serving all other Managers.

Figure 3 shows an example of major functional components of the invention. An Agent 31 is an entity that interfaces with various managers (not shown in fig. 3) and offers the interface via which the managers and the agent 31 communicate. The Agent maintains two functional components, storage 33 and MIB 25.

The storage 33 holds all Maps designed/created by the Manager. There are two kinds of Maps contained in the storage 33, LocationMap 36 and SchemaMap 35.

A LocationMap 36, identified by an identifier maplD, is a holder of following information:

• maplD; this uniquely identifies this Map instances from all other Map instances inside the Storage 33.

• location; this is the Distinguished Name (DN) of the MOI of the MIB 25. The schema (the third attribute) relates to the subtree identified by this DN attribute.

• schema; this is the schema, collection of class definition and their relations applicable to the subtree identified by the DN of the 2 ^nd attribute.

A SchemaMap 35 is identical to the LocationMap 36 except that there is no location parameter. The Agent 31 holds this missing information, i.e. the location where the schema is applicable. The Agent 31 knows this missing information when it uses the SchemaMap 35 for a particular location in response to attachMap(), described below.

The Agent 31 further maintains the Management Information Base (MIB) 25. As described above, the MIB 25 holds software instances (modules), each of which is a representation of the managed network resource. The one or multiple schemas used (and the 'used' relation is denoted by 38) by the MIB 25 at run time are stored (or contained) in the storage 33 in figure 3, denoted by 37.

The Agent 31 supports 6 operations via the interface 39:

1. queryMapStorage ()

This operation allows the Manager to ask for a listing of the current LocationMap(s) and SchemaMap(s) in Storage 33. The listing contains maps created by all Manager(s). The listing includes the status (e.g. if it is used/active at the moment).

• Input parameter 1 : none

• Output parameter 1 : list of LocationMap • Ouput parameter 2: list of SchemaMap

2. createMaplnStorageQ

This operation allows the Manager to create a new LocationMap or SchemaMap. The Agent stores the newly created map in Storage. • Input parameter 1 : LocationMap or SchemaMap

• Output parameter 1 : It has two legal values. Successful means the map is created. Failure means the map is not created. The failure reason is also provided.

3. deleteMaplnStorageO

This operation allows the Manager to delete a map from Storage.

• Input parameter 1 : list of LocationMap. maplD, list of SchemaMap. maplD.

• Output parameter 1 : It has two legal values. Successful means all identified maps are removed or deleted from Storage. Failure means at least one identified maps is still in Storage. The failure reasons and the map(s) that are still in Storage are provided.

4. queryActiveMaps()

This operation allows the Manager to ask for a listing of identification of active maps. The operation response does not include the (definitions) the actual schema definition, just the identification of the map(s). The Agent returns the list of active LocationMap(s) and SchemaMap(s), i.e. have the 'use' 38 relation in figure 3. In the case of SchemaMap(s), the Agent also, for each SchemaMap identified, supply the location information where the said SchemaMap is being used/applied. • Input parameter 1 : none

• Output parameter 1 : list of LocationMap.maplD(s) and list of {SchemaMap.maplD, location}.

5. activateMap() This operation allows the Manager to activate a set of maps (LocationMap(s) and/or SchemaMap(s)). In the case of SchemaMap, the Manager would also supply the location information.

• Input parameter 1 : locationMapList: This carries a set of maplD(s) (the identifier of the map). • Input parameter 2: schemaMapList: This carries a set of {maplD, location}.

• Output parameter 1 : It has two legal values. Successful means all operation is successful and that all maps are active. Failure means none of the maps supplied are active. The failure reason is also provided. There might be a "partly successful" scenario as well which would be a simpler and more 'fail safe' solution that assured NM, nothing has changed. NM can then try again. The server does not know the possible inter-dependency of members of MapList. So, it is 'not safe' for server to activate one and not the other (partly successful scenario).

6. deactivateMap()

This operation allows the Manager to deactivate active map(s).

• Input parameter 1 : mapList: This carries a set of maplD(s).

• Output parameter 1 : It has two legal values. Successful means the identified map is not active now regardless if it was active or not before the operation. Failure means the identified map is not known or the identified map was active and is still active. The failure reason is also provided.

Figure 4 shows an exemplifying flowchart of how the activateMap(...) operation is used when the manager wants to activate a set of maps: • If the activateMap is valid (or maps are in storage) and activating is a schemaMap, marking the schemaMap as active (step 41 );

• Then, if activating is a locationMap, creating the necessary MOIs in the MIB (step 42);

• Further, if the activateMap is valid (or maps are in storage), activating is not a schemaMap but is a locationMap, creating the necessary MOIs in the MIB (step 42),

Figure 5 shows another example of a flowchart of how the createMaplnStorage(...) (queryMap) operation is used when the manager wants to create a new LocationMap or SchemaMap:

• If createMaplnStorage is valid, storing maps in Storage (step 51 );

According to an embodiment of the present invention, the procedure for facilitating communication network system management in which a network management architecture comprises modules representing a virtual reality of network nodes and network links under management, wherein organization of said modules and information contained in said modules are based on a pre-determined network management schema, whereby said network nodes and said network links are managed by accessing and manipulating said modules, as shown in fig. 6, is as follows:

• receiving a request to modify the network management schema (step 61 ). The request is initiated by the manager;

• determining the request format (step 62), i.e. possible operations (supported by the agent) and its attributes;

• modifying the schema based on the received format (step 63), i.e. reducing the size of the MIB by e.g. disable some attributes;

• using the modified schema for network management (step 64).

Thus, while there have been shown and described and pointed out fundamental novel features of the invention as applied to a preferred embodiment thereof, it will be understood that various omissions and substitutions and changes in the form and details of the devices illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit of the invention. For example, it is expressly intended that all combinations of those elements and/or method steps which perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. Moreover, it should be recognized that structures and/or elements and/or method steps shown and/or described in connection with any disclosed form or embodiment of the invention may be incorporated in any other disclosed or described or

suggested form or embodiment as a general matter of design choice. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.

Expressions such as "including", "comprising", "incorporating", "consisting of, "have", "is" used to describe and claim the present invention are intended to be construed in a nonexclusive manner, namely allowing for items, components or elements not explicitly described also to be present. Reference to the singular is also to be construed to relate to the plural and vice versa.

Numerals included within parentheses in the accompanying claims are intended to assist understanding of the claims and should not be construed in any way to limit subject matter claimed by these claims.