Patent Application
20160269276
The invention relates to the field of communications devices, in particular to Internet servers and residential gateways being arranged within a home network and adapted to operate via a broadband connection with a service provider network.
Residential gateways are widely used to connect devices in a home of a customer to the Internet or to any other wide area network (WAN). Residential gateways use for example digital subscriber line (DSL) technology that enables a high data rate transmission over copper lines, or use optical fiber broadband transmission systems, e.g. fiber-to-the-home (FTTH) or fiber-to-the premises (FTTP).
Home networks have become part of everyday life for many customers. A home network consists of a range of heterogeneous devices, which means that the home network is made up of different kinds of devices. All these devices need to communicate with each other. For this interconnection, multiple solutions are available. The home network uses a mixture of solutions, such as wireless and wired network connections. Combining these devices creates a network that allows users to share information and control devices in the home. Examples of networked devices in the home are for example residential gateways, set-top boxes, TVs, personal computers, tablet PCs, smart phones, network-attached storage (NAS) devices, printers and game consoles.
DDS (Data Distribution Service for Real-Time Systems) is a standard governed by the Object Management Group (OMG). It describes a data-centric publish-subscribe middleware that can be used to build distributed real-time systems. Since its formal adoption as an OMG standard in the year 2004, it has become a popular technology being used in many different industries such as the airline/aviation industry, the automotive industry, the military, etc. Several commercial and open-source implementations of the DDS standard exist.
To allow different DDS implementations to interoperate, they must implement a second OMG standard, called the Real-Time Publish-Subscribe Wire Protocol—DDS Interoperability Wire Protocol Specification (RTPS, also abbreviated DDSI). RTPS specifies how DDS entities (Domains, Participants, Publishers, Subscribers, Readers, Writers, Topics, . . . ) are mapped to RIPS entities (domains, participants, endpoints and optionally topics), the format of the messages that are exchanged between the participants/endpoints, and also valid message sequences of message exchanges between participants/endpoints, as well as a mechanism for discovering other participants and endpoints within a RTPS domain. The latest version of DDS is currently the version v1.2 and the latest version of the Real-Time Publish-Subscribe Wire Protocol is the version v2.1, which are both published by the OMG on its Internet site under www.OMG.org.
A new network communication paradigm is designed building upon DDS, which uses a DDS forwarding functionality to interconnect DDS peers residing in a LAN (Local Area Network) with DDS peers residing outside the LAN, e.g. in another LAN or the WAN, e.g. Internet. In a large network topology, it is possible to have multiple forwarders, e.g. forwarding servers of the Internet, involved in a communication between two DDS peers.
The RTPS message is described in detail in the RTPS wire protocol specification: An RTPS domain contains a set of participants, each comprising local endpoints: readers and writers. The writers of participants communicate with readers within the domain by sending RTPS messages. All RTPS messages comprise a header followed by a variable number of submessages. Each submessage contains a submessage header and a submessage element. The RTPS protocol version 2.1 defines several kinds of submessages, which are categorized into two groups: entity submessages and interpreter submessages. Entity submessages are for example data, DATA_FRAG and HEARTBEAT messages and target an RTPS Entity. The interpreter submessages are: INFO_SOURCE, INFO_DESTINATION, INFO_REPLY, INFO_TIMESTAMP and PAD. Interpreter Submessages modify the RTPS Receiver state and provide context that helps to process subsequent Entity Submessages. The INFO_SOURCE and INFO_DESTINATION submessages are primarily used for relaying RTPS submessages.
Each RTPS entity includes a globally unique identifier (GUID), which uniquely identifies the entity within a DDS domain. The GUID includes a prefix: GUID prefix, which uniquely identifies a participant within the DDS domain, and an entity identifier: entityID, which uniquely identifies the entity within the participant. The header of an RTPS message identifies the RTPS message as belonging to the RTPS protocol and includes a field that indicates the vendor providing the implementation of the RTPS protocol and a field: GUIDprefix, which is used to reconstruct the GUID that appears within the submessages contained in the RTPS message, and includes the name of the participant sending the RTPS message.
This loop as shown in
The DDS message as described with regard to
It is noted that in
U.S. Pat. No. 7,558,210 discloses a system for detecting and correcting publish-subscribe looping in a messaging network, which requires a token, which uniquely identifies a node in this network, or which is universally unique in this network. The system maintains a list of Universally Unique Identifiers (UUID) as a metadata attached to each publish-subscribe message. As a node forwards a message to another node, it is required to append its own UUID to this list, or discard the message, if its UUID already is in the attached list.
The method for avoiding a loop when forwarding a message from a first participant of a first LAN to a participant of a second LAN via several forwarding servers of a wide area network (WAN) comprises the steps of: including each time an identifying address of the sending forwarding server in the message by the receiving forwarding server, and keeping each identifying address in the message. The forwarding servers are in particular Internet servers forwarding messages in accordance with a Data Distribution Service for Real-Time Systems (DDS) or in accordance with a Real-Time Publish-Subscribe Wire Protocol—DDS Interoperability Wire Protocol (RTPS). The identifying address is advantageously a GUIDPrefix of an RTPS message. The message is in particular a DDS message or a RTPS message.
In an aspect of the invention, the message includes a submessage, and each added identifying address is stored in the submessage.
In another aspect of the invention, the message is an RIPS message including an InfoSource submessage, and each added identifying address is stored in the InfoSource submessage. Advantageously, the entity from which the message was received is added in the InfoSource submessage: a first forwarder adds the GUIDPrefix of the sending participant, a second forwarder adds the GUIDPrefix of the first forwarder, and a third forwarder: the GUIDPrefix of the second forwarder. To detect a loop, the first forwarder inspects the InfoSource submessage, and when the InfoSource submessage already contains the GUIDPrefix of the first forwarder, then the first forwarder drops this message to prevent a loop.
A communications device utilizing the method is for example a customer premises equipment (CPE) device comprising a microprocessor, a non-volatile memory, in which an operating system is stored, and a volatile memory for the operation of the CPE device.
A system utilizing the method comprises a first participant of a first Local Area Network (LAN), a participant of a second LAN and several forwarding servers of a wide area network (WAN),
The main idea is thus to extend the RIPS InfoSource submessage. According to the standard RIPS, the InfoSource submessage provides information about the source from which subsequent Entity submessages originated. This submessage is primarily used for relaying RIPS submessages.
The important thing to notice is that only one source is contained within the standard InfoSource submessage. To address the loop detection mechanism when forwarding (relaying) RIPS messages, additional entities, identifying the intermediate forwarders, are added to the InfoSource submessage.
Preferred embodiments of the invention are explained in more detail below by way of example with reference to schematic drawings, which show:
In the following description, a method for avoiding a loop, a respective system and a respective communications device are described. The communications device is for example a customer premises equipment (CPE) device, e.g. an access gateway, adapted for connecting a home network with a service provider network via a broadband connection. For purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.
The CPE device includes for example a controller, e.g. a microprocessor, a non-volatile memory, in which an operating system is stored, a volatile memory for the operation of the CPE device, a wireless node for a wireless operation, and a broadband connection, e.g. an xDSL connection. The wireless node includes a complex software driver, a physical layer with data buffers, and an antenna. A CPE device of this kind is for example a residential gateway, which has a central position within a wireless local area network (WLAN).
The system includes DDS peers residing in a LAN (Local Area Network) with DDS peers residing outside the LAN. The system includes for example participants A and B and forwarders F1-F3, as depicted in
Loop detection is possible by making intermediates, i.e. the RTPS forwarders/relayers F1-F3, e.g. provided by Internet servers, to add in the InfoSource submessage the entity from which the message was received, advantageously the GUIDPrefix mentioned in the RTPS message received.
As can be seen in
Advantages of the invention: The presented mechanism allows RIPS forwarders to detect and prevent loops in a network topology.
Also other embodiments of the invention may be utilized by one skilled in the art without departing from the scope of the present invention. The invention resides therefore in the claims herein after appended.
| Number | Date | Country | Kind |
|---|---|---|---|
| 13290256.0 | Oct 2013 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2014/072300 | 10/17/2014 | WO | 00 |
