EP0995325A2

EP0995325A2 - Cellular system employing an object request broker

Info

Publication number: EP0995325A2
Application number: EP98934471A
Authority: EP
Inventors: Praveen Kumar; Scott Larribeau; Stewart Y. Kuan; Sanjay Kapoor
Original assignee: Nortel Networks Ltd; Nortel Networks Corp
Current assignee: Nortel Networks Ltd
Priority date: 1997-07-11
Filing date: 1998-07-10
Publication date: 2000-04-26
Also published as: AU8398298A; CA2295833A1; WO1999003286A3; WO1999003286A2

Abstract

A cellular system employs a telephone switch having a layered, distributed architecture, where modules for protocol dependent functions are separated from modules for non-protocol dependent functions. The switch also employs an object request broker that controls and facilitates communication between cards operating on object-oriented and non-object-oriented platforms.

Description

CELLULAR SYSTEM EMPLOYING AN OBJECT REQUEST BROKER BACKGROUND OF THE INVENTION

The present invention relates to a microcellular telephone system. In particular, the present invention relates to a microcellular telephone system employing an object request broker to facilitate communication among components.

Conventional systems for providing cellular communication generally include mobile switching centers (MSC) coupled to base stations, base station transceivers, and transcoders. Each of these elements is typically assigned dedicated functions in the call processing procedure, although the MSC conventionally handles the bulk of the call processing operations. The MSC is typically carried out by a central switch, such as a wireless public broadcast exchange (PBX) switch.

These elements, often comprising processor hardware programmed to execute software modules, are typically configured to allow a system to communicate in accordance with a particular protocol. Protocols provide standards that ensure compatibility between elements, such as portable terminals and the particular service platform on which they depend. Examples of the currently-implemented protocols include the GSM standard (Europe), the PHS standard (Japan), and the AMPS/TDMA and CDMA protocols (North America).

While some functions may be protocol dependent (e.g., mobility call processing functions) and others are not (e.g., core processing functions), the conventional system architecture integrates the various software modules together so that a new protocol cannot be installed without replacing or enhancing many of the software modules. Replacing, rather than reusing, modules for non-protocol dependent functions in this fashion results in substantial inefficiencies in time and investment. Thus, a need currently exists to allow the protocol under which a system operates to be changed, or at least modified, without the needless replacement of entire software modules, especially those for non-protocol specific functions.

The same problem presents itself again when older systems are upgraded. Older cellular systems, commonly referred to as "legacy" systems, are not compatible with newer systems and thus are effectively unusable when upgrades are desired. This can be very expensive, considering that a large number of legacy systems are already in place. Legacy systems conventionally operate on platforms which are not compatible with known platforms used in newer systems. For example, many legacy cellular systems cannot communicate with or access data from object-oriented platforms or object request broker (ORB) platforms, on which many newer cellular systems operate. Needless to say, this problem is not limited to legacy systems, but also occurs with newer, but less expensive, systems operating on platforms that are, for example, possess insufficient resources to support an object-oriented environment. Thus, a need exists to interface components operating under one platform, such as an object-oriented platform, with components that are not, thereby permitting legacy systems to be salvaged and newer, but less expensive, systems to be used with other newer object-oriented systems.

SUMMARY OF THE INVENTION

The present invention provides a mobility architecture that distributes functions across several peripheral processors within a microcellular communication environment. The system and method of the present invention provides a transport mechanism that permits objects to effectively communicate with non-object oriented platforms. Thus, the present invention allows existing systems to be integrated with newly designed call processing applications. In accordance with the purpose of the invention as embodied and broadly described herein, there is provided In a microcellular communication system including a first processor and at least one peripheral processor coupled to the first processor, a call processing method comprises the steps of transmitting an object request message from the first processor to an object request broker (ORB); identifying an interface wrapper using the object request message, the interface wrapper serving as a proxy for a non-object residing on the at least one peripheral processor; receiving, at the identified interface wrapper, the object request message from the ORB; converting the object request message to a data request by inserting an identifier reference; retrieving a non-object entity using the data request; returning the non-object entity to a call application program via the ORB, the non-object entity corresponding to the object requested by the ORB; and executing the call application program using the returned non-object entity.

