Hi Martin,
Thanks for the quick response.
I am trying to figure out what the impact to the Internet is if many SDOs develop their own specifications for emergency services without considering the NENA work and I am particularly referring to the SDOs that potentially impact real networks.
More comments below:
> -----Ursprüngliche Nachricht-----
> Von: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> Gesendet: Donnerstag, 15. März 2007 12:47
> An: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes
> Tschofenig; GEOPRIV; ECRIT
> Betreff: RE: [Geopriv] RE: [Ecrit] NENA
>
> I think Martin (the other Martin, not me) meant that ATIS
> works with NENA specifications. NENA is not an accredited SDO
> - in the same sense, for example, that ATIS is accredited and
> able to publish American National Standards. Of course, that
> doesn't prevent NENA from publishing referencable documents.
> The E2 interface specification used for wireless E-9-1-1 is a
> NENA document and, as ever, the i2 architecture specification
> is a NENA document.
>
> I don't think there's anything prescriptive about how the
> work of NENA interacts with other SDOs. I think it's best
> understood in terms of the general role of NENA - which is to
> provide a national consensus view on how the elements of the
> emergency service fit together. This ends up covering
> everything from devices through access and core networks, and
> into the emergency network elements - the routers, call
> centers, and ALI and ANI databases.
>
> This is particularly important in an environment such as the
> US which is extremely devolved with multiple independent
> parties operating at every level and every function. Without
> a body like NENA it would all deteriorate into chaos -
> despite how it seems to some, that's not what it is now. :)
>
> It's good to look at a case study.
>
> NENA had a lot of influence on, for example, the TIA
> J-STD-036 specification for phase 2 wireless which
> subsequently formed the deployment model for how the FCC
> mandate for wireless E-9-1-1 should be satisfied. This
> consequently had an impact on 3GPP/2.
>From the last SDO workshop I got the impression that the 3GPP2 actually had nothing expect for a few high-level requirements. Since a lot of the 3GPP2 work is taken from 3GPP it might well be possible that they also recycle the emergency services work.
Maybe they have developed a solution already. Maybe you can point to the relevant documents.
There are even
> parameters in the 3GPP MAP specification called NA-ESRK and
> NA-ESRD (the NA part stands for North American) - though they
> do actually have generic utility.
But the NENA work is more than just these parameters.
>
> A typical chain of influence would go along the lines that US
> carriers need to meet some regulatory requirement for which
> definitions originating or influenced by NENA form the model
> for deployment. The carriers need their vendors to support
> the functionality associated with the model. Both the vendors
> and the carriers participate in the SDOs governing the
> specifications for the network elements involved and
> subsequently influence what those specifications look like.
> To a large extent, artefacts turn up in SDO specifications as
> an extended phenotype of the significance and influence of
> the US market and the role of NENA in that market.
But it is not really good if the NENA work does not appear in the standardization work of other SDOs.
>
> Does that make sense? I'm not aware that there are any strict
> definitions for the relationship between NENA and other SDOs.
It makes sense but to me it looks like the recipe for a non-working global emergency service solution since there are too many players involved that want to develop their own story.
Ciao
Hannes
> Cheers,
> Martin
>
> -----Original Message-----
> From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]
> Sent: Thursday, 15 March 2007 9:31 PM
> To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT
> Subject: AW: [Geopriv] RE: [Ecrit] NENA
>
> Hi Martin,
>
> what do you mean by "ATIS"?
>
> You mean that ATIS is using the NENA architecture or I should
> have included ATIS in the list of SDOs?
>
> Ciao
> Hannes
>
> > -----Ursprüngliche Nachricht-----
> > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]
> > Gesendet: Donnerstag, 15. März 2007 11:28
> > An: Hannes Tschofenig; GEOPRIV; ECRIT
> > Betreff: [Geopriv] RE: [Ecrit] NENA
> >
> > ATIS
> >
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > Sent: Thursday, March 15, 2007 5:41 AM
> > To: GEOPRIV; ECRIT
> > Subject: [Ecrit] NENA
> >
> > Hi all,
> >
> > I would like to better understand the work done by NENA.
> >
> > Which SDOs are going to make use (or is already used) of the
> > work done
> > by NENA?
> >
> > Consider the following SDOs, as an example
> > - 3GPP
> > - 3GPP2
> > - Wimax
> > - Wifi Alliance
> > - DSL Forum
> > - ETSI TISPAN
> > - CableLabs
> >
> > Since there is often a mismatch between the standards being
> > developed in
> >
> > these SDOs I would like to also understand how the NENA work
> > going to be
> >
> > used on the Internet?
> >
> > Ciao
> > Hannes
> >
> >
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
> >
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>
> --------------------------------------------------------------
> ----------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------
> ----------------------------------
> [mf2]
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 15 Mar 2007 12:57:36 +0100
This archive was generated by hypermail 2.1.8 : Thu Mar 15 2007 - 07:54:41 EDT