Access Control in 5G NR

Abstract

Access control in 5G NR. An access class management object may be configured to support access class configuration of a user equipment, UE. Various methods for UE configuration with access class are disclosed. Signaling methods for access restriction parameters of a radio access network are disclosed, such as a signaling method for a partial list of access restriction parameters with explicit signaling of an access class index, and a signaling method for signaling a complete list of access restriction parameters for an access class using a bitmap. Access control parameters and an access control architecture in terms of the distribution of access control functions within the UE protocol sublayer, a solution to address the impact of access control in connected mode on buffer status reporting, logical channel prioritization, and flow control between the UE AS and the UE NAS, and detailed information on access restriction checks are also disclosed.

Description

[0001] This application is a divisional application of the patent application with application number 201880061842.4, invention name “Access Control in 5G NR”, and international application date of August 9, 2018, and all the contents of which are incorporated herein by reference.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 542,977, filed on August 9, 2017, the entire contents of which are incorporated herein by reference. Background Art

[0004] It is envisaged that International Mobile Telecommunications (IMT) (ITU-R M.2083) to 2020 and beyond (“IMT 2020”) will extend and support a diverse range of use cases and applications that will survive the current IMT. Furthermore, a wide variety of capabilities are likely to be tightly coupled with these different expected use cases and applications for IMT to 2020 and beyond. The range of use cases for IMT to 2020 and beyond includes: eMBB (enhanced mobile broadband), URLLC (ultra-reliable and low latency communications) and mMTC (massive machine type communications). These major use cases have diverse and conflicting service requirements in terms of latency, data rate, mobility, device density, reliability, UE battery life, network energy consumption, etc. Summary of the invention

[0005] Given the multitude and variety of services and vertical industries that 5G systems are expected to support, effective access control in 5G networks is critical for stable 5G network operations while ensuring that available network capacity is allocated in a manner that is consistent with the operator’s goal of maximizing profits from the services provided, while providing an excellent customer experience and complying with regulatory requirements for prioritizing critical communications and emergency calls.

[0006] Disclosed herein is an access category management object configured to support access category configuration of a user equipment (UE) by a core network (e.g., using a push approach) and to support the UE querying the core network for access category configuration (e.g., using a pull approach). Various methods for UE configuration with access categories are disclosed (e.g., by fully enumerating access category attributes or by using access category components). Signaling methods for access restriction parameters of a radio access network are disclosed, such as signaling methods for a partial list of access restriction parameters and signaling methods for a complete list of access restriction parameters. Access control parameters and access control architectures in terms of the distribution of access control functions within a UE protocol sublayer are also disclosed, solutions to address the impact of access control in connected mode on buffer status reporting, logical channel prioritization, and flow control between a UE AS and a UE NAS, and detailed information on access restriction checks. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The following detailed description will be better understood when read in conjunction with the accompanying drawings. For illustrative purposes, examples are shown in the accompanying drawings; however, the subject matter is not limited to the specific elements and instrumentalities disclosed. In the drawings:

[0008] Figure 1A One embodiment of an example communication system in which the methods and apparatus described and claimed herein may be implemented is shown;

[0009] Figure 1B is a block diagram of an example apparatus or device configured for wireless communication according to embodiments illustrated herein;

[0010] Figure 1C is a system diagram of an exemplary radio access network (RAN) and core network according to an embodiment;

[0011] Figure 1D is another system diagram of a RAN and a core network according to another embodiment;

[0012] Figure 1E is another system diagram of a RAN and a core network according to another embodiment;

[0013] Figure 1F It is possible Figure 1A , Figure 1C , Figure 1D and Figure 1E A block diagram of an exemplary computing system 90 for one or more devices in a communication network shown in FIG.

[0014] Figure 2 An example flow chart showing an access category control method;

[0015] Figure 3An example flow chart illustrating the principles of access control is shown;

[0016] Figure 4 shows an example process for limiting time and limiting factors;

[0017] Figure 5 shows an example access category management object;

[0018] Figure 6 An example access category configuration is shown;

[0019] Figure 7 shows an example application information configuration;

[0020] Figure 8 shows an example access category configuration;

[0021] Fig. 9 shows an example call type configuration;

[0022] Fig.10 shows an example network slice configuration;

[0023] Fig.11 shows an example QoS flow configuration;

[0024] Fig.12 shows an example service data flow configuration;

[0025] Fig.13 shows an example packet flow filter configuration;

[0026] Fig.14 An example access category authentication configuration is shown;

[0027] Fig.15 An example block diagram illustrating access categories based on access category components;

[0028] Fig.16 An example UE configuration is shown, which shows details of AC attributes or AC components of access categories;

[0029] Fig.17 An example of a bitmap representation of an access component is shown;

[0030] Fig.18 An example UE configuration with access category using an access category component based approach is shown;

[0031] Fig.19 An example UE configuration with access category using a method based on access category attribute enumeration is shown;

[0032] Fig. 20 An example non-roaming architecture for access class provisioning on the user plane is shown;

[0033] Fig.21 An example roaming architecture for access class provisioning on the user plane is shown;

[0034] Fig. 22 showing an example access category bitmap having access category components at predetermined locations;

[0035] Fig.23 Example signaling showing a partial list of AC restriction parameters;

[0036] Fig.24 Another example signaling showing a partial list of AC restriction parameters;

[0037] Fig.25 Example signaling showing a complete list of AC restriction parameters;

[0038] Fig.26 Another example signaling showing a complete list of AC restriction parameters;

[0039] Fig. 27 An example combination of access restriction parameter signaling based on a partial list and a complete list is shown;

[0040] Fig.28 Another example combination of access restriction parameter signaling based on a partial list and a complete list is shown;

[0041] Fig.29 An example AS-CP solution is shown for NAS-CP events requiring access control in RRC_IDLE;

[0042] Fig.30 An example NAS-CP solution is shown for NAS-CP events requiring access control in RRC-IDLE;

[0043] Fig.31 An example AS-UP solution is shown for AS-UP events requiring access control in RRC_INACTIVE and RRC_CONNECTED;

[0044] Fig.32 An example NAS-UP solution is shown for NAS-UP events requiring access control in RRC_INACTIVE and RRC_CONNECTED;

[0045] Fig.33Shows an example AS-CP solution for NAS_CP events requiring access control in RRC_INACTIVE and RRC_CONNECTED;

[0046] Fig.34 An example AS-CP solution is shown for AS-CP events requiring access control in RRC_INACTIVE and RRC_CONNECTED;

[0047] Fig.35 An example AS-CP solution is shown for AS-UP events requiring access control in RRC_INACTIVE and RRC_CONNECTED;

[0048] Fig.36 An example AS-CP solution is shown for NAS-UP events requiring access control in RRC_INACTIVE and RRC_CONNECTED;

[0049] Fig.37 An example NAS-CP solution is shown for NAS-CP events requiring access control in RRC_CONNECTED and RRC_INACTIVE;

[0050] Fig.38 An example NAS-CP solution is shown for NAS-UP events requiring access control in RRC_INACTIVE and RRC_CONNECTED;

[0051] Fig.39 Shows an example AS solution for UP events requiring access control in RRC_CONNECTED;

[0052] Fig.40 An example NAS solution for UP events requiring access control in RRC_CONNECTED is shown;

[0053] Fig.41A and Fig.41B An example process for access restriction initiation is shown;

[0054] Fig.42 An example of access restriction information in a system information block is shown.

[0055] Fig.43Another example of access restriction information in a system information block is shown.

[0056] Fig.44A and Fig.44B An example process for access restriction checking is shown;

[0057] Fig.45A and Fig.45B illustrates an example process for access restriction control timers; and

[0058] Fig.46 An example user interface for access category display and selection is shown. DETAILED DESCRIPTION

[0059] The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport network, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE-Advanced standards. 3GPP has begun work on the standardization of the next generation of cellular technology, which is called New Radio (NR), also known as "5G". The development of the 3GPP NR standards is expected to include the definition of the next generation radio access technology (new RAT), which will include the provision of new flexible radio access below 6 GHz, and the provision of new ultra-mobile broadband radio access above 6 GHz. The flexible radio access is expected to include new non-backwards compatible radio access in new spectrum below 6 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide set of 3GPP NR use cases with different requirements. It is expected that ultra-mobile broadband will include centimeter wave (cmWave) and millimeter wave (mmWave) spectrum, which will provide opportunities for ultra-mobile broadband access, such as indoor applications and hotspots. In particular, it is expected that ultra-mobile broadband will share a common design framework with flexible radio access below 6 GHz, with design optimizations specific to cmWave and mmWave.

[0060] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high broadband access indoors, broadband access in crowds, 50+Mbps everywhere, ultra-low-cost broadband access, mobile broadband in vehicles), critical communications, massive machine-type communications, network operations (e.g., network slicing, routing, migration and interworking, energy conservation), and enhanced vehicle-to-everything (eV2X) communications. Specific services and applications within these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, car emergency calls, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, and virtual reality, to name a few. All of these use cases and others are contemplated in this article.

[0061] Figure 1A An embodiment of an example communication system 100 is shown in which the methods and apparatus described and claimed herein may be implemented. As shown, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and / or 102d (which may be generally or collectively referred to as WTRUs 102), a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e may be any type of apparatus or device configured to operate and / or communicate in a wireless environment. Although in the example of FIG. Figures 1A-1E 102a, 102b, 102c, 102d, 102e are depicted as handheld wireless communication devices, but it will be understood that in the context of the various use cases envisioned for 5G wireless communications, each WTRU may include or be implemented in any type of device or apparatus configured to send and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smart phone, a laptop computer, a tablet computer, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronic product, a wearable device such as a smart watch or smart clothing, a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle such as a car, truck, train or airplane, and the like.

[0062] The communication system 100 may also include a base station 114a and a base station 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The base station 114b may be any type of device configured to wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b and / or TRPs (transmit and receive points) 119a, 119b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node Bs, eNode Bs, Home Node Bs, Home eNode Bs, site controllers, access points (APs), wireless routers, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0063] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a may be configured to send and / or receive wireless signals in a specific geographic area, which may be referred to as a cell (not shown). The base station 114b may be configured to send and / or receive wired and / or wireless signals in a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, for example, one transceiver for each sector in the cell.In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may therefore employ multiple transceivers for each sector in the cell.

[0064] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0065] The base station 114b may communicate with one or more of the RRHs 118a, 118b and / or TRPs 119a, 119b via a wired or air interface 115b / 116b / 117b, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115b / 116b / 117b may be established using any suitable radio access technology (RAT).

[0066] The RRHs 118a, 118b and / or the TRPs 119a, 119b may communicate with one or more of the WTRUs 102c, 102d over an air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115c / 116c / 117c may be established using any suitable radio access technology (RAT).

[0067] More specifically, as described above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 103 / 104 / 105, or the RRHs 118a, 118b and TRPs 119a, 119b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively, using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0068] In an embodiment, the base station 103a and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b and TRPs 119a, 119b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. In the future, the air interface 115 / 116 / 117 may implement 3GPP NR technology.

[0069] In an embodiment, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b and TRPs 119a, 119b and the WTRUs 102c, 102d in the RAN 103b / 104b / 105b may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0070] Figure 1A The base station 114c in the example may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area (e.g., a place of business, a home, a vehicle, a campus, etc.). In an embodiment, the base station 114c and the WTRU 102e may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114c and the WTRU 102d may implement a radio technology such as IEEE802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114c and the WTRU 102e may employ a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or a femtocell. Figure 1A As shown in FIG, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114c may not be required to access the Internet 110 via core network 106 / 107 / 109.

[0071] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.

[0072] Although not in Figure 1A Although not shown in the figure, it will be appreciated that the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs, which employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, which may be utilizing an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0073] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT.

[0074] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links. Figure 1A The WTRU 102e shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and may be configured to communicate with the base station 114c, which may employ an IEEE 802 radio technology.

