WO2010010424A1

WO2010010424A1 - Transport independent multicast architecture

Info

Publication number: WO2010010424A1
Application number: PCT/IB2008/052962
Authority: WO
Inventors: Arto Palin; Juha-Matti Tuupola
Original assignee: Nokia Corporation; Nokia, Inc.
Priority date: 2008-07-23
Filing date: 2008-07-23
Publication date: 2010-01-28

Abstract

A system for streamlining communication between a plurality of nodes in a multi- transport architecture. For example, in a scenario wherein multiple communication requests are directed to the same information being provided by the same source, various embodiments of the present invention may facilitate multicast operation over one or more transports. The information may only have to be provided once by the providing node, but may be broadcast multiple times (e.g., to each consuming node). This multicast operation may be executed over various transports as determined by lower layers of the multi-transport architecture, and therefore, may be transparent to nodes in upper layers.

Description

TRANSPORT INDEPENDENT MULTICAST ARCHITECTURE

BACKGROUND

L Field of Invention:

[0001] Various embodiments of the present invention relate to communications between information providers and consumers, and more specifically, to an architecture for providing multicast communication via one or more wired and/or wireless transports.

2. Background:

[0002] In general, software programs may include instruction sets that are executable by a processor, and are further organized to receive input (e.g., data) for use in a calculation or determination resulting in an output. Software technology has evolved to transform these individual instruction sets into program modules that may in turn be integrated together to form more complex programs. Today's more-sophisticated software programs may receive various forms of input such as raw data, for example as stored in magnetic or optical storage, user input through various known types of user interfaces, measured or monitored information converted to electronic information from electronic and/or electromechanical sensors, etc.

[0003] In some instances, programs may be configured to produce data usable by other software applications. However, a problem may be presented in conveying the information from one program to another. If the relationship is known before the programs are created, then a specific strategy may be devised to convert one program's output into another program's input. Traditionally this strategy has led to functional but rigid software applications, requiring frequent and possibly substantial revisions due to changes in functionality, platform, architecture, etc.

[0004] Recently, more flexible modular architectures for sharing information amongst programs are emerging. These programs use modular program units, or "nodes," that can be revised or replaced without having to interrupt overall device operation. In particular, some nodes may contribute information to a shared memory space, while others may read previously stored information from the shared memory space or may combine these functions. Other types of nodes may also be specialized to provide communication services. Using this strategy, altering program elements (e.g., altering, adding or deleting one or more nodes) may not affect nodes that are actively communicating with other nodes, and memory usage may be optimized since information may be stored in a single location while being accessible to all of the nodes.

[0005] However, existing systems are designed only for conveying information utilizing "brute-force" strategies (e.g., without any optimization features). In particular, node interaction currently may operate in only a unicast mode, wherein data is conveyed from a single providing node to a single consuming node. This mode of operation is not problematic on a small scale, but if multiple consuming nodes are requesting the same information from the same providing node, the communication requirement created for the providing node (and its corresponding application or service) may be overwhelming. Moreover, communication delays and/or failures may occur because unicast operation requires each information request to be serviced individually by the providing node itself (e.g., via a separate response message), which may inundate communication resources.

[0006] There is currently no practical solution for streamlining communication when multiple nodes that are operating in a consuming mode request information from the same source (e.g., a service node) in an architecture where the providing node and consuming nodes interact in a shared memory space. This example scenario becomes even more complicated when the shared memory space spans various devices linked, for example, by wireless communication. Therefore, nodes interacting in the shared memory space (and/or their corresponding applications) may actually reside on different devices.

SUMMARY

[0007] Various embodiments of the present invention may include a method, computer program, device and system configured to streamline communication between a plurality of nodes in a multi-transport architecture. For example, in a scenario wherein multiple communication requests are directed to the same information being provided by the same source (e.g., an information providing node such as a service node), various embodiments of the present invention may facilitate multicast operation over one or more transports. The information may only have to be provided once by the providing node, but may be broadcast multiple times (e.g., to each consuming node). This multicast operation may be executed over various transports as determined by lower layers of the multi-transport architecture, and therefore, may be transparent to nodes in upper layers. [0008] In accordance with at least one embodiment of the present invention, a plurality of communication requests may be received in an intermediate layer of the multi-transport architecture. The communication requests may originate, for example, from application or service nodes residing on one or more devices in the multi-transport architecture. The intermediate layer may then determine if any of the plurality of communication requests that were received can be grouped. The grouping determination may be based on, for example, whether any of the plurality of communication requests are directed to the same information being provided by the same device. In this manner, each communication request that corresponds to particular data being requested from a particular source may be members of the same group. The plurality of communication requests may then be passed to a lower layer of the multi-transport architecture.

[0009] Communication requests that have been grouped may be forwarded to the lower layer of the multi-transport architecture in s group format. Using group format may provide the communication request information to the lower layer in a form indicating that multiple communication requests are directed to the same information being provided by the same source. Examples of group format may include send commands that include multiple communication requests as command parameters, send commands that include a special command parameter that signifies a group of communication requests, etc.

[0010] After the lower layer of the multi-transport architectures establishes that more than one communication request is directed to the same information being provided by the same source, a determination may be made as to whether some or all of the communication requests may be serviced via multicasting. A determination whether multicasting may be implemented may be based, for example, on whether devices on which the requesting nodes reside support common transports. If a common transport exists (e.g., a wireless communication medium is supported by the devices on which the consuming nodes reside) then these communication requests may be fulfilled via multicasting. Any communication requests that cannot be serviced utilizing multicast operation (e.g., due to no other communication requests with which to group or due to no common transports existing between grouped communication requests) may be serviced via unicast communication. Communicating by utilizing a unicast or multicast mode, in accordance with various embodiments of the present invention, may be determined by the lower layer of the multi-transport architecture so as to be transparent to higher layers. [0011] The foregoing summary includes example embodiments of the present invention that are not intended to be limiting. The above embodiments are used merely to explain selected aspects or steps of the present invention. However, it is readily apparent that one or more aspects, or steps, pertaining to an example embodiment can be combined with one or more aspects, or steps, of other embodiments to create new embodiments still within the scope of the present invention. Therefore, persons of ordinary skill in the art would appreciate that embodiments of the present invention may incorporate aspects from other embodiments, or may be implemented in combination with other embodiments.

