WO2001010139A2

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

Info

Publication number: WO2001010139A2
Application number: PCT/SE2000/001497
Authority: WO
Inventors: Arnfinn Andersen; Knut Bakke; Geier Olav Evensen; Parastoo Mohagheghi
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 1999-07-29
Filing date: 2000-07-14
Publication date: 2001-02-08
Also published as: NO310750B1; EP1201092A2; NO993699L; CA2380466A1; AU6195600A; WO2001010139A3; NO993699D0

Abstract

The Ericsson GPRS application is implemented using object oriented methods. During traffic a single GPRS subscriber (MS) is represented by a set of objects running in different environments. Object communication is realised through an object request broker with the capability to address all objects associated by a subscriber and thus treat them as one unity whenever required. This capability facilitates the design and implementation of the application software.

Description

OBJECT REQUEST BROKER WITH CAPABILITY TO HANDLE MULTIPLE ASSOCIATED OBJECTS

Technical Field

The present invention relates to the implementation of the Ericsson GPRS application.

Technical Background

The GSM based GPRS network enables users always to stay attached for information exchange over the World Wide Web. The end-user is only charged for the words of data contained in the packages transmitted to and from the mobile 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 management and session management for mobile users.

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 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 located in the same network element or networked communicat- ing over a LAN or WAN.

The interwork between the software instances in this environment must be smooth both with regard to the software development itself and when the GPRS network is put into op- 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. Problems

To overcome the complexity of GPRS application software the 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.

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:

* Synchronize the state machines implemented in (some of) the objects

^• Complete transactions, or do rollback if necessary

* 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

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 handle cases as listed above. This implies that developers of client and server functions must spend a lot of time to tailor solutions for each case, and it also implies extraneous method invocations through the middleware.

The solution to this problem is to implement an ORB with knowledge about objects with relationships as described above. This opens up the possibility for a range of support functions in the middleware. KNOWN SOLUTIONS

OMG' s Corba standard (ref. [1]) specifies the principles of how to address software objects so that they may be invoked independently of which computing environment they are running 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 handling associated objects in the middleware.

THE INVENTION

The invention in brief