In another embodiment, a method for facilitating communication between an ORB platform processor and a non-ORB platform processor comprising: receiving, at an object adapter client, a registration request message from at least one non-object entity, the adapter client and the at least one non-object entity residing on the non-ORB platform processor; forwarding the registration request message from the object adapter client to an object adapter server, the object adapter server residing on the ORB platform processor; and generating an interface wrapper to serve as a proxy for the at least one non- object entity.

In yet another embodiment, a microcellular telephone system including a core processing unit and a wireless private branch exchange (PBX) switch for distributing communication signals to a plurality of portable terminals, the PBX switch comprises a mobility controller, the mobility controller includes an object request broker for communicating object request messages from the core processing unit; and at least one transcoder card, coupled to the mobility controller, for performing protocol dependent processing functions.

In still a further embodiment, a telephone switch comprises a call services layer for providing call processing services that are common to both wireline and wireless services; a mobility layer, coupled to the call processing layer, for providing mobility control for a plurality of portable terminals; a protocol interface layer for providing a protocol specific communication link to the plurality of portable terminals; and a platform layer for providing a protocol independent operating environment.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate systems and methods consistent with this invention and, together with the description, explain the objects, advantages and principles of the invention. In the drawings, FIG. 1 illustrates a cellular system consistent with the invention; FIG. 2 illustrates one embodiment of the layered software architecture consistent with the invention;

FIG. 3 is a block diagram of the mobility controller and transcoder shown in Fig. i; FIG. 4 illustrates the registration of a non-object residing on a transcoder card for access by an ORB object;

FIG. 5 illustrates the message sequence occurring during a non-object to object binding procedure in accordance with the one embodiment of invention;

FIG. 6 is a flow diagram showing a message sequence 600 occurring during a object to non-object binding procedure in accordance with one embodiment of the invention; and

FIG. 7 illustrates a message sequence occurring when an ORB object residing on a ORB platform processor calls upon a non-object residing on a peripheral non-ORB platform processor, in accordance with the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS The following detailed description of the invention refers to the accompanying drawings that illustrate preferred embodiments consistent with the principles of this invention. Other embodiments are possible and changes may be made to the embodiments without departing from the spirit and scope of the invention. The following detailed description does not limit the invention. Instead, the scope of the invention is defined only by the appended claims.

I. INTRODUCTION A cellular system consistent with the invention employs a telephone switch having a layered, distributed architecture, where modules for protocol dependent functions are separated from modules for non-protocol dependent functions. In this way, the protocol under which the system operates can be changed with minimum disruption to modules for non-protocol dependent functions. The switch also may employ a mechanism to enhance the object request broker that controls and facilitates communication between cards operating on object-oriented and non-object-oriented platforms. In this way, components operating under an object- oriented platform can be used in conjunction with components operating under a non- object-oriented platform.

II. SYSTEM

FIG. 1 is a block diagram of a cellular communication system 100 consistent with the invention. System 100 includes a public branch exchange (PBX) switch 110, a series of telephone terminals 102 and 104, at least one micro base station 150, a group of distributed antenna 160 and 161, and a series of portable, or cellular, telephone units 170 and 171. In an alternative embodiment, system 100 could include a plurality of PBX switches, in which case each of the PBX switches would cover a different zone. System 100 preferably operates within a single facility, or group of related facilities, the size of which dictates the number of components that system 100 accommodates.

As shown in Fig. 1, system 100 is preferably connected to a public switching network 180 through standard communication link 182 and to a macro cellular network 190 through communication link 192. Telephone terminals 102 and 104 are connected to PBX 110 switch by a conventional communication link 105 capable of transmitting both voice and data communication signals. PBX 110 is also coupled to micro base station 150, which in turn is coupled to distributed antenna 160 and 161. Antenna 160 and 161 communicates with portable units 170 and 171 through wireless link 165. Preferably, system 110 interfaces with at least one network server terminal (not shown) responsible for, among other things, network administration and maintenance functions. Telephone terminals 102 and 104 are standard telephones capable of receiving and transmitting call signals to and from PBX switch 110 using conventional methods and equipment. Micro base station 150 preferably comprises programmed processing hardware executing signal transceiver software for routing communication signals from PBX switch 110 to the portable units 170 and 171 via antennae 160 and 161, respectively. Portable units 170 and 171 are preferably conventional cellular telephones, and alternatively could also comprise pagers, personal digital assistants (PDA) or any other wireless device capable of receiving and transmitting a radio or microwave frequency communication signal. Depending on the utilized protocol, portable units 170 and 171 comply with communication protocol IS-136 and are capable of following the registration requirements of IS-41.

