The Access Control capability prevents mobile users from initiating call origination attempts and from responding to pages in specific areas (e.g., in emergency situations where resource shortages exist). Access control is intended to allow network operators to prevent overload of radio access channels under critical conditions. The basic mechanism is administered as follows: All SIMs are randomly assigned to one of ten access classes (0 - 9). In addition, SIMs may also be members of one or more of five special categories (access classes 11 to 15). These special classes are designated for specific purposes as summarized in the following Table:

In an emergency situation, broadcast messages are used (on an individual cell basis) to indicate the "Access Classes" of subscribers that are barred from network access. Any number of classes may be barred at any one time. For example, to reduce approximately 20 percent of the basic mobile traffic in a given cell, broadcast messages might indicate that two of the basic access classes should be barred from access. Upon receiving an emergency broadcast message, those mobiles belonging to the barred access classes (and not also being members of any of the special classes) should not initiate a call attempt or respond to a page (note 1) . In addition, broadcast messages use "access class 10" to indicate whether network access is allowed for emergency calls. Access Control is designed to suppress not only the ability of non-priority end users to seize traffic channels, but also the ability of those end users to use signaling channels for call attempts. Service Accessibility, as specified, cannot be turned on and off by the end user.

The following Table identifies Service Accessibility support for Priority Service.

The eMLPP service is provided as a network operator's option to a domain of a network. The domain can be the whole network or a subset of the network. The eMLPP service applies to all network resources in the domain, and eMLPP is provided to a subscriber for all basic services subscribed to and for which eMLPP applies. The eMLPP service supports two capabilities: precedence and pre-emption. Precedence involves the assignment of a priority level to a call. eMLPP supports a maximum of seven priority levels. The two highest levels (A and B) are reserved for network internal use (e.g., for emergency calls). These are only used locally (i.e., in the domain of one MSC) ¹. The other five priority levels are offered for subscription and can be applied globally (presuming the priority level is successfully passed from the originating end and processed at the terminating end). For each of the seven priority levels, the network operator can administer parameters that control the treatment of that priority within its domain. This treatment includes the selection of a target set-up time and whether or not pre-emption is allowed for each priority level. For example, a network operator might administer priority levels as follows:

In the example above, three classes of set-up time performance are supported. In the above example, the network operator has assigned class 1 (fast set-up, nominally 1-2 seconds ²) to Priority Level A traffic, has assigned class 2 (normal set-up, nominally less than 5 seconds) to traffic at Priority Levels B and 0, and has assigned class 3 (slow set-up, nominally less than 10 seconds) to the lower Priority Level traffic. 3GPP specifications do not define specific mechanisms (which may include specific technical capabilities and/or network engineering decisions) to achieve the target set-up times as defined by the service provider ³. If idle resources are not available, pre-emption involves the seizure of resources (currently in use by a lower-priority call) for use by a call that is of higher priority. The network releases the lowest-priority call and seizes the necessary resources that are required to set up the higher-priority call. At handover to a congested cell, higher-priority calls replace existing calls of the lowest priority. In the above example, the network operator has chosen not to allow pre-emption. Thus, priority levels will use different queuing priorities rather than pre-emption capabilities. The eMLPP priority level for a given call depends on the calling subscriber. The maximum precedence level for each subscriber is set at subscription time (and is stored on the SIM). The default priority level is established via normal registration procedures. If the user does not explicitly select a precedence level at call set-up, the network applies the subscriber-specific default precedence level. The priority level can be selected by the user on a per-call basis (up to and including their maximum authorized precedence level). The eMLPP service is invoked automatically by the network at call set-up, with the priority level established as above for mobile-originated calls. For mobile-terminated calls, the priority level is established based on the priority of the calling party, and is applied at the terminating end (presuming the call's priority is passed via signaling between the originating and terminating networks). Interworking with ISDN MLPP is required. The eMLPP service applies to roaming scenarios, if eMLPP is supported by the related networks. The HLR maintains the logical state for eMLPP (provisioned or not provisioned), the maximum priority level, and the default priority level for each user. The MSC stores service configuration information for each priority level (i.e., set up time [class] and pre-emption indicators, as illustrated in the previous section). The SIM stores data that influences UE actions, as noted in the following Table:

The maximum authorized precedence level is stored on the SIM, allowing the mobile station to check that only an authorized level is used for set-up. (In addition, the network may verify the level used at set-up against the maximum authorized level.) In the case of automatic answering of an incoming call with a sufficient priority level, the alerting indication to the calling party may not be provided in order to shorten the set-up time. If the called mobile subscriber is busy and automatic answering applies, the existing call may be released (if pre-emption applies) or may be placed on hold in order to accept an incoming call of higher priority.

The following Table identifies eMLPP support for Priority Service.

The SIM specifications address the allocation and administration of Access Control Classes for control of Service Accessibility. All mobile stations with an inserted SIM are members of one out of 10 access classes numbered 0 to 9. In addition, mobile stations may be members of one or more out of 5 special access classes (access classes 11 to 15). Both the regular as well as the special access class number are stored in the SIM. The access control class is a parameter to control the RACH utilization. The first 10 Access Control Classes (0-9) are randomly allocated to normal subscribers; and the top 5 classes (11-15) are allocated to specific high priority users. The system information messages on the BCCH broadcast the list of authorized access classes and authorized special access classes in the system information messages, and whether emergency calls are allowed in the cell to all mobile stations or only to the members of authorized special access classes. If the establishment cause for the request of the MM sub-layer is not "emergency call", access to the network is allowed if and only if the mobile station is a member of at least one authorized:

• access class; or
• special access class.

If the establishment cause for the request of the MM sub-layer is "emergency call", access to the network is allowed if and only if:

• emergency calls are allowed to all mobile stations in the cell; or
• the mobile station is a member of at least one authorized special access class.

Access Control is designed to suppress not only the ability of non-priority end users to seize traffic channels, but also the ability of those end users to use signaling channels for call attempts. Access Control class cannot be updated by the end-user, but by the operator and/or another authorized body. The information i.e., the access class field can be updated either over the air (with caution) or via SIM Toolkit. Security and authentication mechanism for the update of access control class need to be further investigated.

The following Table identifies SIM based support for Priority Service.

This element indicates the priority of the assignment request in A and Iu interface. Following information may be included in IE:

• priority level of the request (levels 1-14),
• if the request can be queued,
• if the request may pre-empt an existing connection and
• if the request can be pre-empted by another request.

The management of priority levels is implementation dependent, under operator control. Priority information IE is also used if the Network supports eMLPP: "The priority level of a call shall be determined by the MSC. Accordingly, the MSC shall request channel assignment with an indication of the priority level and the pre-emption capability of that call. For this the MSC shall use the priority message element as defined in GSM 08.08. Mapping of the priority information in this message element on the network specific eMLPP configuration shall be performed in the MSC. Queuing and resource pre-emption shall be performed accordingly if necessary." (23.067 [10]) It is coded as follows [19]: Octet 2 is a binary indication of the length of the rest of the element. Octet 3 is coded as follows: Bit 8 is spare, set to 0 pci = Pre-emption Capability indicator (see note) 0 1 priority level:

6 5 4 3
0 0 0 0  spare
0 0 0 1  priority level 1 = highest priority
0 0 1 0  priority level 2 = second highest priority
: : : :
1 1 1 0  priority level 14 = lowest priority
1 1 1 1  priority not used

qa = queuing allowed indicator 0 1 pvi = Pre-emption Vulnerability indicator (see note) 0 1

The following Table identifies Priority Information Element support for Priority Service. Note that the 3GPP specifications do not explicitly define the use of Priority IE, e.g. the data that the setting of the Information Element fields could/should be based on. Since this information element was introduced quite early in the standards, Network Element vendors may have taken this IE into other than eMLPP uses, too. Therefore, mandating usage of these fields in 3GPP specifications in this regard could cause problems. The Table indicates issues that may be achieved with using Priority Information Element, requirements that can be fulfilled with MSC internal or other additional vendor specific functionality have been also identified. Note that vendor specific information or functionality is not needed over open interfaces, where only standardized information is used.