[0075] Figure 1B 1 is a block diagram of an example apparatus or device (such as, for example, WTRU 102) configured for wireless communication according to the embodiments illustrated herein. Figure 1BAs shown in , the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiment. Moreover, the embodiment contemplates that the base stations 114a and 114b and / or the nodes that the base stations 114a and 114b may represent (such as, but not limited to, a transceiver station (BTS), a Node B, a site controller, an access point (AP), a Home Node B, an evolved Home Node B (eNodeB), a Home Evolved Node B (HeNB), a Home Evolved Node B gateway and a proxy node, etc.) may include Figure 1B Some or all of the elements depicted in and described herein.

[0076] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0077] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 115 / 116 / 117. For example, in an embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, although Figure 1AAlthough transmission / reception is not shown, it will be appreciated that the RAN 103 / 104 / 105 and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs, which may employ the same RA or a different RAT as the RAN 103 / 104 / 105. For example, in addition to being connected to the RAN 103 / 104 / 105, which may employ an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0078] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. Suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may use the same RAT or a different RAT as the RAN 103 / 104 / 105.

[0079] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links. Figure 1A The WTRU 102c shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and may be configured to communicate with the base station 114b, which may employ an IEEE 802 radio technology.

[0080] Figure 1B 1 is a block diagram of an example apparatus or device (such as, for example, WTRU 102) configured for wireless communication according to the embodiments illustrated herein. Figure 1BAs shown in the example WTRU 102, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. Moreover, embodiments contemplate that the base stations 114a and 114b and / or the nodes that the base stations 114a and 114b may represent (e.g., but not limited to, a transceiver station (BTS), a Node B, a site controller, an access point (AP), a Home Node B, an evolved Home Node B (eNodeB), a Home Evolved Node B (HeNB), a Home Evolved Node B gateway, and a proxy node, etc.) may include Figure 1B Some or all of the elements depicted in and described herein.

[0081] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0082] The send / receive element 122 may be configured to send a signal to a base station (e.g., base station 114a) or receive a signal from a base station (e.g., base station 114a) via an air interface 115 / 116 / 117. For example, in an embodiment, the send / receive element 122 may be an antenna configured to send and / or receive RF signals. In an embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the send / receive element 122 may be configured to send and receive both RF and optical signals. It will be appreciated that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

[0083] In addition, despite Figure 1BThe transmit / receive element 122 is shown as a single element in the WTRU 102, but the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0084] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, for example, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0085] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data from the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. In an embodiment, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0086] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0087] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0088] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors (e.g., accelerometers, biometric (e.g., fingerprint) sensors), electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, etc.

[0089] The WTRU 102 may be implemented in other devices or equipment, such as sensors, consumer electronics, wearable devices (e.g., smart watches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, vehicles (e.g., cars, trucks, trains, or airplanes). The WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripheral devices 138.

[0090] Figure 1C 1 is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As described above, the RAN 103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also communicate with the core network 106. Figure 1CAs shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0091] like Figure 1C As shown in , Node B 140a, 140b can communicate with RNC 142a. In addition, Node B 140c can communicate with RNC 142b. Node B 140a, 140b, 140c can communicate with corresponding RNC 142a, 142b via Iub interface. RNC 142a, 142b can communicate with each other via Iur interface. Each of RNC 142a, 142b can be configured to control the corresponding Node B 140a, 140b, 140c to which it is connected. In addition, each of RNC 142a, 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0092] Figure 1C The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the foregoing elements is depicted as part of the core network 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0093] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0094] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0095] As described above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0096] Figure 1D 1 is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0097] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0098] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and / or downlink, etc. Figure 1D As shown in FIG. , the eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0099] Figure 1D The core network 107 shown in FIG. 1 includes a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the foregoing elements is depicted as part of the core network 107, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0100] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0101] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during handovers between eNode Bs, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0102] The serving gateway 164 may also be connected to a PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0103] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the core network 107 and the PSTN 108. The networks 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0104] Figure 1E1 is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As will be discussed further below, the communication links between the different functional entities WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0105] like Figure 1E As shown in the figure, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it will be understood that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with the embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In an embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to send wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy implementation, etc. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of user profiles, routing to the core network 109, and the like.

[0106] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0107] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point, which includes protocols for facilitating WTRU handovers and data transfer between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0108] like Figure 1E As shown in , the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which includes, for example, protocols for facilitating data transmission and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. Although each of the above elements is depicted as part of the core network 109, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0109] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communication devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0110] Although not in Figure 1EAs shown in FIG. 1 , it will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0111] Described in this article and Figure 1A , Figure 1C , Figure 1D and Figure 1E The core network entities shown in are identified by the names given to those entities in certain existing 3GPP specifications, but it should be understood that those entities and functions may be identified by other names in the future, and that certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Figure 1A , Figure 1B , Figure 1C , Figure 1D and Figure 1E The specific network entities and functionality described and illustrated in the present disclosure are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or defined in the future.

[0112] Figure 1F It is possible Figure 1A , Figure 1C , Figure 1D and Figure 1E109, PSTN 108, Internet 110 or other network 112. The computing system 90 may include a computer or a server and may be primarily controlled by computer-readable instructions, which may be in the form of software, wherever, whenever or by whatever means such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to enable the computing system 90 to operate. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0113] In operation, the processor 91 retrieves, decodes and executes instructions, and transfers information to and from other resources via the computing system's main data transfer path (system bus 80). Such a system bus connects the components in the computing system 90 and defines the medium for data exchange. The system bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0114] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes circuits that allow information to be stored and retrieved. ROM 93 generally contains stored data that is not easily modified. The data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set up, it cannot access memory within the virtual address space of another process.

[0115] In addition, the computing system 90 may include a peripheral device controller 83 , which is responsible for passing instructions from the processor 91 to peripheral devices, such as a printer 94 , a keyboard 84 , a mouse 95 , and a disk drive 85 .

[0116] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components required to generate a video signal, which is sent to the display 86.

[0117] In addition, computing system 90 may include communication circuitry (such as, for example, network adapter 97) that may be used to connect computing system 90 to an external communication network (eg, Figure 1A , Figure 1B , Figure 1C , Figure 1D and Figure 1E The RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112) of the present invention can be used to enable the computing system 90 to communicate with other nodes or functional entities of those networks. Alone or in combination with the processor 91, the communication circuit can be used to perform the sending and receiving steps of certain devices, nodes or functional entities described herein.

