RESPECTIVE CPE DEVICE

TECHNICAL FIELD

The invention relates to the field of communications devices, in particular to Internet servers and residential gateways arranged within a home network and adapted to operate via a broadband connection with a service provider network.

BACKGROUND OF THE INVENTION

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. 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 (RTPS, also abbreviated DDSI) Specification. RTPS specifies how DDS entities (Domains, Participants, Publishers, Subscribers, Readers, Writers, Topics, ...) are mapped to RTPS 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 vl.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 .

DDS was originally designed for using UDP (User Datagram Protocol) , with zero-configuration discovery of peers based on a UDP multicast protocol. This is based on standardized RTPS. DDS uses for its discovery protocol the UDP multicast protocol, hence limiting the communication to a Local Area Network (LAN) . When peers are not on the same LAN, there are a number of issues : Multicast discovery will not work, since there is lack of multicast support on a Wide Area Network (WAN) , e.g. the Internet, because disabled by Internet network operators .

NAT (Network address Resolution) and firewall issues make direct UDP communication impossible. Many

enterprises and organizations often filter UDP traffic completely in their firewalls. Typically by default, only outgoing TCP connections are allowed and the port range of the incoming TCP connections is strictly controlled .

The publication "A DDS Discovery Protocol based on Bloom Filters" by Javier Sanchez Monedero is a Master Thesis published by the University of Granada on September 14, 2009, which describes advantages and disadvantages of several discovery mechanisms for DDS.

SUMMARY OF THE INVENTION

To overcome these problems, a forwarder application is

introduced. The main characteristics of the forwarder can be summarized as follows:

• discovery information and application data is

forwarded between peers that reside in different LANs

• both TCP and UDP can be used as communication

mechanism : UDP to communicate with peers in the same LAN as the forwarder, TCP to communicate with peers in other networks .

· A federation model is possible: multiple forwarders may be involved in the communication between two peers .

Apart from the protocol aspects involved when using DDS over TCP, DDS over UDP, and realizing the forwarding functionality between these different interfaces, the problems to be addressed are:

How does a DDS device know if it needs or has

currently a connection with a forwarder ?

If a DDS device has no connection with a forwarder, how can it verify there is one forwarder available for its realm such it can setup a connection to it ? How can a forwarder residing in a LAN find out the IP address and port on which it is publically available? How to handle roaming scenarios when moving from LAN to WAN or vice versa?

To address the above question, on top of the forwarder, a location service and a specific logic in the DDS device and forwarder application are introduced to assure a smart usage of the forwarder application.

The presented mechanism allows DDS based applications to communicate across the LAN boundary. It involves a

forwarder application and a location service. Thanks to dedicated state machines implemented in the DDS forwarder and plain DDS apps, the DDS apps can communicate with all peer DDS apps within their domain regardless if these are residing in the LAN or WAN. The algorithms presented support roaming from LAN to WAN and vice versa. An

extension is defined supporting network topologies where double NAT is encountered, involving a "cloud forwarder".

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the invention are explained in more detail below by way of example with reference to schematic drawings, which show: Fig. 1 a schematic network setup showing a forwarder application in a Local Area Network being

reachable by an external host,

Fig. 2 a state diagram illustrating a method for

starting a forwarder application,

Fig. 3 a flow chart illustrating a method to setup a

connection between a DDS application and a forwarder application, and

Fig. 4 a schematic network setup including a forwarder application behind a double network address translation .

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the following description, a CPE device 1 adapted for connecting a peer 5 of a second Local Area Network (LAN) 7 with a peer 6 of a first LAN 8 is described, as shown in figure 1. The LAN 8 is for example a home network or an enterprise network. The LAN 7 and the LAN 8 constitute in particular each an independent DDS domain. 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 1 is for example a residential gateway, a router, a switch or a set-top box, and includes a

microprocessor, a non-volatile memory, in which an

operating system and applications are stored, and a

