All geographic area codes are available for ESRK allocation. Currently being used in the U.S. are (1)dialable ones, either assigned from the wireless provider's numbers or provided to the wireless provider from the 9-1-1 service provider (LEC) or (2) non-dialable ones, using NPA-511-XXXX or NPA-211-XXXX. (In Canada, only NPA-511-XXXX is used, no dialable ones are used.) In the U.S., there is no entity allocating them. There is a proposal working its way through industry groups that would only allocate non-dialable ESRKs in the future and they would be allocated by a third-party administrator. ATIS INC (Industry Numbering Committee) has approved recommending the use of NPA-511-XXXX and NPA-211-XXXX as ESRKs, and ATIS ESIF (Emergency Services Interconnection Forum) now has to work the issues of (1) recommendation for choosing a third-party administrator and its tasks, and (2) developing a migratory path for moving existing dialable ESRKs to non-dialable. If the 20,000 ESRKs per area code (NPA-511-XXXX and NPA-211-XXXX) were deemed not adequate, the other N11 non-dialable numbers could be used, providing an additional 10k per area code each. They could be handed out in small quantities. It would be up to the 9-1-1 service provider (LEC) or wireless service provider, distributing them. For Canada, they are distributed in blocks of 100 each, per guidelines established for that country (no equivalent guidelines in U.S.). If the ESRK as pANI is working through the Selective Router, today the nunbers have to coorrespond to the typically 4 area codes supported by that router. Data records have to go into the ALI database supporting each service area - sometimes statewide or a few states, sometimes down to County for standalons ALI systems - in today's system layout. There is a SRDB associated with each SR switch, usually several switches use a paired SRDB, consistent with the relationship noted above. By the way, I assume the `two big database providers' are Intrado and TCS, as in the wireless solution approach? If so, they handle data records and ALI server updates for maybe 70% of the USA, and route DB updates to the appropriate ALI servers under their contracts with wireless carriers. But, from a terminology standpoint, `ALI servers' has to be clarified here. You may be talking about the ALI servers that connect to PSAPs, or you may be talking about the MPCs and their variable levels of wireless `ALI' record handling (which feed records to the above ALI servers on the basis of a query from the PSAP via those original ALI servers. I expect you are talking about the MPCs where wireless ALI data (and presumably VoIP records) would be stored, to support PSAP->ALI servers->MPC queries. * Any carrier large enough to consider owning their own LGS will also be large enough to get an ESRK allocation - just as cellular carriers do. * Very small carriers, who may need some small number of ESRKs, will tend to use a service bureau for their LGS - such as Intrado - who will manage the global pool of ESRKs for their customers. Having said that, I think there are still some issues - mostly organizational and process-orientated - that will need to be worked out. For example, I'm not sure where the cellular carriers source their ESRK allocation from but, VoIP carriers will need a source of ESRKs from all possible subscriber locations (ESZ) rather than being limited to specific access coverage areas as is the case for cellular. It may even be that cellular carriers get their ESRK pool from the LECs... This would obviously be a poor arrangement for VoIP - and we'd need to work through NENA to have this changed to a more centralized authority. Dick Dickinson (or the Intrado Folks) would be a good person to assist with working this question through. In the slightly longer term, it should not actually be necessary to have an ESRK pool. A single, common, number should be able to be used to route to a particular PSAP (this is a lot like what an ESRD is). If the signaling could carry an LGS ID (plus, potentially, a unique key generated by that LGS), then allocated pools would not really be necessary. The trick here, without changing the emergency network, is having such a mechanism successfully cohabiting with the cellular implementation. For example, the ALI uses the ESRK to select the GMLC/MPC to send requests to. It needs the same sort of mechanism to select an LGS. We could consider it a "stretch objective" for our WG to solve this challenge as well... :) Be forewarned that an ESRD does not represent a PSAP in the wireless E9-1-1 world - it represents a specific wireless tower and face, ie, a specific face coverage area. An ESRK represents, in wireless, a set of towers and faces associated with the basic jurisdictional area of a PSAP, often stated as ` representing a PSAP'. Patti McCalmont: There is no restriction to the Selective Router (switch) itself for an ESRK. It is not restricted to 4 area codes. That restriction is for NPD digits for standard CAMA PSAP interface. It does have follow the required North American Numbering plan for the format of the NPA, that is it take the form of NXX where N=2-9 and X=0-9. The rest of the number just has to be 7 numeric digits. ALI/SRDBs are regional. So Qwest does not access Bell Souths or Verizons or SBCs or Carrier X. If you look at an NPD digit, it is 1 digit to represent an area code, so 0-3 = area code. If there is a need to indicate special processing must take place, flashing, then 4 is added to the same area code. For example, the value 0 and 4 both represent 1 area code. The value 8 is a special NPD used for testing. So the restriction of 4 area codes is really centered around the standard CAMA PSAP interface (8-digit signaling NPD-NXX-XXXX) and not the enhanced CAMA - 10/20 digit interface). Enhanced CAMA PSAP interfaces (10/20 digit signaling) has different mechanism to signal flashing so does not restrict area codes. http://www.numberpooling.org/faq/default.shtml ---- Essentially every country does its own thing. The 112 directive only says it has to pass calls to an emergency service. UK pass all calls to a central call handling centre that passes the calls on to the appropriate fire police or ambulance with the Calling Line ID, The Fire police and ambulance use the CLI to identify where to go. This can be a pain if a corporate gets his dial plan wrong and delivers the call to the wrong point of interconnect. IN France and Germany 112 goes to police, but each country have other numbers to go direct to fire police and ambulance. The idea of delivering location directly from the telephone company is quite usual in the fixed network because they have the database of subscriber addresses. In mobile it is unusual and at present the best that can be done is tell them what cell people are in. So sometimes we listen to people die while the ambulance is looking for them. People are working on how to integrate GPS or EOTD into the emergency services system but quite how far they have got I don't know. My cousin's husband runs the technology for one of the county police forces here in England. I will see if he is interested in getting ahead of the game. --- 1. If the ESRKs were assigned per MPC vendor (TCS or Intrado), the PSAP would have a single point of contact in the event of an ALI failure. In fact, the MPC (which would be registered with a NENA ID) would be a more appropriate contact point that the VoIP vendor, many of whom will not have 24x7 NOCs. Most ALI failures will be the result of problems with the MPC or LEC anyway, and the VoIP vendor will not be able to troubleshoot it. In the event that a call trace is required, the MPC can provide that, too. 2. Even with wireless today, some PSAPs do not have dedicated trunks per carrier. 3. New service providers could not use the network without the express cooperation of the MPCs. In my experience both TCS and Intrado have very high business ethics. We are not Enron. Inevitably, any such abuse would be discovered and the fallout would be far worse than any short term gain. ---- 1. In the event of ALI failure, the call back number and address are not presented to the 9-1-1 call taker and the ESRK is all we have. We need to be able to identify the service provider (who should be registered with a NENA company ID) by the ESRK so that we can initiate a call trace through the service provider. You do not need to repeat the story line that the service provider has no idea where the person is, at a minimum we need the ability to track ALI failures by service provider for statistical measurement/analysis. 2. The incoming trunk group does little to identify the service provider if the same trunk group is transporting calls originating from multiple service providers. However, if you will agree to use a trunk group per service provider I would be delighted. :) ---- If you look at the MSC call flow, the trunk group identifies the connection to the MSC, however; the ESRK sent to the SR identifies the carrier (Verizon, Cingualar, AT&T, etc). Multiple calls from various carriers can be passed over the same trunk group so it is important for the PSAP, for ALI failures, to be able to have a means to identify the source information for the caller. If the pool is owned by the MPC for VoIP Carriers then it would be up to the MPC provider to be able to supply the necessary information to the PSAP (very doable and already in practice). --- As a complete aside - in the wireless realm, and particularly for GSM, the ESRK is currently typically assigned by the MSC and is not generated by the GMLC whether it is a service bureau or otherwise. It is only recently that the standards have been extended to include XY routing of calls with the GMLC being able to generate the ESRK based on the lat/lon. So - up until now - even for service bureau users - the ESRK pools have had to belong to the carrier and not the bureau operator. ---- This does not have a ten digit length limitation - as it is an E.164 format number with standard ISUP encoding. I would be interested in the S/R manufacturer persepective on the capability to utilise arbitrary length (to 15 digit) ESRK values in this field - as well as the LEC operators as to how they typically configure their selective routers. There is already a workaround for this limitation which is utilised for cellular networks. It is often referred to as an ALI-hop (or WALI-hop - for wireless ALI-hop). This network function is in the signaling path and intercepts the value of ESRK provided and provides a shorter, local, value in its place. This is where we can talk about a pseudo-ANI (or pANI) being provided. The pANI-ESRK mapping is pushed into the ALI, the pANI is delivered over the CAMA trunk and, upon query, the ALI substitutes the ESRK for the pANI in making the ESPOSREQ query to the wireless network. It is a level of indirection provided by the emergency network which protects the limited address space supported by CAMA - since a given CAMA trunk does not really need to work into the national address space. The open question in my mind is the extent to which a similar mechanism can be used in VoIP and the degree to which it could impact the existing configurations and operational procedures in the emergency network. I have a query outstanding, now, with our MSC implementors to see what sort of ESRK coding flexibility they support - and whether they know how it is used. --- Normally, ESRKs are issued to wireless carriers. A typical allocation may be from 5-15 ESRKs per PSAP per carrier. Each ESRK has an NPA commensurate with the local selective router. In some LECs, the ESRKs come from the pool of numbers owned by the wireless carriers that are usually reserved for issuance to new cellular customers. The wireless carrier has to be careful to ensure that these numbers are removed from the pool of assignable numbers. In other LECs, the numbers are assigned and managed by the LEC. Sometimes these ESRKs have a cost associated with them directly and sometimes the cost is absorbed in the cost of the various trunks purchased by either the PSAP or the carrier. Every LEC is different. With VoIP, the number of VoIP "carriers" will be significantly greater than the number of wireless carriers. Moreover, evey VoIP carrier is potentially a nationwide vendor, meaning that an ESRK may be required for every PSAP, even if only one customer may have service in certain jurisdictions. This promises to be a nightmare for ESRK management, as well as in inefficient use of ESRKs. Thus I have proposed that ESRKs be issue per MPC per PSAP. In this way, each MPC vendor can reuse ESRKs for different carriers. Given 5 ESRKs per PSAP, and 7,000 PSAPs and 2 MPC vendors, this comes to a grand total of 70,000 ESRKs required nationwide. It is currently not feasible to have a single pool of ESRKs (or a single ESRK) per PSAP, to be shared by everyone. This would be possible if the PSAPs could receive 20 digits: 10 for the ESRK and 10 for the call-back number. In this way, the ESRK could be used for routing, while the CBN could be used for the record key in the MPC. The problem is that some PSAPs cannot accept 20 digits. More importantly, the LECs will not allow ALI steering for 20 digits. TCS has been clamoring for "20-digit" NCAS for years, but the LECs refuse to allow it because this would threaten their own HCAS solutions. --- Individual PSAPs do have one-button transfer capability to select PSAPs in their area. These transfers route the call back to the selective router and then back to the next PSAP. Both PSAPs have access to ther same ALI database, so they can both query to receive the callers location data. In cases where PSAPs transfer calls but do not share the ALI, this is a serious problem for them. --- 1. A single ESRK per vendor per rate center will not work. ESRKs are dedicated per PSAP. As a minimum, you could have 1 ESRK per PSAP. However, in a VoIP world based on wireline responders, it would be better to have 1 ESRK per ESZ. Each PSAP has numerous ESZs. Also, this would mean that you could only support one call at a time. This would not create too much trouble until the PSAP might elect to requery the ALI database for whatever reason, at which time the dispatcher would receive ALI data for the last call, not necessarily the one in progress. My recommendation is to have 5 ESRKs per ESZ. However, these ESRKs should be assigned to the MPC vendor, not the VoIP vendor. In this way the MPC can use the same ESRKs for multiple VoIP vendors, thus saving ESRKs and maximizing their efficient usage. 2. No. Access to selective routers is permitted only via direct trunking from the Central Office or via direct trunks from your switch. It is not cost effective to install interlata SS7 trunks to specific selective routers. Also, you cannot route a 911 call across the PSTN from one switch to another. ---- Information regarding phase II deployment (by at least one provider in a county) can be found at http://nena.ddti.net/. ---- ESRK pool management should be a pool per PSAP used by all VoIP Vendors. This also provides for a congestion control method, something now missing with Wireless calls since each carrier is provided their own pool (on a per PSAP basis (not an ESN) - much wider coverage than what would be required for VoIP equivalent Wireline service). --- 1) The 211 and 511 numbers are generally, at this time allocated by 9-1-1 system service providers in a fair and equitable manner to the wireless carriers that need them for service within the service area that the 911 SSP provides service to. Although they technically can be any NANP number with a 211 or 511 NXX, they are for now, restricted to the NPAs that are served on the particular 9-1-1 Selective Routing Switch that the call is routed to, and through. This is NOT necessarily due to a limitation on the router, but often due to other limitations. Often a carrier will want more pANIs than they can be allocated fairly, and then, it is up to them to use their own numbers in order to fill the gap between what can come from the 211/511 numbers and what they need. 2) There are many (most) PSAPs out there STIIL using the OLD 7 digit call delivery mechanism. This is sometimes because the 9-1-1 SSP hasn't started upgrading the interface and letting the PSAPs get the benefit of the new format, but more often than not, because the PSAPs haven't seen fit to upgrade their CPE to take advantage of the enhanced format. So, as long as there are PSAPs out there that are on 7 digit format, the NPA delivered as a key to the call at the router will need to be from an NPA designated by the 9-1-1 SSP that can be managed and handled within that network. 3) In most cases, as Patti said, the limit of 4 NPAs per area is NOT due to a router problem, but is in fact limited to the 7 digit signaling format (and ALI bid links) that are limited to being able to ONLY uniquely send 4 NPAs in a way that the PSAP can ONLY get unique ALI on up to 4 NPAs. Yes, there are some fixes, but they aren't universal, and can only boost the NPAs into a PSAP to a few more NPAs where the NPAs from one router, or PSAP trunk are each kept under 4, so the things that can be done do NPT let ANY NPA be used at the PSAP. 4) Cost of pANIs and delivery of service for VOIP in a wireless look alike service... Each 9-1-1 SSP has their own tariffs, or contracts for the WIRELESS services that they provide, or act as an intermediary for the wireless carriers to meet their FCC mandated duties and deliver calls to the PSAPs that have agreed to take them. The attempt to deliver VOIP in this fashion is outside of those agreements, and as such would likely be another service, and the cost of pANIs would therefore be different for that design than under other services. In addition, since this service is delivering a land based call to a PSAP under current wireless routing, with ALI that may (or likely will NOT) match land line MSAGs, to a PSAP that isn't getting paid for the service, with a class of service that doesn't accurately represent the VOIP type of user, you may find that the Public Safety Community doesn't want to take those calls that way, or expects that they WILL be delivered like a land line call, on land line trunks, with ALI that matches land line ALI and MSAGs, and with surcharge or other revenue that compensates the PSAP for their work to take and handle, and dispatch, and do error resolution on them, and etc... That also excludes the 9-1-1 service provider who also will need to come up with a tariff or other service offering that will properly charge any provider for the services that they use of the 911 SSP, and who may see fit not to deliver the service if it doesn't fit the standards that their other customers - the PSAPs want or are willing to accept. So, as for delivering these through the wireless network and making a land line call look like wireless - that I would suggest needs to be addressed with BOTH the PSAPs that are going to get them, and the 9-1-1 service provider that you are sending them through. 5) Relative to the on board, or external or centralized database. Think of it as 33% each with 1% for "other." Yes, many selective routers and PSAPs use a large centralized database, and route through the external database, but many also use an internal database to the router, or even route to a small selective router that serves PSAPs with local ALI systems. In the big cases, the external, centralized database serves no more than the PSAPs of a particular 9-1-1 service provider in a state. However remember, that there can be SEVERAL 9-1-1 service System Providers in a state as well, and even if all were off board, and centralized you still would need to connect to several. In SBC Midwest for example (Illinois, Wisconsin, Indiana, Ohio, and Michigan), we have 5 centralized database pairs, 2 serving one state each, 1 serving 2 states, and 2 more serving only portions of a state (Illinois is served by 2 pairs). And although we have come up with a front end server/router system that allows a third party provider, or other wireless carrier to interconnect to just one diverse pair of nodes, and steer to any of these 5 database pairs, there are in Illinois for example at least 4 other 9-1-1 system service providers not connected through this common front end interface. Finally, remember that there are MANY counties out there that aren't even taking wireless OR land line calls, and that is like a whole other 9-1-1 provider issue as well. Paul Stoffels ---- In the context of this discussion, ESRKs or ESRDs within the 4 NPA restriction are required, and the full 10 digit code and the 10 digit callback number arrive to the PSAP in the ALI record. Some places are using variants on the Hybrid wireless solution with 10 digit numbers through EMF or ISDN interfaces, but most are 8 digit. --- * ESQK identifies: the call instance, the LGW, and the PSAP (only needed because S/R can't/doesn't process CdPN=ESRN on "wireline" emergency calls). * ESRN identifies: the ESGW, [possibly mirrored] E9-1-1 S/R(s) to get to the correct PSAP. (Could conceivably identify PSAP for direct routing.) --- Prepaid cards do contribute to the E911 fund according to formulas developed by the local jurisdiction or by the wireless carrier. In some cases, a flat fee is levied at the time of sale. In other cases, a fee is prorated across several months. In other cases, the wireless carrier or reseller contributes according to usage (If a card is used up after 30 days, no contribution is required for the subsequent month). There is no national standard, but we wish there was. Prepaid cards are a headache. --- 1. Call is initiated. 2. Call server requests LGS to provide routing information + plus provides assigned callback number. 3. LGS pings access network LIS for location information. 4. LIS provides lat/lon *and* street address info. 5. LGS determines route from lat/lon and informs call server. 6. LGS determines ESN and caches with query key, location info, and callback number. 7. Responding PSAP queries ALI with query key. 8. ALI performs E2+ request to LGS 9. LGS returns civil address location, lat/lon, ESN, callback number ---- The Easy one first: PSAPs now on 10 digits: It is probably much lower than we think, and certainly lower than we want. Probably 15%-25% of the nations PSAPs are capable of receiving a 10 digit number. But there are MANY other reasons why these systems (and their 9-1-1 service providers) should be upgrading them to Enhanced MF. NENA should be addressing this, and in my opinion, should explain to their members of all of these reasons, and get them to move forward. Coming up with a pANI solution when a real callback number can be delivered, merely because some/most PSAPs (and/or service providers) haven’t upgraded to the current state of the art, is again, coddling the customers not willing to invest in the upgrades that they need to, because they think some one else will solve their problems for them, and make everything backward compatible. This is strange though, since many of these same customers are the ones who say that they want the call back number delivered with the call, in cases, where for example, the ALI updates are not working, and can’t provide it. (and I’m not just talking about you Ric, nor am I talking about the Internet devices. This could be in the 9-1-1 provider’s network too). This means that while the use of pANIs in local NPAs to the selective router can cause calls to be delivered to PSAPs, we still should always be asking ourselves how to actually deliver a real callback TN instead of the pANI with the call if that is possible. The harder question is the MSAG validations and why, and ESN use: I see that there seem to be 2 camps out there. They have suggested 2 ways that we are trying to locate the caller – either by validating a postal type address against an MSAG to get a destination PSAP, or by trying to validate a Lat/Long against a PSAP boundary map. So, which method to deciding where a caller is located (or where to route it to) is being suggested. MSAGs are really just a big list of street names and house number ranges that contain an ESN AND an indicator of some account or group of MSAG ledgers. In many cases, the actual number of the ESN is used over and over in different selective routers in the same 9-1-1 providers territory, so just getting an ESN isn’t going to tell you where to route the call, since you won’t know what selective router to send it to. The MSAG ledger ID also is not specific, and although MANY of these IDs map into a particular selective router, there are many cases as well where the ID is shared across selective routers and will not uniquely tell you what switch to route the call through. If those 2 or 3 routers don’t repeat the ESNs (planned that way), and only 1 of them has the trunks to the PSAP. When you have a central office with cable to fixed locations, you can look at a map, and easily tell the LEC (ILEC/CLEC) that “calls from here go to that router there.” The MSAG account is not associates with this choice. It is hard and fast geography that decides the far end of the trunk groups. We have no problem telling any one where our router boundaries are, and/or what areas route to a given router, but what I am saying is, that the MSAG validation WILL NOT actually, 100% tell you what router to send the call through. In contrast to this, I have seen references to using the lat/long of a device to validate against a point/polygon type map that tells the user what PSAP the call should route to. I am less familiar with who has these, how they are updated (say when a PSAP extends a house number range on a particular street by 4 numbers), and where the source data is coming from (MSAGs, Maps, etc.)? This seems to be secondary data to the true E9-1-1 routing information, the MSAG, and also precludes the PSAP from getting postal type address information in their call display information. So, I see this as a harder thing to be as accurate as the street address validation. However, I now see that as Brian suggested, the service provider of the device knows its address, and it doesn’t require the customer to do that, or spoof the system. Yes, many can, and will put the wrong community name (choosing the more affluent one of two is done all the time), but in general, after the first call, that can be determined, and then figure out how to correct it, and not do further mis-routes. Finally – SS7 vs. CAMA. Yes, Selective routers (many/most) can take and receive calls over SS7 signaling, ISDN PRI, and even traditional CAMA. HOWEVER – that is on the incoming side to the router. Outbound to the traditional (legacy) PSAP is NEITHER CAMA OR SS7, (and rarely is it even ISDN). It is CAMA-LIKE, not true CAMA. Only a point that matters to me, but I need to say it. This is because there are no other standards that any one else has that allow a non MF call delivery format to be built into the CPE AND the selective routers. Without those standards, the routers can not develop a new interface to send the call to the PSAP. (Yes, there is an old ISDN version, but no vendor I know of actually has built to the standard of that, and it only would allow a 10 digit number to be sent in digital format to the PSAP and not any other significant data. But, this means that the information to a PSAP can ONLY come in as MF digits, OR as data down a traditionally slow data circuit, currently now just a bunch of fixed field width characters with no delimiters, and bi-directional transmission to the PSAP upon ONLY a single request message for information in either a 7 or 10 digit type TN format. This data transmission can not ask any other questions other that a simple – here is a 7/10 digit number, spill me the data. And it only gets the data in the record for that TN. It can NOT accept data pushed to it without it first asking for it. So, no, PSAPs do NOT have ISUP data transmission into them, nor will they for any time soon - i.e, not for another 10 years or more IF it is needed. So, I guess the final thing to say, is that I see that this proposal makes a PSAP basically have 2 types of incoming services. One is the traditional legacy, that will serve phone type services for the indefinite long term future. The other would be VOIP type service. Yes, many PSAPs (ad CPE vendors) are developing VOIP type technology into the answering stations at the PSAP, but we don’t have a standardized interface that will replace that old MF from the router to the PSAP. Dare I ask that you might have a simple standard all of us 9-1-1 providers and PSAPs don’t know about (or haven’t been hit over the head with) that will, and can be used as the next router to PSAP interface, so that the CPE and switch vendors can develop to that, and maintain calls through the selective router, with the new bells and whistles of VOIP? That of course assumes that you expect that it might be easier for you to still go through a central router. If you think not, then come up with a separate delivery mechanism that looks like it is a parallel/overlay design, and which doesn’t try to use the ALI links that are there already, and start getting PSAPs to put them in to their PSAPs in parallel with, and side by side with their current legacy equipment. Your next difficulty there will then be how to get that PSAP that has this to be able to transfer the call to the one that doesn't. ----- The SR uses the ESN to choose the destination PSAP, so it is a key routing criteria on the SR. However, there are many tens of thousands of different combinations of Police Fire, and EMS agencies out there, and in general practice, (even though some routers can handle ESNs to 15,000), ESNs are still assigned under 1000. Knowing the ESN that the database has with the TN will help you figure out what PSAP to send it to IF AND ONLY IF you know the selective router to send the call to first. Then, that router will look at the phone number of the caller (real callback number, pANI, etc.) and ask the database for the ESN associated with that TN, and route the call. SO, YOU DO NOT NEED TO KNOW THE ESN. THAT CHANGES, CAN BE CHANGED, AND WILL BE CHANGED, AND IT DOESN'T TELL YOU A THING. WHAT YOU NEED TO CHANGE IS, INSTEAD OF WANTING THE ESN - AN ARBITRARY NUMBER THAT REALLY HAS VERY LITTLE MEANING IS: What is the PSAP that this goes to? Yes, that can change to, as things get annexed, systems combine, or go enhanced, and yes they change all the time too. Not frequently for any one, but in general, many changes of customers from one PSAP to another happen through out the year. As for cities with the same street name – sure, they can have duplicate street names, but it only works if the house number addresses there are in different ranges. Otherwise the routing is ambiguous, and one area gets the calls for the other when those TNs’ addresses validate against the MSAG. It is up to the 9-1-1 system administrator to correct incidences of duplicate names during the implementation interval of the E911 system. That is one reason why it takes a little time – and yes, some people get new addresses because of E9-1-1. -------- In the legacy network, the SR does have intelligence/attributes assigned to ESNs. The feature "selective transfer" relies on the ESN to control which Law, Fire, or EMS responder will be dispatched. Certain default and overflow routing criteria may also be controlled by the ESN of each incoming call. -------- Note that we must not confuse the E2 spec with the E2 protocol. The J-STD-036 identifies the E2 interface as the connection between the ALI and the MPC. It then goes on to define an E2 protocol. However, there are a variety of other protocols for the E2 connection, including E2, E2+, PAM, NENA, etc. The E2 protocol does not support any sort of civic address--it is designed for lat/lon only. The E2+ does support lat/lon plus a civic address, but it does not do any sort of validity confimation. Meanwhile, the PAM and NENA formats also support lat/lon and/or civic addresses. Each LEC chooses which protocol to use. Verizon, for example, uses PAM. PAM does a fine job of providing lat/lon as well as the civic address. ---- Access to the MSAG is a big problem. Given the PSAP's requirement that all civil addresses be MSAG valid, TCS has determined that the only current alternative is a brute force approach in which we will collect MSAGs from every PSAP willing to provide them and maintain our own database of MSAGs. If the PSAP cannot provide their MSAG, then we will be forced to deliver a call-back number only, unless the PSAP will accept non-validated civil addresses. This will continue until there is a better way to access some sort of national MSAG. (There are MSAG sources available today, but to my knowledge they require one-by-one manual confirmation, not suitable for thousands of new addresses every day) ---- The NENA Company ID code, which is currently 5 characters in length, identifies the line owner (with some exceptions for reseller cases). It is often used to attempt to identify the originator of the data base record. However, that doesn't identify the `address is correct' point. The correct-address point is the E9-1-1 system service provider (SSP), as that is where the `raw' TN records are processed against the MSAG, which is the validator mechanism. Take this case: Originator X has the customer, and sends an extracted subscriber TN record to the SSP, who then processes it against the MSAG. If it passes, it becomes an ALI record, which is sent to the PSAP upon query against a 9-1-1 call. Since the ALI record exists, it by definition contains a valid address - unless, of course, the originator company has failed to send an update for move or change of service. If the address of the TN record is invalid against the MSAG, no address exists in the ALI system, and a default record goes to the PSAP if a 9-1-1 call occurs, until such time as the correction process resolves the address-to-MSAG descrepancy. ---- NENA ID is in the ALI message delivered to the PSAP. If you look at the version 1 schema, it is the "DataProviderID." (In earlier versions it was in a field called "Company ID 2," defined as the ALI data source provider. In the existing E9-1-1 database infrastructure, it is REQUIRED (and therefore assumed as a given) that the civil location information will be validated against the MSAG before it is entered into the database. I believe this is also documented in Section 2.7.1 of the VoIP E9-1-1 Requirements TID prepared by the NENA VoIP E9-1-1 Requirements WG. http://www.nena.org/companyid/index.htm http://www.nena.org/9-1-1TechStandards/Standards_PDF/NENA%2002-010.PDF ---- My PSAPs do not do lat/lon to civil address conversion. We can dispatch to the nearest intersection or block range of the coordinates provided by a wireless carrier, but it would be dangerous to conclude that the coordinates identify a specific house. If the VoIP user has self-identified using a MSAG-validated civil address, we would like to have that civil address. If that address is not where the caller is actually located, we will expect the service providers to be able to explain whether it was an error on the part of their location determination process, or the result of the user not providing the correct address when they self-identified. ---- If dedicated SS7 circuits are used to transport these calls to the SR it would be possible and desirable to send both the ESRK/D/ESQK and the calling party TN to the SR, at which point any PSAPs with EMF trunks would have the option of receiving both numbers. ---- - Address content (i.e.; house number range, street name, community, etc.) and ESN assignment is managed by the respective serving jurisdictional entity; however the ESN values available for use are typically under the direct control of the SR provider. - Most MSAGs reside on LEC-owned platforms, however batch or near real-time MSAG update delivery service is generally available to the serving PSAPs as a tariffed offering. - I am unaware of any legal documents designating "ownership" of the MSAG, but it is commonly believed that the jurisdiction being served has ownership and management responsibility for their respective portion of the MSAG. Tom Hicks ---- A pANI is a fake TN that is not a callback number, but is used to link call and ALI together, and also, or more importantly, is loaded in the 9-1-1 database with default information that associates it with a service (or service provider) AND which has a location value associated with it so that the current E9-1-1 network can use it for routing, and route to the PRE-DETERMINED PSAP that the pANI was loaded for. An ESRD is a single pANI that has fixed geographic properties. It defines a tower face, and has fixed location information, and the pre-loaded record in the data base validates against an MSAG ledger created by the PSAP. That defines the street name, house number, street directional, state, city, and other MSAG specific fields. The service provider defines the customer name field, and the location details. The ESRD is loaded by the service provider (wireless carrier) into the 9-1-1 database according to standard TN loading rules, and validates against the pre-loaded MSAG. The PSAP tells the carrier how they created the MSAG, and the carrier uses that to pre-define the TN record, so that it validates against the MSAG. An ESRD is only used when the wireless carrier sends 20 digits to the 9-1-1 service provider. The unique key is NOT the ESRD. It is the valid 10 digit callback number of the cell phone of the caller. More than one caller, originating from the same tower face, can arrive at the PSAP on side by side positions, concurrently, with the same pANI, but different callback numbers. An ESRD is only used with CAS setup from the carrier to the Selective Router (in phone company/PSAP terms) which is defined as NCAS in J-STD-36. This is why we try to only say that the ESRDs are sent with 2 10 digit numbers, and not describe them as NCAS or CAS – because perspective of those terms means different things to different people. The Query Key for wireless info that contains location info will be the callback number, NOT the ESRD. The ESRD is not generally over-written. It is static. An ESRK on the other hand is a more GENERIC version of a pANI. ESRK values are pANIs in a “POOL” of numbers, that represent a “POOL” of cell towers that all have primary routing to the SAME primary PSAP. ANY and all towers, for the same wireless carrier, whether geographically adjacent or not, are built in the same pool of pANIs, and ALL of them use that pool, and rotate through that pool as calls occur. The MSAG ledger created by the PSAP is generic, since all of the pANIs are common and similar, and the ledger and ALI record is less street specific than with the ESRDs. An ESRK is only used with NCAS (Wireline compatibility mode as per J-36) During the call, mechanisms allow for the phase I and phase II dynamic updates to occur. An ESRK can be dynamically over-written. It is not static like with an ESRD. The ESRD is the query key with this type of call, not the callback number (since with this type of call, the PSAP does not have a callback number till after the ALI query). ------ Standard wireline compatibility mode requirements when delivered to a 9-1-1 service provider. The call will be set up with: - the Called Number = 911, - the Charge and/or CPN = ESQK. NOTE: If both of these are populated, they MUST be the same number. No calls with Charge and CPN different values. - NO GDP (not a type 13 - wireless GDP) - OLI = ordinary (not Wireless) or omitted. - CPCat (Calling Party Category) = Ordinary 0A hex (not Emergency - E0 hex) - Calls will be delivered over dedicated trunks, marked as 9-1-1 traffic only. NOTE: Non 9-1-1 calls will not be allowed to route over those trunks. - ESQKs will be pre-loaded in the 9-1-1 database before use. - PSAPs will provide the proper MSAG spelling and field formats to the LGW operator, who will load them to the 9-1-1 service provider database according to standard rules. - Any call delivered over the 9-1-1 trunks that does not have an ESQK that validates against an MSAG ledger will default route to a designated PSAP for the group. - The LGW who orders the trunk group from the 9-1-1 service provider will provide the 9-1-1 service provider with the PASP that has AGREED to be the default PSAP for the trunk group. They may be required to confirm that the PSAP has agreed to be the default PSAP. - There may be tariffs, contracts, charges or other service fees that a 9-1-1 service provider, and/or PSAP will have entered into with the LGW before the service is allowed to be activated. This, as a new (and potentially un-regulated) service, may not be charged according to the same schedules as wireless services are charged, due to the differences in the service design. - It is the responsibility of the LGW to provide survivability, and diversity within their network, including the trunks into the selective router. - The class of service indication displayed to the PSAP will be dependant on 9-1-1 service provider capabilities, and is based on those classes of service currently defined by NENA as those displayed to a PSAP (subject to database capabilities). ---- Callbacks use the PSTN. 9-1-1 router to PSAP circuits are 99%+ of the time restricted to 1 way traffic to the PSAP. PSAPs can only originate a conference (3 way on them) during the period that a call is up and active. Once the caller drops, a PSAP can not generate the calls. Therefore, A PSAP can not generate a call through the selective router to the callback number, and must use the alternative, a local POTS number, unrelated to the selective router (even if co-located thereof). Yes, PSAPs can make long distance calls. ---- Let me explain why an ESQK can’t be a callback. - In most databases, there are, or will be edits to prevent a phone number (other than those specifically marked) from being dynamically over-written by E2 data queries or transmissions. This prevents land line numbers, or ESRDs from inadvertent changes that should not occur. - Therefore, only specific numbers in the database (ESRKs) will be marked to allow a dynamic update over the E2 links. A number has to be in the database to be marked this way as well. - Since most of the callbacks numbers associated with VOIP will, I am guessing, not be loaded against the database, and loaded in there with a fixed land line location, then you can’t do this. - If the ESQK was a callback, it would resemble pre-loaded TNs against an MSAG ledger, and route just like a CLEC line, and would collect surcharges, and remit them to the PSAP, and pay the 9-1-1 provider for the fees associated with the service, etc. ---- PC-based PSAP work stations have web browsers (most run Windows of which, IE is a standard component). Internet access varies. Of the four top 911 CPE vendors at least 2 of them forbid Internet access. That would account for about 40% of the "new" installs not authorizing internet access. If new installs make up 25% of the total PSAP amount (1500 ±), than that assumes that about 1/6th of all PSAP's have Internet access (provided their is no contradicting local policy). -----