[0118] It should be understood that any or all of the devices, systems, methods, and processes described herein may be implemented in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor such as processor 118 or 91, causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any steps, operations, or functions described herein may be implemented in the form of such computer executable instructions, which are executed on a processor of a device or computing system configured for wireless and / or wired network communications. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-transient (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassettes, tapes, disk storage or other magnetic storage devices, or any other tangible or physical media that can be used to store desired information and can be accessed by a computing system.

[0119] In view of the diverse and conflicting service requirements that the next generation international mobile telecommunications system may support, 3GPP has identified a set of system architecture requirements. The following are examples of requirements that the architecture of the next generation system may support:

[0120] The RAN architecture may support tight interworking between the new RAT and LTE. Aggregation of data flows via at least dual connectivity between LTE and the new RAT and high performance inter-RAT mobility may be considered. This may be supported by both collocated and non-collocated site deployments;

[0121] CN architecture and RAN architecture can allow C-plane / U-plane separation;

[0122] The RAN architecture may support connections through multiple transmission points that may be collocated or non-collocated. The RAN architecture may separate control plane signaling and user plane data from different sites. The RAN architecture may support the following interface that supports efficient inter-site scheduling coordination:

[0123] It can allow different options and flexibility for partitioning the RAN architecture. The RAN architecture can allow deployment using network function virtualization;

[0124] The CN architecture and RAN architecture can allow the operation of network slicing;

[0125] Support services with different latency requirements between the UE and the data network;

[0126] Support multiple simultaneous connections of UE via multiple access technologies;

[0127] Supports the transmission of IP packets, non-IP PDUs and Ethernet frames;

[0128] Supports network sharing; and

[0129] Allows independent evolution of the core network and RAN and minimizes access dependencies.

[0130] One purpose of access control in a communication system is to manage the load generated by the various services on the communication system. Access control solutions can be grouped into two main categories: active solutions that are usually applied to prevent overload in the system, and passive solutions that are usually applied when the system is overloaded. Radio access restriction control can be categorized into the following two methods:

[0131] Access class control method (control in a mobile terminal): before the mobile terminal sends a connection request to a base station, the mobile terminal can identify the type of call and determine whether the connection request for the call should be restricted; and

[0132] RRC Connection Rejection Method (Control in Base Station): The base station can identify the type of signal triggering a connection request sent from the mobile terminal and decide whether the request should be rejected (by sending an RRC Connection Reject) or accepted.

[0133] Access class control according to TS 22.011 allows the possibility to prevent a UE from making an access attempt or responding to a page. The basis of many LTE access control functions is the division of UEs into assigned populations (0-9) and special categories (11-15), so-called access categories. All UEs can be members of one of ten randomly assigned mobile populations (e.g., access categories 0 to 9). The population numbers can be stored in the SIM / USIM. In addition, the UE can be a member of one or more of 5 special categories (e.g., access categories 11 to 15) also stored in the SIM / USIM. These are assigned to specific high priority users as shown below. The existing access categories are enumerated below. Note that the enumeration does not imply a priority sequence.

[0134] Category 15: PLMN staff; (only when the EHPLMN list does not exist or any EHPLMN is the home PLMN);

[0135] Category 14: Emergency services; (home PLMN and visited PLMN of home country only. For this purpose, home country is defined as the country of the MCC part of the IMSI);

[0136] Category 13: Utilities (e.g. water / gas providers); Home PLMN and Visiting PLMN of the country only. For this purpose, the Country of Home is defined as the country of the MCC part of the IMSI;

[0137] Category 12: Security services; Home PLMN and Visiting PLMN of the home country only. For this purpose, the home country is defined as the country of the MCC part of the IMSI;

[0138] Category 11: For use by PLMN (only when the EHPLMN list does not exist or any EHPLMN is the home PLMN);

[0139] Category 10: for emergency calls; and

[0140] Category 0-9: Home PLMN and Visited PLMN.

[0141] In access category control, the base station broadcasts information containing control data (e.g., barring rate, average access barring time value in seconds) set for each access category (AC), so that all terminals in the coverage area can simultaneously receive the information and perform access control, such as Figure 2 Generally, the purpose of applying access class control to AC 0 to 9 is to protect network devices and optimize communication traffic, while applying access class control to AC 10 and AC 11 to 15 so that no restrictions are applied is to achieve safe communication for emergency and high-priority communications. Figure 2 Several access class control methods of the control flow shown in have been specified in LTE and are further discussed in this article.

[0142] Access Class Barring (ACB) is an access control mechanism applicable only to RRC idle mode. ACB is performed in the UE RRC layer. Based on the restriction rate information broadcast by the network, the terminal determines, based on its AC, whether to allow the sending of a connection request. In addition, there are two types of packet data transmission that can be controlled using ACB: the sending of connection requests for general packet calls (including Voice over LTE (VoLTE)) and emergency calls. Restriction parameters for signaling (e.g., mobile originated signaling, such as MO signaling) are defined separately from restriction parameters for ordinary data signaling (mobile originated data, such as MO data). Based on the restriction rate information broadcast by the network, the terminal determines, based on its AC, whether to allow the sending of a connection request.

[0143] Service-specific access control (SSAC) is an access class control method that is applicable to both RRC idle mode and RRC connected mode. In this method, SSAC is performed in the NAS IMS layer. The SSAC access control feature allows independent access control for multimedia telephony (MMTEL services, such as VoLTE and LTE video (ViLTE), etc.). The SSAC feature is also applied to RRC connected mode, because even if the terminal is already connected to the network, access control may be required for background signaling traffic (for example, background synchronization traffic between an IMS application client in the UE and an IMS server). Based on the SSAC-specific limiting rate information broadcast by the network, for IMS voice, IMS video, or IMS SMS, the terminal determines whether to allow the connection request to be sent according to its AC.

[0144] It should be noted that in order to prioritize MMTEL services, a mechanism is discussed herein that skips the ACB feature for connection requests associated with MMTEL service call types. The concept is to invalidate MMTEL services that are subject to dual access restrictions (e.g., restrictions at the conventional ACB level and then restrictions at the SSAC level).

[0145] For LTE terminals that do not support the above-mentioned VoLTE function, voice services are provided through access control for circuit switched fallback (CSFB). ACB for CSFB is defined to limit connection requests for CSFB calls while the terminal is still camped in the LTE network. This access control mechanism is applied to UEs in RRC idle mode. It should be noted that in order to prioritize CSFB calls when ACB is enabled and avoid CSFB calls being restricted due to the ACB features as described in this article, CSFB-specific access restriction control has been introduced in LTE. Based on the CSFB-specific restriction rate information broadcast by the network, the terminal determines whether to allow the connection request to be sent based on its AC.

[0146] Application-specific data communication congestion control (ACDC) is an access control mechanism for operators to allow / prevent new access attempts from specific operator-identified applications in UEs in idle mode. This mechanism is applicable only to UEs in RRC idle mode. The home network can configure the UE with at least four and up to sixteen ACDC categories, with specific operator-identified applications associated with each ACDC category. When configured, the access control restriction configuration is configured on the basis of the ACDC category, and when not present, access to the cell is considered unrestricted for that ACDC category. Based on the ACDC category-specific restriction rate information broadcast by the network, the terminal determines whether to allow the connection request to be sent based on its AC.

[0147] Extended Access Class Barring (EAB) is an access restriction control method that may only be applicable to UEs in RRC idle mode. Extended Access Barring (EAB) is a mechanism for operators to control mobile-originated access attempts from UEs configured as EAB (typically machine type communication (MTC) devices) to prevent overload of the access network and / or core network. In congestion situations, operators can restrict access from UEs configured as EAB while allowing access from other UEs. UEs configured as EAB are considered to be more tolerant of access constraints than other UEs. When an operator determines that it is appropriate to apply EAB, the network broadcasts the required information to provide EAB control for UEs in a specific area. The network broadcasts a bitmap that includes the AC (possibly 0 to 9) to which extended access restrictions are applied and the category of the UE to which EAB is applied (category a, b or c). UEs configured with low access priority and extended access restrictions can also be configured to permit overwriting of low access and extended access restriction priority constraints. This configuration is mainly intended for applications or users that can tolerate being delayed due to low access priority most of the time when competing with other UEs for access to network resources, but sometimes need to access the network when the low access priority configuration would prevent access. In order to obtain network access during low priority access or extended access restriction constraints, the user or application (upper layers in the UE) can request the UE to start activation of the PDN connection without low access priority.

[0148] The RAN2 working group of 3GPP is considering a unified access control framework (e.g., a common framework for radio access control based on access categories), in which each UE will use a default or pre-configured access category to evaluate whether to allow access to the network based on access restriction configuration information signaled by the network (e.g., when in RRC idle mode or RRC inactive mode) or sent to the network (e.g., when in RRC connected mode). Figure 3 An exemplary access control procedure supporting this unified approach is depicted in R2-1706505, Access Control for NR, 3GPP TSG-RAN WG2 NR#2, Ericsson. This example assumes that the actual access control is performed in the UE AS (e.g., Figure 3 6 in the previous step).

[0149] The following is a brief description of the signaling flow captured in R2-1706505:

[0150] In step 1, the core network configures the access categories in the UE. The configuration includes mapping rules related to combinations of event types, applications, services or other aspects of the access categories. If necessary, the access categories (0-15) stored in the SIM can also be used in the mapping rules. These mapping rules are configured from the core network using NAS signaling. This is usually dedicated signaling in order to have a UE-specific configuration and is usually performed during attachment and, for example, registration area updates. The configuration results of the categories in the UE can be shown as a table, including both the configuration rules and the resulting categories.

[0151] Table 1: Example of access category configuration in UE

[0152] Access Type Sharding application Call Type … Access Category * 7 * * 3 * * 3 * 5 10 * * Emergency Call 10 * * * Originating signaling 2

[0153] This example shows the access category depending on access class, slice, application and call type, but it is not necessarily the case that all aspects need to be considered. Once the access is related to application 3, it may for example always lead to access category 5, regardless of other inputs. The configured access category is stored in the UE.

[0154] In step 2, the triggering of access to the network occurs in the NAS layer in the UE.

[0155] In step 3, the NAS determines the access category for the specific access based on the UE configuration in step 1.

[0156] In step 4, when requesting to establish a connection, NAS provides the determined access category to AS (RRC layer).

[0157] In step 5, an access control restriction indication is received. The RAN indicates whether the access category is restricted through system information (for example, using a restriction probability factor and restriction time similar to ACDC, or a bitmap or other methods similar to EAB). This signaling is part of the RRC layer. How to implement and transmit these parameters is further discussed in R2-1706509 (Signaling of Access Control Parameters, 3GPP TSG-RAN WG2NR#2, Ericsson) and is Figure 4 Further shown in .

[0158] At step 6, an access restriction check occurs. Before making an access attempt (random access), the AS layer in the UE uses the determined access class and the broadcasted system information to check if a particular access class is restricted. This is typically part of the RRC layer.

[0159] In step 7, if the AS layer in the UE determines that the specific access is not restricted, it performs an access attempt.

[0160] Table 2 summarizes the allocation of different functions for access control.

[0161] Table 2: Allocation of access control functions

[0162]

[0163] Given the 5G NR requirements and the multiple and varied services and verticals that 5G systems are expected to support, effective access control in 5G networks is required for stable 5G network operations while ensuring that available network capacity is allocated in a manner that is consistent with the operator’s goal of maximizing profits from the services provided, while providing an excellent customer experience and complying with regulatory requirements for prioritization of critical communications and emergency calls.

[0164] As discussed herein, the RAN2 working group of 3GPP is considering a unified access control framework (e.g., a common framework for radio access control based on access categories), in which each UE will use a default or pre-configured access category to evaluate whether to be allowed to access the network based on access restriction configuration information signaled by the network (e.g., when in RRC idle mode or RRC inactive mode) or sent to the network (e.g., when in RRC connected mode).

[0165] One issue that needs to be addressed is the design of an efficient signaling process for AC restriction configuration. Given the large set of services and vertical industries that 5G systems are expected to support and the forward-looking requirements for 5G design, many access class mapping rules for combinations of attributes (e.g., event type, application, service, slice, call type, device class, QoS classification index (QCI), QoS flow, or other aspects used to define access classes) may be considered, resulting in a potentially large number of access classes. If not designed properly, the signaling of these classes and their corresponding radio access restriction configuration parameters may represent a large amount of overhead.

[0166] Furthermore, configuring the UE by the network to have an access class on itself may represent a signaling overhead challenge, and therefore the design of the signaling used to configure the access class for the UE needs to be carefully considered. For example, performing the configuration of the access class in the UE may require signaling from the core network. This configuration may then be used when the UE makes subsequent access attempts. This typically means that during idle and inactive mobility, the UE should be able to use the configuration previously obtained from the core network. In order to avoid triggering additional signaling, it seems reasonable to try to maintain the rules for access class mapping and change them infrequently. However, a method for determining the validity of the stored configuration of the access class by the UE is an issue that should be addressed.

[0167] Another problem to be solved is the issue of access restriction control for UEs in RRC connected mode. A solution for access control in the control plane and the user plane for UEs in RRC connected state needs to be designed. For example, assume that there is access control in the user plane and there is uplink data to be sent on a QoS flow belonging to an existing PDU session. Such uplink transmissions may be subject to access control. If uplink transmissions are not possible due to access control decisions, UE behavior may need to be specified for the following:

[0168] Buffer status reporting in the presence of uplink transmission constraints through access control;

[0169] Scheduling request handling in the presence of uplink transmission constraints through access control;

[0170] logical channel prioritization in the presence of uplink transmission constraints through access control; and / or

[0171] If access control is implemented by AS, flow control between UE NAS and UE AS.

[0172] Additionally, access control in idle and inactive modes may need to be addressed.

[0173] A method and system for access class configuration signaling are disclosed.

[0174] Two types of access categories can be configured for the UE. One type of access category may be an access category defined in the specification. These access categories may include special access categories for use by PLMN staff, emergency services, utilities (e.g., water / gas suppliers), security services, etc. These types of access categories, including special access categories, which may be specified in the standard, may be referred to as default access categories in this article. Other types of access categories that can be configured for the UE may be access categories that are not specified in the standard. Definitions such as access categories can be left to implementation- and deployment-specific scenarios, thereby providing operators with flexibility to supply service differentiation products. For example, the 5G specification may define a series of access categories and potential access category identifiers. A portion of access category identifiers, corresponding access categories, and details of their use and attributes may be specified, while a second set of access categories that constitute the rest of the specified access category series may be left to implementation- or deployment-specific scenarios in terms of their meaning and how to use them. This second type of access category may be referred to as an "operator-defined access category" in this article.

[0175] Access categories may be defined based on one or more of the following attributes or components: access class, slice, application, OS, call type, traffic flow or packet flow, service data flow, QoS flow, QCI, subscription profile (e.g., platinum, gold, silver, and bronze).

[0176] exist Figure 5 Possible management objects for access category configuration using the Open Mobile Alliance Device Management (OMA DM) protocol are shown in FIG. Figures 6 to 14 The configuration of the node of the access category management object is described in.

[0177] like Figure 6 Another aspect of the access class configuration shown in relates to the validity of the access class configuration stored in the UE. The access class configuration information may include validity criteria configuration information. One or more of the following criteria may be used to define and configure validity rules for one or more access classes: validity area, time of day, radio access network conditions related to radio signal quality, radio signal strength threshold criteria. Fig.14 Possible management objects of validity criteria that the UE may use to evaluate the validity of stored access class configurations are depicted in FIG.

[0178] Before the UE sends the access category information to the UE entity that performs the access restriction check, the UE may verify that the access category is still valid (e.g., the access category meets the validity criteria). For example, if the access restriction check is performed by the UE access stratum (AS) and the access category information is configured for the UE non-access stratum (NAS) or an entity within that stratum, the UE NAS may verify the access category validity before providing the access category information to the AS for the access restriction check as described herein. When the access category is no longer valid, the UE may not use the access category in the access restriction check.

[0179] In one example, access category configuration based on access category components is disclosed. An access category may include one or more access category components. Fig.15 As shown in , the access category component can be one or more of the following: access class, slice, application, OS, call type, business flow or packet flow, service data flow, QoS flow, QCI, subscription profile (e.g., platinum user, gold user, silver user and bronze user). For the default access category, the details of the access category component can be specified in the standard, as described herein. One or more access categories can be configured for the UE by the core network, where each access category contains one or more access category components. In another example, one or more access categories can be configured for the UE by the radio access network (e.g., gNB), where each access category contains one or more access category components.

[0180] In an example, each access category component may be represented by a bitmap, where a given value of the bitmap corresponds to an instance of the access category component. Fig.16 As shown in , a list of possible values ​​or instances of access attributes or components corresponding to potential access categories that may eventually be configured for the UE by the core network may be first configured for the UE.

[0181] For the purpose of configuring a UE with a particular access category, the bitmap may subsequently be used to represent access components within the access category. For example, an access category component may correspond to an application that is expected to be run over the communications network. The UE may be initially configured with a list of applications that may be used as part of the access category configuration in the network. To support UE configuration with a particular access category, the UE may use a bitmap to reference applications that have been configured on the UE, which may then be used to configure an application ID, which is a component of the access category being configured for the UE. The bitmap for each access category component may be of a different size. In an example, to configure an access category for a UE, the core network signals to the UE the bitmap corresponding to the access category components that make up the access category, such as Fig.17 and Fig.18 In another example, to configure an access category for a UE, a radio access network (e.g., a gNB) signals to the UE a bitmap corresponding to the access category components constituting the access category.

[0182] In an example, each access category component may be represented by an enumeration structure, wherein each value of the enumeration corresponds to a possible instance of an access category component. For example, as an illustration, taking network slicing as an access category component, an operator may configure the following slicings: eMBB slicing_1, eMBB slicing_2, eMBB slicing_3, URLLC slicing_1, URLLC slicing_2, mMTC slicing_1, mMTC slicing_2, and mMTC slicing_3. The access category component of a network slicing may be represented by the following enumeration: enumeration {slicing_1, eMBB slicing_2, eMBB slicing_3, URLLC slicing_1, URLLC slicing_2, mMTC slicing_1, mMTC slicing_2, and mMTC slicing_3}. In order to configure an access category for a UE, the core network signals the UE with the enumeration values ​​of the access category components that constitute the access category (e.g., URLLC slicing_2 for the access category component corresponds to a network slicing attribute). In another example, to configure an access category for a UE, the radio access network (e.g., a gNB) signals to the UE enumerated values ​​of access category components that constitute the access category (e.g., URLLC fragmentation_2 for the access category component corresponds to a network fragmentation attribute).

[0183] use Fig.15In the example access category depicted in FIG. 1 , an enumeration example of access components may be enumerated as follows:

[0184] Call Type: Enum {"Originating Signaling","Emergency Call","Originating Voice","Originating Video","Originating SMSoIP","Originating SMS","Terminating Call","Originating Call","Mobile Originating CS Fallback"}

[0185] Network sharding: enumeration {eMBB shard_1, eMBB shard_2, eMBB shard_3, URLLC shard_1, URLLC shard_2, mMTC shard_1, mMTC shard_2, and mMTC shard_3)

[0186] Operating system (OS): enumeration {Apple iOS, Android, Blackberry, Windows, Symbian, BADA, Palm OS (palm OS), Open WebOS (open web OS), Maemo, MeeGo, Verdict}

[0187] Apps: {Movie and video apps such as Netflix, Hulu, YouTube, YouTube TV, Spotify, etc.; News apps such as NYTimes, Vice News, The Washington Post, CBS Sports, etc.; Social media apps such as Facebook, Instagram, Twitter, etc.; Instant messaging apps such as Skype, Messenger, WhatsApp, Snapchat, etc.; Gaming apps such as Steam, PlayStation apps, XboxOne, V2V apps, carrier-specific apps, etc.}

[0188] Access type: {AC0, AC1, AC2, AC3, AC4, AC5, AC6, AC7, AC8, AC9}

[0189] Special access types: {AC11, AC12, AC13, AC14, AC15)

[0190] Fig.19 is an example of access category configuration signaling, where each access category is represented as a tuple, and where each element of the tuple is an enumeration value of the components constituting the access category.

[0191] In an example, some access category components may be represented by a bitmap and other access category components may be represented by an enumeration structure. To configure the access category for the UE, the core network signals some access category components to the UE as a bitmap and other access categories to the UE using an enumeration structure.

[0192] In an example, to configure an access category for a UE, the radio access network (e.g., gNB) signals some access category components to the UE as a bitmap, while signaling some other access categories to the UE using an enumeration structure.

[0193] The core network may configure the access category for the UE via dedicated NAS control plane signaling. In an example, the core network configures the access category for the UE using NAS control plane signaling. The core network may configure the access category information for the UE during a mobility management procedure. Using LTE terminology, examples of mobility management procedures that may be used by the core network to configure the access category at the UE may be, for example, a tracking area update procedure, a UE attach or combined attach procedure, a detach and combined detach procedure, a service request procedure, transmission of NAS messages, or generic transmission of NAS messages. The control plane NAS signaling for access category configuration may be implemented via an access category management function (ACMF). Such a function may itself be part of other core network functions, such as the access and mobility management function (AMF) that is now being specified as part of the 5G core network architecture.

[0194] In the example, Fig. 20 and Fig.21 As shown in , the core network can configure the access category for the UE through dedicated NAS user plane signaling. In this case, the ACMF may be located in the user plane. Fig. 20 and Fig.21 As shown in , Nx can be a reference point between the UE and the access category management entity in the user plane for direct query via a pull mechanism (UE-initiated session) or a push mechanism (ACMF-initiated session). This can enable the access category information to be provided to the UE semi-statically or dynamically (relative to statically) to support access restriction control procedures related to 3GPP access and non-3GPP access. Communication through Nx can be secure communication. The Nx interface can be implemented above the IP level. In an example, ACMF can be a new network function of the core network. In another example, ACMF can be part of an already defined 5G core network function, such as an AMF (access and mobility management) function or a PCF (policy control function). ACMF can also be a function that is part of an access network discovery and selection function (ANDSF) element designated as part of the evolved packet core (EPC) network architecture, or an equivalent function in the 5G core network.

[0195] In an example, a radio access network (e.g., a gNB) configures an access category for a UE via dedicated RRC signaling. Using the LTE RRC procedure as a reference, the radio access network may signal the access category configuration information to the UE using one or more of the following RRC messages: RRCConnectionRelease message, RRCConnectionReconfiguration message. For example, in NR, a new RRCConnectionReconfiguration message with an RRCConnectionRelease code point intended to signal an RRCConnection release to the UE may be used to configure the access category configuration information for the UE. The access category stored in the USIM may be pre-provisioned to the UE.

[0196] In an example of an access category design based on access category components, the number of access category components that an access category may include is predefined or specified. Possibly, the number may be fixed. The order of the access category components within the arrangement of access category components to access categories may be predefined. For example, assuming that the access category components are represented by bitmaps, and the total number of access category components in the access category is specified or predefined as ten, the access category may be a larger bitmap including, for example, ten access category component bitmaps, wherein the position of each access category component bitmap in the access category bitmap is predefined (e.g., specified). For example, an access category may include, in order, access class, slice, application, OS, call type, traffic flow or packet flow, service data flow, QoS flow, QCI, subscription profile components, and their corresponding bitmaps in the access category may appear in that order, wherein the most significant bit of the access category bitmap will correspond to the access category, and the least significant bit of the access category bitmap may correspond to the subscription profile. This concept is described in detail in the text of the access category. Fig. 22 , where the most significant bit of access category X is bit b_0 of access component 1, and the least significant bit of access category X is bit b_kn of access component n. In the figure, the access category component "access component 1" has b_k1+1 bits, access component 1 has b_ki+1 bits, and access component n has b_kn+1 bits.

[0197] Similarly, assuming that the access category components are represented by an enumeration structure and the total number of access category components in the access category is specified or pre-defined as ten, the access category can be represented as 10 tuples of access category components represented by the enumeration structure, for example ({access class enumeration}, {slice enumeration}, {application enumeration}, {OS enumeration}, {call type enumeration}, {service flow or packet flow enumeration}, {service data flow enumeration}, {QoS flow enumeration}, {QCI enumeration}).

[0198] In one example, access category configuration signaling that is not based on an access category component is disclosed. Access category signaling may not assume the use of an access category component as a component of an access category. Instead, all possible combinations of attributes of an access category (e.g., access class, slice, application, OS, call type, traffic flow or packet flow, service data flow, QoS flow, QCI, subscription profile, etc.) may be enumerated and assigned access category values ​​or access category identifiers. The mapping between access category attribute combinations and access category values ​​may be predefined or specified. As described herein, a subset of possible combinations of access category attributes and associated access category values ​​may be specified in a standard, while the remaining set of possible combinations of access category attributes and associated access category values ​​is left to a deployment-specific configuration by a network operator. In other words, the possible combinations of access category attributes may be divided into two subgroups, one of which is specified in a standard as a default combination with an associated default access category value, while the configuration of a second group of combinations of access category attributes and associated access category values ​​is left to a deployment-specific configuration by a network operator. These second groups may be referred to herein as operator-defined access categories. The operator-defined access categories may be represented by a bitmap or by an enumeration structure. In one example, the core network may signal the access category configuration information (default access category and / or operator-defined access category) to the UE using NAS-dedicated control plane signaling. In another example, the core network may signal the access category configuration information (default access category and / or operator-defined access category) to the UE using NAS-dedicated user plane signaling. In another example, the radio access network (e.g., gNB) may configure the access category configuration information for the UE using RRC signaling. It should be noted that for operator-defined access categories, detailed information of the attributes of the access category may need to be configured for the UE. Subsequently, the network may optionally configure the access categories that the UE is allowed to use for the UE in the form of a bitmap, or in the form of an enumeration value or an access category identifier. For the default access categories, it is assumed that the detailed information of the attributes or components of these access categories are specified in the standard. As a result, the default access category that the UE is allowed to use may be configured for the UE only in the form of a bitmap or an enumeration value or an access category identifier.

[0199] In addition to or in lieu of an access class, an access identifier may be identified and / or sent for an access attempt. As described above, an access class may be defined based on one or more attributes, such as access category, slice, application, OS, call type, traffic flow or packet flow, service data flow, QoS flow, QCI, subscription profile (e.g., platinum, gold, silver, and bronze). Figure 5As shown in , the access category configuration may include one or more of these attributes, an AC value, and a subscription profile identifier (which may be equivalently represented as an access identifier). For example, an access identifier for an access attempt may include an indication that the UE is configured for mission-critical services, such as for use by first responders; or that the device is configured to monitor biometric information of a patient. It should be understood that in any examples herein where an access category is sent from one entity to another, or from one protocol layer within an entity to another, the access identifier may be sent along with the access category, or may be sent in place of the access category. The access identifier of an access attempt may be used additionally or alternatively to determine whether the access attempt is restricted.

[0200] A method and system for access restriction control parameter signaling are disclosed. A UE may perform an access restriction check based on an access restriction rate (or interchangeable access restriction factor) and an access restriction average time of a corresponding access category broadcast by a radio access network (RAN) (e.g., a gNB), or the UE may perform an access restriction check based on a Boolean access parameter of a corresponding access broadcast by the RAN, the Boolean access parameter indicating whether access is allowed or restricted for the access category. For example, in the case of an access restriction check based on an access restriction rate and an access restriction average time, the UE may draw a random number rand uniformly distributed between 0 and 1, e.g., 0≤rand<1. If 'rand' is less than the value indicated by the ac-BarringFactor included in the "AC restriction parameter", where AC represents the access category (not the access category), the UE considers that access to the cell is not restricted; otherwise, the UE considers that the cell is restricted for the duration of ac-BarringTime. If an access attempt is not allowed, then other access attempts of the same type may be restricted for a period of time calculated based on the average duration of access restrictions for the access class signaled to the UE and a random number rand drawn by the UE. The access restriction factor for an access class may be in the range [0, 1) and may take, for example, one of the following values: p00 = 0, p05 = 0.05, p10 = 0.10, ..., p95 = 0.95.

[0201] In case of performing access restriction check based on a Boolean access restriction parameter, if the Boolean access restriction parameter is set to 1, the UE may consider that access to the cell is restricted, otherwise, the UE considers that access to the cell is not restricted.

[0202] The signaling of access restriction parameters by the RAN (e.g., gNB) may be based on one or more of the following schemes:

[0203] signaling a partial list of access restriction parameters, including signaling an access category index;

[0204] Signaling a complete list of access restriction parameters, where access category information is signaled in the form of a bitmap; and / or

[0205] A combination of partial and complete lists of access restriction parameters are signaled.

[0206] In any of these methods, the radio access network (e.g., gNB) may configure access restriction parameters for the UE through RRC common signaling (e.g., system information broadcast signaling) or RRC dedicated signaling to support access control in RRC connected mode. Figure 23-Figure 28 Examples of signaling of access restriction control parameters are shown in . In any of these figures, the access restriction control parameter (access restriction rate, access restriction averaging time or Boolean access restriction parameter) may be signaled to the UE on a per PLMN basis, i.e., a single access restriction control parameter signaling message may carry access restriction parameters for more than one PLMN on a per PLMN basis, e.g. in case of network sharing.

[0207] Fig.23 and Fig.24 An example of access restriction parameter signaling is provided, where the network is broadcasting restriction parameters for a partial list containing m access categories (e.g., m is less than or equal to N) out of N available access categories in the network. In this example, it can be assumed that the core network has configured an access category set for the overall population of UEs, the access category set containing a number of access categories equal to or greater than m, but where potentially a number of n access categories are configured for each UE, where n is greater than or equal to 1 but less than N (e.g., see Fig.18 or Fig.19 ). For each access category that the core network has configured for the UE and for which the RAN (e.g., gNB) is broadcasting access restriction parameters, the UE may create an association between the access category and the corresponding access restriction parameters. In order for the UE to perform such an association, the radio access network (RAN) may broadcast a unique access category identifier along with the access restriction parameters for each of the m access categories.

[0208] Additionally or alternatively, the UE may implicitly derive a unique access category identifier for each access category for which access restriction parameters are being broadcast. For example, assume that the RAN (e.g., gNB) uses a data structure containing an array of size N, where N represents the total number of access categories available for access control in the network, including default access categories, special access categories, or operator-defined access categories. The UE may implicitly derive an access category unique identifier for each of the m access categories for which access restriction parameters are being broadcast by the RAN (e.g., gNB) as an index corresponding to the position of the access category in the array of size N (e.g., a bitmap). For example, referring to Fig.25 , the UE may implicitly derive the unique identifier of access category X as X (e.g., the unique identifier of access category X is the position of the access category in an array of size N, i.e., in this example, the Xth position in an array of size N (e.g., a bitmap)). For each access category that has been configured for the UE by the core network, if the restriction parameters for the access category are broadcast by the network, the UE stores the corresponding access restriction parameters in its internal database. The UE may use the stored and valid access restriction parameters to perform the access restriction check disclosed herein.

[0209] The validity of the access restriction parameters may be handled according to the validity of the corresponding system information block (SIB) validity rules. Fig.23 The example shown in FIG. 1 assumes that the access barring rate and the average access barring time are configured for the UE, and Fig.24 The examples in assume that access control for some access categories is based on access barring rate and access barring average time, while access control for some access categories is based on Boolean access control (e.g., access to a cell is allowed or not allowed). For example, for a default access category or special access categories (some of which may be specified in the standard), access control based on access control via Boolean parameters may be specified.

[0210] Fig.25 and Fig.26An example of access restriction parameter signaling is provided where the network is broadcasting access restriction parameters for a complete list of N available access categories in the network. For each of the n access categories that the core network has configured for the UE (as described above) and for which the RAN (e.g., gNB) is broadcasting access restriction parameters, the UE may create an association between the access category and the corresponding access restriction parameter. In order for the UE to perform such an association, the UE may implicitly derive a unique access category identifier for each access category for which the access restriction parameter is being broadcast. For example, assume that the RAN (e.g., gNB) uses a data structure containing an array of size N, where N represents the total number of access categories available for access control in the network, including default access categories, special access categories, or operator-defined access categories.

[0211] The UE may implicitly derive the access category unique identifier for each access category for which access restriction parameters are being broadcast by the RAN (e.g., gNB) as an index corresponding to the position of the access category in an array of size N (e.g., a bitmap). Fig.25 , the UE may implicitly derive the unique identifier of access category X as X (e.g., the unique identifier of access category X is the position of the access category in an array or bitmap of size N, i.e., the Xth position in the array or bitmap of size N in this example). Fig.25 The example shown in FIG. 1 assumes that the access barring rate and the average access barring time are configured for the UE, and Fig.26 The examples in assume that access control for some access categories is based on access barring rate and access barring average time, while access control for some access categories is based on Boolean access control (e.g., access to a cell is allowed or not allowed). For example, for a default access category or special access categories (some of which may be specified in the standard), access control based on access control via Boolean parameters may be specified.

[0212] For each access category that has been configured by the core network for the UE, if the restriction parameters for the access category are broadcast by the network, the UE may store the corresponding access restriction parameters in its internal database. The UE may use the stored and valid access restriction parameters to perform the access restriction check as described herein. The validity of the access restriction parameters may be processed according to the validity of the corresponding system information block (SIB) validity rules.

[0213] Fig. 27 and Fig.28The following example is shown, in which some access restriction parameters are signaled to the UE according to a partial signaling list scheme as described herein, while some access restriction parameters are signaled to the UE according to a complete signaling list scheme also as described herein. For example, the access categories may include default access categories (including special access categories) and operator-defined access categories. Some or all of the default access categories and their use for access control (e.g., access control based on access restriction rate and access restriction average time versus access control based on Boolean access restriction) may be specified in the standard, while the operator-defined access categories and their use for access control may be left to the operator to decide. For example, the total number of default access categories including special access categories may be k. In such a case, access restriction parameter signaling may be used in which the network broadcasts access restriction parameters for a complete list of available access categories, except that, in this case, the complete list of available access categories may be limited to the list specified in the standard or in the default access categories including the specified special access categories, which is specified in the standard. Fig.25 and Fig.26 The example case shown in includes k access categories.

[0214] The access restriction parameters may be signaled to the UE using the partial list signaling mechanism described herein. Fig. 27 or Fig.28 In the example shown in , the number m of access categories for which access restriction parameters are being signaled may be less than or equal to the total number of operator-defined access categories (Nc) available for access control in the network.

[0215] A method and system for access control of a UE in RRC_IDLE mode is disclosed. Fig.29 and Fig.30 The process shown in and further described below can be used to perform access control for a UE in RRC_IDLE (RRC idle) in response to an event within an upper layer of the UE above the access stratum (AS), thereby requiring the UE to initiate a NAS signaling connection to the core network, and therefore requiring the UE to perform access control before initiating a signaling connection to the network. The event in the upper layer requiring the UE to initiate a NAS signaling connection may include an event in the user plane (for example, if data becomes available for transmission), or an event in the control plane (such as a change in tracking area), thereby requiring the UE to perform a tracking area update. Due to these events, many NAS processes can be performed. Taking existing LTE technology as a reference, examples of 5G initial NAS messages that initiate the establishment of a NAS signaling connection may include, but are not limited to, the following: an attach request, a detach request, a tracking area update request, a service request, an extended service request, and a control plane service request.

[0216] In one example, a method for performing access control on a UE in RRC_IDLE mode may include: receiving access restriction information at an access stratum (AS) of a user equipment and from a radio access network (RAN); receiving an access trigger at a non-access stratum (NAS) of the user equipment, wherein the access trigger causes the user equipment to initiate an access attempt; determining, at the NAS of the user equipment, an access category associated with the access attempt of the user equipment; sending, from the NAS of the user equipment to the AS of the user equipment, a NAS message associated with the access attempt and an indication of the determined access category; determining, at the AS of the user equipment and based at least on the determined access category and the access restriction information, whether to restrict access attempts for the access category; and performing a radio resource control (RRC) connection establishment procedure based on determining that the access attempt is not restricted.

[0217] Receiving an access trigger may cause the NAS of the user equipment to generate a NAS message associated with the access attempt. The access category may be determined based on an access category configuration stored in a database of the user equipment. The method may further include: receiving the access category configuration at the NAS of the user equipment and from a core network node; and reconfiguring the functionality of the user equipment that supports one or more access control mechanisms at the NAS of the user equipment. The method may further include sending, by the AS of the user equipment to the NAS of the user equipment, an indication of whether to restrict the access attempt. The method may further include sending an access identifier associated with the access attempt from the NAS of the user equipment to the AS of the user equipment. Determining whether to restrict the access attempt may include determining whether to restrict the access attempt at the AS of the user equipment and based on the access identifier associated with the access attempt.

[0218] Fig.29 An example AS-CP solution is shown for NAS-CP events requiring access control in RRC_IDLE mode. Fig.29 The steps can be further described as follows:

[0219] In step 1, the UE obtains access restriction information sent by the RAN. The access restriction information may be signaled to the UE using the mechanism described herein.

[0220] In step 2, the access triggering event triggers the UE to perform a NAS process, which initiates an initial NAS message for establishing a NAS signaling connection. As described above, the access triggering event may be an event in the UE NAS user plane or an event in the UE NAS.

[0221] In step 3, the NAS-CP determines the access category for the NAS signaling connection according to the access category configuration procedure described in this document, and selects a valid access category from the access category configuration stored in the UE internal database.

[0222] In step 4, between the UE NAS-CP and the UE AS-CP, the NAS-CP provides the initial NAS message and the selected valid access category to the AS-CP in an appropriate inter-layer message, such as the RRC layer. In one example, an access identifier of the access attempt may also be provided.

[0223] In step 5, the AS-CP uses the access category and access restriction information received from the upper layer to determine whether to restrict the access attempt. In one example, an access identifier of the access attempt may be additionally or alternatively used to determine whether to restrict the access attempt.

[0224] The UE AS-CP notifies the NAS-CP of the result of the access restriction check in step 6. If the access is restricted, the process ends.

[0225] Otherwise, in step 7, the UE performs the RRC connection establishment procedure.

[0226] In step 8, the network may (re)configure the access category for the UE using the mechanisms described herein.

[0227] In step 9, the NAS / AS functions supporting access control (e.g., access control status check and access category determination) may be reconfigured based on the access category configuration. The AS / NAS may store the access category parameters as part of the QoS flow, bearer, or logical channel context. For access control solutions that require configuration of the AS-UP, the NAS-CP may signal the configuration parameters to the AS-CP (e.g., the RRC layer, which then configures the AS-UP). Additionally or alternatively, the NAS-CP may directly configure the AS-UP.

[0228] Fig.30 An example NAS-CP solution for NAS-CP events requiring access control in RRC-IDLE mode is shown. Fig.30 The process can be described as follows:

[0229] In step 1, the UE obtains access restriction information sent by the RAN, where the access restriction information may be signaled to the UE using the mechanism described herein.

[0230] In step 2, the AS-CP provides the acquired access restriction information to the NAS-CP. It should be noted that although the UE-AS automatically provides the access restriction information to the UE-NAS, the UE-NAS can also request the UE-AS to forward the access restriction information to the UE-NAS at any time. In addition, the UE AS-CP can forward the access restriction information to the NAS whenever there is an update of the access restriction information from the RAN.

[0231] In step 3, the access triggering event triggers the UE to perform a NAS procedure, which initiates an initial NAS message for establishing a NAS signaling connection. As described above, the access triggering event may be an event in the UE NAS user plane or an event in the UE NAS.

[0232] In step 4, the NAS-CP determines the access category for the specific NAS signaling connection according to the above access category configuration process, and selects a valid access category from the access category configuration stored in the UE internal database.

[0233] In step 5, NAS-CP uses the selected access category and the access restriction information received from UE AS to determine whether to restrict the access attempt. If the access is restricted, the process ends. Otherwise, the process will continue with the remaining steps.

[0234] In step 6, the UE NAS-CP sends an initial NAS message to the UE AS-CP.

[0235] In step 7, the UE AS CP performs an RRC connection establishment procedure.

[0236] In step 8, when the UE is in the RRC_CONNECTED state, the network may use the above mechanism to (re)configure the access category for the UE.

[0237] In step 9, the NAS / AS functions supporting access control (e.g., access control status check and access category determination) may be reconfigured based on the access category configuration. The AS / NAS may store the access category parameters as part of the QoS flow, bearer, or logical channel context. For access control solutions that require configuration of the AS-UP, the NAS-CP may signal the configuration parameters to the AS-CP (e.g., the RRC layer, which then configures the AS-UP). Additionally or alternatively, the NAS-CP may directly configure the AS-UP.

[0238] A method and system for access control of a UE in RRC_INACTIVE and RRC_CONNECTED states are disclosed. The AS-UP may perform one or more of the following functions to support access control: access control state check, determination of access category, access restriction check. Which AS-UP sublayer performs these functions may depend on the level of granularity at which access control is performed (e.g., QoS flow, bearer, or logical channel). For example, if access control is performed at the granularity of a QoS flow, the access control function may target the SDAP sublayer. Additionally or alternatively, if access control is performed at the granularity of a bearer or logical channel, the access control function may target the MAC sublayer. If access control is performed at a bearer level granularity, access control in the AS-UP may be performed at the PDCP sublayer. If access control is performed at a logical channel level granularity, access control may be performed at the RLC sublayer.

[0239] Fig.31 An example method for AS-UP events requiring access control in RRC_INACTIVE and RRC CONNECTED states is shown.

[0240] In step 1, the UE may obtain access restriction information sent by the RAN, where the access restriction information may be signaled to the UE using the mechanism described herein. Note that the access restriction information may actually be obtained via the AS-CP (eg, RRC layer) and provided to the AS-UP.

[0241] In step 2, UL data may be sent from the UE NAS UP to the AS via the UP. The UE NAS UP may also provide the UE AS with an access category used by the UE AS for data transmission. The UE NAS-UP may determine the access category of the new data packet. For example, the UE NAS-UP may determine the access category from the access categories configured for the UE using one or more attributes associated with the data packet described herein (e.g., QoS flow ID, QCI, application ID, SDF, packet flow, etc.).

[0242] In step 3, additionally or alternatively, the UE AS-UP may determine the access category of the new data packet. The access category determination may be based on the QoS flow, or bearer or logical channel to which the new data packet is mapped. For example, the UE AS-UP may determine the access category from the access categories configured for the UE using the QoS flow ID or QCI associated with the new data packet.

[0243] In step 4, the AS-UP may check the access restriction state for the received packet in its internal database to determine whether the access restriction state (e.g., access is restricted or access is not restricted) has been stored in its internal database for the received packet. Depending on the level of granularity at which access control is performed, the check may be based on a QoS flow ID (QFI), a bearer ID, or a QCI or a logical channel ID. For example, in order to perform access control at the granularity of a QoS flow, the UE AS-UP may check whether an access restriction state (e.g., access is allowed or not allowed) has been stored in the UE internal database for the packet received from the upper layer based on the QFI in the packet header and the access category selected by the UE in step 3. Similarly, in order to perform access control at the granularity of a bearer or logical channel, the UE AS-UP may check whether an access restriction state (e.g., access is allowed or not allowed) has been stored in the UE internal database using the access category selected in step 3 and the DRB ID or logical channel ID of the data packet. If there is no access restriction state in the UE internal database for the data packet, or the stored access restriction state is no longer valid, the UE may proceed to step 5 to perform access restriction determination; otherwise, steps 5 and 6 may be skipped.

[0244] In step 5, the AS-UP may use the selected access category and the access restriction information to determine whether access is restricted or access is allowed. The UE may update its internal database with the result of the access control (e.g., access is restricted or access is not restricted) for the corresponding access category and the corresponding QoS flow ID or DRB ID or logical channel ID selected in step 3, according to the granularity level of the access restriction. The UE may be notified of changes in the access restriction information by dedicated signaling. If the UE is in an RRC inactive state, the UE may be notified via a paging message including an access restriction modification IE. Additionally or alternatively, the UE may monitor the SI for a flag (e.g., systemInfoValueTag) indicating whether a change has occurred in the SI message, and then reacquire the SI when a change has occurred. As a result of subsequent changes to the access restriction information received from the RAN, the UE may update the access restriction status in its internal database.

[0245] In step 6, the AS-UP may notify the NAS-CP of the result of the access restriction check. If access is restricted, the process ends. Otherwise, the UE performs the remaining steps of the process.

[0246] In step 7, if the UE is in RRC_INACTIVE state, or if the UE is in RRC_CONNECTED state and the UL is not time aligned, or if the UE needs to send an SR and PUCCH resources are not available, the UE may perform a random access procedure.

[0247] In step 8, if the UE is in the RRC_INACTIVE state, the UE may perform an RRC connection recovery procedure.

[0248] At step 9, UL data for the QoS flow / bearer / logical channel may be sent to the network.

[0249] Fig.32 An example method for NAS-UP events requiring access control in RRC_INACTIVE and RRC_CONNECTED states is shown.

[0250] In step 1, the UE may obtain access restriction information sent by the RAN, wherein the access restriction information may be signaled to the UE using the above-mentioned mechanism.

[0251] In step 2, the AS-CP may provide the acquired access restriction information to the NAS-CP.

[0252] In step 3, the NAS-CP may provide the acquired access restriction information to the NAS-UP.

[0253] In step 4, the UE NAS UP may receive data for UL transmission.

[0254] In step 5, the UE NAS-UP may determine the access category of the new data packet. For example, the UE NAS-UP may determine the access category from the access categories configured for the UE using one or more attributes associated with the data packet described herein (e.g., QoS flow ID, QCI, application ID, SDF, packet flow, etc.).

[0255] In step 6, the NAS-UP may check the access restriction state for the received data packet in its internal database to determine whether the access restriction state (e.g., access is restricted or access is not restricted) has been stored in its internal database for the received data packet. Depending on the level of granularity at which access control is performed, the access state restriction check may be based on QoS flow ID, SDF, packet flow, QCI, application ID, etc. For example, in order to perform access control at the granularity of QoS flow, the UE NAS-UP may check whether there is an access restriction state (e.g., access is allowed or not allowed) already stored in the UE internal database for the packet received from the upper layer based on the QFI in the packet header and the access category selected by the UE in step 5. Similarly, in order to perform access control at the granularity of SDF, packet flow, QCI, or application ID, the UE NAS-UP may check whether there is an access restriction state (e.g., access is allowed or not allowed) already stored in the UE internal database using the access category selected in step 5 and the corresponding access category attribute of the data packet. If there is no access restriction state in the UE internal database for the data packet, or the stored access restriction state is no longer valid, the UE may proceed to steps 7 and 8 to perform access restriction determination as described herein; otherwise, steps 7 and 8 may be skipped.

[0256] In step 7, NAS-UP may use the selected access category and the received access restriction information to determine whether access is restricted or access is allowed. The UE may update its internal database with the result of the access control (e.g., access is restricted or access is not restricted) for the corresponding access category selected in step 5 and the corresponding QoS flow ID, SDF, packet flow, QCI, application ID, etc., according to the level of granularity of the access restriction. Changes in access restriction information may be signaled to the UE via dedicated signaling. If the UE is in an RRC inactive state, the UE may be notified via a paging message including an access restriction modification IE. Additionally or alternatively, the UE may monitor the SI for a flag (e.g., systemInfoValueTag) indicating whether a change has occurred in the SI message, and then reacquire the SI if a change has occurred. As a result of subsequent changes to the access restriction information received from the RAN, the UE may update the access restriction status in its internal database.

[0257] In step 8, the UE NAS-UP may notify the NAS-CP of the result of the access restriction check. If access is restricted, the process may end. Otherwise, the UE may perform the remaining steps of the process.

[0258] In step 9, UL data may be sent from the NAS to the AS via the UP.

[0259] In step 10, if the UE is in the RRC_INACTIVE state, or if the UE is in the RRC_CONNECTED state and the UL is not time aligned, or if the UE needs to send an SR and PUCCH resources are not available, the UE may perform a random access procedure.

[0260] In step 11, if the UE is in the RRC_INACTIVE state, the UE may perform an RRC connection recovery procedure.

[0261] At step 12, UL data for the specific access may be sent to the network.

[0262] In one example, a method for performing access control in an AS-CP for a NAS-CP event requiring access control in an RRC_INACTIVE (RRC inactive) and RRC_CONNECTED (RRC connected) state is disclosed. The method may include: receiving access restriction information at an access stratum (AS) of a user device and from a radio access network (RAN); receiving a trigger associated with an event requiring access control at a non-access stratum (NAS) of the user device; determining, at the NAS of the user device, an access category associated with the event requiring access control; sending an indication of the determined access category from the NAS of the user device to the AS of the user device; determining, at the AS of the user device, whether the access restriction state associated with the event requiring access control is stored in an internal database of the user device; determining, at the AS of the user device and based at least on the indication of the determined access category and the access restriction information, whether an access attempt for the access category associated with the event requiring access control is restricted; and sending an indication of whether an access attempt for the access category associated with the event requiring access control is restricted to the NAS of the user device.

[0263] A trigger associated with an event requiring access control may include an indication that data is available for the user equipment to send. The access category may be determined based on an access category configuration stored in a database of the user equipment. The method may further include determining that an access restriction state associated with an event requiring access control is not stored in an internal database of the user equipment. The method may further include updating an internal database of the user equipment to indicate an access restriction state associated with an event requiring access control. The method may further include sending an access identifier associated with an access attempt from the NAS of the user equipment to the AS of the user equipment. Determining whether an access attempt for an access category associated with an event requiring access control is restricted may include: determining, at the AS of the user equipment and based on the access identifier, whether an access attempt for an access category associated with an event requiring access control is restricted.

[0264] Fig.33 The procedures shown in FIG. 4 can be used to perform access control in the AS-CP for NAS-CP events that require access control in the RRC_INACTIVE and RRC_CONNECTED states.

[0265] In step 1, the UE may obtain access restriction information sent by the RAN. The access restriction information may be signaled to the UE using the above mechanism.

[0266] In step 2, the NAS-CP may receive a trigger for an event requiring access control. Such an event may be an event from the NAS-UP, such as when data becomes available for transmission, such as when the UE connects to a different network slice than the current one.

[0267] In step 3, the NAS-CP may determine the access category for the specific access. For example, the UE NAS-CP may use one or more of the above attributes (e.g., QoS flow ID, QCI, application ID, SDF, packet flow, etc.) to select a valid access category from the access categories configured for the UE.

[0268] At step 4, the NAS-CP may provide the selected valid access category to the AS-CP (eg, RRC layer, in an appropriate inter-layer message) between the UE NAS-CP and the UE AS-CP. In one example, an access identifier may also be provided.

[0269] In step 5, the UE AS-CP may check the access restriction status in its internal database to determine whether the access restriction status (e.g., access is restricted or access is not restricted) has been stored in its internal database for the selected access category. For example, depending on the level of granularity at which access control is performed, the check may be based on a QoS flow ID (QFI), a bearer ID or a QCI or a logical channel ID. For example, in order to perform access control at the granularity of a QoS flow, the UE AS-CP may check whether there is an access restriction status (e.g., access is allowed or not allowed) already stored in the UE internal database based on the QFI and the access category selected by the UE in step 3. Similarly, in order to perform access control at the granularity of a bearer or a QCI or a logical channel, the UE AS-CP may check whether there is an access restriction status (e.g., access is allowed or not allowed) already stored in the UE internal database using the access category selected in step 3 and the DRB ID or QCI or the logical channel ID to which the data packet to be sent is mapped. If there is no access restriction state in the UE internal database for the data packet, or the stored access restriction state is no longer valid, the UE may proceed to steps 6 and 7 to perform access restriction determination as described herein; otherwise, steps 6 and 7 may be skipped.

[0270] In step 6, the UE AS-CP (e.g., RRC) may use the selected access category and the access restriction information to determine whether access is restricted or access is allowed. The UE may update its internal database with the result of the access control (e.g., access is restricted or access is not restricted) for the corresponding access category and the corresponding QoS flow ID or DRB ID or logical channel ID selected in step 3, according to the granularity level of the access restriction. The UE may be notified of changes in the access restriction information by dedicated signaling. If the UE is in an RRC inactive state, the UE may be notified via a paging message including an access restriction modification IE. Additionally or alternatively, the UE may monitor the SI for a flag (e.g., systemInfoValueTag) indicating whether a change has occurred in the SI message, and then reacquire the SI when a change has occurred. As a result of subsequent changes to the access restriction information received from the RAN, the UE may update the access restriction status in its internal database. In one example, an access identifier may be used additionally or alternatively to determine whether to restrict an access attempt.

[0271] In step 7, the AS-CP may inform the NAS-CP of the result of the access restriction check. If access is restricted, the NAS-CP may optionally forward the access restriction check result to the NAS-UP. If access is restricted, the process may end. Otherwise, the UE may perform the remaining steps of the process.

[0272] In step 8, if the UE is in RRC_INACTIVE state, or if the UE is in RRC_CONNECTED state and the UL is not time aligned, or if the UE needs to send an SR and PUCCH resources are not available, the UE may perform a random access procedure.

[0273] In step 9, if the UE is in the RRC_INACTIVE state, the UE may perform an RRC connection recovery procedure.

[0274] At step 10, UL data for the specific access may be sent to the network.

[0275] Fig.34 An example AS-CP solution is shown for AS-CP events requiring access control in RRC_INACTIVE and RRC_CONNECTED states.

[0276] In step 1, the UE may obtain access restriction information sent by the RAN. The access restriction information may be signaled to the UE using the mechanism described herein.

[0277] In step 2, the UE may perform an AS procedure requiring network access.

[0278] In step 3, the UE AS-CP may determine the access category. The access category determination may be based on the QoS flow or QCI. For example, the UE AS-UP may determine the access category from the access categories configured for the UE using the QoS flow ID or QCI associated with the new data packet.

[0279] In step 4, the UE AS-CP (e.g., RRC) may use the selected access category and the access restriction information to determine whether access is restricted or access is allowed. The UE may update its internal database with the result of the access control (e.g., access is restricted or access is not restricted) for the corresponding access category and the corresponding QoS flow ID or DRB ID or logical channel ID selected in step 3, according to the level of granularity of the access restriction. The UE may be notified of changes in access restriction information by dedicated signaling. If the UE is in an RRC inactive state, the UE may be notified via a paging message including an access restriction modification IE. Additionally or alternatively, the UE may monitor the SI for a flag (e.g., systemInfoValueTag) indicating whether a change has occurred in the SI message, and then reacquire the SI when a change has occurred. As a result of subsequent changes to the access restriction information received from the RAN, the UE may update the access restriction status in its internal database.

[0280] In step 5, the UE AS-CP (e.g., RRC) may use the selected access category and the access restriction information to determine whether access is restricted or access is allowed. The UE may update its internal database with the result of the access control (e.g., access is restricted or access is not restricted) for the corresponding access category and the corresponding QoS flow ID or DRB ID or logical channel ID selected in step 3, according to the level of granularity of the access restriction. The UE may be notified of changes in the access restriction information by dedicated signaling. If the UE is in an RRC inactive state, the UE may be notified via a paging message including an access restriction modification IE. Additionally or alternatively, the UE may monitor the SI for a flag (e.g., systemInfoValueTag) indicating whether a change has occurred in the SI message, and then reacquire the SI when a change has occurred. As a result of subsequent changes to the access restriction information received from the RAN, the UE may update the access restriction status in its internal database.

[0281] In step 6, the AS-CP may notify the NAS-CP of the result of the access restriction check. If the access is restricted, the process ends. Otherwise, the UE may perform the remaining steps of the process.

[0282] At step 7, if the UE is in RRC_INACTIVE state, or if the UE is in RRC_CONNECTED state and the UL is not time aligned, or if the UE needs to send an SR and PUCCH resources are not available, the UE may perform a random access procedure.

[0283] In step 8, if the UE is in the RRC_INACTIVE state, the UE may perform an RRC connection recovery procedure.

[0284] At step 9, UL data for this specific access may be sent to the network.

[0285] Fig.35 An example AS-CP solution is shown for AS-UP events requiring access control in RRC_INACTIVE and RRC_CONNECTED states.

[0286] In step 1, the UE may obtain access restriction information sent by the RAN. The access restriction information may be signaled to the UE using the mechanism described herein.

[0287] In step 2, UL data may be sent from the NAS to the AS via the UP.

[0288] In step 3, the AS-CP may determine the access category of the new QoS flow / bearer / logical channel. The access category may be determined according to the access category configuration.

[0289] In step 4, the AS-UP may perform checks on packets that may require access control. Depending on the level of granularity at which access control is performed, the check may be based on a QoS flow ID (QFI), a bearer ID, or a logical channel ID. For example, to perform access control at the granularity of a QoS flow, the AS-UP may check whether the QFI in the packet header has a corresponding QFI to DRB mapping in the AS mapping table for the corresponding PDU session. Additionally or alternatively, to perform access control at the granularity of a bearer or logical channel, the AS-UP may compare the bearer / logical channel ID in the packet header with the bearer / logical channel ID stored as part of the bearer / logical channel context. If a new QoS flow / bearer / logical channel is detected, the UE may proceed to steps 4-7 to perform access control; otherwise, these steps may be skipped. If the access restriction information of the corresponding QoS flow / bearer / logical channel has changed since the access restriction check was performed, access control may also be performed on packets corresponding to the QoS flow / bearer / logical channel to which access has been granted. The UE may be notified of changes in access restriction information explicitly (e.g., via a paging message including an access restriction modification IE). Additionally or alternatively, the UE may monitor the SI for a flag (e.g., systemInfoValueTag) indicating whether a change has occurred in the SI message, and then reacquire the SI if a change has occurred. The state (e.g., changed / unchanged) of the access restriction information associated with a QoS flow / bearer / logical channel may be stored in a QoS flow, bearer or logical channel context, an AS mapping table, or a separate database / data structure.

[0290] An indication including packet information that can be used to determine the access category may be sent to the AS-CP at step 5. For example, the packet information may include a QFI, a bearer ID, or a logical channel ID found in a packet header, depending on the level of granularity at which access control is performed.

[0291] In step 6, the AS-CP may use the determined access category and the access restriction information to determine whether to restrict access attempts associated with the new QoS flow / bearer / logical channel.

[0292] In step 7, the AS-CP may inform the AS-UP and NAS-CP of the result of the access restriction check. The AS-UP may store the result of the access restriction check as part of the QoS flow, bearer or logical channel context. If access is restricted, the process may end. Otherwise, the UE may perform the remaining steps of the process.

[0293] At step 8, if the UE is in RRC_INACTIVE state, or if the UE is in RRC_CONNECTED state and the UL is not time aligned, or if the UE needs to send an SR and PUCCH resources are not available, the UE may perform a random access procedure.

[0294] In step 9, if the UE is in the RRC_INACTIVE state, the UE may perform an RRC connection recovery procedure.

[0295] At step 10, UL data for the new QoS flow / bearer / logical channel may be sent to the network.

[0296] Fig.36 An example AS-CP solution is shown for NAS-UP events requiring access control in RRC_INACTIVE and RRC_CONNECTED states.

[0297] In step 1, the UE may obtain access restriction information sent by the RAN. The access restriction information may be signaled to the UE using the mechanism described herein.

[0298] In step 2, UL data may be received via NAS UP.

[0299] In step 3, the NAS-UP may determine the access category and perform checks on packets that may require access control. For example, in order to perform access control at the granularity of a QoS flow, the NAS-UP may check whether the QFI in the packet header has a corresponding QFI to DRB mapping in the AS mapping table for the corresponding PDU session. If a new QoS flow is detected, the UE may proceed to steps 3-8 to perform access control; otherwise, these steps may be skipped. If the access restriction information of the corresponding QoS flow / bearer / logical channel has changed since the access restriction check was performed, access control may also be performed on packets corresponding to the QoS flow / bearer / logical channel to which access has been granted. The UE may be notified of changes in access restriction information explicitly (e.g., via a paging message including an access restriction modification IE). Additionally or alternatively, the UE may monitor the SI for a flag (e.g., systemInfoValueTag) indicating whether a change has occurred in the SI message, and then reacquire the SI when a change has occurred. The status (e.g., changed / unchanged) of the access restriction information associated with a QoS flow / bearer / logical channel may be stored in the QoS flow, bearer or logical channel context, the AS mapping table, or a separate database / data structure.

[0300] In step 4, an indication including packet information that can be used to determine the access category may be sent to the NAS-CP. For example, if access control is performed at the granularity of QoS flows, the packet information may include the QFI.

[0301] In step 5, the NAS-CP may determine the access class for the particular access. The access class may be determined according to an access class configuration, which may be based on access class components.

[0302] In step 6, the NAS-CP may provide the determined access category to the AS-CP (eg, RRC layer). In one example, an access identifier may also be provided.

[0303] In step 7, the AS-CP may use the determined access category and the access restriction information to determine whether to restrict the access attempt. In one example, the access identifier may be additionally or alternatively used to determine whether to restrict the access attempt.

[0304] In step 8, the AS-CP may notify the NAS-CP of the result of the access restriction check. If the access is restricted, the process may end. Otherwise, the UE may perform the remaining steps of the process.

[0305] In step 9, UL data may be sent from the NAS to the AS via the UP.

[0306] In step 10, if the UE is in the RRC_INACTIVE state, or if the UE is in the RRC_CONNECTED state and the UL is not time aligned, or if the UE needs to send an SR and PUCCH resources are not available, the UE may perform a random access procedure.

[0307] In step 11, if the UE is in the RRC_INACTIVE state, the UE may perform an RRC connection recovery procedure.

[0308] At step 12, UL data for the specific access may be sent to the network.

[0309] Fig.37 An example NAS-CP solution is shown for NAS-CP events requiring access control in RRC_CONNECTED and RRC_INACTIVE states. Such events may include, but are not limited to, the execution of NAS procedures using initial NAS messages, where the initial NAS message set may include, but is not limited to, the following: Attach Request, Detach Request, Tracking Area Update Request, Service Request, Extended Service Request, and Control Plane Service Request.

[0310] In step 1, the UE may obtain access restriction information sent by the RAN, wherein the access restriction information may be signaled to the UE using the mechanism described herein.

[0311] In step 2, the AS-CP may provide the acquired access restriction information to the NAS-CP.

[0312] In step 3, the NAS-CP may receive a trigger for an event requiring access control.

[0313] In step 4, the NAS-CP may determine the access class for this particular access. Depending on the level of granularity at which access control is performed, the access class may be associated with a new / modified QoS flow, bearer, or logical channel. The access class may be determined based on an access class configuration, which may be based on access class components.

[0314] In step 5, the NAS-CP may use the determined access class and the access restriction information to determine whether to restrict access attempts for a specific access class. If access is restricted, the process may end. Otherwise, the UE may perform the remaining steps of the process.

[0315] In step 6, if the UE is in RRC_INACTIVE state, or if the UE is in RRC_CONNECTED state and the UL is not time aligned, or if the UE needs to send an SR and PUCCH resources are not available, the UE may perform a random access procedure.

[0316] In step 7, if the UE is in the RRC_INACTIVE state, the UE may perform an RRC connection recovery procedure.

[0317] In step 8, UL data for this specific access may be sent to the network.

[0318] Fig.38 An example NAS-CP solution is shown for NAS-UP events requiring access control in RRC_INACTIVE and RRC_CONNECTED states.

[0319] In step 1, the UE may obtain access restriction information sent by the RAN, where the access restriction information may be signaled to the UE using the mechanism described herein.

[0320] In step 2, the AS-CP may provide the acquired access restriction information to the NAS-CP.

[0321] In step 3, the NAS-CP may provide the acquired access restriction information to the NAS-UP.

[0322] In step 4, UL data may be received via the NAS UP.

[0323] In step 5, the NAS-UP may determine the access category and perform checks on packets that may require access control. For example, in order to perform access control at the granularity of a QoS flow, the NAS-UP may check whether the QFI in the packet header has a corresponding QFI to DRB mapping in the AS mapping table for the corresponding PDU session. If a new QoS flow is detected, the UE may proceed to steps 6-9 to perform access control; otherwise, these steps may be skipped. If the access restriction information of the corresponding QoS flow / bearer / logical channel has changed since the access restriction check was performed, access control may also be performed on packets corresponding to the QoS flow / bearer / logical channel to which access has been granted. The UE may be notified of changes in access restriction information explicitly (e.g., via a paging message including an access restriction modification IE). Additionally or alternatively, the UE may monitor the SI for a flag (e.g., systemInfoValueTag) indicating whether a change has occurred in the SI message, and then reacquire the SI if a change has occurred. The status (e.g., changed / unchanged) of the access restriction information associated with a QoS flow / bearer / logical channel may be stored in the QoS flow, bearer or logical channel context, the AS mapping table, or a separate database / data structure.

[0324] In step 6, an indication including packet information that can be used to determine the access category is sent to the NAS-CP. For example, if access control is performed at the granularity of QoS flows, the packet information may include the QFI.

[0325] In step 7, the NAS-CP may determine the access class for the particular access. The access class may be determined according to an access class configuration, which may be based on access class components.

[0326] In step 8, the NAS-CP may use the determined access class and the access restriction information to determine whether to restrict access attempts for a specific access class.

[0327] In step 9, an indication may be sent to the NAS-UP to indicate the result of the access restriction check.

[0328] At step 10, UL data may be sent from the NAS to the AS via the UP.

[0329] In step 11, if the UE is in the RRC_INACTIVE state, or if the UE is in the RRC_CONNECTED state and the UL is not time aligned, or if the UE needs to send an SR and PUCCH resources are not available, the UE may perform a random access procedure.

[0330] In step 12, if the UE is in the RRC_INACTIVE state, the UE may perform an RRC connection recovery procedure.

[0331] At step 13, UL data for the specific access may be sent to the network.

[0332] Fig.39 An example AS solution for UP events requiring access control in the RRC_CONNECTED state is shown. Fig.39 The process shown in can be used to perform access control in the AS for AS-UP events (eg, UE-initiated UL QoS flows).

[0333] Fig.40 An example NAS solution for UP events requiring access control in the RRC_CONNECTED state is shown. Fig.40 The process shown in can be used to perform access control in NAS for NAS-UP events (eg, UE-initiated UL QoS flows).

[0334] When access control blocks UL data transmission, the UE may not include such data in the calculation of the amount of data available for transmission for the purpose of buffer status reporting. In one example, the UE may be configured by the network to apply such constraints at the following granularity levels: logical channel level, logical channel group level, or bearer level. The UE may also be configured by the network to apply such constraints at the service data flow level, specific service flow level, or IP flow level. When a buffer status report (BSR) constraint is placed on a logical channel or logical channel group due to an access restriction check, the UE may cancel the associated periodic BSR timer (periodicBSR-Timer), retransmit BSR timer (retxBSR-Timer). Additionally or alternatively, the UE may cancel the associated logical channel scheduling request prohibit timer (logicalChannelSR-ProhibitTimer). Similarly, when access control blocks UL data transmission, as a result of such UL data, or for the purpose of sending a BSR associated with such UL data, the UE may not send a scheduling request.

[0335] If the UE marks a logical channel or a logical channel group as constrained after the access control restriction check, the MAC may not consider these constrained logical channels during the logical channel prioritization process. As described herein, the access category configuration may be defined at the granularity level of attributes (e.g., network slices, applications, business flows or packet flows, service data flows, QoS flows, QCI). The current 5G QoS framework requires the access layer to map QoS flows to data radio bearers (DRBs), and requires NAS to map IP packet flows or other data packet flows (including non-IP packet flows) to QoS flows. In the case of data replication, DRBs may be mapped to one logical channel or more than one logical channel. The UE AS may perform mapping of access categories to logical channels or logical channel groups. For example, the UE may create an association between a logical access category and a logical channel, and when the access category mapped to the logical channel is restricted, the logical channel may be constrained to send data. The UE may use the derived mapping of access categories to logical channels or logical channel groups to establish logical channel constraints or logical channel group constraints.

[0336] A method and system for access restriction are disclosed. When data transmission is constrained due to access control, there is a risk of buffer accumulation and possible buffer overflow in both the AS and the NAS. The UE AS may send an indication to the UE NAS to notify the NAS of the access restriction. The indication may carry the restricted access category and may carry an explicit indication of the granularity level of the access restriction, such as network slice, application, business flow or packet flow, service data flow, QoS flow, QCI. Upon access restriction, the US AS and US NAS may release their respective constrained data buffers. The NAS may also send an indication to the layer above the NAS (referred to herein as the application layer) intended to constrain the transmission of restricted services. Similarly, if access restriction checks are implemented in the NAS, the NAS may avoid forwarding restricted services to the AS and may clear its buffers from any restricted services. In addition, the NAS may send an indication to the layer above the NAS intended to constrain the transmission of restricted services.

[0337] A method and system for access restriction are disclosed. The access restriction procedure may be performed in an access layer (eg, RRC) of a UE, and a call or signaling initiation triggering the access restriction check may be performed in an upper layer (eg, NAS) above the UE AS.

[0338] exist Fig.41A and Fig.41BAn example process for initiating access restriction is shown in . SystemInformationBlockType2 may represent a system information block carrying access restriction parameters broadcast by the RAN (e.g., a gNB), and ac-BarringPerPLMN-List may represent a data structure within SystemInformationBlockType2 that contains AC-BarringPerPLMN entries or access category restriction parameters (e.g., ac-BarringInfo for each PLMN) for each PLMN served by the RAN.

[0339] Fig.42 and Fig.43 An example of access restriction information in a system information block (e.g., SystemInformationBlockType2) is shown in FIG.

[0340] In another example, Fig.44A and Fig.44B An example process for access restriction checking is shown in Note that the ac-Boolean access restriction parameter may be configured for access categories defined for emergency applications (eg, emergency calls), or mission-critical or time-critical applications (eg, URLLC applications).

[0341] When access barring is controlled by the RAN (e.g., gNB) based on an access barring rate (e.g., access barring factor), an access barring timer may be used to control how long the UE may wait before another access reattempt. Differentiated timers for different purposes may be specified as the access barring timer Tbarring used in the description of the access barring check function described herein. At a minimum, a timer may be specified for access attempts due to mobile originated signaling, and a separate timer may be specified for access attempts due to mobile originated applications (e.g., mobile originated calls). T MOSignalling and T MOCall The timers used as Tbarring for access attempts due to mobile originated signaling and mobile originated applications (e.g., mobile originated calls), respectively. Each of these types of timers can be further differentiated into different timers. For example, the following T MOCall Timer:

[0342] T MOURLLC , used for mission-critical URLLC application type calls;

[0343] T MOeMBB , for calls of eMBB application type; and

[0344] T MOmMTC, used for calls of mMTC application type.

[0345] Similarly, T MOSignalling It can be further differentiated into different timers to provide differentiated treatment for mobile originated signaling restrictions based on the requirements of the signaling use cases and scenarios.

[0346] Fig.45A and Fig.45B Example actions at the UE when the access restriction timer expires are shown.

[0347] The definition and usage of the timers disclosed in this article can be defined in the following example table:

[0348]

[0349]

[0350]

[0351] Fig.46 An example user screen for access display and selection is shown. Nw can represent the number of available access categories from which the user can select, and Nr can represent the number of available access categories displayed to the user as read-only. The list of access categories from which the user can select can include operator-defined access categories. Operator-defined access categories can include special access categories or wild card access categories defined by the operator. For any given application, the user can select or negotiate with the network a corresponding access category, but pay an appropriate usage fee for the selected access category. The operator can define and assign a default access category for each application. The access category selected by the user (if accepted by the network) can override the default access category assigned by the network.

[0352] The following is a list of acronyms that may be referenced in the detailed description above. Unless otherwise stated, the acronyms used in this article refer to the corresponding terms listed below:

[0353] 5G Fifth Generation

[0354] 3GPP Third Generation Partnership Project

[0355] AC Access Category

[0356] ACB access type restrictions

[0357] ACDC Application Specific Data Communications Congestion Control

[0358] ACMF Access Category Management Function

[0359] AMF Access and Mobility Management Function

[0360] AN Access Network

[0361] ANDSF Access Network Discovery and Selection Function

[0362] Apps

[0363] AS Access Layer

[0364] BSSID Basic SSID

[0365] BSR Buffer Status Report

[0366] CI Cell Identifier

[0367] CN Core Network

[0368] CP Control Plane

[0369] CSFB Circuit Switched Fallback

[0370] DL Downlink

[0371] DM Device Management

[0372] DRB Data Radio Bearer

[0373] EAB Extended Access Limit

[0374] eMBB Enhanced Mobile Broadband

[0375] eNB Evolved Node B

[0376] EHPLMN Equivalent HPLMN

[0377] ESS Extended Service Set

[0378] EUTRA Evolved Universal Terrestrial Radio Access

[0379] FDD Frequency Division Duplex

[0380] gNB: gNode B

[0381] HESSID Homogeneous ESS ID

[0382] HPLMN belongs to PLMN

[0383] ID or Id Identifier

[0384] IMSI International Mobile Subscriber Identity

[0385] IMT International Mobile Telecommunications

[0386] IP Internet Protocol

[0387] LTE Long Term Evolution

[0388] MAC Media Access Control

[0389] MCC Mobile Country Code

[0390] MO Management Object

[0391] MTC Machine Type Communication

[0392] mMTC massive machine type communication

[0393] OMA Open Mobile Alliance

[0394] NAS Non-Access Stratum

[0395] NGC Next Generation Core Network

[0396] NR New Radio

[0397] OS Operating System

[0398] PCF Policy Control Function

[0399] PDU Packet Data Unit

[0400] PHY Physical Layer

[0401] PLMN Public Land Mobile Network

[0402] PUCCH Physical Uplink Control Channel

[0403] QCI QoS Category Identifier

[0404] QFI QoS Flow Identifier

[0405] QoS Quality of Service

[0406] RAN Radio Access Network

[0407] RAT Radio Access Technology

[0408] RRC Radio Resource Control

[0409] SDF Service Data Flow

[0410] SIB System Information Block

[0411] SIM Subscriber Identity Module

[0412] SPID User Profile ID

[0413] SR Scheduling Request

[0414] SSAC Service-Specific Access Control

[0415] SSID Service Set ID

[0416] TAC Tracking Area Code

[0417] TCP Transmission Control Protocol

[0418] TDD Time Division Duplex

[0419] TRP Send and Receive Points

[0420] Tx Transmitter

[0421] UDP User Datagram Protocol

[0422] UE User Equipment

[0423] UL Uplink

[0424] UP User Plane

[0425] USIM Universal SIM Card

[0426] URLLC Ultra-Reliable and Low-Latency Communications

[0427] ViLTE LTE Video

[0428] VoLTE Voice over LTE

[0429] WLAN Wireless Local Area Network

[0430] This written description uses examples to disclose the invention (including the best mode) and also enables those skilled in the art to practice the invention (including making and using any device or system and performing any combined method). The patentable scope of the invention is defined by the claims and may include other examples that occur to those skilled in the art. If such other examples have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements that do not differ substantially from the literal language of the claims, they are intended to be within the scope of the claims.

Claims

1. A method for performing access control in a wireless network, the method comprising: receiving a non-access stratum (NAS) message, the NAS message comprising information about one or more access category values, wherein the information indicates that the one or more access category values ​​are associated with a network slice; determining that the access attempt is associated with the one or more access category values; receiving system information related to access category restrictions; determining whether to restrict the access attempt based at least on an access category value of the one or more access category values ​​and the system information related to access category restriction; as well as Indicates whether to restrict the access attempt.

2. The method according to claim 1, wherein: The access category value is associated with an access category defined by an operator.

3. The method according to claim 1, wherein: The information indicates that the access category value is associated with an operating system.

4. The method according to claim 1, wherein: The information indicates that the access category value is associated with a quality of service class identifier (QCI).

5. The method according to claim 1, wherein: The determining whether to limit the access attempt is based on a random number being within a threshold.

6. The method according to claim 1, wherein: The access category value associated with the access attempt includes an indication that the wireless transmit / receive unit is configured for one or more mission critical services.

7. The method according to claim 1, wherein: The information indicates that the access category value is associated with an application and an operating system.

8. A wireless transmit / receive unit WTRU, comprising: processor; and A memory coupled to the processor, the memory storing computer executable instructions, the computer executable instructions, when executed by the processor, causing the processor to perform operations including: receiving a non-access stratum (NAS) message, the NAS message comprising information about one or more access category values, wherein the information indicates that the one or more access category values ​​are associated with a network slice; determining that the access attempt is associated with the one or more access category values; receiving system information related to access category restrictions; determining whether to restrict the access attempt based at least on an access category value of the one or more access category values ​​and the system information related to access category restriction; as well as Indicates whether to restrict the access attempt.

9. The WTRU of claim 8, wherein: The access category value is associated with an access category defined by an operator.

10. The WTRU of claim 8, wherein: The information indicates that the access category value is associated with an operating system.

11. The WTRU of claim 8, wherein: The information indicates that the access category value is associated with a quality of service class identifier (QCI).

12. The WTRU of claim 8, wherein: The determining whether to limit the access attempt is based on a random number being within a threshold.

13. The WTRU of claim 8 wherein: The access category value associated with the access attempt includes an indication that the WTRU is configured for one or more mission critical services.

14. The WTRU of claim 8 wherein: The information indicates that the access category value is associated with an application and an operating system.

15. The WTRU of claim 8, further comprising: The system information is received from a base station.

Images