Fixed wireless access sessions

The MAG-c supports a rebalancing operation to restore an equal distribution of sessions among the eligible set of highest-priority UPs, that is, the set of UPs belonging to the highest-priority entry in the target profile for a TAI list or ECGI and NCGI list. Clearing a configurable percentage of sessions on each of the currently active UPs in the highest-priority entry of the target profile via CLI or via a network element management system, such as NSP, triggers the rebalancing operation. When a new UP becomes active and belongs to the highest-priority entry in the target profile for a TAI list or ECGI and NCGI list, a log event is generated to signal that a rebalance operation should be performed.

When the number of surviving UPs in the highest-priority entry of the target profile falls below the configured threshold, sessions may be anchored on UPs that are not highest-priority UPs. When the number of surviving UPs increases up to the configured threshold, a revert operation can be performed to reanchor the sessions from the lower-priority UPs to the highest-priority UPs. Clearing a configurable percentage of sessions on each of the lower-priority UPs for the target profile via CLI or via a network element management system, such as NSP, can trigger the revert operation. A log event is generated to signal that a revert operation should be performed.

clear mobile-gateway pdn bearer-context target-profile

A:MAG-c>config>mobile>profile>node-selection# info
----------------------------------------------
                group-label "site1"
                exit
                group-label "site2"
                exit
                client-profile "pgw_tai_client_prof"
                    entry 1
                        match
                            tai-list "tai1"
                        exit
                        action
                            set-target-profile "target_prof_tai1"
                        exit
                    exit
                    default-action
                    exit
                exit
                target-profile "target_prof_tai1"
                    entry 1
                        threshold 3
                        match
                            group-label "site1"
                        exit
                    exit
                    entry 2
                        threshold 2
                        match
                            group-label "site2"
                        exit
                    exit
                exit
----------------------------------------------

clear mobile-gateway pdn 1 bearer-context target-profile "target_prof_tai1" action rebalance up-peer 30.0.1.188 
clear mobile-gateway pdn 1 bearer-context target-profile "target_prof_tai1" action revert up-peer 30.0.1.241 

clear mobile-gateway pdn 1 bearer-context target-profile "target_prof_tai1" action rebalance up-peer 30.0.1.188 percentage 50 
clear mobile-gateway pdn 1 bearer-context target-profile "target_prof_tai1" action revert up-peer 30.0.1.241 percentage 50 

clear mobile-gateway pdn 1 bearer-context target-profile session-deletion-rate 100 "target_prof_tai1" action rebalance up-peer 30.0.1.188 percentage 50 
clear mobile-gateway pdn 1 bearer-context target-profile session-deletion-rate 100 "target_prof_tai1" action revert up-peer 30.0.1.241 percentage 50 

The concept of a bearer defines the 4G FWA QoS functionality in mobile networks. Sessions support default bearers of the non-GBR type, as determined by specific parameters, and only APN-AMBR is supported for mobile rate-limiting.

4G FWA sessions only support default bearers and these default bearers must be of the non-GBR type. This means that only an APN-AMBR is supported for mobile-specific rate-limiting.

The authorized QoS parameters are used for the generic mobile QoS functionality. They are installed on the FWA-UP using PFCP QER constructs and included in the GTP Create Session Response message so the MME can signal their values to the eNodeB and the UE.

The APN-AMBR can be dynamically changed during the session lifetime using the following procedures:

• RADIUS CoA including the 3GPP-GPRS-Negotiated-QoS-Profile attribute
• Npcf_SMPolicyControl_Update service operation
• HSS-initiated QoS procedure, where the new APN-AMBR is sent using a GTP Modify Bearer Command message

These procedures trigger a forced change of the APN-AMBR on the FWA-UP using a PFCP Session Modification Request that updates the applicable QER IE. When successful, the MAG-c initiates the PGW-initiated QoS update procedure to signal the new APN-AMBR to the MME/HSS using a GTP Update Bearer Request message.

In 5G mobile networks, the QoS flow is a key concept. The MAG-c interacts with the PCF to create and then signal QoS flows, along with corresponding default-bearer information, to the RAN (gNodeB), UPF, and the UE.

configure mobile-gateway profile qfi-mapping-profile 5qi-as-qfi 

configure mobile-gateway pdn qfi-mapping-profile
configure mobile-gateway pdn apn qfi-mapping-profile