DESCRIPTION OF DRAWINGS

[0012] The present invention will be further understood from the following detailed description of various example implementations, taken in conjunction with appended drawings, in which:

[0013] FIG. IA discloses an example intra-device Network on Terminal

Architecture (NoTA) in accordance with at least one example embodiment of the present invention.

[0014] FIG. IB discloses a structural diagram of various example layers of an inter-device Network on Terminal Architecture (NoTA) including a Whiteboard-type exchange service in accordance with at least one example embodiment of the present invention.

[0015] FIG. 2 discloses an example need for underlying connectivity establishment in accordance with at least one example embodiment of the present invention.

[0016] FIG. 3 A discloses a structural example of communication establishment in accordance with at least one example embodiment of the present invention.

[0017] FIG. 3B discloses an example of establishing access to a target service residing in another device in accordance with at least one example embodiment of the present invention. [0018] FIG. 4 discloses an example of various software levels and interfaces through which information may be conveyed in accordance with at least one example embodiment of the present invention.

[0019] FIG. 5 discloses an example configuration for the lower level communication structure in accordance with at least one example embodiment of the present invention.

[0020] FIG. 6 discloses an example of connection establishment in accordance with at least one example embodiment of the present invention.

[0021] FIG. 7 discloses an example of multi-subsystem inter-device connection establishment in accordance with at least one example embodiment of the present invention.

[0022] FIG. 8 A discloses a flowchart of an example communication establishment process in accordance with at least one example embodiment of the present invention.

[0023] FIG. 8B discloses a flowchart of a communication routing process example in accordance with at least one example embodiment of the present invention.

[0024] FIG. 9A discloses an example scenario wherein more than one consuming node requests the same data being provided by the same node in accordance with at least one embodiment of the present invention.

[0025] FIG. 9B discloses a unicast mode operation example in accordance with at least one embodiment of the present invention.

[0026] FIG. 9C discloses a multicast mode operation example in accordance with at least one embodiment of the present invention.

[0027] FIG. 10 discloses examples of group format messaging in accordance with at least one embodiment of the present invention.

[0028] FIG. 11 discloses a combined unicast and multicast mode operation in accordance with at least one embodiment of the present invention.

[0029] FIG. 12 discloses a flowchart of a control process example in accordance with at least one embodiment of the present invention. DESCRIPTION OF EXAMPLE EMBODIMENTS

[0030] While the present invention has been described below in terms of multiple example configurations, various changes can be made therein without departing from the spirit and scope of the invention, as described in the appended claims.

I. Network on Terminal Architecture (NoTA)

[0031] Network on Terminal Architecture (NoTA) is a service based interconnect-centric platform architecture usable in various electronic apparatuses including wired and/or wireless (e.g., mobile) devices. The interconnect-centric approach incorporated in NoTA may allow any physical sub-system to directly communicate with other sub-systems while supporting multiple parallel connections. Direct connections are possible due to simple switches optimized for the underlying physical media. NoTA interconnect architecture and related interfaces may be complexity and performance optimized for service and data communication, and may be designed in such a way that different communication media technologies can be utilized.

[0032] FIG. IA discloses an example of NoTA implemented in a single device

100. The NoTA platform architecture consists of subsystems 102 connected together via interconnects as shown, for example, at 104. It is also possible for subsystems to be directly coupled to other subsystems as shown at 102' in FIG. IA. A coupled configuration may exist in a scenario where subsystems frequently cooperate during operation. FIG. IA also discloses service nodes (SN) 106 and application nodes (AN) 108 (e.g., PN, RN and AG) that may be mapped into subsystems 102 and 102'. Subsystems in NoTA context may encompass all of the resources (e.g., computing, software, peripherals, etc.) required to implement the services and/or applications running in the corresponding subsystem.

[0033] Now referring to FIG. IB, a more detailed disclosure of NoTA as it may be applied to a multiple-device system, in accordance with at least one embodiment, is now disclosed. The general architecture may be explained in terms of three example operational levels: whiteboard 110, billboard 122 and connectivity map 140. Whiteboard 100 is an example of an application and service level that may comprise the highest level of operation in this architecture. At this level, operational groups 112 may be formed including whiteboards 114 and various application nodes 108. Application nodes 108 may correspond to application existing on a plurality of wireless communication devices, and may be utilized to exchange information between these applications, for example, by placing data into, and removing data from, whiteboard 114. For example, the various nodes may consist of proactive nodes (PN) 116 that may place information into whiteboard 114, reactive nodes (RN) 120 that may take information from whiteboard 114 and agent nodes (AG) 122 that may operate either in a PN or RN mode depending on the particular application. Information semantics interpreter (ISI) 118 may be utilized to link different whiteboards 114 together. Utilizing these constructs, whiteboard 114 may provide a standardized means for application interaction that overcomes many incompatibilities.

[0034] Billboard level 124 may facilitate interaction between services available on the one or more devices. Services 134 and clients 136 that may utilize these services may be organized in service domains 126. In at least one scenario, service domains 126 may correspond to a particular protocol, such as UPnP, BT SDP, Bonjour, etc. In each service domain 126, services 134 may be represented by service nodes (SN) 130, and likewise, application nodes (AN) 132 may be established to correspond to applications. Further, service domains 126 may interact utilizing service ontology interpreters (SOI) 128. SOI 128 may allow service domains 126 to interact with other service domains (e.g., 138), even if service domain 138 resides on another wirelessly-linked device (e.g., to provide access information to service domains 126).

[0035] Connectivity map 144 may define connectivity methods/possibilities and topology for different devices participating in sharing resources in order to support a top level, for example whiteboard 110, and also billboard-type services in billboard level 122. In at least one example embodiment of the present invention, devices 144 may be linked in directly connected groups 142. Examples of directly connected groups of devices (Dev) 142 may include devices connected via Bluetooth™ piconet, a WLAN network, a wUSB link, etc. Each directly connected group of devices 142 may further be linked by gateways (GW).

II. Underlying communication elements that may couple subsystems

[0036] While examples of inter-node interaction involving application and/or service nodes has been described, no detailed discussion regarding how the devices may be coupled via wired or wireless communication, or the management of this connection, has been offered. FIG. 2 discloses an example scenario wherein application and/or service nodes may reside on two different devices 200 and 202. Whiteboard sections 152A and 152B also reside on these devices, respectively, ideally providing a common memory space via which the nodes may interact. However, interaction with a common memory space in the form of whiteboard 152 may initially depend upon the establishment a wireless connection between whiteboard sections 152A and 152B.

[0037] While an example whiteboard 152 divided into two sections 152A and

152B has been utilized for the sake of explanation in the present disclosure, the facilitation of node interaction is not specifically limited to this scenario. For example, while proactive node (PN) 210 coupled to whiteboard section 152 A may utilize SN 212 and 214 to interact with whiteboard section 152B as shown in FIG. 2, it is further conceivable that whiteboard 152 A may allow PN 210 access to other shared memory spaces, such as service domain 126 (e.g., to allow an application to access a desired service, like a printer service), or any other example subsystem 102 as previously discussed in accordance with various embodiments of the present invention. Regardless of the node/device configuration, interaction between nodes may not be problematic on a single device in view of the locally interconnected subsystems However, this interaction may become more difficult with multiple devices linked, for example, over one or more wireless transports.

[0038] FIG. 3 A discloses an example of an underlying logical architecture that may be utilized in implementing NoTA in accordance with at least one example embodiment of the present invention. NoTA may be configured as multiple subsystems (e.g., 300 and 350) coupled by interconnect 312. As previously set forth, a communication link between devices that may be both established and managed by a lower operational level may facilitate the routing of messages for higher level subsystems, such as sections (152A and 152B) of the same shared memory space (whiteboard) 152, without the actual involvement of the higher levels in any communication configuration. NoTA interconnect 312 may comprise two layers: High Interconnect (H IN) layer 302 and Low Interconnect (L IN) layer 304 coupled to corresponding H IN 352 and L IN 354 by switch 310. The various communication layers may further interact over interfaces (abbreviated "IF" in FIG. 3). For example, H IF 380 may serve as the interface between the application level and H IN 302/352, while L_IF 382 may serve as the interface between H_IN 302/352 and L_IN 304/354. Low interconnect layer 304 may include ISO/OSI layers Ll - L4 and may provide transport socket type interface upwards. High Interconnect layer 302 may act as the middleware between L_IN 304 and the higher level Application nodes 306 (AN) and Service nodes (SN) 308 residing in subsystems like 300 and 350. Key H_IN 302 functionality may include providing client nodes (AN 306 or SN 308) a direct access to services without having to disclose the location of the latter (e.g., transparent at the top level). All communication establishment may be connection-oriented, meaning that before any service or data communication may take place, connection setup procedures must first be carried out. Security features have been added to countermeasure identified threats. NoTA is an architecture that may be used to provide inter-device service access, making it possible to build independent subsystems providing both services and applications. In an example implementation there may be several individual NoTA devices involved in direct inter sub-system communication.

[0039] Utilizing the previously described architecture, an example of establishing access to a service on another device via a wireless link, in accordance with at least one example embodiment of the present invention, is disclosed in FIG. 3B. A node in the application/service level of subsystem 300 in device 200 desires to access a service. The service may be identified, for example, by a service description (SID). This service description may be used to locate and establish access to the desired service. In the H IN level, the SID may be mapped to an Interconnect Address (IA) that may further identify the subsystem in which the service resides. In this example, the desired service resides in subsystem 350 in target device 202. In order to make an H IN level connection with the subsystem offering this service, a transport must be selected that is suitable for making a connection between the devices. The IA may then be mapped to the selected transport in L IN 304. In the example of FIG. 3B, a wireless link must be established because the devices are not coupled by a wired connection. This wireless link is established over interconnect 312 via the wireless transport. Once devices 200 and 202 are wirelessly coupled, H IN level connection between subsystem 300 and 350 may be possible. In H IN level 352 a corresponding H IN protocol is usable to negotiate service usage. The (SID -MA) and (IA-^ transport) mapping is used only in subsystem 300 in order to build a connection with a proper subsystem offering the needed service (e.g., subsystem 350). As a result, upper level (e.g., application/service level) access may be established from a requesting node in device 200 to a service that is able to fulfill the request, even though the service resides in device 202. This access may be facilitated by lower level link establishment via one or more transports.

III. Example connection management structures

[0040] The present invention, in accordance with at least one embodiment, may be described in terms of the functionality of various architecture components and component relations. FIG. 4 describes the interaction of the various communication levels and examples of functions that may be performed by each level and its corresponding interface in accordance with at least one example embodiment of the present invention. For example, 400 discloses an example service node (SN) that may facilitate the set-up and establishment of connections supporting various application nodes (AN) such as 108 shown in FIG. IA. The interface between the top application level and the H IN level 404 may provide service access, registration and communication stream access via H IF interface level 402. In accordance with at least one example embodiment of the present invention, services may be identified by a Service Identification (SID). H IN level 404 may then obtain device-to-device access and communication interface access to L INup level 408 via L IF interface level 406. The H IN level access may be identified by an Interconnect Address (IA) which separates different devices/ subsystems in high level middleware layer. A general connectivity control interface L IFdown level 410 may then provide access from transport- independent L INup level 408 to L IN down 412 including transport specific L IN adaptors as disclosed at 414. In various embodiments of the present invention, there may be a specific L IN adaptor 414 for each communication medium (e.g., transport 418), each being linked by transport specific control interfaces 416. Wired and/or wireless transports 418 supported, for example in a mobile device, may then utilize the physical hardware and/or corresponding software in device PHY layer 420 to communicate. Overall, the service level may utilize an SID to identify different services, H IN level middleware layer may then map this SID into a certain IA, which corresponds to an address of a device/subsystem where the respective service may be accessed in the high level middleware layer. L INup level 408 may then map this IA to one or more physical connections (e.g., transports) that may offer connectivity to the device/subsystem that corresponds to the IA. L INdown level 410 may then establish physical connections with the specific transport.

