CAP 6 PAR3

identifier as well as service componen! type and protection level to be applied by the channel encoder are given in addition of the length of the respective stream data in the MST fíeld. Of course, data included in the SSTC have to be compliant with those signalled via FIC (i.e. the MCI).
In contrast to STI-D(LI), only streams constituting complete MSC sub-channels can be transported using ETI(LI).
The subsequent end of header (EOH) field comprises not only a CRC for error detection but also 2 bytes of the multiplex network signalling channel (MNSC) to be used for management purposes (see section 6.3.3).
Frame data are completed by a further check sum of the MST contents and the ETI(LI) time-stamp. This time-stamp is for managing delay compensation in the transport network and defines the notional delivery time of the frame at the input of the channel encoder. Time is represented as (always positive) offset to a common time reference, mostly the one pulse per second (1 pps) of GPS. Time resolution is 61 ns. But, in most cases, accuracy will be determined by the accuracy of the time reference. An additional time-stamp is defined at the NA layer (see below).
At the physical layer, ETI(NI) is defined without error protection and therefore is only applicable for restricted use, such as for local connections or test purposes. To form an ETI(NI) frame, frame sync pattern and error status (analogous to STI generic transport frame, see Figure 6.8) as well as frame padding bytes (according to the bit rate used) are added to the ETI(LI). The interfaces ETI(NI,V.ll) and ETI(NI,G.703) are defined in [EN 300799] to support RS432 and PDH-based connections respectively.
For operational distribution networks, ETI(NA) is normally used owing to the provisión of FEC. The interfaces defined in [EN 300799] primarily concern two versions of interfaces compliant to G.704, but adaptation to PDH based on the first hierarchical level of 1544 kbit/s instead of 2048 kbit/s is given as well.
With respect to G.704, the mapping of 24 ms ETI(LI) frames into the correspond-ing multiframes of PDH is defined. There is a trade-off between redundancy used for FEC and the máximum useful bit rate available.
The first versión, ETI(NA,G.704)5592, provides for 5592 bytes of useful data (ETI(LI) data) corresponding to 1864 kbit/s. Further capacity up to the máximum bit rate of 1920 kbit/s is occupied by 40 kbit/s allocated to FEC and 16 kbit/s used for management and supervisión purposes. These data include block counts used for frame synchronisation, a further time-stamp related to an NA link and defining the frame delivery time at the output of the respective converter from the NA layer to the NI or LI layer as well as a Network-adapted Signalling Channel (NASC) (see also section 6.3.3).
The respective figures of the alternative, the ETI(NA,G.704)5376, are 1792 kbit/s for LI data, 112 kbit/s for FEC and again 16 kbit/s for management.
6.3.2 Network Architecture
According to [EN 300799], the DAB distribution network is unidirectional and logically based on point-to-multipoint connections. Figure 6.13 outlines this principie.

Because the radiated signáis in the SFN have to be synchronised not only in frequency but also in time with tolerances of a few microseconds, automatic delay compensation is one of the most important issues. Therefore GPS receivers are usually located at each site involved to cater for the common time reference. Using the ETI(LI) time-stamps, it can be ensured that the overall delay throughout the transport network is always the same for every path between the ensemble multi-plexer and a transmission site. Together with the information about the constant transmitter delay the ensemble multiplexer is able to evalúate the right time to schedule service providers and to signal time in FIC with regard to absolute time outside of the DAB network. See Chapter 7 (section 7.6.3) for details about delay defínitions and treatment.
Network adapters as depicted in Figure 6.13 are needed to convert ETI(LI) into ETI(NA) and vice versa. This functionality is often integrated in the respective devices. The additional NA time-stamp in principie allows for the retiming of NA links, for example in the case of cascading ETI devices. Although support for distributed multiplexing would be useful in some special scenarios, this leads to considerably extra effort regarding synchronised actions and signalling among the sites involved and is therefore not considered further here.
The transport network in between the ETI network adapters can of course make use of further bearer services than PDH as long as G.704 payload can be transported transparently. For instance, additional terminal adapters to comply with SDH or

