We are pleased to announce a bundled release of the draft specification v1.0.0 for RadioEPG and RadioDNS
Both are being released simultaneously as they are dependant on each other for detailing methods of discovery for IP-based audio services.
This release of the RadioEPG specification is the first official draft for the RadioEPG project and add significantly to previous drafts that may have been circulated.
The specification builds upon the DAB EPG XML specification, but puts the focus on defining services rather than programmes, with an Extended Service Information (XSI) document. This allows the detailing of services with DAB and/or non-DAB bearers, along with the standard set of user-surfaceable metadata.
It also enables and specificies implementation details of Service Following, allowing devices to become service-oriented, rather than platform-oriented.
The changes to both specification are key to the success of the RadioDNS project as a whole and so I would strongly urge you to give it close consideration. All changes within the RadioDNS specification are highlighted and comments explaining the change are attached as PDF comments. The RadioEPG specification can be considered as a new document.
In particular to RadioEPG, the following questions will need to be considered:
- Are the methods of document discovery compatible with your environment? Do they cover the majority of situations where discovery will be needed? - Have we defined the bearers appropriately for your services? - Has the interaction between bearer information across PI and XSI files been defined correctly? - Do we need to enable the ability for service providers to be able to signal that a programme in a PI file is available on *no* bearers? - Do we need to provide a means for a service provider to be able to signal that signal following *must not* occur for specific programmes? - Has the service following implementation recommendations been described sufficiently for service provider and device implementations?
It is *vitally important* that we all examine the implications these changes would have, as well as whether they fully support our ambitions.
During some work on an XSI generator it was commented that it may be useful to include extra information when specifying DAB bearers, in order to assist client implementation of Service Following. The scenario is described as following:
Take a device within a car listening to a service via IP. It has the capability to perform Service Following, by switching between bearers for that Service, enabled using the XSI document from the Service Provider.
In order to determine whether the service is available on DAB, it can use the DAB Bearer details (ECC, EId, SId, SCIdS) but to do this for a device with a single DAB receiver, it needs to constantly scan the DAB spectrum and acquire any ensemble details. This takes a finite amount of time (around 90 seconds, say), which is wasteful and would provide a poor user experience for a device moving between areas of DAB broadcast.
To help with this, an indication of the frequencies on which ensembles exist carrying that service can be included in the XSI against the DAB bearer details, presumably one per DAB Bearer ID for the ensemble that Bearer exists within. This would *narrow* the search for that service when roaming between ensembles, enabling Service Following to happen more smoothly.
This could include the frequency. I would prefer to have this as part of a possible URI for a DAB Bearer, although I am open to suggestion to how this could be formatted. The frequency will need to remain optional, and should co-exist with the other optional part of the URI (SCIds/X-Padd AppType). One possible format is:
The existing bearer is currently sufficient to uniquely identify a service. Specifying the frequency is more a hint than a part of identifier, so the two should be separate. I believe that most DAB radios will build a services table when they autoscan, which would already include the frequency. Using the DAB bearer in the current format would be enough for the radio to tune to the correct service.
In a situation where the multiplexes available to the radio are constantly changing (such as an in-car radio) then the cached list of services is constantly changing. Hinting what the multiplex frequency is could, as you say, considerably reduce the amount of time taken to retune. For this reason, I would suggest that listing the frequency is marked as 'strongly recommended' in the specification.
Finally, there are some circumstances where the same multiplex can occur on multiple frequencies. For example, the Digital One mux in the UK has two frequencies in use (a separate one for Scotland) but both have the same ensemble id. In this case I would suggest using multiple bearer entries in the XSI document, with different frequency attributes - similar to an RBR of an FM station.
On Wed, Aug 24, 2011 at 4:37 PM, Ben Poor <magicbad...@gmail.com> wrote: > Dear All,
> During some work on an XSI generator it was commented that it may be useful > to include extra information when specifying DAB bearers, in order to assist > client implementation of Service Following. The scenario is described as > following:
> Take a device within a car listening to a service via IP. It has the > capability to perform Service Following, by switching between bearers for > that Service, enabled using the XSI document from the Service Provider.
> In order to determine whether the service is available on DAB, it can use > the DAB Bearer details (ECC, EId, SId, SCIdS) but to do this for a device > with a single DAB receiver, it needs to constantly scan the DAB spectrum and > acquire any ensemble details. This takes a finite amount of time (around 90 > seconds, say), which is wasteful and would provide a poor user experience > for a device moving between areas of DAB broadcast.
> To help with this, an indication of the frequencies on which ensembles > exist carrying that service can be included in the XSI against the DAB > bearer details, presumably one per DAB Bearer ID for the ensemble that > Bearer exists within. This would *narrow* the search for that service when > roaming between ensembles, enabling Service Following to happen more > smoothly.
> This could include the frequency. I would prefer to have this as part of a > possible URI for a DAB Bearer, although I am open to suggestion to how this > could be formatted. The frequency will need to remain optional, and should > co-exist with the other optional part of the URI (SCIds/X-Padd AppType). One > possible format is:
I tend to feel that frequency is an (optional) attribute of the serviceID element.
I've now got two supplementary questions to consider: * Should <frequency> be an optional attribute in the specification of FM bearers. It's primarily there to allow an FM receiver to go straight to a frequency, acquire a signal and check the PI code, but theoretically there's nothing to stop the tuner doing a scan of the FM band if frequency is absent, and just working from PI. * Should it be possible to explicitly declare frequency as a wildcard (eg. "*") if you mean "any frequency", or does simply omitting the frequency information imply that. Should we allow frequency to be specified as a range such as "frequency="100000-102000" which means any frequency between 100MHz and 102MHz. This is probably relevant to radio stations that have many transmitters and relays on many different frequencies.
Nick
On 25 August 2011 09:20, Pete Redhead <peteredh...@googlemail.com> wrote:
> The existing bearer is currently sufficient to uniquely identify a service. > Specifying the frequency is more a hint than a part of identifier, so the > two should be separate. I believe that most DAB radios will build a services > table when they autoscan, which would already include the frequency. Using > the DAB bearer in the current format would be enough for the radio to tune > to the correct service.
> In a situation where the multiplexes available to the radio are constantly > changing (such as an in-car radio) then the cached list of services is > constantly changing. Hinting what the multiplex frequency is could, as you > say, considerably reduce the amount of time taken to retune. For this > reason, I would suggest that listing the frequency is marked as 'strongly > recommended' in the specification.
> Finally, there are some circumstances where the same multiplex can occur on > multiple frequencies. For example, the Digital One mux in the UK has two > frequencies in use (a separate one for Scotland) but both have the same > ensemble id. In this case I would suggest using multiple bearer entries in > the XSI document, with different frequency attributes - similar to an RBR of > an FM station.
> A receiver not using the frequency attribute would require some > deduplication on the bearers.
> Thanks,
> Pete Redhead
> On Wed, Aug 24, 2011 at 4:37 PM, Ben Poor <magicbad...@gmail.com> wrote:
>> Dear All,
>> During some work on an XSI generator it was commented that it may be >> useful to include extra information when specifying DAB bearers, in order to >> assist client implementation of Service Following. The scenario is described >> as following:
>> Take a device within a car listening to a service via IP. It has the >> capability to perform Service Following, by switching between bearers for >> that Service, enabled using the XSI document from the Service Provider.
>> In order to determine whether the service is available on DAB, it can use >> the DAB Bearer details (ECC, EId, SId, SCIdS) but to do this for a device >> with a single DAB receiver, it needs to constantly scan the DAB spectrum and >> acquire any ensemble details. This takes a finite amount of time (around 90 >> seconds, say), which is wasteful and would provide a poor user experience >> for a device moving between areas of DAB broadcast.
>> To help with this, an indication of the frequencies on which ensembles >> exist carrying that service can be included in the XSI against the DAB >> bearer details, presumably one per DAB Bearer ID for the ensemble that >> Bearer exists within. This would *narrow* the search for that service when >> roaming between ensembles, enabling Service Following to happen more >> smoothly.
>> This could include the frequency. I would prefer to have this as part of a >> possible URI for a DAB Bearer, although I am open to suggestion to how this >> could be formatted. The frequency will need to remain optional, and should >> co-exist with the other optional part of the URI (SCIds/X-Padd AppType). One >> possible format is:
I think Pete's suggestion of repeating the same serviceID in circumstances where there are multiple frequencies could be bad practice as it involves repeating the 'id' attribute which is normally used as an unique identifier. However I do agree with Pete that the bearer itself is sufficient to uniquely identify a service and should not be merged with frequency as he explains.
I can think of three possible alternatives:
Using a frequency attribute on serviceID as a space delimited list of associated frequencies.
> I tend to feel that frequency is an (optional) attribute of the serviceID > element.
> I've now got two supplementary questions to consider: > * Should <frequency> be an optional attribute in the specification of FM > bearers. It's primarily there to allow an FM receiver to go straight to a > frequency, acquire a signal and check the PI code, but theoretically there's > nothing to stop the tuner doing a scan of the FM band if frequency is > absent, and just working from PI. > * Should it be possible to explicitly declare frequency as a wildcard (eg. > "*") if you mean "any frequency", or does simply omitting the frequency > information imply that. Should we allow frequency to be specified as a range > such as "frequency="100000-102000" which means any frequency between 100MHz > and 102MHz. This is probably relevant to radio stations that have many > transmitters and relays on many different frequencies.
> Nick
> On 25 August 2011 09:20, Pete Redhead <peteredh...@googlemail.com> wrote:
>> Hi Ben(s),
>> My opinion on this topic is that it would be better to have the frequency >> listed as an optional attribute in the bearer, in a format such as
>> The existing bearer is currently sufficient to uniquely identify a >> service. Specifying the frequency is more a hint than a part of identifier, >> so the two should be separate. I believe that most DAB radios will build a >> services table when they autoscan, which would already include the >> frequency. Using the DAB bearer in the current format would be enough for >> the radio to tune to the correct service.
>> In a situation where the multiplexes available to the radio are constantly >> changing (such as an in-car radio) then the cached list of services is >> constantly changing. Hinting what the multiplex frequency is could, as you >> say, considerably reduce the amount of time taken to retune. For this >> reason, I would suggest that listing the frequency is marked as 'strongly >> recommended' in the specification.
>> Finally, there are some circumstances where the same multiplex can occur >> on multiple frequencies. For example, the Digital One mux in the UK has two >> frequencies in use (a separate one for Scotland) but both have the same >> ensemble id. In this case I would suggest using multiple bearer entries in >> the XSI document, with different frequency attributes - similar to an RBR of >> an FM station.
>> A receiver not using the frequency attribute would require some >> deduplication on the bearers.
>> Thanks,
>> Pete Redhead
>> On Wed, Aug 24, 2011 at 4:37 PM, Ben Poor <magicbad...@gmail.com> wrote:
>>> Dear All,
>>> During some work on an XSI generator it was commented that it may be >>> useful to include extra information when specifying DAB bearers, in order to >>> assist client implementation of Service Following. The scenario is described >>> as following:
>>> Take a device within a car listening to a service via IP. It has the >>> capability to perform Service Following, by switching between bearers for >>> that Service, enabled using the XSI document from the Service Provider.
>>> In order to determine whether the service is available on DAB, it can use >>> the DAB Bearer details (ECC, EId, SId, SCIdS) but to do this for a device >>> with a single DAB receiver, it needs to constantly scan the DAB spectrum and >>> acquire any ensemble details. This takes a finite amount of time (around 90 >>> seconds, say), which is wasteful and would provide a poor user experience >>> for a device moving between areas of DAB broadcast.
>>> To help with this, an indication of the frequencies on which ensembles >>> exist carrying that service can be included in the XSI against the DAB >>> bearer details, presumably one per DAB Bearer ID for the ensemble that >>> Bearer exists within. This would *narrow* the search for that service when >>> roaming between ensembles, enabling Service Following to happen more >>> smoothly.
>>> This could include the frequency. I would prefer to have this as part of >>> a possible URI for a DAB Bearer, although I am open to suggestion to how >>> this could be formatted. The frequency will need to remain optional, and >>> should co-exist with the other optional part of the URI (SCIds/X-Padd >>> AppType). One possible format is:
