EP3149953A1

EP3149953A1 - Sat-ip proxy server for iptv

Info

Publication number: EP3149953A1
Application number: EP15713691.2A
Authority: EP
Inventors: Carsten Dethloff
Original assignee: Deutsche Telekom AG
Current assignee: Deutsche Telekom AG
Priority date: 2014-05-30
Filing date: 2015-03-26
Publication date: 2017-04-05
Also published as: WO2015180863A1; DE102014107656B3

Abstract

The invention relates to a method for the transmission of IPTV signals to a SAT-IP client, wherein an IPTV server function simulates vis-à-vis the SAT-IP client requesting a satellite transmitter that is characterized by certain reception parameters to have the functionality of a SAT-IP server. For this purpose, the IPTV server function analyzes the request received by the SAT-IP client, associates it with an IPTV transmitter and sends to the SAT-IP client a response in accordance with the SAT-IP specification.

Description

SAT> IP proxy server for IPTV

The invention relates to a method and a system for transmitting IPTV (Internet Protocol Television) signals to a client, which is integrated into an IP-based architecture for the reception and distribution of satellite signals over a local area network, the communication being satellite Signals over the network on the basis of the satellite to Internet Protocol (SAT-IP or synonym SAT> IP) happens.

Known satellite TV reception systems first convert the signals received by the satellites in the frequency range between 1 1, 7 GHz and 12.95 GHz to an intermediate frequency in the frequency range 950-2150 MHz and then distribute the signals according to the DVB-S (satellite) or DVB-S2 standard via coaxial cable or - with the help of multi-frequency converters - to one or more satellite receivers and set-top boxes. A standard was recently published with the SAT> IP protocol, with which DVB-S signals can be converted and encapsulated in IP packets, whereby these packets can then be distributed over any IP network as known from conventional IPTV.

With this SAT> IP protocol, the digital DVB satellite signals, as they come from a LNB (low noise block) or a multi-switch, converted directly into IP signals and distributed over the landline or wireless network-based IP network. In this way, broadcasts received via satellite can be output directly to corresponding multimedia IP devices, so-called SAT> IP clients. In the process, such a SAT> IP client uses the SAT> IP server virtually as a "virtual" receiver The particular advantage of this transmission in the form of IP signals is that the distribution of the satellite signals can take place over the existing IP networks and not The SAT> IP protocol has been specially developed to allow devices that "understand" this protocol to communicate with the appropriate SAT> IP servers. The SAT> IP protocol is a remote tuner protocol based on existing protocols such as IP and UPnP (Universal Plug and Play), RTSP (RealTime Streaming Protocol) and HTTP (Hypertext Transfer Protocol). It provides a media layer and a control layer, where at the media level the SAT> IP Server Media Stream is sent in unicast or multicast RTP / UDP (User Datagram Protocol). For example, at the control level, clients request access to satellite, transponder, and MPEG streams over RTSP or HTTP. The packets required for the requested TV transmission are then sent over the IP network.

In the meantime, the SAT> IP protocol has become so prevalent that more and more corresponding end devices, in other words SAT> IP clients, are coming onto the market that can communicate via this standard. The integration into new Smart TV devices is also planned. With the spread of the SAT> IP protocol, it is becoming increasingly difficult for users, or more uncomfortable, to receive broadcasts over other currently prevalent transmission standards. In the worst case, there will eventually be terminals that can only understand SAT> IP.

The object of the invention is now to propose a method by which programs that are already distributed via IPTV via the (V) DSL or fiber network can be displayed in a technically simple and cost-effective manner by means of SAT> IP clients. The task is still to propose a corresponding system for implementing the method.

WO 2014/029 817 A1 discloses a device ("crossover box") which receives requests from a client in accordance with the SAT-IP protocol and evaluates corresponding reception parameters in order to be able to send a corresponding response to the SAT-IP client For example, this apparatus generates a combined output data stream according to the SAT-IP protocol, which not only contains data of a received TV program, but also provides further data retrieved over the Internet. These objects are achieved by the method according to claim 1 and the system according to claim 7. Preferred embodiments emerge from the respective subclaims.

The basic idea of the method according to the invention is, in simple terms, to "pretend" the SAT-IP client by means of a functionality integrated in the interface to the IPTV to a SAT-IP server, wherein the SAT-IP client has the IPTV content in that of a SAT-IP server This is done with an IPTV server function according to the invention, which specifies the functionality of a SAT-IP server to the requesting SAT-IP client Advantageously, the IPTV server functionality is integrated as a module in an IAD (Integrated Access Device) or a router.

