Gateway adapted for vod

Gateway adapted for VOD

The present invention concerns the field of internet access gateways, associated video service decoders and the methods for broadcasting video content by an operator through such a gateway to such a decoder.

In this document operator means the entity providing a service of access to a 5 communications network, typically the internet, coupled to a service of access to a multimedia content, in particular video.

This type of operator offers its service and to do this generally provides two items of equipment. A first item of equipment consists of an access gateway to the communications network. It is known to the general public by the English term “box”.

Technically it is generally a modem, for example of the ADSL (Asymmetric Digital Subscriber Line) type but may be based on other technologies, such as cable networks, optical fibre or other. This modem is coupled to a router that enables connecting several items of equipment thereto. The gateway therefore forms the link between a data communications network on the one hand and a local area network to which the user connects various items of equipment. These items of equipment may be personal computers, smartphones, game consoles, television sets, etc. These gateways enable the user to access an increasing number of services using the communications network. Among the most popular are access to IP (Internet Protocol) telephony and access to television channels broadcast.

Access to television channel broadcast services generally involves a second item of equipment called a decoder (set top box). This item of equipment is used to receive the digital streams that transport the television channels and to reconstitute, from these streams, the audio and video signals for display on a television set.

In addition to this basic television service, the offer of a video on demand (VOD) service is becoming widespread. This offer consists of a content catalogue available on the servers of the operator. This catalogue is accessible to the user on his television set via his decoder. The choice of a particular content causes a request to the servers, which then broadcast the content to the decoder for display on the television set. These operations may be performed using conventional IP network technologies.

However, since this service is charged, the operator generally wishes to have available a high level of control of the contents broadcasting and of the destination thereof. In particular, he wishes to avoid the broadcast content being able to be easily diverted onto a personal computer.

The invention aims to solve the above problems through the use of a virtual MAC address dedicated to VOD on the decoder. This address is then recognised by the gateway. The gateway implements a direct circuit directly directing the traffic related to this virtual address between the interface for accessing to the communications network and the physical port of the gateway to which the decoder is connected. Advantageously, the circuit is dynamically configured by interception of the DHCP request used to configure this virtual address.

The invention thus concerns a device for processing information intended to be used as a gateway between a local area communications network and a wide area communications network which comprises a plurality of physical ports for connecting equipment of the local area network, a physical port connected to the wide area communications network, a router for routing the data streams between these various ports, and a direct circuit management module for managing a layer-2 direct circuit between the physical port connected to the wide area communications network and one of the physical ports for connecting equipment of the local area network.

According to the invention, said information processing device is intended to receive the connection, on one of said physical ports, of equipment having a plurality of layer-2 virtual addresses, at least one of which is dedicated to a particular service.

It is furthermore characterised in that it comprises means for detecting a marker relating to a particular service with which a particular DHCP discovery request that said device receives from a connected item of equipment is provided, means for relaying said particular discovery request to a remote DHCP server of the wide area communications network, and means for configuring the direct circuit management module thanks to the layer-2 virtual address from which said particular DHCP recovery request is originated, such that said direct circuit management module directly relays the traffic going to or coming from said layer-2 virtual address of said connected equipment.

The present invention also concerns an item of equipment intended to be connected to an information processing device as has just been described and which further comprises a plurality of layer-2 virtual addresses and means for marking a particular DHCP discovery request relating to the configuration of one of these virtual addresses relating to a particular service offered by said equipment.

The present invention also concerns a method for configuring at least two layer2 virtual addresses of an item of equipment as has just been described connected to a port of an information processing device as has just been described, said device being connected by a physical port to a wide area communications network.

According to the invention, said method comprises the following steps:

- a step of sending a particular DHCP discovery request relating to the configuration of a first virtual address of said equipment, and/or

- a step of sending a conventional DHCP discovery request relating to the configuration of a second virtual address of said equipment; and

- when said device has recognised a particular request in a received DHCP discovery request:

- a step of relaying the first request to a remote DHCP server, and

- a step of configuring a layer-2 direct circuit thanks to the first layer 2 virtual address in said device between the physical port connected to the wide area communications network and the physical communication port to which said equipment is connected;

- a step of receiving by said device a DHCP offer response sent by the remote DHCP server, and

- relaying, via the previously configured direct circuit, this response to said equipment;

- a step of sending a configuration request by said equipment to the remote

DHCP server via said direct circuit, and

- a step of receiving a response sent by the remote DHCP server carrying a layer-3 configuration related to the first virtual address of said equipment; and

- when said device has not recognised a particular request in a received DHCP discovery request:

- a step of receiving a DHCP offer response sent by the DHCP server of said device;

- a step of sending a configuration request by said equipment to the DHCP server of said device;

- a step of receiving a response sent by the DHCP server of said device carrying a layer-3 configuration related to the second virtual address of said equipment.

The features of the invention mentioned above, as well as others, will emerge more clearly from a reading of the following description of an example embodiment, said description being given in relation to the accompanying drawings, among which:

Fig. 1 illustrates the architecture of an example embodiment of the invention.

Fig. 2 illustrates the exchanges of typical messages of an example embodiment of the invention.

The invention has been developed in the context of the offer of a video on demand service, but it may apply identically to any service. The adopted technical solution is not specific to the service.

Fig. 1 illustrates the architecture of an example embodiment of the invention. This figure shows us a gateway 1.1 for accessing a wide area communications network 1.16. This network is generally referred to as a WAN (Wide Area Network), in contradistinction to local area network, generally referred to as LAN (Local Area Network). The gateway, as its name indicates, is used as an interface between the two networks.

This gateway therefore has a physical port 1.15 connected to the WAN. This connection is typically a point-to-point connection using a technology from amongst

ADSL, cable and optical fibre technologies, for the most usual. Any network technology can be used here.

The gateway typically has a set of physical ports for accessing the LAN. The figure references a port 1.7 to which the decoder 1.10 is physically connected. It also illustratively references a port 1.8 to which another item of equipment 1.14, which may for example be a personal computer, is physically connected.

The network traffic is routed over its interfaces by a router (switch) 1.6. The function of such a router is widely known to persons skilled in the art and we shall not detail here its known functionalities based on a conventional layer-3, IP layer, routing based on routing tables. Such a router typically implements a layer-3 address translation functionality known by the term NAT (Network Address Translation). This mechanism allows making public on the WAN only the address of the WAN interface 1.15 of the gateway. Any request originating in an item of equipment of the LAN reaches the gateway and is processed by the NAT in order to replace the original IP address with that of the gateway before being relayed to the WAN. The response therefore reaches the gateway, which recognises the message and replaces the destination address with the address of the LAN equipment originating the request before relaying this response over the LAN. The processing module NAT is referenced 1.3 in the software stack 1.2 that manages the gateway.

This software stack 1.2 managing the gateway also typically hosts a DHCP (Dynamic Host Control Protocol) server 1.4 that allows dynamically configuring any equipment connected to the LAN without intervention by the user. The precise operating of the DHCP protocol can be found in the RFCs (Requests For Comment) numbers 1531, 1534, 2131 and 2132. We shall here simply accept that the protocol operateds as follows: an item of equipment (for example the decoder 1.10 in Fig. 1) that is connected to the LAN sends a layer-2 broadcast message with its layer-2 address, i. e. its MAC address. This message is called a “DHCP discover”; it aims to discover the existence of a DHCP server on the network. The or each DHCP server in the network then responds to the equipment by offering it an available layer-3 address,

i.e. an IP address. The equipment then broadcasts a configuration request to the DHCP server of its choice, which responds thereto with the requested connection parameters. These parameters typically comprise the definitive IP layer address of the equipment, a sub-network mask and the IP address of the gateway in order to join the WAN.

The decoder 1.10 has a physical port 1.9 directly connected to the gateway, to the port 1.7 of this gateway. Typically the decoder 1.10 has an MAC address and obtains its layer-3 configuration via the DHCP mechanism previously described. Alternatively, this configuration may be statically recorded in the decoder 1.10. When this decoder 1.10 communicates with the WAN using these conventional mechanisms, the traffic is seen from the WAN as emanating from the gateway 1.1 because of the NAT address translation mechanism performed by the gateway. This feature does not create any particular problem for a certain number of services used by the decoder, such as access to the internet or other.

On the other hand, for a service such as the VOD service, the operator requires more control and to “see” the decoder 1.10 directly at the network level, at least to ensure that the streams associated with the VOD are indeed consumed by the decoder and not diverted in the LAN.

In order to obtain this control of certain services, the operator will, with regard to the services that he wishes to control, manage the decoder as forming part of a network of the LAN type particular to the operator, referred to hereinafter as the LAN of the operator, under the direct control of the operator rather than like equipment of the LAN of the user. More exactly, the decoder 1.10 will be seen as equipment of the LAN of the operator only with regard to the service that the operator wishes to control, for example here the VOD service. With regard to the other services offered by the decoder 1.10, the decoder 1.10 will operate as a conventional item of equipment of the LAN of the user.