[0041] FIG. 5 depicts an example low interconnect architecture (L IN) 304, in accordance with at least one example embodiment of the present invention. L IN 304 may provide service upwards to H IN 302 via L IF interface 382, and may comprise a unified L INup communication structure 408 and one or more L INdown communication structures 412. L_INdown 412 may further include at least one L_INdown adaptor 414 corresponding to each transport 418 that may be utilized in a device. As a result, L INup 408 may be transport independent (e.g., L INup operation does not change in dependence upon the transport in use), while L INdown adaptors 414 in L INdown 412 may be specifically configured for use with each transport 418. Each L INdown adaptor 414 may provide service to L INup 408 through one or more L IFdown interface 410. L IFdown interfaces 410 may be configured similarly for each transport 418 except in the addressing and access mechanism.

[0042] L INup 408 may perform multiple functions in embodiments of the present invention. For example, activation and deactivation may be controlled in this layer of the communication structure. The L IN activation process is controlled over the L IF 382. During the activation process, the L IN 304 may be configured to be able to use wireless and/or wired transports as L_IN transports. As a result of successful activation, L IN 304 may then be able to resolve an Interconnect Address (IA) as well as IAs for the existing Resource Managers (IArm). L_INup 408 may use the query services provided to L INdown 412 during this activation.

[0043] When active, L_IN 304 may be able to detect loss of a L IN network connection. As a result, any earlier allocated IA and IArms may be released in order to, for example, automatically reconnect the network connection using the same or a different transport. The deactivation process is also controlled over L IF 382. In the deactivation process, L IN 304 is deactivated in respect of all available transports. During this process, the IA is released.

[0044] The L IN connection creation process may establish a L IN-level connection between different devices such as shown in FIG. 6. This connection may utilize different types of transport technologies in-between the end-points. In general, the choice of transport may be transparent at the application level, since interfaces with which the nodes may interact may be transport-independent. However, there may be instances where applications and services (e.g., represented in the NoTA architecture by AN 306 and SN 308) may have requirements, or desired characteristics, regarding the connectivity that L IN layer 304 may provide. L IF interface 382 may therefore be equipped with a mechanism to enable a quality of service (QoS) parameter setup to monitor each connection. At this level, the quality of service parameters may not be bound to an actual transport since the transport technology used to carry out data would not be selected at this level. Rather, the QoS requirements may be mapped to an L IN communication instantiation, or "socket," that are abstractions of the actual connection that upper protocols may use. The connectivity requirements may be achieved using, for example, buffer state-based transport selection and flow control. The interface does not have to address transport specific parameters. Instead the requirements, or wishes, may be described in more universal manner.

[0045] In order for L IN to carry out its function, a set of basic L INup-L INup connection protocols may be defined. All of these may be utilized by the L INup communication structure 408, hence making the implementation of the L INdown adapter 412 simple (e.g., because no generic L INdown - L INdown peer protocols are required). The following L INup protocols may be defined for facilitating communication between L IN communication structures existing in two separate devices (e.g., devices 200 and 202 as shown in FIG. 6):

[0046] A protocol that may provide a means to allocate and identify unique interconnect addresses for each device may be called an Interconnect Address Resolution Protocol (IARP) in accordance with at least one example embodiment of the present invention.

[0047] A protocol that may provide a means to establish data connection establishment and disconnection between sockets may be called the Device Access Protocol (DAP) in accordance with at least one example embodiment of the present invention.

[0048] A protocol that may provide a means to exchange connectivity map-type information between devices. This information (e.g., regarding connectivity in the device environment) may further be utilized to select optimal connectivity method when distributing information across the devices. This protocol may be called the Connectivity Environment Protocol (CEP) in accordance with at least one example embodiment of the present invention.

[0049] IARP may be specified to provide inter-device NoTA architecture

Interconnect Address (IA) resolution within a network of devices, in an ad-hoc communication connection, etc. IARP may contain four messages in order to retrieve and release a unique IA. In the example of FIG. 6, the IA resolution process may handle IA address allocation between devices as a connection is established. Address resolution may utilize IARP as a resource for supporting connection establishment. Address resolution may be centralized or distributed/autonomous requiring zero manual configuration. The data delivery process may manage data flow control between the sending device and the receiving device. L IF ring-buffer based sockets may be used in this process. The data delivery process may further implement connection loss detection and recovery process in order to provide more reliable data delivery using inter-transport switching.

[0050] DAP may provide connectivity initialization, creation, and disconnection.

L IN layer internal interface, L IFdown 410, may provide uniform way for DAP to access individual transports. Each transport needs an adaptor 412 which implements L IFdown interface 410. FIG. 6 shows how the architecture scales from a transport independent intra-device domain (e.g., L INup 408) to transport independent inter-device domain (e.g. L INdown 412). For example, the depicted communication layers may be coupled data sockets 600 that may directly couple H IN 302 and L INdown 412 via transport-independent L INup communication structure 408.

[0051] Inter-transport switch triggering decisions may be controlled in view of condition information obtained by monitoring the transmit (TX) and receive (RX) buffer fill levels. All data conveyance may be considered "Best Effort" (BE) type. Introduction of some simple QoS classes (e.g. BE, low-latency delivery, minimized power consumption, etc.) may then be possible while still keeping the overall implementation complexity of NoTA manageable. The connection loss and recovery process is a supplemental action in L IN communication structure 304 that can be utilized for restoration and reconnection procedures that could not otherwise be handled in as part of the inherent abilities of resources operating at the transport level. [0052] Part of the connection setup, data delivery, and connectivity recovery solutions may include sharing and distributing information about the connectivity in the surrounding environment by means of the CEP protocol. This method may retrieve information about the available connectivity technologies used by other surrounding devices and enables smart decision making procedures when choosing optimal transport to access devices and services. In FIG. 6, control sockets 602 for enabling L_INup-to- L INup protocol communication are shown interacting with the IARP, DAP and CEP protocols in furthering inter-device communication.

[0053] The L INdown communication structure 412 may provide other communication-related functionality. For example, a query operation may be an L INdown internal function that is intended to provide information concerning transport specific connection opportunities. This functionality may be tightly coupled with scene and connectivity maps by which information regarding the overall space/proximity/neighborhood connectivity may be obtained. The query function is mainly employed during the establishment of a connection.

[0054] A data delivery process may handle data flow control between the same transport peer entities (e.g., between L IN up communication structures such as shown in FIG. 6). The same ring buffers may be used as in the previously described case with respect to L IF. A transport specific connection loss and recovery process may also be implemented in L INdown 412. The implementation may substantially depend on the applied transport technology.