When QoS flows are created, the MAG-c acting as the SMF signals the QoS flows and the corresponding parameters to the RAN (gNodeB), UPF, and the UE. Toward the RAN and UE this includes parameters that are typically not applicable to SMF or UPF and are passed through as they are; for example, averaging window.

When a session is provisioned with policy and charging control (PCC) rules, the MAG-c enforces QoS as specified in 3GPP TS 23.501 and TS 23.503. The MAG-c supports the following PCC rule parameters for QoS enforcement:

• precedence versus other PCC rules in case of overlapping packet classifiers
• list of service data flows (SDFs) that act as classifiers to associate packets with PCC rules. SDFs can contain the 5-tuple or the type of service (TOS) field classification, and can be bidirectional or unidirectional.
• 5G quality of service identifier (5QI) and allocation and retention priority (ARP) to determine the end-to-end 5G QoS characteristics
• indicator to bind the PCC rule to the default QoS flow, which is created based on the session level 5QI and ARP values. The 5QI and ARP values are ignored for the QoS flow binding.
• indicator to enable reflective QoS
• gate status to allow or disallow the PCC rule to forward traffic
• maximum bit rate (MBR) and guaranteed bit rate (GBR) values
• QoS characteristics specific to a radio access network (RAN) such as priority level, averaging window, maximum data burst volume, and maximum packet loss rate. These are passed as is to the RAN and act as overrides for the QoS characteristics associated with the 5QI.
  Note: QoS characteristics for a standard 5QI are defined in 3GPP TS 23.503 table 5.7.4-1.

Based on the provided 5QI and ARP values and the default QoS flow binding, the MAG-c generates QoS flows as specified in 5G QoS attributes. For any GBR QoS flows, it sets the guaranteed flow bit rate (GFBR) and the maximum flow bit rate (MFBR) value to the sum of the GBR and MBR values of all PCC rules tied to that QoS flow.

The following figures show the rate enforcements.

The MAG-c automatically generates a default any-to-any PCC rule that uses the session level 5QI and ARP in addition to any explicit per-session PCC rules. When the creation of the any-to-any rule is disabled, the MAG-c does not automatically install a default rule and drops any traffic that does not match a specific PCC rule.

Perform the following steps to disable the creation of the any-to-any PCC rule:

1. Use the following command to enable 5QI to be used as the QFI value.

   configure mobile-gateway profile qfi-mapping-profile 5qi-as-qfi

2. Provision a PCC rule with the same 5QI and ARP as the session 5QI and ARP.

In addition to applying base 4G and 5G QoS, Nokia’s FWA solution can also apply DSCP marking based on QCI/5QI and ARP values. The FWA-UP remarks the DSCP values as follows:

• In the uplink direction, the FWA-UP marks the DSCP value of the forwarded IPv4 and IPv6 PDU packets. This is useful for QoS treatment based on QCI/5QI in the data network beyond the FWA-UP.
• In the downlink direction, the FWA-UP marks the DSCP value of both the forwarded IPv4 and IPv6 PDU packets and marks the DSCP value of the outer GTP-u header. This is useful to honor 4G/5G QoS properties in the aggregation network between UP and RAN.

As shown in the following figure, in both directions statically preprovisioned QoS treatment is applied based on QCI/5QI and ARP via the DSCP values in Network Elements (NEs) that are typically not 4G or 5G QoS aware.

Do the following to apply DSCP marking on the UP:

1. Use the following command to configure a QCI policy.

   configure mobile-gateway profile policy-options qci-policy

2. Use the following commands to configure per QCI and ARP combination, the DSCP value in the uplink (in) and downlink (out) directions and to disable DSCP preserve.
   Note: The no dscp-preserve command specifies that the MAG-c signals the configured DSCP values to the FWA-UP in PFCP messages. See the MAG-c CLI Reference Guide for more information about this command.

   configure mobile-gateway profile policy-options qci-policy qci 
   configure mobile-gateway profile policy-options qci-policy qci dscp
   configure mobile-gateway profile policy-options qci-policy qci no dscp-preserve

3. Apply the QCI policy in the following context.

   configure mobile-gateway pdn apn qci-policy