PBX switch 110 preferably comprises programmed processing hardware executing software for performing call processing and mobility routing functions for system 100. Northern Telecom Ltd.'s Meridian Ml is an example of a PBX switch suitable for the present invention. Preferably, PBX switch 110 receives internal call processing and routing requests from the telephone terminals 102 and 104 and the portable units 170 and 171, as well as external call routing requests from PSTN 180 and macro cellular network 190 via communication links 182 and 192, respectively.

As seen in FIG. 1, PBX switch 110 contains a core network central processing unit (CPU) 120, a mobility controller 130, and a transcoder card 140. Core network CPU 120 is a standard call processing and switching device that handles non-mobile related call processing requests received at PBX switch 110 from external or internal sources.

For example, if a call request is received from PSTN 180, core network CPU 120 routes the call according to conventional switching techniques to telephone terminals 102 or 104.

PBX switch 110 also contains mobility controller 130 and transcoder card 140 for routing communication signals to portable units 170 and 171 via micro base station 150 and antenna 160 and 161. Both mobility controller 130 and transcoder card 140 have processors and associated components to perform their various call routing and processing duties. Consistent with the invention, mobility controller 130 performs general call mobility functions such as (1) providing call handover to maintain a continuous wireless communication link when portables move between zones, (2) allowing portables of different configurations access system 110, and (3) tracking the portable's location as a user moves within the serviced facility and outside the coverage area of system 100. Mobility controller 130 receives mobility routing requests from core network CPU 120 via a standard communication connection, such as an Ethernet-type bus connection. Transcoder card 140 is preferably coupled to mobility controller 130 via a connection such as an HDLC communication link and micro base station 150. Transcoder card 140 provides protocol specific mobility call processing functions such as call signal compression and decompression, encoding, echo cancellation and physical access to the portable terminal. In general, transcoder card 140 provides functions that are specific to the protocol standard employed by the particular portable terminal.

In a preferred embodiment, transcoder card 140, which is preferably physically isolated and separate from mobility controller 130, contains software modules for protocol dependent functions and operates under the same platform as mobility controller 130. In this configuration, the protocol under which system 100 operates can be modified by replacing, or modifying, transcoder card 140 and the protocol related software modules located on mobility controller 130. Such protocols include GSM, AMPS/TDMA, CDMA and PHS, as well as other protocols.

For efficiency reasons, transcoder card 140 may also operate on a different platform than mobility controller 130. As discussed in greater detail below, the invention provides an interface to allow communication between mobility controller 130 and transcoder card 140.

III. SOFTWARE MOBILITY DISTRIBUTION FIG. 2 shows one embodiment of a layered software architecture structure 200 representing a distribution of functions among the processors in system 100. This layered distribution isolates protocol dependent functions from non-protocol dependent functions, minimizing the need to replace the modules for non-protocol dependent functions when the protocol under which the system operates is changed. As shown in FIG. 2, structure 200 includes a platform layer 210, a protocol layer 220, a network mobility layer 230, and a call services layer 240. These layers represent groups of functions performed by PBX 110 that may be distributed between core network CPU 120, mobility controller 130 and transcoder card 140.

In a preferred embodiment, mobility controller 130 and transcoder card 140 performs the functions associated with protocol layer 220. Core network CPU 120 performs functions associated with call services layer 240 and network layer 230. Generally, the layered software architecture of the present invention allows designers the flexibility to assign functions among machines that best fit the system needs and accommodates the available resources. Platform layer 210 contains the general operating system environment for the underlying hardware of PBX 110. This includes development platforms for the various software modules residing on PBX 110 individual processor cards and the software needed to communicate with a system server apparatus interfaced to PBX 110. Preferably, core network CPU 120, mobility controller 130 and transcoder card 140 each have functionality relating to platform layer 210.

Protocol layer 220 encodes requests and data transfers to a specified protocol standard. The layer preferably contains protocol standards to allow communication in at least one known protocol standard, such as AMPS/TDMA, GSM, PHS, and CDMA.

