WO2010044731A1 - Methods and arrangements for an ip tv network - Google Patents

Methods and arrangements for an ip tv network Download PDF

Info

Publication number
WO2010044731A1
WO2010044731A1 PCT/SE2009/051147 SE2009051147W WO2010044731A1 WO 2010044731 A1 WO2010044731 A1 WO 2010044731A1 SE 2009051147 W SE2009051147 W SE 2009051147W WO 2010044731 A1 WO2010044731 A1 WO 2010044731A1
Authority
WO
WIPO (PCT)
Prior art keywords
session
request
controller
user equipment
media server
Prior art date
Application number
PCT/SE2009/051147
Other languages
French (fr)
Inventor
Jan Erik Lindquist
Mats Cedervall
David Crick
Niklas Fondberg
Fredrik Persson
Original Assignee
Telefonaktiebolaget L M Ericsson (Publ)
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 Telefonaktiebolaget L M Ericsson (Publ) filed Critical Telefonaktiebolaget L M Ericsson (Publ)
Publication of WO2010044731A1 publication Critical patent/WO2010044731A1/en

Links

Classifications

    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1046—Call controllers; Call servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H04N21/25816—Management of client data involving client authentication
    • 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/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • 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/64—Addressing
    • H04N21/6408—Unicasting
    • 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/643—Communication protocols
    • 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/643—Communication protocols
    • H04N21/64322—IP
    • 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/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • 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
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests

Definitions

  • the present invention generally relates to the field of an IPTV network, and in particular to management of unicast sessions.
  • IPTV Internet Protocol Television
  • IP network such as e.g. a broadband access network.
  • the predominant IPTV service is linear, or scheduled, TV, in which normal non-IPTV channels, as well as additional channels having a low penetration among the potential users, are transmitted over the broadband network from a super head-end on the server side, to User Equipments (UEs), such as e.g. STB enabled TV sets (STB/TV), or any other type of user equipments that have been provided with STB functionality.
  • UEs User Equipments
  • STB/TV STB enabled TV sets
  • IPTV services In addition to broadcasted IPTV services, many new IPTV services, such as e.g. Personal Video Recorder in the Network (NPVR), Video on Demand (VoD), TVof Yesterday, and pause live TV, are distributed to the end-users via unicast.
  • NPVR Personal Video Recorder in the Network
  • VoD Video on Demand
  • TVof Yesterday TVof Yesterday
  • pause live TV e.g.
  • IPTV services delivered via unicast allows more sophisticated features to be offered to the end-users, but raises also a demand for more complicated techniques for setting up and maintaining a session. Therefore, throughout this document, the term IPTV services is consequently to be interpreted to comprise IPTV unicast services.
  • Open IPTV Forum is a new standard which defines, or references to, procedures and protocols that are applicable for this type of services. A simplified, prior art system, adapted to provide IPTV services to end-users may be described according to figure 1.
  • a UE 100 which may typically be e.g. a STB (set-top-box)/TV, is connected to an IP-based network 101, via an access network 102 and an IP Edge 103.
  • the IP network 101 enables UEs, such as a UE denoted 100, to connect to a controller 104 and to one or more media servers (MS) 105a,b,c, of the IP-based network 101, each of which provides one or more IPTV services to the end-users and their respective UE.
  • MS media servers
  • a typical system comprises a plurality of UEs, and that a UE may be able to access a plurality, even a large number, of different media servers, each of which may offer different types of IPTV services to the end-users.
  • figure 1 only comprises one UE 100 and three MSs 105a,b,c.
  • the unicast IPTV services mentioned above are different in nature, compared to the broadcasted IPTV services, and the different IPTV services are usually also using different setup and control procedures.
  • the content to be played out on a UE is normally a combination of a movie, typically provided as a plurality of separate movie parts, and one or more advertisement parts, that have been clipped in between the movie parts.
  • These parts are normally put together by the controller, that usually has access to pre-defined end-user preferences for certain types of advertisements, in a list, typically referred to as a playlist, where such a playlist may comprise one or more movies and one or more advertisements, listed in a certain order.
  • UEs When applying pause live TV, media content that is captured from a real-time stream does not fully exist when a setup is performed between a UE and an MS. Such a situation may typically give rise to several problems. Both UEs, as well as MSs, such as e.g. video servers, do for example become more difficult to integrate, because of the complexity associated with having to maintain two connections throughout a session, namely one connection between the UE and the controller, acting a first server, and another connection between the UE and the media server, acting as a second server, where different commands will be addressed to the first or the second server, respectively.
  • MSs such as e.g. video servers
  • FIG. 2 illustrates that a UE 100 initiates two sessions Sl, S2 (also referred to as connections) one with a media server 105 and one with a controller 104.
  • an end-user having access to a number of IPTV services, or programs, from a MS 105, such as e.g. a video server, via an IPTV enabled UE 100, and a controller 104, has accessed a content list, e.g. via a browser, or after activation of native local code of UE 100, and that the end-user has chosen a specific, required IPTV service from the content list.
  • a MS 105 such as e.g. a video server
  • a controller 104 has accessed a content list, e.g. via a browser, or after activation of native local code of UE 100, and that the end-user has chosen a specific, required IPTV service from the content list.
  • a first step 2:1 an end-user (UE) initiates a request for the selected IPTV service from an MS 105, by forwarding an RTSP setup, to a controller 104.
  • the requested IPTV service is typically indicated in a service offering, here referred to as URL 1, of the RTSP setup forwarded in step 2:1.
  • the service offering also comprise additional information, such as e.g. the x-client extension header, which helps to identify the end-user and the MAC address of UE 100 in one or more extension headers.
  • the controller 104 performs an asset control, i.e. determines which assets that are available from MS 105.
  • Assets may comprise e.g. one or more films, selected by the end-user, and indicated in the service offering, as well as one or more advertisement that may be predestined to be provided to the end-user, together with the selected IPTV service content.
  • Such information may be obtained from a storage means of controller 104, during the asset control.
  • a playlist typically comprising one or more films and one or more advertisements, is specified, such that e.g. one or more specific advertisements will be delivered to the end-user, together with a specific film or group of films, in a predefined order.
  • a subsequent step 2:3 the controller 104 issues a request, comprising the play list, requesting MS 105 to create, or set up, a session with UE 100, for enabling delivery of the content of the playlist, previously created by the controller 104 in step 2:1.
  • the MS 105 creates a second URL, URL 2,that comprises an address to the MS 105, such that the UE 100 will be able to communication with the MS 105.
  • URL 2 is returned to the controller 104, and in another step 2:6, the controller 104 responds to the RTSP setup of step 2:1 with forwarding a response message, pointing to URL 2, to UE 100.
  • the response message is transmitted to UE 100 as a 200 OK message.
  • a 200 OK message comprises data and constitutes also an acknowledgement.
  • a first connection here referred to as Sl
  • a second connection S2 will be used for the communication between UE 100 and MS 105, that is associated with the created session.
  • the UE 100 may forward additional commands to the controller 104 via one session Sl and to MS 105 via the other session S2, depending on the required task to be executed.
  • the end-user may e.g. at any occasion choose to pause the watched movie. This is done in a next step 2:9, and it is normally verified by the MS 105 with a 200 OK, referred to as step 2:10.
  • the end-user may initiate such a command, and the UE 100 will accordingly instruct the MS 105 to terminate the present IPTV service, typically by transmitting an RTSP Teardown request to the controller 104 via session Sl, referred to as step 2:11, whereby the controller 104, transmits a corresponding request, here a destroy stream request, to the MS 105, instructing the MS 105 to terminate the IPTV service, as a final step 2:12.
  • two connections, sessions Sl and S2 are required for enabling an end-user to maintain a session between the UE 100 and the MS 105, such that an IPTV service provided from the MS 105, can be consumed at a UE 100, while allowing the controller 104 to control the delivery of the IPTV service.
  • a rather complex configuration will be required at the UE 100 as explained below.
  • figure 2 is showing one possible solution for handling two different connections, Sl and S2 associated with a session that have been set up e.g. according to the example described above, may be handled, where the UE 100 have to set up a first connection, Sl, with a controller 104, and a second connection, S2, with a certain, selected MS 105, in order to enable a required IPTV service to be selected by an end-user and delivered to the UE 100.
  • An RTSP Proxy 300 may enable the UE 100 to communicate with a controller 104 and a MS 105, via a connection SO (not shown), such that from the perspective of the UE, only one connection is required, while the RTSP Proxy 300 will be handling the connections Sl and S2.
  • the controller may act as an RTSP Proxy.
  • RTSP Proxy a severely increased load at the controller, but also in a delay for all RTPS traffic.
  • keep alive messages also referred to as heartbeats
  • heartbeats over connection Sl
  • the keep alive messages affect the dimensioning of the controller and requires additional hardware to manage the extra load.
  • the MS 105 instead of the controller 104, control the session with the UE and omit the session between the UE and the controller.
  • the UE is thereby sending the keep alive messages to the MS, but that would not imply a troublesome load on the MS, since the keep alive messages are regular RTSP requests with an empty body.
  • aTSP request like pause, fastforward can replace the RTSP keep alive messages.
  • a method in a controller (402) for controlling an IPTV unicast session from a media server to a user equipment is provided.
  • a request for an IPTV session (Sl) set-up between the user equipment and the controller is received.
  • a session (Sl) allocation at said media server is requested in response to receiving said request and a pointer pointing towards a new session (S2) to be allocated between the user equipment and the media server is received from said media server 401.
  • a session dependent URL URL2
  • a redirect command is sent to said user equipment towards the session dependent URL (URL2) thereby enabling the user equipment to cancel the allocated session (Sl) between the user equipment and the controller and to set up the new session (S2) towards the media server such that the media server controls the IPTV unicast session between the user equipment and the media server.
  • URL2 session dependent URL
  • a method in a media server for providing an IPTV unicast session to a user equipment is provided.
  • a request, from a controller, for a session (Sl) between a controller and the user equipment is received.
  • the session (Sl) is allocated in response to said request.
  • a pointer, pointing towards a new session (S2), to said controller 401 is provided to the controller thereby enabling the controller to obtain, on the basis of said pointer, a session dependent URL (URL 2), and to send a redirect from the session between the user equipment and the controller to the new session by using the session dependent URL (URL2) to said user equipment.
  • a request is received for the new session from the user equipment indicated by the session dependent URL, and the requested session is allocated, thereby allowing the media server to control the IPTV unicast session.
  • a controller for controlling an IPTV unicast session from a media server to a user equipment comprises a communication unit.
  • the communication unit is configured to receive from the user equipment a request for an IPTV session (Sl) set-up between the user equipment and the controller, to request a session allocation at said media server in response to receiving said request, and to receive, from said media server, a pointer pointing towards a new session (S2) to be allocated between the user equipment and the media server.
  • the controller further comprises a generating unit for obtaining, on the basis of said pointer, a session dependent URL (URL2), wherein the communication unit is further configured to send to said user equipment a redirect command towards the session dependent URL (URL2).
  • the user equipment is thereby enabled to cancel the allocated session (Sl) between the user equipment and the controller and to set up the new session (S2) towards the media server such that the media server controls the IPTV unicast session between the user equipment and the media server.
  • a media server for providing an IPTV unicast session to a user equipment.
  • the media server comprises a communication unit for receiving, from a controller, a request for a session (Sl) between a controller and the user equipment and a processing unit for allocating the session (Sl) in response to said request.
  • the communication unit is further configured to provide a pointer, pointing towards a new session S2, to said controller, thereby enabling the controller to obtain, on the basis of said pointer, a session dependent URL (URL 2), and to send a redirect from the session between the user equipment and the controller to the new session by using the session dependent URL (URL2) to said user equipment.
  • the communication unit is further configured to receive a request for the new session from the user equipment indicated by the session dependent URL, and the processing unit is further configured to allocate the requested session, thereby allowing the media server to control the IPTV unicast session.
  • An advantage with embodiments of the present invention is that they facilitate retrieval over the javascript API of the second URI.
  • the URI includes the sessionld that identifies the session created over ISA.
  • the information is available in local code within the STB but is not available in the browser (refer to OIPTVF contribution).
  • a further advantage with embodiments of the present invention is that the same procedure can be used for both an IMS (managed) and non-IMS (non-managed or open internet) IPTV (refer to OIPTVF contribution).
  • a further advantage is that it is possible to have only one session setup at the time by using messages of existing standard and protocols. This is a difference from prior art where two sessions were required, one towards the controller and one towards the MS (refer to Plain IPTV STB Interface Specification). By using the RTSP redirect request (moved) it is possible to have a unified session setup.
  • An advantage with the present invention is that the reduced load on the controller provides free processing capacity and allows the controller to be used in a more optimal way.
  • bookmarks are handled correctly in relationship to the session that is setup towards the MS.
  • IMS Session Initiation Protocol
  • RTSP non-IMS
  • FIG. 1 is a simplified system overview of a prior art system for providing IPTV services to end users.
  • FIG. 2 is a simplified illustration of a user equipment configuration comprising an RTSP proxy, according to the prior art.
  • FIG. 3 is a signaling scheme illustrating a procedure for setting up an IPTV session, according to one embodiment.
  • FIG. 4 is another signaling scheme illustrating a procedure for setting up an IPTV session, according to another embodiment.
  • FIG. 5 is a flow chart illustrating method steps to be executed at a controller when setting up an IPTV unicast service session, according to one exemplified embodiment.
  • FIG. 6 is another flow chart illustrating method steps to be executed at a media server when setting up an IPTV unicast service session, according to one exemplified embodiment.
  • FIG. 7 is a block scheme illustrating a controller that is configured to apply the method described with reference to figure 5.
  • FIG. 8 is another block scheme illustrating a media server that is configured to apply the method described with reference to figure 6.
  • the basic concept of the present invention is to provide a solution for setting up an IPTV unicast session between a UE, e.g. a STB, and an MS, wherein the session between the UE and the controller is avoided.
  • a UE e.g. a STB
  • MS is allowed to keep the control of the UE instead of the controller which implies that the keep alive messages are sent from the UE to the MS instead of, to the controller. Therefore the load of the controller is reduced.
  • FIG. 3 is a signalling diagram that illustrates one way of executing the suggested session set up procedure by setting up an IPTV session between a UE 400 and a MS 401, via a Controller 402, when content on demand, such as e.g. VoD, is applied.
  • content on demand such as e.g. VoD
  • an end-user requesting for an IPTV unicast service in this case a content on demand service, initiates a procedure for setting up a session Sl between the UE and the controller by first transmitting a set up request to the controller 402.
  • the setup request which in the present case is an RTSP setup request comprising a service offering indicated as URL 1 in figure 3, corresponds to a conventional set up command. In the present content on demand case this is typically done by transmitting an RTSP Setup.
  • a conventional asset control is performed on the service offering, as indicated in a step 4:2.
  • a playlist typically comprising one or more films and one or more advertisements, is specified, such that e.g. one or more specific advertisements will be delivered to the end-user, together with a specific film or group of films, in a predefined order.
  • the controller 402 issues a request, comprising the play list, requesting MS 401 to create, or set up, a session with UE, for enabling delivery of the content of the playlist, previously created by the controller 402 in step 4:2.
  • the MS 401 responds to this request by allocating a session Sl and stores the playlist. Further a first session Sl is allocated between the UE in step 4:4.
  • the MS response is transmitted to the controller 402, comprising a pointer also referred to as a stream ID, as indicated with a subsequent step 4:5.
  • a session dependent URL, URL 2 is created on the basis of the stream ID in the response, as indicated with a step 4:6.
  • the URL 2 is created at the MS 401, and if so the URL 2 is provided to the controller 402 in the response instead of the stream ID.
  • the controller 402 initiates a temporary remove of session Sl by executing a redirect, comprising the session dependent URL, URL 2, towards the UE 400.
  • the URL 2 is stored at a storage means for later retrieval, as indicated with another step 4:8.
  • Session 1 is now removed and a new session S2 has to be established. Although if Session 1 between the UE and the controller is removed, the controller is still responsible for creating sessions.
  • the new session S2 is set up between the UE and the MS by the UE 400 transmitting another RTSP setup, to the MS 401.
  • This setup do however comprise the URL 2, which initiates a process for verifying the session, i.e. to verify that the URL 2 is actually associated with a session, as indicated with another step 4:10. If successfully verified, the MS 401 responds to the setup request in a subsequent step 4:11, typically via a 200 OK message.
  • S2 One single connection, here referred to as S2, has now been established between the UE 400 and the MS 401, and the end-user may now at any time decide to start a required service.
  • a request to start playing a requested IPTV service is initiated by the end-user, by transmitting such a request, in this case an RTSP Play request, comprising URL 2, to the MS 401.
  • the requested service is delivered to the UE 400 by the MS by using the stored playlist, as indicated with another step 4:15.
  • the UE will send keep alive messages to the MS continuously, indicating that the session is to be maintained by the MS. If the keep alive messages fail (i.e. is not received by the MS) then the MS will assume that the resources provided by the MS are no longer required by the UE.
  • the keep alive messages are an integral part of RTSP implying that any RTSP message is considered as a form of keep alive message. So a pause request will have the same effect as a keep alive.
  • Subsequent commands initiated from UE 400 by the end-user may then be performed in a similar manner.
  • a procedure for terminating the session is initiated and performed as indicated with steps 4:16-4:18.
  • a request to terminate the session is initiated from UE 400, by transmitting a RTSP teardown to MS 401, as indicated with a step 4:17.
  • the controller 402 is notified of the upcoming session termination in a step 4:19, after which controller 402 requests for the session to be terminated in a next step 4:20, in this case by transmitting a Destroy stream request.
  • the session is then removed.
  • a corresponding session setup may be performed also if instead a download IPTV session set up is requested by means of HTTP instead of RTSP.
  • a setup procedure may typically be initiated with transmitting a HTTP GET, in an initial step 5:1.
  • the HTTP method is very similar to the above described RTSP solution except for that a silent notification is sent in step 5:17 to the controller and a destroy stream may be sent in step 5:18. Therefore, the remaining steps are not further described.
  • the method exemplified above only requires first one session Sl and then one session S2 for setting up a connection with a media server, and for subsequently enabling an end-user to initiate and consume the IPTV services.
  • the UE engaged in an IPTV session will not require any RTSP Proxy, or equivalent adaptation, that has to keep track of two simultaneous sessions, and, thus, a UE that is less complex than prior art solutions may be used.
  • the UE e.g. a STB, comprises a browser and a client, wherein client software is running under the browser.
  • the JavaScript in the browser page sets the "data" property of the A/V scriptable Object to a first URL, URL 1, to play.
  • the JavaScript calls the play method with the speed parameters set to 0 (pause).
  • the play method of the client software is called. This is done to ensure that everything is ready in the client before step 14 is performed.
  • the Client software may send an RTSP DESCRIBE to the IPTV controller containing said URL, URL 1, user identities, STB identity, e.g. MAC, and IP address.
  • the client SW sends an RTSP SETUP to the IPTV controller, containing the first URL, URL 1, and zero or more extensions headers, e.g. the x-client extension header.
  • the x-client helps identify the user and the MAC address of the STB. This information is used by the IPTV controller to perform asset control, meaning which assets are available to the particular user on the particular STB.
  • a first session Sl is setup between the client and the controller. This step corresponds to step 4:1 in figure 3.
  • the IPTV controller issues one or several ISA methods on the media server in order to setup the media session. This step corresponds to step 4:3 in figure 3.
  • the media server returns a stream ID.
  • the stream ID is used when the URL 2 is created. This step corresponds to step 4:5 in figure 3.
  • the IPTV controller creates URL 2 based on the received stream ID and responds to the setup with a redirect message comprising URL2. This implies that session 1 is cancelled and a new session will be setup between the client and the media server.
  • the stream ID may be exemplified as 3535252 while a URL may have the format like RTSP://192.158.3.2/3535252. This step corresponds to step 4:7 in figure 3.
  • the Client SW may send an RTSP DESCRIBE to the Media Server containing the second url, URL 2.
  • the client SW sends an RTSP SETUP to the Media Server, containing the second URL, URL 2 to setup a new session. This step corresponds to step 4:9 in figure 3.
  • the client software sends an RTSP Play to the Media Server. At this stage the client and the media server are ready to start playing the content. 16. A 200 OK is returned. After this step the stream will be delivered to the
  • the UE will keep sending keep alive messages to the MS.
  • the embodiments of the present invention also relates to a method and arrangement for jumping to a bookmark.
  • session 1 between the UE and the controller is cancelled, it is no longer possible to prior art methods for distinguishing between multiple sessions between the UE and the MS.
  • Multiple sessions occurs if the UE comprises multiple STBs, wherein each STB has an individual session towards the MS. 17.
  • the javascript code in the UE reads the second URL, URL 2, from the data property (or equivalent property) which contains the sessionld in the URL 2. Without the second URL it is not be possible to differentiate different sessionld's towards the MS, since the URLs are unique per created session.
  • the URLs are not shared between different users.
  • the browser javascript code makes a webservice (json) request towards the IPTV controller containing at least the user credentials, MAC address, IP address and the second URL which was retrieved in the previous step.
  • the IPTV controller returns at least one bookmark position, wherein the position may be adapted due to inserted commercials.
  • the browser javascript code calls a seek method, which resides in the browser to jump between positions, to jump to the bookmarked position.
  • the client software sends an RTSP play to the Media Server, indicating the new play position, i.e. the bookmarked position.
  • a 200 OK is returned comprising the media.
  • An onStatusChange event may be triggered in the browser to indicate that things are going ok.
  • the javascript code running on the browser of the STB can read the second URL, URL 2, with the sessionld information. This information can then be used in step 18 to get the appropriate the bookmark.
  • the suggested method is applicable also for other protocols, such as e.g. the HTTP protocol, where e.g. the initial setup request, represented by an RTSP setup request in the example, is replaced by a HTTP GET request.
  • the suggested session set up mechanism may comprise the series of steps which will now be described with reference to figure 6.
  • a request for an IPTV session (Sl) set-up between the user equipment and the controller is received at the communication unit 801.
  • a session (Sl) allocation at said media server is requested in step 602(4:3) in response to receiving said request by said communication unit 801 and a pointer pointing towards a new session (S2) to be allocated between the user equipment and the media server is received in step 603(4:5), at the communication unit 801 from said media server 401.
  • a session dependent URL (URL2) is obtained in step 604(4:6) by a generating unit 803.
  • a redirect command is sent in step 605(4:7) to said user equipment towards the session dependent URL (URL2) thereby enabling the user equipment to cancel the allocated session (Sl) between the user equipment and the controller and to set up the new session (S2) towards the media server such that the media server controls the IPTV unicast session between the user equipment and the media server.
  • URL2 session dependent URL
  • the MS will be able to control services provided via the session, while the session between the controller and UE can be cancelled and hence reduce the load on the controller.
  • the suggested session set up mechanism may comprise the series of steps which will now be described with reference to figure 7.
  • a request, from a controller, for a session (Sl) between a controller and the user equipment is received at the communication unit 901.
  • the session (Sl) is allocated by a processing unit in response to said request.
  • a pointer, pointing towards a new session (S2), to said controller 401 is provided by the communication to the controller thereby enabling the controller to obtain, on the basis of said pointer, a session dependent URL (URL 2), and to send a redirect from the session between the user equipment and the controller to the new session by using the session dependent URL (URL2) to said user equipment 400.
  • URL 2 session dependent URL
  • a request is received for the new session from the user equipment indicated by the session dependent URL, and the requested session is allocated in step 705(4:10) by the processing unit 900, thereby allowing the media server to control the IPTV unicast session.
  • the controller 402 comprises a communication unit 801.
  • the communication unit 801 is configured to receive from the user equipment a request for an IPTV session (Sl) set-up between the user equipment 400 and the controller 402, to request a session allocation at said media server 401 in response to receiving said request, and to receive, from said media server 401, a pointer pointing towards a new session (S2) to be allocated between the user equipment and the media server.
  • Sl IPTV session
  • the controller further comprises a generating unit 803 for obtaining, on the basis of said pointer, a session dependent URL (URL2), wherein the communication unit 803 is further configured to send to said user equipment 400 a redirect command towards the session dependent URL (URL2).
  • the user equipment 400 is thereby enabled to cancel the allocated session (Sl) between the user equipment and the controller and to set up the new session (S2) towards the media server such that the media server controls the IPTV unicast session between the user equipment and the media server.
  • the controller 402 further comprises a database for storing e.g. session information, URL 2, and other related asset information.
  • a controlling unit is also provided for controlling the UE during session Sl .
  • a MS that is configured to interact with a UE and a controller in such a way that the suggested session set up procedure can be applied will now be described in more detail with reference to figure 9.
  • the media server 401 comprises a communication unit 901 for receiving, from a controller, a request for a session (Sl) between a controller and the user equipment and a processing unit 900 for allocating the session (Sl) in response to said request.
  • the communication unit 901 is further configured to provide a pointer, pointing towards a new session S2, to said controller 401, thereby enabling the controller to obtain, on the basis of said pointer, a session dependent URL (URL 2), and to send a redirect from the session between the user equipment and the controller to the new session by using the session dependent URL (URL2) to said user equipment 400.
  • the communication unit 901 is further configured to receive a request for the new session from the user equipment indicated by the session dependent URL, and the processing unit 900 is further configured to allocate the requested session, thereby allowing the media server to control the IPTV unicast session.
  • processing unit 900 may be configured to execute a verifying process each time a request associated with a session is received from UE 400, verifying that the respective session exists.
  • the request for setting up a session is a content download set up request or a content on demand set up request.
  • the request for setting up a session may be a HTTP GET request or a HEAD request and the redirect command may be a 303 See other message.
  • the request for setting up a session may be a RTSP setup request and the redirect command may be a 302 Moved Temporary message.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Graphics (AREA)
  • Computer And Data Communications (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

The present invention relates to methods and arrangements for reducing the load on the controller in an IPTV network. This is achieved by the embodiments of the present invention by letting the MS 105, instead of the controller 104, control the session with the UE and omit the session between the UE and the controller. The UE is thereby sending the keep alive messages to the MS, but that would not imply a troublesome load on the MS, since the keep alive messages are regular RTSP requests with an empty body.

Description

METHODS AND ARRANGEMENTS FOR AN IP TV NETWORK
TECHNICAL FIELD
The present invention generally relates to the field of an IPTV network, and in particular to management of unicast sessions.
BACKGROUND
Internet Protocol Television (IPTV) is a concept that has been configured for delivery of TV and video services over an IP network, such as e.g. a broadband access network. The predominant IPTV service is linear, or scheduled, TV, in which normal non-IPTV channels, as well as additional channels having a low penetration among the potential users, are transmitted over the broadband network from a super head-end on the server side, to User Equipments (UEs), such as e.g. STB enabled TV sets (STB/TV), or any other type of user equipments that have been provided with STB functionality.
In addition to broadcasted IPTV services, many new IPTV services, such as e.g. Personal Video Recorder in the Network (NPVR), Video on Demand (VoD), TVof Yesterday, and pause live TV, are distributed to the end-users via unicast.
IPTV services delivered via unicast allows more sophisticated features to be offered to the end-users, but raises also a demand for more complicated techniques for setting up and maintaining a session. Therefore, throughout this document, the term IPTV services is consequently to be interpreted to comprise IPTV unicast services. Open IPTV Forum is a new standard which defines, or references to, procedures and protocols that are applicable for this type of services. A simplified, prior art system, adapted to provide IPTV services to end-users may be described according to figure 1.
In figure 1 a UE 100, which may typically be e.g. a STB (set-top-box)/TV, is connected to an IP-based network 101, via an access network 102 and an IP Edge 103. The IP network 101 enables UEs, such as a UE denoted 100, to connect to a controller 104 and to one or more media servers (MS) 105a,b,c, of the IP-based network 101, each of which provides one or more IPTV services to the end-users and their respective UE. It is to be understood that a typical system comprises a plurality of UEs, and that a UE may be able to access a plurality, even a large number, of different media servers, each of which may offer different types of IPTV services to the end-users. However, for simplicity reasons, figure 1 only comprises one UE 100 and three MSs 105a,b,c.
The unicast IPTV services mentioned above are different in nature, compared to the broadcasted IPTV services, and the different IPTV services are usually also using different setup and control procedures. When, for example VoD is applied, the content to be played out on a UE is normally a combination of a movie, typically provided as a plurality of separate movie parts, and one or more advertisement parts, that have been clipped in between the movie parts. These parts are normally put together by the controller, that usually has access to pre-defined end-user preferences for certain types of advertisements, in a list, typically referred to as a playlist, where such a playlist may comprise one or more movies and one or more advertisements, listed in a certain order.
When applying pause live TV, media content that is captured from a real-time stream does not fully exist when a setup is performed between a UE and an MS. Such a situation may typically give rise to several problems. Both UEs, as well as MSs, such as e.g. video servers, do for example become more difficult to integrate, because of the complexity associated with having to maintain two connections throughout a session, namely one connection between the UE and the controller, acting a first server, and another connection between the UE and the media server, acting as a second server, where different commands will be addressed to the first or the second server, respectively.
Today there is no standardised method which enables a controller to control a session and to maintain control over the play-lists applicable for the respective session. One way of enabling the setting up, and controlling of a session for delivery of a content on demand service, such as e.g. a VoD service according to the prior art will now be described in more detail with reference to the figure 2. It is to be understood that although the given example refers to an RTSP setup, a corresponding procedure may be applied also for a session setup using any other conventional standard, such as e.g. HTTP. Figure 2 illustrates that a UE 100 initiates two sessions Sl, S2 (also referred to as connections) one with a media server 105 and one with a controller 104.
It is assumed as a prerequisite that an end-user, having access to a number of IPTV services, or programs, from a MS 105, such as e.g. a video server, via an IPTV enabled UE 100, and a controller 104, has accessed a content list, e.g. via a browser, or after activation of native local code of UE 100, and that the end-user has chosen a specific, required IPTV service from the content list.
In a first step 2:1 (not shown in figure 2) an end-user (UE) initiates a request for the selected IPTV service from an MS 105, by forwarding an RTSP setup, to a controller 104. The requested IPTV service is typically indicated in a service offering, here referred to as URL 1, of the RTSP setup forwarded in step 2:1. The service offering also comprise additional information, such as e.g. the x-client extension header, which helps to identify the end-user and the MAC address of UE 100 in one or more extension headers.
In a next step 2:2, the controller 104 performs an asset control, i.e. determines which assets that are available from MS 105. Assets may comprise e.g. one or more films, selected by the end-user, and indicated in the service offering, as well as one or more advertisement that may be predestined to be provided to the end-user, together with the selected IPTV service content. Such information may be obtained from a storage means of controller 104, during the asset control.
As a result of the asset control, a playlist, typically comprising one or more films and one or more advertisements, is specified, such that e.g. one or more specific advertisements will be delivered to the end-user, together with a specific film or group of films, in a predefined order.
In a subsequent step 2:3, the controller 104 issues a request, comprising the play list, requesting MS 105 to create, or set up, a session with UE 100, for enabling delivery of the content of the playlist, previously created by the controller 104 in step 2:1. In response to this request, the MS 105 creates a second URL, URL 2,that comprises an address to the MS 105, such that the UE 100 will be able to communication with the MS 105. This is referred to as a step 2:4. In a subsequent step 2:5 URL 2 is returned to the controller 104, and in another step 2:6, the controller 104 responds to the RTSP setup of step 2:1 with forwarding a response message, pointing to URL 2, to UE 100. In the present example the response message is transmitted to UE 100 as a 200 OK message. I.e. a 200 OK message comprises data and constitutes also an acknowledgement.
The result of this response message is that a first connection, here referred to as Sl, will be used for communication between UE 100 and controller 104, while a second connection S2 will be used for the communication between UE 100 and MS 105, that is associated with the created session.
An exemplified scenario for setting up an IPTV service will now be described with reference to subsequent steps 2:7-2:12, where it is assumed that an end-user of the UE 100, initiates a command, in order to start playing a requested film on the UE 100. In the present example this is done by transmitting an RTSP Play command comprising URL 2 to MS 105, in a step 2:7, and responded to in a subsequent step 2:8, which may be a 200 OK, that is subsequently returned to the UE 100 from the MS 105.
In subsequent steps (not shown), the UE 100 may forward additional commands to the controller 104 via one session Sl and to MS 105 via the other session S2, depending on the required task to be executed. When watching a movie, the end-user may e.g. at any occasion choose to pause the watched movie. This is done in a next step 2:9, and it is normally verified by the MS 105 with a 200 OK, referred to as step 2:10.
Once the end-user decides to quit watching the movie, the end-user may initiate such a command, and the UE 100 will accordingly instruct the MS 105 to terminate the present IPTV service, typically by transmitting an RTSP Teardown request to the controller 104 via session Sl, referred to as step 2:11, whereby the controller 104, transmits a corresponding request, here a destroy stream request, to the MS 105, instructing the MS 105 to terminate the IPTV service, as a final step 2:12.
Obviously, two connections, sessions Sl and S2, are required for enabling an end-user to maintain a session between the UE 100 and the MS 105, such that an IPTV service provided from the MS 105, can be consumed at a UE 100, while allowing the controller 104 to control the delivery of the IPTV service. In order for a UE 100 to be able to communicate with the controller 104 and an MS 105 accordingly, and for the controller 104 to maintain control of the IPTV service delivery, a rather complex configuration will be required at the UE 100 as explained below.
Hence figure 2 is showing one possible solution for handling two different connections, Sl and S2 associated with a session that have been set up e.g. according to the example described above, may be handled, where the UE 100 have to set up a first connection, Sl, with a controller 104, and a second connection, S2, with a certain, selected MS 105, in order to enable a required IPTV service to be selected by an end-user and delivered to the UE 100.
The configuration according to figure 2, which is doable, but which increases the complexity of the UE 100, relies on an RTSP Proxy 300, which is implemented at UE 100, having the purpose of keeping track of the two separate connections Sl, S2 as long as the associated session is active. An RTSP Proxy 300 may enable the UE 100 to communicate with a controller 104 and a MS 105, via a connection SO (not shown), such that from the perspective of the UE, only one connection is required, while the RTSP Proxy 300 will be handling the connections Sl and S2.
Alternatively, the controller may act as an RTSP Proxy. Such a solution will, however result not only in a severely increased load at the controller, but also in a delay for all RTPS traffic.
Furthermore the UE 100 needs to continuously send keep alive messages, also referred to as heartbeats, over connection Sl to the controller 104 while the associated session is active. These keep alive messages implies a high load on the controller 104. The keep alive messages affect the dimensioning of the controller and requires additional hardware to manage the extra load.
SUMMARY It would therefore be desired to reduce the load on the controller.
This is achieved by the embodiments of the present invention by letting the MS 105, instead of the controller 104, control the session with the UE and omit the session between the UE and the controller. The UE is thereby sending the keep alive messages to the MS, but that would not imply a troublesome load on the MS, since the keep alive messages are regular RTSP requests with an empty body. It should be noted that aTSP request like pause, fastforward can replace the RTSP keep alive messages.
According to a first aspect of the present invention, a method in a controller (402) for controlling an IPTV unicast session from a media server to a user equipment is provided. In a first step a request for an IPTV session (Sl) set-up between the user equipment and the controller is received. A session (Sl) allocation at said media server is requested in response to receiving said request and a pointer pointing towards a new session (S2) to be allocated between the user equipment and the media server is received from said media server 401. On the basis of said pointer, a session dependent URL (URL2) is obtained. A redirect command is sent to said user equipment towards the session dependent URL (URL2) thereby enabling the user equipment to cancel the allocated session (Sl) between the user equipment and the controller and to set up the new session (S2) towards the media server such that the media server controls the IPTV unicast session between the user equipment and the media server.
According to a second aspect of the present invention, a method in a media server for providing an IPTV unicast session to a user equipment is provided. In a first step a request, from a controller, for a session (Sl) between a controller and the user equipment is received. In a further step the session (Sl) is allocated in response to said request. In a yet further step a pointer, pointing towards a new session (S2), to said controller 401, is provided to the controller thereby enabling the controller to obtain, on the basis of said pointer, a session dependent URL (URL 2), and to send a redirect from the session between the user equipment and the controller to the new session by using the session dependent URL (URL2) to said user equipment. In a further step a request is received for the new session from the user equipment indicated by the session dependent URL, and the requested session is allocated, thereby allowing the media server to control the IPTV unicast session.
According to a third aspect of the present invention a controller for controlling an IPTV unicast session from a media server to a user equipment is provided. The controller comprises a communication unit. The communication unit is configured to receive from the user equipment a request for an IPTV session (Sl) set-up between the user equipment and the controller, to request a session allocation at said media server in response to receiving said request, and to receive, from said media server, a pointer pointing towards a new session (S2) to be allocated between the user equipment and the media server. The controller further comprises a generating unit for obtaining, on the basis of said pointer, a session dependent URL (URL2), wherein the communication unit is further configured to send to said user equipment a redirect command towards the session dependent URL (URL2). The user equipment is thereby enabled to cancel the allocated session (Sl) between the user equipment and the controller and to set up the new session (S2) towards the media server such that the media server controls the IPTV unicast session between the user equipment and the media server.
According to a fourth aspect of the present invention a media server for providing an IPTV unicast session to a user equipment is provided. The media server comprises a communication unit for receiving, from a controller, a request for a session (Sl) between a controller and the user equipment and a processing unit for allocating the session (Sl) in response to said request. The communication unit is further configured to provide a pointer, pointing towards a new session S2, to said controller, thereby enabling the controller to obtain, on the basis of said pointer, a session dependent URL (URL 2), and to send a redirect from the session between the user equipment and the controller to the new session by using the session dependent URL (URL2) to said user equipment. The communication unit is further configured to receive a request for the new session from the user equipment indicated by the session dependent URL, and the processing unit is further configured to allocate the requested session, thereby allowing the media server to control the IPTV unicast session.
An advantage with embodiments of the present invention is that they facilitate retrieval over the javascript API of the second URI. The URI includes the sessionld that identifies the session created over ISA. The information is available in local code within the STB but is not available in the browser (refer to OIPTVF contribution).
A further advantage with embodiments of the present invention is that the same procedure can be used for both an IMS (managed) and non-IMS (non-managed or open internet) IPTV (refer to OIPTVF contribution).
A further advantage is that it is possible to have only one session setup at the time by using messages of existing standard and protocols.. This is a difference from prior art where two sessions were required, one towards the controller and one towards the MS (refer to Plain IPTV STB Interface Specification). By using the RTSP redirect request (moved) it is possible to have a unified session setup.
An advantage with the present invention is that the reduced load on the controller provides free processing capacity and allows the controller to be used in a more optimal way.
A yet further advantage with one embodiment is that bookmarks are handled correctly in relationship to the session that is setup towards the MS. With the information of the second URL using standard mechanisms no proprietary approaches are needed to carry bookmarks within the session setup for either IMS (SIP based) or non-IMS (RTSP based).
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, illustrate exemplified embodiments of the invention, which, together with the description, serve to explain the principles of the invention.
- Figure 1 is a simplified system overview of a prior art system for providing IPTV services to end users. - Figure 2 is a simplified illustration of a user equipment configuration comprising an RTSP proxy, according to the prior art.
- Figure 3 is a signaling scheme illustrating a procedure for setting up an IPTV session, according to one embodiment.
- Figure 4 is another signaling scheme illustrating a procedure for setting up an IPTV session, according to another embodiment.
- Figure 5 is a flow chart illustrating method steps to be executed at a controller when setting up an IPTV unicast service session, according to one exemplified embodiment.
- Figure 6 is another flow chart illustrating method steps to be executed at a media server when setting up an IPTV unicast service session, according to one exemplified embodiment.
- Figure 7 is a block scheme illustrating a controller that is configured to apply the method described with reference to figure 5.
- Figure 8 is another block scheme illustrating a media server that is configured to apply the method described with reference to figure 6.
DETAILED DESCRIPTION
The basic concept of the present invention is to provide a solution for setting up an IPTV unicast session between a UE, e.g. a STB, and an MS, wherein the session between the UE and the controller is avoided. Hence, the MS is allowed to keep the control of the UE instead of the controller which implies that the keep alive messages are sent from the UE to the MS instead of, to the controller. Therefore the load of the controller is reduced.
This achieved by way of introducing modifications at the controller and at the MS, but without having to modify the UE. More specifically, the MS is configured to allocate a session dependent URL, which the controller then redirects the UE to. Figure 3 is a signalling diagram that illustrates one way of executing the suggested session set up procedure by setting up an IPTV session between a UE 400 and a MS 401, via a Controller 402, when content on demand, such as e.g. VoD, is applied.
It is to be understood that the signalling scheme of figure 3, as well as other signalling schemes referred to in this document, are simplified signalling schemes where signalling steps, as well as nodes which may normally be used in a common IPTV session setup procedure, but which are not essential for the understanding of the suggested method may have been omitted for simplicity reasons.
In a first step 4:1 of figure 3, an end-user requesting for an IPTV unicast service, in this case a content on demand service, initiates a procedure for setting up a session Sl between the UE and the controller by first transmitting a set up request to the controller 402. The setup request, which in the present case is an RTSP setup request comprising a service offering indicated as URL 1 in figure 3, corresponds to a conventional set up command. In the present content on demand case this is typically done by transmitting an RTSP Setup.
At the controller 402, a conventional asset control is performed on the service offering, as indicated in a step 4:2. As a result of the asset control, a playlist, typically comprising one or more films and one or more advertisements, is specified, such that e.g. one or more specific advertisements will be delivered to the end-user, together with a specific film or group of films, in a predefined order.
In a subsequent step 4:3, the controller 402 issues a request, comprising the play list, requesting MS 401 to create, or set up, a session with UE, for enabling delivery of the content of the playlist, previously created by the controller 402 in step 4:2. The MS 401 responds to this request by allocating a session Sl and stores the playlist. Further a first session Sl is allocated between the UE in step 4:4. The MS response is transmitted to the controller 402, comprising a pointer also referred to as a stream ID, as indicated with a subsequent step 4:5. At the controller 402, a session dependent URL, URL 2, is created on the basis of the stream ID in the response, as indicated with a step 4:6. Alternatively, the URL 2 is created at the MS 401, and if so the URL 2 is provided to the controller 402 in the response instead of the stream ID. In a next step 4:7 the controller 402 initiates a temporary remove of session Sl by executing a redirect, comprising the session dependent URL, URL 2, towards the UE 400. Once received at the UE 400, the URL 2 is stored at a storage means for later retrieval, as indicated with another step 4:8. Session 1 is now removed and a new session S2 has to be established. Although if Session 1 between the UE and the controller is removed, the controller is still responsible for creating sessions.
In a next step 4:9, the new session S2 is set up between the UE and the MS by the UE 400 transmitting another RTSP setup, to the MS 401. This setup do however comprise the URL 2, which initiates a process for verifying the session, i.e. to verify that the URL 2 is actually associated with a session, as indicated with another step 4:10. If successfully verified, the MS 401 responds to the setup request in a subsequent step 4:11, typically via a 200 OK message.
One single connection, here referred to as S2, has now been established between the UE 400 and the MS 401, and the end-user may now at any time decide to start a required service.
In a next step 4:12 the URL 2 is retrieved from the storage and in a subsequent step 4:13 a request to start playing a requested IPTV service is initiated by the end-user, by transmitting such a request, in this case an RTSP Play request, comprising URL 2, to the MS 401.
After another session verification procedure, as indicated with a step 4:14, the requested service is delivered to the UE 400 by the MS by using the stored playlist, as indicated with another step 4:15. The UE will send keep alive messages to the MS continuously, indicating that the session is to be maintained by the MS. If the keep alive messages fail (i.e. is not received by the MS) then the MS will assume that the resources provided by the MS are no longer required by the UE. The keep alive messages are an integral part of RTSP implying that any RTSP message is considered as a form of keep alive message. So a pause request will have the same effect as a keep alive.
Subsequent commands initiated from UE 400 by the end-user may then be performed in a similar manner. In figure 3, a procedure for terminating the session is initiated and performed as indicated with steps 4:16-4:18. In the present example a request to terminate the session is initiated from UE 400, by transmitting a RTSP teardown to MS 401, as indicated with a step 4:17. After verification, as indicated with a step 4:18, the controller 402 is notified of the upcoming session termination in a step 4:19, after which controller 402 requests for the session to be terminated in a next step 4:20, in this case by transmitting a Destroy stream request. In a final step 4:18 the session is then removed. These steps are performed in order to keep the synchronization between the controller and the MS, otherwise the controller and the MS are out of sync as to what should be removed or not.
A corresponding session setup may be performed also if instead a download IPTV session set up is requested by means of HTTP instead of RTSP. Such a scenario is illustrated with the signalling scheme of figure 4, where a setup procedure may typically be initiated with transmitting a HTTP GET, in an initial step 5:1.
The HTTP method is very similar to the above described RTSP solution except for that a silent notification is sent in step 5:17 to the controller and a destroy stream may be sent in step 5:18. Therefore, the remaining steps are not further described.
Obviously, the method exemplified above only requires first one session Sl and then one session S2 for setting up a connection with a media server, and for subsequently enabling an end-user to initiate and consume the IPTV services. As a consequence, the UE engaged in an IPTV session will not require any RTSP Proxy, or equivalent adaptation, that has to keep track of two simultaneous sessions, and, thus, a UE that is less complex than prior art solutions may be used. According to embodiments of the present invention, the UE, e.g. a STB, comprises a browser and a client, wherein client software is running under the browser. The above described embodiments will now be described in the context of the browser and the client and in conjunction with the sequence diagram of figure 5.
1. The JavaScript in the browser page sets the "data" property of the A/V scriptable Object to a first URL, URL 1, to play.
2. The JavaScript calls the play method with the speed parameters set to 0 (pause). The play method of the client software is called. This is done to ensure that everything is ready in the client before step 14 is performed.
3. The Client software may send an RTSP DESCRIBE to the IPTV controller containing said URL, URL 1, user identities, STB identity, e.g. MAC, and IP address.
4. A 200 OK is returned.
5. The client SW sends an RTSP SETUP to the IPTV controller, containing the first URL, URL 1, and zero or more extensions headers, e.g. the x-client extension header. The x-client helps identify the user and the MAC address of the STB. This information is used by the IPTV controller to perform asset control, meaning which assets are available to the particular user on the particular STB. A first session Sl is setup between the client and the controller. This step corresponds to step 4:1 in figure 3.
6. The IPTV controller issues one or several ISA methods on the media server in order to setup the media session. This step corresponds to step 4:3 in figure 3.
7. The media server returns a stream ID. The stream ID is used when the URL 2 is created. This step corresponds to step 4:5 in figure 3.
8. The IPTV controller creates URL 2 based on the received stream ID and responds to the setup with a redirect message comprising URL2. This implies that session 1 is cancelled and a new session will be setup between the client and the media server. The stream ID may be exemplified as 3535252 while a URL may have the format like RTSP://192.158.3.2/3535252. This step corresponds to step 4:7 in figure 3.
9. The Client SW may send an RTSP DESCRIBE to the Media Server containing the second url, URL 2.
10. A 200 OK is returned.
11. The client SW sends an RTSP SETUP to the Media Server, containing the second URL, URL 2 to setup a new session. This step corresponds to step 4:9 in figure 3.
12. A 200 OK is returned
13. An event is raised in the browser environment, with the name onStatusChange. At this time the client SW has updated the data property to contain the second URL, URL 2.
14. As a response to the event the browser javascript code issues a new play method in the client software, with speed 1 (normal speed).
15. The client software sends an RTSP Play to the Media Server. At this stage the client and the media server are ready to start playing the content. 16. A 200 OK is returned. After this step the stream will be delivered to the
STB. As long as the session should be maintained, the UE will keep sending keep alive messages to the MS.
As described above, only one session, i.e. the session between the client and the media server, is required which implies that the load of the controller is reduced since no session between the client and the controller is needed.
Furthermore, the embodiments of the present invention also relates to a method and arrangement for jumping to a bookmark. Now when session 1 between the UE and the controller is cancelled, it is no longer possible to prior art methods for distinguishing between multiple sessions between the UE and the MS. Multiple sessions occurs if the UE comprises multiple STBs, wherein each STB has an individual session towards the MS. 17. If the user wants to jump to a bookmark. The javascript code in the UE reads the second URL, URL 2, from the data property (or equivalent property) which contains the sessionld in the URL 2. Without the second URL it is not be possible to differentiate different sessionld's towards the MS, since the URLs are unique per created session. The URLs are not shared between different users.
18. The browser javascript code makes a webservice (json) request towards the IPTV controller containing at least the user credentials, MAC address, IP address and the second URL which was retrieved in the previous step.
19. The IPTV controller returns at least one bookmark position, wherein the position may be adapted due to inserted commercials.
20. The browser javascript code calls a seek method, which resides in the browser to jump between positions, to jump to the bookmarked position.
21. The client software sends an RTSP play to the Media Server, indicating the new play position, i.e. the bookmarked position.
22. A 200 OK is returned comprising the media.
23. An onStatusChange event may be triggered in the browser to indicate that things are going ok.
Thus by using the second URL, URL 2, the javascript code running on the browser of the STB can read the second URL, URL 2, with the sessionld information. This information can then be used in step 18 to get the appropriate the bookmark.
Although the example described above refers to the RTSP protocol, the suggested method is applicable also for other protocols, such as e.g. the HTTP protocol, where e.g. the initial setup request, represented by an RTSP setup request in the example, is replaced by a HTTP GET request.
Considering the suggested set up mechanism from the perspective of the controller, the suggested session set up mechanism may comprise the series of steps which will now be described with reference to figure 6.
In a first step 601 (corresponding to step 4:lof figure 3) of figure 6, a request for an IPTV session (Sl) set-up between the user equipment and the controller is received at the communication unit 801. A session (Sl) allocation at said media server is requested in step 602(4:3) in response to receiving said request by said communication unit 801 and a pointer pointing towards a new session (S2) to be allocated between the user equipment and the media server is received in step 603(4:5), at the communication unit 801 from said media server 401. On the basis of said pointer, a session dependent URL (URL2) is obtained in step 604(4:6) by a generating unit 803. A redirect command is sent in step 605(4:7) to said user equipment towards the session dependent URL (URL2) thereby enabling the user equipment to cancel the allocated session (Sl) between the user equipment and the controller and to set up the new session (S2) towards the media server such that the media server controls the IPTV unicast session between the user equipment and the media server.
As a result of the described procedure, the MS will be able to control services provided via the session, while the session between the controller and UE can be cancelled and hence reduce the load on the controller.
Considering instead the suggested set up mechanism from the perspective of the MS, the suggested session set up mechanism may comprise the series of steps which will now be described with reference to figure 7.
In a first step 701 (corresponding to step 4:3of figure 3) a request, from a controller, for a session (Sl) between a controller and the user equipment is received at the communication unit 901. In step 702(4:4) the session (Sl) is allocated by a processing unit in response to said request. In a further step 703(4:5) a pointer, pointing towards a new session (S2), to said controller 401, is provided by the communication to the controller thereby enabling the controller to obtain, on the basis of said pointer, a session dependent URL (URL 2), and to send a redirect from the session between the user equipment and the controller to the new session by using the session dependent URL (URL2) to said user equipment 400. In a further step 704(4:9), a request is received for the new session from the user equipment indicated by the session dependent URL, and the requested session is allocated in step 705(4:10) by the processing unit 900, thereby allowing the media server to control the IPTV unicast session.
A controller that is configured to apply the suggested IPTV service session set up procedure described above, will now be described below, with reference to figure 8. The controller 402 comprises a communication unit 801. The communication unit 801 is configured to receive from the user equipment a request for an IPTV session (Sl) set-up between the user equipment 400 and the controller 402, to request a session allocation at said media server 401 in response to receiving said request, and to receive, from said media server 401, a pointer pointing towards a new session (S2) to be allocated between the user equipment and the media server. The controller further comprises a generating unit 803 for obtaining, on the basis of said pointer, a session dependent URL (URL2), wherein the communication unit 803 is further configured to send to said user equipment 400 a redirect command towards the session dependent URL (URL2). The user equipment 400 is thereby enabled to cancel the allocated session (Sl) between the user equipment and the controller and to set up the new session (S2) towards the media server such that the media server controls the IPTV unicast session between the user equipment and the media server.
According to embodiments of the present invention, the controller 402 further comprises a database for storing e.g. session information, URL 2, and other related asset information. A controlling unit is also provided for controlling the UE during session Sl .
A MS that is configured to interact with a UE and a controller in such a way that the suggested session set up procedure can be applied will now be described in more detail with reference to figure 9.
The media server 401 comprises a communication unit 901 for receiving, from a controller, a request for a session (Sl) between a controller and the user equipment and a processing unit 900 for allocating the session (Sl) in response to said request. The communication unit 901 is further configured to provide a pointer, pointing towards a new session S2, to said controller 401, thereby enabling the controller to obtain, on the basis of said pointer, a session dependent URL (URL 2), and to send a redirect from the session between the user equipment and the controller to the new session by using the session dependent URL (URL2) to said user equipment 400. The communication unit 901 is further configured to receive a request for the new session from the user equipment indicated by the session dependent URL, and the processing unit 900 is further configured to allocate the requested session, thereby allowing the media server to control the IPTV unicast session.
In addition, the processing unit 900 may be configured to execute a verifying process each time a request associated with a session is received from UE 400, verifying that the respective session exists.
According to embodiments of the present invention, the request for setting up a session is a content download set up request or a content on demand set up request.
In case of the content download set up request, the request for setting up a session may be a HTTP GET request or a HEAD request and the redirect command may be a 303 See other message.
In case of the content on demand set up request, the request for setting up a session may be a RTSP setup request and the redirect command may be a 302 Moved Temporary message.
The present invention is not limited to the above-described preferred embodiments. Various alternatives, modifications and equivalents may be used. Therefore, the above embodiments should not be taken as limiting the scope of the invention, which is defined by the appending claims. ABBREVIATION LIST
IPTV Internet Protocol Television
MAC Media Access Control
MS Media Server
NPVR Personal Video Recorder in the Network
RTSP Real Time Streaming Protocol
STB Set Top Box
UE User Equipment
URL Uniform Resource Locator
VoD Video on Demand

Claims

1. A method in a controller (402) for controlling an IPTV unicast session from a media server to a user equipment, said method comprises the steps of: -receiving (4: 1) from the user equipment a request for an IPTV session (Sl) set-up between the user equipment and the controller,
- requesting (4:3) a session (Sl) allocation at said media server (401) in response to receiving said request,
- receiving (4:5), from said media server (401), a pointer pointing towards a new session (S2) to be allocated between the user equipment and the media server,
- obtaining (4:6), on the basis of said pointer, a session dependent URL (URL2),
- sending (4:7) to said user equipment (400) a redirect command towards the session dependent URL (URL2), thereby enabling the user equipment (400) to cancel the allocated session (Sl) between the user equipment and the controller and to set up the new session (S2) towards the media server such that the media server controls the IPTV unicast session between the user equipment and the media server.
2. A method according to claim 1, wherein the request for setting up a session is a content download set up request.
3. A method according to claim 2, wherein the request for setting up a session is a HTTP GET request or HEAD request.
4. A method according to any of claims 1-3, wherein said redirect command is a
303 See Other.
5. A method according to claim 1, wherein the request for setting up a session is a content on demand set up request.
6. A method according to claim 5, wherein the request for setting up a session is a RTSP setup request.
7. A method according to any of claims 5-6, wherein said redirect command is a
302 Moved Temporary message.
8. A method in a media server for providing an IPTV unicast session to a user equipment, said method comprises the steps of:
- receiving (4:3), from a controller, a request for a session (Sl) between a controller and the user equipment,
- allocating (4:4) the session (Sl) in response to said request, - providing (4:5) a pointer, pointing towards a new session (S2), to said controller
(401), thereby enabling the controller to obtain, on the basis of said pointer, a session dependent URL (URL 2), and to send a redirect from the session between the user equipment and the controller to the new session by using the session dependent URL (URL2) to said user equipment (400), -receiving (4:9) a request for the new session from the user equipment indicated by the session dependent URL, and
-allocating (4: 10) the requested session, thereby allowing the media server to control the IPTV unicast session.
9. A method according to claim 8, wherein the request for setting up a session is a content download set up request.
10. A method according to claim 9, wherein the request for setting up a session is a HTTP GET or HEAD request.
11. A method according to any of claims 8-10, wherein said redirect command is a
303 See Other message.
12. A method according to claim 8, wherein the request for setting up a session is a content on demand set up request.
13. A method according to claim 12, wherein the request for setting up a session is a RTSP setup request.
14. A method according to any of claims 12-13, wherein said redirect command is a 302 Moved Temporary message.
15. A controller (402) for controlling an IPTV unicast session from a media server to a user equipment, said controller (402) comprises a communication unit (801) for receiving from the user equipment a request for an IPTV session (Sl) set-up between the user equipment (UE) and the controller (402), for requesting a session allocation at said media server (401) in response to receiving said request, and for receiving, from said media server (401), a pointer pointing towards a new session (S2) to be allocated between the user equipment and the media server, a generating unit (803) for obtaining, on the basis of said pointer, a session dependent URL (URL2), wherein the communication unit (803) is further configured to send to said user equipment (400) a redirect command towards the session dependent URL (URL2), thereby enabling the user equipment (400) to cancel the allocated session (Sl) between the user equipment and the controller and to set up the new session (S2) towards the media server such that the media server controls the IPTV unicast session between the user equipment and the media server.
16. A controller according to claim 15, wherein the request for setting up a session is a content download set up request.
17. A controller according to claim 16, wherein the request for setting up a session is a HTTP GET or HEAD request.
18. A controller according to any of claims 15-17, wherein said redirect command is a 303 See Other message.
19. A controller according to claim 15, wherein the request for setting up a session is a content on demand set up request.
20. A controller according to claim 19, wherein the request for setting up a session is a RTSP setup request.
21. A controller according to any of claims 19-20, wherein said redirect command is a 302 Moved Temporary message.
22. A media server (401) for providing an IPTV unicast session to a user equipment, said media server comprises a communication unit (901) for receiving, from a controller, a request for a session (Sl) between a controller and the user equipment, a processing unit (900) for allocating the session (Sl) in response to said request, the communication unit (901) is further configured to provide a pointer, pointing towards a new session (S2), to said controller (401), thereby enabling the controller to obtain, on the basis of said pointer, a session dependent URL (URL 2), and to send a redirect from the session between the user equipment and the controller to the new session by using the session dependent URL (URL2) to said user equipment (400), the communication unit (901) is further configured to receive a request for the new session from the user equipment indicated by the session dependent URL, and the processing unit (900) is further configured to allocate the requested service, thereby allowing the media server to control the
IPTV unicast session.
23. A media server according to claim 22, wherein the request for setting up a session is a content download set up request.
24. A media server according to claim 23, wherein the request for setting up a session is a HTTP GET or HEAD request.
25. A media server according to any of claims 22-24, wherein said redirect command is a 303 See Other message.
26. A media server according to claim 22, wherein the request for setting up a session is a content on demand set up request.
27. A media server according to claim 26, wherein the request for setting up a session is a RTSP setup request.
28. A media server according to any of claims 26-27, wherein said redirect command is a 302 Moved Temporary message.
PCT/SE2009/051147 2008-10-13 2009-10-12 Methods and arrangements for an ip tv network WO2010044731A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10494708P 2008-10-13 2008-10-13
US61/104,947 2008-10-13

Publications (1)

Publication Number Publication Date
WO2010044731A1 true WO2010044731A1 (en) 2010-04-22

Family

ID=42106715

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2009/051147 WO2010044731A1 (en) 2008-10-13 2009-10-12 Methods and arrangements for an ip tv network

Country Status (1)

Country Link
WO (1) WO2010044731A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3780625A4 (en) * 2018-04-10 2021-06-16 Huawei Technologies Co., Ltd. Recorded data processing method and relevant device

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006110322A2 (en) * 2005-04-11 2006-10-19 Roundbox, Inc. Multicast-unicast adapter
WO2007071461A1 (en) * 2005-12-19 2007-06-28 Telefonaktiebolaget Lm Ericsson (Publ) Method for establishing a unicast media session

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006110322A2 (en) * 2005-04-11 2006-10-19 Roundbox, Inc. Multicast-unicast adapter
WO2007071461A1 (en) * 2005-12-19 2007-06-28 Telefonaktiebolaget Lm Ericsson (Publ) Method for establishing a unicast media session

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BT, UK: "Content Delivery Detailed Dynamic Architecture", CONTRIBUTION 722; ITU-T FG IPTV FOCUS GROUP ON IPTV STANDARDIZATION, July 2007 (2007-07-01), GENEVA, pages 1 - 10, XP003026376, Retrieved from the Internet <URL:http://www.itu.int/md/dologin_md.asp?lang=en&id=T05-FG.IPTV-C-0722!!MSW-E> [retrieved on 20070711] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3780625A4 (en) * 2018-04-10 2021-06-16 Huawei Technologies Co., Ltd. Recorded data processing method and relevant device

Similar Documents

Publication Publication Date Title
US8132218B2 (en) Access/edge node supporting multiple video streaming services using a single request protocol
EP2030403B1 (en) Ims service proxy in higa
EP2294733B1 (en) A method and equipment for providing unicast preparation for iptv
US8307049B2 (en) Method and device for obtaining media description information of IPTV services
US20080288458A1 (en) Session Initiation Protocol (Sip) Multicast Management Method
RU2647654C2 (en) System and method of delivering audio-visual content to client device
EP2429144A1 (en) Method and apparatus for transmitting hyper text transport protocol (http) media
US20100269132A1 (en) Method and System For Inserting Advertisements In A Content Stream In Internet Protocol Television (IPTV)
JP5436577B2 (en) Managing associated sessions in the network
KR100891745B1 (en) Method and apparatus of providing video on demand service based on ip multimedia subsystem
US20120042335A1 (en) Method and apparatus for reproducing advertisement
WO2018090978A1 (en) Self-adaptive playing and control method, set top box and electronic programme server
EP3675456A1 (en) Content transfer device and content transfer method, content reproduction device and content reproduction method, content distribution system and computer program
KR20090123781A (en) Method and apparatus for using internet protocol television based on application received by multi-cast session
US11729232B2 (en) Content delivery
US11102536B2 (en) Transmission apparatus, reception apparatus, and data processing method
WO2010044731A1 (en) Methods and arrangements for an ip tv network
CN105744309A (en) Method, device and system for generating and playing, and terminal
US20110164857A1 (en) Systems and methods for network-based bookmarking
Stockhammer et al. DVB-IPTV content download services—overview and use cases
KR101029852B1 (en) IPTV service control method and control server
Stockhammer et al. DVB-IPTV Content Download Services-IPTV services anytime and anywhere
WO2011102079A1 (en) Content delivery system, content delivery method, service mediation system, service mediation device, and storage medium

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: 09820838

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09820838

Country of ref document: EP

Kind code of ref document: A1