CAP 6 PAR2

demónstrales both cases.
6.2.2 Network Architecture
Figure 6.9 Physical connections of ST/-D and STI-C (examples)
According to [EN 300797] the collection network is logically based on point-to-point connections forming a tree-like hierarchy of entities. Figure 6.10 outlines this by means of an example. It should be recalled that diverse physical connections between entities can be implemented.


Figure 6.9 Physical connections of ST/-D and STI-C (examples



Figure 6.10 Tree-structured DAB collection network (example)
Each entity can be classified by a type according to its role in the network [TS 101860], As already introduced in section 6.1, the essential roles are service or ensemble provider.
Based on implications to specifíc STI functionality to be implemented, service providers are further distinguished into those who are in the UE position and those who are situated intermediately in the tree, that is those who are both UE and DE (see also section 6.2.4).
As outlined in Figure 6.10 each entity needs to be identified uniquely by a service or ensemble provider identifier. These identifiers are used for the addressing of control messages and marking of logical data frame sources as well. No specifíc numbering scheme is pre-defined. The total of transmission and coding resources allocated to an entity have to be shared between this entity and all of the entities connected to its inputs. For instance, in Figure 6.10, resources allocated to SP 100 comprise resources reserved for local use by SP 100 itself (e.g. due to service components or information inserted by non-STI sources at this level) and those propagated to its subordinated SPs, that is to SP 1001 and 1002.
At least during the migration phase real networks may additionally comprise non-STI SPs (see also section 6.2.4). Section 6.4 presents a corresponding example.
6.2.3 Network Operation
The requirement of both flexible and safe regular operation of the complete DAB broadcast network constitutes a challenge due to the complexity of the distributed real-time system. In general, service providers should be able to opérate independ-ently of each other, but be co-ordinated by the ensemble provider, based on respect¬ive contracts.


Assuming collection network has been established according to section 6.2.2, STI-C(LI)-based management tasks and subsequent actions have to be considered concerning dynamical operation. STI-D stream processing is consequently controlled. For simplicity, the focus will be on the most important first hierarchical level of the collection network, that is EP and directly connected SPs. The STI defines an interface of machine-readable data and no user interface for operators. In practice there will be a need for additional tools performing the translation tasks from manual specifícations to STI control messages or FIGs and vice versa.
In order to enable service providers to start broadcasting, the ensemble provider has to provide some prerequisites. The control connections to the service providers have to be opened using the provider identifiers as negotiated. Via these connections information about individually allocated resources could be transmitted to the service providers if implemented. Otherwise this information has to be passed to them outside of STI. Essential data, which can be delivered via STI-C by RESOURCE messages, comprise:
• Identifiers of sub-channels, services, FIC data channels and linkage sets
• Transmission capacities of MSC and FIC
• Máximum number and bit rates of specific stream types
• Restrictions concerning usable FIGs (regarding FIG type/extension)
• Entitlement and parameters to send announcements.
Based on these, service providers are able to specify and check activities of their own. Further on, an empty ensemble can be generated, which means no service com-ponents are included before the first reconfiguration initiated by a service provider. Nevertheless basic ensemble-related FIGs can be already sent as defined by the ensemble provider. Essentially this FIG set will consist of
• Ensemble identification and label (FIG O/O, FIG 1/0)
» Date and time (FIG 0/10)
• Ensemble-related tables to be used, country with local time offset (time zone)
(FIGO/9)
» Frequency lists (FIG 0/21)
s. TU lists (FIG 0/22)
• Regional definitions (FIG 0/11).
Service providers will normally start transmission by performing a reconfiguration of the virtual ensemble allocated to them, for instance by means of RESOURCE messages as mentioned above. Figure 6.11 shows this process in chronological sequence.
First of all the multiplex conflguration has to be defined in the frame of a data exchange session. Therefore the first message block will be enclosed by CONFDEF DEF and CONFDEF END messages. The CONFDEF DEF message is the header of the block providing the ñame of the conflguration and numbers of messages of specific type included.

Figure 6.11 Control message flow for definición and activation oí virtual ensamble configuraron (example)
The body of the message block contains the following definitions (one message per item):
• Sub-channels to be used for transmission of service components including identi-fiers and protection levéis (SUBCHAN DEF)
• Service components (CMPNENT DEF) including service component types and corresponding stream and sub-channel identifiers (for both MSC and FIDC), also including packet addresses in the case of packet mode service components
• Service defínitions (SERVICE DEF) comprising one or more service components and based on the specifications given before
• Further optional definitions, for instance to specify by ñame that predefined FIG files (signalling data) have to be enabled at reconfiguration instants (USEFIGF DEF) or that FIG streams out of STI-D have to be inserted into FIC (USESTRM DEF).






Firstly, the ensemble provider needs these data for generation of MCI FIGs to signal the multiplex on-air. Secondly, these data are necessary for controlling stream extraction from STI-D to form the MSC and to enrich the FIC in case FIG streams are in use.
The messages received will be checked for plausibility and compliance to the allocated resources. If the checks are passed, the configuration is stored and can be referred to from then on. Otherwise an error message is sent back to the service provider. How many configurations an ensemble provider is able to store depends on implementation and usage. Service providers can be informed about that via STI-C. Next the service provider will request a reconfiguration from the ensemble provider specifying the ñame of the configuration and the execution time wanted (RCONFIG REQ). To ensure seamless reconfiguration the time specification (<í5> in Figure 6.11) must be frame related. It is therefore sub-divided into a UTC valué uniquely addressing 2 minutes out of 24 hours and a data frame count valué specifying the respective 24 ms frame within the 2 minutes.
According to [EN 300 401] two subsequent reconfigurations must have a time distance of at least 6 seconds. Because there is no co-ordination required between service providers to agree on reconfiguration times, only the ensemble provider is entitled to define the instant of execution. Thereby the latter is able to merge the requirements of several providers in such a way that only execution times equal to or later than the requested ones are allocated.
Correspondingly the ensemble provider will check that a correct configuration of the received ñame has been defined previously by the service provider and will define the execution time for reconfiguration as cióse as possible to that requested. This information is sent back to the service provider (RCONFIG DEF). From now on a reconfiguration is pending at the ensemble multiplexer which will lead to the corres-ponding on-air signalling of the next ensemble configuration starting automatically about 6s before reconfiguration. Per provider, only one reconfiguration can be pending at a time.
Assuming that the service provider does not cancel the reconfiguration request right in time (RCONFIG CAN), it is expected that contributions are delivered via STI-D precisely timed and in accordance with the activated configuration. Otherwise error messages would be generated by the ensemble provider. Some further remarks are needed regarding the right instance to change streams or bit rates. As depicted in Figure 6.11 the service provider needs to know the propagation delay x of the STI-D frames, that is the time offset between departure of a frame at the service multiplexer and the appearance of its contents in the respective ETI frame leaving the ensemble multiplexer. By means of the message COUNTER INF a service provider can ask the ensemble provider about the frame-counter-related time difference and has to take this into account to support seamless reconfiguration. Moreover, decreasing the bit rate of a sub-channel needs to be accomplished 15 frames in advance to comply with the 16 frame interleaving process of the on-air signal.
Provisión of service and ensemble information is essential. As mentioned earlier, there are two basic mechanisms to be used in conjunction or alternatively: FIG streams (transported in STI-D) and FIG files (transported in STI-C). The main difference concerns the responsibility for FIG repetition. Required repetí tion rates are defined in


[TR 101496]. In the case of FIG streams, which are transparently passed into the on-air FIC, this must be performed by the source, for example by a service provider. Otherwise the ensemble provider is responsible for repetition of FIGs.
It should be emphasised that special treatment of so-called list FIGs is necessary. In the main, information is concerned with
• Service linking sets
• Región definitions
• Frequency lists .
• Transmitter identifícation lists
• Announcement support
• Other ensemble services
• Satellite datábase.
These FIGs comprise small databases. Well-defined parts of them should be updated selectively in order to avoid time-consuming recovery of complete data by receivers in case of changes. That is, with regard to key data fields the change event concerning a data subset has to be signalled by means of specially defmed FIGs sent for 6 seconds between the oíd and the new data versions (SIV/CEI, see also [TR 101496]).
Additionally or alternatively FIG files can be used to signal supporting infor¬mation. As with ensemble configurations, the corresponding file, which consists of one or more FIGs, has to be transferred to the ensemble multiplexer first. It would be checked and stored analogously under its ñame.
Further on, two alternative activation mechanisms are standardised for FIG files. As mentioned above, the FIG file to be activated at the instant of reconfiguration should be named by means of a USEFIGF DEF control message which is part of the respective ensemble configuration. Alternatively, FIG files can be activated or de-activated explicitly using FIGFILE SEL(elect) or DES(elect) messages respectively at arbitrary time points. Thereby activation/deactivation can be triggered in principie either based on pre-defined schedules or derived from events like key-stroking by a moderator. Repetition of FIGs as part of FIG files including the SIV/CEI treatment is up to the ensemble provider.
Intermedíate service providers exist in hierarchical collection networks (Figure 6.10) consisting of more than one level of service providers. As a downstream entity they should communicate with its upstream service providers like an ensemble provider. In the opposite direction, as an upstream entity, they should behave like other service providers (leaf entities). Consequently, intermedíate service providers have to share resources with and act on behalf on their subordinated service providers.
Because STI covers only management issues very cióse to DAB, there is a need for support beyond STI to opérate real networks. For example, section 6.4 will briefly cover such requirements and their practical implementation.
Important requirements are:
• Automation of operation (scheduling)
• Coding support for ensemble configurations and FIGs guided by allocated resources


• Event logging
• Alarm handling
• Connection to existing infrastructure (e.g. studio operation system, databases/ sources).
The problem of interoperability due to devices from different manufacturers who may each implement different subsets of the STI is considered in section 6.2.4.
6.2.4 STI Implementation Levéis
As demonstrated above, the STI standard [EN 300797] is rather complex and therefore the question arises how the interoperability of equipment produced by different manufacturers can be ensured. It is quite reasonable that not all STI-compliant devices ha ve to provide for the complete functionality as defined in the standard. Owing to the different extents of dynamic operation of the specific collec-tion network and the number and kind of providers involved, there will of course be varying requirements leading to different implementation costs too.
Faced with this situation, a WorldDAB task forcé derived subsets of functionality from the standard. It was assumed that the standard itself should not be changed. A technical specification defining "STI Levéis" has been standardised by ETSI [TS 101860].
Analysis has shown that definitions of basic stream types to be processed as well as management functionality related to the STI control functions are most important considering useful sub-sets of functionality. Therefore sub-division of functionality has been done with regard to these criteria. Three hierarchical levéis of STI function¬ality have been defined. This means that a higher STI level fully endoses the lower ones. But even the highest level, the third level, does not comprise the whole functionality of [EN 300797]. Some special functions are declared to be optional and level independent.
Also physical interfaces are beyond the scope of the STI level definition because it is much easier to reach interoperability between devices on this level than on a functional level. A wide variety of terminal adapters and other interface converters can be used for that purpose. Table 6.4 outlines the STI levéis as defined in [TS 101860].
Implementation of the control channel is not required at STI Level 1. Only STI-D has to be supported regarding basic stream types. In contrast to the ensemble provider, or a downstream entity in general, service providers are only enforced to genérate at least one out of the basic stream types. Implementations at the down¬stream side will be similar to those aimed at supporting non-STI providers (refer to section 6.2.5).
To be compliant with STI Level 2 the availability of the control channel is assumed and processing of a basic set of STI-C(LI) messages has to be implemented. This leads to the ability for seamless dynamic reconfiguration initiated by the remotely situated service provider. FIG files can be used for FIC signalling. Both FIG file activation mechanisms as described in section 6.2.3 have to be implemented.


Table 6.4 STI implementation levéis
Level Interface STI-D(LI) Stream Types STI-C(LI) Messages Comment
1 Restricted
(no control
Local control proxy for UE at DE


channel)
needed

2 Regular Processing of basic
ACTION,
Seamless dynamic re-configuration

stream types:
CONFIG, FIGFILE,
initiated by remote SP (UE), FIG

MSC audio
INFORMATION,
file-based signalling, status and

MSC stream data
SUPERVISIÓN
error messages

MSC packet data
•


FIG (SI)



FIG (FIDO




Advanced
Options
Processing of other
stream types:
FIB, PMC, FIC(CA)

RESOURCE
FIBGRID Reconfiguration enforcement of U E by DE

Resource allocation and consistency checks, more status and error messages
Selection of physical ¡nterfaces according to STI standard by both users and ¡mplementers



The advanced STI Level 3 additionally provides for ensemble co-ordination by means of RESOURCE messages. Nearly the full functionality of STI-C(LI) has to be realised to be compliant. Upstream entities working at the same level get useful information via STI-C to guide their specifícation process and to make it right fírst time. At downstream entities consistency checks will be carried out on all directly connected upstream entities based on the respective resources allocated. This concerns supervisión of used stream rates and transmission capacities as well as the checking of FIG contents. Severe interference between service providers can thereby be excluded.
For example, this relates to service and service component identifíers used in a couple of FIGs to signal service labels, programme type, announcement support and so on. Also linkage and announcement provisión data (e.g. cluster Id, announcement type and, if applicable, sub-channel Id) should be checked. In case of errors or inconsistencies, the generation of STI-C(LI) error messages takes place, for instance STERROR DEF messages pointing out respective stream Id and error type.
Optional functions which are beyond the scope of the STI level definition mainly concern
• Ensemble output of time, respectively frame, window related FIGs as needed for low-power-consuming receivers dealing with paging or emergency warning systems or for entitlement messages to be signalled in FIC to support conditional access
• MSC sub-channel contributions, as PMC, which need to be pre-processed before mapping into ETI frames
• Use of FIB instead of FIG streams leading to specifíc FIC assembling requirements
• Enforcement of upstream entity reconfigurations by the downstream entity.


The network example given in section 6.4 shows that the approach described above has been implemented successfully.
6.2.6 Advanced Features and Further Development
In the early stage of DAB introduction, not all features defined in the respective standards are of the same importance and will be implemented immediately. The most important features related to collection networks have been described earlier, also taking into account different STI implementation levéis.
Based on the changes in the broadcast landscape in general, and experiences gathered on collection networks, implementations are developed with respect to three categories:
• Use of advanced features already standardised
• Evolution of standards, especially the STI standard
• Evolution outside DAB standardisation.
The first category mainly comprises features such as
• Extended use of satellites in the collection networks (multicast of STI data)
• Dynamic change of local services and respective signalling of local service áreas
• Dynamic post-processing of received signalling data by the enseñable provider, for example to form ensemble preview on programme types
• Use of the FIC overflow channel (Auxiliary Information Channel, AIC)
• Provisión for time window related FIC output (by paging, conditional access, EWS).
Evolution of the STI standard could mean for instance:
• Acknowledgement of every transaction executed to support closer supervisión
• Addiíional information messages, for example to ask for FIG files which are currently active
• Provisión of ensemble-related global signalling data as, for instance, table, coun-try and regional definitions to upstream entities thereby supporting specification of related FIGs
• Support for cross-signalling between co-operating ensemble providers or even cascading of ensembles
• Standardisation of conformance tests for STI devices.
All in all, open and reliable system solutions providing easy and seamless adaptation to the embodying infrastructure, as well as offering trade-offs between functionality and expenditure will be developed stepwise.


6.3 The Distribution Network
6.3.1 The Ensemble Transport Interface (ETI)
Originally defined within the Eureka 147 project, the ETI was published by ETSI [EN 300799]. It is intended to be used for the distribution of ensemble data from the ensemble multiplexer to the transmitting sites of the single frequency network (SFN).
The ETI is conceptually based on layers differentiating between the logical inter-face (LI) and, at the physical layer, network-independent interfaces (NI) and net-work-adapted interfaces (NA). For physical transport in public telecommunication networks, it has been decided not to exceed the bit rate of 2 Mbit/s with regard to cost efficiency. Consequently, the process of convolutional encoding, which leads to higher ensemble data rates of 2448kbit/s (DAB transmission mode III) or 2432kbit/s (DAB mode I, II, IV), must be shifted from the ensemble multiplexer to transmission sites. The data to be broadcast is transmitted un-coded vía ETI and normally another means of error protection is needed. Forward Error Correction (FEC) based on Reed Solomon (RS) block coding has therefore been defmed in ETI(NA). In the following, the different ETI layers will be described in more detail.
The frame structure of the logical data interface ETI(LI) is presented in Figure 6.12 and corresponds to those of STI-D(LI) as presented in Figure 6.6. As STI-D(LI), the ETI(LI) frame carries data that are related to the 24 ms Common Inter-leaved Frame (CIF) formed in the channel encoder at the transmission site.
The frame characterisation fíeld comprises the lower part of the complete frame count (modulo 250, i.e. at 6 s periodicity) and a flag to point out that FIC data are present at the beginning of the main stream data part. The amount of FIC data, if present, is determined by the DAB mode signalled as well (three or four FIBs with 32 bytes each depending on the transmission mode). Further on, the number of streams contained, and the overall frame length, is described in the frame characterisation field. The frame phase (FP) consists of a modulo 8 counter, incremented at each frame, and controls the TU insertion in the channel encoder. On starting the ensem¬ble multiplexer it must be ensured that FP zero is aligned to CIF count zero
Each stream to be broadcast in the MSC is specifíed by its single stream charac¬terisation (SSTC) which thereby commands the channel encoder, see section 6 3 3 As depicted in Figure 6.12, the start address in MSC (in CU, O... 863), the sub-channel
FC
STC
EOH
MST
EOF
TIST

Frame Stream End of Main stream data characterisation characterisation header
Endof frame
Time-stamp


- Time-stamp
-CRC
per stream (SSTC):
- Frame count
- FIC flag
- Number of streams
- Frame phase - Type and
- DAB mode protection level
- Frame length - Stream length
- Start address
- Sub-channel Id _ MNSC - FIC data (if FIC fiag set)
— CRC
per stream (MSC sub-channel)-- Stream