KR20010034892A - Communications system having a distributed object architecture - Google Patents

Abstract

The communication device 10 includes a plurality of subsystems 16, 18, 20 that are each connected to a software bus 12. Each of subsystems 16, 18, and 20 includes at least one processor 42 having associated memory for storing a plurality of software objects 30, each associated with a particular processing function. The software bus 12 provides, among other things, an interface between software objects 30 located in different subsystems, so that one software object 30 is connected to any other software object 30 in the communication device 10. Acts to allow calling). 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

Telecommunication systems up to now generally use communication equipment designed to perform one or a few pre-allocated tasks to perform communication between users. Such equipment generally works well within a narrow range of designed operations but cannot adapt to changing system requirements. Therefore, systems with such equipment have a limited range of use, and tend to become obsolete before the associated hardware reaches its intended life. This leads to situations where expensive redesigns of the system are common and functional hardware units are discarded prematurely.

FIELD OF THE INVENTION The present invention relates generally to communication systems, and more particularly to communication systems capable of supporting a wide variety of different signal formats.

1 is a block diagram illustrating a communication device according to an embodiment of the present invention.

FIG. 2 is a block diagram illustrating functional interrelationships within the communication device of FIG. 1 in one embodiment of the present invention. FIG.

3 is a block diagram illustrating a hardware structure for a radio frequency (RF) subsystem in accordance with an embodiment of the present invention.

Therefore, there is a need for communication equipment that can adapt to changing system requirements.

The present invention relates to a communication device having a distributed object configuration. The communication device has a plurality of communication subsystems all linked to the software bus. Each communication subsystem has at least one processor, such as a general purpose microprocessor or a digital signal processor, for processing communication signals within the device. Each processor has an associated memory for storing a software program to be executed by the processor. Some software programs, known as software objects, are special purpose programs that each operate to perform a particular processing function (in association with an associated processor). The software bus allows a program or object inherent in one of the communication subsystems to invoke a software object inherent in another subsystem in the device. That is, if a program to be run 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 to perform the function, then the program is required. To do this, you can use the software bus function to locate and call objects within other subsystems. The software bus also allows information flow between subsystems within the device.

In a preferred embodiment of the present invention, most or all software and hardware interfaces in the communication device follow a standard (ie, published) interface protocol that is strictly formally described in the industry. As an example, in one embodiment, the software bus includes an Object Request Broker (ORB) conforming to the Common Object Request Broker Architecture (CORBA) developed by the Object Management Group. In addition to using a standard interface, the communication device of the present invention preferably provides hardware scalability that allows hardware modules to be added to the device quickly and easily via standard hardware interface connections. The communication device of the present invention is very flexible, highly upgradable, and can perform a vast and variable range of communication applications.

1 is a block diagram illustrating a communication device 10 according to an embodiment of the present invention. As shown, the communication device 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 shown in FIG. 1 represent functional elements that do not necessarily correspond to individual hardware units. In the illustrated embodiment, each subsystem 16, 18, 20 is adapted to perform a particular class of communication function. In one example, RF and modem subsystem 16 performs particularly typical transmit / receive and modulation / demodulation functions; Security subsystem 18, among other things, performs data encryption / decryption functions; The NCS 20 performs, among other things, user interface functions in particular. However, it should be appreciated that the invention is not limited to the use of bus systems for specific purposes.

Each subsystem 16, 18, 20 has one or more processors 42 to perform its assigned functions. Each processor 42 may be a general purpose microprocessor (GPP), a reduced instruction set computer (RISC), a complex instruction set computer (CISC), although other processing elements may be appropriate. Or a commercially available digital processing element, such as a digital signal processor (DSP). Each processor 42 may have associated memory (such as random access memory) for storing one or more software objects 30 (and possibly other programs) to be executed by the processor 42. Equipped. As mentioned above, each such software object 30 represents a software program for performing a particular processing function. In general, each software object 30 may be independently called and executed within the corresponding processor 42 to perform its respective functions. As used herein, the term "software object" refers to any limited purpose software routine regardless of the programming language. As shown, the software object 30 may be stored at various locations within each subsystem 16, 18, 20. In order to call a particular software object 30 within the communication device 10, it is necessary to know where the object 30 is located within the device 10. The software bus 12 stores the locations of the various software objects 30 within the device 10, and thus knows the location of the objects to find when a particular processing function needs to be performed.