ATM allow for the use of the corresponding networks. Satellite transmission or radio links are also used alternatively to terrestrial connections.
6.3.3 Network Operation
In the basic configuration, operation of the distribution network has to be performed fully automatically under control of the ensemble multiplexer. In contrast to the collection network, control is straightforward without response from transmission sites via ETI due to unidirectional communication. The basic conñguration of the distribution network can be taken from the ensemble multiplexer using the signalling channels (MNSC, NASC, see also section 6.3.1) to channel encoders.
The MNSC pro vides for 2 bytes per 24 ms frame, that is 667 bit/s at máximum. Messages for frame synchronous and asynchronous signalling are defmed formally in Annex A of [EN 300799]. Frame synchronous signalling can be used to transfer time information. Important applications of asynchronous signalling concern pre-definition of the individual TU and transmitter offset delay (see also section 7.6.3).
In the case when ETI(NA) is applied, the NASC can be used additionally to communicate between ETI(NA) network adapters. It has a capacity of 24 bytes per 24 ms, that is 8 kbit/s. As for the MNSC, frame synchronous as well as asynchronous signalling have been defmed in general, but no application is pre-defined so far.
During regular operation dynamic delay compensation and especially reconfigur-ation of the MSC controlled via ETI(LI) have to be managed automatically. Delay compensation requires careful definition of delay figures and time reference in the network (see above) and will then work reliably.
Dynamic reconfiguration needs control of both the channel encoder and the receiver operated in the coverage área of the respective SFN. Normally, changes have to be accomplished inaudible to the listener and therefore require careful co-ordination.
Figure 6.14 outlines how this can be performed based on frame-related actions carried out by the ensemble multiplexer, see also [EN 300401] and [EN 300799].
The signalling of multiplex reconfiguration starts in advance in the so-called
preparation phase lastíng up to 6 seconds. During this time the ensemble identifica-
tion (FIG O/O) is extended by a byte signalling the instant of planned reconfiguration
in terms of the frame count (occurrence change). Additionally the type of reconfigu¬
ration (sub-channel or service organisation or both will be changed) is signalled by
this FIG at each fourth frame. ,,
In parallel, the current and the next MCI will be signalled at least three times to the receiver using the respective FIGs marking its scope by means of the current/next flag. In particular, only the relevant part of the next MCI, which depends on the type of reconfiguration in turn, is required to be signalled. For instance, only the next sub-channel organisation FIGs (0/1) has to be sent in case the reconfiguration is restricted to that part of the MCI.
Service information related to the next configuration can also be optionally provided in advance during the preparation phase.


The channel encoder is controlled by means of the SSTC included in the header of the ETI(LI) frame. As depicted in Figure 6.14, it is important to note how a certain sub-channel changes in the course of reconfiguration. Owing to the time interleaving process, stream data delivered via ETI(LI) will be spread over 16 consecutive CIFs formed by the channel encoder. Therefore, sub-channels which will be removed or reduced in capacity at reconfiguration instant must be changed in ETI(LI) 15 frames before then.
The ensemble multiplexer has to ensure this by communicating with the respective service provider(s) and taking into account-resource allocation. Bit error measure-ments aimed at single sub-channels, full transmission channel or telecommunication lines are usually based on pseudo-random binary sequences [EN 300799].
6.4 Example of Implementation
As shown in previous sections, a good design of the entire network for the convey-ance of all necessary contributions is a prerequisite for successful DAB operation.
Figure 6.14 Commanding the ensemble reconfiguration via ETKLI)