The MAG-c tracks and learns the location of an FWA session using procedures such as X2/Xn-based handover, UE-triggered service request, location reporting, and tracking area update. For 4G, the MAG-c requests the MME to report location if the MME signals the "Change Reporting Support Indication" flag and if the BNG charging profile is enabled to track the location. For 5G the MAG-c does not subscribe to specific location updates and only learns location changes as part of other procedures.

When RADIUS location tracking is enabled, an Interim Update message is triggered whenever the user location changes. The user location is sent in the 3GPP-User-Location-Info attribute.

Use the following commands to configure location tracking for RADIUS:

• Use the following command to enable location tracking.

  configure mobile-gateway profile charging bng-charging radius session update-triggers user-location-change

• Use the following command to send the user location in the 3GPP-User-Location-Info attribute.

  configure mobile-gateway profile charging bng-charging radius session include-attribute user-location-info

To enable 5G FWA sessions, do the following:

1. Use the following command to configure an SMF PDUSession service server instance on the MAG-c, to handle service calls from the AMF to the SMF.

   configure mobile-gateway pdn sba-server-services nsmf-pdusession

2. Configure the service instance with the following required elements:
   • an interface on which the MAG-c listens for incoming connections from the AMF
   • the N3 interface realm that is sent to the FWA UP as the realm (service) where N3 GTP-u tunnels are terminated
   Note: When 4G and 5G interworking is required, configure the interface-realm option for the S11 interface using the following command.

   configure mobile-gateway pdn s11 interface gtp-c

   See 4G and 5G NSA option 3 sessions for more information about configuring the S11 interface.

3. Optionally provision the following for the server instance:

   • An HTTP2 profile to influence generic HTTP/2 and SBI parameters; see HTTP/2, OpenAPI, and Python for more details.
   • An API prefix to be part of the service URI; see URI construction for more information about how URIs are constructed.
   • An FQDN to identify the service by other NF peers. For example, the AMF can use this when constructing URIs or when discovering the SMF using DNS.
   • Multiple attributes to send to the NRF when registering the service:
     • NF domains lists using the following command.

       configure mobile-gateway pdn sba-server-services nsmf-pdusession allowed-nf-domains-list

     • PLMNS using the following command.

       configure mobile-gateway pdn sba-server-services nsmf-pdusession allowed-plmns

     • slices using the following command.

       configure mobile-gateway pdn sba-server-services nsmf-pdusession allowed-slices

       See NF registration for more information about how services and related attributes register with the NRF.

4. Use the following command option to enable the service instance.

   configure mobile-gateway pdn sba-service-realm server-service service-instance

In addition to the SMF server instance, you must configure the AMF communication client service. This service generates service calls from the SMF to the AMF, to forward N1 or N2 messages to the UE or RAN.

To configure the AMF client service, do the following:

1. Use the following command to configure the AMF service.

   configure mobile-gateway pdn sba-client-services amf-client namf-comm

2. Use the following command to configure an interface for the service instance that the MAG-c uses to communicate with the AMF.

   configure mobile-gateway pdn sba-client-services amf-client namf-comm interface

3. Optionally configure the following for the client service instance:
   • An FQDN to identify the service by other NF peers. For example, when generating callback functions the SMF can use the FQDN in the URI, rather than the IP address; see URI construction for more information about how URIs are constructed.
   • An NF ID list to specify which NF instances can be used for the AMF service; see Enabling discovery based on a local NF ID list for more information. This command is required if the AMF is not dynamically discovered using NRF.
   • An HTTP2 profile to influence generic HTTP/2 and SBI parameters; see HTTP/2, OpenAPI, and Python for more information.
   • An AMF profile to handle AMF failure handling; see section Failure handling for more information.
   • An N1 profile configured using the following command.

     configure mobile-gateway profile n1-profile

     Use the following commands to configure the N1 profile to influence N1 signaling:

     • The N1 profile timer governs retransmit behavior for an N1 PDU SESSION MODIFICATION COMMAND message.

       configure mobile-gateway profile n1-profile n1-t3591

     • The N2 profile timer specifies retransmit behavior for an N1 PDU SESSION RELEASE COMMAND message.

       configure mobile-gateway profile n1-profile n1-t3592

     • The cause-code commands in the following context specify which error codes are signaled to the UE and AMF for several session removal and rejection cases.

       configure mobile-gateway profile n1-profile