The adopted solution is based on the use of virtual layer-2 addresses, i. e. MAC addresses, in the decoder 1.10. A first virtual address 1.11 is dedicated to the service that it is wished to control in a particular manner, here the VOD service. This MAC virtual address will be configured at the layer-3, the IP layer, as an address of the LAN of the operator. For the other services, one or more other virtual addresses, the addresses 1.12 and 1.13 in the figure, are managed in a traditional manner and configured at the IP layer as interfaces of the LAN of the user.

The use of layer-2 virtual addresses is equivalent to using different logic interfaces, all using the same physical interface. Each logic interface has its own layer-2 address in order to separate the traffic at this layer between the gateway 1.1 and the decoder 1.10. Each interface has its own configuration in layer-3, the IP layer, to communicate with the other entities in the network.

A separation of the network traffics dedicated to the VOD service and the other network traffics in the decoder is thus obtained. The VOD traffic is therefore never routed in the LAN of the user, making any diversion of the stream difficult for the user.

The correct routing of the two types of stream between the WAN and the decoder 1.10, the first type being the stream dedicated to the VOD service and the second being the conventional stream, requires adaptation at the gateway. This adaptation is done in the form of a management module 1.5 that establishes a direct layer-2 circuit (bridge) between the interface 1.7 connected to the decoder on the LAN side and the interface 1.15 of the WAN network.

This management module 1.5 analyses the layer-2 traffic that reaches the gateway 1.1. It detects all the messages reaching the physical port 1.7 and having the virtual address 1.11 dedicated to the protected service as source MAC address. These packets are then directly sent to the WAN interface 1.15 without being processed by the conventional routing module 1.6 or address translation module 1.3.

Likewise, the layer-2 traffic reaching the WAN interface 1.15 and having as destination address the MAC address 1.11 dedicated to the protected service is directly sent to the interface 1.7 without being processed by the conventional routing module 1.6 or address translation module 1.3.

The operator allocates an IP address to the virtual interface of the decoder dedicated to the protected service in the LAN that is particular thereto and is therefore dedicated to this service. The means used by the operator for routing the IP packets intended for the decoder 1.10 on the gateway 1.1 is out of the scope of the description of this document. It is possible for example to use an IP-in-IP encapsulation. Thus the data relating to the protected service of the decoder 1.10 are transported at the layer-2 to the virtual MAC address of the decoder 1.10, since the latter forms part of the LAN of the operator dedicated to the service. The packet will therefore be detected by the module 1.5 allocated to the direct circuit and routed in the gateway 1.1 directly to the interface 1.7 connected to the decoder 1.10.

The configuration of the module 1.5 for managing the direct circuit can be statically or dynamically done. According to an advantageous embodiment of the invention, the circuit management module 1.5 is dynamically configured. For this purpose, the decoder 1.10 is provided with means for sending a particular DHCP discovery request relating to the configuration of one of its virtual addresses. This request is a discovery request (DHCP discover) of the DHCP server that contains a particular identifier for distinguishing it from a traditional DHCP discovery request. This identifier may be a particular parameter in the header of the DHCP packet.

The gateway 1.1, and more particularly its DHCP server 1.4, then has means for detecting this particular DHCP discovery request marked for this purpose. Instead of serving this request by means of a DHCP offer response, the gateway relays it without processing it to any remote DHCP server 1.17 in the WAN of the operator. It takes this opportunity to note the original MAC address of the request (the virtual address of the decoder 1.10 concerning the protected service) and to configure the direct circuit management module 1.5 with this MAC address.

Once this is done, the DHCP offer response sent by the DHCP server 1.17 of the operator is automatically relayed, by means of the direct circuit that has just been established by the management module 1.5, to the decoder 1.10, which can then receive its level-3, i.e. IP, configuration.

This way of dynamically programming the circuit between the interface 1.7 connected to the decoder on the LAN side and the interface 1.15 of the WAN network by means of the management module 1.5 allows being automatically adapted, in the event of change of decoder or if the decoder is not supplied by the operator.

The DHCP discovery requests sent for the configuration of the other virtual addresses of the decoder do not have a marker identifying them as relating to the protected service. They are therefore conventionally processed by the DHCP server 1.4 of the gateway and configured within the local network LAN of the user.

The traffic relating to the protected service per se, originating in or intended for the virtual interface of the decoder 1.10, is also relayed to the relevant servers 1.18 of the operator. Typically it is an RTSP (Real Time Streaming Protocol) request in the case of VOD.