Mobility layer 230 provides mobility call processing function such as (1) providing call handover to maintain a continuous wireless communication link when portables move between zones, (2) allowing portables of different protocol configurations access to system 110, and (3) tracking the portable's locations as a user moves within the serviced facility and outside the coverage area of system 100. Preferably, the functions relating to this layer are performed on both core network CPU 120 and mobility controller 130.

Call services layer 240 interfaces mobility controller 130 with core network CPU 120 and allows communication of call processing and call routing requests between the mobility application and the standard wireline processing modules.

IV. OBJECT ORIENTED MESSAGE TRANSPORT (OOMT)

FIG. 3 is a block diagram illustrating components of mobility controller 130 and transcoder card 140. As shown in FIG. 3, transcoder card 140 includes adapter client 325 and non-object 330. Mobility controller 130 includes object request broker (ORB) 305, wrapper object 310, ORB object 315, and adapter server 320. These components allow mobility controller 130, which is an object-oriented platform, to communication with transcoder card 140, a non-object oriented platform. In the present embodiment, a non- object may also be referred to as a non-ORB or an OOMT object.

ORB 305 comprises a software module that permits objects on a processor, or machine, operating under an object-oriented platform to access objects on another processor, or machine, also operating under an object-oriented platform. ORB 305 allows these platform-compatible machines to send object request messages from one machine to another and return object messages or data corresponding to the request messages.

In general, ORBs create virtual objects, or "stubs," which represent remotely- located objects on other machines. Objects residing on the same machine as the stubs treat the stubs as if they were actual objects by passing information and submitting requests, which the stubs forward to the corresponding remotely-located objects. The use of ORBs and interface stubs is conventionally known in fields other than cellular call processing. In a preferred embodiment, core network CPU 120 and mobility controller 130 operate under an object-oriented platform and communicate through ORB 305. Unless otherwise stated, the specification refers to "ORB platforms" and "object-oriented platforms" interchangeably. Similarly, "non-ORB platforms" and "non-object-oriented platforms" are used interchangeably. Wrapper object 310 serves as a proxy for an object or a non-object residing on a remote non-ORB platform machine. It converts messages received from ORB 305 to a compatible message format that is understood by a non-object residing on a non-ORB platform. For example, if ORB object 315 requests a non-object residing on transcoder card 140, wrapper object 310 is called and converts the request into a format understandable by transcoder card 140. Preferably, wrapper object 310 is mapped to an integer value that serves as a identifier reference corresponding to and identifying the non- object it represents. When an object request message is sent from ORB object 315 to non- object 330, object 315 sends the message thru ORB 305 by invoking a "stub" that represents wrapper object 310. The stub and ORB 305 work together to deliver the message to wrapper obj ect 310, wrapper obj ect 310 translates the request so that it may be understood by adapter server 320 and adapter client 325. Preferably, wrapper object 310 is created either when a new non-object becomes available or a new object is created that wants to use an existing non-object.

ORB object 315 comprises an object, such as an application program, that accesses other objects. For example, in a preferred embodiment, ORB object 315 is a call processing program using remotely-located objects or sub-process programs to complete its assigned task.

Adapter server 320 and adapter client 325 communicate to pass data and requests to, for example, permit ORB object 315 to utilize data or functions residing in non-object 330. Adapter server 320 and adapter client 325 use a standard TCP/IP communication link, or a similar common or proprietary link, as their underlying transport mechanism. Adapter server 320 and adapter client 325 preferably comprise a programmed processor executing software to perform the associated functions described herein.

Non-object 330 may be data or sub-processing program residing on transcoder card 140, or any non-ORB platform machine. While non-object 330 is characterized as non-object, it may also be an object residing on non-ORB platform transcoder card 140.

V. SYSTEM OPERATION A. General Wrapper object 310 serves two basic functions. First, wrapper object 310 operates as a translator, or interface, for messages transmitted from non-object 330 to ORB object 315. Second, wrapper object 310 operates as a translator, or interface, for message transmitted from ORB object 315 to non-object 330.

