EP1082657A1

EP1082657A1 - Communications system having a distributed object architecture

Info

Publication number: EP1082657A1
Application number: EP99955344A
Authority: EP
Inventors: Peter Gifford Cook; John Paul Sharrit
Original assignee: Motorola Inc
Current assignee: Motorola Solutions Inc
Priority date: 1998-06-01
Filing date: 1999-05-28
Publication date: 2001-03-14
Also published as: WO1999063436A1; JP2003524809A; CA2333940A1; AU4319899A; IL139134A0

Abstract

A communications apparatus (10) includes a plurality of subsystems (16, 18, 20) that are each coupled to a software bus (12). The subsystems (16, 18, 20) each includes at least one processor (42) having an associated memory storing a plurality of software objects (30) that are each associated with a specific processing function. The software bus (12) is operative for, among other things, providing an interface between software objects (30) located in different subsystems, thus allowing one software object (30) to invoke any other software object (30) in the communications apparatus (10). In one embodiment, a software bus (12) is provided that conforms to the Common Object Request Broker Architecture (CORBA) standard.

Description

COMMUNICATIONS SYSTEM HAVING A DISTRIBUTED OBJECT ARCHITECTURE

Field of the Invention

The invention relates in general to communications systems and, in particular, to communications systems that are capable of supporting a wide variety of different signal formats

Background of the Invention

Communications systems of the past generally use communications equipment that is designed to perform one or a small number of preassigned tasks for effecting communication between users Such equipment generally works well within a narrow range of designed operation, but is unable to adapt to changing system requirements Systems including this equipment, therefore, have a limited range of uses and are prone to become obsolete before the associated hardware has reached a projected useful lifetime This leads to a situation where costly system redesigns are common and functional hardware units are being prematurely discarded

Therefore, there is a need for communications equipment that is adaptable to changing system requirements

Brief Description of the Drawings

FIG 1 is a block diagram illustrating a communications apparatus in accordance with one embodiment of the invention, FIG 2 is a block diagram illustrating the functional interrelationships within the communications apparatus of FIG 1 in one embodiment of the present invention, and

FIG 3 is a block diagram illustrating a hardware configuration for a radio frequency (RF) subsystem in accordance with one embodiment of the present invention Detailed Description of the Drawings

The present invention relates to a communications apparatus having a distributed object architecture The communications apparatus includes a plurality of communication subsystems all linked to a software bus The communication subsystems each include at least one processor, such as general purpose microprocessor or a digital signal processor, for processing communications signals within the apparatus Each processor has an associated memory for storing software programs for execution by the processor Some of the software programs, known as software objects, are special purpose programs that are each operative for performing (in conjunction with the associated processor) a specific processing function The software bus allows programs or objects that are resident in one of the communication subsystems to invoke software objects that are resident in other subsystems within the apparatus That is, if a program being executed in one subsystem requires a particular processing function to be performed, and the program does not have direct access to a subroutine or software object for performing that function, the program can use the software bus functionality to locate and invoke an object in another subsystem to perform the required function In addition, the software bus permits a flow of information from subsystem to subsystem within the apparatus In a preferred embodiment of the present invention, most or all of the software and hardware interfaces within the communications apparatus follow standard (i e , open) interface protocols that are rigorously and formally described in the industry For example, in one embodiment, the software bus comprises an Object Request Broker (ORB) following the Common Object Request Broker Architecture (CORBA) developed by the Object Management Group In addition to using standard interfaces, the communications apparatus of the present invention preferably provides hardware extensibility allowing hardware modules to be quickly and easily added to the apparatus via standard hardware interface connections The communications apparatus of the present invention is extremely flexible, highly upgradable, and capable of performing a wide and variable range of communications applications FIG 1 is a block diagram illustrating a communications apparatus 10 in accordance with one embodiment of the present invention As illustrated, the communications apparatus 10 includes a software bus 12, an interface memory 14, a radio frequency (RF) and modem subsystem 16 a security subsystem 18, and a networking and control subsystem (NCS) 20 It should be noted that the blocks illustrated in FIG 1 represent functional elements that do not necessarily correspond to discrete hardware units In the illustrated embodiment, each of the subsystems 16,18,20 is adapted for performing a specific class of communications functions For example, the RF and modem subsystem 16 performs, among other things, traditional transmit/receive functions and modulation/demodulation functions; the security subsystem 18 performs, among other things, data encryption/decryption functions, and the NCS 20 performs, among other things, user interface functions It should be appreciated, however, that the present invention is not limited to the use of special purpose subsystems