During operation, software bus 12 receives a request from a subsystem of one of subsystems 16-20 to cause a particular processing function to be performed. The software bus 12 then locates the software object 30 that can perform the requested function. Once the location is found, the software bus 12 calls the software object 30 and passes any information needed to perform the desired processing function to the called software object. After the process is completed, the software bus 12 again passes the process result to the requesting entity. The entity making the request may be any function within the device 10 that is linked to the software bus 12. In a typical mode of operation, a control program running within one of the subsystems 16, 18, and 20 sends a request to the software bus 12 to perform a specific function, such as a demodulation function, on the communication signal. send. After the function has been performed and the result returned, the control program now sends another request to the bus to perform another function, such as a decryption function. This process is repeated until all necessary processing is performed on the communication signal. In this way, data "flows" across the communication device 10 are established.

In a preferred embodiment of the present invention, the functionality of the software bus 12 is implemented in software within the communication device 10. That is, one of the processors in device 10 executes a software bus program inherent in the associated memory to perform the function of software bus 12. Requests to the software bus 12 are forwarded to the appropriate port of the running processor. The software bus program then processes the requests as described above. The software bus program may be embedded in any processor in the communication device 10. In one example, the program may be embedded within one of the subsystems 16, 18, 20, or may be embedded within a separate dedicated processor. In general, the functionality of the software bus 12 will be substantially transparent to the entity making the request. That is, the entity making the request will not know the location of the software object 30 to be called. In one embodiment of the present invention, the software bus 12 includes a function for linking to another software bus, either inside or outside the communication device 10. In one example, software bus 12 may link to another software bus in an external user network, thereby providing a source of additional objects for use in communication device 10. Such external connection may be implemented using functionality within NCS 20 as an example.

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

In a preferred embodiment of the present invention, the software bus 12 comprises an object request broker (ORB) according to 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 in Revision 2.1 in August 1997. , Which is incorporated herein by reference. The CORBA standard defines the interface definition language (IDL) used to describe the software interface to the software bus 12. Since these software interfaces are strictly defined and publicly available, anyone can design software objects that can interface with the ORB. The ORB can provide an interface between virtually any two objects, regardless of the programming language used. That is, a first software object written in C language and located in RF and modem subsystem 16 may interface with a second software object written in ADA language and located in NCS 20. In general, after the ORB finds a location of an object capable of performing the requested function, the ORB obtains the interface information necessary to provide an interface between the object making the request and the object. Usually, a "stub" is retrieved by the ORB to provide an interface between the object making the request and the ORB, and a "skeleton" by the ORB to provide an interface between the ORB and the selected object. Or "template" is searched. Stubs, skeletons, and templates are mostly implementation specific.

Under the CORBA standard, the interface memory 14 includes, among other things, an Interface Repository Library (IRL) accessible by an ORB to provide information relating to software interfaces. The IRL may, for example, provide persistent objects representing IDL information in a form available at runtime. IRLs store additional information such as, for example, debugging information, libraries of stubs, skeletons, and templates, routines for formatting or browsing certain kinds of objects, and others. It can also be used to. In addition to the IRL, the CORBA standard also defines an implementation repository, which, among other things, contains information that allows the ORB to locate or call software objects within the system.

FIG. 2 is a block diagram illustrating the interrelationship of functions within the communication device 10 of FIG. 1 in one embodiment of the present invention. As shown, the block diagram is divided into three separate functional units representing the RF and modem subsystem 16, the security subsystem 18, and the NCS 20. Further functional elements are also shown outside the three subsystems 16, 18, 20. In general, functional blocks within subsystems 16, 18, and 20 represent individual software objects (or groups of objects) that are implemented within subsystems 16, 18, and 20 to perform particular functions. The interconnection between functional blocks in other subsystems (such as the connection between RF and modem block 50A in modem subsystem 16 and security unit 70 in security subsystem 18) is in part software. The function of the bus 12 is shown. Likewise, the interconnection between functional blocks within the same subsystem (such as the connection between RF / T module 52A and modem 50A in RF and modem subsystem 16) is responsible for the functionality of software bus 12. It can also be indicated.