In the first case, when messages are transmitted from non-object 330 to ORB object 315, wrapper object 310 acts as a "reader thread" that permits data and messages contained in non-object 330 to be transmitted to ORB object 315 without disturbing the normal operation of ORB 305 and ORB object 315. That is, wrapper object 310 supplies data and messages from non-object 330 in a format understandable to ORB object 315 and at a time in which ORB object 315 expects to receive the data and message (i.e., ORB object 315 may be event-driven). Thus eliminating the need for ORB object 315 to poll for messages from non-object 330. Alternatively, several wrapper objects could rely on a single reader thread to receive messages from non-objects.

In the second case, when ORB object 315 communicates with non-object 330, wrapper object 310 acts as a virtual object that represents non-object 330 residing on the non-obj ect platform transcoder card 140. Wrapper obj ect 310 remains transparent to ORB object 315 and ORB 305 and receives any received data and messages to non-object 330 in a manner and format understandable to non-object 330.

Wrapper object 310 is assigned an OOMT reference identifier that adapter client 325 uses to call non-object 330. The reference identifier is preferably unique to ensure that adapter client 325 and adapter server 320 call for the correct non-object 330. For example, when a non-abject registers itself with adapter client 325 and adapter server 320 and wrapper object is created, it is assigned an integer reference that represents both the wrapper object and the OOMT it represents. This identifier reference, or "OOMTobjectReference," includes information about the non-ORB platform on which the register non-object resides and is stored at both wrapper object 310 and the non-object 330. The OOMTobjectReference is subsequently used in all messages when a reference to the non-object is required.

For example, when an ORB object 315 sends a message to a non-object 330, the message is delivered through the ORB 305 to the wrapper object 310. Wrapper object 310, as non-object's 330 proxy, receives the message and adds the identifier reference to the message before forwarding it to adapter server 320. Adapter server 320 uses the identifier reference to determine the appropriate adapter client 325 to send the message and adapter client 325 uses the identifier reference to determine the appropriate non- object.

B. Non-Object Registration

In order for ORB object 315 or a call application program to use non-object 330, ORB object 315 must be "aware" of non-object 330. Non-object 330 makes itself available for access by objects, such as ORB object 315, by registering. FIG. 4 shows a flow diagram for a registration process 400 consistent with the present invention. Upon creation of non-object 300 on transcoder card 140, a registration message is forwarded to adapter client 325, which also resides on transcoder card 140 (step 410). Next, adapter client 325 transmits a registration request message to adapter server 320 (step 420). Upon the receipt of the registration request message, adapter server 320 creates wrapper object 310 (step 430). As described above, wrapper object 310 serves as a proxy device that translates requests transmitted between ORB 305 and adapter server 320. Adapter server 320 transmits a registration confirmation signal to adapter client 325 (step 440). Finally, adapter client 325 transmits a registration confirmation signal to non- object 330 (step 450).

C. Binding

After registering non-object 330 with adapter server 320, non-object 330 "binds" to a registered ORB object 315. Binding permits non-object 330 to utilize, for example, data contained at ORB object 315 or to send messages to ORB object 315. FIG. 5 is a flow diagram showing a message sequence 500 occurring during a non-object to object binding procedure in accordance with one embodiment of the invention.

First, non-object 330 sends a bind request message to adapter client 325 (step 510). The bind request message includes the name of the ORB object 315 with which non-object 330 seeks to bind and a corresponding host name containing ORB object 315. In this case, the host name refers to the core network CPU 120. Adapter client 325 forwards the bind request message to adapter server 320 (step 520). Adapter server 320 sends the bind request message to wrapper object 310 (step 530). Wrapper object 310 then sends an ORB_bind command message to ORB 305 (step 540). The bind message contains the host and object name for ORB object 315. Upon receiving the ORB_bind command, ORB 305 creates an stub 335 to serve as an interface between ORB 305 located on mobility controller 130 and ORB object 315 on core network CPU (step 550). When stub 335 is created, adapter server 320 and adapter client 325 assign an OOMT object identifier, or "ORBobjectReference," that is similar to the "OOMTobjectReference," describe above. Then, wrapper object 310 sends a bind confirmation message to adapter server 320 (step 560). Finally, adapter server 320 sends a bind confirmation message to adapter client 325 (step 570), which, in turn, forwards the bind confirmation message to non-object 330 (step 580). Preferably, the bind confirmation message contains an OOMT object identifier reference that identifies stub 335. The OOMT object identifier reference allows wrapper object 310 and adapter server 320 to identify stub 335 and associated ORB object 315 by using the stub identifier as a key in a translation table contained in adapter server 320. Adapter server 320 and adapter client 325 use this integer identifier to recognize when a particular stub is called. To allow ORB object 315 and non-object 330 to engage in two way message communication, ORB object 315 also preferably binds to non-object 330. FIG. 6 is a flow diagram showing a message sequence 600 occurring during an object to non-object binding procedure in accordance with one embodiment of the invention. While this message flow sequence is described as a separate process the "reverse bind" could occur during registration in conjunction with the non-object to ORB object registration procedure. ORB object 315 sends an ORB_bind command to ORB 305 (step 610). Upon receiving the ORB_bind command, ORB 305 creates an ORB stub 340 to serve as an interface for wrapper object 310 (step 620). Preferably, stub 340 is used when ORB object 315 wants to send a message to non-object 330.