Each of the subsystems 16,18,20 includes one or more processors 42 for performing its assigned functions Each processor 42 is preferably a commercially available digital processing device, such as a general purpose microprocessor (GPP), a reduced instruction set computer (RISC), a complex instruction set computer (CISC), or a digital signal processor (DSP), although other processing devices may be appropriate Each processor 42 has an associated memory (such as a random access memory) for storing one or more software objects 30 (and, possibly, other programs) for execution by the processor 42 As discussed above, each of these software objects 30 represents a software program for performing a specific processing function In general, each software object 30 can be independently called and executed within a corresponding processor 42 to perform its respective function As used herein, the term "software object" refers to any limited purpose software routine regardless of programming language As illustrated, software objects 30 can be stored in various locations within each of the subsystems 16, 18,20 To invoke a particular software object 30 within the communications apparatus 10 one needs to know where that object 30 is located within the apparatus 10 The software bus 12 keeps track of the locations of the various software objects 30 within the apparatus 10 and, therefore, knows where to look when a particular processing function needs to be performed

During operation, the software bus 12 receives a request from one of the subsystems 16-20 to have a particular processing function performed The software bus 12 then attempts to locate a software object 30 that is capable of performing the requested function Once found, the software bus 12 invokes the software object 30 and passes it any information needed to perform the desired processing function

After processing is completed the software bus 12 passes the results of the processing back to the requesting entity The requesting entity can be any functionality within the apparatus 10 that is linked to the software bus 12 In a typical scenario, a control program being executed within one of the subsystems 16,18,20 sends a request to the software bus 12 to have a particular function, such as a demodulation function, performed on a communications signal After the function has been performed and the results have been returned, the control program next sends another request to the bus to have another function, such as a decryption function, performed This process is repeated until all required processing has been performed on the communication signal In this manner, a data "flow" through the communications apparatus 10 is established

In a preferred embodiment of the invention, the functions of the software bus 12 are implemented in software within the communications apparatus 10 That is, one of the processors within the apparatus 10 executes a software bus program that is resident in an associated memory to perform the functions of the software bus 12 Requests to the software bus 12 are delivered to an appropriate port of the implementing processor The software bus program then processes the requests as described above The software bus program can be resident within any of the processors in the communications apparatus 10 For example, the program can be resident within a processor within one of the subsystems 16,18,20 or within a separate, dedicated processor In general, the functioning of the software bus 12 will be substantially transparent to the requesting entity That is, the requesting entity will have no knowledge of the location of the software object 30 that it causes to be invoked In one embodiment of the present invention, the software bus 12 includes functionality for linking into another software bus either internal or external to the communications apparatus 10 For example, the software bus 12 can link into another software bus within an external user network thereby providing an additional source of objects for use in the communications apparatus 10 Such an external connection can be implemented using, for example, functionality within NCS 20

The interface memory 14 is a storage means for storing information describing the interfaces between software programs in the various subsystems 16,18,20 For example interface memory 14 may include interface information for providing a software interface between a control program within the RF and modem subsystem 16 and a user verification object within security subsystem 18 In addition, interface memory 14 can store information describing available processing functions within communications apparatus 10 and the locations of corresponding software objects within the apparatus 10 During operation the software bus 12 accesses the interface memory 14 to perform requests received from the subsystems 16,18,20 For example, the software bus 12 can access interface memory 14 to determine if a particular requested processing function is available and, if so, where a corresponding software object is located Interface memory 14 can also include any other information that is useful to the software bus 12 in performing its functions The interface memory 14 preferably includes some form of non-volatile memory device, such as a disk drive or a non-volatile semiconductor memory The non-volatile memory device is preferably programmable so that new information can be added and old outdated information can be modified or deleted