4. This service generates service calls from SMF to AMF, to forward N1 or N2 messages to the UE or RAN. Use the following command option to subsequently enable this service instance.

   configure mobile-gateway pdn sba-service-realm client-service service-instance

In 5G, the MAG-c acting as the SMF directly communicates with the UDM function to retrieve session subscription data, such as subscribed default QoS. The MAG-c subscribes to any subscription data changes to apply these changes.

This differs from 4G where a similar function is provided by the HSS, but the PGW does not retrieve this context directly. In 4G, the MME retrieves the subscription data from HSS and signals this via GTP messages to the PGW.

Typically a UDM (see UDM function configuration) and PCF (see PCF-based policy management) are configured for a 5G session, in addition to the SMF PDUSession service and the AMF client communication service. The following figure shows the basic 5G FWA session setup when all these components are configured.

The following describes the message flow and actions to set up a 5G FWA session:

1. An initial registration sequence is initiated between the UE and the AMF. This procedure is orthogonal to the SMF because it does not involve any session-management functionality. Upon completion of the registration, an FWA UE requests creation of a PDU session to forward traffic. To do this, it generates a PDU Session Establishment Request NAS message and signals this to the AMF. Upon receipt of this message, the AMF may obtain additional subscription parameters from the UDM and determines which SMF should handle the session based on local configuration. For example, a specific FWA slice (S-NSSAI) could be used, with which the SMF registers (see NF registration) and the AMF discovers this SMF by calling the Nnrf_Discovery service that has the S-NSSAI configured in the query parameters. Upon discovering the SMF, the AMF creates a session management resource on the SMF by calling the Nsmf_PDUSession_CreateSMContextRequest service operation. In this it includes the PDU Session Establishment Request NAS message as it is, and any additional metadata it can provide, for example the DNN.

2. Upon receiving the Nsmf_PDUSession_CreateSMContextRequest the MAG-c uses the signaled DNN to look up the configured APN/DNN in the following context.

   configure mobile-gateway pdn apn

   Note: To enable 5G FWA functionality, the APN must be in the enabled state and configured with an FWA node using the following command.

   configure mobile-gateway pdn apn fixed-wireless-access

   If a UDM client service is configured (see UDM function configuration ), a Nudm_SDM_Get Request service call is executed to obtain subscription parameters such as session AMBR, default 5QI, default S-NSSAI, and so on.

   If the UDM is not configured, these parameters must either be provided by the PDU Session Create message, or locally configured on the MAG-c. Subsequently, the authentication flow of the FWA node (configured using the following command) is used to authenticate the session.

   configure mobile-gateway pdn apn authentication-flow

   FWA-specific ADB match criteria or RADIUS include attributes can be used. Match criteria use data from the PDU Session create call and the UDM. For example, if an S-NSSAI is not provided in the create call, but a default S-NSSAI is provided in UDM subscription data, this is matched.

3. After the UDM and authentication flow is completed, the MAG-c answers the call from the AMF Nsmf_PDUSession_CreateSMContext. This creates the session context in the AMF only; it does not yet include an answer to the UE-originated PDU Session Establishment Request message.
4. Optionally, after the UDM and authentication flow completes, the MAG-c can obtain policy data from a PCF. See PCF-based policy management for more information about policy management and the PCF service.
5. When all authentication and policy management is completed, the MAG-c selects an FWA-UP and sets up the corresponding PFCP session that carries the full session data, including all BNG-specific parameters. The RAN (gNodeB) has not yet allocated a downlink GTP-U F-TEID, so the downlink data packet is buffered. For uplink traffic, the FWA-UP allocates an F-TEID and sends it back to the MAG-c. See the 7750 SR and VSR BNG CUPS User Plane Function Guide for information about the BNG CUPS UPF.
6. The MAG-c acknowledges the UE-originated PDU Session Establishment Request message by generating an N1 PDU Session Establishment Accept message. It also generates an N2 SM Information message which is sent to the RAN (gNodeB), including the F-TEID it received from the FWA-UP. Both messages also include any policy QoS rules applicable to either the UE or RAN. It includes these messages in a Namf_Communication MessageTransfer service call toward the AMF. The AMF in turn creates an N2 PDU Session Request call to the RAN to create context on the RAN, including the N2 SM Information and N1 PDU Session Establishment Accept message generated by the SMF. The RAN and UE finalize the radio resources setup. The uplink data can now flow.
7. The RAN acknowledges the session context creation using an N2 PDU Session Response message to the AMF. In this message it also includes an N2 SM Information message with its F-TEID for downlink data, which the AMF forwards to the MAG-c using the smf_PDU_Session_UpdateSMContext service. The MAG-c forwards the F-TEID to the FWA-UP using a PFCP Session Modification Request message. This changes the downlink rules from buffering to forwarding with the provisioned F-TEID. The FWA-UP acknowledges the PFCP message to the MAG-c, which in turn acknowledges the smf_PDU_Session_UpdateSMContext call. Downlink traffic is now possible.
8. If the UDM is enabled, the MAG-c registers itself for subscription updates for this session context using the Nudm_SDM_Subscription service call. Additionally, it also registers itself as the active SMF for this UE session using the Nudm_UECM_Registration service call.
9. The data layer connectivity is now fully ready, although it is possible that not all IP addresses allocated to the RG are signaled to the UE. The addresses are signaled over the data connection using the DHCP, ICMPv6, and DHCPv6 protocols as needed. See Address signaling methods and deferred allocation for more information.

