Construction of <ecc> Parameter from DAB
Nick Piggott (RadioDNS)
The definition of a lookup in RadioDNS for DAB Digital Radio requires
the construction of an <ecc> parameter. (Section 5.1.2 in the proposed
update to RadioDNS - http://radiodns.org/documentation#proposed)
Recently, we have been contacted regarding an anomaly as to how this
<ecc> parameter should be constructed - the wording in the
specification is "Service broadcast multiplex ECC code."
Let's start at the easy bit.
EN 300 401 defines an Extended Country Code, which is a transfer of a
legacy concept from RDS. That can be transmitted as the second nibble
in FIG0/9. (clause 8.1.3). Alternatively, it can be provided on a per-
service basis by transmitting FIG0/2 with long-form (32bit) SIDs, in
which case both the ECC and the Country ID form the first 12 bits of
the 32 bit SID.
The problem is that ECC in itself is not unique. In RadioDNS, the
definition of the <ecc> parameter is a concatenation of items to make
it unique, and this is where the problem has arisen.
When writing the spec, we had in mind that it was a concatenation of
Country ID and ECC. So for the UK the Country ID is "c" and the ECC is
"e1", so the RadioDNS parameter is "ce1". However, we haven't
clarified *where* Country ID can be sourced from.
The situation in Germany has highlighted a problem.
EN 300 401 refers to Country Code and ECC code in various places - for
instance:
6.4 Ensemble Information (FIG0/0)
"EId (Ensemble Identifier): a unique 16-bit code, shall be allocated
to the ensemble and allows unambiguous identification of the ensemble
when associated with the Ensemble ECC (see clause 8.1.3).
Country Id (Country Identification): see clause 6.3.1.
Ensemble reference: this 12-bit field shall indicate the number of the
Ensemble allocated for use within a national area."
So an Ensemble ID could reasonable be inspected, and use the first
nibble to source the Country ID. Some people have understood that the
wording in the RadioDNS spec "Service broadcast multiplex ECC code"
suggests this is the Country ID to use.
But earlier on in EN 300 401 (and where the Country ID in 6.4 refers
to):
6.3.1 Basic Service and Service Component Definition (FIG0/2)
"[SId] Service Identifier description:
• Country Id (Identification): this 4-bit field shall be as defined in
TS 101 756 [16], tables 3 to 7.
• Service reference: this field shall indicate the number of the
service.
• ECC (Extended Country Code): this 8-bit field shall be as defined in
TS 101 756 [16], tables 3 to 7"
So you could also reasonably assume that either the 1st nibble of a
short form SId, or the 3rd nibble of a long for SId would *also* give
you the Country ID. And that's where we had assumed Country ID would
come from, because it has a parallel with the position in RDS, where a
genuinely unique country code is derived from the 1st nibble of the PI
code combined with the (non-mandatory) ECC code.
In the UK, the Country ID is set as "C" and consistently applied in
the construction of Ensemble IDs ("Cxxx") and Service IDs ("Cxxx").
But Germany has a problem, because Germany officially has TWO country
codes - "D" and "1", and of course existent FM services have PI codes
which begin with either, and then they want to have the same SId code
on DAB to ensure Implied Service Following between DAB and FM on the
rule "PI=SId".
So in a German mux, they have set the ensemble identifier "1008" using
the Country ID "1" and they've made a Service Identifier "D317" using
the Country ID "D".
This demonstrates that either the Ensemble ID OR the Service ID could
a reasonable source of a consistent Country ID, but those Country IDs
may not be the same.
I would like to solicit opinion in how we make the construction of
<ecc> in RadioDNS more definitive.
In my opinion, a suitably clear directive would be:
"For a SId in short form, the <ecc> is derived from the Country ID in
1st nibble of the SId followed by the two byte ECC defined in FIG 0/9.
If ECC has not been received, the <ecc> parameter cannot be
constructed, and no lookup is possible.
For SId in long form, the <ecc> is derived from the 3rd nibble of the
SId (the Country ID) followed by the 1st and 2nd nibbles of the SId
(the ECC)". (That would be in line with the legacy approach in FM/
RDS).
Your thoughts are welcome.
Richard Morris (gmail)
Nick, All
I am a little confused by this.
Australia as well as Germany has more than one country code, and we had
wanted to mix country codes in a single ensemble - but we didn’t think it
was allowed by the ETSI 300 401 DAB specification.
The German example suggests there are audio services in the multiplexer with
"long form" service IDs.
To have a "long form" service ID you need a P/D flag set to "1" in the
FIG0/2 (clause 6.3.1 in EN 300401)
You can only set the P/D flag (programme/data flag) to "1" if your service
is a data service (clause 5.2.2.1 in EN 300401)
So - in the German example you quote where they have a long form SID for an
audio (programme) service - it looks to me that they are not complying with
the ETSI EN 300 401 specification.
----------------------
However - I can see why they have done this , and I suppose the logical next
step is to update the ETSI EN 300 401 spec.
------------
If we ignore the issue as to whether the DAB configuration is a valid
configuration or not - then I agree with your proposal.
I believe it could be worded clearer however.
Instead of
**********original proposal*****************************
"For a SId in short form, the <ecc> is derived from the Country ID in
1st nibble of the SId followed by the two byte ECC defined in FIG 0/9.
If ECC has not been received, the <ecc> parameter cannot be
constructed, and no lookup is possible.
For SId in long form, the <ecc> is derived from the 3rd nibble of the
SId (the Country ID) followed by the 1st and 2nd nibbles of the SId
(the ECC)". (That would be in line with the legacy approach in FM/
RDS).
*********************************************
In both the German case and the Australian case -more than one country ID is
allocated - but in each case the same ECC is used.
Can I suggest the following.
************suggested proposal******************************
The 8 bit extended country code (ECC) should be sourced from the Ensemble
ECC in Fig 0/9 (see clause 8.1.3.2 ETSI EN 300 401)
The 4 bit Country ID should be sourced from the audio services SID in FIG
0/2 (see clause 6.3 , ETSI EN 300 401)
It should be noted that there are a few examples where the Country ID for
the service differs from the country ID used for the Ensemble ID, hence the
Country ID should always be taken from the FIG 0/2 for the selected service.
*******************************************
Best regards
Richard Morris
Consultant
Commercial Radio Australia
UK Mobile: +44 7554 418747
Australia: 02 8999 4292
(forwards to my UK mobile phone)
richard...@commercialradio.com.au
Freelance Consultant Engineer
Chartered Engineer (UK)
BSc C.Eng MIET
Mobile: +44 7554 418747
Ric...@signalbroadcast.co.uk
-----Original Message-----
From: ric...@digitalengineer.biz [mailto:ric...@digitalengineer.biz]
Sent: Friday, 12 August 2011 7:53 PM
To: Richard.r...@gmail.com
Subject: Fw: [RadioDNS-Dev] Construction of <ecc> Parameter from DAB
Hello,
Your thoughts are welcome.
--
You received this message because you are subscribed to the RadioDNS
developers group. RadioDNS is at http://radiodns.org/
To post to this group, send email to
radiodns-...@googlegroups.com
To unsubscribe from this group, send email to
radiodns-develo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
Sent from my BlackBerry® wireless device
Nick Piggott (RadioDNS)
I was also surprised to see SIds with mixed Country IDs on the same
ensemble. Here's probably not the place to discuss if that's within EN
300 401.
Also, to clarify, I haven't seen Audio Services with long form SId
codes. The German examples are all short form (16 bit) codes, with
Country ID as the first nibble (4 bits).
In the long form, the ECC and Country ID are explicitly defined, and
I'm now presuming that we might see a long form SId with an ECC that
isn't equal to the ECC being transmitted in FIG 0/9. In that case, I
am assuming that the Long Form SId is genuinely universally unique,
which is what we strive to acquire for RadioDNS. The Short Form SId is
only unique within a region, which is why you need to do the old RDS
trick of involving the ECC sourced from another place.
Nick
On Aug 13, 10:31 pm, "Richard Morris \(gmail\)"
> Freelance Consultant Engineer
> Chartered Engineer (UK)
> BSc C.Eng MIET
> Mobile: +44 7554 418747
>
>
>
>
>
>
> -----Original Message-----
> From: rich...@digitalengineer.biz [mailto:rich...@digitalengineer.biz]
> Sent: Friday, 12 August 2011 7:53 PM
> To: Richard.r.g.mor...@gmail.com
> Subject: Fw: [RadioDNS-Dev] Construction of <ecc> Parameter from DAB
>
> ------Original Message------
> From: Nick Piggott
>
> Sender: radiodns-...@googlegroups.com
> To: RadioDNS developers
> ReplyTo: radiodns-...@googlegroups.com
> Subject: [RadioDNS-Dev] Construction of <ecc> Parameter from DAB
> Sent: 12 Aug 2011 10:20
>
> Hello,
>
> The definition of a lookup in RadioDNS for DAB Digital Radio requires
> the construction of an <ecc> parameter. (Section 5.1.2 in the proposed
> radiodns-...@googlegroups.com
> To unsubscribe from this group, send email to
> radiodns-develo...@googlegroups.com
Richard Morris (gmail)
Thanks for clearing that up - I had misinterpreted what you had written.
If broadcasters are not using long form SIds for audio services - then there
is no issue with compatibility with the spec.
In that case the answer would appear to be simple - there is no need to
mention long form or short form sids in the RadioDNS specifications - as all
radio services will use Short form.
Regards
Richard
Hello Richard, all.
Nick
developers group. RadioDNS is at http://radiodns.org/
Nick Piggott (RadioDNS)
I think the RadioDNS specification should still allow linking from
broadcast data services (that is, services with 32bit SId) in case
there's a need to combine a broadcast data service with an IP channel
for interactivity. That's why we have both audio and data cases
covered.
We can be more explicit in reminding people that Audio Services use
16bit SId (and therefore need to acquire ECC from FIG0/9) and Data
Services use 32bit SId (and therefore both the Country ID and the ECC
are in the SId).
Nick
On Aug 14, 11:41 pm, "Richard Morris \(gmail\)"
>
> read more »
Nick Piggott (RadioDNS)
======
As a result of feedback in this discussion and directly by e-mail, I
am slightly amending the proposed wording:
"For Audio Services (16bit SId), the <ecc> is derived from the Country
ID in 1st nibble of the SId followed by the one byte ECC defined in
constructed, and no lookup is possible.
of the SId (the ECC).
decimal 31 should be expressed as 1f".
This will be transferred to the draft proposal in a few days unless
more comment is forthcoming.
James Cridland
As a result of feedback in this discussion and directly by e-mail, I
am slightly amending the proposed wording:
Where new platforms and radio collide: http://james.cridland.net/blog/
Twitter: @jamescridland | Web: http://james.cridland.net/
Not At All Bad Ltd | http://notatallbad.ltd.uk/legal_info/
Nick Piggott (RadioDNS)
In this discussion, and drawn randomly(ish) from www.wohnort.org/DAB
Klassik Radio
Service Identifier = d75b, ECC in FIG 0/9 = e0
<ecc> = 1st nibble of Service ID ("d") followed by ECC("e0")
<ecc> = de0
EPG + Slideshow (London I Multiplex)
Service Identifier = e1c00098
<ecc> = 3rd nibble of Service ID ("c") followed by 1st and 2nd nibble
of Service ID ("e1")
<ecc> = ce1
In neither case is Ensemble ID (EId) considered, even though the EN
300 401 specification suggests that the first nibble should also
contain a country ID value.
On Aug 15, 7:31 pm, James Cridland <ja...@cridland.net> wrote:
> On Mon, Aug 15, 2011 at 4:23 PM, Nick Piggott (RadioDNS) <
>