D. Communication Between ORB Platform and Non-ORB Platform

Once a non-object has successfully bound itself to a remote ORB object and the ORB object has successfully bound itself to the remote non-object, the ORB object may access the non-object (i.e., call upon data or message located at the non-object to request the non-object to send data). The binding and registration procedure described above also permits non-object to request data from the ORB object. FIG. 7 is a flow diagram showing a message sequence 700 occurring when an ORB object, or call application program residing on an ORB platform processor, calls upon a non-object residing on a peripheral non-ORB platform processor.

First, ORB object 315 transmits a object request message to stub 340 (step 705). In this case, the object requested is non-object 330 residing on transcoder card 140. Stub 340 forwards the request to ORB 305 (step 710) and ORB 305, recognizing that wrapper object 310 is the requested object, forwards the request message to wrapper object 310 (step 715). The object request message is in a standard ORB message format.

Wrapper object 310 then converts the ORB message object request message to a message format that adapter server 320 and adapter client 325 can recognize. This converted message is then sent to adapter server 320 (step 720), which sends the message to adapter client 325 (step 725). Preferably, the converted object request message contains the non-object's 330 identifier reference.

Upon receipt of the object request message and the object identifier reference, adapter client 325 forwards the message to called non-object 330 (step 730). Next, non- object 330 sends, for example, data or a message to adapter client 325 (step 735), and adapter client 325 forwards the non-object data to adapter server 320 (step 740). Preferably, the non-object data or message is a data byte stream and contains data information, a second parameter identifying the length of the data byte stream, and the identifier reference for wrapper object 310. This data byte stream is in accordance with the underlying communication transport that adapter server 320 and adapter client 325 use to communicate. Next, adapter server 320 forwards the ORB data message to wrapper object 310 (step 745).

Wrapper object 310 then converts the data byte stream to an ORB formatted message and forwards the ORB data message to stub 335 (step 750). Finally, stub 335 returns the data message to ORB 305 (step 755) and ORB object 315 receives the requested data message (step 760). Upon the completion of message sequence 600, ORB object 315 is able to complete its task using the retrieved object or data message.

VI. CONCLUSION

It will be apparent to those skilled in the art that various modifications and variations can be made in the method and system of the present invention without departing from the spirit or scope of the invention. For example, while described in terms of one mobility controller 130 and one transcoder card 140, the present invention could be implemented using multiple transcoder cards. In addition, communication could be performed between two non-ORB platform transcoder cards in the same manner as described above in conjunction with FIG.s 4-6. Mobility controller 130 implemented on a ORB platform would serve as a communication intermediary between the two non-ORB transcoder cards regardless of their particular platform characteristics. The message flow sequences would be similar to those described in conjunction with communicating between the ORB and non-ORB platform cards.

The present invention covers the modifications and variations of this invention provided they come within the scope of the appended claims.

Claims

What is Claimed:

1. In a microcellular communication system including a first processor and at least one peripheral processor coupled to the first processor, a call processing method comprising: transmitting an object request message from the first processor to an object request broker (ORB); identifying an interface wrapper using the object request message, the interface wrapper serving as a proxy for a non-object residing on the at least one peripheral processor; receiving, at the identified interface wrapper, the obj ect request message from the ORB; converting the object request message to a data request by inserting an identifier reference; retrieving a non-object entity using the data request; returning the non-object entity to a call application program via the ORB, the non-object entity corresponding to the object requested by the ORB; and executing the call application program using the returned non-object entity.