In 5G networks, a slice identifies an end-to-end logical network, from the UE to the network, on top of the shared physical infrastructure. The user can pick the physical or virtual components on a per-slice basis. This is a very flexible and powerful concept that can be used for many purposes. For example, FWA can be expressed as a single slice with dedicated FWA SMF and FWA UPF components.

MAG-c acting as the SMF is not involved in the slice-selection function itself. However, when selecting a peering NF instance via NRF, the MAG-c can use S-NSSAI as a query parameter to discover only peers associated with the selected slice. The MAG-c also passes the S-NSSAI to any peers, such as the UDM, PCF, or CHF, which require the MAG-c S-NSSAI to identify the services to offer. Finally, the SST and SD part of the S-NSSAI can be used as a match parameter in the authentication database, which allows the S-NSSAI to influence a wide set of parameters on itself.

Interworking of 5G-4G allows seamless mobility between a 5G and a 4G radio coverage area.

In 5G Service Based Architecture (SBA), the model D method supports indirect communication via a service communication proxy (SCP) that mediates between the NF consumer and producer.

Load control is an overload prevention concept. It enables the originator node (for example, SGW-C + PGW-C or SMF) to send its load information to a consumer node (for example, the MME or the AMF). During the session setup, the consumer node uses the load information it receives from multiple originator nodes to select nodes for load balancing the session across all the nodes, according to their effective loads.

Use the following command to enable GTP-C load control.

configure mobile-gateway pdn load-control enable-gtp-load-control

To support load control with 4G or 5G NSA, the originating node sends the Load Control Information (LCI) IE in the GTP-C messages to the consumer node. The MAG-c can send GTP-C load control information in every nth GTP-C message, or on every x percentage load change.

The load metric reported in the LCI represents the current load level of the MAG-c node as a percentage, within the range of 0 to 100, where 0 means no load and 100 means the maximum or 100% load (no further load is desirable).

Use the following command to configure the GTP-C load control settings based on the percentage of load change.

configure mobile-gateway pdn load-control load-change-trigger

Use the following command to configure the GTP-C load control settings to send the load control information in every nth message.

configure mobile-gateway pdn load-control nth-message 

To support indirect load reporting to the consumer nodes, the producer node updates the NRF with its local load information. The load reported by the producer (originating) node to the NRF is made available to the consumer node during node selection. The consumer node can load balance the signaling load by selecting a producer node that has a lower load compared to a similar node with a higher load. This method is used for load control for SBI interfaces only.

Use the following command to enable SBI load reporting.

configure mobile-gateway pdn enable-sbi-load-reporting

Overload control is an overload mitigation concept. It enables an originator node (SGW‌-C + PGW‌-C, SMF, MME, or AMF) that is overloaded, or at risk of becoming overloaded, to gracefully reduce the incoming signaling. The originator node is in an overload state when it operates beyond its signaling capacity, resulting in diminished performance and impacting the handling of incoming and outgoing traffic.

configure mobile-gateway pdn overload-control enable-gtp-overload-control

configure mobile-gateway pdn overload-control thresholds minor 85
configure mobile-gateway pdn overload-control thresholds major 90
configure mobile-gateway pdn overload-control thresholds critical 95

