Date, Time (MM:DD, and HH:MM. Not even year or seconds in most cases). Customer Name (a 32 character field) House Number (8 AN chars), House Number Suffix (i.e. 1/2 - 4 char), Street Dir. (2 chars only NSEW), Street Name - up to 32 or 48 chars, And City (up to 32), state (2), ESN (3 - 5 characters), No Zip. Then there are variable fields that are the Class Of Service (4 characters as defined ONLY by the choices provided by Delaine), Finally, there is - on ONLY PSAPS with some phase II upgrades, a Lat and a Long field, with in some 9-1-1 systems an optional confidence or uncertainty field. These too are fixed format depending on system. Finally, there is often a 20-32 character location details field. That text can be added to. --- = Customer name – up to 32 characters. Can be updated at time of the call over an E2 link. = Date, Time – often only MM/DD and HH:MM – sometimes not even year or seconds. Never anything other than the time at which the data record is created or sent to the PSAP. Can’t be updated or changed externally. = Class of service of the TN used to do the ALI query – fixed at a set of four characters – based on NENA standards. Can not be overwritten at the time of call, but is substituted, and created from a table of values to 4 character PSAP friendly type (ha ha) display for the particular TN. = Location Details – 20 to 30 characters of details about the apt., floor, or room, etc. that the phone is located in. It is set at what the telco records define it on land line calls, but can be overwritten by customers (PBXs entering their own data through special services from the 9-1-1 service provider). In wireless NCAS – the predominant method, this gets over-written with the 10 digit callback number. Won’t have much chance to do much else with this field. = Address stuff – house number, street direction, street name, city, state – all pretty fixed. In all cases the TN used to do the query MUST match a pre-loaded MSAG ledger EXACTLY. However, again, this stuff (perhaps not state) can be overwritten with data sent from the E2. This is where the PSAPs EXPECT that a VOIP service will be MSAG valid. This is because this data is sent into their CAD, and used to dispatch, or assist the dispatch of vehicles, and pull up mapping. If you use AVE and they use AV, then their system won’t display where the caller is, and they can’t really act as fast as they normally do. = Then there are other fields, like an extrapolation of pre-defined police, fire and EMS agencies associated with the ESN of the TN used for the query. These can’t be changed. = There is also other stuff like the ESN of the TN used for the query, the position number, and trunk number associated with the call link into the CPE, or attendant position. = Finally, there are fields for lat-long, and perhaps confidence or uncertainty. These are filled in with data sent over the E2. The piece that maybe you also need, is that the data that is sent over the E2 that over-writes the fields that can be changed at the time of the call is only allowed on TNs that have the option in the database for doing so. You can’t really just over-write any TN. Also, the data used to over-write, according to desires of the PSAPs, need to match the content (and structure) of the field. For example, don’t put house number, direction, and street name all in the street name field. Put the house number in the house number field, and the street name by itself where it belongs – WITH spelling that the PSAP tells you, which is really the MSAG validation part. --- Shell records are placeholder ALI records, or pointers, indexed by ESRK, which have all the typical field definitions, BUT are pre-provisioned with data values that represent 'default' values. These are literal text strings like 'Wireless Caller' inside the Street Address field, etc. (I'll leave it to someone more knowledgeable to explain what these default values really are.) 1. The PSAP gets an ESRK delivered with the call (NCAS), 2. Issues a request for location data to the ALI, 2. ALI system matches the ESRK with a specific (MPC/GMLC) IP Address, and sends an ESPOSREQ (Invoke) query to get location information 4. ALI gets an esposreq (return result) containing lat/lon and street address, etc (see thread for more detail), and data overwrites the default values within the shell record and is passed back to the PSAP. 5. In the case where nothing is returned to the ALI system, the ALI uses those shell record's 'default' values to send back to the PSAP's CPE display. ---- The ALI's use of a shell record is somewhat implementation specific. In our system the shell record will contain Tower information (especially for Phase I implementations). The shell record is never updated with information received from an MPC -- even for Phase II (we keep that information in a separate, wireless record table). The shell record does have one important function that has not been mentioned -- the ESN assigned to the shell record is used for routing the call to the PSAP -- either on-board the switch (since the ESRK 'TN' and ESN will have been uploaded to the switch) or off-board (the switch queries the ALI for ESN real-time). ---- Currently, the MSAG does not contain any field that identifies which Selective Router serves that address. IN the past and currently, the selective routing files are distributed by NPA/NXX to the appropriate tandem. However, with the proliferation of LNP and eventually GNP and probably VoIP, using NPA/NXX for selective routing will NOT work. The Data Technical Committee has an action item on our issues list that we will be looking at and it is shown below: ---- During the meeting we agreed that we would have two sets of MSAG data -- one without routing information that is public and one with routing information that is private (only accessible from the VPC). The LIS will use the public MSAG to determine address validity--and no routing data will be kept with the LIS data. The VPC will use the private MSAG to get routing information at the time of a call. The routing information the MSAG will need to contain is ESN & PsapID. Both pieces of information are necessary because ESNs aren't unique from switch to switch (i.e. for ESN 01000 for Switch ABC points to a PSAP in New Jersey and ESN 01000 for Switch DEF points to a PSAP in Las Vegas for a Switch in Nevada). The simple case is where a single set of ESNs is implicitely assigned to a single SR--the TNs and ESNs that belong to that MSAG will only be uploaded to a single switch. However I know of cases where TNs and ESNs are loaded to more than one switch for a single MSAG. New Jersey has a single set of ESNs for the entire state and those ESNs are maintained in 4 switches (and all of the TN's for the state are also duplicated in those 4 switches). I don't know how Verizon determines which SR to route calls to in New Jersey. Somehow we will need to have a process that either makes sure that PSAP IDs are unique accross all of the consolidated MSAGs or we will need to include Selective Router as part of the info that makes the routing indicator unique (ESN & PSAPID & SR). It looks like there are situations where we will need to learn more from the LEC to determine which SR should be assigned in cases like New Jersey. If we want to deliver CallBackNumber with VOIP calls those numbers will have to be loaded in the ALI (just as if the VOIP vendor were another CLEC). In that case the I2 solution would need to use the routing information determined from the MSAG (ESN, PSAPID & possibly SR) to determine which ESGW to get to. I think that probably would require the use of some kind of ESRN to insure the system knew what to do with the call. I think once that type of call hit the SR and ALI system neither the SR or ALI would be able to tell that it was a VOIP call rather than a regular wireline call (whether that is good or bad I don't know). ---- Earlier this year, ATIS INC (Industry Numbering Committee)officially agreed wireless E911 ESRD/ESRKs should be non-dialable numbers. This was added to the INC numbering guidelines used by the industry. ATIS ESIF (Emergency Services Interconnection Forum) which sought this INC endorsement, now is determining how to proceed regarding establishing a 3rd party administrator of these numbers and a migratory path forward for converting existing dialable ESRD/ESRKs to non-dialable. (U.S. has a mixture; Canada only using non-dialables) It was not brought to INC that VoIP use may be involved, however, the ESIF subcommittee which worked the issue has added that the use of non-dialable ones applies for both wireless and VoIP. (Non-dialables referenced by INC currently being NPA-511-XXXX and NPA-211-XXXX, giving approximately 20,000 per area code) ----