Patent Publication Number: US-2021168697-A1

Title: User Equipment and Method to Handle Access Barring

Description:
TECHNICAL FIELD 
     Embodiments herein relate to a User Equipment (UE) and a method therein. In some aspects, they relate to handling access barring in a wireless communications network  100 . 
     BACKGROUND 
     In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and/or User Equipments (UE), communicate via a Local Area Network such as a WFi network or a Radio Access Network (RAN) to one or more core networks (CN). The RAN covers a geographical area which is divided into service areas or cell areas, which may also be referred to as a beam or a beam group, with each service area or cell area being served by a radio network node such as a radio access node e.g., a WI-Fi access point or a radio base station (RBS), which in some networks may also be denoted, for example, a NodeB, eNodeB (eNB), or gNB as denoted in 5G. A service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node communicates over an air interface operating on radio frequencies with the wireless device within range of the radio network node. 
     Specifications for the Evolved Packet System (EPS), also called a Fourth Generation (4G) network, have been completed within the 3rd Generation Partnership Project (3GPP) and this work continues in the coming 3GPP releases, for example to specify a Fifth Generation (5G) network also referred to as 5G New Radio (NR). The EPS comprises the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as System Architecture Evolution (SAE) core network. E-UTRAN/LTE is a variant of a 3GPP radio access network wherein the radio network nodes are directly connected to the EPC core network rather than to RNCs used in 3G networks. In general, in E-UTRAN/LTE the functions of a 3G RNC are distributed between the radio network nodes, e.g. eNodeBs in LTE, and the core network. As such, the RAN of an EPS has an essentially “flat” architecture comprising radio network nodes connected directly to one or more core networks, i.e. they are not connected to RNCs. To compensate for that, the E-UTRAN specification defines a direct interface between the radio network nodes, this interface being denoted the X2 interface. 
     Multi-antenna techniques can significantly increase the data rates and reliability of a wireless communication system. The performance is in particular improved if both the transmitter and the receiver are equipped with multiple antennas, which results in a Multiple-Input Multiple-Output (MIMO) communication channel. Such systems and/or related techniques are commonly referred to as MIMO. 
     In addition to faster peak Internet connection speeds, 5G planning aims at higher capacity than current 4G, allowing higher number of mobile broadband users per area unit, and allowing consumption of higher or unlimited data quantities in gigabyte per month and user. This would make it feasible for a large portion of the population to stream high-definition media many hours per day with their mobile devices, when out of reach of Wi-Fi hotspots. 5G research and development also aims at improved support of machine to machine communication, also known as the Internet of things, aiming at lower cost, lower battery consumption and lower latency than 4G equipment. 
     Access Control 
     When performing access to a wireless communication system, a UE must signal to the network that it wants to acquire communication opportunities. There are many schemes for how this may be done. For example, a UE may utilize air-interface resources, e.g., times, frequencies, to send a short message that would indicate to the network that a UE wants to communicate. Further details about a certain communication need may then occur in subsequent communication. 
     The event which triggers a UE to perform a request to access a wireless communication system may for example be a need for an application, such as a software module in the UE, to transmit uplink user data, and/or receive downlink user data. Or, a need to exchange signaling messages with a network node, or alternatively, a combination of both. 
     Consider a simplified wireless network  10  illustrated in  FIG. 1 , with a UE  12 , which communicates with an access node  14 , which in turn is connected to a network node  16 . 
     For wireless communication systems pursuant to 3GPP E-UTRAN/LTE standard specifications, the access node  14  corresponds typically to an Evolved NodeB (eNB) and the network node  16  corresponds typically to either a Mobility Management Entity (MME) and/or a Serving Gateway (SGW). 
     In 3GPP LTE, a request for communication is performed by initiating a random access procedure followed by a Radio Resource Control (RRC) Connection Establishment procedure. Please see  FIG. 2  depicting a Random access and RRC connection establishment in 3GPP LTE. 
     This sequence starts with a transmission of a Random Access Preamble  201 , also known as “msg1”, on specifically allocated channels or resources. This random access preamble is, when received by a base station or eNB, followed by a random access response  202 , also known as “msg2” that includes an allocation of resources for continued signaling, in this case the RRC Connection Request  203 , also known as “msg3” which is the first message in the RRC Connection Establishment procedure. 
     As is easily realized, an access attempt will cost air interface resources. Both the initial message  201 , Preamble as well as resources for further signaling  202 - 205  will add to the wireless network load, simply to configure and setup communication resources for subsequent data transfer. It should be noted that even further communication is needed with network entities before any communication can take place, these are omitted from  FIG. 2 . 
     Under certain circumstances, it is desirable to prevent UE&#39;s from making these access attempts. For example, in case of an overload situation like radio resource congestion or shortage of processing capabilities, a network may wish to reduce overload by denying access to a cell. The network may also need to prioritize between specific users, such as UEs, and/or services during overload situations. For example, to give priority to emergency calls compared to ordinary calls. 
     To this end, the network may employ what is in 3GPP referred to as access control. Access Class Barring (ACB) is an example of one such control. In short, access barring is about preventing or making it less likely that a UE will attempt to send an access request, e.g., to initiate the sequence above by sending a preamble,  201 . In this way, the total load in the system can be controlled. The network may for example divide UE&#39;s or different reasons for why a UE want access into different classes, or categories and dependent on this, the network can differentiate and make it less likely that, e.g., certain UE&#39;s and/or certain events trigger access requests. For example, a given UE may belong to a certain access class and the network may communicate, via broadcasted system information, that certain classes at certain instances are barred, i.e., not allowed to make access, or allowed to make access with a lower probability if not barred altogether. When a UE receives this broadcasted system information, if it belongs to a barred access class, it may result in that a UE will not send an access request. There are multiple variants of access barring mechanisms specified for LTE. 
     1. Access Class Barring (ACB) as per 3GPP Release 8: In this mechanism, it is possible to bar all access requests from a UE. Normal UEs in Access Class (AC) range 0-9 are barred with a probability factor, also referred to as barring factor, and a timer, also referred to as barring duration, whereas specific classes can be controlled separately. Beside the normal classes 0-9, additional classes have been specified to control the access to other type of users, e.g. emergency services, public utilities, security services, etc. 
     2. Service Specific Access Control (SSAC): The SSAC mechanism allows a network to prohibit Multi-Media Telephony (MMTel)-voice and MMTel-video accesses from a UE. The network broadcasts barring parameters, parameters similar to ACB, and a barring algorithm that is similar to ACB, barring factor and random timer. An actual decision if access is allowed is done in the IP Multi-Media Subsystem (IMS) layer of a UE. 
     3. Access control for Circuit-Switched FallBack (CSFB): The CSFB mechanism allows a network to prohibit CSFB users. A barring algorithm used in this case is similar to ACB. 
     4. Extended Access Barring (EAB): The EAB mechanism allows a network to prohibit low priority UEs. Barring is based on a bitmap in which each access class (AC 0-9) can be either barred or allowed. 
     5. Access class barring bypass: The ACB mechanism allows omitting access class barring for IMS voice and video users. 
     6. Application specific Congestion control for Data Communication (ACDC) barring: ACDC allows barring of traffic from/to certain application. In this solution, applications are categorized based on global application identification (ID) (in Android or iOS). The network broadcasts barring parameters (barring factor and timer) for each category.) 
     All the variants of access control operate for UEs in idle mode prior to random access and RRC connection establishment. SSAC additionally can be applied also for connected mode UEs, i.e. UEs in RRC_CONNECTED state in LTE. 
     In LTE, before a UE performs access towards an access node, it needs to read certain system information that is usually broadcast by the network node  110 . The system information describes how access should be performed to initiate communication between the UE  102  and the access node  104 . Part of this system information may be information related to access barring. This barring information is usually broadcasted in the access network  10  and there may be different barring information in different cells or areas. Usually, one access node  14  will transmit its own barring information. The barring information may be arranged in a way such that it includes a set of access categories [1 . . . m] and for each category, information elements containing a barring factor and a barring time, for example as specified in 3GPP TS 36.331 v.14.1.0, 2016-12, see text below, illustrating an example of ACDC access barring information for LTE. 
     
       
         
           
               
             
               
                   
               
             
            
               
                 BarringPerACDC-Category-r13 ::= SEQUENCE { 
               
            
           
           
               
               
               
            
               
                   
                 acdc-Category-r13 
                 INTEGER (1..maxACDC-Cat-r13), 
               
            
           
           
               
               
               
            
               
                   
                 acdc-BarringConfig-r13 
                 SEQUENCE { 
               
            
           
           
               
               
               
            
               
                   
                 ac-BarringFactor-r13 
                 ENUMERATED { 
               
            
           
           
               
               
            
               
                   
                 p00, p05, p10, p15, p20, p25, p30, p40, 
               
               
                   
                 p50, p60, p70, p75, p80, p85, p90, p95}, 
               
            
           
           
               
               
               
            
               
                   
                 ac-BarringTime-r13 
                 ENUMERATED {s4, s8, s16, s32, s64, s128, 
               
            
           
           
               
            
               
                 s256, s512} 
               
            
           
           
               
               
               
            
               
                   
                 } 
                 OPTIONAL -- Need OP 
               
            
           
           
               
            
               
                 } 
               
               
                   
               
            
           
         
       
     
     This barring information per access category will be used by the UE attempting access and it is a way for the access node to limit and prioritize certain accesses over other. 
     3GPP System Architecture 
       FIG. 3  depicts Planes in a communications system. A communication system, such as a 3GPP system, is normally functionally divided vertically into User Plane  401 , Control Plane  402  and Management Plane  403  as illustrated in  FIG. 3 . This division allows independent scalability, evolution and flexible deployments. The user plane  401 , which carries the user data traffic, contains functions and protocols related to user data transfer such as segmentation, reassembly, retransmission, multiplexing, ciphering and so forth. In the control plane  402 , which carries signalling traffic, we find the protocols and functions needed to setup, release, control and configure the user plane. The control plane  402  also contains functions and protocols related to for example UE mobility, UE authentication, control of user sessions and bearers, also known as service data flows or QoS flows. In the Management plane  403 , which carries administrative traffic, there is found for example operations and maintenance (O&amp;M) and provisioning functions. There exists normally no distinct division between the control plane  402  and that management plane  403  but typically the control plane  402  operates in a faster time scale, e.g. seconds, than the management plane  403 , e.g. hours. Then the User Plane  401  operates typically in the fastest time scale, e.g. in milliseconds. 
       FIG. 4  depicts domains and strata in a 3GPP system and illustrates another division of the 3GPP system, into domains and strata. A stratum is a grouping of protocols related to one aspect of the services provided by one or several domains. There are a number of domains, most important are the UE  12 , the Access Network (AN)  502  and the Core Network (CN)  503 . It needs to be understood that typically the UE  12 , AN  502  and CN  503  all contains User Plane  401 , Control Plane  402  and Management Plane  403  functions. 
     The UE  12  is a device allowing a user access to network services. It is typically a wireless terminal, such as a smartphone, equipped with a User Services Identity Module (USIM). The latter contains the credentials in order to unambiguously and securely identify itself. The functions of the USIM may be embedded in a stand-alone smart card, but may also be realized, e.g., as software in a software module. 
     The AN  502 , also known as the RAN, comprises access nodes, or base stations, also known as eNBs or gNBs, which control the radio resources of the access network and provides the UE  12  with a mechanism to access the core network  503 . The Access Network  502  is dependent of the radio access technology used in the wireless interface between the UE  12  and Access Network  502 . Thus, there are different flavors of access networks  502  for different radio access technologies, such as E-UTRAN supporting LTE or E-UTRA radio access technology and NG-RAN supporting New Radio (or 5G) type of radio access technology. 
     The CN  503  comprises network nodes which provide support for the network features and telecommunication services, such as the management of user location information, control of network features and services, the switching and transmission of signaling and user data. The core network  503  also provides an interface towards the External Network  507 . There are different types of core networks  503 , for different 3GPP system generations. For example, in 4G, also known as the Evolved Packet System (EPS), there is the Evolved Packet Core (EPC). Developed as part of the 5G System (5GS) there is the 5G Core (5GC). 
     Moreover, the core network  503  is access-agnostic and the interface between the access network  502  and core network  503  enables integration of different 3GPP and non-3GPP access types. Agnostic when used refers to something that is generalized so that it is interoperable among various systems. For example, an Access Network  502 , also known as E-UTRAN, supporting LTE or E-UTRA radio access technology as well as an access network, also known as NG-RAN, supporting New Radio type of radio access technology may both be connected to a 5G type of core network  503 , also known as 5G Core (5GC). 
     The External Network  507  represents here a network outside of the 3GPP domain, such as the public Internet. 
     As seen in  FIG. 4 , 3GPP system is also horizontally divided into the access Stratum (AS)  504  and Non-Access Stratum (NAS)  505  reflecting a protocol layering hierarchy. In the AS  504  there are functions which are related to the wireless portion of the system such as transport of data over the wireless connection and managing radio resources. The AS  504  typically comprises functions in the access network  502  and the dialogue, using corresponding protocols, between the UE  12  and the access network  502 . In the NAS  505 , which may be seen as higher in the protocol layering hierarchy than AS  504 , there are the functions which are not directly dependent on the radio access technology and typically the functions in the core network and the dialogue, using corresponding protocols, between the UE  12  and the core network  503 . 
     In  FIG. 4 , also the Application  506  is illustrated above NAS  505 . The Application  506  may comprise parts in the UE  12 , the core network  503  and the External network  507 . 
       FIG. 5  depicts protocol layers in user plane and control plane of a 3GPP system. The control plane  402  and User Plane  401  of the Access Stratum  504  and Non-Access Stratum  505  are further divided into protocol layers. As illustrated in  FIG. 5 , in the AS  504 , there is one protocol layer in the control plane  402 , namely the Radio Resource Control (RRC) layer  601 . As the RRC layer  601  is part of the Access Stratum  504 , it is dependent on the type of radio access technology used between the UE  12  and Access Network  502 . Thus, there are different flavors of RRC  601  for different radio access technologies, e.g. one type of RRC layer  601  for each of UTRA, E-UTRA and New Radio type of radio access technologies. 
     Further, in the Access Stratum  504  there are also a number of protocol layers in the user plane  401 , such as the Physical (PHY) layer  611 , Medium Access Control (MAC) layer  612 , Radio Link Control (RLC) layer  613  and Packet Data Convergence Control (PDCP) layer  614 . 
     For New Radio, we also expect a new layer in the AS  504 , above PDCP  614 , here denoted New Layer (NL)  615 . 
     All protocol layers, both in the User Plane  401  and Control Plane  402  of the Access Stratum  504  are terminated in the Access Network  502  in the network side, such as the eNB or the gNB. 
     In the NAS  505 , there are multiple protocol layers in the control plane  402 . In Evolved Packet System (EPS), also known as 4G or LTE, these layers are known as EPS Mobility Management (EMM)  603  and EPS Session Management (ESM)  604 . In the 5G system, we will find protocol layers performing the equivalent functions of EMM  603  and ESM  604 , such as the Connection Management (CM)  605 . 
     Further, in the NAS  505 , there are multiple protocol layers in the user plane  401 , such as the Internet Protocol (IP)  616 . 
     The Application  506  resides above the NAS  505 , and interacts with the user plane  401  and in some cases also the control plane  402 . 
     UE States and State Transitions 
     In the 3GPP system, for each protocol layer there is a state machine, reflecting the UE states of the particular protocol layer. In the state machine of the RRC layer  601  for NR radio access technology, according to 3GPP TS 38.804 v14.0.0 (2017-03), three states are specified as illustrated in  FIG. 6 : RRC_IDLE  701 , RRC_INACTIVE  702  and RRC_CONNECTED  703 .  FIG. 6  depicts RRC states for NR. 
     The RRC states reflect the UE&#39;s activity level where RRC_IDLE  701  is typically used when the UE has no ongoing data traffic, thus no activity, and RRC_CONNECTED  703  when the UE needs to send and/or receive data. RRC_INACTIVE  702  may be used as an alternative state instead of RRC_IDLE  701  when the UE has no or low activity. 
     The procedure to enter RRC_CONNECTED  703  from RRC_IDLE  701  is known as the “RRC connection establishment” procedure. Before the RRC connection establishment the UE will be subject to Access control, including an access barring check as described above. 
     A UE in RRC_CONNECTED  703  will typically after a while, typically by order of a network node, such as the gNB, transit to RRC_INACTIVE  702 , due to inactivity, using what is known as the “RRC Inactivation” procedure. Then, after even longer period of inactivity it will again enter RRC_IDLE  701  using e.g. the RRC Connection Release procedure. A UE in RRC_INACTIVE  702  needs to again enter RRC_CONNECTED  703  in order to transmit or receive data. Alternatively, the UE may remain in Inactive for as long as it remains in a certain network area, or it may be paged by the network to transition from RRC_INACTIVE  702  to RRC_IDLE  701 . 
     The procedure for entering RRC_CONNECTED  703  from RRC_INACTIVE  702  is sometimes referred to as an “RRC Resume” or “Activation” procedure. The RRC Resume procedure is currently being standardized and details are yet to be set, but it is expected to require much less signaling than the RRC connection establishment procedure, since e.g. processing resources, transport resources and security association in the network are preserved in RRC_INACTIVE  702  and thus there is typically no need to establish those in the RRC Resume procedure. Therefore the latency before user data can be exchanged between the UE and the network is typically much shorter for a UE in RRC_INACTIVE  702  than for a UE in RRC_IDLE  701 . On the other hand, a UE in RRC_INACTIVE  702  consumes a little more power as well as resources, e.g. memory, than a UE in RRC_IDLE  701 . 
     For LTE, a similar RRC state machine is specified and the functionality similar to the NR RRC_INACTIVE state as well as an RRC Resume procedure already exists. 
     Unified Access Control in 3GPP 
     An ongoing evolution of the access control mechanisms, in particular for 5th generation cellular standards according to 3GPP, is to gather the existing access control mechanisms into one single mechanism that can be configurable and adaptable to various network operator preferences. It has thus been agreed that 5G will include a single access control framework, what is known as Unified access control. 
     Unified access control will apply to UEs accessing 5G Core via NR or E-UTRA/LTE. Moreover, Unified access control is applied in all UE states, whereas for LTE, with one exception, SSAC, the access control mechanisms only apply for idle mode UEs. 
     Unified access control is currently being specified in 3GPP TS 22.261 referring to 5G service requirements, 3GPP TR 24.890 referring to 5G system core network CT1 aspects, 3GPP TS 36.300 referring to RAN stage 2. CT1 is a Working Group responsible for the 3GPP specifications that define the User Equipment—Core network Layer three (L3) radio protocols and Core network side of the Iu reference point. 
     According to the solutions being discussed in 3GPP, the access node, e.g. gNB or eNB, indicates barring condition for each cell using access barring parameters to UEs, by system information broadcast in the RRC layer within the Access Stratum (AS). This barring condition makes it able to prevent UEs from accessing the network using relevant barring parameters that vary depending on Access Identity and Access Category. 
     Further, in the UE, there is a process which detects what is known as “access attempts” defined in 3GPP TS 22.261. An access attempt is an event which triggers the UE to request access the network, such as to setup an RRC connection in RRC_IDLE state, or a new session request in RRC_CONNECTED state, such as a new PDU session or an MMTEL Voice call. For each detected access attempt one or more Access Identities and only one Access Category are selected. 
     Access Identities are configured at the UE and are typically used for “special” UEs, such as UEs for mission-critical services or for operator use. In TS 22.261, the access identities are being specified as illustrated in Table 1 below. 
     
       
         
           
               
               
             
               
                   
               
               
                 Access Identity 
                   
               
               
                 number 
                 UE configuration 
               
               
                   
               
             
            
               
                 0 
                 UE is not configured with any parameters from this table 
               
               
                  1 (NOTE 1) 
                 UE is configured for Multimedia Priority Service (MPS). 
               
               
                  2 (NOTE 2) 
                 UE is configured for Mission Critical Service (MCS). 
               
               
                 3-10 
                 Reserved for future use 
               
               
                 11 (NOTE 3) 
                 Access Class 11 is configured in the UE. 
               
               
                 12 (NOTE 3) 
                 Access Class 12 is configured in the UE. 
               
               
                 13 (NOTE 3) 
                 Access Class 13 is configured in the UE. 
               
               
                 14 (NOTE 3) 
                 Access Class 14 is configured in the UE. 
               
               
                 15 (NOTE 3) 
                 Access Class 15 is configured in the UE. 
               
               
                   
               
               
                 (NOTE 1): 
               
               
                 Access Identity 1 is used to provide overrides according to the subscription information in UEs configured for MPS. The subscription information defines whether an overide applies to UEs within one of the following categories: 
               
               
                 a) UEs that are configured for MPS; 
               
               
                 b) UEs that are configured for MPS and are in the PLMN listed as most preferred PLMN of the country where the UE is roaming in the operator-defined PLMN selector list or in their HPLMN or in a PLMN that is equivalent to their HPLMN; 
               
               
                 c) UEs that are configured for MPS and are in their HPLMN or in a PLMN that is equivalent to it. 
               
               
                 (NOTE 2): 
               
               
                 Access Identity 2 is used to provide overrides according to the subscription information in UEs configured for MCS. The subscription information defines whether an overide applies to UEs within one of the following categories: 
               
               
                 a) UEs that are configured for MCS; 
               
               
                 b) UEs that are configured for MCS and are the PLMN listed as most preferred PLMN of the country where the UE is roaming in the operator-defined PLMN selector list or in their HPLMN or in a PLMN that is equivalent to their HPLMN; 
               
               
                 c) UEs that are configured for MCS and are in their HPLMN or in a PLMN that is equivalent to it 
               
               
                 (NOTE 3): 
               
               
                 Access Identities 11 and 15 are valid in Home PLMN only if the EHPLMN list is not present or in any EHPLMN. Access Identities 12, 13 and 14 are valid in Home PLMN and visited PLMNs of home country only. For this purpose the home country is defined as the country of the MCC part of the IMSI. 
               
            
           
         
       
     
     Access Categories are defined by the combination of conditions related to UE and the type of access attempt. In TS 22.261, the access categories are being specified as illustrated in Table 2 below: 
     
       
         
           
               
               
               
             
               
                   
               
               
                 Access Category 
                   
                   
               
               
                 number 
                 Conditions related to UE 
                 Type of access attempt 
               
               
                   
               
             
            
               
                 0 
                 All 
                 MO signalling resulting from 
               
               
                   
                   
                 paging 
               
               
                 1 (NOTE 1) 
                 UE is configured for delay tolerant service and 
                 All except for Emergency 
               
               
                   
                 subject to access control for Access Category 1, 
               
               
                   
                 which is judged based on relation of UE&#39;s HPLMN 
               
               
                   
                 and the selected PLMN. 
               
               
                 2 
                 All 
                 Emergency 
               
               
                 3 
                 All except for the conditions in Access Category 1. 
                 MO signalling resulting from 
               
               
                   
                   
                 other than paging 
               
               
                 4 
                 All except for the conditions in Access Category 1. 
                 MMTEL voice 
               
               
                 5 
                 All except for the conditions in Access Category 1. 
                 MMTEL video 
               
               
                 6 
                 All except for the conditions in Access Category 1. 
                 SMS 
               
               
                 7 
                 All except for the conditions in Access Category 1. 
                 MO data that do not belong to 
               
               
                   
                   
                 any other Access Categories 
               
               
                 3-31 
                   
                 Reserved standardized Access 
               
               
                   
                   
                 Categories 
               
               
                 32-63 (NOTE 2) 
                 All 
                 Based on operator classification 
               
               
                   
               
               
                 (NOTE 1): 
               
               
                 The barring parameter for Access Category 1 is accompanied with information that define whether Access Category applies to UEs within one of the following categories: 
               
               
                 a) UEs that are configured for delay tolerant service; 
               
               
                 b) UEs that are configured for delay tolerant service and are neither in their HPLMN nor in a PLMN that is equivalent to it; 
               
               
                 c) UEs that are configured for delay tolerant service and are neither in the PLMN listed as most preferred PLMN of the country where the UE is roaming in the operator-defined PLMN selector list on the SIM/USIM, nor in their HPLMN nor in a PLMN that is equivalent to their HPLMN. 
               
               
                 (NOTE 2): 
               
               
                 When there are an Access Category based on operator classification and a standardized Access Category to both of which an access attempt can be categorized, and the standardized Access Category is neither 0 nor 2, the UE applies the Access Category based on operator classification. When there are an Access Category based on operator classification and a standardized Access Category to both of which an access attempt can be categorized, and the standardized Access Category is 0 or 2, the UE applies the standardized Access Category. 
               
            
           
         
       
     
     As illustrated in Table 2 there are up to 32 standardized access categories (0-8, 9-31), and up to 32 operator-defined access categories (32-63). How to select the standardized access categories are specified as rules in the standard. On the other hand, the rules for how to select the operator-defined access categories are configured by the network. Each of these configured rules will be used as one criterion for selecting a particular operator-defined access category. An example of a criterion is that an access attempt associated with a PDU session for a certain value of Data Network Node (DNN) is mapped to a certain operator-defined access category. Each rule is associated with precedence, used to prioritize in which order the UE evaluates the rules. 
     This means that when selecting the appropriate access category for a given access attempt, the UE selects either a standardized access category or an operator-defined access category, in a deterministic way based on specified and configurable rules. 
     Definition of the access attempts, for each access category, is now being done by 3GPP working groups, mainly CT1 and RAN2. It is understood that access attempts may be detected and identified in several layers in the UE, including 5G Session Management (5GSM), 5G Mobility Management (5GMM), SMS over Internet Protocol (SMSolP), Multimedia Telephony (MMTEL) and Radio Resource Control (RRC). But “double barring” should be avoided and therefore a given access attempt should only detected at one place in the protocol stack, and only once. 
     Typically, the layer which detects the access attempt performs the mapping to access category, triggers access barring check and performs enforcement of blocking the attempt if not authorized. 
     The overall procedure for unified access control is illustrated in  FIG. 7 , referring also to  FIG. 1 . 
     In a first step  1001 , a network node optionally provides rules for the operator-specific access categories. This information is illustrated as originating from the network node  16  but may very well also originate from other network nodes and be transmitted to the UE  12  via network node  16  or possibly via another node, e.g. an operator&#39;s policy functionality configuring the UE  12  via a Wireless Local Area Network (WLAN) access network. If the network includes a higher-level controller or policy functionality it may originate from another node hosting such controller or policy functionality. The higher layer rules may be signalled to the UE  12  via Non-Access-Stratum (NAS) signalling, or it may be signalled using other protocols. For example, the UE  12  may include an entity that may be configured with and host access category rules signalled using an OMA-DM device management protocol. 
     Included in the rules from the network node  16 , may be information related to for example, how a UE should select access category if the access is triggered by a certain service. Examples of such services may be for example an emergency service or an MMTel Service. Further, the rules may include information related to how a UE  12  should select access category if an access is triggered by a certain application, such as, e.g., a certain game or a certain social media application. Rules may also include information related to access to various slices. For example, a small device-UE  12 , may want to access, e.g., an Internet of Things (IoT)-optimized slice. Further, it is not uncommon that radio networks are shared between different operators or that one and the same operator is using different Public Land Mobile Network (PLMN) codes. There may be different rules for selecting access category dependent on if access is to occur for different PLMN&#39;s. 
     It should be noted that step  1001  may also include signalling from the access node  14 , in particular when it comes to access category selection for accesses that are triggered by, e.g., signalling with the access node. 
     When an event occurs triggering a need for the UE  12  to request an access to the network, such as a need to transmit uplink data when the UE  12  is in idle mode, or to setup an MMTel Voice call when the UE  120  is in RRC_CONENCTED state, the UE  12  first detects whether this event is an access attempt in step  1002 . An access attempt would always undergo access barring check before it is allowed. Some events are not classified and detected as access attempts. For example, when uplink data is to be sent for an existing PDU session in RRC_CONNECTED state. 
     If the event was classified and detected as an access attempt, the UE  12  determines the access category in step  1003 , based on the standardized rules as well as any configured rules obtained in step  1001 . 
     After determining the access category for this particular access attempt, the UE  120  then reads access barring information typically part of the broadcasted system information in step  1004 . Typically the UE  12  is required to maintain the latest version of the broadcasted system information which implies that the UE  120  in many cases does not actually have to re-read the system information and instead can use cached system information. 
     The UE  12  then performs an access barring check in step  1005 , using the determined access category and the access barring information as input. 
     If the outcome of barring check is “authorized” the UE  12  will continue and perform the access in step  1006 , resulting typically in an uplink signalling message such as an RRC connection request or a NAS message such as a PDU Session Request, depending on the UE state and the type of access attempt. 
     On the other hand, if the outcome of barring check is “not authorized” the UE  12  will not perform an access and instead wait for a period, such as by starting a timer with a value indicated in the access barring information. 
     The development of a unified access control mechanism for access barring is currently ongoing. Access attempts are being defined in 3GPP, in particular in the CT1 and RAN2 groups, and being specified in 3GPP TS 24.501 and TS 38.331. 
     The access control and in particular the barring mechanisms are used to prevent UE&#39;s from sending an access request. There are also other mechanisms available for controlling the load in the network. For example, in situations when access barring allows an access attempt and a UE is allowed to send a Preamble  201  and an RRC Connection Request,  203  or any equivalent message, also known as “msg3” the network may anyway respond with an RRC Connection Reject message. The reasons for this reject message may for example be, e.g., an overload situation that is not yet reflected on in the parameters governing the access barring. It may also be other reasons. 
     SUMMARY 
     As a part of developing embodiments herein a problem was identified by the inventors and will first be discussed. 
     In the recent developments of unified access control in 3GPP, access attempts are being specified. One particular problem is the barring of uplink signaling messages to be sent by the UE. 
     For example, TS 22.261 defines access category 3 to be used for “MO Signalling” types of access attempts. One example of an “Mobile Originated (MO) Signalling” type of access attempt would be initiation of a 5GMM Registration Procedure. Another example would be initiation of a RAN update procedure. Yet another example would be a Measurement Report message. 
     In case of the access attempt not being authorized, as part of the barring check for the access category used by the particular access attempt, the UE will block this access attempt. This is true also for access attempts of type “Mobile Originated (MO) signaling”, i.e. access category 3. A problem with blocking these attempts is that these messages are important for the system itself, and not triggered by a human or an end-user operated application. For example, if the UE cannot initiate a 5G MM registration procedure such as a Tracking Area Update procedure when it shall, this will cause a conflict with existing procedure specifications, e.g. UE becomes unreachable or potentially implicitly detached from the system. 
     Therefore, typically those “error cases” would need to be specified, i.e. what the UE need to do when an uplink signaling message cannot be transmitted, due to access barring. A method typically used, is that the UE enters idle mode. A main drawback is that since the access barring check is based on probability, i.e. when barring is applied for an access category it means e.g. 50% probability for barring. The network cannot know if a particular UE is barred in this example. If a UE goes to idle, without having the possibility to inform the network due to barring, the UE and the network do have an inconsistency, or at least an uncertainty from network side, about the UE state. Also, it may be beneficial if the network has a possibility to control the UE behavior, since different UE behavior on access barring may be desirable depending on scenario and/or type of network overload. 
     In recent 3GPP discussions there have also been raised proposals to add a way to efficiently release multiple UEs in a cell, e.g. in case of network overload situations. In case of network overload, to send separate release messages to each individual UE may seem too costly in case of e.g. a processor or a downlink radio resource being overloaded. One proposal to solve this would be to rather use a single paging message or some other type of broadcast or multicast signaling message to order multiple UEs to go to idle mode. The common issue with these proposals is that this opens up the possibility for e.g. Denial of Service (DoS) attacks with a false network, e.g. using a false base station, illegally releasing all UEs within an area covered by this false network. 
     Thus, there is a need for:
         A method to efficiently prohibit UE signaling messages due to access barring.   A method to avoid uncertainty about the UE state in the network.   A method to control the UE behavior from the network in case of uplink signaling messages are barred.   A method for releasing a number of UEs in an efficient way during e.g. overload situations.       

     An object of embodiments herein is therefore to improve the performance of the network such as a wireless communications network. 
     According to an aspect of embodiments herein, the object is achieved by a method performed by a User Equipment, UE, for handling access barring in a wireless communications network. The UE obtains barring instructions from a network node. The UE further performs access barring check. When the outcome of the access barring check is that the UE is not authorized, the UE determines how to proceed based on the barring instructions. 
     According to another aspect of embodiments herein, the object is achieved by User Equipment, UE, for handling access barring in a wireless communications network. The UE is configured to:
         obtain barring instructions, from a network node  110 ,   perform access barring check, and   when the outcome of the access barring check is that the UE  120  is not authorized, determine how to proceed based on the barring instructions.       

     This is an advantage provided by embodiments herein since the network such as the network node  110  may dynamically control how UEs such as the UE  120  behave when barring check results in “not authorized” by providing barring instructions, rather than a fixed behaviour which is stated in specifications . . . . 
    
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         FIG. 1  is a schematic block diagram illustrating prior art. 
         FIG. 2  is a sequence diagram illustrating prior art. 
         FIG. 3  is a schematic block diagram illustrating prior art. 
         FIG. 4  is a schematic block diagram illustrating prior art. 
         FIG. 5  is a schematic block diagram illustrating prior art. 
         FIG. 6  is a schematic block diagram illustrating prior art. 
         FIG. 7  is a sequence diagram illustrating prior art. 
         FIG. 8  is a schematic block diagram illustrating embodiments of a wireless communications network. 
         FIG. 9  is a flowchart depicting embodiments of a method in a UE. 
         FIG. 10  is a flowchart depicting embodiments of a method. 
         FIG. 11  is a flowchart depicting embodiments of a method. 
         FIG. 12  is a schematic block diagram illustrating embodiments of a UE. 
         FIG. 13  schematically illustrates a telecommunication network connected via an intermediate network to a host computer. 
         FIG. 14  is a generalized block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection. 
         FIGS. 15-18  are flowcharts illustrating methods implemented in a communication system including a host computer, a base station and a user equipment. 
     
    
    
     DETAILED DESCRIPTION 
     Embodiments herein relate to wireless communication systems such as cellular networks. A method, user equipment and network nodes for transmitting and receiving messages related to wireless access are disclosed. 
     Examples of embodiments herein relate to wireless communication networks in general.  FIG. 8  is a schematic overview depicting a wireless communications network  100 . The radio communications network  100  comprises one or more RANs and one or more CNs. The radio communications network  100  may use a number of different technologies, such as Long Term Evolution (LTE), LTE-Advanced, 5G, New Radio (NR), be a radio communications network pursuant to 3GPP LTE/EUTRA specifications, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations. Embodiments herein relate to recent technology trends that are of particular interest in a 5G context, however, embodiments are also applicable in further development of the existing wireless communication systems such as e.g. WCDMA and LTE. 
     In the wireless communication network  100 , wireless devices e.g. a UE  120  such as a mobile station, a non-access point (non-AP) STA, a STA, a user equipment and/or a wireless terminals, communicate via one or more Access Networks (AN), e.g. RAN, to one or more core networks (CN). It should be understood by the skilled in the art that “wireless device” is a non-limiting term which means any terminal, wireless communication terminal, user equipment, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, or node e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a small base station communicating within a cell. 
     The radio communications network  100  comprises a network node  110  providing radio coverage over a geographical area, a service area  11 , which may also be referred to as a beam or a beam group of a first radio access technology (RAT), such as 5G, LTE, Wi-Fi or similar. The network node  110  may be a transmission and reception point e.g. an access node such as a radio access node, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), an access controller, a base station, e.g. a radio base station such as a NodeB, an evolved Node B (eNB, eNode B), a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a transmission arrangement of a radio base station, a stand-alone access point or any other network unit capable of communicating with a wireless device within the service area served by the network node  110  depending e.g. on the first radio access technology and terminology used. The network node  110  may be referred to as a serving radio network node and communicates with the UE  120  with Downlink (DL) transmissions to the UE  120  and Uplink (UL) transmissions from the UE  120 . 
     Methods for handling such as e.g. controlling access the wireless communications network  100 , is performed by the UE  120 . As an alternative, a Distributed Node (DN) and functionality, e.g. comprised in a cloud  130  as shown in  FIG. 8  may be used for performing or partly performing the methods. 
     The technology described herein may be used in various wireless systems and is not restricted to 3GPP EUTRA/LTE systems and 3GPP Next Generation systems deploying New Radio, even though such systems will serve as examples. Access control is a mechanism that may be applicable to any system where user, service or other differentiation and load management of access is needed. Other examples may be wireless access pursuant to IEEE 802 standards, such as IEEE 802.11 WLAN standard or the IEEE 802.16 standard, but also 3GPP GSM evolutions. 
     Actions of Some Embodiments Herein 
     Example embodiments of a flowchart illustrating embodiments of a method performed by the UE  120 , e.g. for handling access barring also referred to as access control, in the wireless communications network  100 , is depicted in  FIG. 9  and will shortly be described in the following. The method comprises one or more of the following actions which actions may be taken in any suitable order. 
     In order for the network such as the network node  110  to control access barring it may send barring instructions to the UE  120 . This is different from the ordinary barring configuration as performed in prior art in that the barring instruction includes information related to actions to be performed by the UE  120 . This is different from the rules provided in the operator-defined access categories, which are only used to select access category. This is also different from the access barring information provided in system information, which only provides information used to determine whether access categories are barred or not. Thus in Action  1201 , the UE  120  obtains barring instructions from the network node  110 . The network node  100  may e.g. may be an access node. The barring instructions may in some embodiments be comprised in a message that may need a response from the UE  120 . This is since typically, many signalling procedures are initiated from the network such as the network node  110  with a signalling message sent to the UE  120 , and the UE  120  shall respond by transmitting a message back to the network. 
     In Action  1202  relating to some embodiments, the UE  120  determines based on the barring instruction, whether or not a signalling message is subject to an access barring check. 
     This may e.g. be a signalling message that the UE  120  is about to trigger to be transmitted. This may be determined since depending on network load, some signalling messages should be prioritized. This may e.g. be messages that relates to access attempts which already have undergone an access barring check. One such example is e.g. the UE  120  when it has an ongoing emergency call that has already been authorized and should not be subject to certain subsequent access barring checks. 
     In other words, this may be determined since depending on network load, some signalling messages should be prioritized, e.g. messages that relates to access attempts which already have undergone an access barring check, such as e.g. UE  120  which has an ongoing emergency call that has been authorized will not be subject to certain subsequent access barring checks. 
     In Action  1203  relating to some embodiments, the UE  120  determines access category for the access barring check. This may be determined as the network such as the network node  110  provides access barring information for each access category, and access categories may be barred independently. By selecting access category a differentiation between barring of e.g. signalling messages is provided. 
     In Action  1204 , the UE  120  then performs access barring check. This may e.g. be performed when the signalling message is to be transmitted. The performing of the access barring check based on the determined access category may be performed when the signalling message is an attempt to access the wireless communications network  1000 , e.g. referred to as access attempt. 
     This is to see whether the signalling message is allowed to be sent or not, based on the access barring information provided by the network for the access categories. Thus, in case of e.g. a network overload, a disaster situation, or network maintenance, access categories may be barred, resulting in barring checks to be “not authorized”. 
     In the embodiments where the UE  120  has determined access category for the access barring check, the UE  120  may perform the access barring check based on the determined access category. 
     In Action  1205 , when the outcome of the access barring check is that the UE  120  is not authorized, the UE  120  determines how to proceed based on the barring instructions. 
     The UE  120  not being authorized may comprises that the UE  120  is not authorized to send the signalling message. 
     This is an advantage provided by embodiments herein since the network such as the network node  110  may dynamically control how UEs such as the UE  120  behave when barring check results in “not authorized” by providing barring instructions, rather than a fixed behaviour which is stated in specifications. For example, in case of a severe overload or a disaster, the network such as the network node  110  may instruct the UEs such as the UE  120  to go to idle mode or selecting another system, and in some embodiments without sending messages to each UE individually. These instructions are comprised in the barring instructions that the UE has obtained from the network node  110 . 
     How to proceed based on the barring instructions is in some embodiments determined according to any one out of: 
     When the barring instruction is set to ignore, determining to not transmit the message, 
     when the barring instruction is set to wait and retry, determining to wait during a period according to the barring instruction and then perform a further access barring check, 
     when the barring instruction is set to go to idle, determining to enter idle stat such as e.g. RRC_IDLE state, 
     when the barring instruction is set to fail, determining to fail a signalling procedure, 
     when the barring instruction is set to go to inactive, determining to enter RRC_INACTIVE state, and 
     when the barring instruction is set to reselect another of any one out of: cell, frequency and system, determining to re-select to another of any one out of: cell, frequency and system. 
     Example steps of some embodiments. It should be noted that terms action and step may be used interchangeably. 
     Some example steps performed by the UE  120  are illustrated in  FIG. 13-14  whereof the steps  1101 - 1105  and  1110  are depicted in  FIG. 10 , and steps  1106 - 1109  are depicted in  FIG. 11 . 
     In step  1101 , the UE  120  obtains one or multiple barring instructions, e.g. one barring instruction per access category. 
     In step  1102 , an uplink signaling message is about to be transmitted by the UE  120 . 
     In step  1103 , the UE  120  uses the barring instruction to determine whether this uplink signaling message is identified as an access attempt. If not identified (No), the UE  120  proceeds to transmit the message in step  1110 . 
     If this uplink signaling message is identified as an access attempt (Yes), the UE  120  determines an access category in step  1104 , possibly by using the barring instruction, and performs access barring check in step  1105 . 
     If outcome of the access barring check is “Authorized” the UE  120  proceeds to transmit the message in step  1110 . 
     If outcome of the access barring check is “Not Authorized” the UE  120  in step  1106 , see  FIG. 11 , uses the barring instruction to determine how to proceed. 
     If the barring instruction is set to IGNORE, the UE  120  in step  1107  does not transmit the message. 
     If the barring instruction is set to WAIT WITH RETRY, the UE  120  in step  1108  waits during a period (according to the barring instruction) and goes back to step  1105  and performs another access barring check. 
     If the barring instruction is set to GO TO IDLE, the UE  120  in step  1109  enters RRC_IDLE state. 
     Embodiments herein will now be described more in detail and be exemplified which may be combined in any suitable way with any of the embodiments above. 
     When the UE  120  is about to trigger an uplink signaling message, such as an RRC message, this signaling message transmission may be subject to be identified as an access attempt and therefore a barring check may be performed using the procedure as illustrated in  FIG. 6  for unified access control. In other words, the UE  120  may determine access identities and an access category and may then perform an access barring check using the determined access category and broadcasted system information containing access barring information. 
     Whether a particular uplink signaling message is identified as an access attempt is either stated in a specification or alternatively provided as configuration information to the UE  120 . 
     When outcome of the access barring check is “Authorized”, the UE  120  may transmit the uplink signaling message. 
     On the other hand, if the outcome of the access barring check is “Not authorized”, the UE  120 , will according to embodiments herein, proceed according to a barring instruction provided by the network, e.g. as part of the access barring information in system information. 
     The barring instruction indicates how the UE  120  shall proceed e.g. IGNORE, WAIT with RETRY, GO to IDLE. Each barring instruction may be applicable to signalling protocol, procedure, UE state and/or message. 
     When an uplink signaling message becomes “Not authorized” the UE  120  checks whether a barring instruction is applicable, e.g. for the UE state, protocol, procedure and message. 
     The barring instruction may also indicate whether a barring check should be performed for the specific message and/or which access category to use. 
     If barring check results in “not authorized” the UE  120  acts according to the instruction value. How to deal with retransmissions may also be part of the instruction. Whether to perform barring check on reply may be indicated per message basis. 
     The barring instruction may also be transmitted on per-UE basis, and even as part of e.g. a reconfiguration message, such as RRC Connection Reconfiguration, which includes an instruction on how to deal with the response to this particular reconfiguration message in case barring is applied. For example, this may be part of operator-defined access categories. 
     In an alternative embodiment, an access barring check by the UE  120  is triggered unrelated to any identified new access attempt, e.g. sending a paging message to the UE  120 , e.g. notification that system info has changed, an explicit, dedicated message to the UE  120 , or using a timer, e.g. when this timer expires, access barring check is triggered, and timer is started again when the access barring check outcome is “Authorized”. 
     When the network performs barring of an access category, the result that a signaling message can&#39;t be send due to that being barred forces the UE  120  to go Idle mode. Both UEs in RRC_CONNECTED and RRC_INACTIVE state may be released this way. 
     Embodiments herein may provide at least the following advantages: 
     When the network such as a wireless communications network, applies barring of one or several access category(ies) as indicated in access barring information, multiple UE&#39;s will go to idle mode in some cases when RRC messages are triggered. Also RRC_INACTIVE UEs can be released this way. This is an efficient way of releasing many UEs, with minimal load on network entities, and thus preventing more load on an already overloaded network. 
     Embodiments herein efficiently prohibit transmission of signaling messages from UEs to the network. 
     Embodiments herein may also ensure that any barred signaling messages to cause a deterministic behavior, as it is controlled by the network, and this behavior may be configured depending on the scenario. 
     Alternative Embodiments 
     The trigger of access barring check may be performed also by indicating so in a message sent from the network such as the network node  110  to the UE  120 . For example, by sending a barring indication as part of a paging indication or system information message, all UEs receiving this such as the UE  120 , e.g. all UEs in a certain cell, will trigger an access barring check. For example, the reception of a paging message may trigger the read of system information where the barring indication is included. In another example, the access barring check is triggered in a single UE such as the UE  120 , by a dedicated message sent from the network node  110  to this UE  120 . 
     The barring instruction may indicate whether the UE  120  should perform access barring check for a given signaling message, or all messages, to be transmitted. For example, when the barring instruction is included in a message sent to the UE  120 , which requires a reply back to the network such as the network node  110 , this barring instruction may indicate if barring check should be performed on the reply message by the UE  120 . 
     The barring instruction may indicate which access category to use by the UE  120  when performing access barring check before the UE  120  transmits a signaling message. For example, when the barring instruction is included in a message sent to the UE  120 , which requires a reply back to the network, this barring instruction may indicate which access category to use in the corresponding access barring check. 
     The barring instruction may indicate FAIL, meaning that the procedure which triggered the access attempt and transmission of a signaling message by the UE  120 , shall fail. For example, when the barring instruction is included in a signaling message sent to the UE  120 , which requires a reply back to the network, this barring instruction may indicate that when barring check before sending the reply message results in “Not authorized”, the procedure will fail and the UE  120  shall revert back to be state and/or configuration it had before receiving the signaling message. 
     In one example, the barring instruction is included in a Measurement Configuration message to the UE  120 , and is used by the UE  120  prior to send measurement reports. 
     The barring instruction may also indicate GO TO RRC_INACTIVE, implying that the UE  120  shall enter RRC_INACTIVE state  702 , in case access barring check results in “Not authorized”. 
     The barring instruction may also indicate that the UE shall re-select to another cell, frequency and/or system. 
     In case the barring instruction indicates WAIT WITH RETRY, the network may either indicate the time period for the UE  120  to wait as part of the barring instruction, or, as alternative. 
     The barring instruction may indicate how to deal with retransmissions. For example, it may indicate that if access barring check results in “Not authorized” before sending a signaling message, any retransmissions of this signaling messages should also be barred and not transmitted. 
     The access barring check may be triggered by a timer. The timer may be started by the UE  120  upon reception of a message, a state transition, or transmission of a message. The timer value may be provided in the barring instruction. When the timer expires, the UE  120  performs an access barring check according to the barring instruction. 
     The examples may apply on signaling messages and procedures, such as RRC or NAS messages, transmitted by a UE  120 . The same embodiments may also be applied to other information to be sent by the UE  120 , such as user data, RLC packets, Service Data Adaptation Protocol (SDAP) packets, MAC PDUs, IP packets. For example, the barring instruction may be applied on a MAC resynchronization procedure, such as whether the UE  120  shall perform access barring check before initiating this procedure and/or which access category to use and how to handle the case when access check results in “Not authorized”. 
     The barring instruction may also indicate on which protocol layer and/or protocol entity (identified as protocol instance, bearer and/or logical channel) that is affected by the barring instruction. 
     The method for access barring may be performed in a UE, e.g. characterized by
         obtaining a barring instruction from an access node;   performing access barring check when a signaling message is to be transmitted;   using the barring instruction when responding to the access barring check.       

     Wherein the UE  120  may enter idle mode when the access barring check result is “not authorized”. 
     Wherein the barring instruction may be used to determine if the signaling message is subject to access barring check. 
     Wherein the barring instruction may be used to determine access category for the access barring check; 
     Referring again to in  FIG. 8 , which may illustrate the wireless communications network  100 , for example being pursuant to 3GPP LTE/EUTRA specifications. 
     In the wireless network  100  the UE  120  is illustrated. The UE  120  may request access to and communicate with the network node  110 . The network node  110  is typically part of an access network such as a RAN. The network node  110  may in turn be connected to a network node  106 , typically part of the core network CN, that for example may provide internet access. In LTE, the network node  110  is commonly referred to as eNB, whereas in other standards, it may be referred to as Node B, Base Station, or simply Access Point. In the development of next generation radio access technology for 5G in 3GPP, also known as “New Radio”, the network node  110  is sometimes referred to as “gNB”. It should be noted that the illustration in  FIG. 8  is traditional in the sense that it provides a view of “physical entities”, but to a person skilled in the art, it should be obvious that for example the network node  110  or the network node  106  may be implemented using distributed or centralized processing capacity such as using what is also known as Network Function Virtualization (NFV). Similarly, they may also be implemented in the same physical entity. For purposes of this example, the description will associate the nodes with certain functionality rather than restricting to certain implementations. 
     The network node  110  may communicate user information and signalling to and from the network node to the UE  120 . The Wireless network  100  comprises in this FIG. four “cell” areas and one network node  110 . It should be understood that any access network usually comprises several access nodes and thus several more areas or cells are thus served. 
     The network node  106  may be one of many nodes part of the core network CN. For example it may be a control plane node, e.g., an Mobility Management Entity (MME), in LTE, a Core Access and Mobility Management Function/Session Management Functions (AMF/SMF) according to 3GPP system architecture as specified in e.g. 3GPP TS 23.102 or 3GPP TS 23.501), for communicating control information with the UE  120 , or it may be a user plane node Serving Gateway (SGW), or a User Plane Function (UPF) as specified in e.g. 3GPP TS 23.102 or 3GPP TS 23.501, for communicating user data information to the UE  120 . Further, the network node  130  may be connected with other network nodes and work as a relay for information from these nodes to the UE. Such other network nodes may for example be a Packet Gateway (PGW) or similar. 
     The UE  120  may be in a valid combination of RRC state and NAS layer state. For example, in case of a 5G core network and a new radio type of access network and corresponding access node and network node, the UE may be in RRC_INACTIVE state and CM-CONNECTED state, or alternatively in RRC_CONNECTED and CM-CONNECTED. It should be understood that the UE may also be in RRC_IDLE and CM-IDLE. 
     For the detailed description embodiments herein, it may be assumed that the UE  120  may be connected to the network node  106  part of a 5G core network via a network node  110  part of an NR access network, also known as NG-RAN. It should be understood that a person skilled in the art is able to apply embodiments herein for other systems than 5G/NR, such as an UE connected to a network node  106  in a 5G core network or the EPC, via a network node  110  part of an LTE access network. 
     For the detailed description of embodiments herein, we as the example here also assume the UE  120  is in the RRC_INACTIVE and CM-CONNECTED states. It should be understood that a person skilled in the art will be able to apply embodiments herein also in another combination of UE states, such as RRC_CONNECTED and CM-CONNECTED. 
     To perform the method actions the UE  120  may comprise the arrangement depicted in  FIG. 12 . 
     The UE  120  may comprise an input and output interface  1500  configured to communicate with the network node  110 . The input and output interface may comprise a wireless receiver not shown) and a wireless transmitter not shown). 
     To perform the method actions as mentioned above, the UE  120  may comprise an obtaining unit  1510 , a performing unit  1520 , and a determining unit  1530 , as shown in  FIG. 12 . 
     The embodiments herein may be implemented through a respective processor or one or more processors, such as the processor  1540  of a processing circuitry in UE  120  depicted in  FIG. 12 , together with respective computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the UE  120 . One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the UE  120 . 
     The UE  120  may further comprise a memory  1550  comprising one or more memory units. The memory  1550  comprises instructions executable by the processor in UE  120 . 
     The memory  1550  is arranged to be used to store e.g. barring instructions, information, data, configurations, and applications to perform the methods herein when being executed in the UE  120 . 
     In some embodiments, a respective computer program  1560  comprises instructions, which when executed by the respective at least one processor  1550 , cause the at least one processor  1550  of the UE  120  to perform the actions above. 
     In some embodiments, a respective carrier  1560  comprises the respective computer program  1550 , wherein the carrier  1560  is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium. 
     Those skilled in the art will also appreciate that the units in the UE  120 , described above and below may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in the UE  120 , that when executed by the respective one or more processors such as the processors described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC). 
     Some example Embodiments numbered 1-14 are described below. The following embodiments refer among other things to  FIG. 8 ,  FIG. 9  and  FIG. 12 . 
     Embodiment 1. A method performed by a User Equipment, UE,  120  e.g. for handling access barring, e.g. access control, in a wireless communications network  100 , the method comprising any one or more out of:
         obtaining  1201  barring instructions, e.g. in a message that may need a response, from a network node  110 , e.g. an access node,   performing  1204  access barring check e.g. when a signalling message is to be transmitted,   when the outcome of the access barring check is that the UE  120  is not authorized, determining  1205  how to proceed based on the barring instructions.       

     Embodiment 2. The method according embodiment 1, further comprising:
         determining  1202  whether or not the signalling message is subject to access barring check, based on the barring instruction.       

     Embodiment 3. The method according any of the embodiments 1-2, further comprising:
         determining  1203  access category for the access barring check, and   wherein the performing  1204  of the access barring check is based on the determined access category.       

     Embodiment 4. The method according any of the embodiments 1-3, wherein the performing  1204  of the access barring check is based on the determined access category is performed when the signalling message is an attempt to access the wireless communications network  100 , e.g. referred to as access attempt. 
     Embodiment 5. The method according any of the embodiments 1-4, wherein the UE  120  is not authorized comprises that the UE  120  is not authorized to send the signalling message. 
     Embodiment 6. The method according to any of the embodiments 1-5, wherein how to proceed based on the barring instructions is determined according to any one out of: 
     When the barring instruction is set to ignore, determining  1205  to not transmit the message,
         when the barring instruction is set to wait and retry, determining  1205  to wait during a period according to the barring instruction and then perform a further access barring check,   when the barring instruction is set to go to idle, determining  1205  to enter idle stat such as e.g. RRC_IDLE state,   when the barring instruction is set to fail, determining  1205  to fail a signalling procedure,   when the barring instruction is set to go to inactive, determining  1205  to enter RRC_INACTIVE state, and   when the barring instruction is set to reselect another of any one out of: cell, frequency and system, determining  1205  to re-select to another of any one out of: cell, frequency and system.       

     Embodiment 7. A computer program comprising instructions, which when executed by a processor, causes the processor to perform actions according to any of the embodiments 1-6. 
     Embodiment 8. A carrier comprising the computer program of embodiment 7, wherein the carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium. 
     Embodiment 9. A User Equipment, UE,  120  e.g. for handling access barring, e.g. access control, in a wireless communications network  100 , the UE  120  being configured to any one or more out of:
         obtain barring instructions, e.g. in a message that may need a response, from a network node  110 , e.g. an access node, e.g. by means of an obtaining unit  1510  in the UE  120 ,   perform access barring check e.g. when a signalling message is to be transmitted, e.g. by means of an performing unit  1520  in the UE  120     when the outcome of the access barring check is that the UE  120  is not authorized, determine how to proceed based on the barring instructions, e.g. by means of a determining unit in the UE  120 .       

     Embodiment 10. The UE  120  according embodiment 9, further being configured to e.g. by means of the determining unit  1530  in the UE  120 :
         determine whether or not the signalling message is subject to access barring check, based on the barring instruction.       

     Embodiment 11. The UE  120  according any of the claims  9 - 10 , further being configured to:
         determine access category for the access barring check, e.g. by means of the determining unit in the UE  120  and   perform the access barring check by basing it on the determined access category, e.g. by means of the performing unit in the UE  120 .       

     Embodiment 12. The UE  120  according any of the embodiments 9-11, wherein the UE  120  further is configured to, e.g. by means of the performing unit in the UE  120 , perform the access barring check based on the determined access category by perform it when the signalling message is an attempt to access the wireless communications network  100 , e.g. referred to as access attempt. 
     Embodiment 13. The UE  120  according any of the embodiments 9-12, wherein the UE  120  not being authorized is adapted to comprise that the UE  120  is not authorized to send the signalling message. 
     Embodiment 14. The UE  120  according to any of the embodiments 9-13, wherein how to proceed based on the barring instructions is adapted to be determined, e.g. by means of the determining unit in the UE  120 , according to any one out of: 
     When the barring instruction is set to ignore, determine to not transmit the message,
         when the barring instruction is set to wait and retry, determine to wait during a period according to the barring instruction and then perform a further access barring check,   when the barring instruction is set to go to idle, determine to enter idle stat such as e.g. RRC_IDLE state,   when the barring instruction is set to fail, determine to fail a signalling procedure,   when the barring instruction is set to go to inactive, determine to enter RRC_INACTIVE state, and   when the barring instruction is set to reselect another of any one out of: cell, frequency and system, determine to re-select to another of any one out of: cell, frequency and system.       

     Further Extensions and Variations 
     With reference to  FIG. 13 , in accordance with an embodiment, a communication system includes a telecommunication network  3210  e.g. a WLAN, such as a 3GPP-type cellular network, which comprises an access network  3211 , such as a radio access network, and a core network  3214 . The access network  3211  comprises a plurality of base stations  3212   a ,  3212   b ,  3212   c , such as the network node  110 , access nodes, AP STAs NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area  3213   a ,  3213   b ,  3213   c . Each base station  3212   a ,  3212   b ,  3212   c  is connectable to the core network  3214  over a wired or wireless connection  3215 . A first user equipment (UE) such a Non-AP STA  3291  located in coverage area  3213   c  is configured to wirelessly connect to, or be paged by, the corresponding base station  3212   c . A second UE  3292  such as a Non-AP STA in coverage area  3213   a  is wirelessly connectable to the corresponding base station  3212   a . While a plurality of UEs  3291 ,  3292  are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station  3212 . Any of the UEs  3291 ,  3292 , may e.g. be the UE  120 . 
     The telecommunication network  3210  is itself connected to a host computer  3230 , which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer  3230  may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections  3221 ,  3222  between the telecommunication network  3210  and the host computer  3230  may extend directly from the core network  3214  to the host computer  3230  or may go via an optional intermediate network  3220 . The intermediate network  3220  may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network  3220 , if any, may be a backbone network or the Internet; in particular, the intermediate network  3220  may comprise two or more sub-networks (not shown). 
     The communication system of  FIG. 13  as a whole enables connectivity between one of the connected UEs  3291 ,  3292  and the host computer  3230 . The connectivity may be described as an over-the-top (OTT) connection  3250 . The host computer  3230  and the connected UEs  3291 ,  3292  are configured to communicate data and/or signaling via the OTT connection  3250 , using the access network  3211 , the core network  3214 , any intermediate network  3220  and possible further infrastructure (not shown) as intermediaries. The OTT connection  3250  may be transparent in the sense that the participating communication devices through which the OTT connection  3250  passes are unaware of routing of uplink and downlink communications. For example, a base station  3212  may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer  3230  to be forwarded (e.g., handed over) to a connected UE  3291 . Similarly, the base station  3212  need not be aware of the future routing of an outgoing uplink communication originating from the UE  3291  towards the host computer  3230 . 
     Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to  FIG. 14 . In a communication system  3300 , a host computer  3310  comprises hardware  3315  including a communication interface  3316  configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system  3300 . The host computer  3310  further comprises processing circuitry  3318 , which may have storage and/or processing capabilities. In particular, the processing circuitry  3318  may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer  3310  further comprises software  3311 , which is stored in or accessible by the host computer  3310  and executable by the processing circuitry  3318 . The software  3311  includes a host application  3312 . The host application  3312  may be operable to provide a service to a remote user, such as a UE  3330  connecting via an OTT connection  3350  terminating at the UE  3330  and the host computer  3310 . In providing the service to the remote user, the host application  3312  may provide user data which is transmitted using the OTT connection  3350 . 
     The communication system  3300  further includes a base station  3320  provided in a telecommunication system and comprising hardware  3325  enabling it to communicate with the host computer  3310  and with the UE  3330 . The hardware  3325  may include a communication interface  3326  for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system  3300 , as well as a radio interface  3327  for setting up and maintaining at least a wireless connection  3370  with a UE  3330  located in a coverage area (not shown in  FIG. 14 ) served by the base station  3320 . The communication interface  3326  may be configured to facilitate a connection  3360  to the host computer  3310 . The connection  3360  may be direct or it may pass through a core network (not shown in  FIG. 14 ) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware  3325  of the base station  3320  further includes processing circuitry  3328 , which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station  3320  further has software  3321  stored internally or accessible via an external connection. 
     The communication system  3300  further includes the UE  3330  already referred to. Its hardware  3335  may include a radio interface  3337  configured to set up and maintain a wireless connection  3370  with a base station serving a coverage area in which the UE  3330  is currently located. The hardware  3335  of the UE  3330  further includes processing circuitry  3338 , which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE  3330  further comprises software  3331 , which is stored in or accessible by the UE  3330  and executable by the processing circuitry  3338 . The software  3331  includes a client application  3332 . The client application  3332  may be operable to provide a service to a human or non-human user via the UE  3330 , with the support of the host computer  3310 . In the host computer  3310 , an executing host application  3312  may communicate with the executing client application  3332  via the OTT connection  3350  terminating at the UE  3330  and the host computer  3310 . In providing the service to the user, the client application  3332  may receive request data from the host application  3312  and provide user data in response to the request data. The OTT connection  3350  may transfer both the request data and the user data. The client application  3332  may interact with the user to generate the user data that it provides. 
     It is noted that the host computer  3310 , base station  3320  and UE  3330  illustrated in  FIG. 14  may be identical to the host computer  3230 , one of the base stations  3212   a ,  3212   b ,  3212   c  and one of the UEs  3291 ,  3292  of  FIG. 13 , respectively. This is to say, the inner workings of these entities may be as shown in  FIG. 14  and independently, the surrounding network topology may be that of  FIG. 13 . 
     In  FIG. 14 , the OTT connection  3350  has been drawn abstractly to illustrate the communication between the host computer  3310  and the use equipment  3330  via the base station  3320 , without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE  3330  or from the service provider operating the host computer  3310 , or both. While the OTT connection  3350  is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network). 
     The wireless connection  3370  between the UE  3330  and the base station  3320  is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE  3330  using the OTT connection  3350 , in which the wireless connection  3370  forms the last segment. More precisely, the teachings of these embodiments may improve the RAN effect: such as data rate, latency, power consumption and thereby provide benefits such reduced user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime]. 
     A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection  3350  between the host computer  3310  and UE  3330 , in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection  3350  may be implemented in the software  3311  of the host computer  3310  or in the software  3331  of the UE  3330 , or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection  3350  passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software  3311 ,  3331  may compute or estimate the monitored quantities. The reconfiguring of the OTT connection  3350  may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station  3320 , and it may be unknown or imperceptible to the base station  3320 . Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer&#39;s  3310  measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software  3311 ,  3331  causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection  3350  while it monitors propagation times, errors etc. 
       FIG. 15  is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to  FIG. 13  and  FIG. 14 . For simplicity of the present disclosure, only drawing references to  FIG. 15  will be included in this section. In a first action  3410  of the method, the host computer provides user data. In an optional subaction  3411  of the first action  3410 , the host computer provides the user data by executing a host application. In a second action  3420 , the host computer initiates a transmission carrying the user data to the UE. In an optional third action  3430 , the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth action  3440 , the UE executes a client application associated with the host application executed by the host computer. 
       FIG. 16  is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to  FIG. 13  and  FIG. 14 . For simplicity of the present disclosure, only drawing references to  FIG. 16  will be included in this section. In a first action  3510  of the method, the host computer provides user data. In an optional subaction (not shown) the host computer provides the user data by executing a host application. In a second action  3520 , the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third action  3530 , the UE receives the user data carried in the transmission. 
       FIG. 17  is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to  FIG. 13  and  FIG. 14 . For simplicity of the present disclosure, only drawing references to  FIG. 17  will be included in this section. In an optional first action  3610  of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second action  3620 , the UE provides user data. In an optional subaction  3621  of the second action  3620 , the UE provides the user data by executing a client application. In a further optional subaction  3611  of the first action  3610 , the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third subaction  3630 , transmission of the user data to the host computer. In a fourth action  3640  of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure. 
       FIG. 18  is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station such as an AP STA, and a UE such as a Non-AP STA which may be those described with reference to  FIG. 13  and  FIG. 14 . For simplicity of the present disclosure, only drawing references to  FIG. 18  will be included in this section. In an optional first action  3710  of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second action  3720 , the base station initiates transmission of the received user data to the host computer. In a third action  3730 , the host computer receives the user data carried in the transmission initiated by the base station. 
     When using the word “comprise” or “comprising” it shall be interpreted as non-limiting, i.e. meaning “consist at least of”. 
     The embodiments herein are not limited to the above described preferred embodiments. Various alternatives, modifications and equivalents may be used. 
     ABBREVIATION EXPLANATION 
     
         
         
           
             5GS 5G System 
             AN Access Network 
             AN Access Node 
             EPS Evolved Packet System 
             AS Access Stratum 
             NAS Non-Access Stratum