In a preferred embodiment of the present invention, the software bus 12 includes an Object Request Broker (ORB) in accordance with the Common Object Request Broker Architecture (CORBA) standard The CORBA standard is described, for example in a document entitled "The Common Object Request Broker Architecture and Specification" published by the Object Management Group, Revision 2 1 , August 1997, which is hereby incorporated by reference The CORBA standard defines an interface definition language (IDL) that is used to describe the software interfaces for the software bus 12 As these software interfaces are rigorously defined and publicly available, anyone is capable of designing software objects that can interface with the ORB The ORB is capable of providing an interface between virtually any two objects, regardless of the programming language used That is, a first software object written in C and located within the RF and modem subsystem 16 can interface with a second software object written in ADA and located within NCS 20 In general after the ORB locates an object capable of performing a requested function it obtains interface information necessary for providing an interface between the requesting entity and the object Ordinarily, a "stub" is retrieved by the ORB for providing an interface between the requesting entity and the ORB and a "skeleton" or "template" is retrieved by the ORB for providing an interface between the ORB and the chosen object. The stubs, skeletons, and templates are, for the most part, implementation specific.

Under the CORBA standard, interface memory 14 includes an Interface

Repository Library (IRL) that is accessible by the ORB for providing, among other things, information relevant to the software interfaces. The IRL can provide, for example, persistent objects that represent the IDL information in a form available at run time. The IRL can also be used to store additional information such as, for example, debugging information; libraries of stubs, skeletons, and templates; routines that can format or browse particular kinds of objects; and others. In addition to the IRL, the CORBA standard also defines an Implementation Repository that contains, among other things, information allowing the ORB to locate and invoke software objects within the system.

FIG. 2 is a block diagram illustrating the functional interrelationships within the communications apparatus 10 of FIG. 1 in one embodiment of the present invention. As shown, the block diagram is separated into three distinct functional portions representing the RF and modem subsystem 16, the security subsystem 18, and the NCS 20. In addition, further functional elements are shown outside of the three subsystems 16,18,20. In general, the functional blocks within the subsystems 16,18,20 represent individual software objects (or groups of objects) that are implemented within the subsystems 16,18,20 to perform specific functions.

Interconnections between functional blocks in different subsystems (such as the connection between modem block 50A in RF and modem subsystem 16 and security unit 70 in security subsystem 18) represent, in part, the functioning of the software bus 12. Similarly, interconnections between functional blocks within the same subsystem (such as the connection between T/R module 52A and modem 50A in RF and modem subsystem 16) may also represent the functioning of the software bus 12.

In a preferred embodiment of the invention, the RF and modem subsystem 16 is responsible for performing most of the transmit/receive functions within the communications apparatus 10. That is, the RF and modem subsystem 16 performs functions such as signal modulation/demodulation, receiver preselection, channel coding/decoding, error detection/correction, and other functions normally performed in transmitters and/or receivers. In general, the transmit/receive functions performed within the RF and modem subsystem 16 are implemented in software using digital processing techniques. However, some of the functions can also be performed using hardware-based modules for providing added functionality. For example, a GPS card

56 having a corresponding antenna 58 can be implemented within the RF and modem subsystem 16 for performing a location function. Similarly, a cellular communications card 62 and corresponding cellular antenna 64 can be provided for establishing a link to a cellular system. In addition, various other standard, commercially available communications "slices" 90,92 can be provided within the RF and modem subsystem

16. In general, hardware-based modules will be used whenever they are practical

(e.g., whenever low-cost, high volume commercial units are available). in addition to the above, some of the transmit/receive functions can be performed by dedicated hardware units external to the RF and modem subsystem 16. For example, as illustrated in FIG. 2, a series of power amplifiers 36 can be provided for amplifying communications signals before they are transmitted into one or more wireless communications channels via corresponding antennas 34. Also, a switch 40 and a co-site unit 38 can be provided for reducing co-site interference. Other functions that may be desirable to perform outside the RF and modem subsystem 16 include, for example, low noise amplification, up conversion/down conversion, signal beamforming (in phased array applications), power limiting, antenna multiplexing, and other such functions. The security subsystem 18 is operative for providing, among other things, encryption/decryption services within the communications apparatus 10. The security subsystem 18 is also operative for maintaining separation between the clear-text and encrypted signals. The encryption/ decryption services are preferably performed as software routines within a processor in security unit 70. In general, the security unit 70 will include individual software objects for a plurality of different encryption schemes. As discussed previously, these software objects can be individually invoked from anywhere in the communications apparatus 10. The security unit 70 can also include software objects for performing other security related functions, such as determining an appropriate encryption key for use with a particular user of the apparatus 10. Software objects can also be provided for investigating a current user of the apparatus 10 to determine whether he/she is authorized to use the apparatus 10. This function can include, for example, comparing a signal signature of a received signal to stored signatures of known service pirates. To support such features, the security unit 70 can include a mass storage device (not shown) for storing, for example, user profiles, signal signatures, and/or encryption key information.