configure mobile-gateway pdn overload-control validity-time

configure mobile-gateway overload-control overload-reduction minor 40
configure mobile-gateway overload-control overload-reduction major 70
configure mobile-gateway overload-control overload-reduction critical 85

configure mobile-gateway pdn overload-control local-throttling local-overload-throttling

configure mobile-gateway pdn overload-control local-throttling minor throttling-percent 0
configure mobile-gateway pdn overload-control local-throttling major throttling-percent 50
configure mobile-gateway pdn overload-control local-throttling critical throttling-percent 80

show mobile-gateway pdn load-overload-control summary

The MAG-c supports node-level N11 congestion mitigation based on 3GPP TS29.500, 29.502. SBI congestion mitigation is triggered on a consumer node based on the HTTP status codes the node receives from the originator (producer) node.

When acting as an SMF, the MAG-c as the producer node on an N11 interface supports sending the HTTP 503 code during overload conditions. You can configure the overload threshold for congestion mitigation using CLI commands.

During overload, the PDU Session Establishment Create Request is rejected, and the HTTP 503 error code is generated toward the consumer node. The MAG-c responds to the AMF with an HTTP 503 message, including the error attribute ProblemDetails set to “NF_CONGESTION”. If the sbi-retry-after-timer command is also configured, the value is included in the HTTP 503 response.

When no longer in overload, the MAG-c stops rejecting any new PDU Session Establishment Create Requests.

Use the following command to enable SBI overload control.

configure mobile-gateway pdn overload-control enable-sbi-overload-control

Use the following commands to modify the default values of the SBI overload threshold and retry timer.

configure mobile-gateway pdn overload-control sbi-overload-threshold 
configure mobile-gateway pdn overload-control sbi-retry-after-timer 

Government-authorized personnel, emergency management officials, and other authorized users who provide disaster response and management rely on the ability to communicate during congestion conditions. These subscribers are expected to receive priority treatment, in support of mission critical multimedia communications.

There are two methods to qualify a high-priority session:

• subscription-based WPS

  For subscription-based WPS, the Message-Priority value received in the GTP message header on the S11 interface during the initial session setup for 4G/5G NSA would indicate the session is high priority. In this case, the signaling messages toward other peers (UDM, CHF, and PCF) also carry a high-priority indication in the SBI message headers, so that the signaling messages on the receiving node are processed at high priority as well. High-priority indication over the SBI interface is achieved using the Message-Priority value in the HTTP/2 header.

  The subscription-based priority service can be enabled on the MAG-c by mapping the Message-Priority value received in the GTP signaling message on S11 for 4G/5G NSA to indicate it is a high-priority session.

• invocation-based WPS

  For invocation-based WPS, the authorized ARP value (received from the PCF) maps the session as a high-priority session. The invocation-based priority service is enabled by mapping the authorized ARP value (for example, received from PCF) for 4G/5G NSA or 5G SA to indicate it is a high-priority session.

In both cases, the authorized ARP value determines the final priority level of the session. The priority level based on authorized ARP value overwrites the priority level assigned based on the Message-Priority value received in the initial GTP messages on the S11 interface.

The MAG-c uses a priority-mapping profile configuration to map high-priority sessions based on the Message-Priority value received in the GTP message and on the authorized ARP. The priority level is defined in the priority-mapping profile using a priority value assigned to an authorized ARP value or a GTP Message‑Priority value.

Based on the following priority-mapping profile example configuration, the priority sessions are processed as follows:

• An ARP value of 1 is processed as a high priority session. All other values of ARP are processed at regular priority.
• All Message-Priority values received in GTP message are processed as high-priority sessions.

A:MAG-c>config>mobile>profile# info
----------------------------------------------
            priority-mapping "profile1"
                arp 1
                    priority 2
                exit
                gtp-rx-message-priority profile *
                    priority 2
                exit
            exit
----------------------------------------------

configure mobile-gateway priority-profile
configure mobile-gateway priority-profile priority

A:MAG-c>config>mobile>profile# info
----------------------------------------------
            priority-profile "profile1"
                priority 2
                    egress 
                        gtp-tx-message-priority 0
                        sbi-tx-message-priority 0
             	        gtp-dscp 56
               	      pfcp-dscp 56
               	      pfcp-priority-level urgent  
                    exit
                exit
----------------------------------------------