Radio is going digital – slowly but steadily. Currently, this happens in two
different worlds: One is DAB(+) and the other is 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 as
is. In contrast, IP-based radio services can offer all kinds of direct interactions
while using unicast for everything can be costly for providers and consumers. Also,
in the streaming domain there are little to no established standards for providing
add-on functionalities which often leads to basic audio-only services on 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 – also on the service and signalling side. Apart from a greater and efficient service offering when both are available,we also want to make switching between the two much smoother. Thus, we propose 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 for the following topics:
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 consequences.
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.
Announcement support: For any radio technology,the support of announcement signalling (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 realised, 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-specificsolution (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 following picture shows an overview of the data flow:
Under https://edistream.irt.de/, a live demo of a DAB+over IP stream, played back in an HTML/Javascript-based player is presented. The demo currently requires a Chrome browser.
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 straight forward as well.
Feel free to contact us If you want to know more.
The work presented in this blog post was supported by the European Union’s Horizon 2020 research and innovation programme under grant agreement No. 761813.