"If somebody could stop technology we would have still been in the stone ages. Technology and Innovation cannot be stopped by apprehensions or bureaucracy. "
- After listening to so many Apprehensions
My dear friends of transmission fraternity,
I hope all of you had a very nice weekend and here I am to release another post that is based on Multicast. In the last post we got a fair amount of Idea of Conditional multicast and how it actually works in the network. IGMP v2 and IGMP v3 were also explained through a RFC link. As we go higher up the technology implementation there would be some amount of deviation that will happen from the transmission. Evolving in Telecom is actually to go up the layers of the OSI model. As a Telecom engineer we are actually expected to reach at least to Layer-4 from the classical Layer-1 or now even Layer-0.
1. How an IPTV network looks like
The difference between normal TV and an IPTV is actually the "interactive" nature of the TV services. IPTV actually helps the user to interact with the TV provider so as to have supreme experience of Television viewing. The user can change camera angles, see a summary of all the channels by PIP, see polls and popularity, take an active part in TRP generation, watch video on demand for many channels and so on.
Typically an IPTV network looks like the following architecture as shown below.
|Block Diagram of an IPTV network generally deployed|
As we can see in the figure the IPTV network is a layer of many MPLS networks that are doing Multicast and Unicast transmission. It is not necessary that all the networks may be owned by a single operator. Different parts of network may be owned by different operators and the revenue can be shared on the basis of signals and distribution only. Due to the CAS regulations it is apparent that all the channels are made visible or available at all the parts of the network to actually reach the users. Each and every object shown as the cuboid have different function and different revenue model in the IPTV systems.
SHO stands for Super Hub Office and SHE stands for Super Head End. Most of the times they are co-located at one place. However, there may be cases where the SHE is the point where only the Feed is taken from National Channels and then there may be multiple SHO that actually take the input from the SHE. The content that is taken in the SHO are generally as follows.
> National TV Channels (channels that are applicable all across the country/ Region)
> Universal video content for VoD (Video on Demand).
> Any content from other source when can be transcoded to a TV channel.
2.1 Live TV Acquisition:
The diagram below shows the typical architecture of a live TV acquisition System in the SHO
|Figure Describing the Live TV acquisition system and final ingestion to the network|
As we can see in the figure the live TV channels are fed by means of the dish array that is there in the SHO/SHE. The dish Array feeds the system to a Encoder which actually provides an IP to these channels. The encoder defines a channel by a particular multicast IP and that is from where the IP output starts to be ingested to the system. One Encoder may cater to one or more channels and there may be redundancies of encoders as well.
The encoder out actually goes to an aggregate switch network that actually sends the respective encoder signals to an acquisition server. One Acquisition server has 2X1Gb/s NIC for in and the same for out. Depending on the total number of channels and the expected redundancies in the system there may be a number of Acquisition servers available in the network.
To understand how much Bandwidth may be required per channel the dimensioning of the Acquisition servers may be done in that respect. Please keep in mind that some amount of margins should be kept in such cases for any data spike or untoward incidences.
SD Channels - 3-5 Mbps
HD Channels - 8-15 Mbps
Audio Channels - 1Mbps
One NIC of the Acquisition server is that of 1Gb/s so based on that there can be a distribution of the channels across the servers and also there can be a planned m:n redundancies.
The output of the Acquisition servers are finally aggregated on a Switch that provides a 10Gb/s or nX10Gb/s output to the Core MPLS router. The redundancies are also understood clearly. From here the signals are entering the network and sent via the multicast IP network.
As told in the article before, at this state there is no need for conditional multicast as most of the content is sent via plain multicast to the system.
2.1 The VoD (Video on Demand) System in the SHO:
There may be a kind of argument that the VoD is more often localized to the VHO, however, the SHO also has servers of VoD that have video content that are catering to a viewing of the entire Country or Region. The SHO maintains a proper storage of the video content that can be watched over the video in the storage servers. This actually helps to ease out the load in the VHO, where the content that is popular every where may not be maintained individually.
The VoD distribution in the SHO may contain static video as well as the video that may be sourced from the live TV channels and that may be watched later. This sourcing may be operator influenced or user influenced. Mostly user influenced storage is not done in the SHO level it is more importantly done in the VHO level, which we will understand in the next post.
The schematic of the VoD flow in the SHO is provided below.
|Video on Demand in the SHO|
As we can see that there is static content in the VoD system flow as well as Live content. Each of the video content may have a specific IP that may be actually available as a separate stream in the EPG. Mind it, that the VoD traffic flow unlike the live TV is Unicast. Needless to say there will be more BW consumption if most of the VoD content is always there in the VHO locally stored that becomes popular. There can be also an implementation of a dynamic object cache in that respect, which understands the full logic of popularity vs the demand of the content in the VoD system flow.
A part of the system is also made up of Catchup storage content that the user may want to store now and see later. Catchup storage in the SHO is generally operator influenced rather than it being user influenced. There may also be a kind of a link from the catchup storage to go to the static storage. Each of this content can also be watched as per the broadcast message and user request from each VHO.
3. Summary Block Diagram of the SHO:
So to summarize the SHO or the Super Hub office can have a block diagram as shown below.
|Generic Block Diagram of the SHO|
As you can see clearly that the sections we covered the Live TV acquisition and the VoD segment is there in the system. However, what is interesting is that apart fro mthe Live channel delivery there is also a kind of interface to the OTT (Over the Top).
While video is already been watched in the form of Live TV and VoD for the managed customers (Customers who are subscribed to the services) of the IPTV operator, the video or the content is also in the form of unmanaged content in the Internet, so that the same content can be watched, provided a proper App is available to watch it, over a Tablet, mobile or many such devices. OTT or over the Top content actually helps the customers to have an access on Live streaming, catchup video and video content in a PAID or a FREE option as decided by the operator.
The OTT mode of transport provides an additional aspect of the revenue for the operator for the content. This revenue may come in the form of advertisements or Pay per view from the user.
We will study more on the OTT aspect as we go forward.
There is a lot....lot.....lot more to be explored in the field of multicast and Television. While most of us, network guys, working with tier-1 operators are conversant on the Mobility transport and some ways the Fixed line Data transport as well, this particular field of IPTV transmission is really interesting to know about. Multicast delivery and IPTV is the future growth aspect of telecom also in India and this has to be understood very clearly. Although, I also am also not an expert, I am trying to aggregate and place in this platform most of which I know. I am confident that in the future, you will be able to explore more articles on the same and may have even more knowledge on the same aspect. Needless to say, I would also request each and every one of you to share your knowledge also in this interactive forum. Also share the blog post with your friends, acquaintances and rivals.
Till then, bye, take care.