The National Radio Systems Committee released an intriguing report earlier this year that lays the informative groundwork for radio-based geo-location. The NRSC-R208 report is titled “Characteristics of Location-based Services Transmissions Using Local Radio.”
This report, released in January, “sets forth recommended characteristics of non-proprietary location-based services information transmitted on or in relation to programming broadcast [by] U.S. terrestrial radio broadcast stations (Broadcaster-Provided Location-based Services, or BPLBS). It is worth noting that some broadcasters are now relying upon broadband delivery methods (to consumers) to supplement over-the-air content and services, and this trend is expected to continue. Therefore, BPLBS do not necessarily need to be carried over-the-air to the end user.”
WHAT IS BPLBS?
BPLBS is not a GPS or a “Where am I?” scheme, but rather a framework to transmit consumer-oriented data in an orderly fashion to radio receivers that can share that received data to the user, if the receiver determines the user is within the area described in the data headers. This may be an economical way of getting essential data to the consumer without using expensive mobile data.
The report suggests classifying future “smart” broadcast receivers into those models that have Internet connectivity (Class “B”) and those that do not have Internet capability (Class “A”). In both classes of receivers, the consumer receives some benefit of “basic level of value,” with the Internet-connected receiver giving the consumer a richer experience. The receivers don’t necessarily have to have GPS to determine their location in space; the report suggests that besides GPS or other dedicated geo-positioning system, “position inference” or “user input” could determine the user location. In reading this, e-Radio’s patented e-NAV location-based system came to mind. The e-NAV technology uses a “spectral signature location technology” that involves scanning the band and analyzing a number of stations’ signals to determine your location — where the particular strength of each analyzed signal can only be had if one is at a particular location.
As to “user input,” I can only imagine a device that has a speech-to-meaning engine similar to what SoundHound Inc. has released, where a user could orient the device by saying something like “I am at 9 North College Street in Athens, Ohio.”
Manufacturers’ specifications for a new receiver design are not discussed in the report; only the broadcast methods and suggested framework for the technology are described.
GETTING THE DATA TO A RECEIVER
The NRSC-R208 report suggests five suitable protocols for coding LBS data for transmission:
Common Alerting Protocol (CAP)
The CAP version 1.2 abstract describes the protocol as “a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems, thus increasing warning effectiveness while simplifying the warning task.” It is in widespread use and well documented.
OpenGIS KML Encoding Standard (OGC KML)
KML, an acronym formerly known as “Keyhole Markup Language,” is a specification maintained by the Open Geospatial Consortium, Inc. (OCG). The opengeospatial.org website describes the specification this way: “KML is an XML language focused on geographic visualization, including annotation of maps and images. Geographic visualization includes not only the presentation of graphical data on the globe, but also the control of the user’s navigation in the sense of where to go and where to look.
From this perspective, KML is complementary to most of the key existing OGC standards including GML (Geography Markup Language), WFS (Web Feature Service) and WMS (Web Map Service).”
OpenGIS GML Encoding Standard (OGC GML)
The Geography Markup Language (GML) is a specification maintained by the Open Geospatial Consortium Inc. The opengeospatial.org website describes the GML as “an XML grammar for expressing geographical features. GML serves as a modeling language for geographic systems as well as an open interchange format for geographic transactions on the Internet … the developers of GML envision communities working to define community-specific application schemas…that are specialized extensions of GML. Using application schemas, users can refer to roads, highways and bridges instead of points, lines and polygons. If everyone in a community agrees to use the same schemas they can exchange data easily and be sure that a road is still a road when they view it.”
The report notes: “BPLBS applications may need to rely on the simple descriptions (such as a lat/long point) implemented in KML (and in GML) for the brevity necessary to limit the data capacity required to broadcast the LBD over the air. Meanwhile, hybrid radio applications could benefit from also including more specific descriptions, such as an identifier of a street address in a street database or a specific building (or even building entrance) in a building geographic dataset. Once the user device has a cue that informs the device and the user of the presence of richer geographic information about the broadcast program, the hybrid radio device can use its Internet connection to fetch the richer LBD for presentation to the user.”
TPEG (Transportation Protocol Experts Group)
The TPEG group was born of the European Broadcasting Union in 1997 and has released generation 2. It is a sprawling set of tools that encompasses roads and public transport and weather, among other elements. It’s designed for easy implementation across European nations by isolating the actual data from the human language meaning, and has a defined binary format and markup language format. The NRSC-R208 report says “the portion of the TPEG protocols most directly applicable to RLBS would be the location referencing protocol.”
Agora-C
According to the Via Licensing Corporation website, which has coordinated the patent pool that contains the patents used to create Agora-C, it is a license-able location reference technology, the main attraction of which is that it “is independent of underlying map technology and enables sharing highly accurate location referencing information between applications such as navigation devices, traffic information systems and other location-based services. Unlike conventional geocoding technologies, Agora-C specifies a method for dynamic encoding and decoding of location references for geographic objects such as road junctions, incidents and points of interest without requiring predefined location codes or lookup tables is attractive because it does not need a built-in location database.”
The NRSC-R208 report states, “As devices have evolved to rely on lat/long coding to place routes, polygons and points on a user map, the need to pre-populate devices with application-specific geo databases has diminished. Nevertheless, it can still be challenging to identify, for example, that a restaurant, whose address is #14 Highway 66, is on the southeast corner of the intersection (due to variations in road databases and/or coordinate systems) and must be accessed from the north by turning left on Feeder Road 2 and entering the parking lot from there. Map layers often do not align perfectly, and some error tolerance is required in the process of snapping a new location data point to the user’s map. Agora-C provides support for this level of complexity.” Agora-C is known formally as ISO Standard 17572-3.
These five possible protocols could carry data sent using three types of over-the-air transmission methods:
● RDS-based transmission — The report was released prior to the introduction of RDS2 and so suggests the use of TMP/ODA Group 8 or other group allocations with a maximum of 600 bits per second. If the NRSC-R208 report is updated, I would expect that the RDS2 allocation and higher transmission speeds would be listed.
● HD Radio system-based — HD Radio technology has a higher innate bandwidth of 145 kilobits per second, according to the report, and the Advanced Application Services (AAS) gateway offers the possible multiplicity of targeted data/audio services. Presumably a specialized HD Radio receiver could act as a data tunnel that forwards received BPLBS data to another, non-radio device for processing
● Digital subcarriers — This section leaves open the possibility of a digital FM subcarrier for BPLBS data.
SEND PICTURES, OR NOT
The report’s section on Presentation lightly touches on the transmission and use of icons and symbols in the user interface and discourages transmitting graphical icons in favor of receiver-based graphical elements that correspond to ISO 7001:2007 Graphical symbols — Public information symbols. The intent is to save over-the-air bandwidth for more important, non-graphical content. The report also points out that the text encoding standard ISO/IEC 8859-1:1998 is already employed in broadcast streams and in receivers and supports 27 languages and logically would be used in BPLBS.
The most entertaining sections of NRSC-R208 are the Annexes. Here, use case examples are presented; Map and Navigation Services are discussed; the likely protocols’ attributes are summarized; and the responses to the NRSC Request for Proposals (RFP) on location-based services are published.
USE CASE EXAMPLES AND RFP RESPONSES
Of interest here are the use case examples and RFP responses.
Only one company, iBiquity Digital Corp., had submitted example use cases. IBiquity illustrates three scenarios; the first illustrates a simple geo-located text advertisement, the second shows multiple text advertisements reaching multiple target receivers that are in different ZIP codes, and the third scenario (Fig. 2) — the most feature-rich and complex — adds customized audio to the multiple text advertisements. In Fig. 2, the host station simultaneously transmits three different audio commercials and three corresponding text commercials.
A receiver that cannot interpret the location data or whose location is not in one of the transmitted ZIP codes will receive the “regular” audio commercial version and “regular” commercial text. Receivers in two other ZIP codes will play a customized audio message with corresponding text commercial. In this illustration, there are three retail establishments reaching a number of different ZIP codes, but a bank or fast-food franchise could just as easily transmit three localized messages for its locations in different ZIP codes.
Two thoughtful RFP responses are the last sections of the NRSC-R208, one from e-Radio Inc. whose patented methods for geographic positioning (“e-NAV”) are mentioned, and one response from Visteon Corp., which presents its patented “Traffic Flash” technology that decodes existing RBDS-TMP broadcasts and uses a text-to-speech synthesizer to tell the driver about relevant location based events. Visteon’s technology does not require an in-vehicle navigation system, which reduces system cost, but as their response says, “Dynamic rerouting is not provided and the user is expected to change their individual driving route based on the warning — same as the conventional broadcast traffic announcement model.”
The NRSC-R208 report is a timely reminder that as vehicles become more connected, there are still economical ways to get critical and useful data to the vehicle that doesn’t necessarily consume bytes from a mobile data plan.
The report can be read in its entirety at http://nrscstandards.org/reports/NRSC-R208.pdf.
Rich Rarey is RWEE technical editor and principal of Rareworks LLC consulting.