In the phase before the introduction of regular operation, it was necessary to pro ve the operability of a real broadcast network based on the latest DAB standards. Therefore Deutsche Telekom established a partnership with Fa. Audio Video Tech¬nologies, Fraunhofer Institute Integrated Circuits, and Fa. Rohde & Schwarz with the aim of achieving and testing a complete workable solution.
In 1999 a field test in Berlin pro ved that the designed system and its componen ts were working properly. On the basis of that field test a simple example of implemen-tation focusing on the more challenging collection network will be presented in the following sections, see also [Nowottne, 1998] and [Peters, 1999].
6.4.1 Operational Scenario
In the trial, STI service providers had to be allowed to opérate their own service contributions and supporting signalling. The extent of the latter was comparable to FM/RDS, that is both static information such as service labels, programme types and announcement support, but also dynamic changing information such as supporting traffic announcements via STI. Decentralised initiation of reconfiguration was needed to start broadcasting. To prevent failures, all specifications from the STI service providers had to be based on STI resource allocations provided via STI by the enseñable multiplexer and had to be supported by appropriate tools. Additionally, non-STI service providers had to be integrated into the collection network.
Figure 6.15 shows the STI-based collection network as used in the field test. For instance, two STI service providers opérate audio encoders MAGIC/STI for the generation of audio streams, optionally including insertion of PAD. Other service providers feed their service components to the ensemble multiplexer without using
STI. Moreover, externally provided packet mode data stream, delivered in STI-D formal, can be fed to the ensemble multiplexer directly or inserted by the MAGIC/ STI service multiplexer. The MAGIC/STI interface to the ensemble multiplexer corresponds to STI(PI,G.704/2) and comprises both STI-D and STI-C with transport adaptation. As the ensemble multiplexer the DM001/STI by Rohde & Schwarz was used. MAGIC/STI as well as DM001/STI are connected via RS232 with PCs, working as service controller and ensemble controller, respectively.
As required, the system is also able to cater for non-STI service providers. In this case the ensemble provider takes the role of a proxy relating conñguration and signalling.
6.4.2 The Service Provider Profíle
The efficient treatment of resource allocation and consistency checking in an oper-ational collection network is based on so-called Service Provider Profiles (SPPs). This has to be done by the ensemble provider in arrangement with service providers.
Each service provider is allowed to manage services independently within the constraints of the SPP. It is the task of the ensemble multiplexer to supervise the service provider's actions to ensure impact-free running. The management processes are performed and monitored by means of the STI control part, on which the service controller and ensemble multiplexer communicate.
Figure 6.16a outlines the contents of the applied SPP, as stored within the datábase of the ensemble multiplexer. These data comprise information on the service
provider's address and basic entitlements, about capacity and coding resources, as well as other parameters.
Figure 6.16b gives an idea of the way it works. It has to be distinguished between central specification and decentralised application. SPPs speciñed and stored at the ensemble provider are downloaded to the service providers and define their frame of action. The ensemble multiplexer supervises their operation, responds to change requests and carries out the changes if possible. Otherwise it rejects requests or reacts with error messages.
6.4.3 Equipment in Use
Two basic devices form the hardware basis of the introduced collection and distribu-tion network: the MAGIC/STI Audio Encoder and Service Multiplexer by Fa. Audio Video Technologies and the DAB Ensemble Multiplexer DM001/STI by Fa. Rohde & Schwarz complemented by their Frame Decoder FD1000 for monitoring and analysis of both STI and ETI.
The structure and components of the Ensemble Multiplexer DM001/STI are depicted in Figure 6.17. The common clock and time reference is provided by an exteraal GPS receiver. The DM001/STI is connected via an RS232 interface to its ensemble controller. Using this computer-based device the ensemble controller soft¬ware, running under WindowsNT®, supports STI-C-like communication with the multiplexer.
It is possible for the operator to define and download complete ensemble configu-rations each consisting of an EPP (Ensemble Provider Profile), several SPPs and all other ensemble-relevant parameters. To illustrate operation, the steps necessary to start broadcasting from the very beginning at the ensemble multiplexer are usted in the following:
1. Basic configuraron of the DAB ensemble multiplexer, including
- definition of DAB mode and external clock source (2.048 MHz from GPS)
- definition of transport network and transmitter delay
- definition of ETI type, for example ETI(NA,G.704)5592
2. Specification of an ensemble confíguration consisting of one EPP and several SPPs
a) Specification of the EPP
- allocation of ensemble identifier (EId) and ensemble label
- stipulations for the FIC (FIC capacity and FIGs allowed to send)
- specification of a FIG file including FIGs for signalling of ensemble infor-mation
b) Specification of SPPs for all service providers
- allocation of service provider identifier (SPId)
- allocation of resources (MCI and FIC capacities, coding ranges, streams, etc.)

- stipulalions tor the FIC (FIGs allowed to send, announcemeni param-eters)
•- speciñcation of physical input;
c) Additional specifícatiou of MCI and SI (íur .nun-STI service providers oniyS 3. Manual or scheduled dovvnioad of the ensemble Configuration specified i.inciuding valid tiine).
The DMUOl'STi will theu genérate the ETi stream according to the specifications downloaded. A recoafiguration vviil be carried out and the STI-C(TA) control connections to the STI service providers will be opened. After ihat. the STI service providers are able to define their virtual ensemble and to initiate reconfigurations of iheir owu.
Moaitormg of the ensemble mullipkxer can be done by means of the status windovvs at the ensemble controller. Additionally a log file will be generated to store messages about all relevant events. A tnessage brcwser for filtered evaluatiou of the log file ¡s alse provided.