The NCS 20 is operative for providing an interface between the communications apparatus 10 and one or more external user devices 60. An external user device 60 can include virtually any system or single unit for providing input/output with one or more users. For example, in one application, the NCS 20 provides a link between the communications apparatus 10 and one or more external wired communications networks such as, for example, a local area network (LAN) within an office building. In another application, the NCS 20 provides an interface to a single personal computer, via a hardwired connection. In a mobile application, the communications apparatus 10 can be implemented in a handheld communicator, in which case the user device 60 includes a microphone, speaker, keyboard, and display unit. In still another application, the NCS 20 provides a connection to a private branch exchange (PBX) telephone system for providing an interface with multiple users of the PBX. In yet another application, the communications apparatus 10 is implemented in a basestation and the NCS 20 provides an interface to a public switched telephone network (PSTN). In addition, the NCS 20 can provide links to any combination of the above-identified systems and/or other systems. As can be appreciated, the types of user connections that can be supported by the NCS 20 are virtually limitless. To interface with multiple users, the NCS 20 will include at least one software object corresponding to each of the external user devices 60 that will be serviced by the communications apparatus 10. These software objects are invoked within the apparatus 10 whenever communications with an associated user is desired.

It should be appreciated that any of the above described subsystems 16,18,20, or any additional subsystems, can be split into multiple sub-subsystems which are each linked to the software bus 12. For example, the RF and modem subsystem 16 can be implemented as a separate RF subsystem and modem subsystem. Also, in one embodiment of the invention, an inter-ORB protocol (IOP) is used to establish a connection between multiple ORBs within the communications apparatus 10. It should be noted that, although convenient, the present invention does not require that related software objects be located within a common subsystem. That is, an apparatus 10 having, for example, encryption objects distributed throughout all available subsystems would not be outside the spirit and scope of the present invention.

The RF and modem subsystem 16 communicates with external communications entities via one or more antennas 34. The RF and modem subsystem 16 communicates with the antennas 34 via a plurality of antenna ports 32.

Each of the antennas 34 is capable of radiating electromagnetic energy into and receiving electromagnetic energy from a corresponding wireless communications channel. The external communications entities can include virtually any entity that is capable of performing wireless communication. For example, an entity can include a handheld communicator, a microwave antenna mounted atop an office building, a police band radio, a communications satellite, a GPS satellite, or any other external wireless communications platform. The antennas 34 can include virtually any type of antenna for radiating/receiving electromagnetic energy including, for example, a patch antenna, a slot antenna, a horn antenna, a dipole antenna, or an array antenna. With reference to FIG. 2, it should be noted that the RF and modem subsystem

16 can be implemented as a multichannel device. That is, multiple external communications channels can be supported by the apparatus 10 by providing individual processing functionality within the RF and modem subsystem 16 for each of the channels. As shown in FIG. 2, the illustrated embodiment includes four separate channels (i.e., channels A, B, C, and D) each having corresponding modem 50, transmit/receive 52, and preselector 54 functionality. Each of the channels is connected to a dedicated antenna 34 for communicating with a corresponding wireless communications channel. In an alternative approach, antenna sharing can be implemented or an array antenna having multiple independent beams can be utilized. In one embodiment of the invention, the modem functions 50A-50D are ail implemented in a first processor, the T/R functions 52A-52D are all implemented in a second processor, and the preselect functions 54A-54D are all implemented in a third processor. A controller is then used to control the "flow" of information through the processors for the four channels (e.g., using the software bus 12). In another approach, each of the channels (i.e., channels A, B, C, and D) is implemented in a separate processor having the appropriate objects stored therein.

