AU6195600A

AU6195600A - Object request broker with capability to handle multiple associated objects

Info

Publication number: AU6195600A
Application number: AU61956/00A
Authority: AU
Inventors: Arnfinn Andersen; Knut Bakke; Geir Olav Evensen; Parastoo Mohagheghi
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1999-07-29
Filing date: 2000-07-14
Publication date: 2001-02-19
Also published as: WO2001010139A2; WO2001010139A3; NO993699D0; CA2380466A1; NO310750B1; NO993699L; EP1201092A2

Description

WO 01/10139 PCT/SEOO/01497 OBJECT REQUEST BROKER WITH CAPABILITY TO HANDLE MULTIPLE ASSOCIATED OBJECTS Technical Field 5 The present invention relates to the implementation of the Ericsson GPRS application. Technical Background 10 The GSM based GPRS network enables users always to stay at tached for information exchange over the World Wide Web. The end-user is only charged for the words of data con tained in the packages transmitted to and from the mobile 15 station. Ericsson's GPRS Support Nodes (GSNs) are based on widespread software and hardware components provided by third party vendors. The application software realises GPRS specific protocols and functionality like mobility manage ment and session management for mobile users. 20 When developing application software for the Ericsson GPRS Support Nodes (GSNs) different programming languages are chosen for different purposes. The traffic control system e.g. handling signalling messages is implemented in Erlang 25 to achieve robustness, while the transmission system e.g. handling payload traffic is implemented in C to achieve high throughput. At run-time the software instances are distributed over any number of processors (CPUs) either lo cated in the same network element or networked communicat 30 ing over a LAN or WAN. The interwork between the software instances in this envi ronment must be smooth both with regard to the software de velopment itself and when the GPRS network is put into op 35 eration. The software development project therefore uses object oriented methods and tools and has developed its own object request broker (ORB) according to the Corba standard for efficient object communication.

WO 01/10139 PCT/SEOO/01497 2 Problems To overcome the complexity of GPRS application software the 5 functionality is modelled into several classes. Thus, when a GPRS subscriber attaches to a SGSN, several objects are instantiated both in the traffic control system and in the transmission system. Each object is highly optimized for the execution of a limited set of tasks. 10 Since all these objects are associated with one subscriber, there is a need to treat these objects as one unity e.g. in order to: 15 * Synchronize the state machines implemented in (some of) the objects * Complete transactions, or do rollback if necessary 20 * Terminate all associated objects if one of the objects is terminated (i.e. clean up the system) * Restore all associated objects to a stable state if one of the objects crashes 25 Conventional middleware solutions do not have the knowledge about which objects actually depend on each other and thus they leave to the client and server implementations to han dle cases as listed above. This implies that developers of 30 client and server functions must spend a lot of time to tailor solutions for each case, and it also implies extra neous method invocations through the middleware. The solution to this problem is to implement an ORB with 35 knowledge about objects with relationships as described above. This opens up the possibility for a range of support functions in the middleware.

WO 01/10139 PCT/SEOO/01497 3 KNOWN SOLUTIONS OMG's Corba standard (ref. [1]) specifies the principles of how to address software objects so that they may be invoked 5 independently of which computing environment they are run ning in and where they are situated. This invention is an extension of these principles. There is known no prior art that address the problem of 10 handling associated objects in the middleware. THE INVENTION The invention in brief 15 In other words: Corba defines an architecture for object communication. An advantage with Corba is that the differ ent objects do not need to be implemented in the same pro gramming language, and they do not need to know where the 20 different objects are executing (i.e. which computer they are instantiated in). The objects defines an interface which they communicate through, while an Object Request Broker ("middleware) transfers a function call from a cli ent object to a server object (ref. 25 http://www.omg.org/corba/whatiscorba.html). There are different implementations of ORBs, and this in vention describes particular features of the ORB which is implemented in connection with GPRS and which we call 'con 30 nection broker'. As far as we know other ORBs only imple ments direct communication between objects without sfurther knowledge concerning how the objects are tied together. Thus each application have to implement some system func tions for operation (e.g. synchronisation) of the objects. 35 In a complex system comprising several objects this is awk ward; the application has to find out itself which objects that are instantiated.

