WO2010026355A1 - Procede et dispositif de redirection d'une requete de controle d'un flux de donnees - Google Patents

Procede et dispositif de redirection d'une requete de controle d'un flux de donnees Download PDF

Info

Publication number
WO2010026355A1
WO2010026355A1 PCT/FR2009/051685 FR2009051685W WO2010026355A1 WO 2010026355 A1 WO2010026355 A1 WO 2010026355A1 FR 2009051685 W FR2009051685 W FR 2009051685W WO 2010026355 A1 WO2010026355 A1 WO 2010026355A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
terminal equipment
capture
request
stream
Prior art date
Application number
PCT/FR2009/051685
Other languages
English (en)
Inventor
Frédéric FIEAU
Thang Vu Duong
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Priority to EP09741379A priority Critical patent/EP2332332A1/fr
Priority to US13/062,906 priority patent/US8639777B2/en
Publication of WO2010026355A1 publication Critical patent/WO2010026355A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6338—Control signals issued by server directed to the network components or client directed to network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6582—Data stored in the client, e.g. viewing habits, hardware capabilities, credit card number

Definitions

  • the present invention relates to the general field of telecommunications.
  • It relates more particularly to the control mechanisms on data streams broadcast by a source on an IP network, such as for example multimedia data streams broadcast in multicast mode within an IPTV (Internet Protocol Television) infrastructure.
  • IPTV Internet Protocol Television
  • nTS service network time shifting
  • an nTS service allows an end user, receiving on a terminal equipment an IPTV data stream broadcast in real time (commonly referred to as "live stream”), to control control operations on this stream (or more precisely on a recording of this stream), similar to those provided by a VCR.
  • live stream IPTV data stream broadcast in real time
  • control operations are for example read, pause, rewind, stop, etc. operations.
  • broadcast servers must be adapted to capture (that is to say record), in circular buffers, the different streams for which the operator wishes to offer this service, and then to broadcast these streams to the user terminal equipment. subscribers to the service, depending on the operations required by these subscribers.
  • the broadcast servers considered are programmed with a predefined list of streams to capture, so as to allow the permanent capture of all the streams for which the operator wishes to offer this service.
  • the present invention responds to this need by proposing a method for redirecting a request for controlling a data stream broadcast by a source in a telecommunications network, transmitted by a terminal equipment, this method comprising:
  • a step of obtaining information representative of a current flow control capability for a plurality of broadcast servers upon receipt of this request, a step of obtaining information representative of a current flow control capability for a plurality of broadcast servers; a step of selecting, using at least this information, a server from the plurality of servers, able to control the stream broadcast by the source;
  • the invention also provides a device for redirecting a request for controlling a data stream broadcast by a source in a telecommunications network, transmitted by a terminal equipment, this device comprising:
  • means activated upon receipt of this request, for obtaining information representative of a current data flow control capability, for a plurality of broadcast servers; means for selecting, using at least this information, a server from among the plurality of servers, able to control the stream broadcast by the source;
  • a control request for a data stream may designate either a request for activation or deactivation of a control of the data flow, a request to establish a control session of this stream or a request to activate a specific control operation on this stream such as for example a pause, read or rewind operation.
  • the current flow control capacity of a broadcast server characterizes its ability to control, at the current time, a data stream, that is to say, to capture it. and broadcast it to a terminal equipment in order to be able to implement control operations on this stream, and this in view of the data flows already controlled by this server at this current time.
  • a data stream that is to say, to capture it. and broadcast it to a terminal equipment in order to be able to implement control operations on this stream, and this in view of the data flows already controlled by this server at this current time.
  • the current flow control capacity of a server can thus be expressed, for example, in the form of a bit rate or a number of data streams that can still be controlled by the server, given the flows already controlled. by this server at the current time.
  • the invention applies in particular to the management of a control of a time shift nTS service data stream managed by the telecommunications network.
  • the terminal equipment can be in this case, for example, a TV decoder also called "set top box”.
  • the invention thus makes it possible, in this context, to dynamically manage and activate the recording of a stream broadcast over the telecommunications network by a broadcast server, as a function of the requests from the terminal equipments receiving this stream.
  • the invention makes it possible to capture at the broadcast server level only the streams for which a control (nTS service) is required by a terminal equipment. Also, for the sake of simplification, we will talk later in this dynamic nTS service document.
  • broadcast servers can be used to implement the invention, which makes it possible to deploy these servers closer to the terminal equipment in the network (for example at the edge of the collection network or in the collection network, also called backhaul).
  • these broadcast servers can also be deployed, as for the techniques of the prior art, at the point of presence of the network (POP) located at the junction of the collection network and the network.
  • core network (“backbone").
  • the invention makes it possible to control congestion at the broadcast server level by selecting, using information representative of a current flow control capability of the broadcast servers (that is, that is, reflecting the state of the control resources available at the broadcast server at the time of the processing of the control request by the redirection device), a broadcast server able to control the data flow, in other words to the capture and broadcast it to the terminal equipment.
  • the information representative of a current flow control capability of a broadcast server comprises representative information:
  • a current capacity of broadcast sessions of this server i.e. reflecting the current ability of the server to broadcast a stream to a terminal equipment, given the streams already broadcast by this server
  • a broadcast server will be considered to be able to control a stream if it has sufficient current capture capabilities and broadcast sessions for that stream.
  • Information representative of a current capture capacity of this server may be, in this case, the information that this server captures this stream.
  • the redirection method further comprises, after the selection step, a step of establishing a session with the terminal equipment for the data stream. During the maintenance of this session, at least one other control request issued by the terminal equipment for this flow is redirected to the server already selected.
  • the redirection device may furthermore comprise means for establishing a session with the terminal equipment for this data stream, the redirection means of the device being adapted, during the maintenance of this session, to redirect at least one other request. from the terminal equipment for this stream to the already selected server.
  • the selection step is implemented once, for example the first time that the terminal equipment sends a control request on a given stream, this request comprising or not a control operation on the stream. This speeds up the execution of the dynamic nTS service according to the invention.
  • the selection of the broadcast server to which to redirect requests from the terminal equipment may also depend on the proximity of the server to the terminal equipment in the telecommunications network. For example, we will select a broadcast server capable of capturing and broadcasting the stream belonging to the same subnetwork of the telecommunications network as the terminal equipment. In this way, the speed and the reliability of execution of the dynamic nTS service according to the invention will be optimized (it limits in particular the latency and the loss of packets due to a journey of data packets of the flow in the network too long).
  • the server may also be selected based on the existence at this server of a capture of the data stream for at least one other terminal equipment.
  • the storage space (Random Access Memory (RAM) or disk array for example) required to implement the nTS service is optimized, because it favors the dissemination of the same data stream by a single server.
  • RAM Random Access Memory
  • several broadcast servers may still be required to capture and broadcast the same data stream, especially if this is necessary for example because their respective capacity is not sufficient to satisfy all equipment terminals requiring nTS operations on this stream (high demand stream).
  • the selection step can also take into account a type of data stream capture for at least one broadcast server, which type can be selected from at least one type of static capture and one type of dynamic capture.
  • the operator can specify, in a database defining the service management policy: - the data streams recorded statically at different broadcast servers. This may be, for example, streams from thematic or regional channel groups; and - dynamically recorded data streams.
  • the redirection method further comprises:
  • a step of detecting a data flow control deactivation event for the terminal equipment a step of determining whether the selected server for the data flow for the terminal equipment captures this data flow for at least one other terminal equipment;
  • the redirection device may further comprise:
  • the redirection method further comprises a step of determining a type of data stream capture, which type can be selected from at least one type of static capture and a type of dynamic capture, and if it is determined that the capture of the stream is of static type, the step of sending an end of capture request is not implemented.
  • the redirection method comprises, before the redirection of a control request to the selected server: a detection step that the control request comprises a control operation which can not Be implemented by the selected server and
  • the redirection device may further comprise: detection means that the control request includes a control operation that can not be implemented by the selected server; and
  • the method and the redirection device according to the invention present in combination all or part of the aforementioned characteristics.
  • the various steps of the redirection method are determined by computer program instructions.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a redirection device or more generally in a computer, this program comprising instructions adapted to the implementing the steps of a redirection method as described above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG. 1 shows a redirection device according to the invention, in its environment, in a particular implementation implementation
  • - Figure 2 shows the hardware architecture of a redirection device according to the invention, in a particular embodiment
  • FIGS. 3A-3D represent the main steps of a redirection method according to the invention, when it is implemented by a redirection device as represented in FIGS. 1 and 2, in a particular embodiment .
  • FIG. 1 illustrates an implementation of the invention for a control of a time shift nTS service data stream managed by a telecommunications network 1.
  • an nTS service allows an end user, receiving on a terminal equipment a data stream
  • IPTV broadcast in real time by a source of a telecommunications network, to control control operations on this stream similar to those provided by a VCR.
  • the telecommunications network 1 is equipped with an IPTV infrastructure enabling the broadcasting of IPTV multimedia streams in real time, by implementing known mechanisms for multicast broadcasting and "streaming".
  • streaming means the broadcasting mechanism of continuously sending data from a source to a destination without the destination needing to download or store the data as a whole.
  • the IPTV infrastructure of the network 1 includes, for this purpose, an HE headend (source within the meaning of the invention) adapted to generate and broadcast in the telecommunications network 1 FL data streams. These data streams consist here of a series of packets carrying TV-type multimedia data (data broadcast on channels or channels of audiovisual programs).
  • the IPTV infrastructure of the network 1 also includes ROUT devices (such as routers), allowing the diffusion of FL data streams in a multicast broadcast mode.
  • a multicast broadcasting mode makes it possible to organize and optimize the sending of the same stream of data transmitted by a source to several recipients, thus avoiding unnecessary replication of the data packets in a network.
  • FL streams are received and decoded at an end user U by a terminal equipment STB.
  • This terminal equipment is for example here a TV set-top box or "set top box”.
  • set top box Of course, other terminal equipment equipped with such a decoder can be considered.
  • the IPTV infrastructure of the network 1 is equipped with an nTS system 10 including:
  • redirection device RB also called redirection server RB;
  • PORT server hosting a portal dedicated to the nTS service;
  • a "dynamic" sDB database called a session database;
  • tDB database a "static" tDB database, called a topology database.
  • system 10 may also include an oDB database specifying an operator policy, referred to as the operator base (shown in dashed lines in Figure 1), and specifying a type of data stream capture based on the strings of programs that broadcast them, for one or more broadcast servers of the set 11 (ie static or dynamic recording).
  • an operator policy referred to as the operator base (shown in dashed lines in Figure 1)
  • the operator base shown in dashed lines in Figure 1
  • a type of data stream capture based on the strings of programs that broadcast them, for one or more broadcast servers of the set 11 (ie static or dynamic recording).
  • the NTSSk broadcast servers, k 1,..., K, implement nTS services such as those proposed in the prior art.
  • Each of these broadcast servers here has the hardware architecture of a computer, and notably comprises a processor, a RAM type of RAM and a ROM type ROM (not shown).
  • It also includes means for capturing flows allowing it, on request of the redirection server: - to subscribe to at least one ROUT router, to receive one or more determined data streams, broadcast (s) ) in multicast mode by the headend HE, and for which service (s) nTS is desired; and
  • IGMP Internet Group Management Protocol
  • the means ING are further adapted to capture (that is to say record) a data stream to which the NTSS server k is subscribed, in a BUF circular buffer of predefined size.
  • This circular buffer is located in a storage space of the NTSSk server, for example in the RAM or in a hard disk of this server. We will consider a circular buffer per captured data stream.
  • the NTSS server k also comprises STR broadcasting means adapted to interpret and process a control request issued by a terminal equipment for a given data stream.
  • Such a request may include a read, pause, etc. operation, and conforms to a predefined protocol.
  • control requests sent by the terminal equipment STB as part of the dynamic nTS service are Real Time Streaming Protocol (RTSP) requests.
  • RTSP Real Time Streaming Protocol
  • the STR means implement here the RTSP protocol, known to those skilled in the art. This protocol is described in particular in the document
  • these requests may be in accordance with other application protocols such as the Session Initiation Protocol (SIP) or the HyperText Transfer Protocol (HTTP).
  • SIP Session Initiation Protocol
  • HTTP HyperText Transfer Protocol
  • the means STR are also adapted to broadcast in unicast mode to the terminal equipment, the contents of the circular buffer BUF corresponding to a control operation contained in a control request RTSP issued by this equipment. They can in particular implement for this purpose a known transport protocol such as RTP / UDP,
  • the capture means
  • ING and STR broadcast are considered implemented by a single device (eg a single computer), namely the NTSS server.
  • the means ING, the means STR and the buffer BUF can be implemented by separate devices; NTSS server will then be understood to mean a system comprising these different devices.
  • the redirection server RB is in accordance with the invention. It has here the hardware architecture of a computer, as represented in FIG. 2, and comprises a processor 20, a random access memory of the RAM type
  • This read-only memory 22 constitutes a recording medium in accordance with the invention, readable by the redirection server RB, and on which is recorded a computer program according to the invention.
  • This program includes instructions for performing the steps of a redirection method according to the invention. The main steps of this method are shown, in a particular embodiment of the invention, in FIGS. 3A-3D described later (steps F1 to F190).
  • the redirection server RB also comprises means of communication 23 with the terminal equipment STB and with the broadcast servers NTSSk, implementing the RTSP protocol in the example described here.
  • the tDB topology database includes, for each NTSS server k :
  • a broadcast session includes the stream broadcast between the broadcast server and a terminal equipment, as well as the control flows exchanged between the terminal equipment and the broadcast server and the control flows exchanged between the redirection server. and the broadcast server.
  • This capacity thus takes into account the processing and broadcasting resources implemented by the NTSS server k to satisfy control operations required by a terminal equipment on a given flow.
  • the ICapMax (k) and DCapMax (k) capabilities are static, i.e. invariant, data that depends on NTSSk server resource requirements (eg, storage space, CPU performance, etc.) . They can vary from one NTSS server to another.
  • This static data can be provisioned in the tDB database or be communicated by the NTSSk servers during a preliminary phase.
  • the topology database tDB also comprises, for each NTSS server k , a location parameter of this server.
  • This location parameter is for example here an identifier
  • subnet identifiers may be considered, as well as other location parameters (such as for example a CLID or Calling An IDentifier in English).
  • the sDB session database includes, at a given moment:
  • Each current stream capture session is defined in the sDB database by a triplet comprising: an identifier of the NTSS server carrying out the capture of the stream;
  • Each current streaming session is defined in the sDB database by a triplet comprising: an identifier of the broadcast stream;
  • FIGS. 3A to 3D the main steps of the redirection method according to the invention, when it is implemented, in a particular embodiment, by the redirection server RB shown in FIGS. 1 and 2.
  • a user U of the terminal equipment STB wishes to access the dynamic nTS service proposed by the operator of the telecommunications network 1, in order to implement time shift operations on a data stream.
  • multimedia data FU received in real time by the terminal equipment STB, for example a return operation OP (control operation within the meaning of the invention).
  • the user U has previously subscribed to this service with the PORT server, and that the terminal equipment STB obtains the authorization to access the dynamic nTS service. for example, by correctly authenticating with the PORT server.
  • the terminal equipment STB will have previously unsubscribed from the multicast broadcast of the stream FL 0 to the router ROUT.
  • DSLAM device Digital Subscriber Access Multiplexer
  • STB Terminal Equipment
  • DSLAM device Digital Subscriber Access Multiplexer
  • the user U for example presses a corresponding key on a remote control of the terminal equipment STB, which transmits the request for access to the user's operation OP. U to the terminal equipment.
  • the terminal equipment STB Upon receipt of this access request (step ElO), the terminal equipment STB sends the redirection server RB a request R_act (FI_o) initialization of a control session for the data stream FL 0 (step E20) .
  • This request is a control request within the meaning of the invention.
  • the request R_act (FI_o) is here an RTSP request including an identifier of the stream FL 0 (eg a multicast IP address). It may also include the command relating to the OP control operation required by the user U on the stream FL 0 - However, this command may be sent later to the redirection server RB, once the control session has been established. embodiment described here).
  • the RB server selects, according to predetermined criteria, an NTSSRO server from the plurality of broadcast servers.
  • the redirection server RB initially interrogates, using the interrogation means 24, the sDB session database (step FlO), so as to obtain for each NTSSk server:
  • the current number ICurr (k) of streams of data simultaneously captured by this server at this time i.e. current number of capture sessions
  • the current number DCurr (k) of broadcast sessions simultaneously managed by this server at this instant i.e. current number of capture sessions
  • the numbers ICurr (k) and DCurr (k) are computed in a known manner by the interrogation means of the database sDB, from the information broadcast sessions and capture sessions stored in this database, to the for example, an appropriate query query obvious to the skilled person.
  • the redirection server RB also queries, during this step, the tDB topology database to obtain, for each NTSS server k , the maximum capacities ICapMax (k) and DCapMax (k).
  • NTSS k and more generally a current flow control capability of the NTSSR server.
  • the capture capabilities and broadcast sessions are expressed in the form of flow numbers, however this assumption is not limiting, one could for example express these capabilities in the form of flow rates. It is the same of course for the capacity of flow control of the server.
  • the redirection server constitutes, in a second step (step F20), a list L of potential NTSS servers that are potential candidates among the NTSS servers k , that is to say, that are capable of capturing the FL 0 data stream and establish a broadcast session of this data stream for the terminal equipment STB (that is, again, which have a current capacity of sufficient flow control, for example non-zero).
  • this list consists of the NTSS servers k of the plurality of servers for which the following conditions (1) or (2) are verified:
  • a server is a potential candidate if it has a current stream capture capability and a current capacity of broadcast sessions sufficient to provide the service (ie, above predetermined thresholds, ⁇ l and ⁇ 2> 0), for example here if: [ICapMax (k) -ICurr (k)]> ⁇ l and [DCapMax (k) - DCurr (k)]> ⁇ 2
  • a server is a potential candidate if it has a current broadcast session capacity sufficient to provide the service (ie greater than a predetermined threshold ⁇ 2) and if it already captures the FLo stream for another terminal equipment , ie for example here, if:
  • information representative of a current capture capacity of this server in the sense of the invention may consist of the information that this server captures the flow required by the server. terminal equipment.
  • the redirection server RB then preferably selects, in the order: - an NTSSRO server of this list already capturing the stream FL 0 for a other terminal equipment;
  • An NTSS server will be considered here as being the closest to the terminal equipment STB if it belongs to the same subnet in the network 1 as the terminal equipment STB.
  • the redirection server RB extracts from the control request R_act, the IP address of the terminal equipment STB (address transmitted in the request in a manner known per se) and compares it with the identifiers IDSub (k) of the under- NTSSk server networks of list L. These identifiers are obtained by querying the tDB topology database using means 24.
  • the list L includes several potential candidate NTSS k servers
  • other selection criteria can be used to select the NTSSko server.
  • load sharing criterion or "load balancing" in English
  • Other load-sharing strategies can of course be considered, such as selecting the server that captures the least flow.
  • the redirection server RB also interrogates, during this step, the oDB operator database to obtain the type of record specified for the data flow object of the control request.
  • the redirection server RB also interrogates, during this step, the oDB operator database to obtain the type of record specified for the data flow object of the control request.
  • the redirection server RB sends the means ING of the NTSS ⁇ server a request RTSP for capturing the data stream FL 0 (step F30), noted below.
  • This request is processed by the means ING, which then send a request for subscription to the stream FL 0 to the router ROUT (for example using the IGMP protocol), in order to benefit from the multicast broadcast of the stream FL 0 implemented. by the headend HE (step GlO).
  • an RTSP Setup or HTTP Setup request may be sent to a device of the RTSP server or proxy type network, or respectively to a device of the server type network or HTTP proxy.
  • a flow capture session FL 0 is initiated by the means ING (step G20).
  • the means ING record the stream FL 0 , broadcast in real time in multicast mode by the headend HE, in a circular buffer BUF associated with the stream FL 0 .
  • RTSP acknowledgment message ACK eg RTSP 200 OK
  • the redirection server RB updates the dynamic database sDB (step F40), with the new entry the capture session of the stream FL 0 initiated by the NTSSko server.
  • this new capture session is represented in the dynamic database sDB by:
  • step F20 an NTSSRO server already capturing the stream FL 0 for another terminal equipment is selected, the steps F30 sending a capture request to the server NTSSk 0 , GlO of NTSS server subscription k0 , G20 of initiation of a stream capture session FL 0 , G30 of sending an acknowledgment message to the redirection server RB and F40 of the database update of sDB are not not implemented, the NTSSko server is already subscribed to the broadcast of FL 0 stream and recording this stream.
  • the redirection server sends to the terminal equipment an acknowledgment message (eg RTSP 200 OK), in response to the control request R_act (step F50).
  • a SESS control session is then established between the terminal equipment STB and the redirection server RB (step F60).
  • the establishment of this RTSP session includes the creation of a context (ie a set of data) associated with this session, and saved for example in the database sDB.
  • a context notably contains, in a manner known per se, a session identifier, an identifier of the terminal equipment STB (eg its IP address) and an identifier of the NTSS server k o.
  • the R_act control request sent by the terminal equipment STB to the redirection server RB is redirected by this server to the distribution means STR of the NTSSko server, in the form of a control request.
  • the broadcast server NTSS k o then establishes a broadcast session for the stream FL 0 and the terminal equipment STB (step G40) and informs the redirection server RB (step G50), which updates the dynamic database sDB with this new broadcast session (step F80).
  • this new broadcast session is represented in the sDB database by:
  • the redirected request R_act ' may be identical to the control request R_act, or alternatively, slightly modified so as to include including parameters of the NTSS server k o such as its IP address or a port number.
  • the RB server can use the RTSP protocol, or alternatively the SIP or HTTP protocol. If no response from the terminal equipment to these messages is received within a predetermined time interval following their sending, the redirection server RB terminates the SESS control session. Otherwise, the SESS session is maintained.
  • the redirection server RB does not send periodic maintenance messages, but it is the terminal equipment STB that is at the origin of these messages. Similarly, if the RB server does not receive such a message within a predetermined time interval, then it terminates the SESS session established with the terminal equipment STB.
  • the terminal equipment STB sends a request to the portal PORT in order to obtain the status of the BUF buffer associated with FL flow 0 (step E30).
  • This request can be in particular an HTTP or SIP request.
  • buffer state its filling rate.
  • This filling rate is calculated by the portal PORT from the start time to the capture session of the stream FL 0 by the server NTSSR O , provided, of course, that the filling rate of the buffers by NTSS servers and the size of these buffers are known (which is assumed here).
  • the start time to is obtained by the PORT portal by consulting the sDB database (step H10).
  • the server PORT sends, in response to the request of the terminal equipment STB, the fill rate thus calculated, for example in the form of a progress bar displayed on the screen of the user U (step H20 ) and updated in real time.
  • the terminal equipment STB sends the redirection server RB a request to activate the operation OP (step E40).
  • this OP operation is a return operation on the stream
  • time shift operations may be required, such as a read, pause, etc. operation.
  • the activation request is a control request within the meaning of the invention and comprises the desired OP operation on the flow FL 0 as well as the instant ti.
  • the server RB interrogates the database sDB (step FlOO), to determine if a control session is already established with the terminal equipment STB for the stream FL 0 -
  • step FIlO the NTSS server k o to which to redirect the control requests and more particularly to activate time shift operations during maintaining this session.
  • the request R (OP, FI_o) is then redirected to the means STR of this NTSS server k o in the form of a request R '(step F120).
  • the redirection server RB also determines, by consulting the sDB session database, the start time to the stream capture session.
  • the server RB verifies whether the OP backtracking operation at the instant ti is allowed. If the server RB detects that the filling rate calculated is not sufficient to allow the OP operation required by the terminal equipment, then, before redirecting the request R to the server NTSSRO, it replaces in this request the operation OP control by an OP 'control operation allowed, namely in the example described here by a pause operation at time to. This advantageously makes it possible to avoid the rejection of the request by the NTSSko server.
  • This request is then received and processed by the means STR of the NTSS server k o (step G60), which broadcast to the terminal equipment the required content of the stream FL 0 from the buffer BUF.
  • a frozen image of the stream at time to is thus broadcast to the terminal equipment STB (execution of the OPO command (step G70).
  • control operation OP when the control operation OP is included in the request R_act, the steps of checking and possibly replacing the operation required by an authorized operation are implemented in a similar manner, before redirecting the request to control to the NTSSko server
  • the end of the circular buffer BUF associated with the stream FL 0 can be reached, following a time offset operation required by the terminal equipment.
  • the means STR of the NTSS server k o stop broadcasting the required content of the stream FL 0 to the terminal equipment and send a RTSP message indicating the end of the buffer (message type
  • End of Buffer to the terminal equipment (alternatively another application protocol may be used).
  • the terminal equipment STB On receipt of this message, the terminal equipment STB sends an R_stop request (FI_o) for deactivation of the control to the redirection server RB (step E50); the user U may wish to manually interrupt the broadcast as part of the flow control FL 0 to the terminal equipment.
  • the terminal equipment STB upon receipt of a command from the user (for example following the support by the user U on a key of the remote control of the terminal equipment STB), sends a request R_stop (FI_o) disabling the control RB redirection server (step E50).
  • the reception of this deactivation request by the redirection server RB is in itself a detection of a control deactivation event for the data stream FL 0 for the terminal equipment STB within the meaning of the invention.
  • the redirection server RB consults the dynamic database sDB (step F130), to determine the current number of broadcast sessions established by the NTSSko server for the stream FL 0 , and this, in order to identify if there are other broadcast sessions at the NTSSko server for this stream for other end devices.
  • step F140 If it is determined (step F140) that the terminal equipment STB is the only terminal equipment for which a broadcast session is in progress at the NTSSko server for the stream FL 0 , then the server RB sends to the means ING of the server NTSSko a request to stop the capture of the flow FL 0 (step F150).
  • the means ING stop the capture of the stream FL 0 and send a request to unsubscribe the broadcast of the stream FL 0 to the router ROUT (step G80). If necessary, the circular buffer BUF associated with stream FL 0 can also be deleted.
  • stopping the capture of the stream and sending the unsubscription request will only be implemented after a predetermined time interval during which no request from the terminal equipment STB has been received, so to avoid in particular the restarts and untimely stops of FLo flow capture at the NTSS k o server.
  • the redirection server On receipt of an acknowledgment message of this stop transmitted by the NTSSko server (step G90), the redirection server updates the database sDB to reflect the closing of the capture session of the stream FL 0 by the NTSS server k0 (step F160). It also redirects the stop request R_stop (FI_o) sent by the terminal equipment STB to the means STR of the NTSSko server (step
  • step GlOO stop the broadcast of the stream to the terminal equipment STB.
  • the redirection server On receipt of an acknowledgment message of this closure issued by the NTSS server k o (step GI10), the redirection server updates the database sDB to reflect the closure of the broadcast session of the FLo stream by the NTSSko server. for the terminal equipment STB (step F180).
  • the current number DCurr (kO) of broadcast sessions managed by the NTSS server k o is thus decremented by 1.
  • the session established between the terminal equipment STB and the server RB is then terminated (step F190) and the periodic sending of the hold messages stopped.
  • the redirection server RB consults the corresponding dynamic base oDB and determines if the relevant data stream is statically captured on the NTSS broadcast server k o. If so, it does not issue a capture stop request to this server.
  • the terminal equipment STB can then, if the user U desires, request a new state of the buffer port PORT.
  • broadcast and capture sessions and the control session established between the terminal equipment and the redirection server can also be interrupted due to exceptional and unexpected events.
  • exceptional and unexpected events For example:
  • the STB terminal equipment can be switched off unexpectedly. In this case, it can no longer respond to the hold messages sent by the RB redirection server. The non-reception of these messages is in itself a deactivation event of the control detected by the redirection server;
  • the means STR can stop broadcasting the required contents of the buffer BUF unexpectedly.
  • the terminal equipment STB detects the non-reception of a stream of STR means and sends to the redirection server a request to deactivate the control;
  • the means ING may stop unexpectedly to capture the stream FL 0 .
  • the terminal equipment STB detects an abnormal flow sent by the means STR and sends, after a predetermined time interval, a request for deactivation of the control to the redirection server.
  • the selected NTSSko server sends a non-acknowledgment message (NACK) to the redirection server, which can either select another server or deny access to the nTS control service by the terminal equipment STB for this stream.
  • NACK non-acknowledgment message
  • the means implemented to carry out the redirection method according to the invention are located on the same device (namely the redirection server RB). As a variant, these means (and the functionalities associated with them) could be distributed over different devices, for example on the RB redirection server and on the broadcast servers.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Procédé et dispositif de redirection d'une requête de contrôle d'un flux de données. Le procédé selon l'invention comprend : - sur réception de cette requête de contrôle, émise par un équipement terminal (STB), une étape d'obtention d'informations représentatives d'une capacité courante de contrôle de flux de données pour une pluralité (11) de serveurs de diffusion; - une étape de sélection, à l'aide de ces informations, d'un serveur (NTSSk0) parmi ladite pluralité de serveurs, apte à contrôler ledit flux (FLo) diffusé par la source; - une étape d'envoi d'une requête de capture du flux au serveur sélectionné si celui-ci ne capture pas déjà le flux pour au moins un autre équipement terminal; et - une étape de redirection de la requête de contrôle vers le serveur sélectionné.

Description

Procédé et dispositif de redirection d'une requête de contrôle d'un flux de données
Arrière-plan de l'invention La présente invention se rapporte au domaine général des télécommunications.
Elle concerne plus particulièrement les mécanismes de contrôle sur des flux de données diffusés par une source sur un réseau IP, tels que par exemple des flux de données multimédia diffusés en mode multicast au sein d'une infrastructure IPTV (Internet Protocol Télévision).
L'invention s'applique notamment, de façon privilégiée mais non limitative, dans le cadre de la gestion et de la mise en œuvre d'un service de décalage temporel, géré par un réseau de télécommunications. Un tel service est aussi connu sous le nom anglais de « network time shifting » (ci-après désigné par service nTS).
De façon connue, un service nTS permet à un utilisateur final, recevant sur un équipement terminal un flux de données IPTV diffusé en temps réel (couramment désigné par « flux live »), de commander des opérations de contrôle sur ce flux (ou plus précisément sur un enregistrement de ce flux), analogues à celles fournies par un magnétoscope. Ces opérations de contrôle sont par exemple des opérations de lecture, pause, retour en arrière, arrêt, etc.
Le déploiement d'un tel service, par un opérateur d'un réseau de télécommunications, nécessite la mise en œuvre dans le réseau de serveurs de diffusion. Ces serveurs de diffusion doivent être adaptés à capturer (c'est-à-dire à enregistrer), dans des buffers circulaires, les différents flux pour lesquels l'opérateur souhaite proposer ce service, puis à diffuser ces flux vers les équipements terminaux des utilisateurs abonnés au service, en fonction des opérations requises par ces abonnés. Dans les techniques de l'art antérieur, les serveurs de diffusion considérés sont programmés avec une liste prédéfinie de flux à capturer, de sorte à permettre la capture permanente de l'ensemble des flux pour lesquels l'opérateur souhaite proposer ce service. Ceci requiert donc le déploiement d'un grand nombre de serveurs et/ou de serveurs de capacités très importantes, afin de pouvoir proposer ce service pour un grand nombre de flux (c'est-à-dire de chaînes diffusées par le réseau de télécommunication) et à un grand nombre d'abonnés. Cette contrainte est d'autant plus problématique que le nombre de flux diffusés aujourd'hui sur les réseaux de télécommunications est en croissance permanente.
Il existe donc un besoin d'une solution pour gérer un tel service de contrôle qui ne présente pas de tels inconvénients.
Obiet et résumé de l'invention
La présente invention répond à ce besoin en proposant un procédé de redirection d'une requête de contrôle d'un flux de données diffusé par une source dans un réseau de télécommunications, émise par un équipement terminal, ce procédé comprenant :
- sur réception de cette requête, une étape d'obtention d'informations représentatives d'une capacité courante de contrôle de flux, pour une pluralité de serveurs de diffusion ; - une étape de sélection, à l'aide au moins de ces informations, d'un serveur parmi la pluralité de serveurs, apte à contrôler le flux diffusé par la source ;
- une étape d'envoi d'une requête de capture de ce flux de données au serveur sélectionné si celui-ci ne capture pas déjà ce flux pour au moins un autre équipement terminal ; et
- une étape de redirection de la requête de contrôle vers le serveur sélectionné.
Corrélativement, l'invention vise également un dispositif de redirection d'une requête de contrôle d'un flux de données diffusé par une source dans un réseau de télécommunications, émise par un équipement terminal, ce dispositif comprenant :
- des moyens, activés sur réception de cette requête, d'obtention d'informations représentatives d'une capacité courante de contrôle de flux de données, pour une pluralité de serveurs de diffusion ; - des moyens de sélection, à l'aide au moins de ces informations, d'un serveur parmi la pluralité de serveurs, apte à contrôler le flux diffusé par la source ;
- des moyens pour déterminer si le serveur sélectionné capture ou non ce flux de données pour au moins un autre équipement terminal ; - des moyens d'envoi d'une requête de capture de ce flux au serveur sélectionné, activés si celui-ci ne capture pas déjà ce flux pour au moins un autre équipement terminal ; et
- des moyens de redirection de la requête de contrôle vers le serveur sélectionné.
On notera, qu'au sens de l'invention, une requête de contrôle d'un flux de données pourra désigner indifféremment une requête d'activation ou de désactivation d'un contrôle du flux de données, une requête d'établissement d'une session de contrôle de ce flux ou une requête d'activation d'une opération de contrôle spécifique sur ce flux telle que par exemple une opération de pause, de lecture ou de retour en arrière.
Par ailleurs, au sens de l'invention, la capacité courante de contrôle de flux d'un serveur de diffusion caractérise son aptitude à contrôler, à l'instant courant, un flux de données, c'est-à-dire à le capturer et le diffuser vers un équipement terminal afin de pouvoir mettre en œuvre des opérations de contrôle sur ce flux, et ce compte-tenu des flux de données déjà contrôlés par ce serveur à cet instant courant. On entend ici par capture d'un flux de données, l'enregistrement de ce flux. La capacité courante de contrôle de flux d'un serveur peut ainsi s'exprimer, par exemple, sous la forme d'un débit ou d'un nombre de flux de données pouvant être encore contrôlés par le serveur, étant donné les flux déjà contrôlés par ce serveur à l'instant courant.
L'invention s'applique notamment de façon privilégiée, à la gestion d'un contrôle d'un flux de données de type service nTS de décalage temporel géré par le réseau de télécommunications. L'équipement terminal peut être dans ce cas, par exemple, un décodeur TV aussi appelé « set top box ».
L'invention permet ainsi, dans ce contexte, de gérer et d'activer dynamiquement l'enregistrement d'un flux diffusé sur le réseau de télécommunications par un serveur de diffusion, en fonction des sollicitations des équipements terminaux recevant ce flux.
Le nombre de serveurs de diffusion requis pour mettre en œuvre un service nTS bénéficiant de cette gestion dynamique, ainsi que les capacités, notamment en termes d'espace de stockage, de ces serveurs, sont alors avantageusement limités, ce qui réduit les coûts de déploiement nécessaires pour le service.
En effet, contrairement aux techniques de l'art antérieur, l'invention permet de ne capturer au niveau des serveurs de diffusion que les flux pour lesquels un contrôle (service nTS) est requis par un équipement terminal. Aussi, par souci de simplification, on parlera dans la suite de ce document de service nTS dynamique.
Ainsi, des serveurs de diffusion plus petits peuvent être utilisés pour mettre en œuvre l'invention, ce qui permet de déployer ces serveurs plus près des équipements terminaux dans le réseau (par exemple en bordure du réseau de collecte ou dans le réseau de collecte, aussi appelé backhaul). Toutefois, bien entendu, ces serveurs de diffusion pourront être également déployés, comme pour les techniques de l'art antérieur, au niveau des points de présence du réseau (POP, Point of Présence) se trouvant à la jonction du réseau de collecte et du réseau cœur (« backbone »).
En outre, de façon avantageuse, l'invention permet de contrôler la congestion au niveau des serveurs de diffusion en sélectionnant, à l'aide d'informations représentatives d'une capacité courante de contrôle de flux des serveurs de diffusion (c'est-à-dire reflétant l'état des ressources de contrôle disponibles au niveau du serveur de diffusion au moment du traitement de la requête de contrôle par le dispositif de redirection), un serveur de diffusion apte à contrôler le flux de données, autrement dit à le capturer et à le diffuser vers l'équipement terminal. Dans un mode particulier de réalisation de l'invention, les informations représentatives d'une capacité courante de contrôle de flux d'un serveur de diffusion comprennent des informations représentatives :
- d'une capacité courante de sessions de diffusion de ce serveur (i.e. traduisant l'aptitude courante du serveur à diffuser un flux vers un équipement terminal, étant donné les flux déjà diffusés par ce serveur) ; et
- d'une capacité courante de capture de flux de ce serveur (i.e. traduisant l'aptitude courante du serveur à capturer un flux, étant donné les flux déjà capturés par ce serveur). Ainsi, au cours du procédé de redirection selon l'invention, un serveur de diffusion sera considéré comme étant apte à contrôler un flux de données s'il possède des capacités courantes de capture et de sessions de diffusion suffisantes pour ce flux.
Si un serveur capture déjà ce flux pour un autre équipement terminal, on considérera qu'il dispose d'une capacité courante de capture suffisante pour ce flux. Une information représentative d'une capacité courante de capture de ce serveur pourra être, dans ce cas, constituée de l'information selon laquelle ce serveur capture ce flux.
On notera que l'invention permet avantageusement de combiner des captures (enregistrements) des flux de données de type statiques, c'est-à-dire telles que réalisées dans l'art antérieur où les serveurs de diffusion sont programmés avec une liste prédéfinie de flux à capturer de sorte à permettre la capture permanente de ces flux, et des captures de type dynamiques, c'est-à-dire tels que permises par l'invention en fonction des besoins des équipements terminaux. Dans un mode particulier de réalisation, le procédé de redirection comprend en outre après l'étape de sélection, une étape d'établissement d'une session avec l'équipement terminal pour le flux de données. Durant le maintien de cette session, au moins une autre requête de contrôle émise par l'équipement terminal pour ce flux est redirigée vers le serveur déjà sélectionné.
Corrélativement, le dispositif de redirection peut comprendre en outre des moyens pour établir une session avec l'équipement terminal pour ce flux de données, les moyens de redirection du dispositif étant adaptés, durant le maintien de cette session, à rediriger au moins une autre requête de contrôle émise par l'équipement terminal pour ce flux vers le serveur déjà sélectionné.
Ainsi, l'étape de sélection est mise en œuvre une seule fois, par exemple la première fois que l'équipement terminal envoie une requête de contrôle sur un flux donné, cette requête comprenant ou non une opération de contrôle sur le flux. Ceci permet d'accélérer l'exécution du service nTS dynamique selon l'invention.
La sélection du serveur de diffusion vers lequel rediriger les requêtes de l'équipement terminal peut dépendre également de la proximité du serveur à l'équipement terminal dans le réseau de télécommunications. Par exemple, on sélectionnera un serveur de diffusion apte à capturer et à diffuser le flux appartenant à un même sous-réseau du réseau de télécommunications que l'équipement terminal. De cette sorte, la rapidité et la fiabilité d'exécution du service nTS dynamique selon l'invention seront optimisées (on limite notamment la latence et la perte de paquets dues à un parcours des paquets de données du flux dans le réseau trop long).
Le serveur peut également être sélectionné en fonction de l'existence au niveau de ce serveur d'une capture du flux de données pour au moins un autre équipement terminal.
Ainsi, l'espace de stockage (mémoire de type RAM (Random Access Memory) ou baie de disques par exemple) requis pour mettre en œuvre le service nTS est optimisé, car on privilégie la diffusion d'un même flux de données par un seul serveur. Bien entendu, plusieurs serveurs de diffusion peuvent tout de même être amenés à capturer et à diffuser un même flux de données, notamment si cela s'avère nécessaire par exemple parce que leur capacité respective n'est pas suffisante pour satisfaire l'ensemble des équipements terminaux requérant des opérations nTS sur ce flux (flux très demandé).
On notera que d'autres critères de sélection pourront être considérés, en fonction de la politique de l'opérateur du réseau de télécommunications proposant le service nTS dynamique.
Par exemple, l'étape de sélection peut prendre également en compte un type de capture du flux de données pour au moins un serveur de diffusion, ce type pouvant être sélectionné parmi au moins un type de capture statique et un type de capture dynamique. A cette fin notamment, l'opérateur pourra spécifier, dans une base de données définissant la politique de gestion du service : - les flux de données enregistrés statiquement au niveau de différents serveurs de diffusion. Il peut s'agir, par exemple de flux provenant de groupes de chaînes thématiques ou régionales ; et - les flux de données enregistrés dynamiquement.
Le choix du type d'enregistrement peut être établi suivant différents critères, tels que, par exemple un taux d'audience sur une chaîne donnée : dans ce cas, si une chaîne bénéficie d'un taux d'audience au delà d'un certain seuil d'audience, les flux de données qu'elle diffuse pourront être basculés dans la liste des captures statiques pour une durée prédéterminée. Dans un mode particulier de réalisation de l'invention, le procédé de redirection comprend en outre :
- une étape de détection d'un événement de désactivation du contrôle du flux de données pour l'équipement terminal ; - une étape de détermination si le serveur sélectionné pour le flux de données pour l'équipement terminal capture ce flux de données pour au moins un autre équipement terminal ;
- si ce n'est pas le cas, une étape d'envoi d'une requête de fin de capture de ce flux de données au serveur sélectionné. Corrélativement, le dispositif de redirection peut comprendre en outre :
- des moyens de détection d'un événement de désactivation du contrôle du flux de données pour l'équipement terminal ;
- des moyens pour déterminer si le serveur sélectionné pour le flux de données pour l'équipement terminal capture ce flux de données pour au moins un autre équipement terminal ;
- des moyens d'envoi d'une requête de fin de capture de ce flux de données au serveur sélectionné, activés si ce n'est pas le cas.
De cette sorte, on évite de capturer des flux pour lesquels un contrôle n'est plus souhaité par aucun équipement terminal.
En variante, le procédé de redirection comprend en outre une étape de détermination d'un type de capture du flux de données, ce type pouvant être sélectionné parmi au moins un type de capture statique et un type de capture dynamique, et si on détermine que la capture du flux est de type statique, l'étape d'envoi d'une requête de fin de capture n'est pas mise en œuvre.
Dans un mode particulier de réalisation de l'invention, le procédé de redirection comprend, avant la redirection d'une requête de contrôle vers le serveur sélectionné : - une étape de détection que la requête de contrôle comprend une opération de contrôle qui ne peut pas être mise en œuvre par le serveur sélectionné ; et
- une étape de remplacement de cette opération dans la requête de contrôle, par une opération de contrôle autorisée. Corrélativement, le dispositif de redirection peut comprendre en outre : - des moyens de détection que la requête de contrôle comprend une opération de contrôle qui ne peut pas être mise en œuvre par le serveur sélectionné ; et
- des moyens de remplacement dans la requête de contrôle de cette opération par une opération de contrôle autorisée, lesdits moyens de détection et de remplacement étant activés avant la redirection d'une requête de contrôle vers le serveur sélectionné par les moyens de redirection.
De cette sorte, il est possible d'anticiper des erreurs pouvant apparaître au niveau du serveur de diffusion, notamment lorsque la capture du flux a débuté depuis peu de temps et que certaines opérations de contrôle du flux, comme par exemple un retour en arrière sur ce flux, ne peuvent être réalisées par le serveur de diffusion (le buffer comprenant l'enregistrement n'étant pas assez rempli). Pour éviter cela, on pourra avantageusement remplacer dans la requête de l'équipement terminal l'opération de retour en arrière par une opération de pause par exemple.
On peut également envisager, dans d'autres modes de réalisation, que le procédé et le dispositif de redirection selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées. Dans un mode particulier de réalisation, les différentes étapes du procédé de redirection sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un dispositif de redirection ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de redirection tel que décrit ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
- la figure 1 représente un dispositif de redirection conforme à l'invention, dans son environnement, dans une mise en œuvre particulière de réalisation ; - la figure 2 représente l'architecture matérielle d'un dispositif de redirection conforme à l'invention, dans un mode particulier de réalisation ; et
- les figures 3A-3D représentent les principales étapes d'un procédé de redirection conforme à l'invention, lorsqu'il est mis en œuvre par un dispositif de redirection tel que représenté sur les figures 1 et 2, dans un mode particulier de réalisation.
Description détaillée d'un mode de réalisation
La figure 1 illustre une mise en œuvre de l'invention pour un contrôle d'un flux de données de type service nTS de décalage temporel géré par un réseau de télécommunications 1. Comme décrit précédemment, un service nTS permet à un utilisateur final, recevant sur un équipement terminal un flux de données
IPTV diffusé en temps réel par une source d'un réseau de télécommunications, de commander des opérations de contrôle sur ce flux analogues à celles fournies par un magnétoscope.
Dans le mode de réalisation décrit ici, le réseau de télécommunications 1 est doté d'une infrastructure IPTV permettant la diffusion de flux multimédia IPTV en temps réel, en mettant en œuvre des mécanismes connus de diffusion multicast et de « streaming ». On désigne de façon connue par streaming, le mécanisme de diffusion consistant à envoyer de manière continue des données d'une source à une destination sans que la destination n'ait besoin de télécharger ou de stocker les données dans leur ensemble.
L'infrastructure IPTV du réseau 1 comprend notamment, à cet effet, une tête de réseau HE (source au sens de l'invention) adaptée à générer et à diffuser dans le réseau de télécommunications 1 des flux de données FL. Ces flux de données sont constitués ici d'une suite de paquets transportant des données multimédia de type TV (données diffusées sur des chaînes ou canaux de programmes audiovisuels). L'infrastructure IPTV du réseau 1 comprend également des équipements ROUT (tels que des routeurs), permettant la diffusion des flux de données FL selon un mode de diffusion multicast. De façon connue, un mode de diffusion multicast permet d'organiser et d'optimiser l'envoi d'un même flux de données émis par une source vers plusieurs destinataires, évitant ainsi de répliquer inutilement les paquets de données dans un réseau.
On notera que l'invention s'applique également lorsqu'un mode de diffusion unicast du flux de données entre la source et l'équipement terminal est envisagé. L'homme du métier saura aisément transposer l'exemple de réalisation décrit ici dans le cadre d'un mode de diffusion unicast, de sorte que cette transposition ne sera pas décrite plus en détails ici.
Les flux FL sont reçus et décodés au niveau d'un utilisateur final U par un équipement terminal STB. Cet équipement terminal est par exemple ici un boîtier décodeur TV ou « set top box ». Bien entendu, d'autres équipements terminaux équipés d'un tel décodeur peuvent être considérés.
Pour offrir un service nTS dynamique tel que proposé par l'invention, l'infrastructure IPTV du réseau 1 est doté d'un système nTS 10 comprenant notamment :
- un ensemble 11 de K serveurs de diffusion NTSS1,...,NTSSK ;
- un dispositif RB de redirection selon l'invention aussi appelé serveur de redirection RB ;
- un serveur PORT hébergeant un portail dédié au service nTS ; - une base de données « dynamiques » sDB, appelée base de sessions ;
- une base de données « statiques » tDB, appelée base de topologie.
De façon optionnelle, le système 10 peut également comprendre une base de données oDB spécifiant une politique de l'opérateur, appelée base opérateur (représentée en pointillés sur la figure 1), et spécifiant un type de capture des flux de données en fonction des chaînes de programmes qui les diffusent, pour un ou plusieurs serveurs de diffusion de l'ensemble 11 (i.e. enregistrement statique ou dynamique).
Les serveurs de diffusion NTSSk, k=l,..,K, mettent en œuvre des services nTS tels que ceux proposés dans l'art antérieur. Chacun de ces serveurs de diffusion a ici l'architecture matérielle d'un ordinateur, et comprend notamment un processeur, une mémoire vive de type RAM et une mémoire morte de type ROM (non représentés).
Il comprend également des moyens ING de capture de flux lui permettant, sur requête du serveur de redirection : - de s'abonner auprès d'au moins un routeur ROUT, pour recevoir un ou plusieurs flux de données déterminé(s), diffusé(s) en mode multicast par la tête de réseau HE, et pour le(s)quel(s) le service nTS est souhaité ; et
- de se désabonner auprès de ce même routeur, pour ne plus recevoir un ou plusieurs de ces flux de données.
Ces opérations d'abonnement et de désabonnement sont réalisées par les moyens ING à l'aide du protocole IGMP (Internet Group Management Protocol), par exemple.
Les moyens ING sont en outre adaptés à capturer (c'est-à-dire à enregistrer) un flux de données auquel le serveur NTSSk est abonné, dans un buffer circulaire BUF de taille prédéfinie. Ce buffer circulaire se trouve dans un espace de stockage du serveur NTSSk, par exemple dans la mémoire vive ou dans un disque dur de ce serveur. On considérera un buffer circulaire par flux de données capturé.
Par ailleurs, le serveur NTSSk comprend également des moyens de diffusion STR adaptés à interpréter et à traiter une requête de contrôle émise par un équipement terminal pour un flux de données déterminé.
Une telle requête peut comprendre une opération de lecture, de pause, etc., et est conforme à un protocole prédéfini.
Dans le mode de réalisation décrit ici, les requêtes de contrôle envoyées par l'équipement terminal STB dans le cadre du service nTS dynamique, sont des requêtes RTSP (Real Time Streaming Protocol). Ainsi les moyens STR mettent en œuvre ici le protocole RTSP, connu de l'homme du métier. Ce protocole est notamment décrit dans le document
IETF RFC 2326 intitulé « Real Time Streaming Protocol ». En variante, ces requêtes peuvent être conformes à d'autres protocoles applicatifs tels que le protocole SIP (Session Initiation Protocol) ou le protocole HTTP (HyperText Transfer Protocol).
Les moyens STR sont également adaptés à diffuser en mode unicast vers l'équipement terminal, le contenu du buffer circulaire BUF correspondant à une opération de contrôle contenue dans une requête de contrôle RTSP émise par cet équipement. Ils peuvent notamment mettre en œuvre à cette fin un protocole de transport connu tel que RTP/UDP,
UDP, TCP ou HTTP.
On notera que les moyens ING et STR, ainsi que le principe de fonctionnement d'un buffer circulaire, sont connus de l'homme du métier et ne seront pas détaillés davantage ici.
Par ailleurs, dans l'exemple décrit ici, les moyens de capture
ING et de diffusion STR sont considérés comme mis en œuvre par un seul dispositif (ex. un seul ordinateur), à savoir le serveur NTSS. Toutefois, en variante, les moyens ING, les moyens STR et le buffer circulaire BUF peuvent être mis en œuvre par des dispositifs distincts ; on entendra alors par serveur NTSS un système comprenant ces différents dispositifs.
Le serveur de redirection RB est conforme à l'invention. Il a ici l'architecture matérielle d'un ordinateur, telle que représentée sur la figure 2, et comporte un processeur 20, une mémoire vive de type RAM
21 et une mémoire morte de type ROM 22. Cette mémoire morte 22 constitue un support d'enregistrement conforme à l'invention, lisible par le serveur de redirection RB, et sur lequel est enregistré un programme d'ordinateur conforme à l'invention. Ce programme comporte des instructions pour l'exécution des étapes d'un procédé de redirection selon l'invention. Les principales étapes de ce procédé sont représentées, dans un mode particulier de réalisation de l'invention, sur les figures 3A-3D décrites ultérieurement (étapes FlO à F190).
Le serveur de redirection RB comprend également des moyens de communication 23 avec l'équipement terminal STB et avec les serveurs de diffusion NTSSk, mettant en œuvre le protocole RTSP dans l'exemple décrit ici.
Il comprend en outre des moyens d'interrogation et de mise à jour 24 de la base de sessions sDB. Ces moyens 24 sont également adaptés à interroger la base de topologie tDB.
La base de topologie tDB comprend, pour chaque serveur NTSSk :
- la capacité maximale de capture de flux de ce serveur, notée ICapMax(k), c'est-à-dire le nombre maximal de flux de données pouvant être capturés (i.e. enregistrés) simultanément par le serveur NTSSk. Cette capacité prend en compte les ressources de capture et de traitement mises en œuvre par le serveur NTSSk pour satisfaire des opérations de contrôle requises par un équipement terminal sur un flux déterminé ; et - la capacité maximale de sessions de diffusion de ce serveur, notée DCapMax(k), c'est-à-dire le nombre maximal de sessions de diffusion pouvant être gérées simultanément par ce serveur pour différents équipements terminaux. De façon connue, une session de diffusion inclut le flux diffusé entre le serveur de diffusion et un équipement terminal, ainsi que les flux de commande échangés entre l'équipement terminal et le serveur de diffusion et les flux de commande échangés entre le serveur de redirection et le serveur de diffusion. Cette capacité prend ainsi en compte les ressources de traitement et de diffusion mises en œuvre par le serveur NTSSk pour satisfaire des opérations de contrôle requises par un équipement terminal sur un flux déterminé. Les capacités ICapMax(k) et DCapMax(k) sont des données statiques, c'est-à-dire invariantes, qui dépendent des spécifications en termes de ressources du serveur NTSSk (ex. espace de stockage, performances du processeur, etc.). Elles peuvent varier d'un serveur NTSS à un autre.
Ces données statiques peuvent être provisionnées dans la base tDB ou être communiquées par les serveurs NTSSk au cours d'une phase préliminaire.
Dans l'exemple décrit ici, la base de topologie tDB comprend également, pour chaque serveur NTSSk, un paramètre de localisation de ce serveur. Ce paramètre de localisation est par exemple ici un identifiant
IDSub(k) du sous-réseau auquel appartient le serveur NTSSk dans le réseau de télécommunications 1, et plus précisément une adresse IP.
En variante, d'autres identifiants de sous-réseau peuvent être considérés, de même que d'autres paramètres de localisation (comme par exemple un paramètre d'identification de ligne CLID ou Calling Une IDentifier en anglais).
La base de sessions sDB comprend, à un instant donné :
- une liste de sessions courantes de capture de flux mises en œuvre par des serveurs NTSSk de l'ensemble 11 à cet instant ; et
- une liste de sessions courantes de diffusion gérées par des serveurs NTSSk de l'ensemble 11 à cet instant.
Chaque session courante de capture de flux est définie, dans la base sDB, par un triplet comprenant : - un identifiant du serveur NTSS réalisant la capture du flux ;
- un identifiant du flux capturé ;
- un indicateur de l'instant auquel a démarré cette capture du flux.
Chaque session courante de diffusion de flux est définie, dans la base sDB, par un triplet comprenant : - un identifiant du flux diffusé ;
- un identifiant du serveur NTSS réalisant le contrôle de cette diffusion ;
- un identifiant de l'équipement terminal ayant requis le contrôle.
Nous allons maintenant décrire, en référence aux figures 3A à 3D, les principales étapes du procédé de redirection selon l'invention, lorsqu'il est mis en œuvre, dans un mode particulier de réalisation, par le serveur de redirection RB représenté sur les figures 1 et 2. On envisage dans ce mode de réalisation, qu'un utilisateur U de l'équipement terminal STB souhaite accéder au service nTS dynamique proposé par l'opérateur du réseau de télécommunications 1, afin de mettre en œuvre des opérations de décalage temporel sur un flux de données multimédia FU reçu en temps réel par l'équipement terminal STB, par exemple une opération OP de retour en arrière (opération de contrôle au sens de l'invention).
En référence à la figure 3A, on suppose qu'à cette fin, l'utilisateur U s'est abonné préalablement à ce service auprès du serveur PORT, et que l'équipement terminal STB obtient l'autorisation d'accéder au service nTS dynamique, par exemple en s'authentifiant correctement auprès du serveur PORT.
On notera, que pour pouvoir bénéficier de ce service, l'équipement terminal STB se sera au préalable désabonné de la diffusion multicast du flux FL0 auprès du routeur ROUT.
En variante, un autre équipement du réseau, comme par exemple un dispositif DSLAM (Digital Subscriber Une Access Multiplexer) du réseau 1 connecté à l'équipement terminal STB, pourra être chargé de ce désabonnement. Pour accéder à l'opération OP de retour en arrière, l'utilisateur U appuie par exemple sur une touche correspondante d'une télécommande de l'équipement terminal STB, qui transmet la requête d'accès à l'opération OP de l'utilisateur U à l'équipement terminal.
Sur réception de cette requête d'accès (étape ElO), l'équipement terminal STB envoie au serveur de redirection RB une requête R_act(FI_o) d'initialisation d'une session de contrôle pour le flux de données FL0 (étape E20). Cette requête est une requête de contrôle au sens de l'invention.
La requête R_act(FI_o) est ici une requête RTSP comprenant un identifiant du flux FL0 (ex. une adresse IP multicast). Elle peut comprendre également la commande relative à l'opération de contrôle OP requise par l'utilisateur U sur le flux FL0- Toutefois, cette commande pourra être envoyée ultérieurement au serveur de redirection RB, une fois la session de contrôle établie (mode de réalisation décrit ici). Sur réception de la requête de contrôle R_act, le serveur RB sélectionne, selon des critères prédéterminés, un serveur NTSSRO parmi la pluralité 11 de serveurs de diffusion.
A cette fin, le serveur de redirection RB interroge dans un premier temps, à l'aide des moyens d'interrogation 24, la base de sessions sDB (étape FlO), de sorte à obtenir pour chaque serveur NTSSk :
- le nombre courant ICurr(k) de flux de données capturés simultanément par ce serveur à cet instant (i.e. nombre courant de sessions de capture) ; - le nombre courant DCurr(k) de sessions de diffusion gérées simultanément par ce serveur à cet instant ; et
- les identifiants des flux capturés par ce serveur.
Les nombres ICurr(k) et DCurr(k) sont calculés de façon connue par les moyens d'interrogation de la base de données sDB, à partir des informations de sessions de diffusion et de sessions de capture mémorisées dans cette base, à l'aide par exemple d'une requête d'interrogation appropriée évidente pour l'homme du métier.
Le serveur de redirection RB interroge également, au cours de cette étape, la base de topologie tDB pour obtenir, pour chaque serveur NTSSk, les capacités maximales ICapMax(k) et DCapMax(k).
A partir de ces informations, il évalue les valeurs de [ICapMax(k)-ICurr(k)] et de [DCapMax(k)-DCurr(k)], représentatives respectivement des capacités courantes de capture et de sessions de diffusion du serveur NTSSk, et plus généralement d'une capacité courante de contrôle de flux du serveur NTSSR. On notera que dans cet exemple, les capacités de capture et de sessions de diffusion sont exprimées sous la forme de nombres de flux, toutefois cette hypothèse n'est pas limitative, on pourrait par exemple exprimer ces capacités sous la forme de débits. Il en est de même bien entendu pour la capacité de contrôle de flux du serveur.
A l'aide de ces valeurs, le serveur de redirection constitue dans un second temps (étape F20), une liste L de serveurs NTSS candidats potentiels parmi les serveurs NTSSk, c'est-à-dire, qui sont aptes à capturer le flux de données FL0 et à établir une session de diffusion de ce flux de données pour l'équipement terminal STB (autrement dit encore, qui ont une capacité courante de contrôle de flux suffisante, par exemple non nulle).
Plus précisément ici, cette liste est constituée des serveurs NTSSk de la pluralité 11 de serveurs pour lesquels les conditions (1) ou (2) suivantes sont vérifiées :
Conditions (1) : un serveur est un candidat potentiel si il dispose d'une capacité courante de capture de flux et d'une capacité courante de sessions de diffusion suffisantes pour fournir le service (i.e. supérieures à des seuils prédéterminés, εl et ε2>0), par exemple ici si : [ICapMax(k)-ICurr(k)] > εl et [DCapMax(k) - DCurr(k)] > ε2
Conditions (2) : un serveur est un candidat potentiel si il dispose d'une capacité courante de session de diffusion suffisante pour fournir le service (i.e. supérieure à un seuil prédéterminé ε2) et si il capture déjà le flux FLo pour un autre équipement terminal, c'est-à-dire par exemple ici, si :
[DCapMax(k) - DCurr(k)] > ε2 et le serveur capture déjà le flux
FL0 pour un autre équipement terminal.
On notera que, pour un serveur vérifiant les conditions (2), une information représentative d'une capacité courante de capture de ce serveur au sens de l'invention peut être constituée de l'information selon laquelle ce serveur capture le flux requis par l'équipement terminal.
Dans l'exemple décrit ici, si la liste L ainsi obtenue comprend plusieurs serveurs NTSS candidats potentiels, le serveur de redirection RB sélectionne alors de préférence, dans l'ordre : - un serveur NTSSRO de cette liste capturant déjà le flux FL0 pour un autre équipement terminal ;
- le serveur NTSSRO de la liste le plus proche de l'équipement terminal STB dans le réseau 1.
Un serveur NTSS sera considéré ici comme étant le plus proche de l'équipement terminal STB s'il appartient au même sous-réseau dans le réseau 1 que l'équipement terminal STB. Pour déterminer ce serveur, le serveur de redirection RB extrait de la requête de contrôle R_act, l'adresse IP de l'équipement terminal STB (adresse transmise dans la requête de façon connue en soi) et la compare aux identifiants IDSub(k) des sous- réseaux des serveurs NTSSk de la liste L. Ces identifiants sont obtenus en interrogeant la base de topologie tDB à l'aide des moyens 24.
Bien entendu, d'autres identifiants pourraient être considérés.
En variante, lorsque la liste L comprend plusieurs serveurs NTSSk candidats potentiels, d'autres critères de sélection peuvent être utilisés pour sélectionner le serveur NTSSko-
Par exemple, il est possible de considérer un critère de partage de la charge (ou « load balancing » en anglais), consistant à sélectionner alternativement, pour différents équipements terminaux, les serveurs candidats potentiels de la liste. D'autres stratégies de partage de la charge peuvent bien sûr être considérées, comme la sélection du serveur capturant le moins de flux.
En variante, le serveur de redirection RB interroge également, au cours de cette étape, la base opérateur oDB pour obtenir le type d'enregistrement spécifié pour le flux de données objet de la requête de contrôle. De façon avantageuse, il pourra, lors de l'établissement de la liste L, privilégier, un serveur NTSSko de cette liste qui capture le flux FL0 de façon statique.
On suppose ici, que parmi la liste L, aucun des serveurs candidats potentiels ne capture déjà le flux FL0 pour un autre équipement terminal. On sélectionne alors le serveur NTSSko le plus proche de l'équipement terminal STB, comme décrit précédemment.
Ce serveur NTSSko ne capturant pas le flux FL0, le serveur de redirection RB envoie aux moyens ING du serveur NTSSω une requête RTSP de capture du flux de données FL0 (étape F30), notée ci-après
R_cap(FL-o).
Cette requête est traitée par les moyens ING, qui envoient alors une requête d'abonnement au flux FL0 au routeur ROUT (par exemple à l'aide du protocole IGMP), afin de bénéficier de la diffusion multicast du flux FL0 mise en œuvre par la tête de réseau HE (étape GlO).
En variante, pour bénéficier d'une diffusion de type unicast du flux FL0, une requête RTSP Setup ou HTTP Setup peut être envoyée à un équipement du réseau de type serveur ou proxy RTSP, ou respectivement à un équipement du réseau de type serveur ou proxy HTTP. Suite à cet abonnement, une session de capture du flux FL0 est initiée par les moyens ING (étape G20). Autrement dit, les moyens ING enregistrent le flux FL0, diffusé en temps réel en mode multicast par la tête de réseau HE, dans un buffer circulaire BUF associé au flux FL0.
Ils envoient ensuite un message RTSP d'acquittement ACK (ex. RTSP 200 OK) au serveur de redirection RB en réponse à la requête de capture R_cap(FU) (étape G30).
Sur réception de ce message d'acquittement, le serveur de redirection RB met à jour la base dynamique sDB (étape F40), avec comme nouvelle entrée, la session de capture du flux FL0 initiée par le serveur NTSSko. Comme mentionné précédemment, cette nouvelle session de capture est représentée dans la base dynamique sDB par :
- l'identifiant du serveur NTSSk0 ;
- l'identifiant du flux FL0 ; et
- un indicateur to de l'instant auquel a démarré la capture du flux.
On notera que si, au cours de l'étape F20, on sélectionne un serveur NTSSRO capturant déjà le flux FL0 pour un autre équipement terminal, les étapes F30 d'envoi d'une requête de capture au serveur NTSSk0, GlO d'abonnement du serveur NTSSk0, G20 d'initiation d'une session de capture du flux FL0, G30 d'envoi d'un message d'acquittement au serveur de redirection RB et F40 de mise à jour de la base de sDB ne sont pas mises en œuvre, le serveur NTSSko étant déjà abonné à la diffusion du flux FL0 et en cours d'enregistrement de ce flux.
Suite à la mise à jour de la base sdB, le serveur de redirection envoie à l'équipement terminal un message d'acquittement (ex. RTSP 200 OK), en réponse à la requête de contrôle R_act (étape F50). Une session de contrôle SESS est alors établie entre l'équipement terminal STB et le serveur de redirection RB (étape F60). L'établissement de cette session RTSP comprend la création d'un contexte (i.e. un ensemble de données) associé à cette session, et sauvegardé par exemple dans la base sDB. Un tel contexte contient notamment, de façon connue en soi, un identifiant de session, un identifiant de l'équipement terminal STB (ex. son adresse IP) et un identifiant du serveur NTSSko.
Suite à l'établissement de cette session, la requête de contrôle R_act envoyée par l'équipement terminal STB au serveur de redirection RB est redirigée par ce serveur vers les moyens de diffusion STR du serveur NTSSko, sous la forme d'une requête de contrôle RTSP R_act' (étape F70). Le serveur de diffusion NTSSko établit alors une session de diffusion pour le flux FL0 et l'équipement terminal STB (étape G40) et en informe le serveur de redirection RB (étape G50), qui met à jour la base dynamique sDB avec cette nouvelle session de diffusion (étape F80). Comme mentionné précédemment, cette nouvelle session de diffusion est représentée dans la base sDB par :
- l'identifiant du serveur NTSSRO ;
- l'identifiant du flux FL0 ; et
- l'identifiant de l'équipement terminal STB. On notera que la requête redirigée R_act' peut être identique à la requête de contrôle R_act, ou en variante, légèrement modifiée de sorte à intégrer notamment, des paramètres du serveur NTSSko tels que son adresse IP ou un numéro de port.
On notera également qu'afin de maintenir la session SESS entre l'équipement terminal STB et le serveur de redirection, celui-ci envoie périodiquement ici, à l'équipement terminal, des messages de maintien de la session (messages « keep-alive ») (étape F90). Pour cela, le serveur RB peut utiliser notamment le protocole RTSP, ou en variante le protocole SIP ou HTTP. Si aucune réponse de l'équipement terminal à ces messages n'est reçue dans un intervalle de temps prédéterminé suivant leur envoi, le serveur de redirection RB met fin à la session de contrôle SESS. Sinon, la session SESS est maintenue.
En variante, le serveur de redirection RB n'envoie pas de messages de maintien périodiques, mais c'est l'équipement terminal STB qui est à l'origine de ces messages. De façon similaire, si le serveur RB ne reçoit pas un tel message dans un intervalle de temps prédéterminé, alors il met fin à la session SESS établie avec l'équipement terminal STB.
En référence à la figure 3B, dans le mode de réalisation décrit ici, pour faciliter l'interaction de l'utilisateur U avec le service nTS dynamique, l'équipement terminal STB envoie une requête au portail PORT afin d'obtenir l'état du buffer BUF associé au flux FL0 (étape E30). Cette requête peut être notamment une requête HTTP ou SIP. On entend ici par état du buffer son taux de remplissage.
Ce taux de remplissage est calculé par le portail PORT à partir de l'instant de démarrage to de la session de capture du flux FL0 par le serveur NTSSRO, sous réserve bien sûr que le débit de remplissage des buffers par les serveurs NTSS et la taille de ces buffers soient connus (ce que l'on suppose ici).
L'instant de démarrage to est obtenu par le portail PORT en consultant la base sDB (étape HlO). Le serveur PORT envoie, en réponse à la requête de l'équipement terminal STB, le taux de remplissage ainsi calculé, par exemple sous la forme d'une barre de progression s'affichant sur l'écran de l'utilisateur U (étape H20) et mise à jour en temps réel.
En référence à la figure 3C, suite à l'établissement de la session SESS de contrôle, l'équipement terminal STB envoie au serveur de redirection RB une requête d'activation de l'opération OP (étape E40).
Dans l'exemple décrit ici, on suppose, comme mentionné précédemment, que cette opération OP est une opération de retour en arrière sur le flux
FL0 à un instant prédéterminé ti du flux, de sorte à revoir ce flux à partir de cet instant ti. Bien entendu, d'autres opérations de décalage temporel peuvent être requises, comme par exemple une opération de lecture, de pause, etc.
La requête d'activation, notée R(OP,FI_o) est une requête de contrôle au sens de l'invention et comprend l'opération OP souhaitée sur le flux FL0 ainsi que l'instant ti.
Sur réception de cette requête, le serveur RB interroge la base sDB (étape FlOO), pour déterminer si une session de contrôle est déjà établie avec l'équipement terminal STB pour le flux FL0-
Le cas échéant (par exemple ici la session SESS est établie), il identifie, à partir du contexte de cette session, le serveur NTSSko vers lequel rediriger les requêtes de contrôle et plus particulièrement d'activation d'opérations de décalage temporel durant le maintien de cette session (étape FIlO).
La requête R(OP,FI_o) est alors redirigée vers les moyens STR de ce serveur NTSSko sous la forme d'une requête R' (étape F120).
Dans le mode de réalisation décrit ici, au cours de l'étape FIlO, le serveur de redirection RB détermine également, en consultant la base de sessions sDB, l'instant de démarrage to de la session de capture du flux
FL0 par le serveur NTSSko, et calcule, à l'aide de cet instant, le taux de remplissage du buffer BUF associé à ce flux comme décrit précédemment. Le serveur RB vérifie ensuite si l'opération OP de retour en arrière à l'instant ti est permise. Si le serveur RB détecte que le taux de remplissage calculé n'est pas suffisant pour permettre l'opération OP requise par l'équipement terminal, alors, avant de rediriger la requête R vers le serveur NTSSRO, il remplace dans cette requête l'opération de contrôle OP par une opération de contrôle OP' autorisée, à savoir dans l'exemple décrit ici par une opération de pause à l'instant to. Ceci permet avantageusement d'éviter le rejet de la requête par le serveur NTSSko-
Cette requête est ensuite reçue et traitée par les moyens STR du serveur NTSSko (étape G60), qui diffusent vers l'équipement terminal le contenu requis du flux FL0 à partir du buffer BUF. Dans l'exemple décrit ici, une image figée du flux à l'instant to est ainsi diffusée vers l'équipement terminal STB (exécution de la commande OPO (étape G70).
Les différentes étapes décrites précédemment en référence à la figure 3C pour l'opération OP sont mises en œuvre pour chaque opération de contrôle requise ultérieurement par l'utilisateur U sur le flux FLo-
On notera, que lorsque l'opération de contrôle OP est comprise dans la requête R_act, les étapes de vérification et éventuellement de remplacement de l'opération requise par une opération autorisée sont mises en œuvre de façon similaire, avant la redirection de la requête de contrôle vers le serveur NTSSko-
Nous allons maintenant décrire, en référence à la figure 3D, les différentes étapes mises en œuvre lors de la fermeture des sessions établies pour le flux FL0 et l'équipement terminal STB. Ces fermetures de sessions peuvent être la conséquence de différents événements, comme par exemple :
- la fin du buffer circulaire BUF associé au flux FL0 peut être atteinte, suite à une opération de décalage temporel requise par l'équipement terminal. Dans ce cas, les moyens STR du serveur NTSSko stoppent la diffusion du contenu requis du flux FL0 vers l'équipement terminal et envoient un message RTSP indiquant la fin du buffer (message de type
« End of Buffer ») à l'équipement terminal (en variante un autre protocole applicatif peut être utilisé). Sur réception de ce message, l'équipement terminal STB envoie une requête R_stop(FI_o) de désactivation du contrôle au serveur de redirection RB (étape E50) ; - l'utilisateur U peut souhaiter interrompre manuellement la diffusion dans le cadre du contrôle du flux FL0 vers l'équipement terminal. Dans ce cas, l'équipement terminal STB, sur réception d'une commande de l'utilisateur (par exemple suite à l'appui par l'utilisateur U sur une touche de la télécommande de l'équipement terminal STB), envoie une requête R_stop(FI_o) de désactivation du contrôle au serveur de redirection RB (étape E50).
La réception de cette requête de désactivation par le serveur de redirection RB constitue en soi une détection d'un événement de désactivation du contrôle pour le flux de données FL0 pour l'équipement terminal STB au sens de l'invention.
Sur détection d'un tel événement, le serveur de redirection RB consulte la base dynamique sDB (étape F130), pour déterminer le nombre courant de sessions de diffusion établies par le serveur NTSSko pour le flux FL0, et ce, afin d'identifier si d'autres sessions de diffusion sont en cours au niveau du serveur NTSSko pour ce flux pour d'autres équipements terminaux.
Si on détermine (étape F140) que l'équipement terminal STB est le seul équipement terminal pour lequel une session de diffusion est en cours au niveau du serveur NTSSko pour le flux FL0, alors le serveur RB envoie aux moyens ING du serveur NTSSko une requête d'arrêt de la capture du flux FL0 (étape F150).
Sur réception de cette requête, les moyens ING arrêtent la capture du flux FL0 et envoient une requête de désabonnement de la diffusion du flux FL0 au routeur ROUT (étape G80). Si nécessaire, le buffer circulaire BUF associé au flux FL0 peut également être effacé.
Préférentiellement, l'arrêt de la capture du flux et l'envoi de la requête de désabonnement ne seront mis en œuvre qu'après un intervalle de temps prédéterminé pendant lequel aucune requête de l'équipement terminal STB n'a été reçue, de sorte à éviter notamment les redémarrages et arrêts intempestifs de capture du flux FLo au niveau du serveur NTSSko. Sur réception d'un message d'acquittement de cet arrêt émis par le serveur NTSSko (étape G90), le serveur de redirection met à jour la base sDB pour refléter la fermeture de la session de capture du flux FL0 par le serveur NTSSk0 (étape F160). II redirige également la requête d'arrêt R_stop(FI_o) envoyée par l'équipement terminal STB vers les moyens STR du serveur NTSSko (étape
F170), pour que ceux-ci ferment la session de diffusion associée au flux
FL0 et à l'équipement terminal STB, et arrêtent ainsi la diffusion du flux vers l'équipement terminal STB (étape GlOO).
Sur réception d'un message d'acquittement de cette fermeture émis par le serveur NTSSko (étape GIlO), le serveur de redirection met à jour la base sDB pour refléter la fermeture de la session de diffusion du flux FLo par le serveur NTSSko pour l'équipement terminal STB (étape F180). Le nombre courant DCurr(kO) de sessions de diffusion gérées par le serveur NTSSko est ainsi décrémenté de 1.
La session établie entre l'équipement terminal STB et le serveur RB est alors résiliée (étape F190) et l'envoi périodique des messages de maintien arrêté. On notera en outre que, dans le cas où une politique de l'opérateur a été définie pour spécifier un type d'enregistrement des flux de données diffusé par les chaînes de programme, le serveur de redirection RB consulte la base dynamique oDB correspondante et détermine si le flux de données concerné est capturé statiquement sur le serveur de diffusion NTSSko. Si c'est le cas, il n'émet pas de requête d'arrêt de capture à destination de ce serveur.
L'équipement terminal STB peut alors, si l'utilisateur U le désire, demander un nouvel état du buffer au portail PORT.
On notera que les sessions de diffusion et de capture, et la session de contrôle établie entre l'équipement terminal et le serveur de redirection peuvent également être interrompues du fait d'événements exceptionnels et inattendus. Par exemple :
- l'équipement terminal STB peut être éteint de façon inopinée. Dans ce cas, il ne peut plus répondre aux messages de maintien envoyés par le serveur de redirection RB. La non réception de ces messages constitue en soi un événement de désactivation du contrôle détecté par le serveur de redirection ;
- durant une session de diffusion, les moyens STR peuvent s'arrêter de diffuser les contenus requis du buffer BUF de façon inattendue. Dans ce cas, l'équipement terminal STB détecte la non réception de flux des moyens STR et envoie au serveur de redirection une requête de désactivation du contrôle ;
- durant une session de capture, les moyens ING peuvent s'arrêter inopinément de capturer le flux FL0. Dans ce cas, l'équipement terminal STB détecte un flux anormal émis par les moyens STR et envoie, après un intervalle de temps prédéterminé, une requête de désactivation du contrôle au serveur de redirection.
Par ailleurs, du fait d'un problème dans le réseau de télécommunications 1 ou d'un problème logiciel et/ou matériel, il se peut que l'enregistrement du flux FL0 par le serveur NTSSko sélectionné ne soit pas possible. Dans ce cas, le serveur NTSSko sélectionné envoie un message de non-acquittement (NACK) au serveur de redirection, qui peut soit sélectionner un autre serveur, soit refuser l'accès au service de contrôle nTS par l'équipement terminal STB pour ce flux. On notera, que dans le mode de réalisation décrit ici, les moyens mis en œuvre pour réaliser le procédé de redirection selon l'invention sont localisés sur un même dispositif (à savoir le serveur de redirection RB). En variante, ces moyens (et les fonctionnalités qui leur sont associées) pourraient être répartis sur différents équipements, par exemple sur le serveur de redirection RB et sur les serveurs de diffusion
NTSS.
Par ailleurs, de façon avantageuse, dans un autre mode de réalisation de l'invention, on pourra considérer également, en plus de la pluralité de serveurs de diffusion considérée précédemment réalisant une capture dynamique des flux, un ou plusieurs serveurs de diffusion additionnels adaptés à capturer statiquement (en permanence) une liste de flux prédéfinie. On pourra ainsi allouer par exemple à ces serveurs de diffusion additionnels, les flux les plus demandés par les abonnés, et rediriger systématiquement (par l'intermédiaire du serveur de redirection RB) vers ces serveurs les requêtes de contrôle émises par un équipement terminal relatives à ces flux (à condition bien sûr qu'ils ne soient pas congestionnés). Les serveurs de la pluralité de serveurs considérée précédemment pourront alors être utilisés soit pour capturer et diffuser les flux les moins demandés, soit en support des serveurs additionnels lorsque la capacité de ceux-ci s'avérera insuffisante.

Claims

REVEN DICATIONS
1. Procédé de redirection d'une requête de contrôle (R_act) d'un flux de données (FL0) diffusé par une source (HE) dans un réseau de télécommunications (1), émise par un équipement terminal (STB), ledit procédé étant caractérisé en ce qu'il comprend :
- sur réception de cette requête, une étape d'obtention (FlO) d'informations représentatives d'une capacité courante de contrôle de flux pour une pluralité (11) de serveurs de diffusion ; - une étape de sélection (F20), à l'aide au moins de ces informations, d'un serveur (NTSSko) parmi ladite pluralité de serveurs, apte à contrôler ledit flux (FL0) diffusé par la source ;
- une étape d'envoi (F30) d'une requête de capture (R_cap) de ce flux (FL0) au serveur sélectionné si celui-ci ne capture pas déjà ce flux de données pour au moins un autre équipement terminal ; et
- une étape de redirection (F70) de la requête de contrôle (R_act) vers le serveur sélectionné.
2. Procédé de redirection selon la revendication 1 caractérisé en ce que les informations représentatives d'une capacité courante de contrôle de flux de données par un serveur comprennent des informations représentatives :
- d'une capacité courante de sessions de diffusion de ce serveur ; et
- d'une capacité courante de capture de flux de ce serveur.
3. Procédé de redirection selon la revendication 1 caractérisé en ce que l'étape de sélection prend en compte un type de capture du flux de données pour au moins un serveur de diffusion, ledit type étant sélectionné parmi au moins un type de capture statique et un type de capture dynamique.
4. Procédé de redirection selon la revendication 1 caractérisé en ce qu'il comprend en outre, après l'étape de sélection, une étape d'établissement (F60) d'une session avec l'équipement terminal pour ce flux de données, et en ce que, durant le maintien de cette session, au moins une autre requête (R) de contrôle émise par l'équipement terminal (STB) pour ce flux de données est redirigée (F120) vers le serveur sélectionné (NTSSk0).
5. Procédé de redirection selon la revendication 1 caractérisé en ce que, au cours de l'étape de sélection (F20), le serveur est sélectionné en fonction également de sa proximité à l'équipement terminal.
6. Procédé de redirection selon la revendication 1 caractérisé en ce que, au cours de l'étape de sélection (F20), le serveur est sélectionné en fonction également de l'existence au niveau de ce serveur d'une capture du flux de données pour au moins un autre équipement terminal.
7. Procédé de redirection selon la revendication 1 caractérisé en ce qu'il comprend en outre : - une étape de détection d'un événement de désactivation du contrôle du flux de données pour l'équipement terminal ;
- une étape (F140) de détermination si le serveur sélectionné pour le flux de données pour l'équipement terminal capture ce flux de données pour au moins un autre équipement terminal ; - si ce n'est pas le cas, une étape d'envoi (F150) d'une requête de fin de capture de ce flux de données au serveur sélectionné.
8. Procédé de redirection selon la revendication 7, caractérisé en ce qu'il comprend en outre une étape de détermination d'un type de capture du flux de données, ledit type étant sélectionné parmi au moins un type de capture statique et un type de capture dynamique, et en ce que, si on détermine que la capture est de type statique, l'étape d'envoi (Fl 50) d'une requête de fin de capture n'est pas mise en œuvre.
9. Procédé de redirection selon la revendication 1, caractérisé en ce qu'il comprend, avant la redirection de la requête de contrôle du flux de données vers le serveur sélectionné :
- une étape de détection (FIlO) que la requête de contrôle comprend une opération de contrôle qui ne peut pas être mise en œuvre par le serveur sélectionné ; et - une étape de remplacement (F120), dans la requête de contrôle, de cette opération par une opération de contrôle autorisée.
10. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de redirection selon la revendication 1 lorsque ledit programme est exécuté par un ordinateur.
11. Dispositif (RB) de redirection d'une requête de contrôle d'un flux de données diffusé par une source (HE) dans un réseau de télécommunications (1), émise par un équipement terminal, ledit dispositif étant caractérisé en ce qu'il comprend en outre :
- des moyens d'obtention (21,24), activés sur réception de cette requête, d'informations représentatives d'une capacité courante de contrôle de flux, pour une pluralité de serveurs de diffusion ; - des moyens de sélection (21), à l'aide au moins de ces informations, d'un serveur parmi ladite pluralité de serveurs, apte à contrôler ledit flux (FL0) diffusé par la source ;
- des moyens pour déterminer (21,24) si le serveur sélectionné capture ou non ce flux de données (FL0) pour au moins un autre équipement terminal ;
- des moyens d'envoi (23) d'une requête de capture de ce flux de données au serveur sélectionné, activés si celui-ci ne capture pas déjà ce flux de données pour au moins un autre équipement terminal ; et
- des moyens de redirection de la requête de contrôle vers le serveur sélectionné.
12. Dispositif de redirection selon la revendication 11 caractérisé en ce qu'il comprend en outre, des moyens pour établir une session avec l'équipement terminal pour ce flux de données, lesdits moyens de redirection étant adaptés, durant le maintien de cette session, à rediriger au moins une autre requête de contrôle émise par l'équipement terminal pour ce flux vers le serveur sélectionné.
PCT/FR2009/051685 2008-09-08 2009-09-08 Procede et dispositif de redirection d'une requete de controle d'un flux de donnees WO2010026355A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP09741379A EP2332332A1 (fr) 2008-09-08 2009-09-08 Procede et dispositif de redirection d'une requete de controle d'un flux de donnees
US13/062,906 US8639777B2 (en) 2008-09-08 2009-09-08 Method and device for redirecting a data flow monitoring query

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0856022 2008-09-08
FR0856022 2008-09-08

Publications (1)

Publication Number Publication Date
WO2010026355A1 true WO2010026355A1 (fr) 2010-03-11

Family

ID=40404156

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/051685 WO2010026355A1 (fr) 2008-09-08 2009-09-08 Procede et dispositif de redirection d'une requete de controle d'un flux de donnees

Country Status (3)

Country Link
US (1) US8639777B2 (fr)
EP (1) EP2332332A1 (fr)
WO (1) WO2010026355A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9927788B2 (en) * 2011-05-19 2018-03-27 Fisher-Rosemount Systems, Inc. Software lockout coordination between a process control system and an asset management system
CN102438170B (zh) * 2011-09-28 2014-01-29 深圳市龙视传媒有限公司 应用于广电网络中的音视频业务点播方法、系统及装置
US8825779B2 (en) * 2012-02-02 2014-09-02 Dialogic, Inc. Systems and methods of real-time data subscription and reporting for telecommunications systems and devices
US9565576B2 (en) * 2013-10-09 2017-02-07 At&T Intellectual Property I, L.P. Network operating system client architecture for mobile user equipment
CN105100887A (zh) * 2014-05-15 2015-11-25 中兴通讯股份有限公司 节目播放控制方法及装置
US10540237B2 (en) 2015-09-16 2020-01-21 Sesame Software, Inc. System and method for procedure for point-in-time recovery of cloud or database data and records in whole or in part

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7017174B1 (en) * 2001-07-30 2006-03-21 Digeo, Inc. Methods and apparatus for providing a central recorder in a broadcast system
WO2006103223A1 (fr) * 2005-03-30 2006-10-05 Nokia Siemens Networks Gmbh & Co. Kg Procede et systeme pour stocker et lire des emissions tv
EP1768347A1 (fr) * 2005-09-21 2007-03-28 Alcatel Appareil d'enregistrement de programmes diffusés
EP1962508A2 (fr) * 2007-02-20 2008-08-27 Sony Corporation Système de réseau, contrôleur, dispositif d'enregistrement, serveur de services, procédé d'acquisition de statut de ressources du dispositif d'enregistrement et programme informatique

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6412015B1 (en) * 1998-06-24 2002-06-25 New Moon Systems, Inc. System and method for virtualizing and controlling input and output of computer programs
US6658473B1 (en) * 2000-02-25 2003-12-02 Sun Microsystems, Inc. Method and apparatus for distributing load in a computer environment
CN1419369A (zh) * 2001-06-29 2003-05-21 松下电器产业株式会社 数据重放装置及数据中继装置
JP2004056394A (ja) * 2002-07-18 2004-02-19 Fujitsu Ltd Ｌａｎを介して取込装置および蓄積装置を制御するための制御装置、およびそのための取込装置、蓄積装置、プログラムおよび方法
FR2890816A1 (fr) * 2005-09-09 2007-03-16 France Telecom Procede de gestion optimisee de ressources dans un terminal muni d'interfaces multiples
US7934216B2 (en) * 2005-10-03 2011-04-26 International Business Machines Corporation Method and system for load balancing of computing resources
KR20080101615A (ko) * 2007-05-15 2008-11-21 삼성전자주식회사 이동 통신 시스템에서 방송 서비스를 위한 컨텐츠 제공장치 및 방법
US8352542B2 (en) * 2008-09-08 2013-01-08 Seachange International, Inc. Method and system for providing an interactive application over a network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7017174B1 (en) * 2001-07-30 2006-03-21 Digeo, Inc. Methods and apparatus for providing a central recorder in a broadcast system
WO2006103223A1 (fr) * 2005-03-30 2006-10-05 Nokia Siemens Networks Gmbh & Co. Kg Procede et systeme pour stocker et lire des emissions tv
EP1768347A1 (fr) * 2005-09-21 2007-03-28 Alcatel Appareil d'enregistrement de programmes diffusés
EP1962508A2 (fr) * 2007-02-20 2008-08-27 Sony Corporation Système de réseau, contrôleur, dispositif d'enregistrement, serveur de services, procédé d'acquisition de statut de ressources du dispositif d'enregistrement et programme informatique

Also Published As

Publication number Publication date
US8639777B2 (en) 2014-01-28
US20110167138A1 (en) 2011-07-07
EP2332332A1 (fr) 2011-06-15

Similar Documents

Publication Publication Date Title
EP2025181B1 (fr) Systeme d'acces a un service de television sur ip dans un reseau a architecture ims
EP1964313B1 (fr) Procédé de transmission de services de télévision numérique, passerelle et réseau correspondants
EP2163065B1 (fr) Basculement de session audiovisuelle d'un premier réseau d'accès vers un deuxième réseau d'accès
RU2647654C2 (ru) Система и способ доставки аудиовизуального контента в клиентское устройство
WO2015101782A1 (fr) Acheminement de contenu
EP2412141A1 (fr) Procede et dispositif de traitement d'une information indicatrice d'un souhait d'implication dans au moins une session applicative d'un utilisateur
WO2010026355A1 (fr) Procede et dispositif de redirection d'une requete de controle d'un flux de donnees
EP3053303A1 (fr) Procede d'abonnement a des flux en provenance de clients multicast
EP3646196B1 (fr) Procédé et dispositif de téléchargement de contenu audiovisuel
FR2933213A1 (fr) Methode d'affichage d'interface utilisateur et methode d'emission correspondante
EP2556646B1 (fr) Technique de contrôle d'accès a un flux de données diffusé
EP3149918B1 (fr) Téléchargement de contenu et mise a disposition de réseaux
EP2589202B1 (fr) Procédé et système de gestion de sessions de communication
EP2266279B1 (fr) Partage de contenu multi supports a partir d'une communication audio-video
EP2055042A2 (fr) Mecanisme pour la gestion de connexions de recepteurs / decodeurs
FR3054765B1 (fr) Procede pour la lecture sur un equipement d'un contenu multimedia avec un retard cible par rapport au direct inferieur a un retard maximal donne
FR3138020A1 (fr) Streaming vidéo adaptatif hybride amélioré
WO2018002469A1 (fr) Procédé et dispositif de gestion d'une session de transmission d'un flux vidéo
FR3019429A1 (fr) Procede et dispositif de controle d'un telechargement de contenus multimedia
EP2553900B1 (fr) Transmission de flux de données adaptable
WO2010112738A1 (fr) Procede d'envoi d'un message de notification, serveur de sessions d'acces et systeme de communications
EP2854367A1 (fr) Procédé de traitement d'une requête de livraison d'un flux de données, procédé de gestion de ressources de livraison, dispositifs et programme d'ordinateur associés
FR2973633A1 (fr) Restitution en differe de donnees.
FR2908951A1 (fr) Procede de modification de l'ensemble des flux recus par un dispositif sur un reseau

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09741379

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13062906

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2009741379

Country of ref document: EP