Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TR 22.952  Word version:  18.0.1

Top   Top   Up   Prev   Next
0…   4…   4.8…   5   5.1   5.2   5.3   5.4   5.5   5.6   5.7   5.8   5.9   5.10   5.11   5.12   5.13   6…   A…   B   B.1   B.2   B.3   B.4   B.5   B.6   B.7   B.8   B.9   C   D…

 

4  Service descriptionp. 8

4.1  Assumptions and limitationsp. 8

Priority Service is a subscription service, based on eMLPP service, as described in the Priority Service feasibility study, TR 22.950. There are no Stage 1, Stage 2, Stage 3 specifications for Priority Service. Only eMLPP Release 6 specifications have been updated to be compatible with Priority Service. The following primary 3GPP capabilities were identified in TR 22.950 to support Priority Service:
  • Service Accessibility, as specified in TS 22.011,
  • Enhanced Multi-Level Precedence and Pre-emption (eMLPP), as specified in TS 22.067, TS 23.067, and TS 24.067,
  • Subscriber Identity Module (SIM), as specified in TS 51.011,
  • Universal Subscriber Identity Module (USIM), as specified in TS 31.102,
  • Priority Information Element, as specified in TS 48.008.
    The following assumptions have been made to provide for Priority Service.
    For the purposes of this document, the term "Service User" is a subscriber to Priority Service and a "Service Provider" is a provider of Priority Service.
    No hardware or software modifications to existing Mobile Stations (MS) have been identified as required to support Priority Service. Priority Service subscribers may use MSs supporting the Adaptive Multi Rate (AMR), Enhanced Full Rate (EFR) and basic full rate voice codecs.
    The ISDN User Part (ISUP) Precedence parameter used in the Multi-Level Precedence and Pre-emption (MLPP) service may be used to transmit the priority of the calling Service User through any transit networks to the terminating network.
  • Up

    4.2  Registration / erasurep. 9

    The eMLPP registration and erasure procedures are not applicable for the Priority Service.

    4.3  Interrogationp. 9

    The eMLPP interrogation procedure is not applicable for the Priority Service.

    4.4  Call origination / invocationp. 9

    Service Users are the only subscribers that are allowed to invoke Priority Service. Priority Service is invoked on a per call basis.

    4.4.1  Service accessibilityp. 9

    Service Accessibility, as specified in TS 22.011, supports an "Access Control" capability used by network operators to prevent overload of radio access channels under critical conditions. Access Class load shedding may be applied to a specified localized area and for a specified duration. Invoking access control does not pre-empt calls in progress.
    For priority access to the network, a Service User receives treatment that is fully compliant with Service Accessibility capabilities with the following exceptions, extensions, or clarifications:
    A call receives end-to-end priority treatment, including priority access to traffic channels on the originating side, when a Service User initiates a call using the Priority Service dialling procedure:
    *Service Code (SC) + Destination Number.
    A generic prefix may be used in place of "*SC".
    A Service User is assigned Access Class(es) in the range of 11 - 15 to receive priority access to the network.
    Support of Localized Service Area for Priority Service is not required.
    Up

    4.4.2  Priority radio resource queuingp. 9

    If a Service User invokes a Priority Service call and a radio traffic channel is available to serve the call, then call establishment proceeds.
    If a Service User invokes a Priority Service call and a radio traffic channel is not available to serve the call, then the call is queued for the next available radio traffic channel according to the call's priority level and the arrival time.
    If a Service User invokes a Priority Service call, a radio traffic channel is not available to serve the call, the queue for the cell is full, and the call's priority level is greater than the priority level of the lowest priority request in the queue, then the most recent Priority Service call request of the lowest priority is removed from the queue and the new Priority Service call is queued according to the call's priority level and arrival time.
    If a Service User invokes a Priority Service call, a radio traffic channel is not available to serve the call, the queue for the cell is full, and the call's priority level is less than or equal to the priority level of the lowest priority request in the queue, then the new Priority Service call request is denied.
    If a radio traffic channel becomes available to serve an originating Priority Service request and is assigned to the call, then the call is allowed to proceed.
    If a Service User invokes a Priority Service call and the Priority Service call is queued for a radio traffic channel, but the maximum allowed time in queue expires before a radio traffic channel becomes available in the cell to serve the Priority Service call, then the Priority Service call is removed from the queue and the Priority Service call request is cleared.
    The queue is a collection of all queued Priority Service calls in a cell. The queue is provisionable for a specified maximum number of Priority Service requests in queue.
    The queue has a specified and provisionable maximum time that a Priority Service call may remain in queue for a radio traffic channel.
    Up

    4.4.3  Directed retryp. 10

    If no radio resources are available at a cell, the BSS may try to set up a call on a neighbouring cell if channels are free at that cell. If enabled, handover with cause "directed retry" is attempted if no radio traffic channel is available in the current cell.
    Priority Service does not prevent handover with cause "directed retry", if enabled, from being attempted for non-Priority Service calls. If enabled, handover with cause "directed retry" should be attempted for Priority Service calls concurrently with radio resource queuing. If directed retry is not performed concurrently with queuing, handover with cause "directed retry", if enabled, should be attempted for Priority Service calls prior to radio resource queuing.
    Directed retry handover may be attempted from a service provider's UMTS network to the service provider's GSM network when a priority call is invoked by a service user in the UMTS network that cannot assign a radio traffic channel due to resource congestion in UTRAN.
    For a call originated/terminated on the UTRAN that is redirected to GERAN, the user's priority level is used for subsequent call processing (e.g., priority service processing on the GERAN).
    Up

    4.5  Call progressionp. 10

    The Priority Service users receive priority call treatment/progression through the mobile network(s). A Priority Service call is given higher priority over normal calls in the originating mobile network, to interconnected networks (including the PSTN) and in the terminating network. Note: The ISDN MLPP feature may be used for signalling the priority level to other networks.
    The term "call progression" is used to refer to procedures that are invoked to set up a call from the originating node, through any transit nodes, and on to the terminating node.
    Up

    4.5.1  Progression in originating networkp. 10

    The originating Service Provider applies enhanced call-completion capabilities to increase the probability of successful call setup through the Service Provider's network and to any interconnecting (transit or terminating) network.

    4.5.2  Progression in transit networksp. 11

    Transit network providers apply enhanced call-completion capabilities to incoming Priority Service calls to increase the probability of successful call setup through the transit network. Transit network providers pass the Service User's priority level, if available, to any interconnecting (transit or terminating) network.

    4.5.3  Progression in terminating networksp. 11

    The terminating Service Provider passes the Service User's priority level through the Service Provider's network toward the destination node serving the called party.

    4.5.4  Enhanced call-completion capabilitiesp. 11

    To achieve end-to-end priority treatment, Priority Service introduces special call-progression capabilities in the Service Provider's network and also within transit networks. General (service-level) capabilities are highlighted in this clause. Some of the call-progression procedures are intended to increase the probability of Priority Service call completion through network transit nodes. They are herein referred to as "enhanced call-completion capabilities".

    4.5.4.1  Exemption from certain restrictive Network Management Controls (NMCs)p. 11

    Priority Service calls may be exempted from certain restrictive NMCs (code controls, manual cancel-to controls, Automatic Congestion Control, Trunk Reservation control) to further increase the probability of completion of the call during severe congestion.

    4.5.4.2  Trunk queuingp. 11

    The MSC performs trunk queuing for Priority Service calls to increase the probability of completion of the call. The MSC allows Priority Service calls to be queued on an ISUP or MF trunk group that is marked for trunk queuing only if at least one trunk within the trunk group is in an in-service state. The trunk queuing feature provides the capability to place a Priority Service call that has experienced a No Circuit (NC) condition into a queue associated with a trunk group until a trunk becomes idle or a maximum queuing time has expired. After the first check of all trunk groups in a routing chain, if an idle trunk is not found in a trunk group on which trunk queuing has been provisioned, the call is entered into a queue. The MSC recognizes Priority Service calls and separates them from all other calls. All non-Priority Service calls that overflow to a busy trunk group on which Priority Service trunk queuing is active are sent to the next call treatment. A Priority Service call held in queue seizes the first trunk that becomes idle or, if the maximum queuing time interval expires, is sent to the next call treatment. Trunk queuing can be provided on network routable trunk types served by the MSC. For those trunk groups on which trunk queuing is provided, the following processes occur:
    The MSC first searches in sequence all the trunk groups in a routing chain to determine if there is an idle trunk.
    • If an idle trunk is found, the trunk is seized and used for call routing.
    • Otherwise, if there was at least one trunk group in the routing chain marked for trunk queuing, then the MSC performs a second search of the routing chain.
    • For the second search of the routing chain, the MSC returns to the first trunk group in the routing chain and will look for an idle trunk.
    • If no idle trunk is found in the trunk group and the trunk group is marked for trunk queuing, then the MSC queues the call for trunk queuing; that is the MSC places the call in a first in first out (FIFO) queue for that trunk group and start the trunk queuing timer.
    • If no trunk is seized from the first trunk group (i.e., the queuing timer times out or the trunk group is not marked for queuing), then the MSC proceeds to search the next trunk group in the routing chain.
    During the second search of the routing chain, the MSC can skip all busy trunk groups that are not marked for trunk queuing and directly proceed to search the first trunk group in the chain marked for queuing.
    Only Priority Service calls enter into Priority Service trunk queues. During the time that one or more Priority Service calls are held in a trunk queue for a particular trunk group, the MSC advances all non-Priority Service calls attempting to use that trunk group to the next call treatment. That is, the trunk group with the trunk queuing feature, on which one or more Priority Service calls are held in a trunk queue, is considered busy for all non-Priority Service calls.
    If any trunk becomes available in a trunk group with queued calls, then the first Priority Service call in queue is removed from the queue, routed on that trunk, and the trunk queuing timer is stopped for that call.
    If a Priority Service call times out in a trunk queue and there are remaining trunk groups in the routing chain, then the MSC removes the call request from the queue and continues searching the remaining trunk groups in the routing chain to find an idle trunk. If a Priority Service call cannot be placed in a trunk queue because the trunk queue is full and there are remaining trunk groups in the routing chain, then the MSC continues searching the remaining trunk groups in the routing chain to find an idle trunk. The MSC provides the capability for trunk queuing to be enabled/disabled office wide and, if enabled office wide, to be disabled/re-enabled on any trunk group. The maximum number of Priority Service calls that may be simultaneously held in any trunk queue is provisionable. The maximum time that a Priority Service call may be held in a trunk queue is also provisionable.
    If the calling party abandons the originating Priority Service call by pressing the END key or the system determines that radio contact with the calling party's MS is lost while a Priority Service call request is in a trunk queue, then the MSC/VLR takes the following actions:
    • Stop the trunk queuing timer,
    • Remove that Priority Service call request from the trunk queue,
    • Clear the call according to normal call clearing procedures.
    Up

    4.5.4.3  Treatment of glare conditionsp. 12

    Glare (dual seizure) occurs when switches at both ends of a two-way trunk try to seize the trunk for outgoing calls simultaneously.
    With the activation of Trunk Queuing for Priority Service calls on a trunk group, the probability of glare occurring for Priority Service calls increases. This is particularly true when Trunk Queuing is activated on both ends of a trunk group. Normal glare procedures [12], [14] are applied for each trunk group during the first search of the routing chain, as well as during the second search of the routing chain for each trunk group that does not have Trunk Queuing activated.
    During either the first or second search of the routing chain, if a Priority Service call encounters glare for the first time in a particular trunk group and yields, then the MSC/VLR attempts to seize an idle trunk on the same trunk group. If glare is encountered twice on the same trunk group during any single search of the routing chain, and
    • this is the first search, then the MSC/VLR advances the call to the next call treatment,
    • this is the second search and Trunk Queuing is not active on the trunk group, then the MSC/VLR advances the call to the next call treatment.
    • this is the second search and Trunk Queuing is active on the trunk group, then the MSC/VLR attempts to seize an idle trunk on the same trunk group.
    Up

    4.5.4.4  Relationship of NMCs to trunk queuingp. 12

    Pre-hunt trunk group controls are processed before trunk queuing when they are active on the same trunk group. Trunk queuing is processed before post-hunt trunk group controls when they are active on the same trunk group.

    4.6  Call terminationp. 12

    The terminating Service Provider applies enhanced call-completion capabilities to incoming Priority Service calls to increase the probability of successful call setup through the Service Provider's terminating network. Additionally, the terminating Service Provider passes the Service User's priority level through the Service Provider's network toward the destination node serving the called party.
    A Priority Service call receives priority treatment (priority access traffic channels) on the terminating side, based on either the calling party priority level information received or default priority level. The default priority level is used only if the calling party priority level information is not received. If an MS provides specific radio channel preferences (e.g., dual rate, half rate, AMR) to the network during the call termination attempt and a radio traffic channel preferred by the MS is not available, the network attempts to allocate a radio traffic channel acceptable to the MS before queuing the Priority Service call request.
    If an incoming Priority Service call terminates to a Service Provider network and a radio traffic channel is available to serve the call, then call establishment proceeds.
    If an incoming Priority Service call terminates to a Service Provider network and a radio traffic channel is not available to serve the call, then the call is queued for the next available radio traffic channel according to the call's (received or default) priority level and the arrival time.
    If an incoming Priority Service call terminates to a Service Provider network, a radio traffic channel is not available to serve the call, the queue for the cell is full, and the call's priority level is greater than the priority level of the lowest priority request in the queue, then the most recent Priority Service request of the lowest priority is removed from the queue and the new Priority Service call is queued according to the call's priority level and arrival time.
    If an incoming Priority Service call terminates to a Service Provider network, a radio traffic channel is not available to serve the call, the queue for the cell is full, and the call's priority level is less than or equal to the priority level of the lowest priority request in the queue, then the new Priority Service call request is given the same treatment as appropriate for non-Priority Service calls that do not get a radio traffic channel.
    If an incoming Priority Service call terminates to a Service Provider network and the Priority Service call is queued for a radio traffic channel, but the maximum allowed time in queue expires before a radio traffic channel becomes available in the cell to serve the Priority Service call, then the Priority Service call is removed from the queue and the Priority Service call request is given the same treatment as appropriate for non-Priority Service calls that do not get a radio traffic channel.
    See subclause 4.4.2 for additional information on radio resource queuing.
    Up

    4.7  Handoverp. 13

    Priority Service is supported during intra-BSC and intra-MSC handover. Established Priority Service calls follow standard handover procedures as for normal calls. Queued Priority Service calls follow standard intra-MSC Stand-alone Dedicated Control Channel (SDCCH) handover procedures.
    If a system invokes intra-MSC SDCCH handover procedures (e.g., when the Service User moves to a new cell served by the same BSC or another BSC on the same MSC) while the Service User's originating Priority Service call request is queued for a radio traffic channel, the system re-queues the request based on call priority level and call arrival time in the new cell if no radio traffic channels are available in the new cell. The queue timer is restarted in the new cell. This allows queue management in the new cell to handle the call.
    Inter-MSC handover does not apply to Priority Service requests in queue. Inter-MSC SDCCH handover for queued Priority Service calls is not supported. SDCCH handovers of queued Priority Service requests to new cells, when no radio traffic channels are available in the new cell should only take place when no other suitable radio traffic channels are available in the current cell. In such a situation, the priority level should be used to determine the place in the queue on the new cell.
    Up

    Up   Top   ToC