2. The method of claim 1, wherein the data request includes a non-object reference identifier, and wherein the non-object entity resides on the at least one peripheral processor, and wherein the step of retrieving includes forwarding the data request from the interface wrapper to a server residing on the first processor; sending the data request from the server to a client residing on the at least one peripheral processor; and returning the non-object entity to the server via the client, the returned non- object entity corresponding to the non-object reference identifier received from the server.

3. The method of claim 2, wherein the step of returning includes returning the non-object entity from the server to the call application program via the ORB, the non-object data file corresponding to the object requested by the ORB; and executing the call application program using the returned non-object entity.

4. The method of claim 3, wherein the call application program is a non-protocol dependent program and the non-object entity is a protocol dependent program, and wherein the step of executing includes the step of executing the non-protocol dependent program using a protocol dependent non-object entity.

5. The method of claim 4, wherein the microcellular communication system uses a (GSM) communication protocol.

6. The method of claim 4, wherein the microcellular communication system uses a Time Division Multiplex Access (TDMA) communication protocol.

7. The method of claim 4, wherein the microcellular communication system uses a Code Division Multiplex Access (CDMA) protocol.

8. The method of claim 4, wherein the microcellular communication system uses a PHS protocol.

9. The method of claim 1 , further including registering the non-object entity with the client; forwarding a registration request message from the client to the server; generating the interface wrapper to serve as a proxy for the registered non- object entity, the interface wrapper residing on the first processor and including the identifier reference of the registered non-object entity; and binding the registered non-object entity to the call application program.

10. The method of claim 9, wherein the ORB resides on the first processor, wherein the call application program resides on a core processor coupled to the first processor, and wherein the step of binding further includes forwarding a bind request from the registered non-object entity to the client, the bind request including the identifier reference of the call application program; sending the bind request from the client to the interface wrapper via the server; and transmitting an ORB bind command from the interface wrapper to the ORB; and creating a stub to serve as a proxy for the call application program, the stub residing on the first processor.

11. A wireless PBX switch comprising: means for transmitting an object request message from a first processor to an object request broker (ORB), the object request message including an identifier reference for identifying a requested object; means for identifying an interface wrapper using the object request message and corresponding identifier reference, the interface wrapper serving as a proxy for a non-object residing on at least one peripheral processor; means for receiving, at the identified interface wrapper, the object request message from the ORB; means for converting the object request message to a data request by inserting an identifier reference; means for retrieving a non-object data entity using the data request ; means for returning the non-object entity to a call application program via the ORB, the non-object entity corresponding to the object requested by the ORB; and means for executing the call application program using the returned non- object entity.

12. The PBX switch of claim 11, wherein the data request message includes a non- object reference identifier, wherein the non-object entity resides on the at least one peripheral processor, and wherein the means for retrieving includes means for forwarding the data request from the interface wrapper to a server residing on the first processor; means for sending the data request from the server to a client residing on the at least one peripheral processor; and means for returning the non-object entity to the server via the client, the returned non-object entity corresponding to the non-object reference identifier received from the server.

13. The method of claim 11 , wherein the means for returning includes means for returning the non-object entity from the server to the call application program via the ORB, the non-object entity corresponding to the object requested by the ORB; and means for executing the call application program using the returned non- object entity.

14. The PBX switch of claim 13, wherein the call application program is a non- protocol dependent program and the non-object entity is a protocol dependent, and wherein the means for executing includes means for executing the non-protocol dependent program using a protocol dependent non-object entity.

15. The PBX switch of claim 14, wherein the PBX switch uses a (GSM) communication protocol.

16. The PBX switch of claim 15, wherein the PBX switch uses a Time Division Multiplex Access (TDMA) communication protocol.

17. The PBX switch of claim 15, wherein the PBX switch uses a Code Division Multiplex Access (CDMA) protocol.

18. The PBX switch of claim 15, wherein the PBX switch uses a PHS protocol.