In a preferred embodiment of the present invention, the RF and modem subsystem 16 is responsible for performing most of the transmit / receive functions within the communication device 10. That is, RF and modem subsystem 16 perform functions such as signal modulation / demodulation, receiver preselection, channel coding / decoding, error detection / correction, and other functions normally performed at the transmitter and / or receiver. In general, the transmit / receive functions performed within the RF and modem subsystem 16 are implemented in software using digital processing techniques. However, some functions may also be performed using hardware based modules to provide additional functionality. As an example, the GPS card 56 with the corresponding antenna 58 may be implemented in the RF and modem subsystem 16 to perform the location finding function. Similarly, cellular communication card 62 and corresponding cellular antenna 64 may be provided to establish a link to the cellular system. In addition, various other standards, commercially available communication “slices” 90 and 92, may be provided within the RF and modem system 16. In general, hardware based modules will be used whenever they are practically applied (eg, whenever low-capacity commercial units are available).

In addition to the above functions, some transmit / receive functions may be performed by dedicated hardware units external to the RF and modem subsystem 16. For example, as shown in FIG. 2, a series of power amplifiers 36 may be provided to amplify the communication signal before the communication signal is transmitted through the corresponding antenna 34 to one or more wireless communication channels. have. Also, switch 40 and co-site unit 38 may be provided to reduce co-site interference. Other functions that may be desirable to perform outside of the RF and modem subsystem 16 include, for example, low noise amplification, up-conversion / down-conversion, signal beamforming {in phased array applications}, power limitation. , Antenna multiplexing, and other such functions may be included.

The security subsystem 18 operates to provide encryption / decryption services, among other things, in the communication device 10. Security subsystem 18 also operates to maintain separation between clear-text and encrypted signals. The encryption / decryption service is preferably performed by a software routine in the processor within the security unit 70. In general, security unit 70 will include separate software objects for a plurality of different encryption schemes. As discussed above, these software objects may be individually called from any place within communication device 10. The security unit 70 may also include a software object for performing other security related functions, such as determining an appropriate cryptographic key for use by a particular user of the device 10. In order to determine whether the current user is authorized to use the device 10, a software object for examining the user may also be provided. Such functionality may include, for example, comparing a signal signature of a received signal with a stored signature of a known service hijacker. To support such a feature, security unit 70 may include, for example, a mass storage device (not shown) for storing user profiles, signal signatures, and / or cryptographic key information.

The NCS 20 is operative to provide an interface between the communication device 10 and one or more external user elements 60. External user device 60 may comprise substantially a single unit or any system for providing input / output by one or more users. For example, in one application, NCS 20 provides a link between one or more external wired communication networks and communication device 10, such as, for example, a local area network (LAN) in an office building. In other applications, the NCS 20 provides an interface to a single personal computer via wire connections. In mobile applications, the communication device 10 may be implemented as a portable communicator, in which case the user element 60 comprises a microphone, a speaker, a keyboard, and a display unit. In another application, the NCS 20 provides a connection to a PBX telephone system to provide an interface with multiple users of a Private Branch Exchange (PBX). In another application, communication device 10 is implemented in a base station, and NCS 20 provides an interface to a public switched telephone network (PSTN). In addition, NCS 20 may provide a link to any combination of the above systems and / or other systems. As will be appreciated, the type of user connection that can be supported by the NCS 20 is substantially unlimited. In order to interface with multiple users, the NCS 20 will include at least one software object corresponding to each of the external user elements 60 to be serviced by the communication device 10. Such software objects are invoked within the device 10 whenever communication with the associated user is required.

It should be appreciated that any of the subsystems 16, 18, 20 described above or any additional subsystem may be divided into multiple sub-subsystems, each linked to a software bus 12. In one example, the RF and modem subsystem 16 may be implemented as separate RF subsystems and modem subsystems. In addition, in one embodiment of the present invention, an inter-ORB protocol (IOP) is used to establish a connection between a plurality of ORBs in the communication device 10. Although convenient, it should be noted that the present invention does not require that related software objects be located in a common subsystem. In other words, a device 10 having cryptographic objects distributed across all available subsystems will not depart from the spirit and scope of the present invention.

The RF and modem subsystem 16 communicates with an external communication entity via one or more antennas 34. The RF and modem subsystem 16 communicates with the antenna 34 through a plurality of antenna ports 32. Each antenna 34 may radiate electromagnetic energy to a corresponding wireless communication channel and may also receive electromagnetic energy from the wireless communication channel. The external communication entity can substantially include any entity capable of performing wireless communication. In one example, the subject may include a portable communication device, a microwave antenna mounted on top of an office building, a police band radio, a communication satellite, a GPS satellite, or any other external wireless communication platform. Antenna 34 may include substantially any type of antenna for radiating / receiving electromagnetic energy, including, for example, patch antennas, slot antennas, horn antennas, dipole antennas, or array antennas.

2, it should be noted that the RF and modem subsystem 16 may be implemented as a multichannel device. That is, multiple external communication channels may be supported through the device 10 by providing separate processing functions for each channel within the RF and modem subsystem 16. As shown in Fig. 2, the illustrated embodiment shows four separate channels (i.e., channels A, B, C) each having corresponding modem 50, transmitter / receiver 52, and preselector 54 functions. , And D). Each channel is connected to a dedicated antenna 34 for communicating with a corresponding wireless communication channel. In an alternative approach, sharing antennas may be implemented, or an array antenna having multiple independent beams may be used. In one embodiment of the present invention, the modem function units 50A to 50D are all implemented as the first processor, the T / R function units 52A to 52D are all implemented as the second processor, and the preselection function unit ( 54A to 54D are all implemented with a third processor. Next, a controller is used to control the “flow” of information through the processors for the four channels (eg, using the software bus 12). In another approach, each channel (ie channels A, B, C, and D) is implemented as a separate processor with the appropriate objects stored therein.

3 is a block diagram illustrating possible hardware configurations for the RF and modem subsystem 66 in accordance with one embodiment of the present invention. As shown, RF and modem subsystem 66 includes GPP 72A, DSP 72B, RISC 72C, hardware bus 74 with a plurality of interface ports 78A-78n, controller 80 ), Mass storage unit 82, global positioning system (GPS) plug-in module 84, and cellular transceiver plug-in module 86. In the illustrated embodiment, each other processor 72A-72C is operative to perform a particular type of operation. For example, the GPP 72A performs a preselection function, the DSP 72B performs a transmit / receive function, and the RISC 72C performs a modulation / demodulation function. In general, the type of processor to be used will be specified depending on the complexity of the processing functions to be performed. Each of the processors 72A-72C has a RAM for storing a plurality of software objects (as well as other programs and data) to be executed by the corresponding processor. Processors 72A-72C are each individually connected to a hardware bus 74 for use in communication with each other and with controller 80.

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

The controller 80, among other things, controls the flow of information through three processors 72A-72C for each of the channels (e.g., channels A, B, C, and D) of the communication device 10. To work. The controller 80 may also control the operation of the various plug-in modules attached to the hardware bus 74. The controller 80 may also implement software bus functionality within the device 10. The functionality of the controller 80 may be implemented within each processor or may be implemented within one of the three processors 72A-72C. In general, the controller 80 will know the signal format used for each channel of the device 10. In this way, the controller 80 will know what function needs to be performed on the communication signal for each channel. The controller 80, using the software bus function, calls the objects in the processors 72A-72C in the proper order to properly process the communication signals in each channel. In one example, after a signal is received from a particular external wireless communication channel, controller 80 first calls the appropriate preselector object in GPP 72A, then calls the appropriate receive function in DSP 72B, and then The signal can then be processed by invoking the appropriate demodulation function in RISC 72C. For signal transmission, the processing will be performed in reverse. Using the software bus function, the controller 80 may also call objects in other subsystems 18 and 20 to process communication signals. In this way, signal flow can be established throughout the device 10. In one embodiment, other subsystems 18 and 20 will also be connected to the hardware bus 74.