volatile memory for the operation of the CPE device. The operating system of the CPE device is for example a LINUX operating system and a CPE device-specific middleware, which represents a device execution environment. The device execution environment includes software components for providing for example a DSL modem function, gateway and switching functions, FXS functions, VoIP functionality and Wi-Fi operation.

The CPE device 1 communicates with other devices in

particular by using a DDS standard (Data Distribution

Service for Real-Time Systems) , wherein the devices establish a DDS network. The LAN 7 and the LAN 8 constitute in particular each an independent DDS domain. The overall architecture of a network where DDS devices 5, 5' , 6, 6' , acting as peers in different LANs 7, 8 and WAN 11 (Wide Area Network, Internet) , device (peer) 9, get

interconnected via a forwarder application, e.g. a

forwarder application 10 included in the CPE device 1, is depicted in figure 1. The LAN 7 includes a respective CPE device 4. The specific logic of the forwarder application

10, together with a location service 3 being located in the WAN 11, assure a smart usage of forwarder scenarios for a communication between the devices 5, 5' with devices 6, 6' utilizing DDS is elaborated below.

The peers P: 5, 5', 6, 6' include each a TCP (Transmission Control Protocol) client TCPc. The CPE devices 1, 4 include each a Network Address Translation (NAT) function and a Firewall (FW) function. The forwarder application 10 is included in the gateway 1 and acts as a TCP server TCPs . For a discovery in the LAN 8, e.g. UDP (User Datagram

Protocol) is used by the forwarder application 10. A connection 15 between the peer 5 and the peer 6 is TLS/TCP based, also a connection 16 between a peer 9 of the WAN 11 and the peer 6. Each CPE device 1, 4, which are e.g.

residential gateways, are connected via a broadband

connection, e.g. DSL or optical fiber, with a network service provider for Internet access, the network service provider being a part of the Internet.

Forwarder application behavior The first thing to be done when it is wanted to extend a DDS realm, as established e.g. within the LAN 8, to

function outside the LAN 8, is to start up the forwarder application 10. When using maximum one forwarder

application per realm, the forwarder application 10, will check at initialization that there is no other forwarder application yet within the LAN 8. To do so, the forwarder application 10 enables a DDS reader listening on a DDS forwarder topic, as described further below. When another local forwarder application was detected within a wait period -being configurable, e.g. 2 seconds- the forwarder application 10 comes into a disabled state, in the other case the forwarder application 10 actually will start up.

To be able to start up, the forwarder application 10 first needs to obtain some network information and makes a corresponding configuration. The forwarder application acts e.g. as a UPnP (Universal Plug and Play) client and

performs UPnP discovery to select an IGD (Internet Gateway Device) device using a Port Control Protocol (PCP) , included e.g. the residential gateway 1. From the selected IGD device, the external IP address is retrieved and a port map is configured to allow incoming traffic on the

external_IP : external_port to be forwarded to the

internal_IP : internal_port on which the forwarder

application is listening. The UPnP actions will realize the portmap and the related firewall configuration so that the forwarder application is reachable on the

external_IP : external_port .

Based on this information and configuration, the forwarder application 10 will publish a public locator 2, i.e.

including external IP address, external port, and/or protocol, on the DDS Forwarder topic, and also register this public locator 2 to the location service 3. The location service 3 will store the public locator 2 of the forwarder application 10, map it with the DDS realm the forwarder application 10 belongs to, and makes it available to other devices 6, 6' belonging to the same DDS realm. It has to be noted that all DDS communication between devices of the DDS realm and the location service 3 is protected by respective certificates and chain of trust. This core logic of the forwarder application 10 is applied at startup ,e.g. after a waiting period for detecting other local forwarders, when its public locator is updated, or when there is a change on the forwarder topic -e.g. an addition or removal or change.

To know when the public locator needs to be updated, the forwarder application periodically polls -which is

configurable, e.g. every 5 minutes- the IGD device GW to verify if the external IP address changed. Static portmaps are not applied, hence a portmap is periodically refreshed based on the portmap lease -which is configurable, e.g. after one hour.