Fig. 2 illustrates the message exchanges involved in the various operating phases of the invention according to the embodiment where the configuration of the circuit is automatic.

A first set of messages illustrates the DHCP configuration of the virtual MAC address 1.11 of the decoder 1.10 at the operator. The DHCP discovery request 2.1 is sent from this virtual MAC address 1.11 and is received by the DHCP server 1.4 of the gateway 1.1. It is relayed, 2.2, to the DHCP server 1.17 of the operator. The DHCP server 1.4 of the gateway 1.1 uses this to configure, 2.3, the direct-circuit management module 1.5 of the gateway 1.1 by creating the direct circuit on the virtual MAC address 1.11 contained in the request 2.1. The response, in the form of a DHCP offer 2.4, is sent and relayed directly, 2.5, by the module 1.5, to the decoder 1.10.

The following messages correspond to a request 2.6 for configuring the virtual MAC address 1.11. This request is relayed 2.7 by the direct-circuit management module 1.5 to the LAN of the operator, where it is processed by the DHCP server. The response 2.8 passes through the direct-circuit management module 1.5 in order to be relayed 2.9 to the decoder 1.10. The configuration carried by the response 2.9 enables the configuration at layer-3 of the virtual MAC address 1.11 of the decoder 1.10 in a remote network, typically an LAN of the operator dedicated to the protected service.

The following messages illustrate a request relating to the service protected by the invention. An RTSP request 2.10 is sent from the virtual MAC address 1.11 dedicated to the protected service of the decoder 1.10. This request 2.10 is captured by the direct-circuit management module 1.5 and is relayed 2.11 to the LAN of the operator. It there continues its route to the VOD server, which responds to the request by sending a response 2.12. The response is sent in the form of an IP traffic from the LAN of the operator, to the decoder 1.10. Then, once arrived at the gateway 1.1, this traffic is directed 2.13 by the direct-circuit management module 1.5 to the decoder 1.10, since it is intended, at the layer-2, for the virtual MAC address 1.11 of the decoder 1.10.

The following messages illustrate the operation of the other virtual interfaces of the decoder 1.10, those that use the virtual addresses 1.12 and 1.13, for example. Each interface must obtain its network configuration. To do this, it sends a first discovery request DHCP 2.14. This request is received by the DHCP server of the gateway 1.10. As this request does not include a marker relating to the protected service, it is conventionally served by the DHCP server 1.4 of the gateway 1.1, which therefore responds with a DHCP offer 2.15. The result is the configuration request 2.16 and its response 2.17. As from this time, the interface is configured as forming part of the LAN of the user and can use the gateway 1.1 for accessing any service on the WAN communications network in a conventional manner.

Typically, an HTTP (Hyper Text Transfer Protocol) request 2.18 is routed through the address translation system 1.3 and is relayed 2.19 to the destination server, typically via an HTTP relay (proxy) of the operator. When the relay receives the response, it relays it 2.20 to the gateway. The address translation mechanism operated by the module 1.3 enables the response 2.21 to be routed, in the router 1.6, to the decoder 1.10.

It is found that the traffic relating to the protected service is separated from the other traffic. The first one is routed in a specific layer-3 LAN of the operator and controlled by it. The other traffic is routed normally and separately in the LAN of the user.

An alternative to the embodiment described above consists of using virtual local networks, called VLANs (Virtual Local Area Networks). This well known mechanism also enables separating the data streams from the same physical interface thanks to layer-2 virtual addresses. Indeed, virtual local networks are layer-2 enciphered tunnel techniques. Each virtual address could use a particular VLAN. At the gateway, the differentiation of the streams could then be done by VLAN rather than by MAC address.

We would then have a first data stream dedicated to the protected service and marked by a VLAN, for example using the label 1001. A second stream dedicated to control and marked by a VLAN using for example the label 1002, while the other data streams would be marked by a VLAN using the label 1003. Each of these VLANs using its own virtual MAC address in the decoder.

This alternative does however have a few constraints. The decoder must be in a position to mark the streams. The gateway must support the VLANs. The operator must also be in a position to manage the VLANs for the protected service. In the contrary case, the gateway must be in a position to delete the marking of the VLANs before relaying the traffic relating to the protected service to the operator. It is also necessary for the operator or the gateway to delete the marking of the data streams that are to be relayed to the internet. This is because the VLANs cannot exist in the internet world or on machines connected to the LAN. The DHCP server of the gateway must always distinguish the packets coming from the decoder in order to relay them to the DHCP server of the operator. This discrimination may be identical to that done in the first embodiment or implement the use of the VLANs.