FIG. 3 is a block diagram illustrating a possible hardware configuration for an RF and modem subsystem 66 in accordance with one embodiment of the invention. As shown, the RF and modem subsystem 66 includes: a GPP 72A, a DSP 72B, a

RISC 72C, a hardware bus 74 having a plurality of interface ports 78A-78n, a controller 80, a mass storage unit 82, a global positioning system (GPS) plug-in module 84, and a cellular transceiver plug-in module 86. In the illustrated embodiment, each of the different processors 72A-72C is operative for performing a particular type of operation. For example, the GPP 72A performs preselector functions, the DSP 72B performs transmit/receive functions, and the RISC 72C performs modulation/demodulation functions. In general, the complexity of the processing functions to be performed will dictate the type of processor to be used. The processors 72A-72C each include a RAM for storing a plurality of software objects to be executed by the corresponding processor (as well as other programs and data). The processors 72A-72C are each individually coupled to the hardware bus 74 for use in communicating with one another and controller 80.

In a preferred embodiment of the invention, the hardware bus 74 is a standard, commercially available structure having standard hardware interface ports 78A-78n. These standard interface ports 78A-78n can include, for example, standard PC expansion slots and/or standard RS-232 connectors. Communications through the interface ports 78A-78n will preferably follow protocols that are well-known and rigorously defined in the industry. Each processor 72A-72C is preferably mounted on a circuit board having a standard connector for interfacing with a respective interface port 78A-78C.

The controller 80 is operative for, among other things, controlling the flow of information through the three processors 72A-72C for each of the channels (e.g., channels A, B, C, and D) of the communications apparatus 10. The controller 80 can also control the operation of the various plug-in modules attached to the hardware bus 74. In addition, the controller 80 can implement the software bus functionality within the apparatus 10. The controller 80 functionality can be implemented within a separate processor or it can be implemented within one of the three processors 72A- 72C. In general, the controller 80 will know the signal format being used in each of the channels of the apparatus 10. In this way, the controller 80 will know which functions need to be performed on communications signals for each channel. The controller 80, using the software bus functionality, invokes objects within the processors 72A-72C, in the appropriate order, to properly process communications signals within each channel. For example, after a signal is received from a particular external wireless communications channel, the controller 80 can process the signal by first invoking an appropriate preselector object within GPP 72A, then invoking an appropriate receive function within DSP 72B, and then invoking an appropriate demodulation function within RISC 72C. For signal transmission, the process would be reversed. Using the software bus functionality, the controller 80 will also be able to invoke objects within the other subsystems 18,20 to process the communications signals. In this manner, a signal flow can be established through the entire apparatus

10. In one embodiment, the other subsystems 18,20 will also be connected to the hardware bus 74.

The mass storage unit 82 can be virtually any form of nonvolatile memory. In a preferred embodiment, the mass storage unit comprises a hard disk drive. The mass storage unit 82 can be used to store any information needed by the controller 80 to perform its functions. For example, the mass storage unit 82 can be used to store all of the interface information (and other information) needed by the software bus 12. The mass storage unit 82 can also be used to store all of the programs that will be implemented in the controller 80. Furthermore, the mass storage unit 82 can be used to store software objects and other programs that are to be implemented in the processors 72A-72C. Other uses are also possible. In a preferred embodiment, the controller 80 can receive configuration instructions from a user of the apparatus 10 via the hardware bus 74. Alternatively, a direct hardwired connection (not shown) can be maintained between the controller 80 and the user. In addition to configuration commands, the controller 80 can also receive new software objects from a user for supporting new or changing signal formats. The controller 80 can store the new software objects in the mass storage unit 82 for later use. As can be appreciated, the RF and modem subsystem 66 of FIG. 3 is capable of supporting a large and varying set of waveforms.

The GPS plug-in module 84 and the cellular transceiver plug-in module 86 are commercially available modules that include standard hardware interfaces. As shown, they are simply plugged into corresponding interface ports on the hardware bus 74. In addition, a plurality of expansion ports 78F-78n are provided for adding further cards or modules, such as commercially available slice modules Alternatively, or in addition, further processors can be added to the RF and modem subsystem 66 using the expansion ports 78G-78n.