As part of the data transfer, the SAT-IP client searches by means of a request for a satellite designated by certain receive parameters transmitter, the SAT-IP client already specify the desired receive parameters together with the request or bring them in the sense of a station scan. The IPTV server function evaluates the request of the SAT-IP client, assigns it an IPTV transmitter and sends the SAT-IP client a response according to the SAT IP specification.

Thus, the previously required SAT> IP server is replaced according to the invention by the IPTV server function. With this procedure, it is now possible to output programs that are sent via IPTV, for example via VDSL or fiber, on SAT-IP clients. As a result, the user does not have to switch from one to the other output medium or to another application when changing the transmission standard, but can receive broadcasts both via satellite and via IPTV with a device and an application. The user does not even notice that he is accessing the offer of the other medium.

In network communication, the method of the invention can make use of the proven techniques that DLNA / UPnP (Digital Living Network Alliance / Universal Plug and Play). Since the basic framework of both specifications is almost identical, SAT> IP devices can easily be extended to DLNA servers or clients. To control the IPTV server function through the SAT> IP client, the method according to the invention advantageously uses the real-time streaming protocol (RTSP) or HTTP. The actual streaming can then also be handled by means of real-time transport protocol or HTTP. The actual data can be transmitted in DVB's usual MPEG-2 transport stream format. Together with the IP, UDP and RTP headers and the transport stream blocks corresponding packets are formed. If required, the IPTV server functionality can also translate the tables by IPTV-specific values into DVB-ST-compliant values.

Since the program contents of the IPTV streams are not touched by the method according to the invention, encrypted PAY-TV channels can in principle be reproduced in addition to the free-to-air channels, which is a significant advantage of the method according to the invention.

The technical realization of the integration of IPTV is advantageously carried out via an internal allocation ("mapping") of IPTV parameters to the structure prescribed by the SAT-IP parameters.This mapping of the parameters necessary for controlling the receiving part is realized by the IPTV server function If the IPTV streams are offered in the SAT> IP format, the SAT> IP client will not be notified that it is receiving IPTV data instead of SAT> IP data.

In a particularly simple version of the IPTV server function, all streams and frequencies are tightly integrated into the code of the operating system. Since a new programming with a corresponding compilation is necessary when changing the frequencies, it is advantageous to read the IPTV channels to be streamed and the frequencies to which the transmitters are mapped from a file.

In order to be able to pass on all available IPTV programs for the IPTV server function, their parameters must be sensibly managed become. For this purpose, it is advantageous to define a variable type, here SATIPmaps, and to create a variable of this type for each IPTV program. The required parameters can be stored in this variable reproduced below.

typedef struct SATIPmaps {

string name;

string IP;

u_intl6_t port;

vector <float> Freqs;

u_intl6_t ServicelD;

u_intl6_t TransportStreamID;

u_intl6_t NetworkID;

} SATIPmaps]

The pointers to the variables can then be passed as parameters in a HashTable and provide access to all parameters. An example of a function for finding stream parameters by frequency is shown in the following function: lookupStreamName (...): string lookupStreamName (float aktFreq) {

HashTable:: iterator * iter = HashTable:: iterator:: create (* fTable); string StreamName;

char const * key;

for (SATIPmaps * map; (map = (SATIPmaps *) (iter-> next (key)))! = NULL;) for (vector <float>:: const_iterator i = map-> Freqs. begin (); i! = map-> Freqsend (); ++ i)

if (aktFreq == * i)

StreamName = key;

return StreamName;

}

To read the stream parameters, a function can be used to read in the multicast address and name of a stream from an M3U file, an open playlist format for media files grouped together. The content of such an M3U file in EXTM3U format is shown below:

# EXTM3U

#EXTINF: -1, the first one

rtp: // 0239.35.10. : 10000

#EXTINF: -1, ZDF

rtp: //@239.35.10.5: 10000

#EXTINF: -1, RTL

rtp: //@239.35.20.10: 10000 The content in this case means that, for example, the ARD transmits a stream by means of the Real-Time Transfer Protocol (RTP), and this can be reached via the IP address 239.35.10.4 and the port address 10,000.

