A number of prominent and forward-thinking U.K. broadcasters have been at work on a proposal for standardizing how to access radio services’ program-associated online resources, and the proposal is now seeing wider promulgation.
It is called RadioDNS, applying the familiar “Domain Name System” used for locating resources on the Internet.
For those unfamiliar with the process, in simple terms the Domain Name System is the equivalent of a distributed “phone book” or “directory assistance switchboard” for the Internet. When a user types a Web address into a browser, the query goes first to DNS, which essentially redirects the connection to the server that holds the desired content.
DNS knows where to send the user’s query because it is a hierarchically structured system that can quickly poll all the name servers on the Internet to quickly determine where the sought content is stored, and once located, route the user’s connection to that server.
This network of name servers constantly is updated with the latest resource identification and location records by the appropriate registration agencies, and any such updates entered into any one name server are soon propagated throughout the entire DNS.
Part of the DNS process includes a translation of the loosely structured alphanumeric URL string entered by the user to a tightly specified numeric IP address, which is used by Internet routers to complete the connection to the target server.
The DNS method, originally specified in 1987 by the Internet Engineering Task Force (IETF) in its RFC 1034, was made intentionally extensible (even beyond the Internet) — and has in fact been compatibly updated in numerous ways since.
Another such extension is now presented in the RadioDNS proposal.
Old meets new
A RadioDNS draft technical specification discusses how to build Fully Qualifed Domain Names, or FQDNs, for broadcast platforms including FM, shown here, as well as for DAB, DRM, AMSS, HD Radio and IP-delivered services. RadioDNS envisions a new class of devices that include both a radio receiver and an Internet connection, either periodic or continuous.
These Web-connected radios could listen to broadcast content like any radio, but obtain enhancements to the content via the Internet, either automatically or upon request of the user.
Although not long ago this concept would have seemed quite forward-looking, we are already seeing the first of these types of devices on the market, so the proposal is not a moment too soon — and the concept could before long become fairly commonplace among new product offerings.
Unlike the typical method of seeking online content via manual data entry to a browser by the user, RadioDNS would make this process far simpler for such “connected radio receivers” by establishing a standard scheme for determining the corresponding URL whenever a particular radio station is tuned in.
This would allow the station’s enhanced content (if any exists) to be delivered to the radio via the Internet without any user intervention other than tuning in the station. The RadioDNS-enabled device, RadioDNS name servers, the Internet and the station’s Web site would do the rest “automagically.”
This is a fairly simple concept — the RadioDNS core spec is only 12 pages long, quite short by standards’ standards — but it is presented elegantly and comprehensively by the proposal. Of course, it can be so concise because it leverages the power of the existing DNS, essentially adding only a specified process for the connected radio receiver to resolve the appropriate domain name, and to discover content and supported applications at that location.
Notably, it covers both analog and digital radio broadcast formats, allowing online enhancements to be compatibly added by broadcasters as extensions to the massively deployed legacy services of AM and FM radio, when received on next-gen radios or other “converged devices” such as wireless devices and 3G/4G phones with FM receivers on board.
To be included in RDNS, however, it is required that FM stations provide RDS service, and AM broadcasters include the AM Signaling System (AMSS) in their transmissions.
RadioDNS can also be used by Internet radio services. In these cases, the domain obviously is already known by the receiver, but it can still benefit from the convenient enhancement-discovery and -delivery processes that also will be defined by RadioDNS.
For those interested in the specifics of the process, they are presented in the RDNS01 spec, available freely at radiodns.org.
Its core functionality can be summarized as follows: RadioDNS uses information already known by the receiver — gained from its tuner settings and/or metadata provided by the tuned service — to automatically generate a unique Internet domain name for every radio signal the receiver tunes in.
The receiver accomplishes this by sending a query to a known RadioDNS name server via its Internet connection, and that server replies with a specific URL for the currently tuned radio service. The receiver can then access the resources available at that Internet location for enhancement of the service being broadcast on that radio channel. (These RadioDNS name servers do not yet exist, of course, but their establishment and operation are also part of the proposed RadioDNS process.)
For example, in the case of FM, the receiver would use the frequency of the currently tuned station, plus data found in one or two of the station’s RDS fields, and format it in a standardized fashion (specified in RDNS01) to create the RDNS query. The RDS fields used here are the PI (Program Identification) code and the ECC (Extended Country Code). If the latter is not provided by the radio station, the two-character ISO country code can be used by the device instead.
The latter would presumably be set upon initialization of the device by the user — and changed by the user whenever the receiver was operated in a different country — or it might be automatically set by the device’s Internet connection.
Building consensus
Ideally, the sorts of applications offered to receivers by broadcasters at these domains would also benefit from some standardization, and the RadioDNS development consortium has targeted this as a next step.
A primary example is an electronic program guide. In this case, a connected radio contacting the currently tuned station’s Web resources via an RDNS would learn that EPG is among the offerings there, and the receiver could then download and display the EPG for that station.
The developers of RDNS are among those responsible for DAB’s unique success in the United Kingdom. What’s most interesting about RDNS, however, is its applicability to other (including analog) broadcasting formats. The current spec includes RDNS methods for FM, DAB, DRM, AM, HD Radio and Internet radio, and it could be extended to cover other formats as needed.
The RadioDNS “promoters” — their organization has no official name other than “RadioDNS” as yet — are now seeking broader input from the radio industry, as they move toward finalization of their inaugural document drafts. Besides the technical specification, they have proposed an organization/governance structure for the RadioDNS process, and various applications and use cases. Find out more at radiodns.org.
Skip Pizzi is contributing editor of Radio World. Follow him atTwitter.com/skippizzi.