WO 01/10139 PCT/SE00/01497 4 Of this reason we have introduced the conception of connec tion which defines a set of objects which naturally are as sociated. E.g. if one of the objects disappears, the ORB should be able to remove the associated objects. This is 5 not necessarily tied to GPRS per se, but GPRS is an example of an application in need of middleware for performing sys tem functionality in an effective way. Connection broker itself is in reality application independent as the inven tion not restricts what a 'connection' can represent. The 10 invention is thus an ORB which has knowledge about related objects - which makes it possible to implement a multitude of support functions in this ORB and facilitate design of client/server objects. 15 According to the present invention there is provided an ar rangement in a telephone communication system, wherein each subscriber is represented by a set of objects running in different environments, said objects taking part in the same chain of related events for a specific subscriber, 20 comprising an Object Request Broker (ORB) which is adapted for providing communication between the objects by transfer of functions calls from client objects to server objects, which arrangement is characterized in that the ORB contains a register of all objects that are associated for each sub 25 scriber and is arranged to treat all objects as one unity. Further features of the invention appears from the appended dependant claims. 30 Brief description of the drawings Fig. 1 shows an implementation of the connection broker for an GPRS application software. 35 Fig. 2 shows part of the connection broker data structure. Fig. 3 shows a traffic use case of the connection broker.

WO 01/10139 PCT/SEOO/01497 5 Description of the invention General 5 All associated and dependent objects taking part in the same chain of related events for a specific GPRS subscriber within a GSN are hereafter denoted a 'connection'. The ORB implementation with knowledge about all objects in a con nection is called a 'connection broker'. 10 According to Corba each object will have a unique object reference which is used by the ORB to address a specific object. In this invention the object reference will always contain the connection id (Cid) which is specific for the 15 subscriber and a general addressing entity like the name of the class defining the operations (functionality) for this object. All objects instantiated for one subscriber have the same Cid. 20 Since one GPRS subscriber may have several active PDP con texts at the same time, it may sometimes be necessary to address one specific PDP context. For this purpose an op tional sub-address is used together with the Cid to point out the appropriate sub-object for that PDP context. 25 The connection broker mechanism extends the standard OMG ORB middleware specification by keeping a register of all objects instantiated for a single user within a network element. This facilitates control of all objects belonging 30 to this user. The object interfaces are defined in IDL files. The connec tion broker mechanism offers pragmas for synchronous or asynchronous communication between any object. A pragma is 35 a directive for automatic code generation which is used in pre-processing or compilators. The designer of a server ob ject only needs to pick the pragma suited for the wanted object communication when designing an interface in IDL.