Hgure 6.18 displays the conditions at the service provider side. The M AGIOS í 1 system provides not only sufficient audio encoding functionality but also realisation of service múltiple*, that is severa! services or service components can be handled.
MAGIG'STI basic umts can be expanded by up to seven further encoders. if several audio signáis are to be encoded at the same locaíion. Encoders are also able to inserí PAD mto the audio data stream. Audio signáis are fed either as anaiogue signáis or as digital AES/EBU signáis.
The output interface complies with G.703/G.7Ü4 (2Mbit/s). Additionally data services m packet mode format can be insertetí vía the STI-D input. Runnmg under WindowsNT". the service controller software consists of three major modules:
» Main manager
* Control file manager
* FÍG encoder.
The rnain manager controls, in a central function. coilaboralion with the
MAGICSTI audio encoder(s) and service multiplexer. It accepts inputs from the
serviee provider operator and serves ío define and adminístrate the stre.ams to be
handled. It is also used to speeify. scheduled actions, to estabhsh'é^fe-triggered
signalling and co-ordinate collaboration with the control file niaa.and FIG
•encoder. • •

In its datábase the main manager stores all information relating to configurations and schedules. The control file manager complements the main manager in specifying and monitoring the respective MCI configuration, the specification of the virtual enseñable. Based on the SPP the service provider operator is able to specify sub-channei and service organisation, that is assignment oí bit rates, start addresses. protection levéis and so on. Consistency of the defined configuration is checked imrnediately.
The task of the FIG encoder is to provide FÍG data for insertion into the FíC of the DAB signal. Since FIC data origínate at the service provider and at the enseñable provider as well. the FIG encoder can be used by both sides equally. At the service provider side the FIG encoder supports the encoding of static and quasi-static FIG data, Resuhing FIGs are embedded within FIG files and transponed vía STI-C to the enseñable provider in order to be stored there and passed into the ET1 data stream if activated. Conversely, FIG data from the enseñable multiplexer datábase can be recailed and depicted for monitoring purposes. In order to initiate signalüng vía the FIG file mechanism. the service provider software can be coupled to the studio control process, For instance, announcement switching can be event triggered accordingly.
Furthermore, precautions have been mipiemeated lo adapt the whole network solution to a sepárate quality supervisión system of the DAB network opera! or.
6.4.4 Experieace and Outlook
The siepwise-developed broadcast network solution was thoroughly tesled in the laboratory. After this, a field test within L-band DAB net-Berlín was carried out successfully.-Two broadcasters were selected to pía y the role of ST1 service providers. while the ensemble multiplexer. encompassing four further service providers. was operated by Deutsche Telekona.
The fieíd test has provided evidence that the implementation fulfils the require-ments of reliable handling of the services and supporting signalüng within the collection and distribution network. For instance, the successful - operatiou of trafile announcements as a necessary fea ture in DAB as ií is in FM/RDS has been an important result. With respect to the exisíing infrastructure of the STI broadcasters. two possibilities of event-oriented FIG file activation control were applied: manual triggering of announcements from the programme moderator's button, as weíl as announcement triggering by derived signal from the studio operating system. Of course. the overal) signal delay of the DA.B chain has to be taken into account by the speaker, that is the speaker cannot start an announcement imrnediately after actu-ation of the procedure.
AIso, Imking functionality worked well- by application of STI in both cases:
» Explicit signalüng with service linking FIG 0/6
•» Impücit signalüng based on idéntica! codes for FM/RDS PJ code and SId of DAB.
The developed network solution corresponds to 6TI Level 3 according to
[TS 101860]. This offers the chance to support regular DAB operation at a aood
leve!, and actually to exploit the superior svstem features of DAB in companson to
FM/RDS. In future it vvill be importara to make further progress concerning en-
hanced management ísee section 6.2.6.) as well as provisión of open and interoperable
svstem solutions.