United States Regional Requirements For the United States, the top 5 priority levels are described in Table A-1.

In addition, the following Use Cases have been identified:

1. Priority Service should be ubiquitous. This requirement means that any authorized user should be able to make a priority call using any UE and that the authorization is "tied" to the user and not the UE.
   1. If, in the short term, having a special UE expedites the fielding of this service, this is an acceptable approach for initial service. However, if the device contains the authorization, there must be a user-involved authentication (e.g., PIN) to prevent misuse or abuse by an un-authorized person.
   2. Initial service might have technology dependent implementations that include differing invocation sequences and man-machine interfaces (MMI). While this might be acceptable in the short-term, a migration needs to be planned to achieve a uniform invocation sequence and a single MMI that supports the ability for any authorized user to invoke priority service on any UE, regardless of technology.
   3. The priority service user should authenticate once for each session. Authentication should be user friendly and will be used for accountability purposes. Authentication might be used for billing purposes. Methods of authentication might include a PIN, a credit-card-like "swipe", or voice recognition.
   4. The concept of using a credit card-like dialing sequence (Dial a specific prefix, enter a credit card and the destination number) for service authentication and billing is acceptable.
2. The user should not have multiple telephone numbers, but rather the ability from one UE with which he/she is able to make priority and non-priority calls on a call-by-call basis. The user should have a user-friendly MMI and/or invocation mechanism to initiate and authenticate a priority call.
   1. The MMI could offer the ability to place the UE into a "Priority Service" mode or profile. During this timeframe, all calls placed from that UE are provided priority treatment. The user would then have to change "profiles" from priority to normal subscription.
   2. The MMI could also easily allow the user to invoke priority service on a call-by-call basis. Prompts might be required to get the user to enter a PIN, authentication, or destination number, if necessary.
3. The user needs to make a voice call in a congested area (due to either increased call volume or infrastructure damage). The user invokes priority service and authenticates.
   1. If end-to-end resources are available, the call proceeds as normal.
   2. As the user attempts to place the call, the network recognizes the user as a priority service subscriber that has requested priority service and allocates network resources to this special user first before servicing other non-priority subscribers. If priority service users of different priority levels attempt to place a call simultaneous, then the user with the higher priority is serviced first by the network, followed by lower priority users, then non-priority subscribers.
   3. If network resources are not immediately available, the network places the priority service subscriber in queue for the next available resource. The queue is managed by priority level and (within each level) time of entry into the queue.
   4. The network provides feedback to the priority service subscriber (either tones or short messages) on the status of their call (e.g., authenticating, queuing, dropped from queue, completing).
   5. The user needs the ability to call with priority other mobile (3G and non-3G) subscribers, PSTN subscribers, and in the future, IP voice subscribers, regardless of their priority status. (Mobile to mobile, mobile to PSTN, and mobile to IP-device).
   6. If, in the case of the US, users need the ability to interwork with GETS, a PSTN service. Since GETS has only one priority level, priority levels need to be mapped and supported so that a GETS call gets priority origination, treatment, and termination across the wireless networks (i.e., across the air interface) and WPS calls gets mapped and supported into the PSTN.
   7. With the current architecture, dissimilar wireless networks connect via the PSTN and not directly with each other. The PSTN is therefore responsible for "translating" priority service indicator(s) for all types of wireless networks.
4. The user needs data services in a congested area (due to either increased call volume or infrastructure damage).
   1. The user needs to send priority and receive priority short messages. The user should have the ability to reject or accept the message. Again, the initiator sets the priority level of the session.
   2. The user sends/receives e-mails, voice-mails, fax etc.
   3. The user needs to query on-line databases and make a transaction (e.g., buy blankets, cots, water, etc).
   4. The user needs to make a secure telephone circuit-switched data call (using COTS secure handsets, e.g., Motorola Sectera GSM phones).
5. Charging Data Records and Billing Issues
   1. In the service provider's billing statement, the user should be able to see/verify each priority call attempt and result (duration if successful, and a reason for termination if unsuccessful).
6. A Service Code of "272" has been identified to invoke Priority Service.
7. Use Cases for PIN authentication are for further study.
8. International roamers should not have access to Priority Service.
9. The ability to distinguish Priority Users from eMLPP Users needs consideration.