A detailed state machine applicable at the forwarder application is represented in figure 2. When a forwarder application starts up, it resides in an initialization state INIT 20 and performs the actions:

Start timer FWD_WAIT_LOCAL_FWD, e.g. with a timer time=2 seconds.

· Enable reader for forwarder topic.

New state = WAIT_LOCAL 21.

When the DDS forwarder application is in the WAIT_LOCAL state 21, it looks for a local forwarder application on the forwarder topic. If already a local forwarder application is present, it performs the actions 22: Stop timer FWD_WAI _LOCAL_FWD

New state = DISABLED, 23

If no local forwarder application is present, then the forwarder application starts up, 24, to get a public locator, 25. If a public IP address is already available for the DDS forwarder application, 26, the public locator is set, 27. If not, a public locator is requested, 28:

^• Use UPnP discovery to select an IGD device

^• Get external IP address successful:

- If changed: delete existing portmap

- update public locator IP address

^• If public locator IP was updated

^• - Add_portmap: 29

^• - Set public locator: 30

If a portmap already exists for the public locator, then the portmap is reused and added to the public locator. If no portmap exists for the public locator, then a portmap is configured e.g. by using the first free port of the ports up to 7400 and added to the public locator, steps 31.

The public locator is published to the location device by using timers, steps 32:

^• A timer to poll the external IP address, updated e.g. every 5 minutes, and

^• a timer to refresh the portmap, having an updated

lease time = 1 hour.

If the forwarder application is in the state = DISABLED 23, but detects that no other local forwarder is available on the forwarder topic 33, the forwarder application starts up again, 24. If the forwarder starts up, 24, but detects another local forwarder on the forwarder topic, 34, then the forwarder goes into the state = DISABLED, 23. If no local forwarder is detected on the forwarder topic, 35, and a public IP address is already available for the DDS forwarder application, 26, then the public locator is set, 27, and forwarding:

· Publish the forwarder topic, and

• Register the public locator to the location service. Then, after the steps 27, the forwarder is enabled, 35.

Plain DDS application -aka forwarder client- behavior

When a DDS application of a DDS deviceincluding a TCP

(Transmission Control Protocol) client, e.g. a peer of the LAN 7, starts up, it needs to setup a connection to the forwarder application. To be able to do so, it needs the public locator 2 of the forwarder application 10, figure 1. Therefore, the DDS application will send a corresponding request to the location service 3 to get the forwarder public locator 2, and also enables a reader to listen on the DDS forwarder topic. Requests to the location service 3 to obtain the public locator 2 are sent periodically, e.g. every 30 seconds, as long as the connection with the forwarder application is not proven. When the public locator 2 is received via the location service 3 or via the forwarder topic, this is configured and applied accordingly by the DDS application. The reception of the public locator 2 via the DDS forwarder topic proves the connectivity with the forwarder application, hence the periodic requests to the location service are no longer needed. The removal of the DDS forwarder topic indicates that the DDS device lost connectivity with the forwarder application, and the DDS application again starts sending periodic requests to the location service to get the public locator of the forwarder application . A detailed state machine applicable at a plain DDS

application, e.g. peer 5 having the role of a forwarder client, is described below with regard to figure 3: When the DDS application starts up, it resides in an initialization state: INIT state 40, in which a timer is started, having e.g. a time-out of: LOC_SRV_ IMEOUT = 30 sec. The DDS application is then in a wait state: New state= WAIT 41, in which:

- A DDS reader is enabled for the forwarder topic.

A request is sent to the location service to get the forwarder public locator.

When the DDS application is in the WAIT state 41, to setup connectivity with a forwarder application , following events and actions can happen :

- A) When the timer LOC_SRV_TIMEOUT expires:

• Reset the timer LOC_SRV_TIMEOUT

• New state= WAIT 41

· A request is sent to the location service to get the forwarder public locator.

B) When data from the location service is received -in WAN (typically) or LAN-:

^• Configure and apply the forwarder public locator.

· New state= WAIT_READER 42, a wait state in which the

DDS application waits for data on the Forwarder topic.

C) When data on the Forwarder topic is received -proved connectivity with forwarder, occurs only in LAN- :

^• Configure and apply the forwarder public locator if not yet done.

• Stop timer LOC_SRV_TIMEOUT .

• New state= READY 43 When the DDS application is in the READY state 43 -proved connectivity with the forwarder application -, following events and actions can happen :

D) When data on the Forwarder topic is removed -lost connectivity with forwarder-:

• Reset timer LOC_SRV_ IMEOUT

• New state= WAIT 41

• Destroy forwarder public locator.

^• A request is sent to the location service to get the forwarder public locator.

When the DDS application is in the WAIT_READER state 42-in WAN (typically) or LAN-, following events and actions can happen :

- E) When the timer LOC_SRV_ IMEOUT expires :

• Reset timer LOC_SRV_ IMEOU .

• New state= WAIT 41

• Destroy forwarder public locator.

^• A request is sent to the location service to get the forwarder public locator.

F) When data on the Forwarder topic is received -proved connectivity with the forwarder application - :

• Stop timer LOC_SRV_TIMEOUT .

• New state= READY 43

Roaming scenarios

Roaming between LAN and WAN and vice versa is supported since the public locator -representing a secured TCP connection- is registered by the forwarder application to the location service, and published on the DDS forwarder topic. The DDS application at startup obtains this public locator, and thus has the means to use it. When the DDS application resides in the LAN 8, figure 1, it doesn't need the related connection to the forwarder public locator. However when the DDS application roams to the WAN 11, connectivity with the public locator 2 is essential. This connectivity transition is realized by the underlying DDS logic .

The opposite is also possible: when a DDS application starts up when residing in the WAN 11, e.g. on the peer 9, it will obtain the public locator 2 from the location service 3, and effectively needs it to setup connectivity to the forwarder application 10 over the WAN 11. When this DDS application roams towards the home LAN 8, where the forwarder application is hosted, this TCP connection to the public locator is no longer necessary since the DDS application and forwarder application can communicate via the UDP-based LAN. This connectivity transition is realized by the underlying DDS.

Summary topology 1 forwarder in realm: In this scenario :

There is one forwarder application at stake: the "home forwarder" residing in the Home LAN. (Fig 1)

the forwarder application obtains its public locator - e.g. using UPnP, NAT-PMP, or other mechanisms- - the forwarder application registers the public locator to the location service.

the forwarder public locator is effectively reachable by a DDS host outside the LAN where the forwarder

application resides.

- Every DDS host requests to the location service the

public locator of the forwarder and setup a connection to it .

The forwarder application acts a server accepting incoming connections being setup by DDS hosts acting as forwarder clients. Every external DDS host must setup a connection to the home forwarder.

Extension : forwarder is behind double NAT

When the home forwarder 10 is behind a double NAT 20, as depicted in figure 4, the public locator as obtained by the forwarder is not reachable from an external host 5. At or preferably before registration time the

reachability of the public locator is verified. When the public locator is not reachable from the external host 5, this is reported to the forwarder application 10. As a result this public locator is not registered in the location service 3, instead the forwarder application 10 requests to the location service 3 the public locator of a "cloud forwarder" application 50 -residing in the WAN 11 and reachable- and setup a connection to it.

Every DDS host requests to the location service 3 the public locator of the forwarder application 10-being the cloud forwarder- and setup a connection to it.

The home forwarder application 10, as well as the plain DDS hosts act as a TCP client TCPc, i.e. they setup a connection to the cloud forwarder application 50 which is acting as a TCP server TCPs .

Also other embodiments of the invention may be utilized by one skilled in the art without departing from the scope of the present invention. Instead of DDS, also any other data- centric publish-subscribe middleware can be used to provide a distributed real-time network. The invention resides therefore in the claims herein after appended.