In other words: Corba defines an architecture for object communication. An advantage with Corba is that the different objects do not need to be implemented in the same programming language, and they do not need to know where the 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 client object to a server object (ref. http : //www. o g. org/corba/whatiscorba .html) .

There are different implementations of ORBs, and this invention describes particular features of the ORB which is implemented in connection with GPRS and which we call ' con- nection broker' . As far as we know other ORBs only implements direct communication between objects without sfurther knowledge concerning how the objects are tied together. Thus each application have to implement some system functions for operation (e.g. synchronisation) of the objects. In a complex system comprising several objects this is awkward; the application has to find out itself which objects that are instantiated. Of this reason we have introduced the conception of connection which defines a set of objects which naturally are associated. E.g. if one of the objects disappears, the ORB should be able to remove the associated objects. This is not necessarily tied to GPRS per se, but GPRS is an example of an application in need of middleware for performing system functionality in an effective way. Connection broker itself is in reality application independent as the invention not restricts what a 'connection' can represent. The 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.

According to the present invention there is provided an arrangement 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, 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- scriber and is arranged to treat all objects as one unity.

Further features of the invention appears from the appended dependant claims .

Brief description of the drawings

Fig. 1 shows an implementation of the connection broker for an GPRS application software.

Fig. 2 shows part of the connection broker data structure.

Fig. 3 shows a traffic use case of the connection broker. Description of the invention

General

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 connection is called a 'connection broker' .

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 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.

Since one GPRS subscriber may have several active PDP contexts at the same time, it may sometimes be necessary to address one specific PDP context. For this purpose an optional sub-address is used together with the Cid to point out the appropriate sub-object for that PDP context.

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 to this user.

The object interfaces are defined in IDL files. The connection broker mechanism offers pragmas for synchronous or asynchronous communication between any object. A pragma is a directive for automatic code generation which is used in pre-processing or compilators . The designer of a server object only needs to pick the pragma suited for the wanted object communication when designing an interface in IDL. The IDL compiler will then generate the appropriate client stubs and server skeletons automatically. The client objects may now simply call the generated stub code which will redirect the object invocation through the connection broker. Use of pragmas is in general according to OMG standards, however, the pragmas offered by the connection broker are tailored.

The implementation of the connection broker for the GPRS application software is based on a three-layered structure as shown in Fig. 1:

^• The Traffic Control (TC) layer typically runs applications related to the signalling traffic to and from the network element. Traffic routing, VLR and networked supplementary 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 reference .

^• The Network element Object Control (NOC) layer represents the generic middleware. It offers a range of programming support functions including the connection broker mechanism which raise the level of abstraction for application designers. Fig. 2 shows parts of the connection broker data structure.

NOC has a table of all classes in the system, given at system initiation. All allocated Cids are stored in an- 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 connection are found.

The Resource Deployment layer is dedicated to switching payload traffic and represents the application' s transmission system. The RD layer objects implement the pro- 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 alternatively a device id in the object reference. A de- vice typically represents the implementation of a part of a protocol stack or other payload processing functions like charging.

The different objects may execute on different CPUs inter- 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 communication. All object communication is done via the connection broker.

In the current implementation the TC objects and the connection broker run in the same processor, while the RD objects may run on other processors. In a multiprocessor computer the objects and the connection broker are distributed over the available processing resources.

Traffic Use Case and Examples of Benefits

Use case:

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 the connection broker. The IMSI of the MS and the class of the TC object are used as addressing information. The connection 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 this process.

Now several TC objects are instantiated - among them objects for handling of mobility management, session manage- ment and VLR functions as needed. If the attach request is accepted, the mobility management TC object orders the establishment of a payload path between device objects in the RD layer. When the attach transaction is complete, the objects needed for this user are instantiated and will persist 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 objects in a connection in an SGSN.

Example 1 - Connection restart:

The NOC connection broker has implemented a software supervision function. If one of the objects belonging to a con- nection crashes (e.g. due to a software error), the supervisor 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 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 .

Example 2 - Transaction monitoring:

A transaction may in this context be defined as a set of signalling messages between network elements with the goal to complete a common task. Before a transaction may be committed, 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- 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 for this connection is stored persistently. Otherwise NOC waits for another 'transaction ended' indication.

Broadening

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.

Further, the current implementation handles objects running within one network element. The principles in this invention allow, however, for communication between objects running in different computing environments at different loca- 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 running on any networked computer resource.

ADVANTAGES

1. Simplifies design and implementation of client and server objects since the generic middleware (i.e. connection broker) may take care of object management and synchronization. By keeping the client and server objects simple they also become less error prone.

2. Minimize number of function calls related to object management and synchronization, i.e. improve network ele- ment performance.

ABBREVIATIONS

Cid Connection identity Corba Common object request broker architecture

GPRS General Packet Radio Services

IDL Interface Definition Language

IMSI International Mobile Subscriber Identity LAN Local Area Network

MS Mobile Station

NOC Network element Object Control

OMG Object Management Group ORB Object Request Broker

RD Resource Deployment

SGSN Serving GPRS Support Node

TC Traffic Control

VLR Visitor Location Register WAN Wide Area Network

References

[1] OMG' s Corba standard: http://www.omg.org

Claims

P a t e n t c l a i m s

1. Arrangement in a telephone communication system, wherein each user is represented by a set of objects, said 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 providing communication between the object by transfer of function calls from client objects to server objects, 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 adapted to treat all said objects as one unity and to synchronise the state machines implemented in some or all of the objects.

2. Arrangement according to claim 1, c h a r a c t e r i z e d i n that the user is a subscriber, 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 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 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- reference contain a common, unique identity and a general address entity like the name of the class defining the method for these objects.

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.

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