19. The PBX switch of claim 11 , further including means for registering the non-object entity with the client; means for forwarding a registration request message from the client to the server; means for generating the interface wrapper to serve as the proxy for the registered object, the interface wrapper residing on the first processor and including the identifier reference of the registered non-object entity; and means for binding the registered non-object entity to the call application program.

20. The PBX switch of claim 19, wherein the ORB resides on the first processor, wherein the call application program resides on a core processor coupled to the first processor, wherein the means for binding further includes means for forwarding a bind request from the registered non-object entity to the client, the bind request including the identifier reference of the call application program; means for sending the bind request from the client to the interface wrapper via the server; and means for transmitting an ORB bind command from the interface wrapper to the ORB; and means for creating a stub to serve as a proxy for the call application program, the stub residing on the first processor.

21. In a microcellular communication system, a method for facilitating communication between an ORB platform processor and a non-ORB platform processor comprising: receiving, at an object adapter client, a registration request message from at least one non-object entity, the adapter client and the at least one non-object entity residing on the non-ORB platform processor; forwarding the registration request message from the object adapter client to an object adapter server, the object adapter server residing on the ORB platform processor; and generating an interface wrapper to serve as a proxy for the at least one non- object entity.

22. The method of claim 21, wherein the ORB platform processor is a non-protocol dependent processor and wherein the non-ORB platform is protocol dependent processor.

23. The method of claim 22, wherein the microcellular system uses a (GSM) communication protocol.

24. The method of claim 22, wherein the microcellular system uses a Time Division Multiplex Access (TDMA) communication protocol.

25. The method of claim 22, wherein the microcellular system uses a Code Division Multiplex Access (CDMA) protocol.

26. The method of claim 22, wherein the microcellular system uses a PHS protocol.

27. A microcellular telephone system including a core processing unit and a wireless private branch exchange (PBX) switch for distributing communication signals to a plurality of portable terminals, the PBX switch comprising: a mobility controller, the mobility controller includes an object request broker for communicating object request messages from the core processing unit; and at least one transcoder card, coupled to the mobility controller, for performing protocol dependent processing functions.

28. The system of claim 27, wherein the mobility controller further includes means for receiving, at the ORB, an object request message from an object residing on a core network CPU, the object request message including an identifier reference for identifying a requested object; means for identifying an interface wrapper residing on the mobility controller using the object request message and corresponding identifier reference, the interface wrapper serving as a proxy for a non-object residing on the at least one transcoder card; means for receiving, at the interface wrapper, the object request message from the ORB; means for converting the object request message to a data request message; means for receiving, at a server, the converted object request message; means for transmitting the converted object request message to the at least one transcoder card; means for retrieving the non-object data from the at least one transcoder card, the non-object data corresponding to the object requested by the ORB; and means for returning the non-object data to the core network CPU via the ORB.

29. The system of claim 27, wherein the transcoder card including means for receiving the converted object request message from the server at a client, the object request message including a non-object identifier reference; means for retrieving the non-object data from a non-object, the non object residing on the at least one transcoder card; and means for forwarding the non-object data from the non-object to the server via the client.

30. The microcellular system of claim 27, further including a base station unit, coupled to the transcoder card, for receiving the communication signals distributed by the PBX switch; and a plurality of antenna, coupled to the base station unit, for transmitting the communication signals to the plurality of portable terminals.

31. A method of facilitating communication from a non-ORB object to an ORB object, comprising: receiving, at an object adapter client operating on a non-ORB platform, a message from a non-ORB object; forwarding the received message from the object adapter client to an object adapter server operating on an ORB platform; receiving, at the object adapter server, the message forwarded from the object adapter client; converting, at the object adapter server, the received message into an ORB message; and forwarding the converted message from the object adapter server to the ORB object.

32. A telephone switch, comprising: a call services layer for providing call processing services that are common to both wireline and wireless services; a mobility layer, coupled to the call processing layer, for providing mobility control for a plurality of portable terminals; a protocol interface layer for providing a protocol dependent communication link to the plurality of portable terminals; and a platform layer for providing a protocol independent operating environment.

33. The telephone switch of claim 32 further including a plurality of processors, and wherein the call services layer and the platform layer reside on a first processor in the plurality of processors.

34. The telephone switch of claim 33, wherein the protocol interface layer resides on at least one processor in the plurality of processors, and wherein the at least one processor is coupled to the first processor.