This invention relates in general to the field of electronics, and more specifically to an InterProcessor Communication (IPC) protocol/network with high level service composition.
Most electronic systems include a number of networked elements (components) such as hardware and software that form the system. In most systems there is a layer responsible for communication between the different components that form a networked element as well as between the different networked elements themselves. This layer is typically referred to as the InterProcessor Communication (IPC) layer.
Several protocols have been introduced in the last few years to deal with interprocessor communications. One example of an IPC product is PCI AGP Controller (PAC) that integrates a Host-to-PCI bridge, Dynamic Random Access Memory (DRAM) controller and data path and an Accelerated Graphics Port (AGP) interface. Another example of an IPC product is the OMAP™ platforms. Neither of these platforms provide much if any support above the hardware level and provide little design flexibility at the lower level component or channel levels (physical layer).
The PAC platforms for example, are closed architectures and are embedded into the Operating System's TAPI layer, with the IPC code not being accessible to developers. Therefore, these platforms do not extend to the component levels and they also do not allow for dynamic assignment of IPC resources, hardware support capabilities, or multi-node routing, etc. With the need to sometimes combine different types of services together for use by a component in a system, an IPC network that can allow for the dynamic combining of different services (e.g., camera and JPEG services) to form a combined service would be very beneficial. Also, the ability to handle different “definitions” of the same service would also be beneficial in an IPC network where, for example, the definition of audio service may be different for two different processors coupled to an IPC network. Given the above, a need thus exists in the art for an IPC protocol that can provide a solution to some of these shortcomings in the prior art.
The features of the present invention, which are believed to be novel, are set forth with particularity in the appended claims. The invention may best be understood by reference to the following description, taken in conjunction with the accompanying drawings, in the several figures of which like reference numerals identify like elements, and in which:
While the specification concludes with claims defining the features of the invention that are regarded as novel, it is believed that the invention will be better understood from a consideration of the following description in conjunction with the drawing figures.
The IPC of the present invention provides the support needed for different processors operating in a system to communicate with each other. For example, in a dual processor (or multi-processor) radio architecture for use in a radio communication device that includes an Application Processor (AP) and a Baseband Processor (BP), the IPC provides the support needed for the processors to communicate with each other in an efficient manner. The IPC provides this support without imposing any constrains on the design of the AP or BP.
The IPC allows any processor that adopts the IPC as its inter-processor communication stack to co-exist together and operate as if the two were actually running on the same processor core sharing a common operating system and memory. With the use of multiple processors in communication devices becoming the norm, the IPC of the present invention provides for reliable communications between the different processors.
The IPC hardware provides the physical connection that ties together the different processors to the IPC network. Data packets are preferably transported between the different hosts asynchronously in one embodiment of the invention. Processors that are connected to the IPC network have their physical and logical addresses statistically or dynamically assigned (e.g., IPC addresses). Also, since data packets can flow in any direction within the IPC network in one embodiment of the invention, they need to carry a destination address of the processor that they are trying to reach. Packets are also preferably checked for errors using conventional Cyclic Redundancy Check (CRC) techniques. Although the network activities of the IPC network of the present invention may have some similarities to those found on an internet network that uses IP transport layers such as a Transmission Control Protocol/Internet Protocol (TCP/IP) network, the IPC of the present invention is not divided into smaller networks with gateways as in a TCP/IP network.
Referring now to
In
(1). IPC Presentation Manager (202)—this layer is used to translate different data types between different system components (e.g., software threads).
(2). IPC Session Manager (204)—this layer is a central repository for all incoming/outgoing IPC traffic between the IPC stack and all of the system components. The IPC session manager 204 has several functions: assignment of component IDs for participating IPC components; deciding if the IPC data needs to be encapsulated; routing of IPC data, termination of IPC traffic; place holder for IPC processors; providing IPC addresses, assigning and authenticating IPC clients, etc.
IPC Transport Layer (208)—located within the IPC session manager (layer) 204, the IPC transport layer 208 provides a very basic cyclic redundancy check for the purpose of transporting the IPC data between the different processors. In addition, the IPC transport layer 208 is responsible for routing IPC messages to their final destinations on the IPC network 100. The routing function of the transport layer is enabled only on IPC servers.
IPC Router Block (210)—transports the IPC data to a destination component (not shown). Incoming IPC messages carry among other things, the originator component ID, the IPC message opcodes such as Audio and Modem. Note that in accordance with an embodiment of the invention, a unique opcode is assigned to each component/software thread (see for example 502 in
(3). Device Interface Layer (206)—is responsible for managing the IPC physical-to-logical IPC channels. Its main function is to abstract the IPC hardware completely so that the stack IPC becomes hardware independent. The device interface layer 206 manages the physical bandwidth of the IPC link underneath to support all of the IPC logical channels. In the incoming path, the device interface layer 206 picks up data from different physical channels 110-114 and passes them up to the rest of the IPC stack. On the outgoing path, the device interface layer 206 manages the data loading of the IPC logical channels by sending them onto the appropriate physical channels. The device interface layer 206 also handles concatenating IPC packets belonging to the same IPC channel before sending them to the IPC hardware. Channel requirements are pre-negotiated between the IPC session manager 204 and the IPC device interface layer 206. The device interface layer 206 provides for hardware ports which in turn provide a device interface to an IPC client 102-106.
Referring to
Referring now to
In
Referring now to
More detailed steps taken during the IPC client initialization process are shown in
The parameters in the configuration request include the node type and the data type. The session server in response to the configuration request in step 702 assigns the requestor an IPC address. It also sets up a dynamic routing table for the requester if one does not exist. It then sends the requestor a configuration indication as in step 708. The configuration indication parameters include the IPC address of the server and the newly assigned IPC address of the client.
In response to receiving the configuration indication, components attached to the session client can request control/data from the client's session manager. The Session client then sends a configuration indication confirm message to the session server in step 710. The “configuration indication confirm” message has no parameters. Upon receiving the configuration indication confirm message in step 710, the session server can initiate IPC streams to the newly configured session client. The session server then sends configuration update messages to the session clients in steps 712 and 714. This causes both session clients shown in
When a packet is received by an IPC session manager, it comes in the form of data that includes the source component ID, the destination ID, a channel ID and the type of BP or AP. The IPC session manager will add the destination component ID in the event that the destination ID is not inserted. The IPC session manager will also insert an IPC address. It is the IPC session manager that discovers the destination ID based on the message opcode received. The destination ID is based on a lookup table. This lookup table is updated dynamically each time a component subscribes to a new IPC message opcode (e.g., an audio component subscribes to audio messages by sending a request to the IPC session manager).
In
In
The same component initialization process is shown between a component (client) 1002, a session (client) also known as a client session manager 1004 and the session (server) also known as the server session manager 1006 in
In response to the request, the client session manager 1004 negotiates a logical channel with its device layer (not shown). The client session manager 1004 also assigns a component ID and adds the new opcode list to its dynamic routing table (not shown). In step 1010, the client session manager 1004 sends a configuration reply which includes the component ID and the channel ID as parameters. In response to the configuration reply, the component (client) 1002 receives its ID and channel ID from the client's session manager 1004.
Once the client session manager 1004 replies in step 1010 to the configuration request in step 1008, the client session manager 1004 sends a configuration update request in step 1012 to the session server 1006. The parameters for the configuration update request are any new changes that have been made in the dynamic routing table. The session manager updates the dynamic routing table for that IPC address. The server session manager 1006 in step 1016 then sends all the IPC clients a configuration update, while it sends the IPC client a configuration update indication in step 1014. The server's session manager 1006 makes sure the IPC server has updated its routing table with the changes that were sent.
In the configuration update message of step 1016 which includes the dynamic routing tables as a parameter(s), the session server 1006 updates the dynamic routing tables and sends a configuration update confirm message in step 1018. The session server 1006 then makes sure all of the IPC participants have been updated.
The IPC session manager determines the routing path of incoming and outgoing IPC packets. The route of an outgoing packet is determined by the component's IPC address. If the destination address is found to be that of a local processor, a mapping of the IPC to the Operating System (OS) is carried out within the session manager. If the destination address is found to be for a local IPC client, the packet is sent to the IPC stack for further processing (e.g., encapsulation). Note that if the destination component is located on the same processor as the component sending the IPC packet, no encapsulation is required and the packet gets passed over through the normal OS message calling (e.g., Microsoft Message Queue, etc.). In this way components do not have to worry about modifying their message input schemes. They only need to change their message posting methodologies from an OS specific design to an IPC call instead.
For incoming packets, if the destination address of the message is not equal to the IPC server's, the incoming packets are routed to the proper IPC client. The routing of incoming packets is handled by the session manager of the IPC server. Otherwise, the message is forwarded to the right component or components depending on whether or not the component destination ID is set to a valid component ID or to 0×FF.
The IPC router block transports the IPC data to the destination component. Incoming IPC messages carry among other things, the originator component ID and the IPC message opcodes such as those for Audio, Modem, etc. The IPC session manager relies on its component routing table to send the IPC data to the right component(s). Both the dynamic routing table and the component routing table are updated by the IPC server/client.
During power-up, each component must register itself with its session manager to obtain an IPC component ID. In addition, it must also subscribe to incoming IPC messages such as Audio, Modem, etc. This information is stored in the component routing table for use by the IPC session manager.
When a component 1102, as shown in
In
A typical IPC data request in accordance with an embodiment of the invention is shown in
In step 1304, the component update indication is sent to the component. If the node type is equal to 0×FF, the node tables are returned to the component. If the opcode field is equal to 0×FF, the list of opcodes is returned to the component. However, if the opcode is a specific value, a true or false message is returned. In step 1306, a component data request is made. The parameters for the component data request include the node type, the IPC message opcode, the IPC message data, the channel ID and the component ID. In a component data request, the session manager checks the node type to determine whether the opcode is supported. If the node type does not support the opcode, a component update indication is sent in step 1308. If however, the node type supports the opcode, a data request is sent to the device layer in step 1310. The data request parameters include the IPC message, the channel ID and the IPC header.
The device layer schedules to send the data request message based on the channel ID. The device layer selects the IPC hardware based on the port # header information. Once the data is committed, a data confirm message is sent to the session manager in 1312. In step 1314, the session manager proceeds to send a component data confirm message to the component. The component can wait for the confirmation before sending more IPC messages. Once a data confirm is received, the component can proceed to send the next IPC message.
In step 1316, the device layer sends a data indication message including IPC message data and an IPC header. The session manager checks the destination IPC header of the message, and if different from the local IPC address, the session manager sends (routes) the message to the right IPC node. In step 1310, the session manager sends a data request to the device layer with a reserved channel ID. The session manager checks the destination component ID, and if it is equal to 0×FF, routes the message to all the components subscribed to that opcode. In step 1318, the session manager sends a component data indication message and the component receives the IPC data.
The IPC stack uses a reserved control channel for communication purposes between all participating IPC nodes. On power-up, the IPC server's session manager uses this link to broadcast messages to IPC clients and vice versa. During normal operations, this control channel is used to carry control information between all APs and BPs.
In
IPC Application Program Interfaces (APIs)
Below are listed some of the APIs for the IPC protocol of the present invention.
1). Component Interface to the IPC session manager:
CreateComponentInst( )
OpenChannelKeep( )
OpenChannel( )
OpenChannelWThru( )
CloseChannel( )
ChannelGrant( )
ChannelError( )
ChannelDataIndication( )
DataChannelRequest( )
ChannelClose( )
OpenChannel( )
CloseChannel( )
ChannelGrant( )
ChannelError( )
ChannelDataIndication( )
DataChannelRequest( )
ChannelClose( )
ChannelDataIndication( )
OpenChannel( )
CloseChannel( )
ChannelGrant( )
ChannelError( )
ChannelDataIndication( )
DataChannelRequest( )
ChannelClose( )
In
The IPC protocol allows for the dynamic addition of any IPC conforming MA into the IPC link for communication. Thus, an IPC network is formed without any compile time dependencies, or any other software assumptions. The IPC of the present invention presents a standard way for software components to communicate with the IPC stack and the hardware below the stack is also abstracted such that components can choose different links to communicate.
Referring now to
In
High Level Service Composition
Referring now to
In this particular example, the new photo service requested by the requesting IPC client 1902 is given a Service ID (also referred to simply as ID) such as a unique opcode provided by the IPC server 1908. The IPC server's session manager (not shown) will keep a higher level routing table in which the Service ID assigned to the photo service will point to the further IDs (e.g., opcodes) that make up the photo service. When a component or client requests a combined service by sending the new opcode or Service ID to the IPC server 1908, the IPC server 1908 will wait until all the components required for the service (e.g., JPEG 1916 and camera 1914) have registered before returning the go ahead to the requesting component/client 1902.
Components or clients can compose services dynamically and inform the IPC server 1908. This can be done by the requesting component or client 1902 sending a component-to-IPC session manager API (i.e., NewService( )) that informs the IPC server's session manager that the component/client has put together a “new” service that comprises one or more IDs, in this particular example the opcodes that refer to a camera and a JPEG service. The IPC server 1908 in response to receiving the new service API sets up a Service ID for the new combined service. The IPC server 1908 in turn discovers the elements (e.g., components, applications) that comprise a combined service from the IPC nodes that have registered. When all of the elements for the combined service have been located, the service is declared present and ready to go.
In this particular example, the IPC client 1902 will send the New Service API and will establish a new Service ID that is assigned by the IPC server 1908. This new Service ID will refer to the opcodes/IDs for a camera and the JPEG applications. The new ID for the photo service will be stored in the session manager for the IPC client 1902 and the IPC server 1908. In the IPC server 1908 a Service ID table will link the photo service ID with its constituent Ids (e.g., opcodes) for the camera and the JPEG application. Although a photo service has been discussed different services can be requested which combine a plurality of different IDs.
In the IPC architecture 1900, the software components can dynamically subscribe to different Service IDs. For instance, an audio software component on one MA, can subscribe to all opcodes related to audio it can support. The IPC client 1902 makes a note of the component subscription and informs the IPC server 1908 about the subscription. Components on any MA need only then send their IPC data with a particular Service ID assigned to the combined service. They need not know in advance what services are provided on the IPC network or where those services are supported.
The IPC network 1900 allows components to change service definition without affecting the interprocessor communications between different MAs. In addition, components do not need to know in advance the concept of a service, register during compile time with a service, nor need to check individually whether or not the services are available on the IPC network 1900. The IPC network 1900 learns dynamically the service and is able to identify the service availability on the network.
Referring to
Once the list of opcodes for the “service” have been determined, the IPC server 1908 in step 2006 will wait until all of the required service components have registered with the IPC network 1900. Once all of the required service components (e.g., JPEG 1916 and camera 1914) have registered, the IPC server 1908 gives the IPC client 1902 the go ahead to use the requested photo service. The IPC server 1908 can send a message to each of the required components requesting they be part of the combined service (e.g., photo service). Components such as the JPEG application 1916 and the camera 1914 can accept or deny being part of the service. If a component does not accept being part of the combined service, the IPC server 1908 will look for another component to support the service.
Once the IPC server 1908 has been able to get approval from all of the required components such as JPEG 1916 and camera 1914, the IPC server 1908 lets the requesting client 1902 know it can go ahead and use the service it has requested in step 2008. After the IPC client 1902 has finished using the photo service, it will send a message to the IPC server 1908 which will release the camera 1914 and JPEG service 1916 for use by other components/clients. If a component such as camera 1914 or JPEG service 1916 that is part of a service drops out for any reason during the use of the service by the requesting client 1902, the IPC server 1908 will attempt to locate a replacement, if it cannot find one in a timely fashion, the requesting component/client 1902 (or component) drops the use of the service.
The advantages of the IPC network 1900 to dynamically discover component services and support the concepts of a service include the benefit that the component development is independent of the IPC stack operations. Also, components can compose “services” dynamically, and components can have different definitions of the concept of the same service. As an example, the notion of an audio service can be different for an iDEN BP versus a PCS BP. The IPC can still route audio data to either by allowing the sending component, through the IPC network, to discover which audio service will serve it better.
While the preferred embodiments of the invention have been illustrated and described, it will be clear that the invention is not so limited. Numerous modifications, changes, variations, substitutions and equivalents will occur to those skilled in the art without departing from the present invention as defined by the appended claims.