Method for comparing attribute values of controllable object expressions in a network element
3 claims: 1 independent, 2 dependent
- 1A method for selecting a target group for an operation applied to a network element (NE) of a communication network, the method comprising the steps of - receiving from a network management element information on the operation and on the first target group (S), which is indicated as a group of object instances contained in the memory of the network element, and as comparison criteria of object instance attributes, the criteria containing reference values, - comparing the attribute values of object instances belonging to the first target group to said reference values, and - selecting the final target group from among those object instances in the first target group (S) that have attributes fulfilling the received comparison criteria, characterized in that - the attribute of an object instance is compared by - reading a semantic data which has been prestored in the network element memory, and which is associated with the attribute, - searching the associated attribute value of the object instance from the network element, and - comparing the attribute value to the received reference value by utilizing the semantic data read.
36 paragraphs, as filed
0001The present invention in general relates to management systems of communication networks. An example of such a management system can be found in for example US-A-5 317 742. More specifically, the invention concerns a method according to the attached claim 1 for selecting a target group for an operation applied to a network element of a communication network.
0002The network management system referred to above may in practise be of the type illustrated in figure 1. Network operators, who are positioned at operation centers OC, use network management workstations WS which are connected to a separate workstation network WSN, such as, for example, an Ethernet network. Typically, the management system is distributed in several computers of the workstation network, and they have an access to a database DB which includes the information required for the management of the network. Via a Q3 interface determined in international standards, the management system is connected, for instance, to a mobile network MN which may comprise as network elements NE a mobile services switching center MSC, a base station controller BSC, a base station BTS and a mobile station. The connection to the managed network is established by means of a data communication network DCN. The managed network may as well be any communication network, for example a combined SDH/PDH network.
0003A CMISE application service element (CMISE = Common Management Information Service Element), used in OSI communication of Q3 interface in network management, provides the application process with a SCOPE/FILTER function (cf. ISO/IEC-9596-1 Information Technology - Open Systems Interconnection - Common management information protocol - Part 1:Specification) . The purpose of the function is to select a sub-group among the managed object instances, to which sub-group a CMIP operation (CMIP = Common Management Information Protocol), such as a m-Get, is applied.
0004The managed objects in the network element form a tree-like hierarchical structure, which is stored in the memory of the network element, and whose nodes contain the object instance and attributes relating thereto. In SCOPE/FILTER function, the SCOPE condition is used for demarcating the CMIP operation to refer to a subtree in the tree (MIT, Managed Information Tree) of the managed object instances. This takes place by the name, i.e. DN (Distinguished Name), of the subtree root being given in the operation. To each object instance functioning as a node for the subtree, the FILTER condition of the CMIP operation is applied separately. The values of the object instance attributes must fulfil this condition prior to applying the CMIP operation to the object instance. Following the application of SCOPE and FILTER conditions, the group of those object instances to which the CMIP operation relates has been established.
0005In testing whether the values of the object instances meet the FILTER condition, a comparison is carried out in which the attribute values of the object instances are compared to specific reference values. Without a general-purpose testing mechanism, a separate, specific comparison function need to be created for each type of attribute in the network element. For carrying out the aforementioned, the network element must have a large memory capacity. As far as large network elements are concerned, typically having hundreds or even thousands of managed objects, this complicates memory management and slows it down, because the overall memory capacity required for carrying out the comparison expands to large measures. As regards small network elements, a memory requirement such as this is also emphasized in economical sense, because in a strive for implementing small network elements (for example, mobile phones) as economically as possible, a memory expansion of just one byte bears significance.
0006For the above reasons, in the implementation of the FILTER condition, a general purpose solution should be the aim, i.e., how to implement the testing of the FILTER condition in a network element by a general-purpose manner. The object is to implement a function which is able to determine, on the basis of the FILTER condition of the CMIP operation and the attribute values of the object instance, whether the attribute values of the object instance fulfil the FILTER condition. The form of the FILTER condition is disclosed in the aforementioned standard ISO/IEC-9596-1, p. 16 by means of ASN.1 notation in an ASN.1 data type CMISFilter (ASN.1 = Abstract Syntax Notation One). (The ASN.1 notation is determined in the standard ISO 8824, in which a reader interested in the subject will find a more detailed description.) In practise, the FILTER condition is a regular expression (c.f. expressions in a programming language), which may contain logical operators (AND, OR, NOT), relational operators (=, ≤, ≥), graphic string operators (initialString, anyString, finalString) and set operators (present, subsetOf, supersetOf, non-nullIntersection).
0007The logical operators and the graphic string operators present no problem in testing a general-purpose FILTER condition. Instead, a problem arises concerning the implementation of relational operators and set operators. The difficulties in the implementation of the operators are clearly shown in the following example:
0008The attribute under comparison is assumed to be of type A, represented in ASN.1 notation as follows:<img file="EP0804841B1_D0001.tif" />
0009The aforementioned denotation means that an attribute of type A is a sequence of three variables, B, C, and D, in which B is an integer, C is a real number and D is a graphic string. In the network element, the type A can be implemented as the following struct data type of C language:<img file="EP0804841B1_D0002.tif" />
0010If the comparison function of the attribute values obtains the real value of the attribute and the reference value as a mere octet string, without knowing the structure of the data type in closer detail, it is hard to conceive how to carry out a general-purpose equivalence comparison between the attribute values. Even if two values of the type A had exactly the same meaning, a linear octet string comparison results in an erroneous result if the graphic string pointers of the field D point to different locations. The equivalence comparison only gives a correct result if the comparison function knows that "the data type A is a record whose third field (D) is a pointer to a graphic string, and that the equivalence comparison of the third field takes place between graphic strings addressed by the pointers".
0011Therefore, a problem in testing the FILTER condition stems from the fact that it is not possible to apply a linear octet string comparison to the attribute values contained in the FILTER condition, but the comparer must always, by one way or another, be aware of the data types of the attribute values under comparison.
0012It is an object of the present invention to provide a method by which the aforementioned problem may be avoided. This object is achieved by a method according to the invention, characterized in that a comparison between the attributes of a single object instance is carried out by (a) reading a semantic data which has been prestored in the network element memory, and which is associated with the attribute, (b) searching the associated attribute value of the object instance from the network element, and (c) comparing the attribute value to the received reference value by utilizing the semantic data read.
0013The idea of the invention is to store in the memory of the network element (already at the commissioning stage, for example) the semantic data indicating the data type to be employed in comparing an attribute of a specific object instance. When the network element has been taken into use, and the network management system (operator) is searching for a target group for a CMIP management operation to be applied to the network element, this semantic data is first read at the network element, and then it is utilized in comparing the attribute values of the object instance to the reference values received from the network management system.
0014In the result according to the invention, it is assumed that the data types in accordance with the description language used (e.g. ASN.1) are created into data types of such a programming language for which there exists a translator (for example, C or C++ compiler). This takes place in the network element on the basis of unequivocal rules. In the above, an example is shown of ASN.1 data type and a data type in C language derived from the ASN.1 data type. The instances of data types (in C language, for example) derived from the ASN.1 representations are here referred to as home areas. In the network element, the attribute values are thus represented as home areas.
0015The invention is based on the realization that attribute values can be compared, if the semantic of home areas corresponding to them is known in the network element when the CMIP management operation is being carried out.
0016The invention enables a considerably smaller memory and improves memory management in the network element. Although it is necessary to store a separate semantic data for each type of attribute in the network element, the significant point is that the semantic data can be stored in a considerably smaller memory space than comparison functions, which are required if no general-purpose comparison mechanism according to the invention is available.
0017In the following, the invention and the preferred embodiments relating thereto will be disclosed in detail with reference to figures 2..5 in the attached drawings, in which <ul id="ul0001" list-style="none" compact="compact"><li>figure 1 shows a typical network management system,</li><li>figure 2 shows a tree formed by managed object instances,</li><li>figure 3 shows a semantic tree corresponding to data type A in C language, as described above,</li><li>figure 4 shows an example of a tree-like data structure corresponding to FILTER condition, and</li><li>figure 5 illustrates the operation of the invention in an exemplary situation in which the network operator searches a group of specific subscribers.</li></ul>
0018When a management operation is applied to a network element in a communication network, for which management operation a final target group must be found, the network management system sends, in accordance with the CMIP data transfer protocol, information to the network element on the operation and the target group. The target group is indicated as a group of object instances (i.e. a subtree, whose root node identifier is sent to the network element) and as comparison criteria of object instance attributes, which criteria contain one or more reference values and one or more comparison conditions. Following this, the attribute values of object instances belonging to the target group are compared in the network element to the received reference values by utilizing the received comparison conditions, and the final target group is selected from among those object instances in the original target group that have attributes fulfilling the received comparison criteria.
0019Figure 2 shows a tree of managed object instances, i.e. a MIT, and a group of object instances demarcated therefrom by SCOPE and FILTER conditions. The group of object instances (e.g. a subtree) demarcated by the SCOPE condition is within the broken line S. An arrow indicates the object instances demarcated by the FILTER condition "attribute A has the value 1". Thus, in the example of figure 2, the final target group of the CMIP operation is constituted by the object instances indicated by the arrow.
0020In the following, a more detailed description is given on how the comparison is carried out in the network element on the basis of information received from the network management system.
0021To achieve a general-purpose compare mechanism, the instances of data types, i.e. the home area semantic, is illustrated in the network element as a tree-like data. structure, which may have nodes at several layers. Each node indicates the data type to be employed in comparing the attribute of the object instance. The tree-like data structure corresponds to a parsing tree that the translator (e.g. C compiler) of the programming language used has produced out of the data type of the home area. It is advantageous to produce the semantic tree of the home area at the same time as the ASN.1 data type is being produced into data types of the programming language to be used in the network element. Typically, at this stage, a compiler program is utilized, which translates the ASN.1 representation into data types of the programming language.
0022A semantic tree shown in figure 3 corresponds to the C language version of the type A in the above example. By means of the semantic tree, the structure of the home area in the memory is known in detail. The semantic tree of the home area of the data type A indicates that the home area belongs to "struct" type of C language, and consists of two separate memory areas. The first memory area contains, in sequence, a four-byte-long integer (ASN.1 type INTEGER, C language type "int"), a four-byte-long floating point number (ASN.1 type REAL, C language type "float"), and the initial address of the second memory area (ASN.1 type GraphicString, C language type "char ∗", i.e. graphic string pointer). The second memory area contains the graphic string. Accordingly, by means of the semantic tree, it is known that "the equivalence comparison of the third field D of type A home areas takes place between graphic strings that are addressed by pointers positioned eight bytes from the beginning of the home areas". Correspondingly, the information contained in the semantic tree is utilized when comparing the first and the second fields of the home areas. Thus, by means of the semantic tree, it is possible to carry out a comparison between two attribute values of the type A as a comparison of the home areas corresponding to the attribute values.
0023It is assumed that the FILTER condition of a CMIP operation (e.g. m-Get) is represented in the network element (such as the Nokia DX200 switching exchange) as a tree-like data structure whose leaf nodes include the Object Identifier of the attribute under comparison, the home area of the reference value and the operator. As the operator, there are the relational operator (≤, ≥, =), the graphic string operator (initialString, anyString or finalString) or a string of set operators (present, subsetOf, supersetOf or nonNullIntersection). In the other nodes of the tree, there may be logical operators (AND, OR or NOT). Figure 4 shows an example of a tree-like data structure corresponding to the FILTER condition, in which the condition clause is ((attribute A=a) AND (attribute B≤b)) OR ((attribute C≥c) AND (attribute D is present)).
0024On the basis of the following algorithm, evaluate_filter, it is possible to produce a program code to test the FILTER condition. The recursive algorithm evaluate_filter goes through the tree-like data structure representing the FILTER condition as from the root, and returns the validity of the FILTER condition as the result. The algorithm tests the entire tree-like data structure except the leaf nodes. The test method for the conditions in the leaf nodes will be described in closer detail below. In the algorithm, the testing of the leaf nodes has been replaced by the operation compare_values. The algorithm does not take into consideration a situation in which the tree-like data structure might be erroneous as to its structure.
0025The algorithm evaluate_filter can be determined as follows:<img file="EP0804841B1_D0003.tif" /><img file="EP0804841B1_D0004.tif" />
0026The algorithm evaluate_filter indicates that the testing of logical operators in the FILTER condition presents no problems. The problem occurs in the testing of conditions in the leaf nodes of the tree-like data structure representing the FILTER condition, i.e. fulfilling the operation compare_values located in the evaluate_filter algorithm.
0027The method employed for comparing the attribute values contained in the FILTER condition takes place in two steps, as described above. According to the invention, the first step comprises constructing semantic trees and a directory for all the home areas of attribute values present in the network element. The semantic trees and the directory are stored into the network element. In the second step, the algorithm compare_values, whose functioning is based on the interpretation of the stored semantic trees, is applied to the attribute values being compared.
0028A prerequisite for the implementation of the algorithm compare_values is that the nodes of the semantic tree include the following information: the identifier of the ASN.1 type corresponding to the home area, the identifier of the home area type, the offset for the fields of a record type home area from the beginning of the home area, and the size of the home area. In addition, there must exist a directory by means of which the Object Identifier registered to the attribute can be associated with the semantic tree of the home area of the attribute. Figure 3 illustrates an example of a home area semantic tree.
0029The principle of the attribute value comparison is illustrated by the algorithm compare_values. The algorithm is presented in a simplified form, and only equivalence comparison is treated in it. For example, the ASN.1 types SET and SET OF are not treated. A person skilled in the art is, however, able to formulate a complete algorithm on the basis of the description disclosed here. The leaf node of the tree-like data structure of figure 4 representing the FILTER condition is supplied as an input to the algorithm compare_values. The leaf node contains the Object Identifier of the attribute employed in the comparison, the relational operator and the attribute value employed in the comparison. In the algorithm, it is assumed that the attribute value corresponding to the attribute identifier can be retrieved when the comparison is started. As a result, the algorithm provides information on the success or failure of the attribute value comparison. The algorithm does not take into account any possible error situations. The algorithm compare_values calls a recursive auxiliary algorithm compare_home.<img file="EP0804841B1_D0005.tif" /><img file="EP0804841B1_D0006.tif" /><img file="EP0804841B1_D0007.tif" />
0030As disclosed above, the comparison program of the network element reads the identity of the received attribute, reference value and the data type semantic. Following this, the comparison program requests the actual value of the attribute from a separate adaptation program (which contains the information on where the attributes can actually be retrieved, and which is able to return the attribute value as the correct data type) and carries out the comparison. As a result, those object instances are obtained whose attributes matched, and which the operation therefore is applied to.
0031To clarify the above, the following will examine a practical example with a telephone exchange as the network element. The network element contains a subscriber register, storing information on the subscribers connected to the network element. At the network management interface, the subscriber is represented by the object class "Subscriber", having the attributes "Line number" and "Directory number". The example is imaginary, but the attribute "Directory number" could refer, for example, to the number indicative of the subscriber line during signalling, and the "Line number" could be the identifier of an extension line within the network element. For the attribute "Line number", an ObjectIdentifier {1 2 3} is registered, and for the attribute "Directory number" the identifier {1 2 4}. In ASN.1, the attributes are represented as follows: <ul id="ul0002" list-style="none" compact="compact"><li>Line number :: = INTEGER</li><li>Directory number :: = GraphicString</li></ul>
0032By means of an ASN.1 translator, the ASN.1 representations of the attributes can be translated into the following data type representations in C language: <ul id="ul0003" list-style="none" compact="compact"><li>typedef long Line number;</li><li>typedef char *Directory number;</li></ul>
0033It is assumed that the network management workstation (reference mark WS in figure 1) wants to find out the subscribers who are connected to the network element, and whose directory number begins with the digit 4 or 5. The network management workstation sends to the network element the following CMIP operation m-Get, which includes the first target group (S) and the FILTER condition, i.e. the comparison criteria of the attributes of the object instances. The group S is determined in the PDU (Protocol Data Unit) of the CMIP protocol, described below by means of the ASN.1 notation, by the value of the baseManagedObjectinstance field, which indicates the subtree root node in the MIT of the network element, and by the scope value of the field. Fields irrelevant to the example have been left out and replaced by three dots. The FILTER condition is indicated by the value of the filter field. As the root node, the example has an object instance representing the subscriber register. For reasons of clarity, the actual name of the subscriber register instance is in the example replaced by the identifier <Subscriber register>. The value wholeSubtree of the scope field means that the group S contains all the object instances of the subtree, i.e. all the subscribers coupled to the network element. As the value of the filter field there is the ASN.1 expression, which may be described as the expression "the directory number begins with the digit 4, or the directory number begins with the digit 5" in natural language.<img file="EP0804841B1_D0008.tif" /><img file="EP0804841B1_D0009.tif" />
0034In the following, the numbers in parentheses refer to corresponding numbers in figure 5, which illustrates the operation of an agent in the network element. (The numbers, however, do not necessarily refer to the order of execution of the operations). In the network element, the m-Get operation is received (1) by an agent responsible for the execution of the operation in the network element. The agent organizes the FILTER condition of the m-Get operation into a tree-like configuration (2). The agent demarcates the group S, which is determined by the m-Get operation, from the object instance tree (i.e. MIT) of the network element (3). In figure 5, the group S is demarcated within the MIT by a broken line. The agent processes each object instance belonging to group S separately (4). The agent finds out whether a specific object instance belongs to the final group of object instances by calling the implementation of the algorithm evaluate_filter described above (5). On the basis of the attribute identifier {1 2 4} in the FILTER condition, the evaluate_filter retrieves the semantic tree corresponding to the home area of the attribute "Directory number" (6). The markings in the semantic tree in this exemplary case mean that the attribute, whose identifier is {1 2 4}, is GraphicString as regards its ASN.1 type, and the data type of the home area is "char*" in C language, i.e. a graphic string pointer. Controlled by the information contained in the semantic tree, the evaluate_filter compares the comparison values included in the FILTER condition to the attribute "Directory number" of the object instance by a manner described above. Following this, as the result to the m-Get operation, the agent returns to the network management workstation those subscribers who have the directory numbers "56789" and "442224" (7). These subscribers constitute the final group of target instances. In the MIT of figure 5, an arrow points to the subscribers in question.
0035As noted above, the comparison method which is based on the utilization of semantic trees and used for comparing attribute values is a general-purpose one. The general-purpose feature here means that the method is independent of the ASN.1 representations of the attributes. In addition to the advantages described above, the general-purpose feature of the method achieves considerable savings concerning network element software development, because the changes in ASN.1 representations or the implementation of new ASN.1 representations will require no additional software development. For the above reason, the implementation of the method can be tested more thoroughly, which improves the reliability of the results of the comparison and of the entire network element.
0036It is obvious for a person skilled in the art that the various embodiments of the invention are not restricted to the examples above, but may vary within the scope of the attached claims.
12 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US5317742A | Cites | United States of America | Examiner |
| EP0661628A | Cites | European Patent Office (EPO) | – |
| US5261080A | Cites | United States of America | – |
| US5317742A | Cites | United States of America | – |
| US5361351A | Cites | United States of America | – |
14 members in 9 offices
Priority claims7
| Document | Office | Kind | Date |
|---|---|---|---|
| 946209 | Finland | A | |
| 946209 | Finland | – | |
| 9500719 | Finland | W | |
| WO1995FI00719 | – | – | – |
| FI19940006209 | – | – | – |
| FI9500719 | – | – | – |
| 946209 | – | – | – |
Members14
| Document | Office | Kind | |
|---|---|---|---|
| FI946209A0 | Finland | A0 | |
| CA2208962A1 | Canada | A1 | |
| WO9621324A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU4306396A | Australia | A | |
| WO9621324A3 | World Intellectual Property Organization (WIPO) | A3 | |
| BR9510183A | Brazil | A | |
| BR9510183A | Brazil | A | |
| EP0804841A2 | European Patent Office (EPO) | A2 | |
| CN1171873A | China | A | |
| US5941978A | United States of America | A | |
| CN1102001C | China | C | |
| EP0804841B1This record | European Patent Office (EPO) | B1 | |
| DE69529846D1 | Germany | D1 | |
| DE69529846T2 | Germany | T2 |
27 legal events, as 3 offices reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | Office | |
|---|---|---|---|
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Notification of lapseLapsedST | ST | FR | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Gb: european patent ceased through non-payment of renewal feeCeasedGBPC | GBPC | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| No opposition filedOpposition26N | 26N | EP | |
| No opposition filed within time limitOppositionORIGINAL CODE: 0009261PLBE | PLBE | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: NO OPPOSITION FILED WITHIN TIME LIMITSTAA | STAA | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Fr: translation filedET | ET | EP | |
| Nl: lapsed or annulled due to failure to fulfill the requirements of art. 29p and 29m of the patents actLapsedNLV1 | NLV1 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Corresponds to:REF | REF | EP | |
| Designated contracting statesAK | AK | EP | |
| European patent grantedGrantedFG4D | FG4D | GB | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| (expected) grantORIGINAL CODE: 0009210GRAA | GRAA | EP | |
| Despatch of communication of intention to grant a patentORIGINAL CODE: EPIDOS IGRAGRAH | GRAH | EP | |
| Despatch of communication of intention to grant a patentORIGINAL CODE: EPIDOS IGRAGRAH | GRAH | EP | |
| Party data changed (applicant data changed or rights of an application transferred)RAP1 | RAP1 | EP | |
| Party data changed (applicant data changed or rights of an application transferred)RAP1 | RAP1 | EP | |
| Request for examination filed17P | 17P | EP | |
| Designated contracting statesAK | AK | EP | |
| Public reference made under article 153(3) epc to a published international application that has entered the european phaseORIGINAL CODE: 0009012PUAI | PUAI | EP |
Numbers
- Publication
- 0804841
- Publication, DOCDB
- 0804841
- Publication, EPODOC
- EP0804841
- Application
- 95941745
- Application, DOCDB
- 95941745
- Application, EPODOC
- EP19950941745
Titles3
- German
- VERFAHREN ZUM VERGLEICH VON ATTRIBUTWERTEN VON STEUERBAREN OBJEKTAUSDRÜCKEN IN EINEM NETZWERKELEMENT
- English
- METHOD FOR COMPARING ATTRIBUTE VALUES OF CONTROLLABLE OBJECT EXPRESSIONS IN A NETWORK ELEMENT
- French
- PROCEDE DE COMPARAISON DE VALEURS D'ATTRIBUTS D'EXPRESSIONS D'OBJETS COMMANDABLES DANS UN ELEMENT DE RESEAU
Classification
- CPC, 2
- H04Q3/0062
- H04Q2213/13516
- IPC, 1
- H04Q3 00
Designated states6
- Contracting states, 6
- Germany
- France
- United Kingdom
- Italy
- Netherlands (Kingdom of the)
- Sweden