Both the security subsystem 18 and the NCS 20 (as well as any other subsystems) will include at least one processor for executing respective objects. In general, whenever a program or object being executed in one of the processors of the communications apparatus 10 needs a particular function performed that it does not have direct access to, it will deliver a request to the software bus 12 which will attempt to locate a software object somewhere within the apparatus 10 that is capable of performing the function. If located, as discussed above, the software bus 12 will invoke the object and pass it any required information to perform the function. The software bus 12 will then return the results to the requesting functionality. If required, the software bus 12 can also search an attached network to locate the requested functionality. In the preferred embodiment, this is all transparent to the requesting entity. In one embodiment of the invention, one or more of the subsystems include reconfigurable hardware in addition to (or in place of) the processor/RAM combination. For example, a subsystem can include a field programmable gate array (FPGA) for processing communications signals. Like the processor/RAM, the FPGA can be periodically reconfigured to provide varying communications functions within the subsystem. Reconfiguration is achieved by delivering a configuration file to the FPGA instructing it how to set up internal connections within the unit. Configuration files can be created for supporting various different waveforms and/or other processing functions. Each processing function implemented within an FPGA is known as a hardware object. Currently available FPGAs allow multiple hardware objects to be implemented within a single FPGA unit. In addition, FPGAs are available that operate on either analog or digital signals.

Claims

CLAIMSWhat is claimed is:

1. A communications apparatus comprising: a plurality of subsystems each including a processor with an associated

memory, said processor being capable of executing software programs stored in said

associated memory, said software programs including at least one software object for

performing a predetermined processing function on a communications signal when

executed by said processor; a software bus, coupled to said plurality of subsystems, for providing an

interface between software programs located within different subsystems; and an interface memory, coupled to said software bus, for storing interface

information for use by said software bus in providing an interface between software programs.

2. The communications apparatus, as claimed in claim 1 , wherein: said software bus provides an interface between a software program in a first

subsystem and a software object in a second subsystem.

3. The communications apparatus, as claimed in claim 2, wherein:

said software bus invokes said software object in said second subsystem

based on a request from said software program in said first subsystem.

4. The communications apparatus, as claimed in claim 1 , wherein:

said software bus includes an object request broker (ORB) in accordance with a Common Object Request Broker Architecture (CORBA) standard.

5. The communications apparatus, as claimed in claim 4, wherein:

said interface memory includes an interface repository library (IRL) in

accordance with the CORBA standard.

6. The communications apparatus, as claimed in claim 1 , wherein:

said software bus is capable of (i) receiving a request for a specified processing function to be performed and (ii) locating a software object in one of said plurality of subsystems that is adapted to perform said specified processing function.

7. The communications apparatus, as claimed in claim 6, wherein: said software bus is capable of invoking said software object, transferring

appropriate parameter values to said software object, and returning results to a

source of said request.

8. The communications apparatus, as claimed in claim 1 , wherein:

said software bus has access to software objects external to said

communications apparatus.

9. The communications apparatus, as claimed in claim 1 , wherein:

said software bus includes means for tracking software object locations within said plurality of subsystems.

10. A communications apparatus comprising: at least one antenna for communicating with a wireless communications

channel;

a radio frequency (RF) subsystem, coupled to said at least one antenna, for

processing a communications signal received from or to be transmitted into said

wireless communications channel, said RF subsystem including a first processor and a first memory, wherein said first processor is capable of executing first software

programs stored within said first memory, said first software programs including at least one first software object, wherein each first software object is adapted to perform

a specific transmit/receive function; a user interface subsystem for interfacing with a user of said communications apparatus, said user interface subsystem including a second processor and a second

memory, wherein said second processor is capable of executing second software programs stored within said second memory, said second software programs

including at least one second software object, wherein each second software object is adapted to perform a specific user interface function; and

a software bus, coupled to said RF subsystem and said user interface subsystem, for providing an interface between software programs within different

subsystems in said communications apparatus, said software bus including means for

receiving a request for a specified processing function to be performed and means for

locating a software object that is capable of performing said specified processing function.