Digital Television Basics: Tutorial
Multimedia Home Platform (MHP)
Download 96.85 Kb.
|
- Navigate this page:
- Near Video on Demand
- Service Information
- Transmission
- Web Browsers
Multimedia Home Platform (MHP) One of the most important documents on the future of digital television has recently been approved by the DVB Project. The work of the Multimedia Home Platform committee, it sets out a migration path to an open standards future which will allow the market the freedom to develop wide ranging innovative products. Up to now, digital television services, although based on DVB standards, have proprietary elements within them which make it difficult, for example, to add a satellite 'sidecar' to a terrestrial receiver, or vice versa. Obviously multiplex operators who started services before recent standards emerged, defend their positions and rightly claim that the standards making work, which includes strategies for migration and gives them time to deal with legacy boxes without jeopardising their commercial investment. The UK Terrestrials have no reason to be smug, however. Although the MHEG-5 API they have adopted is likely to have a place in the new standard, the fact is that everyone will have to cope with regular upgrades, just as Windows 3.1 moved to Windows 95. The analogy is not complete however, becauseWindows 3.1 users could chose to continue just as they were - in a broadcast situation, users of older spec machines expect them to continue to work when the broadcaster upgrades,even if they can't avail themselves of all of the new features. The need for 'backward compatibility' is at the heart of the debate and the DVB Project, based at the EBU headquarters in Geneva, offers the right forum for industry experts to come up with the best technical for the commercial requirement. In the UK, the ITC are proposing to add support for the MHP standards as a requirement to licensees. None of this matters very much to the viewer who, today, just wants to watch television but for an industry beginning to come to grips with the issues of convergence, some quiet satisfaction is in order that they have managed to get the 'route map' in place. More information from www.dvb.org (opens in new window).
If you are anything like me, the one thing you can bank on is that BBC, ITV, Channel 4 and 5 for that matter, will start their feature films at an inconvenient time (to me). For example, Channel 4 features are a lost cause, because my mum told me most severely before I left home that I must be in bed by eleven. I try to use the video but I either forget to program it or it gets lost with all the others that I failed to label! So, if Saturday night viewing looks awful, we call by the video store on the way home from shopping. Thats good, because we can press the play button when we want to. Now, all this is not lost on broadcasters fighting for every percentage point rating and digital compression offers the tools to fight back ... near-video-on-demand or NVOD for short. The principle is simple. If you've got more channels than you know what to do with, why not use a block of, say, six of them to play the film with staggered start times. That way your viewer is never more that 20 mins away from the start of the film whenever he (or she) sits down. And that is the way you'll see it on Sky Movies or Front Row on cable. But not, unfortunately, on DTT - alas, poor dears, they don't have enough bandwidth for NVOD. But, maybe I'll be eating my words in a year or two for the following reason. Nowadays, broadcasters don't play their movie channels from banks of videotape machines - they use a computer fileserver which can output several channels from the same file on hard disk store. 
Using statistical multiplexing, it is possible to vary the datarate share between channels so that difficult pictures are given more bandwidth instantaneously and easy ones less. And if, as is the case with NVOD, the file or files are pre-recorded, then it is possible to do some pretty sophisticated (and lengthy) 'robbing Peter to pay Paul' calculations before transmission to achieve acceptable pictures at average datarates as low as 2Mb/sec or even less. We shall see! Security Introduction Security means different things to different people. To the programme distributor, security concerns the risk of pirating of valuable programme inventory; to the multiplex operator, security is the risk of a rogue application crashing the customer's boxes; to the customer, security is the risk of his or her credit card details being stolen during a transaction; to the merchant and bank, it is the risk of repudiation of a purchase. Security is multifaceted and complex; it is part technical and part legal, and requires commercial judgements to direct the technical aspects.
For the downloadable applications, security covers the authentication of applications/data, their integrity and consequent certification. It is necessary to differentiate between the technical aspects and the policy aspects of the security model. In particular, the policy aspects have to address the way to handle authenticated applications vs non-authenticated applications.
Another method for enforcing security is to use legal means, such as copyright laws, contracts between the participants in the broadcast chain, agreement between the broadcaster and the regulator, etc. Authentication Authentication is provided by digitally signing the content. The signature verifies that the content has not been modified after signing it. The signature can be verified by the MHP terminal by using the certificates. The certificates contain a public key that is used for verifying the signature and information about who the signing party is. In order to ensure that the certificate has not been modified, it is again signed by a higher layer Certifying Authority. The topmost certificate in the hierarchy belongs to a so-called Root Certifying Authority. There can be any number of Root Certifying Authorities; however, the certificates of the Root Certifying Authorities need to be stored in the MHP terminal, to allow for verifying that they are valid. Now the question is what does the signing actually provide? Essentially it provides only a guarantee that the content has not been modified after signing and the certificates provide information about who signed it. It should be noted that the same content as well as the certificates may be signed by multiple parties - i.e. this is not limited to only a single signature. What can the receiver then do with this information? Essentially this all depends on the policy of how the Root Certifying Authority issues the certificates to the different parties. There can be various policies associated with issuing the certificates. Examples of possible policies are:
The receiver can use the authentication information for determining what kind of privileges are given to the application. The Java environment allows for very fine grained control of this. Possible choices are:
It should be noted that the authentication is useful only for protecting the receiver and/or the end user from possibly hostile applications; it does not provide technically viable mechanisms for any protection of the content in a unidirectional broadcast environment (this is provided by encryption which is completely separate from authentication). Now, it is clear that the authentication information can be used for determining what to do with the content. The question that needs to be answered is: who is in control of the receiver and decides which Certifying Authorities the receiver trusts, etc. It is clear that this party that controls this aspect of the receiver is the ultimate gatekeeper that decides which content runs on the receiver and which doesn't. In the vertical markets this typically has been the operator. It should be noted that technically it is fully possible that the end user has this control and makes these decisions. Naturally, this can vary between different receivers and possibly depend on the end user's relation with the receiver (i.e. does the end user own the receiver or not, did he pay the full price for it or not, etc.). However, it should be decided which of these possible models the MHP specification should support. Another question is: is there a limited number of Root Certifying Authorities or should anyone be allowed to become a Certifying Authority? What are the premises for a security model to be put in place ? There has to be a root certifying Authority. The certifying Authority has to provide the manufacturers with root-certificates. It is worth noting that there is no secret to be embedded in the MHP : The certificates provided to the manufacterer are public and contain public keys. Note also that the Model has to account for revokation of root/non-root certificates. Security on the return channel There is a need to address the security on the return channel. Before to address the technical issues, some scenarios are needed. The main applications involving the return channel are, amongst others e-commerce or telebanking. It is worth noting that the security that we have to address here relates to the security of the content. The e-commerce field is a tremendously growing activity that involves many technical and legal aspects. It is all the more complex because :
Debit Card Payment techniques The user simply communicates its card number and expiration date to the server in the clear. This mechanism is obviously the simplest one. However, it has the following drawbacks :
Electronic Purse To solve the problem of micro-payments, some companies have created systems enabling the user to store money in an Electronic Purse. In a E-Purse transaction, only the merchant server and the end-user are involved. No authentication server is involved here.
Practically, there are two ways to make the transaction secure :
SET
SET™ (Secure Electronic Transaction) is an international standard whose aim is to provide the adequate level of security that is expected for secure transactions. It allows for use of sofware security, and also allows to integrate chip-card technologies. (SETv2) Chip-card standards There are a lot of chip-card technologies specified by different Bank Consortia in the various countries. Examples of these are BO' in France, WG10 or TIBC in Spain. These technologies specify application protocols on top of ISO 7816 for debit transactions, or Electronic Purse Transactions. Data to be sent to the merchant server depend on the chip-card technology. It is worth noting that all the existing technologies do not account for micropayments yet. EMV (Europay, MasterCard and Visa) is a new standard, whose aim is to merge the various chip-card standards, and which will be deployed around 2002. Conclusions The aim of this paper is to give a very brief overview of some of the existing technologies, that are sometimes orthogonal to each other. The requirements for secure electronic transactions can be found in the SET specifications. The acceptance of the SET standard is not know yet, nor is known the impact of this technology on STB implementations. SET is not incompatible with the future chip-card international standard EMV. It is not clear however how these technologies will be merged. SSL is a widely-accepted tool enabling to have a 'secure pipe' between a client and a Server. This is at the moment the tool that is the most often used tool for transaction services on Internet. The resolution of technical / regulatory aspects of e-commerce is being driven by large interests focussing on trading from pcs. API developers cannot influence these developing standards to any great degree. The aim should be to provide a flexible and layered specification that will enable to smoothly integrate the e-commerce technologies when they are clearly specified and defined. Further, should any standard be defined that encompasses all the aspects of secure transactions, it should allow to account for the Set-Top-Box capabilities and limitations. This document is an edited version of a paper prepared by the DVB Multimedia Home Platform Technical Group. Service Information Introduction The DVB has prepared a specification for Sl to accompany broadcast DVB signals, intended to assist the receiver/decoder and the viewer to navigate through the array of services offered. (ETSI draft standard prETS 300 468 and associated Guidelines Document ETR 211.)
Networks are assigned individual network_id values which serve as unique identification codes for networks. Each NIT_actual must list:
NITs may contain the tuning information that can be used during the set-up of a receiver/decoder, including alternative frequencies for each unique multiplex. SDT The Service Description Table lists the names and other parameters associated with each service referred to. Service descriptors for other transport streams are optional. The service_id is a unique identifier of a service within a transport stream. It is thought that the ITC will want to manage / regulate the allocation of Sevice IDs. The service_ID contains a Running Status field which, for example, coupled with a linkage descriptor, can be used to implement BBC opt-outs and may be used to describe the change from GMTV to ITV Companies on ITV1. EIT The Event Information Table (EIT) is used to transmit information relating to the events (programmes) in the MPEG transport stream. It is mandatory to transmit an EIT for present-and-following events ("now-and-next") in the actual transport stream and optionally covers future events in the same transport stream. EITs can also be transmitted for events in other transport streams, thus allowing the viewer to select programmes on other services. EITs also contain a Running Status field which can be used to initiate a vcr record function shortly before a selected programme starts. TDT The Time and Date Table is used to update the receiver/decoder's internal clock. The optional tables are as follows: Other NITs, SDT, EITs are used to give details of other multiplexes, services and events. RST At a programme junction, the change of present and following information may be delayed due to the cycle time of the SI information. If required a Running Status Table may be used more accurately signal the status of an event, although this information is continually available from EIT_p/f. BAT A Bouquet Association Table provides a means of grouping services to allow a service provider to point to other services on other multiplexes, including cable or satellite if desired. For example, Granada might use a bouquet association table on its terrestrial transmissions to point to GSkyB services on satellite. The use of multiple bouquets is allowed. Particular Problems of Terrestrial (a) Digital terrestrial television is fundamentally different to satellite in the large number of transmitters in a network. The SI received by the IRD has to take account of widespread overlap area conditions, such that an individual receive aerial installation may well offer a choice of frequencies for a network, which may or may not contain regional variations. It thus seems desirable for the SI for a particular main station to include information about adjoining regions which may be receivable by a particular aerial installation. In the design of the SI system, there is the twin risk of either not providing pointers to available multiplexes, or of pointing to multiplexes which are not available. The only solution is for the IRD to correlate SI information with its own local knowledge of available digital services derived during installation. The Scheme Proposed for DTT in the UK In course of preparation. Transmission COFDM
Coded Orthogonal Frequency Division Multiplexing (COFDM) was largely developed into a practical proposition by the CCETT in France in the late 1980s, although the idea of OFDM was originally propounded elsewhere. It found its first major application in Digital Audio Broadcasting (DAB), developed in the Eureka 147 project. Many organisations and collaborative projects subsequently took up the idea of COFDM for application to digital terrestrial television, including CCETT ("Sterne"), the Nordic HD-Divine, HDTVT in Germany, ITC ("Spectre"), RACE dTTb project, Thomson, BBC, etc. COFDM is a system of modulation well-suited to the propagation and interference environment of terrestrial broadcasting in the VHF (used in UK for DAB) and UHF bands (used in UK for DVB-T). It uses a large number of carriers, each carrying a small part of the total coded data rate. The frequency spacing is carefully chosen to ensure "orthogonality" - the carriers do not crosstalk one to the other, despite having spectra which overlap in the frequency domain. The low data rate per carrier itself reduces the susceptibility to multipath, because the symbol period is quite long compared with the likely echo delay. And it makes it feasible to enhance the multipath immunity substantially by the addition of a guard interval. Each symbol is transmitted for a period which is longer (by the guard-interval duration) than the period during which the receiver examines it. The guard-interval duration is chosen to be just greater than the expected spread of multipath delays for any particular application. The immunity to multipath reflections is a particularly important property which can also be exploited in so-called single frequency networks, where a chain of transmitters can all use the same frequency for transmission - the delayed signals from distant transmitters just appear to the receiver as echoes within the guard interval duration. The use of coding (the "C" of OFDM) is an important factor in coping with both co-channel analogue TV interferers and the frequency-selective fading caused by multipath. The predominant effect of co-channel analogue TV interfererence is to corrupt only a few carriers (those lying around the vision carrier, and to a lesser extent around the sound carrier and colour sub-carrier). There is plenty of information in the many unaffected carriers for the coding to repair this damage. Thus DVB-T is robust against co-channel interference from analogue TV. It is also fairly benign as an interferer to analogue TV, as it is similar in character to flat noise and will also be transmitted at a much lower power level than analogue TV, thanks to its smaller signal-to-noise ratio requirement. These two factors explain how it has been possible to fit new digital services into a UHF spectrum already crowded with analogue transmissions. The development of the DVB-T system specification was taken on by a collaborative group called the Task Force on System Comparison (TFSC), comprising representatives from BBC, CCETT, CNS, DLR, IRT, ITC, Philips, RAI, Tele Danmark, Teracom and Thomson, and was adopted by DVB and ETSI. The Plan for the UK Estimates use a 1km sq grid. The figures quoted are the populations within grid squares where it is predicted that at least 90% of viewers will be served. It should be noted that reception of digital signals is a bistable event - it either works or it doesn't - and the predictions have assumed an ideal ITU standard aerial installation. Common sense suggests that people often have very sub-standard installations and are content to watch truly awful pictures. It thus raises the debate as to whether people should be allowed to buy digital terrestrial receivers as a "carry away" purchase, or whether the sale price should include a professional installation or checkup. Number of Carriers To take advantage of OFDMs capability for single frequency networks, the DVB originally defined a system using 8,000 carriers, the so-called 8k system. However, there were concerns about the additional complexity of an 8k system, so DVB allowed the use of 2000 carriers (2k) as an alternative for early implementation and the ITC have specified 2k carriers in their requirements for digital terrestrial in the UK. 2k gives very restricted capability for single frequency networks but, in the UK, the plan is to use 81 of the existing main transmitter sites such that a s.f.n. would not have been appropriate. In the event, it now appears that most STB / receiver implementations will offer 2k / 8k switchable, such that a single implementation can be used across Europe. Datarates and Bit Budgets Within COFDM transmission, there are a number of parameters that directly affect the datarate of the signal. The method of modulation (QPSK, 16QAM, 64QAM), the code rate and the guard interval can be varied to achieve an optimum compromise between datarate and robustness of signal. QPSK is most robust but achieves datarates only up to 10.6Mb/sec., 16QAM can achieve a maximum of 21Mb/sec and with 64 QAM, over 30Mb/sec can be achieved but with increased liability to interference. In the UK situation with 2k carriers, the NTL have predicted interference limited coverage, using three different systems:
The failure point figures are approx 3db above the theoretical figures given in prETS 300 744 but have still to be confirmed by field trials. The coresponding coverage figures are as follows:
So, moving to 64QAM increases the possible datarate to 24Mb/sec but reduces the predicted service areas by a significant amount. There is concern, too, that the coverage may become patchy and unpredictable with 64QAM, giving problems to retailers at the sharp end of selling receivers. Coverage Predictions A word is in order on how population coverage predictions are made and what they mean. The steps in the process are as follows: (i) Firstly a field strength prediction is made from ERP and terrain profile information, on a 1km grid, assuming an omni-directional transmit antenna. (ii) The field strength prediction is then modified by the designed radiation pattern of the antenna, taking account of any needs to reduce interference in adjacent areas. (iii) The field strengths of co-channel and adjacent-channel interfering signals are then compared and grid squares where there is significant interference removed from the coverage profile. This has to consider separately both analogue and digital transmissions. Three different coverage predictions may be quoted - the so called 90% cut-off method, the proportional method, and the composite coverage method. In all cases, a log-normal distribution about a mean signal strength is assumed; in other words, if calculations show a certain mean signal strength, then a proportion of households are assumed to have greater and less signal strength according to a log-normal curve. (The BBC and NTL have their own special algorithms in areas of urban clutter which can give rise to differences) In the 90% cut-of method, the population of a grid square is only counted if it is calculated that 90% of households will be able to receive an acceptable signal. Any less than 90% and the reception is considered doggy and not counted. In the proportional method, the percentage of housholds in each square is counted, usually down to a 50% cut-off, even though reception may be a bit hit-and-miss. Lastly, a composite coverage figure may be quoted in overlap areas. If transmitter A is calculated to serve 80% of the households in a grid square and transmitter B is calculated to serve 60% of households, the the composite coverage is calculated as 80 + 60% of the remaining 20% = 92%. The number of households in each grid square is derived from a Post Office address file which gives the number of households for each 6 digit postcode. Digital predictions have been based on 1993 figures. The number of viewers is calculated using a figure of 2.39 viewers per residential address, with the exception of N. Ireland, where a figure of 3.0 is used. Limitations of Coverage Predictions Coverage predictions use a standard ITU defined aerial which has a 15dB front-to-back ratio. Thus, whilst signal strength on a set-top aerial will be considerably worse (How much?) it is also possible to install a significantly better aerial (how much) in cases of marginal reception prediction. Digital reception is calculated to be largely interference limited, so a more directional aerial will be of more help than a head-amp. The methods of prediction used are inherently conservative, so coverage is likely to be greater than prediction, though it cannot be guaranteed. Because digital signals will will fail suddenly, rather than degrade as with analogue, a 3dB margin above cut-off has been assumed, so it is said that digital will usually work where analogue reception is poor. However, without statistically sound evidence of practical installations, that is unsubstantiated. Web Browsers One of the most difficult issues to deal with in the development of an API for digital television is the provision of a web browser for internet surfing. It is difficult for several reasons:
Up till now, the approach has been to implement the so-called 'walled garden' environment, where the user logs onto a special ISP (internet service provider), whose server translates requested content on-the-fly to make it suitable for the set-top box. WebTV was the first example of this approach. This solves all three problems in one go - upgrades can be performed on the broadcaster's server without any change to the viewer's box - and it also has the advantage (?) of locking the viewer onto the broadcaster host. However, this is not the only model and many take the view that the set-top box browser should have the same freedoms as the pc. So the quest is on for a micro-browser without the bloatware of pc browsers. It is not just the set-top box industry that has this ambition - the mobile phone industry want to put visual content onto their tiny screens, a far greater problem in some ways. With the bubble of success driving them, it is likely that ready-made solutions from their industry could be applied to the set-top box much quicker than starting from scratch. Microsoft is pushing Windows CE as the operating system for mobile phones as well as set-top boxes and Sun have their HotJava microbrowser - both familiar names to the API developer. But there are others which may be worth looking into. AOL / Netscape have a microbrowser called Gecko; 3Com have recently acquired French company Smartcode Technologies that has a microbrowser product and UK based STNC also has its HitchHiker microbrowser. Ericsson has a mobile phone running with the Symbian operating system and HitchHiker, though Symbian recently brought Sun into its partnership to add the flexibility of Java to its offering. So there is a real prospect of acquiring a ready-made application as a hand-me-down from mobile phone developers. Download 96.85 Kb. Share with your friends:
|