[0055] FIG. 7 discloses an implementation example in an example scenario, wherein each device may include multiple internally coupled subsystems that are then wirelessly coupled in accordance with at least one embodiment of the present invention. In the disclosed example, one or more transport technologies may be utilized alone or in combination as shown at 704. These transport technologies may, in many cases, be implemented without any visibility being required to the application level since the interfaces by which the application level may access these communication services do not change based on the transport utilized.

[0056] A transport independent connection may be formed between the L INup layers in each device using, for example, the aforementioned connection protocols is shown at 702. This transport-independent link between devices may provide stabile and unchanging communication link that perpetuates the exchange of service and data communication between the devices as shown at 700. As a result of this communication interface architecture, flexible connection strategies may be employed to wirelessly couple the devices that may vary depending on the situation. For example, concurrent use of multiple transports may create a faster communication rate. Further, if a transport were to fail or become interrupted, then the original socket may be discontinued and replaced with a socket in the same transport or an alternate transport without risking disruption of higher-level NoTA operation (e.g., in the application or service node level).

[0057] FIG. 8A discloses a flowchart for an example process in accordance with at least one example embodiment of the present invention. The process may start at step 800 with L IN activation. After activation, the L IN can be used to exchange L IN user (e.g. H_IN) messages wirelessly (and/or by wired means). After the L_INup has received Lactivate req over the L IF in step 802, the L INup is ready to perform needed operation to build up wireless L IN-LIN connection. For this purpose LdOpen req may create a control socket for L INup control purposes.

[0058] In this specific example it is assumed that L INup does not have knowledge where to connect so first operation is a query. With an LdScene req message, L INup may ask L INdown to provide information of some devices using one selected technology in step 804. Using various parameters, L INup can instruct L INdown to search for devices which have specific characteristics such as only Resource Manager (RM) devices, all NoTA devices or any device capable of performing the required transaction (e.g., via a specific transport). These instructions may be interpreted in step 806, and according to this message L INdown perform transport specific query operation and returns device information that matches to the parameters given in LdScene req. If no specific characteristics are specified, then in step 808 all discovered devices may be returned. If certain parameters were specified, then in step 810 only devices that match the characteristics of the target specification may be returned. It should be noted that in here a first device (e.g., a service device) may be put in active mode with query parameters, where a second device may be put in a "listening" mode with scan parameter. This means that the second device may not be actively searching for any devices but is available for connection creation. Regardless of the query information that is returned, this information may be reviewed in step 812 to determine an appropriate target device from all of the available devices that were discovered.

[0059] In the L IN connection creation process, L INup may use information returned by the LdScene cnf (or alternatively information that might already exist on the device) to create connection with at least one other device. In this example, a connection may be created with a NoTA device having RM. An LdConnect req message from L INup may instruct L INdown to create connection with a target device in step 814. L INdown may then attempt to create a connection with the desired device in step 816. If for some reason the connection is not accepted in step 818, then in step 820 the L INdown socket created earlier in the process is removed and the selection of an alternative connection method (e.g., using another transport) or an alternative target device may occur. The connection request process may then repeat starting in step 814 until the connection is accepted by another device in step 816. After the connection is created the second device may receive an LdConnect ind message which may be implicitly accepted. After successful socket (connection) creation, L INup-L INup connection may be utilized.

[0060] IA resolution may further be completed in step 822, which may be performed on the L INup-L INup level. An L INup peer protocol message may be sent out by a device which needs an IA for the inter-device operation. Another device may then return an IA in response to this request. After IA resolution completes, a confirmation activation cnf may be sent (L IF). The communication may continue until the connection is lost or the communication is complete. Step 824 deals with the loss of the connection. A connection loss indication may be used to indicate to the situation to L INup for the lost connection or device in the case it can not be managed by L INdown. After receiving this notification, L INup can decide what is the operation needed to recover/rebuild the connection. The recovery process may include returning from step 824 where connection is lost to step 818 to remove the existing L INdown socket and replace the method of connection or the target device as previously described with respect to step 818.

[0061] When the connection is determined to be complete in step 826, a disconnection procedure may be executed in step 828. In the disconnection procedure, a connection formed using a specific transport or certain coupled device may be disconnected. In a normal procedure all the connections may first be removed before disconnecting whole device (e.g., all of the sockets are removed first before disconnecting the device in total). After all coupled devices have been disconnected the L IN deactivation can be performed. The process may then return to initial step 800 to await the next communication activity requiring connection establishment.

[0062] Referring to FIG. 8B, a flowchart disclosing a communication routing example in accordance with at least one example embodiment of the present invention is now disclosed. In step 850, an application or service (e.g., represented by a node at the application/service level) may request service access. A requested service may be identified, for example, through the use of a service identifier (SID). A search may occur in step 852 utilizing the requested service SID.

[0063] The search may be executed using, for example, a service like billboard

124 as previously discussed with respect to FIG. IB. Another possibility is that the service search is done prior to the access request, which means that a service list (including services available on other devices) may already be available when service is accessed. If the service is not located in step 854, then a determination may be as to whether the search has been completed in step 856. If the search is complete, the conclusion that the requested service is not currently available made by made in step 858, at which point the search may terminate and return to step 850 to await the next service request. The termination of the search may be based on limiting factors such as end of list, timeout, number of attempts, etc. If the requested service is located in a subsystem, then the process may proceed to step 860 where connection establishment may begin.

[0064] In step 860, the H IN level may map the SID to an interconnect address

(IA). The IA may indicated both the subsystem in which the requested service resides and the device where the subsystem may be found. The L IN level may then map the IA to a particular transport in step 862. For example, if the devices are coupled by a wired local area network (LAN), then a suitable transport may be Ethernet. However, if the devices are not connected via wires, then a wireless transport may be more suitable. Transports may further be selected based on speed, error correction, transmit range, power consumption, etc. The process may continue to search for a suitable transport in steps 862 -864 until a suitable (and available) transport is determined. [0065] In accordance with at least one example embodiment of the present invention, the selection of a transport may include a prioritization of the transports based on their characteristics, for example, by comparing the transport characteristics to the needs of the application and/or service initiating the access request. Based on this comparison, the transports may be ordered accordingly, and the most preferred transport may be selected as shown in steps 862-864. In an instance where the most preferred transport cannot be used, the next preferred transport in the order may be selected and subjected to the transport selection. This process may be repeated until a suitable and available transport is found. Further, according to at least one example embodiment, the general state of the device, including e.g., battery power level and other operational characteristics may also be considered in the prioritization of the transports.

