Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02380466 2002-O1-28
WO 01/10139 PCT/SE00/01497
1
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 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
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.
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 lo-
cated in the same network element or networked communicat-
ing over a hAN 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-
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.
CA 02380466 2002-O1-28
WO 01/10139 PCT/SE00/01497
2
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 han-
dle 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 extra-
neous 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.
CA 02380466 2002-O1-28
WO 01/10139 PCT/SE00/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
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
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 differ-
ent objects do not need to be implemented in the same pro-
gramming 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 cli-
ent object to a server object (ref.
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-
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.
In a complex system comprising several objects this is awk-
ward; the application has to find out itself which objects
that are instantiated.
CA 02380466 2002-O1-28
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
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
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 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,
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.
CA 02380466 2002-O1-28
WO 01/10139 PCT/SE00/01497
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'.
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 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.
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 IDZ files. The connec-
tion 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 ob-
ject only needs to pick the pragma suited for the wanted
object communication when designing an interface in IDL.
CA 02380466 2002-O1-28
WO 01/10139 PCT/SE00/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
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
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
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.
' 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
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-
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.
' 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-
CA 02380466 2002-O1-28
WO 01/10139 PCT/SE00/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-
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-
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.
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
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 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
this process.
Now several TC objects are instantiated - among them ob-
jects for handling of mobility management, session manage-
CA 02380466 2002-O1-28
WO 01/10139 PCT/SE00/01497
8
ment and VhR 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-
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.
Example 1 - Connection restart:
The NOC connection broker has implemented a software super-
vision function. If one of the objects belonging to a con-
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
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 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-
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
CA 02380466 2002-O1-28
WO 01/10139 PCT/SE00/01497
9
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 inven-
tion allow, however, for communication between objects run-
ning 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 run-
ning on any networked computer resource.
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
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-
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
CA 02380466 2002-O1-28
WO 01/10139 PCT/SE00/01497
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
