For a long time the audio-visual world has been highly fragmented among different business players with sometimes overlapping roles. Two-way speech communications, audio and television broadcasting, audio and video distribution on package media and on cable see intertwined relationships among different business actors in some cases with a role of operators of an infrastructure, in others as producers of content and in some others with overlapping roles.
This complicated pattern used to be the excuse, if not the justification, of the existence of a plurality of incompatible systems, as information was supposed to flow from source to destination using just one delivery medium, flow of information across media not being intended.
This arrangement is being shaken to its roots by the advent of digital technologies. Because "bits are bits", once audio and video information is converted into digital form, any digitised delivery medium can be used to carry audio-visual information. If the current paradigm of incompatible systems were confirmed and every delivery medium were to set technical specifications independently, the end user would find himself with a multiplicity of sources of information represented by means of bits with an audio-visual meaning different from one delivery system to another. This, in addition to being irrational because the underlying common nature of digital audio and video, runs also counter to the interest of the differnt players, in particular the end users.
This would be a typical issue to be settled by appropriate standards. Unfortunately, standards bodies are still organised along traditional vertically-integrated systems with objective difficulties in addressing cross-system issues. The problem is exacerbated by the current speed of technology which forces an accelerating decision-making pace.
There is no time to lose. Either an effective means of defining horizontal standard cutting across applications is found or the opportunity of putting things right in this epochal conversion from analogue to digital is lost forever.
This paper is about the initiative of creating the Digital Audio-Visual Council, an organisation working with the goal of providing specifications that maximise interoperability across countries and applications/services.
The absence of an environment able to address interoperability issues across applications and services and across countries and the realisation that one needed to exist is at the root of the Digital Audio-Visual Council (DAVIC). DAVIC was conceived at the end of 1993 and a first meeting convened in Geneva in March 1994. In August 1994 DAVIC had already been formally established in Geneva as a non-profit Association. Its purpose, as set in the Statutes, is to favour the success of emerging digital audio-visual applications and services by the timely availability of internationally agreed specifications of open interfaces and protocols that maximise interoperability across countries and applications/services.
Membership in DAVIC is open to any corporation and individual firm, partnership, governmental body or international organization. DAVIC does not restrict Membership on the basis of race, colour, sex, religion or national origin. By joining DAVIC each Member agrees - both individually and collectively - to adhere to open competition in the development of digital audio-visual products, technology or services. Associate Member status is usually chosen by those entities, mostly government organisations, who do want to be members of the Council without taking an active role in the precise technical content of the specifications.
DAVIC Members are not restricted in any way from designing, developing, marketing or procuring digital audio-visual hardware, software, systems, technology or services. Members are not bound to implement or use specific digital audio-visual standards, recommendations and DAVIC specifications by virtue of their participation in DAVIC.
The (September 1995) DAVIC membership of 200 corporations represents 25 countries from all over the world and virtually all business communities with a stake in the emerging field of digital audio-visual applications and services.
Fig. 1 gives the current organisational structure of the Council. All DAVIC members are represented in the General Assembly (GA). The GA elects the Board of Directors (BD). Besides Finance and Audit (FA), and Membership and Nominating (MN) Committees there are three more Advisory Committees: Standardisation (ST), Strategic Planning (SP) and Management (MC). The technical work is carried out by Technical Committees (TC), under the supervision of the MC. Six TCs have been established: Applications, System Integration, Server, Delivery Systems , Set-top Unit and Technology.
Fig. 1 DAVIC organisation
DAVIC has developed its own philosophy of work to reach its statutory goals of producing technical specifications providing interoperability across application and countries overcoming the current limitations of standardisation.
The need to be able to respond to the changed needs of standardisation still requires that the specification development process be open. Although only DAVIC members are allowed to take part in DAVIC meetings, these are the steps taken by DAVIC to open specification development process and make the specifications available:
DAVIC has substantially innovated the way specification work is defined, approved and executed. Purpose of this paragraph is to give a brief description.
As other standard bodies DAVIC activities are structured on the basis of work items (WI). These are the new systems, tools, profiles and reference points that need to be added to the DAVIC specifications and at what time they are needed. The DAVIC workplan (WP) is the collection of all active and planned work items.
The WP is produced by the Board of Directors using a draft proposed by the Strategic Planning Committee. The proposed WP is submitted to the membership for comments and a final WP taking the comments into account is approved by the General Assembly. Complementary to the WP is the "Inventory of Standards and Specifications of potential DAVIC interest" produced by the Technology TC using information coming from standards bodies, industry consortia and individual members.
When a new WI is to be activated a Call for Proposals (CFP) is produced and made known to the membership and all interested parties. Submissions are screened to identify whether, for any of the items requested in the CFP, there is sufficient technology either through submissions or from available standards. If, for any item, insufficient technology is available, another call for these items is issued or a decision to develop the necessary technology internally is made.
Submissions retained for consideration and standards identified to be relevant for the work item are assigned to the appropriate TCs. On this occasion existing TCs may be disbanded and new TCs may be established to provide a better match between the kind of technologies to be specified for the particular new WI and the organisation of work. TCs are given a precise duration of time to produce the version of DAVIC specifications corresponding to the current work item.
A TC produces progressive revisions of the DAVIC specification part(s) assigned to it. In its technical work a TC is driven by the basic requirement of delivering specifications of the highest possible quality within the given deadline. A TC Chair will usually assign sufficient time to clarify an issue and will resort to membership voting when consensus cannot be reached. Of course only one tool may be specified for any functionality. As a principle, specifications draw elements from existing standards, but TCs, in making their decisions, also balance other criteria such as technical merit, cost and wide usage.
When specifications have reached a sufficient degree of maturity they are "frozen". The meaning of "frozen" is that all multiple choices for a DAVIC tool have been reduced to just one. When this is achieved the document is made public, i.e. known also outside the DAVIC membership, and comments are solicited from anybody.
DAVIC holds regular quarterly meetings which typically last five working days. DAVIC weeks usually involve all TCs and the MC. All work is done by Member representatives physically present at the meeting. The work of a DAVIC week is coordinated by the General Assembly meeting in plenary sessions. Plenaries are usually held three times, at the beginning of the first day, on the third day, and at the end of the fifth day. MC meetings are held every day at different times of the day, however, at the end of every working day TC Chairs and Vice Chairs are usually asked to join the MC.
The main purpose of a DAVIC week is to produce either the initial version or the next revision of the DAVIC specifications currently under development. Using the procedure described above the TCs work towards the goal of producing either the initial version or next revision of the part(s) of the specifications they are responsible for. The TCs attempt to reach a consensus on a sequence of issues and on rare occasions they may need to resort to TC membership voting.
Even though on certain issues there are joint TC meetings, the component parts of the specifications are usually so interrelated that daily harmonisation and coordination meetings are called at the initiative of the MC and are attended by TC Chairs and Vice Chairs as required. This process is usually repeated every day of the meeting.
A further synchronisation and consensus building point involving all delegates occurs at the mid-week plenary where short reports are made by the different TC Chairs on the progress of work of their TCs.
In the general case, because of the many synchronisation meetings, the recommendations proposed by the different TCs at the final plenary meeting are accepted, possible modifications being agreed upon by consensus. On certain rare occasions during the final plenary, an issue already resolved by one or more TCs during that week may be the subject of reconsideration if two or more members request a membership vote. At such time as the Chairman of the General Assembly deems that the issue has been sufficiently debated, a vote can be taken of all Members present.
The results of a DAVIC meeting are summarised in a set of approved resolutions, including the recommendations produced by the TCs.
In the current phase of work DAVIC is concentrating on digital audio-visual applications and services of broadcast and interactive type and Fig. 2 is a very general representation of the system being addressed. It comprises 5 entities: the content provider system, the service provider systems and the service user system; the three entities being connected by two entities - delivery systems - the first connecting the content provider to the service provider and the second the service provider to the service user.
As a rule DAVIC specifications contain normative and informative parts. Normative parts have to be implemented as in the specifications in order to claim conformity of a subsystem to DAVIC specifications. Informative parts are included as well for the purpose of clarifying the normative parts of the specifications and to give general assistance to implementors of specifications.
DAVIC specifications contain the reference model of the DAVIC system and its subsystems. DAVIC specifications also define reference points, i.e. points of particular interest in the system. These points have a normative value if they are accessible. Therefore a digital audio-visual subsystem conforms to DAVIC specifications if its accessible reference points do. This means that a subsystem can be considered as a black box and DAVIC specification conformity is only assessed at the external reference points.
DAVIC specifications define the technical "tools" whose use allows the provision of "functionalities" required by the DAVIC system and the applications that make use of it. Tools are usually associated with grades that determine the level of performance of a given tool, e.g. mono-stereo-multichannel audio, TV-HDTV, bandwidth of a return channel etc.
Fig. 2 - The general DAVIC system
DAVIC specifications are issued in versions: DAVIC 1.0, DAVIC 1.1 etc. The current DAVIC 1.0 version of specifications defines a first set of tools enabling the deployment of systems that support initial applications such as TV distribution, near video on demand, video on demand and some basic forms of teleshopping. Each future version will specify different grades of previously defined tools or more tools in addition to previously specified tools.
Even if DAVIC defines only one tool per functionality the toolkit nature of DAVIC specifications would lead to too many incompatible instantiations of subsystems. It is therefore necessary to define groupings of tools with associated grades which are deemed to have a particular value in the application domain. These serve as a guidance to manufacturers and application providers, are called profiles and have normative value.
DAVIC specifications are developed by making use of the best available technologies or combinations thereof and as far as feasible are validated by technical interoperability tests. Because of the toolkit nature of the specifications, however, no claim can be made as to the suitability of DAVIC specifications or of any of its parts for any intended purpose of a user.
As a rule DAVIC specifications are accompanied by documents specifying methods to test the conformity of reference points to the specifications.
DAVIC 1.0 is organised in 11 parts. These can be classified in three groups, as indicated in Tab. 1. Parts in Group 1 identify all the tools that are necessary to build DAVIC-conforming systems. Parts in group 2 describe how the three main DAVIC subsystems can be assembled using the tools of group 1. Parts in group 3 address system-wide issues.
Part no. |
Title |
Version |
|
Group 1 |
Tools |
||
7 |
High-layer and Mid-layer protocols | DAVIC 1.0 | |
8 |
Lower-layer protocols and physical interfaces | DAVIC 1.0 | |
9 |
Information representation | DAVIC 1.0 | |
10 |
Security | DAVIC 1.1 | |
11 |
Usage information protocols | DAVIC 1.1 | |
Group 2 |
Subsystems |
||
3 |
Service Provider System architecture and interfaces | DAVIC 1.0 | |
4 |
Delivery System architecture and interfaces | DAVIC 1.0 | |
5 |
Service Consumer System architecture and interfaces | DAVIC 1.0 | |
6 |
Content Provider System | DAVIC 1.2 | |
Group 3 |
System-wide issues |
||
1 |
Description of DAVIC System functions | DAVIC 1.0 | |
2 |
System reference models and scenarios | DAVIC 1.0 | |
12 |
Dynamics, reference points, and interfaces | DAVIC 1.0 | |
13 |
Conformance testing | DAVIC 1.1 |
This paragraph illustrates the particularly important role played by tool relocatability in supporting the security functionality. It also elaborates on the meaning of downloadability in the Service Consumer System (SCS).
Fig. 3 below is a possible model of an SCS which is in general composed of 4 subsystems:
The Security subsystem is very important because it controls the way information is consumed. It may happen, therefore, that a network operator is willing to be the guarantor of secure delivery of information to the final user. In this case some of the tools, typically "Security Filter" and "Descrambling" will be resident in the NIU (which is likely to be owned by the network operator), while "Security Management" is likely to be resident in the STU. In other cases all of the Security subsystems will be resident in the STU.
DAVIC does not issue specifications where the location of a tool, which can have multiple locations, is determined a priori, because DAVIC is the place where all those with a stake in digital audio and video can find their needs recognised. Part 10 (Security) will also be published in December 1995, but will not be normative, in the sense that specifications will not appear there yet, as they are planned to be developed for DAVIC 1.1. can find a technical solution to their exploitation plan.
The following guidelines for development of DAVIC 1.1 security tools have been agreed:
Fig. 3 - Schematic diagram of a Service Consumer System
Downloadability, a subtler form of tool relocatability, is becoming more and more important because the progress of microelectronics is such that even complex algorithms can be executed on generic programmable processors. Flexibility of software implementation can lead to implementation of modules identified in an SCS in hardware or software or a mix of both technologies, modules can be grouped in different ways and need not be physically or logically identifiable and modules can be split in submodules and these can be grouped to produce modules having functions different from those described in the figure.
What is the meaning of interoperability in an environment where downloadability is possible? It is to be noted that an Service Consumer System whose software modules are partly or wholly downloaded can claim conformity to this DAVIC 1.0 specification only if, after software downloading, it can successfully execute DAVIC 1.0 applications, i.e. applications built using information representation tools defined in part 9 "Information representation".
As mentioned before DAVIC published its specifications in versions. DAVIC 1.0, currently being developed, will be published in December 1995. A Call for Proposals has been issued in September 1995 and the corresponding specifications will be published in June 1996. A fourth Call for Proposals will be issued in December 1995 and the corresponding specifications will be published in December 1996.
This information is contained in the DAVIC workplan. This is divided in three sections:
Section 1: Items for DAVIC 1.1;
Section 2: Items for DAVIC 1.2;
Section 3: Future items.
The most important DAVIC 1.1 sub work-items, requested by Call for Proposals #3 are:
The most important DAVIC 1.1 sub work-items, that will be requested by Call for Proposals #4 are:
The third section contains items which will be specified in future activities, e.g.
DAVIC has a vision of a digital audio-visual world, where producers of digital audio-visual content can reach the widest possible audience, users have seamless access, carriers can offer effective transport, and manufacturers can provide hardware- and software to support unrestricted production, flow and use of information has been accepted by a large number of companies throughout the world. The DAVIC 1.0 specifications agreed at the Berlin meeting in December 1995 are a proof that it is possible to make that vision real.
| Dr. Leonardo Chiariglione | Tel. | +39 011 228 6120/6116/5111 |
| Multimedia and Video Services | Fax | +39 011 228 6299/6190/5520 |
| CSELT | leonardo.chiariglione@cselt.it | |
| Via G. Reiss Romoli, 274 | URL | http://www.cselt.it/leonardo/ |
| I-10148 Torino (ITALY) |