[0066] In step 866 the L INdown level may establish a low-level connection to the device on which the desired subsystem/service resides. This low-level link may be made to the corresponding L INdown of the other device. After the initial connection is established, the L-INup level in each device may form a mid-level connection (e.g., also called middleware) in step 868. Step 868 has been shown as optional in FIG. 8B, as it may only be implemented when applicable or needed. This mid-level connection may be used to, for example, resolve the IA of the desired subsystem and exchange Channel map (CMAP) information. Following completion of L INup connection establishment (if required), an upper level (e.g., service level) link may be established in step 870, and this upper level connection may in turn be used to grant access to the requested service in step 872. The process may then return to step 850 to await the next request.

IV. Unicast and multicast mode operation examples

[0067] It is foreseeable that in operating systems, such as the various example configurations described above, that problematic communication scenarios may occur. At least one example scenario that can possibly cause communication delays and or failures is depicted in FIG. 9A. Service node (SN) 900 resides in device 200. Device 200 further contains whiteboard section 152A that allows service node 900 to interact with other nodes also operating in whiteboard 152. SN 900 may, for example, be associated with a service that is "popular" or frequently accessed by other nodes. FIG. 9A further depicts three other devices 910, 920 and 930 containing nodes that desire to obtain information from (or consume information) from service node 900. In particular, an application node (AN) 912 in device 910 is requesting information from SN 900 via whiteboard section 152B. AN 922 in device 920 is requesting the same information from SN 900 via WB section 152C, and AN 932 is also requests this information from SN 900 via whiteboard section 152D. These three requests are represented in FIG. 9A at 902, and the attempt of SN 900 to service these requests via whiteboard section 152A is represented at 904. It is important to note that while a specific operational scenario is set forth in FIG. 9A, the use of this particular example is for the sake of explanation only. The various embodiments of the present invention are not limited only to the disclosed interaction, and as a result, these embodiments may be applied in other scenarios, both simpler and more complex. For example, AN 912, 922 and 932 may also receive the same transmissions if all of the nodes are subscribed to a service (e.g., corresponding to SN 900) that is configured to provide updated information periodically, on change, etc. As a result, all consuming nodes should receive the same update messages from SN 900.

[0068] FIG. 9B discloses an example of SN 900 attempting to service multiple communication requests in a unicast mode of operation. Unicast operation is limited to the transmission of data from one point to another point. In unicast systems, even though a plurality of users might request the same data from the same source at the same time, duplicate data streams are transmitted individually, one to each consumer. In FIG. 9B, SN 900 must separately reply to each of the communication requests from AN 912, 922 and 932, creating a large amount of message traffic (shown, for example, at 950) to be conveyed through H IN 302 and L IN 304. Again, this phenomenon may occur because each request must be individually serviced by SN 900 and conveyed to consuming AN nodes 912, 922 and 932 via H_IN 302 and L_IN 304. The substantial number of communication messages being conveyed, for example, as shown in FIG. 9B may occupy resources in a device to the level where delays may began to manifest in one or more communication streams. These delays may cause applications relying upon the communications to slow down or freeze, and in the worst case, may cause failures in multiple device systems.

[0069] FIG. 9C demonstrates at least one benefit of multicast communication in accordance with various example embodiments of the present invention. Multicast mode operation allows for the transmission of data to multiple recipients at the same time using one transmission stream that may be received by each consumer (as shown, for example, at 960). Multicast operation may, in accordance with the depicted example, allow the communication layers comprising SN 900, H_IN 302 and L_IN 304 to transmit fewer messages while servicing the same number of consuming nodes. More specifically, the amount of messages that would need to be conveyed by H IN 302 and L IN 304 would be reduced substantially, reducing the overall traffic burden on communication resources in device 200.

V. Implementation Example

[0070] Various example embodiments of the present invention may be configured to allocate some or all of unicast/multicast determination control to lower communication layers in the NoTA. For example, in at least one example embodiment L IN layer 304 may make all of the decisions regarding whether messages can (or should) be sent via multicast communication. In this way, the method by which the message is transmitted to the consuming node may be transparent to intermediate (e.g., H IN 302) and upper (e.g., Application layer) layers in the architecture, which may make the overall architecture more simple, more flexible (e.g., program modules can be change in and out easier), etc.

[0071] In order for L IN layer 304 to make a determination regarding the use of unicast mode and/or multicast mode operation, control elements in L IN layer 304 must be aware that communication requests that are being conveyed may be grouped for multicast transmission. In various example embodiments of the present invention, H IN layer 302 may be tasked with reviewing communication requests in order to determine whether any of these request can be grouped. Grouping may occur, for example, if the same information is being requested from the same source. In a case where two or more communication requests are requesting the same information from the same source, the communication requests may be grouped together. It is important to note, however, that "grouping" is not a determination that the messages can (or should) be sent via multicast mode communication. This decision process is reserved for L IN 304. Instead, grouping may indicate to L IN 304 that the messages contained in each group may be sent via multicast communication. The control elements in L IN 304 must then determine if the grouped communication requests can be serviced via multicasting in view of various parameters. Example parameters may include communication transports supported by the devices on which consuming nodes resides (e.g., whether these communication transports support multicast mode operation, whether there are any communication transports in common between the devices, etc.), the amount of information to be conveyed, the current level of communication traffic, quality-of-service (QoS) requirements, etc.

[0072] Given a plurality of communication requests, an intermediate layer (e.g.,

H IN 302) may group the communication requests by forming a groups of two or more communication requests corresponding to the information being requested and the source of the information being requested. The plurality of communication requests may then be passed to L IN 304 for processing (e.g., multicast determination) and transmission. The communication messages that have been grouped may be passed in group format. Two examples of group format usable in accordance with at least one example embodiment of the present invention, are disclosed in FIG. 10. The first example, shown in FIG. 10 at 1000, uses a send command (e.g., Lsend) including multiple parameters. The multiple parameters may pertain to, for example, communication requests that are members of a particular group. When received in L IN level 304 receives and interprets the Lsend command shown at 1000, it may recognize that when this command is passed with multiple parameters that these parameters each identify a communication request that is requesting the same information from the same source, and therefore, may further determine whether any or all of these communication requests can be serviced using multicast mode operation. Any of the communication requests that cannot be serviced using a multicast mode may then be serviced using unicast mode operation.

