- Joined
- 3 Nov 2010
- Messages
- 31,509
- Solutions
- 3
- Reaction score
- 52,734
In an exclusive and wide-ranging interview, we speak to Simon Orme, Director of Content Services at BT, who explains the thinking behind the service, how it is much more than just an upgrade to multicast, how it might benefit from a standardised approach to content encryption, and what it could potentially mean for the YouView project and for the local TV initiative of Jeremy Hunt, UK Culture Secretary.
TV Connect appears to be a major new IP television initiative from BT that has somehow slipped underneath the radar. Firstly, what is the service, and what role will the ongoing upgrade of BT's broadband network to multicast play?
We have talked a little bit about TV Connect at a number of conferences over the past six months, but it is still in the order of 12 months away, so there is still no launch plan or focused communications or activity around this, and the way we have communicated this is really appropriate for what it is, which is that in our view it is a natural extension of the strategy we have been laying out, and it is something that we have been working on for a long time because it is a huge project.
We kicked off TV Connect in 2009, although it didn't get formalised as a project until the middle of 2009, when it started to be recognised as part of the delivery programme for BT Wholesale. It has been worked on "under the wires" as it were, because it is a big project.
The thinking around it all stems from the strategy we have laid out, which is our intent to position "broadband as a television platform". At every conference I talk at, I wheel out this phrase, because I think underneath that phrase is everything that we are doing, it just depends on how you want to interpret each of the words in that sentence. In my mind, as soon as you have the words TV and platform in the same phrase, you have to be talking about live television - a means of delivering live television - and so it was implicit to me all the time, although we weren't speaking about it explicitly until more recently.
We started to expose what the whole portfolio of content delivery services would look like three to five months ago - starting at the IP&TV World Forum in London last March - as an extension of managing VOD content, managing live content in a unicast mode, and then managing content in a multicast mode, so this is sort of an evolution for us.
What we are really trying to do here is meet the needs of two communities: one is the television industry, and as soon as we talk about multicast we are primarily talking about the broadcast part of that industry, and of course the other side of our customer community, which is the ISP and operator community. There are massive benefits to both in engineering a multicast solution, it has really been a question of when is the right time to introduce that, and we have felt that the way in to this market is to build our on-demand platform - our Content Connect platform - get that into the market first and start the process of building the commercial models around that and customer engagement models around that, and then bring in the bigger development some time later, which is the TV Connect element.
Although the technologies of TV Connect and Content Connect are very different - the boxes that are being used and the way it is being delivered - in terms of a customer conversation, particular with the content provider side of that customer equation, if you are talking to a broadcaster about how they optimally deliver their content online, the fact that it is on-demand, unicast or multicast is of less relevance. It is one big story to the content provider, you wouldn't generally talk about one without talking about the other, so within the conversations about online media distribution, there are some techniques we might use for different elements of that service, but what we are trying to do is build a holistic story for the online industry, which we see as comprising both the content community and the carrier community, of how we create a valuable and sustainable business for online media distribution, and multicast is an absolute key part of that.
If we look at the other side of the equation, at the challenges that an ISP has in managing online video, a lot of the problems that we see being aired very vocally in this space are more around video than any other traffic category. This is partly because with video the file sizes are large, and the bit rates are very high, and so on and so forth, but although we estimate that live traffic represents between 15-20% of online hours viewed, in terms of the proportionate pain that it causes ISPs, which is proportionate to peak bandwidth consumed, live is that much more painful than VOD, and that pain can be resolved with multicast.
In an IPTV News interview with Anthony Rose (then CTO of the YouView project) last year in the wake of the 2010 FIFA World Cup, he spoke enthusiastically about the potential benefits of multicast delivery for online video. Especially with the 2012 London Olympics coming up, broadcasters would surely see TV Connect as a potentially huge enabler for their online delivery plans?
The London 2012 Olympics next year will make this a massive, massive issue - the BBC will be the biggest-ever host broadcaster of the Olympics, so they will have all of that content to deliver, and they have extremely ambitious plans, so it's going to create some very significant challenges. I happen to believe that what you tend to see with these one-off phenomena in the online space is that the traffic and behaviour don't revert back to where it was before, but rather they peak and then stabilise at a significantly higher level, because consumers who were not viewing online before have been educated that you actually can. You bring into the community a whole load of new consumers, you broaden the base of consumption, so the traffic never goes all the way back down again.
The key thing to understand about TV Connect is that we have not positioned it as a multicast service - that is possibly why the language has not leaked itself outside the company as multicast. We could have built a multicast-enabled network and then just sat back and seen what happens, but we don't believe that is going to answer the problem. What we have actually built with TV Connect is an end-to-end linear TV delivery service, so the ingress point into the TV Connect product is a broadcast feed. An SDI (Serial Digital Interface) broadcast feed would come in at the top of the platform, so TV Connect includes a TV headend - the live real-time encoding of that content down into a format that is appropriate for linear TV delivery. It includes the content protection, conditional access and DRM (Digital Rights Management) functionality, it includes the creation of the appropriate hooks for EPGs (Electronics Programme Guides) to work with.
Would ISP customers be limited in which channels they can offer?
The way the commercials are planned to work is that it is up to the ISP to secure the carriage deals that they want with the broadcaster - that is their role - so if they can secure the appropriate carriage deal then they can come to us and we can enable that service for them. I think one of the challenges here is in the area of standardisation: if we were to launch the service today, what would happen is that multiple ISPs (we hope) would come into this platform, and each one of them might have a different set-top box, a different view on TV resolution, on DRM, on a number of different things, so you might end up sending channel X three or four times, which kind of undermines some of the premise of multicast.
What we are anticipating happening, in line with other trends in the industry, is increasing standardisation of those kinds of issues. And the commercial benefit to ISPs is very, very large: if ISPs can start to think about standardising common resolution, common H.264-type video standards, and so on and so forth then it will make the platform much more economical and much more attractive. Those are the kinds of things strategically that we are working on, and of course there are a number of initiatives within the Digital TV Group [an association for the UK digital television industry] and other regulatory bodies concerned with finding ways to standardise, particularly around DRM - I think that DRM will be one of the key ones, I think persuading ISPs that the right resolution and the right H.264 variant ought to be relatively straightforward, I think ISPs may still want to work with different types of DRM, depending on what type of device they are going to deliver to, because it might not be a set-top box, it might be a Connected TV for example, but one of the very interesting areas of standardisation that's going on within the industry is re-architecting the way DRM works.
We are a member of the DTG and of the other body which is appropriate to this, which is Ultraviolet from the DECE (Digital Entertainment Content Ecosystem), which is led by the TV Movie studios. Both of these deal with very similar issues, including the move to separate the encryption layer, an AES (Advanced Encryption Standard) layer from the key management layer, so that in principle we can see a route to a world not that far away from now where you could be running a standard encryption process as part of your headend, but each individual operator runs different DRM, such as Marlin, or Windows DRM, or Apple DRM etc etc, but they would all be running on the same encryption base, and that is perfectly viable in this wholesale model - that is exactly the way our wholesale model is designed, so that the retailer entity, whoever they are, manages their own key, their own EPG look and feel, user experience, we are just providing the enabling delivery technology underneath.
What Quality of Service mechanisms have you built into TV Connect?
Quality of Service is built into the delivery architecture: Quality of Service works differently in a multicast world than in an online world, because multicast isn't using native TCP (Transmission Control Protocol). That is one of the challenges of multicast is that you ping out your UDP (User Datagram Protocol), which has no inbuilt QoS (Quality of Service) mechanisms. So this is one of the areas that we have been spending a lot of effort on, and we continue to spend a lot of effort to refine the techniques that we use, which are a combination of two things: firstly classic forward error correction, which is to say building more padding into the packet as you send, so there is more intelligence in the packet should errors occur, versus what's called "reliable delivery", which is where you back-fill the delivery with unicast packets, so that the player recognises that it has missed a packet, and then requests that packet, which is actually delivered from the CDN or from some CDN source.
The other part of the Quality of Service story is how you engineer the delivery network itself - one of the key things about TV Connect, one of the most exciting things about it, stems from our philosophy of "How do we deliver an end-to-end linear TV service" rather than "How do we build a multicast product". We are not actually delivering TV Connect through the broadband route, we are delivering it from the headend directly into the exchanges, and that has effectively enabled us to build a television network, as opposed to having to find a way to push multicast television through the broadband network.
In other words you are circumventing the broadband network?
We are using the same physical infrastructure, but we have set up different virtual paths into the exchange, so that the TV Connect traffic combines with the broadband traffic in the last mile (the dedicated piece of copper or fibre that goes into the customer's home) - it avoids having to fight with the congestion within the broadband access network.
The other benefit is that because we have been building broadcast television networks for years, we have a whole load of technical "smarts" that enables us to do proactive network monitoring: we have robots in the network, and all of this kind of smart stuff that we have had for years in our global broadcast network, that we have been providing the global broadcast network industry with for many years, and we are able to deploy those kinds of techniques into the TV Connect network, because it is a dedicated television network, and it is not fighting with other traffic.
The story about TV Connect is not just that it is multicast, although it is obviously a massive deployment for us, but it is actually the engineering of a dedicated television network for online TV distribution.
What are the likely time frames for this project?
All that we are able to say at the moment is that we will bring this to market within the next 12 months: there is still a lot of work to do, we have been in technical trials for quite a while, and we are planning to move to a small-scale market-based trial later in the year, in the summer, but the service will actually be "launched" in 2012, although we don't have any firmer dates on that at the minute.
What will this mean for BT Vision? Does it mean that all linear channels on the BT Vision service will start to be delivered via IP?
I can't really comment on BT Vision's plans - they are a customer of the service, and for that reason we can't talk for them. In broad terms, we expect ISPs to see the opportunity to deliver live TV channels over their network. Our sense is that it is less likely to be applicable to free-to-air channels, the way we originally laid out the plans for this TV Connect product is that it is more likely to be taken up by the pay-TV market - in other words enable revenue-generating services for ISPs - and one of the interesting things about this is that there are some really interesting benefits from doing things in this way.
The economics for a broadcaster with a relatively small and thinly-spread audience using TV Connect are far better than, for instance, for a channel with a very large audience, which can justify the very large fixed fees that broadcasting brings with it - whether that is DTT spectrum or satellite spectrum - as these tend to be fixed-fee costs of hundreds of thousands or even millions of pounds sterling a year, regardless of whether you have one viewer or ten million viewers.
Those economics tend to work very well if you are a large-scale channel, but I think one of the beauties of network IP multicast is that there is a greater element of user-based variability in the cost. For channels with small audiences, it is much more economical, and one of the things that we haven't seen yet is that it is also more economical if your channel is more local. The economics of multicasting to a community in Liverpool or Manchester on an IP multicast model are going to be far more appealing than having to buy national spectrum on satellite or DTT for just that marketplace.
This would be a perfect fit then for the local TV project of Jeremy Hunt (UK Culture Secretary)?
That is certainly one of our thoughts. And of course the whole local TV marketplace has been in the doldrums for the last few years, and the economics have started to look very horrible, and the primary broadcasters have started to cut down or withdraw completely from this area, so what we are thinking is that TV Connect will stimulate a new growth within the broadcast industry that can't exist today with its current economics.
It is quite hard to build business models for the future - we can map out how we think today's broadcast industry might work with carriers to create online multicast distribution, but it is very hard for us to predict what new innovations this might stimulate in the next three to five years. We know for example that in our broadcast services business, we launched the Eurobird service to allow smaller channels to get onto the Sky platform at much lower costs - I can't remember what the economics were, but it practically halved the economics overnight - and it just spawned literally hundreds and hundreds of channels coming into the market that otherwise couldn't have survived: TV Connect is much more disruptive or radical than that, and we are anticipating a new wave of innovation in the television on the back of it.
What might be the implications of TV Connect for YouView?
I think YouView will be a major catalyst for TV Connect: the YouView partners are planning to support multicast within the YouView specification, so at some point in the service's evolution the set-top boxes will be multicast-ready, and clearly because there will be a huge marketing drive behind the deployment of those boxes, and we anticipate large-scale take-up, that is going to be one of the catalysts we think of multicast adoption. And also because YouView is a joint venture between the ISP industry and the broadcast industry - all of those things make it a perfect fit for the TV Connect model, and of course part of the TV Connect thinking was in anticipation of YouView coming to market.
sorce- http://www.iptv-news.com/iptv_news/june_2011_2/tv_connect_is_actually_the_engineering_of_a_dedicated_television_network_for_online_tv
TV Connect appears to be a major new IP television initiative from BT that has somehow slipped underneath the radar. Firstly, what is the service, and what role will the ongoing upgrade of BT's broadband network to multicast play?
We have talked a little bit about TV Connect at a number of conferences over the past six months, but it is still in the order of 12 months away, so there is still no launch plan or focused communications or activity around this, and the way we have communicated this is really appropriate for what it is, which is that in our view it is a natural extension of the strategy we have been laying out, and it is something that we have been working on for a long time because it is a huge project.
We kicked off TV Connect in 2009, although it didn't get formalised as a project until the middle of 2009, when it started to be recognised as part of the delivery programme for BT Wholesale. It has been worked on "under the wires" as it were, because it is a big project.
The thinking around it all stems from the strategy we have laid out, which is our intent to position "broadband as a television platform". At every conference I talk at, I wheel out this phrase, because I think underneath that phrase is everything that we are doing, it just depends on how you want to interpret each of the words in that sentence. In my mind, as soon as you have the words TV and platform in the same phrase, you have to be talking about live television - a means of delivering live television - and so it was implicit to me all the time, although we weren't speaking about it explicitly until more recently.
We started to expose what the whole portfolio of content delivery services would look like three to five months ago - starting at the IP&TV World Forum in London last March - as an extension of managing VOD content, managing live content in a unicast mode, and then managing content in a multicast mode, so this is sort of an evolution for us.
What we are really trying to do here is meet the needs of two communities: one is the television industry, and as soon as we talk about multicast we are primarily talking about the broadcast part of that industry, and of course the other side of our customer community, which is the ISP and operator community. There are massive benefits to both in engineering a multicast solution, it has really been a question of when is the right time to introduce that, and we have felt that the way in to this market is to build our on-demand platform - our Content Connect platform - get that into the market first and start the process of building the commercial models around that and customer engagement models around that, and then bring in the bigger development some time later, which is the TV Connect element.
Although the technologies of TV Connect and Content Connect are very different - the boxes that are being used and the way it is being delivered - in terms of a customer conversation, particular with the content provider side of that customer equation, if you are talking to a broadcaster about how they optimally deliver their content online, the fact that it is on-demand, unicast or multicast is of less relevance. It is one big story to the content provider, you wouldn't generally talk about one without talking about the other, so within the conversations about online media distribution, there are some techniques we might use for different elements of that service, but what we are trying to do is build a holistic story for the online industry, which we see as comprising both the content community and the carrier community, of how we create a valuable and sustainable business for online media distribution, and multicast is an absolute key part of that.
If we look at the other side of the equation, at the challenges that an ISP has in managing online video, a lot of the problems that we see being aired very vocally in this space are more around video than any other traffic category. This is partly because with video the file sizes are large, and the bit rates are very high, and so on and so forth, but although we estimate that live traffic represents between 15-20% of online hours viewed, in terms of the proportionate pain that it causes ISPs, which is proportionate to peak bandwidth consumed, live is that much more painful than VOD, and that pain can be resolved with multicast.
In an IPTV News interview with Anthony Rose (then CTO of the YouView project) last year in the wake of the 2010 FIFA World Cup, he spoke enthusiastically about the potential benefits of multicast delivery for online video. Especially with the 2012 London Olympics coming up, broadcasters would surely see TV Connect as a potentially huge enabler for their online delivery plans?
The London 2012 Olympics next year will make this a massive, massive issue - the BBC will be the biggest-ever host broadcaster of the Olympics, so they will have all of that content to deliver, and they have extremely ambitious plans, so it's going to create some very significant challenges. I happen to believe that what you tend to see with these one-off phenomena in the online space is that the traffic and behaviour don't revert back to where it was before, but rather they peak and then stabilise at a significantly higher level, because consumers who were not viewing online before have been educated that you actually can. You bring into the community a whole load of new consumers, you broaden the base of consumption, so the traffic never goes all the way back down again.
The key thing to understand about TV Connect is that we have not positioned it as a multicast service - that is possibly why the language has not leaked itself outside the company as multicast. We could have built a multicast-enabled network and then just sat back and seen what happens, but we don't believe that is going to answer the problem. What we have actually built with TV Connect is an end-to-end linear TV delivery service, so the ingress point into the TV Connect product is a broadcast feed. An SDI (Serial Digital Interface) broadcast feed would come in at the top of the platform, so TV Connect includes a TV headend - the live real-time encoding of that content down into a format that is appropriate for linear TV delivery. It includes the content protection, conditional access and DRM (Digital Rights Management) functionality, it includes the creation of the appropriate hooks for EPGs (Electronics Programme Guides) to work with.
Would ISP customers be limited in which channels they can offer?
The way the commercials are planned to work is that it is up to the ISP to secure the carriage deals that they want with the broadcaster - that is their role - so if they can secure the appropriate carriage deal then they can come to us and we can enable that service for them. I think one of the challenges here is in the area of standardisation: if we were to launch the service today, what would happen is that multiple ISPs (we hope) would come into this platform, and each one of them might have a different set-top box, a different view on TV resolution, on DRM, on a number of different things, so you might end up sending channel X three or four times, which kind of undermines some of the premise of multicast.
What we are anticipating happening, in line with other trends in the industry, is increasing standardisation of those kinds of issues. And the commercial benefit to ISPs is very, very large: if ISPs can start to think about standardising common resolution, common H.264-type video standards, and so on and so forth then it will make the platform much more economical and much more attractive. Those are the kinds of things strategically that we are working on, and of course there are a number of initiatives within the Digital TV Group [an association for the UK digital television industry] and other regulatory bodies concerned with finding ways to standardise, particularly around DRM - I think that DRM will be one of the key ones, I think persuading ISPs that the right resolution and the right H.264 variant ought to be relatively straightforward, I think ISPs may still want to work with different types of DRM, depending on what type of device they are going to deliver to, because it might not be a set-top box, it might be a Connected TV for example, but one of the very interesting areas of standardisation that's going on within the industry is re-architecting the way DRM works.
We are a member of the DTG and of the other body which is appropriate to this, which is Ultraviolet from the DECE (Digital Entertainment Content Ecosystem), which is led by the TV Movie studios. Both of these deal with very similar issues, including the move to separate the encryption layer, an AES (Advanced Encryption Standard) layer from the key management layer, so that in principle we can see a route to a world not that far away from now where you could be running a standard encryption process as part of your headend, but each individual operator runs different DRM, such as Marlin, or Windows DRM, or Apple DRM etc etc, but they would all be running on the same encryption base, and that is perfectly viable in this wholesale model - that is exactly the way our wholesale model is designed, so that the retailer entity, whoever they are, manages their own key, their own EPG look and feel, user experience, we are just providing the enabling delivery technology underneath.
What Quality of Service mechanisms have you built into TV Connect?
Quality of Service is built into the delivery architecture: Quality of Service works differently in a multicast world than in an online world, because multicast isn't using native TCP (Transmission Control Protocol). That is one of the challenges of multicast is that you ping out your UDP (User Datagram Protocol), which has no inbuilt QoS (Quality of Service) mechanisms. So this is one of the areas that we have been spending a lot of effort on, and we continue to spend a lot of effort to refine the techniques that we use, which are a combination of two things: firstly classic forward error correction, which is to say building more padding into the packet as you send, so there is more intelligence in the packet should errors occur, versus what's called "reliable delivery", which is where you back-fill the delivery with unicast packets, so that the player recognises that it has missed a packet, and then requests that packet, which is actually delivered from the CDN or from some CDN source.
The other part of the Quality of Service story is how you engineer the delivery network itself - one of the key things about TV Connect, one of the most exciting things about it, stems from our philosophy of "How do we deliver an end-to-end linear TV service" rather than "How do we build a multicast product". We are not actually delivering TV Connect through the broadband route, we are delivering it from the headend directly into the exchanges, and that has effectively enabled us to build a television network, as opposed to having to find a way to push multicast television through the broadband network.
In other words you are circumventing the broadband network?
We are using the same physical infrastructure, but we have set up different virtual paths into the exchange, so that the TV Connect traffic combines with the broadband traffic in the last mile (the dedicated piece of copper or fibre that goes into the customer's home) - it avoids having to fight with the congestion within the broadband access network.
The other benefit is that because we have been building broadcast television networks for years, we have a whole load of technical "smarts" that enables us to do proactive network monitoring: we have robots in the network, and all of this kind of smart stuff that we have had for years in our global broadcast network, that we have been providing the global broadcast network industry with for many years, and we are able to deploy those kinds of techniques into the TV Connect network, because it is a dedicated television network, and it is not fighting with other traffic.
The story about TV Connect is not just that it is multicast, although it is obviously a massive deployment for us, but it is actually the engineering of a dedicated television network for online TV distribution.
What are the likely time frames for this project?
All that we are able to say at the moment is that we will bring this to market within the next 12 months: there is still a lot of work to do, we have been in technical trials for quite a while, and we are planning to move to a small-scale market-based trial later in the year, in the summer, but the service will actually be "launched" in 2012, although we don't have any firmer dates on that at the minute.
What will this mean for BT Vision? Does it mean that all linear channels on the BT Vision service will start to be delivered via IP?
I can't really comment on BT Vision's plans - they are a customer of the service, and for that reason we can't talk for them. In broad terms, we expect ISPs to see the opportunity to deliver live TV channels over their network. Our sense is that it is less likely to be applicable to free-to-air channels, the way we originally laid out the plans for this TV Connect product is that it is more likely to be taken up by the pay-TV market - in other words enable revenue-generating services for ISPs - and one of the interesting things about this is that there are some really interesting benefits from doing things in this way.
The economics for a broadcaster with a relatively small and thinly-spread audience using TV Connect are far better than, for instance, for a channel with a very large audience, which can justify the very large fixed fees that broadcasting brings with it - whether that is DTT spectrum or satellite spectrum - as these tend to be fixed-fee costs of hundreds of thousands or even millions of pounds sterling a year, regardless of whether you have one viewer or ten million viewers.
Those economics tend to work very well if you are a large-scale channel, but I think one of the beauties of network IP multicast is that there is a greater element of user-based variability in the cost. For channels with small audiences, it is much more economical, and one of the things that we haven't seen yet is that it is also more economical if your channel is more local. The economics of multicasting to a community in Liverpool or Manchester on an IP multicast model are going to be far more appealing than having to buy national spectrum on satellite or DTT for just that marketplace.
This would be a perfect fit then for the local TV project of Jeremy Hunt (UK Culture Secretary)?
That is certainly one of our thoughts. And of course the whole local TV marketplace has been in the doldrums for the last few years, and the economics have started to look very horrible, and the primary broadcasters have started to cut down or withdraw completely from this area, so what we are thinking is that TV Connect will stimulate a new growth within the broadcast industry that can't exist today with its current economics.
It is quite hard to build business models for the future - we can map out how we think today's broadcast industry might work with carriers to create online multicast distribution, but it is very hard for us to predict what new innovations this might stimulate in the next three to five years. We know for example that in our broadcast services business, we launched the Eurobird service to allow smaller channels to get onto the Sky platform at much lower costs - I can't remember what the economics were, but it practically halved the economics overnight - and it just spawned literally hundreds and hundreds of channels coming into the market that otherwise couldn't have survived: TV Connect is much more disruptive or radical than that, and we are anticipating a new wave of innovation in the television on the back of it.
What might be the implications of TV Connect for YouView?
I think YouView will be a major catalyst for TV Connect: the YouView partners are planning to support multicast within the YouView specification, so at some point in the service's evolution the set-top boxes will be multicast-ready, and clearly because there will be a huge marketing drive behind the deployment of those boxes, and we anticipate large-scale take-up, that is going to be one of the catalysts we think of multicast adoption. And also because YouView is a joint venture between the ISP industry and the broadcast industry - all of those things make it a perfect fit for the TV Connect model, and of course part of the TV Connect thinking was in anticipation of YouView coming to market.
sorce- http://www.iptv-news.com/iptv_news/june_2011_2/tv_connect_is_actually_the_engineering_of_a_dedicated_television_network_for_online_tv