For the allocation of the frequencies the DVB-S and the DVB-T frequency range can be used. In the DVB-S frequency range, the allocation from the current DVBViewer station list can be used for satellite reception on Astra 19.2 ° East. The frequencies in the DVB-T range are assigned automatically, as shown in the listing below. The order does not match the order in which the SATiPmaps objects are added to the HashTable. void cleanUpFreqs (Boolean addDVBT) {

HashTable:: Iterator * iter = HashTable:: Iterator:: create (* f Table); char const * key;

float freq = 474;

for (SATiPmaps * map; (map = (SATiPmaps *) (iter-> next (key)))! =

ZERO; )

{

if (addDVBT) {

map-> freqs. push_back (freq);

freq + = 8;

}

map-> name = key;

sort (map-> Freqs. begin (), map-> Freqs. end ());

map-> Freqs.erase (unique (map-> Freqs. begin (), map-> Freqs.end ()), map-> Freqs.end ());

}

In the example of the ARD stream mentioned above, this can be assigned, for example, to the frequency 10748 MHz.

Another possibility of allocation is a separate configuration file in which the frequencies to be allocated are listed after the colon followed by a colon, separated by spaces. Allocation of frequencies in the DVB-C range is easily possible in one of these ways.

In order to better organize the parameters read in by the SAT> IP parser and to make their storage easier to understand, it is advantageous to define a new type of SATiPParams analogous to the SATiPmaps type. The parser can be integrated into the SATiPmapping class and a function can be integrated with the method calcPids (...) to calculate the currently requested PIDs. For consumers of IPTV, the procedure according to the invention is of great advantage, since the service is no longer limited to the set-top box. With the support of SAT> IP by the new generation of smart TVs, it is now possible for the first time to receive IPTV directly on the TV without additional remote control.

The invention will be described in more detail below with reference to the figure.

The figure shows a network element 1 of a telecommunications network receiving an IPTV stream from a server. The network element 1 is connected via a (V) DSL or optical fiber line 2 to an access means 3 in the form of a router or an IAD (Integrated Access Device). The router 3 can send the IPTV stream via radio interfaces 4, in particular via WLAN, to a notebook 5, a tablet PC 6 or a smartphone 7. On these devices, the IPTV stream is played in a known manner by means of a corresponding media player.

In addition, the router 3 is connected via a landline 8 with a set-top box 9, which is associated with a television set 10. About the set-top box 9 10 satellite programs can be played on the TV, which are transmitted in the SAT> IP standard. In this respect, the set-top box 9 assumes the role of a SAT> IP client.

In the router 3, the IPTV server function according to the invention is implemented, with which the IPTV stream is converted into the SAT> IP protocol that is understandable for the SAT> IP client, the set-top box 9. Alternatively, the IPTV server function may also be implemented in a standalone device, e.g. connected to the IAD or router via a free LAN port.

When the set-top box 9 is switched on, it can start a request, for example in the form of a search run, which depends on the IPTV address realized in the router 3. Server function is picked up. The IPTV server function sends in response a IPTV stream mapped to a frequency that can be processed by the set-top box 9, which it receives from the network element 1.

Claims

claims

1. A method for the transmission of IPTV signals to a SAT-IP client, wherein the SAT-IP client requesting a designated by certain receiving parameters satellites transmitter, the functionality of a SAT-IP server is given by an IPTV server function by the IPTV server function the request of the SAT-IP client is evaluated, assigned to an IPTV transmitter and the SAT-IP client sends a response according to the SAT-IP specification.

2. The method according to claim 1,

characterized,

the answer comprises an IPTV content transmitted to the SAT-IP client in a parameter environment otherwise used by a SAT-IP server as defined in the SAT> IP protocol, with an IPTV parameter mapping , in particular the frequency to which the structure prescribed by the SAT-IP parameters takes place.

3. The method according to claim 1 or 2,

characterized,

that the IPTV signals are implemented at the IP level in the network (LAN) and forwarded to the SAT-IP client.

4. Method according to one of the preceding claims,

characterized,

that the SAT-IP client first acquires the reception parameters in the sense of a station search before requesting the station.

5. Method according to one of the preceding claims,

characterized,

that the SAT> IP client uses the Real-Time Streaming Protocol (RTSP) or http to control the IPTV server function, and that the streaming is done using real-time transport protocol or HTTP.

6. The method according to any one of the preceding claims,

characterized,

the IPTV content is transmitted in the MPEG-2 transport stream format.

7. System for implementing the method according to one of the preceding claims characterized by

a network element (1) of a telecommunications network receiving an IPTV stream,

an access means (3) connected to the network element (1) realizing the IPTV server function, and

a SAT> IP client associated with a TV connected to the Integrated Access Device.

8. System according to claim 7,

characterized,

that the access means (3) is implemented in a router.

9. System according to claim 7 or 8,

characterized,

that the SAT-IP client is implemented in a set-top box (9).