[0073] Another example of a group format is shown in FIG. 10 at 1002. In this example the multiple parameters corresponding to, for example, communication requests in a particular group are replaced by a single parameter assigned to represent a group of communication requests. When L IN 304 receives and interprets the command message shown at 1002, the parameter may be understood by L IN 304 to represent a group of communication requests. In at least one example scenario, the assigned parameter may not identify a group of message request, but instead may identify a group of consuming nodes that are already established as able to participate in multicast mode operation. In accordance with various embodiments of the present invention, the "LsockMulticastID" parameter may be associated with identification information (LsocklDs) corresponding to a plurality of actual communication requests that were established as a multicast group, for example, during previous interaction between H IN 302 and L IN 304. [0074] L IN 304, in determining whether the plurality of communication requests can (or should) be serviced using unicast and/or multicast mode communication, may further determine that some grouped communication requests will be communicated via unicast communication. For instance, consuming nodes (e.g., application nodes) that correspond to communication requests in a group of communication requests may actually be located on different devices. The different devices may be linked using various wired or wireless communication transports in order to facilitate the servicing of communication requests via whiteboard 152. As a result, some consuming nodes may only be accessible via communication transports that are not common to all the devices, and therefore, may require their communication requests to be serviced separate from the rest of the group.

[0075] FIG. 11 discloses an example of unicast and multicast mode operation being employed in conjunction. In the example of FIG. 11, at least one communication request corresponds to a node that can only communicate over a communication transport indicated in the figure at 1100. The other communication requests can be serviced using at least one common transport as shown at 1102. Further, in the example disclosed in FIG. 11 the communication transport in common between two or more nodes at 1102 is not the same communication transport as 1100. As a result, the communication requests that share at least one common communication transport may be serviced using multicast mode operation 960, while the remaining communication request may be fulfilled using unicast mode operation 950. In this way, all communication requests may be serviced.

[0076] A flowchart disclosing an example process in accordance with at least one embodiment of the present invention is shown in FIG. 12. A plurality of communication requests may be received by an intermediate layer of a multi-transport architecture in step 1200. The plurality of communication requests may be the result of, for example, consuming nodes in the multi-transport architecture subscribing to one or more services. The plurality of communication requests may be reviewed and grouped if appropriate in step 1202. Communication requests may be grouped, for example, if they are requesting the same information being provided by the same source (e.g., the same service). One or more groups of communication requests may be created in step 1202, wherein each group corresponds to particular information that was requested from a particular source. The plurality of communication requests, including both grouped and non-grouped requests, may be then be passed to a lower layer of the multi-transport communication architecture.

[0077] In accordance with at least one embodiment of the present invention, the grouped communication requests may be passed in group format, examples of which were discussed previously. The lower layer of the multi-transport architecture may interpret received send commands and/or send command parameters received in group format as groups of communication requests that may eligible for communication via multicast mode operation. If in step 1204 a determination is made that no grouped communication requests were received, then in step 1206 all communication requests may be sent via unicast mode operation. Upon completion the process may return to step 1200 to await receipt of new communication requests (step 1208). Otherwise the process may continue in step 1202 until all of the pending communication requests are serviced.

[0078] However, if grouped communication requests were received, then in step

1210 a determination may be made (e.g., in the lower layer) as to whether all of the grouped communication requests may be serviced via multicast operation. This determination may be based on various parameters, for example, communication transports supported by the devices on which consuming nodes resides, the amount of information to be conveyed, the current level of communication traffic, quality-of-service (QoS) requirements, etc. If in step 1210 it is determined that all communication requests in a particular group can be serviced by multicast mode operation, then the entire group of communication requests may be serviced using a multicast operation mode in step 1212. Similar to process step 1208, upon completion the process may return to step 1200 to await receipt of new communication requests (step 1214). Otherwise the process may continue in step 1202 until all of the pending communication requests are serviced.

[0079] However, if it is determined that one or more communication requests in a particular group cannot be serviced via multicast operation in step 1210, then in step 1216 each communication request in the particular group may be reviewed to determine whether the request can be serviced via multicasting. For example, transports supported by a device on which a consuming node corresponding to a particular communication request resides may be compared to the transports supported by other devices with nodes requesting the same information. If these devices share at least one transport in common, then the requested information may be delivered via multicasting. In general, any communication request that can be serviced via multicast mode operation should be serviced via multicast transmission in step 1218, since multicast mode operation helps to conserve communication resources. In step 1220, any remaining communication requests not serviceable via multicast mode operation may be serviced via unicast mode operation.

[0080] Various scenarios exist wherein only some communication requests in a group may be serviced using multicast mode operation. For instance, a particular node may request the same information being provided by the same source as the other nodes in a particular group, but the particular node may only accessible via a communication transport unusable by the other nodes. After step 1220 the process may return to step 1200 to await receipt of new communication requests (step 1214). Otherwise the process may continue in step 1202 until all of the pending communication requests are serviced.

[0081] Accordingly, it will be apparent to persons skilled in the relevant art that various changes in forma and detail can be made therein without departing from the spirit and scope of the invention. The breadth and scope of the present invention should not be limited by any of the above-described example embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

WHAT IS CLAIMED:

1. A method, comprising: receiving a plurality of communication requests in an intermediate layer of a multi-transport architecture; determining, in the intermediate layer of the multi-transport architecture, if any of the plurality of communication requests can be grouped together; if any of the plurality of communication requests can be grouped together, passing the communication requests that can be grouped together to a lower layer of the multi-transport architecture in group format; determining, in the lower layer of the multi-transport architecture, if any communication requests received in group format are serviceable via multicasting; transmitting the communication requests determined to be serviceable via multicasting via multicast mode transmission; and transmitting communication requests in the plurality of communication requests not transmitted via multicast mode transmission via unicast mode transmission.

2. The method of claim 1, wherein determining, in the intermediate layer of the multi-transport architecture, if any of the plurality of communication requests can be grouped together includes determining if any of the plurality of communication requests are requesting the same information from the same source.