WO 01/10139 PCT/SEOO/01497 6 The IDL compiler will then generate the appropriate client stubs and server skeletons automatically. The client ob jects may now simply call the generated stub code which will redirect the object invocation through the connection 5 broker. Use of pragmas is in general according to OMG stan dards, however, the pragmas offered by the connection bro ker are tailored. The implementation of the connection broker for the GPRS 10 application software is based on a three-layered structure as shown in Fig. 1: * The Traffic Control (TC) layer typically runs applica tions related to the signalling traffic to and from the 15 network element. Traffic routing, VLR and networked sup plementary services are examples of TC layer functions. Objects representing the end-user in the TC layer are addressed by the Cid and the TC class in the object ref erence. 20 * The Network element Object Control (NOC) layer repre sents the generic middleware. It offers a range of pro gramming support functions including the connection bro ker mechanism which raise the level of abstraction for 25 application designers. Fig. 2 shows parts of the connec tion broker data structure. NOC has a table of all classes in the system, given at system initiation. All allocated Cids are stored in an 30 other table. In addition there is a table for each class, which will point at a specific object given the Cid. By iterating all classes for one Cid in the 'all objects' tables, all associated object for one connec tion are found. 35 * The Resource Deployment layer is dedicated to switching payload traffic and represents the application's trans mission system. The RD layer objects implement the pro- WO 01/10139 PCT/SEOO/01497 7 tocol stacks for network element external communication. Objects representing the end-user in the RD layer are addressed by the Cid and a so-called device type or al ternatively a device id in the object reference. A de 5 vice typically represents the implementation of a part of a protocol stack or other payload processing func tions like charging. The different objects may execute on different CPUs inter 10 connected e.g. via an Ethernet LAN. The connection broker in NOC and the underlying computing environment (realising the node internal switch) provides the inter-object commu nication. All object communication is done via the connec tion broker. 15 In the current implementation the TC objects and the con nection broker run in the same processor, while the RD ob jects may run on other processors. In a multiprocessor com puter the objects and the connection broker are distributed 20 over the available processing resources. Traffic Use Case and Examples of Benefits Use case: 25 When an end-user switches on her mobile station (MS), an attach request message is sent to the appropriate SGSN. Here a device object is instantiated in the RD layer and a request for path data is sent as a TC object invocation to 30 the connection broker. The IMSI of the MS and the class of the TC object are used as addressing information. The con nection broker does not recognise the IMSI, and allocates a new Cid for this MS. Then it spawns a new process in the TC layer and forwards the message to the requested TC class on 35 this process. Now several TC objects are instantiated - among them ob jects for handling of mobility management, session manage- WO 01/10139 PCT/SEOO/01497 8 ment and VLR functions as needed. If the attach request is accepted, the mobility management TC object orders the es tablishment of a payload path between device objects in the RD layer. When the attach transaction is complete, the ob 5 jects needed for this user are instantiated and will per sist as long as the user stays attached in this area. Other objects may be instantiated as needed at the reception of other signalling messages. Fig. 3 shows the associated ob jects in a connection in an SGSN. 10 Example 1 - Connection restart: The NOC connection broker has implemented a software super vision function. If one of the objects belonging to a con 15 nection crashes (e.g. due to a software error), the super visor function will detect the crash and initiate a restart of all objects associated for this end-user. Some of the objects are implemented as state machines. If all influenced state machines are in a stable state, the 20 process data may be restored from replicated memory and the objects may be recovered. However, if (some of) the objects are in an unstable state, NOC will remove all objects in the connection from the network element and the end-user must reconnect. 25 Example 2 - Transaction monitoring: A transaction may in this context be defined as a set of signalling messages between network elements with the goal 30 to complete a common task. Before a transaction may be com mitted, all associated objects must be finished processing and state machines must have reached a stable state. When one of the objects' state machines has reached a sta 35 ble state, it sends an indication to NOC that a transaction is ended, and NOC will inform all associated objects about this. They must then return an indication whether this is acceptable or not. If the transaction is complete, the data WO 01/10139 PCT/SEOO/01497 9 for this connection is stored persistently. Otherwise NOC waits for another 'transaction ended' indication. Broadening 5 The connection broker does not contain any GPRS specific functionality and is thus suited as a generic layer in any network element in a packet or line switched network with a heterogeneous software environment. 10 Further, the current implementation handles objects running within one network element. The principles in this inven tion allow, however, for communication between objects run ning in different computing environments at different loca 15 tions. This invention is also not limited to any specific carrier for the inter-object communication. The objects handled by the connection broker could in principle be run ning on any networked computer resource. 20 ADVANTAGES 1. Simplifies design and implementation of client and server objects since the generic middleware (i.e. con nection broker) may take care of object management and 25 synchronization. By keeping the client and server ob jects simple they also become less error prone. 2. Minimize number of function calls related to object man agement and synchronization, i.e. improve network ele 30 ment performance. ABBREVIATIONS Cid Connection identity 35 Corba Common object request broker architecture GPRS General Packet Radio Services IDL Interface Definition Language IMSI International Mobile Subscriber Identity WO 01/10139 PCT/SEOO/01497 10 LAN Local Area Network MS Mobile Station NOC Network element Object Control OMG Object Management Group 5 ORB Object Request Broker RD Resource Deployment SGSN Serving GPRS Support Node TC Traffic Control VLR Visitor Location Register 10 WAN Wide Area Network References [1] OMG's Corba standard: http://www.omg.org 15

Claims

1. Arrangement in a telephone communication system, wherein each user is represented by a set of objects, said 5 objects taking part in the same chain of related events for a spesific user, comprising an Object Request broker (ORB) conformed to the Corba standard which is adapted for pro viding communication between the object by transfer of function calls from client objects to server objects, 10 c h a r a c t e r i z e d i n that the ORB contains a register of all objects that are associated for each user, said objects each associated with one or more execution threads implemented in one or more programming languages running at one or more distributed processors, said ORB 15 adapted to treat all said objects as one unity and to syn chronise the state machines implemented in some or all of the objects.

2. Arrangement according to claim 1, 20 c h a r a c t e r i z e d i n that the user is a sub scriber, a network node or another external user.

3. Arrangement according to claim 2, c h a r a c t e r i z e d i n that the ORB is adapted to 25 terminate all associated objects if one of the objects is terminated.

4. Arrangement according to claim 3, c h a r a c t e r i z e d i n that the ORB is adapted to 30 restore all associated objects to a stable state if one of the objects crashes.

5. Arrangement according to one of the preceding claims, c h a r a c t e r i z e d i n that the objects object 35 reference contain a common, unique identity and a general address entity like the name of the class defining the method for these objects. WO 01/10139 PCT/SEOO/01497 12

6. Arrangement according to one of the preceding claims, c h a r a c t e r i z e d i n a pragma for automatic code generation to obtain method invocation. 5

7. Use of the arrangement according to one of the preced ing claims in a GPRS communication system.