Radio is going digital – slowly but steadily. Currently, this happens in two different worlds: one of them being DAB(+) and the other IP streaming. DAB(+) is a sophisticated and efficient broadcast standard with many clearly specified add-on functionalities – but it does not support personalisation of its services. In contrast, IP-based radio services can offer all kinds of direct interactions. However, using unicast for everything can be costly for providers and consumers. Moreover, in the streaming domain, there are little to no established standards for providing add-on functionalities, which often leads to basic audio-only services and many platforms falling behind the service level of regular broadcast services.
HRADIO has set out to seamlessly combine the best of both worlds, by making radio truly hybrid – on the service as well as the signaling side. Apart from a greater and efficient service offering when both are available, HRADIO also aims to make switching between the two much smoother. Thus, the project proposes to distribute DAB(+) services transparently over IP, making the life easier for broadcasters, radio service providers, app developers and device manufacturers who want to support DAB(+) and IP at the same time.
For the transparent consumption of radio services either via DAB(+) or IP, the same level of metadata and data services is necessary for both transmissions. Otherwise, the listener would notice the (even temporary) switch over from DAB(+) to IP and back.
Rebuilding the same level of audio and data services in IP-delivered scenarios could be difficult because of the following:
Seamless audio switching
Switching between DAB(+)-based audio (HE-AAC) and IP based audio (typically mp3 or AAC) is rather difficult because of the fact that normally, the same audio signal from the studio is going through different processing workflows for either DAB(+)transmission or IP streaming, often even on different locations. Different delay times and different audio levels are the consequence.
Data services (DL+ and SLS)
In traditional DAB(+) services, the provision of a slideshow feature as well as DynamicLabel+ is more or less obligatory. DynamicLabel+ provides short text messages to the client, which contain additional metadata with title.artist or title.album information about the current song and exact timing information regarding the start, stop or pause status of a programme event. Slideshow provides little jpg or png encoded images with programme-related information e.g. album art. On top of this, slideshows (with categorisation) can provide links to web pages or alternative (location-based or device-specific) content related to the actual slide. These two data services are transmitted “in-band” as additional information to the audio packets (PAD) which synchronises them perfectly to the audio signal they relate to. Although RadioVIS provides an alternative to a text message and slideshow specification, opening the necessary private ports for the required STOMP protocol is difficult (esp. in cars) and RadioVIS cannot provide the same tight synchronisation between the data and the audio service as its DAB(+) counterparts.
For any radio technology, the support of announcement signaling (Traffic, Alarm, Emergency) has always been crucial and therefore it is part of the core DNA of DAB(+). On FM, a similar technology in the form of RDS exists. Surely, server push information to the clients can also be realized, however, they are rarely implemented. Compared to the “in-band” broadcast announcements, either additional open IP ports or technologies such as web sockets are required (which often causes problems) or vendor-specific solution (e.g.for iOS or Android) have to be used.
For broadcasters and service providers, this means additional development effort and additional operational resources at a significant scale.
As a solution, the HRADIO project developed an alternative, in using DAB(+) data for streaming over IP.
The DAB(+) specifications also describe the encapsulation of DAB(+) ensemble data into IP packets: DAB(+) EDI. Usually, the encapsulation of a whole DAB(+) ensemble (typically 10 -12 services in a 1.8 MBit/s multiplex) is used for IP-based contribution of DAB(+) signals from the multiplexer to the transmission sites. The HRADIO project uses this specification – however, only for the transmission of a single radio service.
Benefits of the solution are:
No additional work for broadcasters that already produce the DAB(+) ensemble for broadcast transmission.
All signalling and data services supported in DAB(+) broadcast are available “in-band” for the IP-based clients as well.
No audio correlation and audio processing required when implementing service following.
For application developers everything “becomes DAB(+)”.
Well-known, documented and standardised solution.
The DAB(+) EDI-Splitter receives a complete multiplexed DAB(+) EDI stream-which is also used for DAB(+) broadcast contribution-via UDP unicast. The received multiplex stream is analysed on how many DAB+services are multiplexed. Every single DAB service is then split out of the full multiplex and the necessary parameters in the EDI-AF (Application frame) layer and the FIGs (Fast Information Group) contained in the EDI-DETI tag are adjusted to generate a standard compliant EDI stream.
The following FIGs are adjusted for a single service EDI stream:
FIG 00 Extension 01 – Basic sub-channel organisation
FIG 00 Extension 02 – Basic service and service component definition
FIG 00 Extension 13 – User application information
FIG 00 Extension 14 – FEC sub-channel organisation
The service payload contained in EDI-MST tags stays untouched. The stream is then recompiled into a standard-compliant single-service EDI stream. For every single-service stream, the DAB/IP splitter creates an entry in the HTTP REST-service which it provides with the following scheme: http://<server-url>/services/<1>
The services can now be obtained via HTTP and/or via HTTPS. The whole DAB/IP splitter is designed as a microservice. Therefore, the roll-out in distributed networks with load balancing is straightforward as well.