3. The method of claim 1, wherein determining, in the intermediate layer of the multi-transport architecture, if any of the plurality of communication requests can be grouped together includes determining if a source is transmitting the same information to service more than one of the plurality of communication requests.

4. The method of claim 1, wherein passing the communication requests that can be grouped together comprises passing the plurality of communication requests to the lower layer based on one or more groups organized in view of information being provided and the source of the common information being provided.

5. The method of claim 1, wherein group format comprises a send command including a plurality of communication requests as command parameters.

6. The method of claim 1, wherein group format comprises a send command including a parameter assigned to indicate a group of communication requests.

7. The method of claim 1, wherein determining if any communication requests received in group format are serviceable via multicasting comprises evaluating one or more parameters including communication transports supported by devices on which consuming nodes resides, the amount of information to be conveyed, the current level of communication traffic and quality-of-service (QoS) requirements.

8. The method of claim 1, wherein multicast mode and unicast mode transmission of the plurality of communication requests are configured to operate concurrently.

9. A computer program product comprising computer executable program code embodied in a computer readable medium, the computer executable program code comprising: computer executable program code configured to receive a plurality of communication requests in an intermediate layer of a multi-transport architecture; computer executable program code configured to determine, in the intermediate layer of the multi-transport architecture, if any of the plurality of communication requests can be grouped together; computer executable program code configured to, if any of the plurality of communication requests can be grouped together, pass the communication requests that can be grouped together to a lower layer of the multi-transport architecture in group format; computer executable program code configured to determine, in the lower layer of the multi-transport architecture, if any communication requests received in group format are serviceable via multicasting; computer executable program code configured to transmit the communication requests determined to be serviceable via multicasting via multicast mode transmission; and computer executable program code configured to transmit communication requests in the plurality of communication requests not transmitted via multicast mode transmission via unicast mode transmission.

10. The computer program product of claim 9, wherein determining, in the intermediate layer of the multi-transport architecture, if any of the plurality of communication requests can be grouped together includes determining if any of the plurality of communication requests are requesting the same information from the same source.

11. The computer program product of claim 9, wherein determining, in the intermediate layer of the multi-transport architecture, if any of the plurality of communication requests can be grouped together includes determining if a source is transmitting the same information to service more than one of the plurality of communication requests.

12. The computer program product of claim 9, wherein passing the communication requests that can be grouped together comprises passing the plurality of communication requests to the lower layer based on one or more groups organized in view of information being provided and the source of the common information being provided.

13. The computer program product of claim 9, wherein group format comprises a send command including a plurality of communication requests as command parameters.

14. The computer program product of claim 9, wherein group format comprises a send command including a parameter assigned to indicate a group of communication requests.

15. The computer program product of claim 9, wherein determining if any communication requests received in group format are serviceable via multicasting comprises evaluating one or more parameters including communication transports supported by devices on which consuming nodes resides, the amount of information to be conveyed, the current level of communication traffic and quality-of-service (QoS) requirements.

16. The computer program product of claim 9, wherein multicast mode and unicast mode transmission of the plurality of communication requests are configured to operate concurrently.

17. An apparatus, comprising: one or more communication modules; at least one memory configured to store at least part of a multi-transport architecture; and a processor, the processor being configured to: receive a plurality of communication requests in an intermediate layer of the multi-transport architecture; determine, in the intermediate layer of the multi-transport architecture, if any of the plurality of communication requests can be grouped together; if any of the plurality of communication requests can be grouped together, pass the communication requests that can be grouped together to a lower layer of the multi-transport architecture in group format; determine, in the lower layer of the multi-transport architecture, if any communication requests received in group format are serviceable via multicasting; transmit the communication requests determined to be serviceable via multicasting via multicast mode transmission; and transmit communication requests in the plurality of communication requests not transmitted via multicast mode transmission via unicast mode transmission.

18. The apparatus of claim 17, wherein determining, in the intermediate layer of the multi-transport architecture, if any of the plurality of communication requests can be grouped together includes determining if any of the plurality of communication requests are requesting the same information from the same source.

19. The apparatus of claim 17, wherein determining, in the intermediate layer of the multi-transport architecture, if any of the plurality of communication requests can be grouped together includes determining if a source is transmitting the same information to service more than one of the plurality of communication requests.

20. The apparatus of claim 17, wherein passing the communication requests that can be grouped together comprises passing the plurality of communication requests to the lower layer based on one or more groups organized in view of information being provided and the source of the common information being provided.

21. The apparatus of claim 17, wherein group format comprises a send command including a plurality of communication requests as command parameters.

22. The apparatus of claim 17, wherein group format comprises a send command including a parameter assigned to indicate a group of communication requests.

23. The apparatus of claim 17, wherein determining if any communication requests received in group format are serviceable via multicasting comprises evaluating one or more parameters including communication transports supported by devices on which consuming nodes resides, the amount of information to be conveyed, the current level of communication traffic and quality-of-service (QoS) requirements.

24. The apparatus of claim 17, wherein multicast mode and unicast mode transmission of the plurality of communication requests are configured to operate concurrently.

25. An apparatus, comprising: means for receiving a plurality of communication requests in an intermediate layer of a multi-transport architecture; means for determining, in the intermediate layer of the multi-transport architecture, if any of the plurality of communication requests can be grouped together; means for if any of the plurality of communication requests can be grouped together, passing the communication requests that can be grouped together to a lower layer of the multi-transport architecture in group format; means for determining, in the lower layer of the multi-transport architecture, if any communication requests received in group format are serviceable via multicasting; means for transmitting the communication requests determined to be serviceable via multicasting via multicast mode transmission; and means for transmitting communication requests in the plurality of communication requests not transmitted via multicast mode transmission via unicast mode transmission.

26. A communication architecture, comprising: an upper layer; an intermediate layer configured to receive a plurality of communication requests from the upper layer, and to determine if any of the plurality of communication requests can be grouped together, and if any of the plurality of communication requests can be grouped together, the intermediate layer is further configured to pass the communication requests that can be grouped together to the lower layer in group format; and a lower layer configured to determine if any communication requests received in group format are serviceable via multicasting, to transmit the communication requests determined to be serviceable via multicasting via multicast mode transmission and to transmit communication requests in the plurality of communication requests not transmitted via multicast mode transmission via unicast mode transmission.