Mass storage unit 82 may be substantially any type of nonvolatile memory. In a preferred embodiment, the mass storage unit comprises a hard disk drive. Mass storage unit 82 may be used to store any information that the controller needs to perform its function. In one example, mass storage unit 82 may be used to store all interface information (and other information) required by software bus 12. Mass storage unit 82 may also be used to store all programs to be implemented in controller 80. The mass storage unit 82 may also be used to store other programs and software objects to be implemented in the processors 72A to 72C. Other uses are also possible.

In a preferred embodiment, the controller 80 can receive configuration commands from the user of the device 10 via the hardware bus 74. Alternatively, a direct hardware connection (not shown) can be maintained between the controller 80 and the user. In addition to the configuration commands, the controller 80 may also receive new software objects from the user to support new or changing signal formats. The controller 80 can store the new software object in the mass storage unit 82 for later use. As can be appreciated, the RF and modem subsystem 66 of FIG. 3 can support a large and deformable set of waveforms.

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

Both security subsystem 18 and NCS 20 (as well as any other subsystem) will include at least one processor for executing each object. In general, whenever a program or object running on one of the processors of the communication device 10 needs to be executed by a particular function that is not directly accessed, the program or object is capable of performing the function. It will forward a request to the software bus 12 requesting to locate the software object somewhere in (10). If a location is found, as discussed above, software bus 12 will call the object and pass any necessary information to the object to perform that function. The software bus 12 will then return the result to the request function. If necessary, the software bus 12 may also search the assigned network to locate the requested function. In a preferred embodiment, the functionality of the software bus is completely transparent to the entity making the request.

In one embodiment of the invention, the one or more subsystems include reconfigurable hardware in addition to (or instead of) a processor / RAM combination. In one example, the subsystem may include a field programmable gate array (FPGA) to process communication signals. Like the processor / RAM, the FPGA can be periodically reconfigured to provide changing communication functionality within the subsystem. Reconfiguration is accomplished by passing a configuration file to the FPGA that instructs how it configures internal connections within the unit. Configuration files may be generated to support different waveforms and / or process functions. Each processing function implemented in an FPGA is known as a hardware object. Currently available FPGAs allow several hardware objects to be implemented in a single FPGA unit. In addition, FPGAs that operate on analog or digital signals are available.

Claims (2)

A plurality of subsystems, each having a processor with an associated memory, the processor capable of executing a software program stored in the associated memory, wherein the software program, when executed by the processor, performs predetermined processing functions for communication signals. A plurality of subsystems having at least one software object to perform, A software bus coupled to the plurality of subsystems to provide an interface between software programs located in different subsystems; An interface memory coupled to the software bus, the interface memory storing interface information to be used by the software bus in providing an interface between software programs. At least one antenna for communicating with a wireless communication channel, A radio frequency (RF) subsystem coupled to the at least one antenna for processing communication signals to be received from or transmitted to the wireless communication channel, the RF subsystem comprising a first processor and a first memory. Wherein the first processor is capable of executing a first software program stored in the first memory, the first software program having at least one first software object, each first software object having a particular transmission / reception. A radio frequency (RF) subsystem, adapted to perform a receive function; A user interface subsystem for interfacing with a user of a communication device, the user interface subsystem having a second processor and a second memory, the second processor capable of executing a second software program stored in the second memory and The user interface subsystem having at least one second software object, each second software object adapted to perform a particular user interface function; A software bus coupled to the RF subsystem and the user interface subsystem to provide an interface between software programs in other subsystems in the communications device, the software bus comprising: means for receiving a request for a particular processing function to be performed; And a software bus having means for locating a software object capable of performing a particular processing function.