The present invention generally relates to Internet Protocol (IP) television (IPTV). More specifically, but not exclusively, the present invention is concerned with a method and system for collecting IPTV traffic distributed over various types of access networks to, for example, analyze this IPTV traffic from a business intelligence perspective.
The IP protocol is increasingly becoming the reference for delivering any type of data over any type of access technology. The most common type of data conveyed over the IP protocol includes web services at large and emails. Such data can be accessed at home via a broadband connection, in the office via a dedicated high speed link, and almost anywhere via a Cellular Operator infrastructure. However, the delivery of such data is more and more considered by end users as a commodity. Thus, there is a huge pressure on the revenues that can be generated from the delivery of such services. At the same time, the revenues generated from traditional voice traffic, be it fixed or mobile, are also under pressure.
As a result, Internet Service Providers (ISPs) and Cellular Operators are deploying new value-added services based on IP technologies, in order to generate new types of revenues. Internet Protocol television (IPTV) constitutes one of these services. Traditional Cable Operators, as well as ISPs, are offering TV services over IP transport, using different types of underlying access technologies (cable, Digital Subscriber Line (DSL), optical fiber, etc.). At the same time, Cellular Operators are also offering IPTV services, as part of a premium service offer over their cellular infrastructure. In the context of the present specification, IPTV must be understood in a broad sense. This includes synchronous diffusion of TV channels to a large number of end users (it will also be referred to as multicast television services); as well as Video (or Television) On Demand services, where a single user asynchronously accesses a specific video content.
The complexity involved with the delivery of IPTV services over different types of access technologies has driven the development of methods and systems to collect IPTV data, in order to analyze the behaviour of different entities involved in the delivery of IPTV services. The data collected are usually used for network management, Quality of Service (QoS) conformance validation, detection of errors and performance analysis.
In the appended drawings:
According to an illustrative embodiment, there is provided a method for collecting and analyzing IPTV traffic in an IPTV network including end user premises, an access network, and an IP core network, the method comprising:
deploying filtering sub-systems to collect in real time IPTV traffic using at least one access technology, wherein:
transmitting the collected IPTV traffic from the filtering sub-systems to a centralized analytic system;
aggregating the collected IPTV traffic in relation to the end users; and
performing business intelligence and marketing oriented analysis over the collected IPTV traffic using the centralized analytic system.
In accordance with another illustrative embodiment, there is provided a system for collecting and analyzing IPTV traffic in an IPTV network including end user premises, an access network, and an IP core network, the system comprising:
filtering sub-systems deployed in at least one location selected from the group consisting of the end user premises, the access network, and the IP core network, the filtering sub-systems each comprising:
an aggregator of the collected IPTV traffic in relation to each individual end user; and
the centralized analytic system comprising an analytic server structured to perform business intelligence and marketing oriented analysis over the collected IPTV traffic.
Generally stated, the method and system of
The method and system for collecting and analyzing IPTV traffic enable to extract IPTV traffic at different locations of the IP network, in a distributed manner. Such locations may include, for example but not exclusively, the end user premises, the access network, the IP core network and the IPTV servers. The extracted traffic is processed locally to extract the pertinent IPTV related data, which are then transmitted to the centralized analytic system. Such method and system are highly scalable, since they allow Telecom Operators to perform the IPTV traffic collection at the best location in the network, based on the type of IPTV related data to be extracted. Additionally, the capture of IPTV related data is optimized for a specific access technology, for example cellular or broadband, and even for a specific network architecture within the same type of access technology. In the case of Telecom Operators with a converged IP network based on different access technologies (for example
Also, the method and system for collecting and analyzing IPTV traffic provide to Telecom Operators a real time, or at least near real time view of the IPTV traffic in their IP network. For that purpose:
Now, turning to
The IPTV network of
The IPTV network of
The IPTV network of
Finally, the IPTV network of
The Video (or Television) On Demand server 30 provides unicast video (or television) services to the end users. More specifically, the Video (or Television) On Demand server 30 enables an end user to order to the server 30 through the access 12 and IP core 14 networks, receive from the server 30 through the IP core 14 and access 12 networks, and watch on the end user equipments 40 and 42 any type of video (or television) content stored in the Video (or Television) On Demand server 30 at any time and as many times as requested, with possibilities to stop and resume the viewing.
The multicast IPTV server 32 provides multicast television services to the end users. More specifically, the multicast IPTV server 32 broadcasts TV channels through the IP core 14 and access 12 networks. The end users can select and watch a TV channel from a group of predetermined TV channels on the end user equipment 40 or 42, and instantly change the currently selected and watched TV channel.
The Electronic Program Guide 34 provides a list of available TV channels on the multicast IPTV server 32, and the programs for each TV channel. The equivalent of the Electronic Program Guide 34 for the Video (or Television) On Demand server 30 may be part of the Video (or Television) On Demand server 30 itself, or may deployed as a standalone server, not shown in
Finally, the IP traffic related to IPTV services is represented by IP flows 50, 52, 54 and 56 in
The method and system for collecting and analyzing IPTV traffic as shown in
Whenever it is possible, IPTV traffic shall be collected by the filtering sub-system 140 located in the IP core network 14. In a typical, non limitative deployment, only one to a few such sub-systems would be deployed in the IP core network 14 of a Telecom Operator. For example, in the case of the Video (or Television) On Demand service, IP based protocols being used to deliver the service comprise the Real Time Protocol (RTP), the Real Time Streaming Protocol (RTSP), the Session Description Protocol (SDP), and possibly the Hypertext Transfer Protocol (HTTP). During a Video (or Television) On Demand session between an end user equipment 40 or 42 and the Video (or Television) On Demand server 30, the IP traffic related to this service (RTP, RTSP, SDP, HTTP, etc.) could be collected from the IP flow 50 in the end user premises 10, from the IP flow 52 in the access network 12, or from the IP flow 54 in the IP core network 14. For scalability reasons, it is very convenient to use in this particular case a single (possibly a few) filtering sub-system(s) 140 located in the IP core network 14.
When it is not possible to collect the IPTV traffic in the IP core network 14, it will be collected for example by the filtering sub-system 120 located in the access network 12. In a typical, non limitative deployment, tens to hundreds to thousands of filtering sub-systems such as 120 can be deployed in the access network 12 of a Telecom Operator. The number of filtering sub-systems 120 depends on the underlying access technology and how close to the end-user premises 10 such filtering sub-systems are deployed (
When it is not possible to collect the IPTV traffic in the IP core network 14 or in the access network 12, it will be collected by the filtering sub-system 100 located in the end user premises 10. In a typical, non limitative deployment, millions of filtering sub-systems such as 100 can be deployed at the end user premises such as 10. Returning to the previous example, the IGMP traffic from the IP flow 52 in the access network 12 may already be aggregated and the granularity at the end user level is lost. This may be the case for a broadband access network, where several end user equipments 40 or 42 in the same end user premises generate their own IGMP traffic. The dedicated IP networking equipment 20 may aggregate these individual IGMP flows for the access network 12. If the Telecom Operator requests a granularity at the level of the various end user equipments 40 or 42 deployed at the end user premises 10, the IGMP traffic is then extracted or collected from the IP flow 50 in the end user premises 10, via the filtering sub-systems 100.
The IPTV data extractors of the filtering sub-systems 100, 120 and 140 extract IPTV related data from the global IP traffic flows 50, 52 and 54, respectively. For that purpose, the IPTV data extractor of the filtering sub-systems 100, 120 and 140 perform analysis on layer 2 to layer 7 of, for example, the OSI model to extract information related to the IPTV services. For the Video (or Television) On Demand service, control traffic is conveyed via the RTSP and SDP protocols, and data traffic is conveyed via the RTP protocol. The HTTP protocol may also be used for control and data traffic. For the multicast IPTV service, the control traffic is conveyed via the IGMP protocol, and the data traffic is conveyed via the multicast RTP protocol. In certain cases (Internet or mobile TV), the IPTV service delivery may not be based on multicast technologies, but may be similar to the Video (or Television) On Demand service, using the RTSP protocol for signaling and the non multicast RTP protocol for data.
The aforementioned protocols represent the most common types of protocols in the context of IPTV services. Any other IP based protocol related to such IPTV services could be supported by the appropriate filtering sub-system 100, 120 or 140. The type of protocols related to the IPTV services and the associated points of capture (filtering sub-systems) will be described with reference to
The different layers of the IP protocol mentioned in the present disclosure refer to the different layers as defined by the OSI model. The OSI model includes the following seven (7) layers of networking protocols:
Although providing a dedicated filtering sub-system (not shown) in the infrastructure of the IPTV servers 16 is technically feasible, this will generally be avoided, to prevent the multiplication of filtering sub-systems at different locations. Only if specific information cannot be captured by the filtering sub-system 140 of the IP core network 14, should a dedicated filtering sub-system be deployed in the infrastructure of the IPTV servers 16.
The IPTV related data gathered at the various filtering sub-systems 100, 120 and 140 are transmitted though their respective transmitters to a centralized analytic system 150. The analytic system 150 comprises a post-processor 151 and a global database 152. The post-processor 151 of the analytic system 150 post-processes and consolidates the IPTV related data to the global database 152, in a pre-defined format consistent with an agreed upon metadata model. Based on the location of a specific filtering sub-system (140 in the core IP network 14, 120 in the access network 12 or 100 in the end user premises 10) and the type of access technology (broadband, cellular, etc.), the type of IPTV related data extracted from the global IP traffic 54, 52 and 50 will widely vary. However, it will always be adapted by the post-processor 151 to fit with the metadata model of the global database 152. Additionally, the post-processor 151 forms an aggregator of the IPTV related data for each individual end user. It will be detailed later in the description how the IPTV related data transmitted by the various filtering sub-systems 100, 120 and 140 can be aggregated in relation to a single global end user identifier.
The location of the analytic system 150 may vary and can be adapted to the needs of the Telecom Operator. In
In the case of an integrated Telecom Operator with several access networks (broadband, cellular, etc.), a single analytic system 150 can be deployed. This provides the Telecom Operator with a vision of the delivery of converged IPTV services over its global network infrastructure.
Additional information not directly related to the IPTV traffic extracted from the IP flows 50, 52 and 54, may also be obtained by the analytic system 150, or alternatively by the filtering sub-system 140 in the IP core network 14 (in the case where the analytic system 150 is incapable to retrieve such information by itself). For example, the mapping between the different multicast television channels (name of the channels and daily programs) and the IP multicast groups over which they are transmitted by the multicast IPTV server 32 can be obtained directly from the Electronic Program Guide (EPG) 34. For that purpose a connection to the EPG 34 can be established by the filtering sub-system 140 using an appropriate IP based protocol, for example the HTTP protocol, supported by the EPG to retrieve the relevant information. In the particular case of the EPG, the relevant information may be transmitted via a multicast group, in which case the filtering sub-system 140 in the IP core network 14 can extract this information from the global IP flow 54.
The IPTV related data extracted and transmitted by the filtering sub-systems 100, 120 and 140 is analyzed and transformed by the pre-processor 151 of the analytic system 150 to match the metadata model of the global database 152. The following is a non-exhaustive and non-limitative list of the consolidated IPTV data that can be stored in the global database 152.
End user identification: Interaction with a centralized authentication server, for example a Radius Server, is used to match the IP address of the IPTV packets extracted by the filtering sub-systems 100, 120 and 140 with an end user identification, for example the International Mobile Subscriber Identity (IMSI) for a cellular network.
Multicast TV channels watched by an end user and time spent on a specific channel: Interaction with an EPG is used to match the IPTV multicast groups subscribed by an end user (information extracted by the filtering sub-systems 100 or 120 from the IGMP traffic) with corresponding multicast TV channels (information provided by the EPG). Additionally, timestamps associated to the captured data can be used in conjunction with the EPG to identify the specific TV programs watched within the TV channel.
Program watched via the Video (or Television) On Demand service: Detailed information can be extracted and stored: time of watch, number of times the program is watched, start/stop/pause events (information extracted by the filtering sub-systems 140 from the RTSP traffic).
Access technology used for consuming a specific IPTV service: This information is relevant for an integrated Telecom Operator, offering IPTV services over different access technologies (broadband, cellular, etc.). A more or less precise localization in the case of cellular access may be available via additional localization information; for example this may indicate that an IPTV program on a cellular phone is being watched in a train, in a park, in a café, in an airport, etc.
The analytic system 150 further comprises an analytic server 153. An analytic server such as 153 is known as being used for Business Intelligence purpose. More specifically, the analytic server 153 takes as input the large amount of IPTV data stored in the global database 152 and processes this large amount of IPTV data and comprises a generator (not shown) of reports and dashboards adapted to help the Telecom Operator in analyzing the behaviours of the end users related to IPTV service consumption. If the global analytic system 150 is properly dimensioned, it can provide if not real time, “almost” real time feedback to the Telecom Operator. In general, behaviours of the end users can be tracked on a daily, weekly or monthly basis. The following is a non-exhaustive and non-limitative list of information that can be provided by the analytic server 153 to the Telecom Operator.
Audience for a specific TV channel and specific TV programs within a TV channel, with the desired granularity (minutes, seconds): This can help gather accurate statistics on the number of users actually watching advertisements included in a TV program.
Trends in the viewing habits of the end users: For example, news programs are watched at a specific time, followed by a sport program or a movie.
Statistics on Video (or Television) On Demand programs: How many users watch them, when do they watch them, etc.
Level of interaction between the end user and an IPTV program including interactive services or events generated during the program.
Type of device used to access an IPTV service, in the case of an integrated operator: For example TV equipment at home or cellular phone (model and capabilities). The type of access network is also a relevant information in the case of a cellular phone, since the most advanced models include WIFI connections, making it possible to access the IPTV service via the cellular infrastructure, or via a WIFI access point connected to a broadband infrastructure.
Synthesized consumption patterns of an end user consuming converged IPTV services: For example what service, when, where, on what device, etc.
Turning back to the global analytic system 150, such system may include additional features and capabilities not show in
The analytic server 153 may also incorporate advanced functionalities. For example, the content of the global database 152 may be transformed according to a specialized data model, optimized for the specific data manipulations performed by the analytic server 153 for Business Intelligence purposes. Also, in addition to the predefined analytic reports, the analytic server 153 may be structured to allow the Telecom Operator to generate customized dynamic reports.
The example of Cellular Network as illustrated in
Referring to
In the embodiment of
A filtering sub-system 140 is deployed in the IP core network 14 to capture the IP flow 250 between the GGSN 204 and a Broadband Multicast Service Center (BMSC) 206. The BMSC 206 is interposed between the GGSN 204 and the dedicated IP networking equipment 24 connecting the IP core network 14 and the IPTV servers 16. The BMSC 206 is a dedicated node deployed in the IP core network 14 to support multicast IPTV services delivered via MBMS. The filtering sub-system 140 also captures the IP flow 252 between the GGSN 204 and the dedicated IP networking equipment 24 connecting the IP core network 14 and the IPTV servers 16.
The data part of the multicast IPTV traffic comprises multicast Real Time Protocol (RTP) IP packets originating from the multicast IPTV server 32 and flowing toward the end user equipment 40 via the BMSC 206, the GGSN 204, the SGSN 202 and the Node B 200. The filtering sub-system 140 captures this IPTV traffic from the IP flow 250 between the BMSC 206 and the GGSN 204—it is referred to as the Gi interface in the Third Generation Partnership Project (3GPP) specifications.
The signalling part of the multicast IPTV traffic comprises Internet Group Management Protocol (IGMP) packets originating from the end user equipment 40 and flowing to the GGSN 204, via the Node B 200 and the SGSN 202. The filtering sub-system 120 captures this traffic from the IP flow 254 between the SGSN 202 and the GGSN 204. The IGMP packets are multicast signaling packets, to subscribe/unsubscribe to the IP multicast groups corresponding to the multicast IPTV channels.
The signalling part of the multicast IPTV traffic also consists in Diameter protocol packets exchanged between the GGSN 204 and the BMSC 206. The filtering sub-system 140 can capture this traffic from the IP flow 250 between the GGSN 204 and the BMSC 206—it is referred to as the Gmb interface in the 3GPP specifications and consists of MBMS specific Attribute-Value Pairs in the Diameter protocol.
The data part and signaling part of the Video (or Television) On Demand IPTV traffic consist in unicast RTP, Real Time Streaming Protocol (RTSP), HTTP, IP packets exchanged between the Video (or Television) On Demand server 30 and the end user equipment 40, via the dedicated IP networking equipment 24 connecting the IP core network 14 and the IPTV servers 16, the GGSN 204, the SGSN 202 and the Node B 200. The filtering sub-system 140 captures this IPTV traffic from the IP flow 252 between the Video On Demand server 30, more specifically the dedicated IP networking equipment 24 connecting the IP core network 14 and the IPTV servers 16, and the GGSN 204—it is referred to as the Gi interface in the Third Generation Partnership Project (3GPP) specifications.
From a deployment perspective, the functionalities of the filtering sub-system 120 may be easily integrated to the filtering sub-system 140, since ultimately all the information present in the IP flow 254 may also be present in the IP flows 250 and/or 252. This is the case if the IPTV multicast signaling traffic (to select multicast IPTV channels) in the IP flow 254 is replicated in the IP flow 250 (potentially via a different signaling protocol). The potential ability, in a Cellular Network, to deploy a single integrated filtering sub-system 140 is a consequence of the scarce radio resources in the cellular access network 12. Resources consuming multimedia services, such as IPTV, are deployed via a centralized architecture to perform admission control, radio resource reservation and user authorization. As a result, all the related IPTV traffic (signalling and data parts) travels through the GGSN 204 and reaches either the BMSC 206 or the dedicated IP networking equipment 24. Thus, it can be captured by the filtering sub-system 140.
The Broadband Network as illustrated in
The end user premises 10 potentially comprises several end user equipments in the form of TV sets 42, as well as set-top boxes (STBs) not shown in
In the access network 12, a Digital Subscriber Line Access Multiplexer (DSLAM) 300 is interposed between the RG 306 and an intermediate router 302, and the intermediate router 302 is interposed between the DSLAM 300 and a Broadband Remote Access System (BRAS) 304. A filtering sub-system 120 is deployed in the access network 12 to capture the IP flow 354 between the DSLAM 300 and the intermediate router 302 and/or the IP flow 352 between the BRAS 304 and the intermediate router 302. The DSLAM 300 is the dedicated IP networking equipment connecting the access network 12 to the end user premises 10. The BRAS 304 is the dedicated IP networking equipment connecting the access network 12 to the IP core network 14.
A filtering sub-system 140 is deployed in the IP core network 14, to capture the IP flow 350 between the BRAS 304 and the dedicated IP networking equipment 24 connecting the IP core network 14 and the IPTV servers 16.
The data part of the multicast IPTV traffic comprises multicast RTP IP packets originating from the multicast IPTV server 32 and flowing toward the end user equipments 42, via the dedicated IP networking equipment 24 connecting the IP core network 14 and the IPTV servers 16, the BRAS 304, the intermediate router 302, the DSLAM 300 and the RG 306. The filtering sub-system 140 captures the IPTV traffic from the IP flow 350 between the dedicated IP networking equipment 24 and the BRAS 304.
The signaling part of the multicast IPTV traffic comprises IGMP packets originating from the end user equipments 42 and flowing toward the BRAS 304, via the RG 306, the DSLAM 300 and the intermediate router 302. Ideally, the filtering sub-system 120 would capture the IPTV traffic from the IP flow 352, as close as possible from the BRAS 304. However, in certain deployments, the capture is better performed from the IP flow 354, close to the DSLAM 300. In a typical DSL access network, there is one to a few BRAS 304, compared to hundreds to thousands DSLAM 300. Therefore, there is one to a few points of capture of the IP flow 352, compared to hundreds to thousands points of capture of the IP flow 354. An optimization known as IGMP proxying can be performed at the RG 306, DSLAM 300 or intermediate router 302, wherein several incoming IGMP flows are aggregated in a single outgoing IGMP flow, resulting in a loss of granularity in the IGMP flows. It is then no longer possible to differentiate the IGMP flows initiated by individual end user equipments 42. If such an optimization is performed by means of the intermediate router 302, the filtering sub-system 120 captures the IGMP traffic from the IP flow 354, to keep a maximum IGMP granularity. If such an optimization is performed by means of the DSLAM 300 or the RG 306, the filtering sub-system 100 is used to capture the IGMP traffic from the IP flow 356, to keep a maximum IGMP granularity. This illustrates a case in which a filtering sub-system 100 is deployed at the end user premises 10. The filtering sub-system 100 can be a standalone equipment or it can be integrated as a functionality of the RG 306. If no optimization is performed on the IGMP flows, the filtering sub-system 120 can capture the IGMP traffic from the IP flow 352, as close as possible to the BRAS 304.
The data part and signaling part of the Video (or Television) On Demand traffic consist in unicast RTP, RTSP, HTTP, IP packets exchanged between the Video (or Television) On Demand server 30 and the end user equipments 42, via the dedicated IP networking equipment 24 connecting the IP core network 14 and the IPTV servers 16, the BRAS 304, the intermediate router 302, the DSLAM 300 and the RG 306. The filtering sub-system 140 captures this traffic from the IP flow 350 between the Video (or Television) On Demand server 30, more specifically the dedicated IP networking equipment 24 connecting the IP core network 14 and the IPTV servers 16, and the BRAS 304.
The network architectures described in
The choice of the deployment of the filtering sub-systems 100, 120 and 140 shown in
Regarding the end user premises 10, for a cellular network (
For a broadband network (
Regarding the IPTV multicast signaling traffic originating from the end users (for example to select a TV channel), it has already been mentioned that it is aggregated in the access network 12 for a broadband network. Accordingly, it is not possible to collect the IPTV multicast signaling traffic originating from the end users in the IP core network 14. Thus, a filtering sub-system is implemented in the end user premises 10 or in the access network 12 to capture this IPTV multicast signaling traffic. It has also been mentioned previously, in relation to
Regarding the IPTV multicast data traffic originating from the multicast IPTV server 32 and the Video (or Television) On Demand traffic in both directions, the filtering sub-system to capture this type of IPTV traffic can be located in the IP core network 14. Thus, a single instance of the filtering sub-system can be used for that purpose. In the case of a broadband network, it makes sense to use a single powerful filtering sub-system in the IP core network 14 to capture the aforementioned traffic while multiple less powerful and less expensive filtering sub-systems are deployed either in the access network 12 and/or at the end user premises 10 to collect only the traffic that cannot be captured by the filtering sub-system in the IP core network 14, for example the IPTV multicast signaling traffic.
The filtering sub-system in the IP core network 14 is also well suited for capturing general purpose information not related to any specific end user. This is the case of EPG data since it makes no sense to capture the related traffic at various locations in the access network 12; the same information would be duplicated at each filtering sub-system in the access network 12.
One issue with the use of a filtering sub-system in the IP core network 14 is the deployment of NATs/NAPTs (Network Address Translators/Network Address Port Translators) in the access network 12 and/or IP core network 14 of Telecom Operators. The IP address of the end user is generally used to identify a specific data session involving a specific end user, this IP address being correlated to a fixed identifier, like the International Mobile Subscriber Identity (IMSI) in a cellular network, to uniquely identify end users over time—since the IP address usually changes over time for each end user data session. With a NAT/NAPT, the filtering sub-system in the IP core network 14 may see two different end users as having the same IP address, making it impossible to differentiate these two end users.
As illustrated by the previous considerations, many different cases lead to various options for the deployment of filtering sub-systems. The most probable options are the following. For a broadband network, multiple filtering sub-systems in the access network 12 and a filtering sub-system in the IP core network 14. An alternative can comprise multiple filtering sub-systems at the end user premises 10 and a filtering sub-system in the IP core network 14. For a cellular network, multiple (a few units) filtering sub-systems in the access network 12 and a filtering sub-system in the IP core network 14. An alternative, when such an optimization is possible, is to use either multiple filtering sub-systems in the access network 12 only or a single filtering sub-system in the IP core network only.
In the case of an integrated Telecom Operator, with both cellular and broadband access networks, the IPTV services may evolve towards a converged architecture. This is due to the fact that a single IP core network is used to interact with the different types of access technologies.
Considering the deployment illustrated in
The assumption is made that the multicast IPTV traffic from the end users (for instance IGMP) to select IPTV channels is aggregated at the level of the GGSN 422 connecting the cellular access network 420 with the converged IP core network 440, and at the level of the intermediate router 432 in the broadband access network 430. For this reason, a dedicated filtering sub-system 460 is also deployed in the cellular access network 420 between the SGSN of that cellular access network 420 and the GGSN 422 and a dedicated filtering sub-system 470 is deployed between the intermediate router 432 of the broadband access network 430 and the DSLAM connecting the end user premises 410 with the broadband access network 430. Beyond the GGSN 422 and the intermediate router 432, the signaling multicast traffic from end users to select channels is aggregated and it is no longer possible to identify individual user requests and to count/analyze them. Thus, the centralized filtering sub-system 480 in the converged IP core network 440 cannot be used for that purpose.
Regarding the IP traffic related to the Video (or Television) On Demand service from/to the Video (or Television) On Demand server 454 forming part of the IPTV servers 450, it goes through a convergence router 442 in the converged IP core network 440. Thus, the filtering sub-system 480 in the converged IP core network 440 captures all the IP traffic related to the Video (or Television) On Demand service, be it related to the cellular access network 420 or to the broadband access network 430. From a technical point of view, the Video (or Television) On Demand traffic may as well be captured in each specific cellular and broadband access networks 420 and 430 by the filtering sub-systems 460 and 470, respectively. However, there are several incentives to use the filtering sub-system 480. One of these incentives is that, in the broadband access network 430, many filtering sub-systems 470 may have to be deployed, as already explained in relation to
The multicast IPTV data flows related to the multicast IPTV service, flowing from the multicast IPTV server 452 forming part of the IPTV servers 450 to the end user premises 400 and 410, are also captured by the filtering sub-system 480 in the converged IP core network 440 (for the same reasons as the Video On Demand IPTV traffic).
The main issue related to the analysis of the converged IPTV services as represented in
The IP Multimedia Subsystem (IMS) is considered as one of the appropriate technologies for integrated Telecom Operators to operate different access technologies (cellular, broadband, etc.) in a converged manner. It offers an open architecture, based on standardized protocols such as the Session Initiation Protocol (SIP), Diameter, and many others. It also offers an abstraction layer with no regards as to the type of supported access technologies. In this perspective, the IMS presents the potential to become the central point of control for IPTV, Video (or Television) On Demand and related value added interactive services. As a result, most of the IPTV traffic related to IPTV services (control and data) could be captured by a centralized filtering sub-system such as 480 in
Several issues have a strong impact on the location of the necessary filtering sub-systems in an IMS infrastructure. For example, the IGMP signaling for IPTV in a broadband network is currently limited to the access network. In the case of an IMS integrated cellular/broadband network, some signaling related to IPTV may go through the IP core network, to allow IPTV to be handled as an IMS converged service. In this case, a single filtering sub-system such as 480 of
The IMS infrastructure also facilitates the deployment of interactive value added services related to IPTV. The signaling protocol for these interactive services can be SIP and the data protocol can be HTTP among others. The signaling and data flows related to these interactive services can be extracted by a filtering sub-system such as 480 of
Examples of interactive video services are: presence and chatting with friends directly on TV to share comments on programs, phone calls received directly on TV while watching a channel with calling party identification, interactive TV programs (vote, interaction with TV animator, products purchased directly on TV, etc.). Online Personal Video Recorders can also be considered as an example of such an interactive service. They allow the end user to record its favorite programs on a server located in the Telecom Operator infrastructure, and view them later just like for a Video (or Television) On Demand program.
By matching the data related to pure IPTV services with those related to the associated interactive value added services, the analytic system such as 490 in
Although the present invention has been described in the foregoing specification by means of several non-restrictive illustrative embodiments, these illustrative embodiments can be modified at will, within the scope of the appended claims, without departing from the spirit and nature of the subject invention.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/CA2009/001610 | 11/5/2009 | WO | 00 | 4/23/2010 |
Number | Date | Country | |
---|---|---|---|
61111449 | Nov 2008 | US |