Access control for a non-terrestrial network (NTN)
By implementing access control mechanisms that allow network entities to bar specific traffic types from accessing NTNs, the solution addresses the lack of granularity in current access control techniques, enhancing resource management and quality of service in satellite-based cellular systems.
Patent Information
- Application Number
- PCT/US2024/053592
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-11-03
- Filing Date
- 2024-10-30
- Publication Date
- 2025-05-08
AI Technical Summary
Current access control techniques for non-terrestrial networks (NTNs) lack granularity, as they either allow or bar all traffic from a user equipment (UE) without distinguishing between different traffic types, leading to inefficient resource management and potential congestion in satellite-based cellular systems.
Implementing a method where a network entity communicates access control information to a UE, indicating barring of access to an NTN based on specific traffic types. This is achieved through various messages, such as system information messages, radio resource control (RRC) messages, and user equipment route selection policy (URSP) rules, which specify the traffic types barred from accessing the NTN.
This approach allows for more granular control over access to NTNs, enabling operators to bar specific traffic types based on factors like user number, cell capacity, quality of service (QoS), or other considerations. By limiting certain traffic types, the system can support a higher number of users per cell and maintain better QoS for other applications.
Smart Images

Figure US2024053592_08052025_PF_FP_ABST
Abstract
Description
Docket No. 14730683000PCT ACCESS CONTROL FOR A NON-TERRESTRIAL NETWORK (NTN) CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This Patent Application claims benefit of priority to U.S. Provisional Patent Application No. 63 / 594,950, filed October 31, 2023, and to U.S. Provisional Patent Application No. 63 / 595,932, filed November 3, 2023, both entitled “ACCESS CONTROL FOR A NON-TERRESTRIAL NETWORK (NTN)” and both assigned to the assignee hereof, the disclosures of which are incorporated by reference in this Patent Application. TECHNICAL FIELD
[0002] This disclosure relates generally to wireless communication and some aspects relate to access control for a non-terrestrial network (NTN), wherein the access control enables a wireless communication system to bar access from a user equipment (UE) to an NTN based on traffic type. DESCRIPTION OF RELATED TECHNOLOGY
[0003] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
[0004] A wireless communication system includes one or more network entities (such as a base station) enabling communication for a mobile communication device (referred to as a user equipment (UE)). Each base station operates one or more cells to provide coverage for the UE. Recent developments in wireless communication technology include the use of non- terrestrial networks (NTNs). An NTN refers to a network, or segment of networks, using radio frequency (RF) resources on board an NTN node, such as a satellite, uncrewed aircraft system (UAS), or high altitude platform (HAP). An NTN node can include a spaceborne vehicle (such as a satellite) or an airborne vehicle (such as UAS). For simplicity, the discussion below refers to all such apparatus as satellites. Satellite-based cellular systems can experience more congestion than terrestrial cellular systems because a satellite cellDocket No. 14730683000PCT typically serves more users and has lower capacity than a cell in a terrestrial cellular network. A satellite in geostationary Earth orbit (GEO) may have a beam footprint diameter ranging from 100 kilometers (km) to 3500 km. For low-earth orbit (LEO) satellite systems, the beam footprint diameter can range from 50 meters (m) to 1200 km. In contrast, terrestrial cellular systems typically have a coverage diameter of 0.5-10 km. Because of its large footprint, a satellite beam / cell generally serves more users than a terrestrial cell. The altitude at which satellites operate can range from approximately 36000 km for GEOs to 600 km for LEOs. Since these distances are several orders of magnitude larger than comparable distances for terrestrial cellular networks, link capacity for satellite-based networks can be relatively low, compared to terrestrial networks.
[0005] Current techniques controlling access to a satellite are limited. For example, access control techniques might restrict access based on location area or time. However, the access control techniques do not, for example, distinguish between traffic type. As a result, the current techniques limit all or none of the traffic from a UE. It is desirable to implement access control with more granularity. BRIEF SUMMARY
[0006] The systems, methods, and apparatuses of this disclosure each have several innovative aspects, no single one of which is solely responsible for the desirable attributes disclosed herein.
[0007] One innovative aspect of the subject matter described in this disclosure can be implemented as a method for wireless communication by a user equipment (UE) in which the UE receives, from a network entity, a message that indicates barring of access to a non- terrestrial network (NTN) for a first traffic type. The UE refrains from accessing the NTN for the first traffic type based on the message. In various example implementations, the message is a system information message, a radio resource control (RRC) message, or a non- access stratum (NAS) message. The message can indicate the barring of access using various combinations of a radio access technology (RAT) type, an access category (AC), a Connection Capability field, or application identifier (ID).
[0008] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method for wireless communication by UE. The method includes the UEDocket No. 14730683000PCT receiving, from a network entity, at least a first UE route selection policy (URSP) rule that includes an indication for barring access to an NTN for a first traffic type. The UE refrains from accessing the NTN for the first traffic type based on the first URSP rule.
[0009] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method for wireless communication by a UE. The method includes the UE receiving access control information from a network entity. The access control information indicates barring for an NTN based on traffic type. In some implementations, a first traffic type is barred, and a second traffic type is not barred. The method includes the UE accessing the NTN for the second traffic type based on the access control information. In some implementations, the method includes the UE refraining from accessing the NTN for the first traffic type based on the access control information.
[0010] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method for wireless communication by a network entity. The method the network includes configuring access control information indicating barring for the NTN based on traffic type and transmitting the access control information to a UE. The network entity can configure the access control information using any of the above-mentioned messages or URSP rules.
[0011] Another innovative aspect of the subject matter described in this disclosure can be implemented as an apparatus or system. In some implementations, an apparatus includes a communication unit and a processing system. The processing system is configured to control the communication unit to implement any one of the methods described in this document. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.
[0012] Details of one or more implementations of the subject matter described in this disclosure are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, the drawings, and the claims. BRIEF DESCRIPTION OF THE DRAWINGS
[0013] Like reference numbers and designations in the various drawings indicate like elements. Note that the relative dimensions of the figures may not be drawn to scale. ToDocket No. 14730683000PCT easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.
[0014] FIG.1 is an example wireless communication system showing a user equipment (UE) and two types of network entities (a base station (BS) and a non-terrestrial network (NTN) node) in which access control information can limit access to the NTN node based on traffic type.
[0015] FIG. 2 shows an example system information message that includes access control information.
[0016] FIG.3 shows an example radio resource control (RRC) message that includes access control information.
[0017] FIG. 4 shows an example UE route selection policy (URSP) message that includes access control information.
[0018] FIG.5 shows an example Route Selection Descriptor (RSD) of a URSP rule in which the RSD includes one or more validity conditions.
[0019] FIG. 6 shows an example non-access stratum (NAS) message that includes access control information.
[0020] FIG. 7 shows a messaging diagram for access control using system information indicating barring based on an access category (AC) in accordance with aspects of this disclosure.
[0021] FIG.8 shows a messaging diagram for access control using a URSP rule for barring in accordance with aspects of this disclosure.
[0022] FIG. 9 shows a messaging diagram for access control using an RRC message for barring in accordance with aspects of this disclosure.
[0023] FIG. 10 shows a messaging diagram for access control using a NAS message for barring in accordance with aspects of this disclosure.
[0024] FIG. 11 is a flow diagram showing example operations of a UE for access control using a URSP rule.Docket No. 14730683000PCT
[0025] FIG. 12 is a flow diagram showing example operations of a UE for access control using a message such as a system information message, RRC message, or NAS message.
[0026] FIG.13 is a flow diagram showing example operations of a network entity for access control in accordance with aspects of this disclosure.
[0027] FIG. 14 illustrates an example control plane protocol stack in accordance with aspects of this disclosure.
[0028] FIG. 15 is a block diagram of an example wireless communication system showing hardware features and communication interfaces. DETAILED DESCRIPTION
[0029] The following description is directed to certain implementations for the purpose of describing innovative aspects of this disclosure. However, a person having ordinary skill in the art will readily recognize that the teachings herein can be applied in a multitude of different ways. Some of the examples in this disclosure are based on wireless communication according to the 3rd Generation Partnership Project (3GPP) wireless standards, such as the 4th generation (4G) Long Term Evolution (LTE) and 5th generation (5G) New Radio (NR) standards. However, the described implementations can be implemented in any device, system, or network that is capable of transmitting and receiving radio frequency signals according to any of the wireless communication standards, including any of the Institute of Electrical and Electronics Engineers (IEEE) 802.11 or 802.16 wireless standards, or other known signals that are used to communicate within a wireless, cellular, or internet of things (IoT) network, such as a system utilizing 4G, 5G, WiFi or future radio technology.
[0030] This disclosure provides systems, methods and apparatuses for access control techniques to limit access from a user equipment (UE) to a non-terrestrial network (NTN). A network entity (such as a satellite or a terrestrial base station) communicates access control information to the UE to indicate barring of access to the NTN based on a traffic type. There are various mechanisms for indicating the barring, the traffic type, and the relationship to the NTN. For example, the network entity can indicate the barring via a non-access stratum (NAS) message (such as a NAS registration accept, NAS registration reject, or NAS downlink transport message). In other examples, the network entity can indicate the barring via a radio resource control (RRC) message or a system information message. In some examples, theDocket No. 14730683000PCT network entity transmits a UE Route selection policy (URSP) with a URSP rule that indicates the barring.
[0031] In some aspects, the network entity indicates the traffic type using an access category (AC) for NTN, such as a standardized AC for NTN or an operator-defined AC for NTN. In some implementations, the standardized AC for NTN is a predefined AC that specifies traffic type, traffic patterns, or traffic criteria that is barred from access the NTN. In some implementations, the operator-defined AC for NTN includes a traffic descriptor that indicates the traffic type. A network entity can transmit a message that indicates that the AC for NTN is barred from accessing the NTN. The message optionally indicates a period for barring or an indication that the access is barred unless indicated otherwise in a subsequent message.
[0032] In some aspects, the network entity indicates the traffic type using a URSP rule that includes a Traffic Descriptor (TD) and a Route Selection Descriptor (RSD). The URSP rule can include an indicator to indicate that traffic matching the URSP rule is barred from accessing the NTN. The indicator (which may be referred to as a barring indicator) can be included in a top level field of the URSP rule, the TD, or the RSD. In some implementations, the URSP rule includes one or more validity conditions that inform the UE when the URSP rule applies. For example, in some implementations, the URSP rule includes a radio access technology (RAT) type that corresponds to the NTN such that the UE applies the URSP rule to the NTN based on the RAT type. In some implementations, the URSP rule indicates an AC (such as a standardized AC for NTN or an operator-defined AC for NTN) to cause the UE to apply the URSP rule for traffic that matches the AC.
[0033] Particular implementations of the subject matter described in this disclosure can be implemented to realize one or more of the following potential advantages. An operator of an example wireless communication system can bar some traffic types from accessing an NTN. The example wireless communication system can control which traffic flows (e.g., applications and / or type of application) can access satellite-based cellular systems. Some techniques of this disclosure enhance existing concepts from 3GPP standards to enable access control at a more granular level. The techniques in this disclosure provide flexibility for an operator to bar particular traffic types based on number of users, NTN cell capacity, quality of service (QoS), or other considerations. By limiting some traffic types, the operator can support an increased number of users per NTN cell. In some implementations, the techniquesDocket No. 14730683000PCT can limit or bar utilization of the satellite capacity for some applications so that the NTN can support a higher QoS for other applications.
[0034] FIG. 1 is an example wireless communication system 100 showing a UE 102 and two types of network entities (a terrestrial network base station (BS 106A) and a non- terrestrial network (NTN) node (satellite 106B). The BS 106A can be an enhanced base station (eNB) or a next generation base station (gNB). The NTN node can be any type of spaceborne vehicle or an airborne vehicle. For brevity, the NTN node is referred to as a satellite 106B in this disclosure. In some implementations, the NTN also includes other components that couple the spaceborne / airborne vehicle to the wireless communication system. For example, the NTN can include an NTN gateway that communicatively couples the satellite 106B to a ground base station (referred to as an NTN BS). In some deployments, some operations of the NTN BS can be collocated on board the satellite 106B. The BS 106A and the NTN BS (or the satellite 106B) are part of one or more radio access networks (RANs) that are communicatively coupled to a core network of the wireless communication system. In 3GPP specifications, the core network can be implemented as an evolved packet core (EPC), a fifth generation (5G) core (5GC), or a sixth generation (6G) core. The wireless communication system can be referred to as a 5th generation system (5GS) when it includes a 5GC. The BS 106A and the satellite 106B can also be referred to as network entities. In this disclosure, a network entity 106 can be either the BS 106A or the satellite 106B.
[0035] The UE 102 can operate in different connectivity states such as connected, idle, or inactive states. A radio resource control (RRC) connected state (referred to as RRC_CONNECTED) refers to a state in which the UE 102 has an active radio connection with any of the network entities 106. An idle state (referred to as RRC_IDLE) refers to a state in which the UE 102 does not have an active radio connection and is not configured with an RRC connection. An inactive state (referred to as RRC_INACTIVE) means that the UE 102 does not have an active radio connection but is configured with the RRC connection in a suspended state.
[0036] One objective of the 5G technology (and beyond) is to provide a unified framework for such types of communication as enhanced mobile broadband (eMBB), ultra-reliable low- latency communications (URLLC), and massive machine type communication (mMTC). The 5G technology relies primarily on legacy terrestrial networks. The 3GPP organization hasDocket No. 14730683000PCT proposed to extend 5G communications (and beyond) to NTNs. An NTN refers to a network, or segment of networks, using radio frequency (RF) resources on board an NTN node (such as satellite or an airborne platform). Airborne platforms can include balloons, dirigibles, winged platforms such as airplane or drones, among other examples. Spaceborne platforms can include a Geostationary Earth Orbit (GEO) satellite (sometimes also referred to as a geosynchronous orbit (GSO) satellite), a Low Earth Orbit (LEO) satellite, a Medium Earth Orbit (MEO) satellite, or a Highly Elliptical Orbit (HEO) satellite, among other examples. In some implementations, NTN nodes form constellations. An NTN node can belong to one of several types based on altitude, orbit, and beam footprint size. For brevity in this disclosure, all types of NTN nodes are referred to as a satellite 106B, which is a type of network entity 106.
[0037] Before 5G, the 3GPP specifications defined access classes to implement access control. A network can randomly assign one of 10 access classes (e.g., numerically numbered access classes, such as AC0, AC1, …, AC9) to each UE. By signaling a barred access class number, the network can periodically or temporarily bar all traffic from those UEs assigned to a particular access class. In 5G (and beyond), the 3GPP has defined a unified access control (UAC) mechanism. In the UAC mechanism, each UE is assigned to one or more Access Identities. Meanwhile, different Access Categories (AC) are associated with various services. When the UE attempts to access the network for any reason, the UE matches a service to an AC. The 3GPP provides rules that govern whether the network can be accessed depending on the UE's Access Identity and the AC for the traffic. The RAN can broadcast barring control information referring to one or more ACs and one or more access identities. The UE can use the barring control information to determine if the access attempt is barred or allowed.
[0038] The current UAC mechanism provides a coarse level of access control that is inadequate for an NTN. For example, the current UAC mechanism operates at the UE level and lacks traffic level control. All the data generated by a UE is either barred or allowed. An operator of an NTN may desire to allow some applications generating limited data (e.g., messaging apps) and bar some other applications generating higher volumes of data (e.g., video or gaming). In a similar vein, satellite systems may be able to support applications that are delay-tolerant, but unable to adequately serve latency sensitive applications. Moreover, depending on network load, the satellite system may, at some points of time and location,Docket No. 14730683000PCT want to allow or disallow some or all the traffic that a UE generates. Currently, the UAC mechanism cannot dynamically configure which application(s) or type of application can use a specific RAT, e.g., satellite access, and which cannot.
[0039] Additionally, the current UAC mechanism cannot bar access for extended periods or indefinitely. Barring is performed at the access stratum (AS) layer per traffic category in a probabilistic manner based on the parameters uac-BarringFactor and uac-BarringTime. The uac-BarringFactor controls the probability of allowing an access attempt, and the uac- BarringTime represents the average time for which an access attempt is blocked. Traditionally, the maximum configurable value of uac-BarringTime is 512 seconds. It might be desirable to permanently block access attempts (for a particular access category) or configure values of uac-BarringTime greater than 512 seconds.
[0040] Another mechanism for access control is based on service area. A network can implement tracking areas that have different tracking area identities (TAIs). Each RAN (possibly of different RAT types) might have a different TAI. An access and mobility management function (AMF) in the core network can determine if the UE is in a forbidden area based on the TAIs. The AMF receives the broadcast TAI (if a single TAI is broadcast) or all broadcast TAIs (if multiple TAIs are broadcast) from the RAN. The AMF provides the UE with Service Area Restrictions which consist of either Allowed Areas or Non-Allowed Areas. The UE and AMF consider the UE to be in a Non-Allowed Area if none of the broadcast TAIs is Allowed. The UE and AMF consider the UE to be in an Allowed Area if at least one broadcast TAI is allowed. This access control mechanism is based on mobility Forbidden area information and service area restrictions mechanism. The AMF provides the UE with mobility Forbidden Area information defined by TAI(s) or Service Area Restrictions which consist of either Allowed Areas or Non-Allowed Areas. If the UE detects that the gNB broadcasts a system information block (SIB) message indicating TAI(s) which is within its configured mobility Forbidden Area or Service area Restrictions, the UE does not access the NTN. This access control mechanism might be too coarse to accommodate the different types of traffic that may be suitable for NTN access.
[0041] In accordance with aspects of this disclosure, a network entity 106 (such as the BS 106A or the satellite 106B) can provide access control information 130 indicating barring for the NTN based on traffic type. For example, the access control information 130 can beDocket No. 14730683000PCT transmitted in a message 120A or 120B from any of the network entities. This disclosure provides several types of messages and access control information to inform the UE 102 regarding which traffic type(s) are barred. The UE 102 can refrain from accessing 160 the NTN node (satellite 106B) based on the access control information.
[0042] A UE 102 can have an application layer, a NAS layer, and an AS layer (such as an RRC, media access control (MAC), and physical (PHY) layers). When a UE 102 launches an application, the application layer can request a data communication service from the NAS layer. For example, the application layer can provide application attributes or related information to the NAS layer. For UAC, the NAS layer of the UE determines an AC for the data communication service based on the application related information. When starting a service request procedure for a service connection (transmission of a service request message or transmission of an extended service request message), the NAS layer can enforce barring based on the AC. Alternatively, the NAS layer can inform the AS layer regarding the AC and the AS layer can enforce the barring based on the AC of the requested data communication service. In either scenario, the data communication service is not requested and the AS does not send the barred transmission 162. The UE 102 can refrain from accessing the satellite 106B by not transmitting the barred transmission 162. This disclosure describes enhancements to the UAC mechanism to implement traffic level barring for NTN access, such as those described with reference to FIG. 2 and FIG. 7. For example, an AC for NTN can indicate traffic types that are barred for NTN. The AC for NTN can be a standardized AC for NTN (such as defined in the 3GPP specifications) or an operator-defined AC for NTN that describes one or more traffic types that are barred from the NTN.
[0043] In some aspects of this disclosure, the AS layer of the UE can transmit a first message (not shown) and receive the access control information 130 via a NAS message or RRC message in response to the first message. Thereafter, the UE 102 refrains from accessing the 106B by not transmitting a subsequent message for the barred application or traffic type. This disclosure describes enhancements to the NAS or RRC messages to implement traffic level barring for NTN access, such as those described with reference to FIG. 3, FIG. 9, and FIG. 10. For example, the NAS or RRC message can indicate barring using an AC for NTN, a barring indicator, cause code, or other information that indicates that the traffic type is barred.Docket No. 14730683000PCT
[0044] In some aspects of this disclosure, barring can be implemented using a URSP. A URSP can have several URSP rules that the UE uses to select the route that the user data traffic takes through the RAN and the core network. The URSP rules are typically implemented at the NAS layer of the UE. The NAS layer can use one or more URSP rules to determine the allowed network nodes, interfaces, or paths based on various factors such as quality of service requirements, operator preferences, or network conditions. This disclosure describes enhancements to the UAC mechanism to implement traffic level barring for NTN access, such as those described with reference to FIG. 4, FIG. 5, and Fig. 8. In some implementations, a URSP rule includes an indication (such as a flag or a field) that indicates that the URSP rule is for barring traffic that matches the URSP rule. Furthermore, the URSP rule can include additional information, such as a RAT type, validity conditions, or other information, that informs the UE 102 that the URSP rule is applicable to NTN access considerations. The UE 102 can refrain from accessing the NTN when the satellite 106B matches the RAT type of the URSP rule, the traffic type matches a Traffic Descriptor (TD) of the URSP rule, and the indication or flag indicates that the URSP rule is for barring access.
[0045] FIG. 2 shows an example system information message 220 that includes access control information. In some implementations, the system information message 220 is a system information broadcast (SIB), such as the SIB type 1 (SIB1) message, a SIB type 19 (SIB19) message for NTN, or a newly numbered SIB message. A network entity (such as either the BS 106A or the satellite 106B of FIG. 1) can transmit the system information message 220 via a broadcast channel. In some implementations, the system information message 220 can indicate a list of ACs that are barred from accessing the broadcasting network entity. In accordance with aspects of this disclosure, the system information message 220 can indicate barring for an AC associated with NTN 230. There are two examples of an AC associated with NTN 230 shown in FIG. 2. The AC associated with NTN 230 can be a standardized AC for NTN 232 (such as an AC having traffic type(s) described in a standard specification) or an operator-defined AC for NTN 234.
[0046] Currently, the 3GPP defines up to 64 ACs, as shown in Table 1. The ACs numbered 0-10 have standardized meanings for various services but are not specific to satellite access. ACs numbered 10-31 are reserved for standardized ACs. ACs numbered 32-63 are available for use as an operator-defined AC.Docket No. 14730683000PCT Table 1. Access Categories Access Conditions related to UE Type of access attempt Category number 0 All mobile originated (MO) signaling resulting from paging 1 (NOTE 1) UE is configured for delay All except for Emergency, tolerant service and subject to or MO exception data access control for Access Category 1, which is judged based on relation of UE’s home public land mobile network (HPLMN) and the selected public land mobile network (PLMN). 2 All Emergency 3 All except for the conditions in MO signaling on NAS level Access Category 1. resulting from other than paging 4 All except for the conditions in multimedia telephony Access Category 1. (MMTEL) voice (NOTE 3) 5 All except for the conditions in MMTEL video Access Category 1. 6 All except for the conditions in short message service Access Category 1. (SMS) 7 All except for the conditions in MO data that does not Access Category 1. belong to any other Access Categories (NOTE 4) 8 All except for the conditions in MO signaling on RRC level Access Category 1 resulting from other than paging 9 All except for the conditions in MO IP multimedia Access Category 1 subsystem (IMS) registration related signaling (NOTE 5)Docket No. 14730683000PCT 10 (NOTE All MO exception data 6) 11-31 Reserved standardized Access Categories 32-63 All Based on operator (NOTE 2) classification NOTE 1: The barring parameter for Access Category 1 is accompanied with information that define whether Access Category applies to UEs within one of the following categories: a) UEs that are configured for delay tolerant service; b) UEs that are configured for delay tolerant service and are neither in their HPLMN nor in a PLMN that is equivalent to it; c) UEs that are configured for delay tolerant service and are neither in the PLMN listed as most preferred PLMN of the country where the UE is roaming in the operator-defined PLMN selector list on the Subscriber Identity Module / Universal Subscriber Identity Module (SIM / USIM), nor in their HPLMN nor in a PLMN that is equivalent to their HPLMN. When a UE is configured for extended access barring (EAB), the UE is also configured for delay tolerant service. In case a UE is configured both for EAB and for EAB override, when upper layer indicates to override Access Category 1, then Access Category 1 is not applicable. NOTE 2: When there is an Access Category based on operator classification and a standardized Access Category to both of which an access attempt can be categorized, and the standardized Access Category is neither 0 nor 2, the UE applies the Access Category based on operator classification. When there is an Access Category based on operator classification and a standardized Access Category to both of which an access attempt can be categorized, and the standardized Access Category is 0 or 2, the UE applies the standardized Access Category. NOTE 3: Includes Real-Time Text (RTT). NOTE 4: Includes IMS Messaging. NOTE 5: Includes IMS registration related signaling, e.g., IMS initial registration, re- registration, and subscription refresh. NOTE 6: Applies to access of a narrowband-IoT (NB-IOT)-capable UE to a NB-IOT cell connected to 5GC when the UE is authorized to send exception data.
[0047] In accordance with this disclosure, one or more new standardized ACs (possibly in the range numbered 10-31) can be defined in the specification to define traffic types commonly barred for satellite access. The standardized AC for NTN 232 might be specific to satellite access. In some implementations, the standardized AC for NTN 232 might also be used for barring the same traffic types over non-satellite access. As an example, the standardized AC for NTN 232 might be defined in the 3GPP specification as related to trafficDocket No. 14730683000PCT from high-bandwidth applications, such as streaming video, real-time gaming, etc. Potential technical advantages of defining a standardized AC for NTN 232 include: multiple network operators can use a common AC configuration, communication can be reduced by using a standardized AC number to describe one or more traffic type, implementation of the AC associated with NTN 230 can be standardized, or any combination of these advantages.
[0048] Alternatively, or additionally, an operator can define and signal an operator-defined AC (possibly in the range numbered 32-63) to describe traffic that is barred from satellite access. The operator-defined AC can include one or more criteria to describe the traffic type. For example, the operator-defined AC can include one or more traffic descriptors (such as those defined in 3GPP technical specification (TS) 24.526) to indicate: ^ Application descriptors ^ Internet Protocol (IP) descriptors ^ Domain descriptors (such as a fully qualified domain name (FQDN)) ^ Non-IP descriptors ^ data network name (DNN) type ^ Connection capabilities type ^ Security parameter index type
[0049] There may be other ways to define the traffic type associated with the AC associated with NTN 230. In some implementations, the AC associated with NTN 230 can indicate one or more connection capabilities type, e.g., IMS traffic, Internet, IoT and machine to machine type of traffic, On demand downlink streaming, On demand uplink streaming, Vehicular communications, Real time interactive traffic, Unified communications traffic, Background traffic, Location-based traffic, Critical Communications, etc. Potential technical advantages of using an operator-defined AC for NTN 234 include: each network operator can customize the traffic types to bar from accessing the NTN, the AC can be dynamically changed based on current operating conditions of the NTN, more sophisticated traffic matching criteria can be configured for the operator-defined AC for NTN 234, or any combination of these advantages.
[0050] The network entity can transmit a system information message 220 indicates that the AC associated with NTN 230 (either or both of the standardized AC for NTN 232 or theDocket No. 14730683000PCT operator-defined AC for NTN 234). The UE using satellite access is not allowed to access the specified connection capabilities for traffic that matches the AC associated with NTN 230. Thus, the UE refrains from accessing the NTN for traffic that matches the AC associated with NTN 230.
[0051] In some aspects, the system information message 220 also includes access parameters 240 (such as barring information). The access parameters 240 can indicate a barring duration (such as in a uac-BarringTime field). In some implementations, the uac-BarringTime is populated with a value to indicate the duration for barring. One or more values can indicate a duration beyond 512 seconds. In some implementations, the uac-BarringTime is populated with a value or flag that indicates an indefinite period or infinity, such that access attempts for that AC are permanently blocked or until a subsequent system information message 220 indicates otherwise. In addition to, or in lieu of the barring duration, the access parameters 240 can include other criteria or parameters associated with the AC associated with NTN 230. A potential technical advantages of including the access parameters 240 is that a network entity can provide more granular control to inform the UE when or how to apply the AC associated with NTN 230 for determining access control.
[0052] FIG.3 shows an example RRC message 320 that includes access control information. Examples of an RRC message 320 include an RRC Reject message, an RRC Complete message, an RRC Configuration message, among other examples. In some implementations, the network entity transmits the RRC message 320 in response to an RRC request message from the UE. Alternatively, or additionally, the network entity can transmit the RRC message 320 whenever the network entity desires to change the access control information.
[0053] In some implementations, the RRC message 320 includes a field indicating AC barring 330 based on an AC associated with NTN, such as the standardized or operator- defined access categories described with reference to FIG. 2. Alternatively, or additionally, the RRC message 320 can include a cause code or other flag to indicate access barring 334. In some implementations, the 3GPP specification (such as 3GPP TS 38.331) for RRC can specify a list of satellite-specific access categories that are barred from accessing a satellite cell.
[0054] FIG.4 shows an example UE route selection policy (URSP) 420 that includes access control information. The URSP 420 can include one or more URSP rules. Each URSP ruleDocket No. 14730683000PCT includes a traffic descriptor 434 and a route selection descriptor 436. A URSP rule can optionally also include URSP rule additional indications 432. In accordance with aspects of this disclosure, one of the URSP rules (shown as URSP Rule 422) can include an indication of barring 430. The indication of barring 430 can be included in any portion of the URSP Rule 422, such as in the URSP rule additional indications 432, the traffic descriptor 434, or the route selection descriptor 436.
[0055] A Traffic Descriptor (TD) 434 can include a variable number (at least one) of traffic descriptor components. Each traffic descriptor component can indicate information about the traffic type that matches URSP rule. For example, the TD can indicate such things as IP address, protocol header, port or port range, QoS tag, connection capabilities, MAC address, among other examples.
[0056] In some implementations, the TD 434 can refer to traffic type using a connection capabilities value. A connection capability value can refer to one of a set of predefined traffic categories such as indicated in Table 2. Each row may be associated with a different value. Table 2 is provided as an example and other traffic categories and implementations of a lookup table are possible. Table 2. Connection Capabilities (traffic categories) IP multimedia Subsystem (IMS) Multimedia Messaging Service (MMS) Secure User Plane Location (SUPL) Internet Operator specific connection capabilities IoT delay-tolerant IoT non-delay-tolerant Downlink streaming Uplink streaming Vehicular communications Real time interactive Unified communications BackgroundDocket No. 14730683000PCT Mission critical communications Time critical communications Low latency loss tolerant communications in un-acknowledged mode
[0057] Returning to the discussion of the indication of barring 430, various implementations of the URSP Rule 422 can include the indication in a different locations. The indication of barring 430 can also be referred to as an information element (IE) or field of the URSP rule additional indications 432, the traffic descriptor 434, or the route selection descriptor 436. The indication of barring 430 can also be referred to as a “AccessNotAllowed” IE or an “Indication for AllowAccess” IE. In some implementations, the indication of barring 430 can be a mandatory binary valued IE that can be either true or false. If AccessNotAllowed is set to true, then traffic matching the corresponding traffic descriptor is not allowed to generate access attempts. In some implementations, the indication of barring 430 is an optional IE, where if the IE is included with a defined valid value, traffic matching the corresponding traffic descriptor is not allowed to generate access attempts. Table 3 and Table 4 show examples of the URSP Rule 422 with an indication of barring 430. Table 3. indication of barring 430 included as top-level field in URSP rule. Policy control Information function (PCF)nameDescription Categorypermitted to Scope modify in a UE context Rule Determines the order the URSP rced in the UE.MandatoUE Precedencerule is enfory Yescontext (new) Determines whether Access is Indication for allowed if this rule is Optional or UE MandYesAllowAccess matchedatorycontext Traffic This part defines the Traffic Descriptor (TD) descriptor components for the Mandatory URSP rule. It consists of object service Application identifier (OSId) and Object tors Server Application IdentifiersOptio UEdescripnal Yescontext(OSAppId(s))Docket No. 14730683000PCT Destination IP 3 tuple(s) (IP IP descriptors address or IPv6 network prefix,UEport number, protocol ID of theOptional Yescontextprotocol above IP). FQDN(s) or a regular Domain expression which are used as aUors domain name matchingOptional Y Edescriptescontextcriteria. Non-IP Descriptor(s) for destination tion of non-IP trafficOptionalUE descriptorsinformaYescontext This is matched against the DNN DNN information provided byOptional Yes UEthe application.contextThis is matched against the information provided by a UE Connection application when it requests aOptio UECapabilities network connection withnal Yescontextcertain capabilities or traffic categories. List of Route A list of Route Selection Selection Descriptors. The components Descriptors of a Route Selection Descriptor Mandatory (RSDs) are described in table 6.6.2.1- 3.
[0058] A potential technical advantage of including the indication of barring 430 in the top- level field (such as the URSP rule additional indications 432) is that implementation of the barring indicator can be easily added to a URSP rule in the standard specification. Table 4. indication of barring 430 included with Traffic Descriptor (TD) Information PCF permittednameDescription Categoryto modify in a Scope UE contextRule PrecedenceDetermines the order the URSPUE rule is enforced in the UE. Mandatory Yescontext Traffic This part defines the Traffic Descriptor (TD) descriptor components for the Mandatory URSP rule.Docket No. 14730683000PCT (new) Determines whether Access is Indication for allowed if this rule is matched Optional or UE or TDsMandaYesAllowAccess ftorycontext Application It consists of OSId andOptionalUE descriptorsOSAppId(s)Yescontext Destination IP 3 tuple(s) (IP IP descriptors address or IPv6 network prefix,UEport number, protocol ID of theOptional Yescontextprotocol above IP). Domain FQDN(s) or a regular expression which are used as a domain nameOption UEdescriptorsal Yesmatching criteria.contextNon-IP Descriptor(s) for destination riptorsinformation of non-IP trafficOptUE descional Yescontext This is matched against the DNN DNN information provided by theOptional Yes UEapplication.contextThis is matched against the Connection information provided by a UE ilities application when it reUECapab quests aOptional Yesnetwork connection with certaincontextcapabilities or traffic categories. List of Route A list of Route Selection Selection Descriptors. The components of a Descriptors Route Selection Descriptor are Mandatory (RSDs) described in table 6.6.2.1-3.
[0059] A potential technical advantage of including the indication of barring 430 in the traffic descriptor 434 is that the indication can be linked to a particular Connection Capability value or traffic descriptor component.
[0060] In some implementations, the URSP rule 422 can also indicate the RAT type 440. For example, the RAT type 440 can be a value from 3GPP TS 29.214 (Table E.2-1), shown below as Table 5. Table 5. RAT Types AccessType specified RatType specified RAT-Type, see for N7, see for N7, see 3GPP TS 29.212 clause 5.3.31 3GPP TS 29.571 3GPP TS 29.571 cla clause 5.4.3.1 use 5.4.3.2Docket No. 14730683000PCT (NOTE 1) Value Value Value Description 3GPP_ACCESS NR 1006 NR EUTRA 1004 EUTRAN NBIOT 1005 EUTRAN-NB-IoT LTE_M 1007 LTE-M NR_U 1008 NR-U NR_LEO 1035 NR(LEO) NR_MEO 1036 NR(MEO) NR_GEO 1037 NR(GEO) NR_OTHER_SAT 1038 NR(OTHERSAT) NR_REDCAP 1039 NR-REDCAP NON_3GPP_ACCESS WLAN 0 WLAN (NOTE 2) VIRTUAL 1 VIRTUAL TRUSTED_N3GA 2 TRUSTED-N3GA TRUSTED_WLAN 0 WLAN (NOTE 2) WIRELINE 3 WIRELINE WIRELINE_CABL 4 WIRELINE-CABLE E WIRELINE_BBF 5 WIRELINE-BBF NOTE 1: Other values of RAT Types specified in 3GPP TS 29.571
[0064] and not shown in this table are not applicable to this specification. NOTE 2: When the received RAT Type in N7 indicates "WLAN", the AN- Trusted AVP set to "Untrusted” indicates the access type is not trusted. When the received RAT Type in N7 indicates "TRUSTED_WLAN", the AN-Trusted AVP set to "Trusted” indicates the access type is trusted.
[0061] When the RAT type 440 is included in the URSP rule 422, the UE can determine that the URSP rule 422 applies when considering access to a RAN that matches the RAT type. For example, a satellite 106B might be a 3GPP new radio (NR) LEO NTN that matches the RAT type of “NR-LEO.” If the RAT type 440 of the URSP rule 422 is “NR-LEO” and the indication of barring 430 indicates that the URSP rule 422 is for barring, then the UE 102 will refrain from accessing the satellite 106B for any traffic that matches the traffic descriptor 434. In various implementations, the RAT type 440 is included in the URSP rule additional indications 432, the traffic descriptor 434, or the route selection descriptor 436. A potential technical advantage of including the RAT type 440 with the URSP rule 422 is that it can limit the scope of the URSP rule 422 to one or more RATs that match the RAT type 440.
[0062] FIG.5 shows an example route selection descriptor 436 of a URSP rule in which the RSD includes one or more validity conditions 540. The route selection descriptor 436 wouldDocket No. 14730683000PCT be included in a URSP rule, such as the URSP rule 422 described with reference to FIG. 4. As described for FIG.4, the route selection descriptor 436 can include an indication of barring 430. In FIG. 5, the route selection descriptor 436 also includes validity conditions 540 to limit when the route selection descriptor 436 is valid. For example, the validity conditions 540 can indicate one or more ACs (such as the AC associated with NTN 230 described with reference to FIG.2), the RAT type 440 (such as described with reference to FIG.4), or both. Table 6 shows an example format for the route selection descriptor 436. The validity criteria can include one or more validity conditions such as time window or location criteria. In accordance with aspects of this disclosure the validity criteria include Access and RAT type Criteria (such as the RAT type 440) and / or the Allowed Access categories Criteria (such as the AC associated with NTN 230). Table 6. Route selection descriptor format PCF Information pernameDescription Categorymitted to modify in Scope URSP Route Selection Determines the order in which the Descriptor Route Selection Descriptors are to Mandatory UE Precedence be applied.(NOTE 1)Yescontext Route selection This part defines the route Mandatory components selection components(NOTE 2)SSC Mode One single value of SSC mode. UE Selection(NOTE 5)Optional Yescontext Network Slice Either a single value or a list of Optional ection values of S-NSSAI(s).(NOTE 3)YeUE Selscontext Data network name (DNN) Either a single value or a list ofOUE onvalptional YesSelectiues of DNN(s).context protocol data unit (PDU) Session One single value of PDU Session Conditional UE n TypeYesType Selectio(NOTE 8)context Non-Seamless Indicates if the traffic of the Offload matching application is to be Optional UE offloaded to non-3GPYesindication P access(NOTE 4)context outside of a PDU Session.Docket No. 14730683000PCT ProSe Layer-3 Indicates if the traffic of the UE-to-Network matching application is to be sent via a ProSe Layer-3 UE-to- Optional UE Relay Offload Network Relay outsi(NOTE 4)Yescontext indication de of a PDU session. Indicates if the traffic of the matching application is preferred ProSe Multi-path to be sent via a PDU Session over OptionalYesUE Preference the Uu reference point and a ProSe(NOTE 9)context Layer-3 UE-to-Network Relay outside of a PDU session. Indicates the preferred Access Access Type Type (3GPP or non-3GPP or Multi-Access) when the UEOp UEpreferencetional Yesestablishes a PDU Session for thecontextmatching application. PDU Session Pair An indication shared by redundant PDU Sessions as descrUEID ibed inOptional Yesclause 5.33.2.1 of TS 23.501 [2].contextrobust security The RSN as described in clause (RSN)5.33.2.1 of TS 23.501 [2].OptionaUE networkl Yescontext Route Selection Validation This part defines the Route Validation Criteria componeOptionalCriteriantsThe time window when the matching traffic is allowed. The Time Window RSD is not considered to be validOptional Yes UEif the current time is not in thecontexttime window. The UE location where the matching traffic is allowed. The Location Criteria RSD rule is not considered to beOptional Yes UEvalid if the UE location does notcontextmatch the location criteria. When the Access type is 3GPP (new) Access and access and the RAT type where RAT type the matching traffic is allowed. UE Criteria The RSD rule is not consideredOptionalYescontext to be valid if the RAT type is not allowed. (new) Allowed The Access categories for whichOptionUE Accessthe matching traffic is allowed.al YescontextDocket No. 14730683000PCT categories The RSD rule is not considered Criteria to be valid if the Access categories is not allowed.
[0063] A potential technical advantage of including the validity conditions 540 with the route selection descriptor 436 is that the URSP rule 422 can be configured to apply to traffic that matches the AC associated with NTN 230 (such as a standardized AC or operator-defined AC), to a RAN that matches the RAT type criteria, or both. For traffic or network entities that do not match the validity conditions 540, the URSP rule 422 can be disregarded and other URSP rule(s) (not shown) can be used to determine routing or access control of the traffic.
[0064] FIG.6 shows an example NAS message 620 that includes access control information. When a UE accesses the wireless communication system, the UE establishes a radio connection to a network entity and then transmits a NAS message to the core network via the radio connection. An element of the core network (such as an AMF) implements a NAS protocol in coordination with a NAS layer of the UE. NAS messages can be used for network registration, service management, or NAS layer configuration. The NAS message 620 can be a NAS registration accept message, a NAS registration reject message, a NAS configuration message, or a downlink NAS transport message, among other examples.
[0065] In some aspects of this disclosure, a NAS message 620 from the core network (via the network entity) to the UE can include an indication of barring 430. The indication of barring 430 can be any of the examples described in this disclosure, such as a flag or field that indicates access category barring, a traffic descriptor and barring indication, a route selection descriptor that indicates RAT type and barring, among other examples. Additionally, or alternatively, the NAS message 620 can include barring information 640. For example, the barring information 640 can include any combination of fields to indicate the RAT type 642, the AC associated with NTN 644, the Connection Capability field 646, or application ID 648.
[0066] As an example, the NAS message 620 can indicate barring in association with a combination of RAT type and traffic type. In some implementations, the RAT type is a value indicating an option from a lookup table, such as Table 5. The traffic type can be configured using an AC or traffic descriptor (such as the traffic descriptor defined for a URSP message).Docket No. 14730683000PCT Alternatively, or additionally, the traffic type can be configured using a Connection Capability field having a value associated with a row in Table 2. Alternatively, or additionally, the traffic type can be configured using one or more application identifiers (IDs) 648 that correspond to specific applications.
[0067] In some implementations, the NAS message 620 can configure an operator-defined AC (such as the operator-defined AC for NTN 234) with a traffic descriptor and an indication that the operator-defined AC is associated with a particular RAT type, TAI, or NTN. Depending on the format of the NAS message 620, the inclusion of an operator-defined AC can be an implicit indication that traffic matching the AC is barred from the NTN.
[0068] FIG. 7 shows a message flow diagram 700 for access control using system information indicating barring based on an AC in accordance with aspects of this disclosure. The message flow diagram 700 shows messages and operations of a UE 102, a network entity 106 (such as a satellite 106B) and a core network 108 (such as an AMF or other entity in the core network).
[0069] In some implementations, an operator can configure an AC associated with NTN (such as an operator-defined AC) via a message 712. In some implementations, the AC associated with NTN can be predefined (such as a standardized AC for NTN) so that message 712 can be omitted. When the network entity 106 desires to bar access for traffic that matches the AC, the network entity 106 can transmit system information 720 the UE 102 that indicates the barring. For example, the system information 720 can be a SIB1, SIB19, or new type of SIB. The system information 720 can include a value referring to the AC that the network entity 106 desires to bar from accessing the network entity 106 or another network entity (e.g., barring access to satellite 106B when the network entity 106 is a terrestrial base station 106A).
[0070] When the UE 102 using a satellite access for an application attempts to access the 5GS, the UE 102 performs access control checks. For example, the UE 102 checks the system information 720 for an indication of barred ACs. If the system information 720 indicates barring for the AC that matches with the traffic type of the application, the UE stops accessing the 5G network using the network entity 106. Thus, the UE 102 refrains (760) from accessing NTN for traffic type that matches the AC indicated as being barred by the system information 720.Docket No. 14730683000PCT
[0071] In some implementations, the UE 102 first checks if the system information 720 indicates a standardized AC for NTN and applies barring for traffic that matches the standardized AC for NTN. If the traffic type for the application does not match the standardized AC for NTN or the system information 720 does not indicate the standardized AC for NTN, the UE 102 continues to check for any operator-defined ACs in that are indicated in the system information 720. If the traffic type of the application matches an operator- defined AC indicated in the system information 720 as being barred, the UE 102 refrains (760) from accessing the network entity 106 for that traffic.
[0072] FIG.8 shows a message flow diagram 800 for access control using a URSP rule for barring in accordance with aspects of this disclosure. The core network 108 can signal a URSP rule 820 to the UE 102. The URSP rule 820 can be included in URSP that the core network 108 communicates to the UE 102 using NAS messaging. The URSP rule 820 can be any of the URSP rules and options described in this disclosure, such as those described with reference to FIG.4 and FIG.5.
[0073] When the UE 102 launches an application, an application layer of the UE 102 requests a data communication service from the NAS layer of the UE 102. At the NAS layer of the UE 102, the UE 102 can determine if traffic for that application matches any of the URSP rules. In the example of FIG. 8, the traffic type of the application matches the URSP rule 820, and the URSP rule 820 includes an indication of barring for any traffic that matches the URSP rule 820. Based on the URSP rule 820, the NAS layer of the UE blocks traffic for that application and refrains (860) from accessing the network entity 106 (such as satellite 106B) for traffic type that matches the URSP rule 820.
[0074] FIG. 9 shows a messaging diagram for access control using an RRC message for barring in accordance with aspects of this disclosure. As described with reference to FIG.7, in some implementations, the core network 108 configures an operator-defined AC via a message 712. Alternatively, the UE 102 and the network entity 106 can be aware of standardized ACs, including a standardized AC for NTN. The network entity 106 (such as satellite 106B) can transmit an RRC message 920 that refers to an AC (such as an operator- defined AC or standardized AC for NTN) with an indication that the AC is barred.
[0075] In some implementations, the RRC message 920 can be a message from the network entity 106 to the UE 102 in response to an earlier RRC message 918. For example, the RRCDocket No. 14730683000PCT message 918 might be an RRC request message to establish a connection to a data service of the wireless communication system, and the RRC message 920 can be an RRC Reject message indicating that the request is rejected with a cause code or barring information that refers to the barred AC. The RRC message 920 can be an example of the RRC message 320 described with reference to FIG.3.
[0076] After receiving the RRC message 920, the UE 102 prevents further access attempts to the 106 and refrains (960) from accessing the network entity 106 (such as satellite 106B) for traffic that matches barring information in the RRC message 920.
[0077] FIG.10 shows a message flow diagram 1000 for access control using a NAS message 1020 for barring in accordance with aspects of this disclosure. The NAS message 1020 can be an example of the NAS message 620 described with reference to FIG.6. For example, the NAS message 1020 can include any combination of barring information, RAT type, barred ACs for NTN, application ID, Connection Capability, or other fields.
[0078] In some implementations, the NAS message 1020 is a response to an uplink NAS message 1018. For example, the uplink NAS message 1018 might be a NAS registration message or service request message. The NAS message 1020 can be a NAS registration accept message, a NAS registration reject message, a NAS configuration message, or a downlink NAS transport message, among other examples. As an example, the NAS message 1020 can be an Attach Accept message and can include a list of access categories and (optionally) associated RAT types, e.g., satellite access, in an information element of the NAS message 1020 to indicate access control information. Alternatively, the NAS message 1020 might be an Attach Reject message including the information of a list of traffic descriptors and (optionally) associated RAT types to indicate the access control information if the UE’s access type and RAT type are not allowed. The NAS message 1020 can include a rejection cause code to indicate that the rejection is based on the access control information. Optionally, the NAS message 1020 can also include a backoff timer based on the UE’s access type and the RAT type.
[0079] Based on receiving the NAS message 1020 indicating barring, the UE 102 refrains (1060) from accessing the network entity 106 (satellite 106B) for any traffic matching traffic type referred to in the NAS message 1020. Where the NAS message 1020 includes a RAT type, the UE 102 might determine that the network entity 106 matches the RAT type andDocket No. 14730683000PCT refrain from accessing the network entity 106. However, if the network entity 106 does not match the RAT type (such as where the network entity 106 is a BS 106A and the RAT type is a satellite type), the UE 102 may proceed with access to the network entity 106.
[0080] FIG. 11 is a flow diagram 1100 showing example operations of a UE for access control using a URSP rule. The example operations of FIG. 11 can be implemented in a UE (such as the UE 102 described herein). In block 1130, the UE receives, from a network entity (such as a satellite 106B), at least a first URSP rule that includes an indication for barring access to a non-terrestrial network (NTN) for a first traffic type. The first URSP rule can be an example of the URSP rule 422 described with reference to FIG. 4. In some implementations, the first URSP rule includes a route selection descriptor, such as the route selection descriptor 436 described with reference to FIG. 5. In block 1160, the UE refrains from accessing the NTN for the first traffic type based on the first URSP rule.
[0081] FIG. 12 is a flow diagram 1200 showing example operations of a UE for access control using a message such as a system information message, RRC message, or NAS message. The example operations of FIG. 12 can be implemented in a UE (such as the UE 102 described herein). In block 1230, the UE receives, from a network entity, a message that indicates barring of access to an NTN for a first traffic type. For example, the message can be any of the example system information messages (220, 720), URSP messages (420, 820), RRC messages (320, 920), or NAS messages (620, 1020) described in this disclosure. The message can indicate barring of the first traffic type in an NTN (such as a satellite 106B or a cell of any type of NTN node). In block 1260, the UE refrains from accessing the NTN for the first traffic type based on the message.
[0082] FIG.13 is a flow diagram 1300 showing example operations of a network entity for access control in accordance with aspects of this disclosure. The example operations of FIG. 13 can be implemented in a network entity (such as the network entity 106, BS 106A, or satellite 106B described herein). In block 1320, the network entity configures access control information indicating barring for an NTN based on traffic type. In block 1322, the network entity transmits the access control information to a UE. Alternatively, or additionally, the network entity can broadcast the access control information, such as via a system information message. The network entity can transmit the access control information using one or more of the various example messages described in this disclosure, such as any of the exampleDocket No. 14730683000PCT system information messages (220, 720), URSP messages (420, 820), RRC messages (320, 920), or NAS messages (620, 1020).
[0083] FIG.14 illustrates an example control plane protocol stack 1400 in accordance with aspects of this disclosure. The control plane protocol stack 1400 illustrated in FIG.14 shows various protocol layers of the UE 102, satellite 106B, NTN gateway 1404, NTN BS 1406, and core network 108 (such as the AMF in a 5G core network). The “NR-Uu” interface refers to the interface between the UE 102 and the NTN BS 1406 (via the satellite 106B and NTN gateway 1404). In some implementations, aspects of the NTN BS 1406 can be implemented on board the satellite 106B. The "NG-C" interface refers to the interface between the NTN BS 1406 and the core network 108.
[0084] In the control plane, the UE 102 includes a NAS layer, a radio resource control (RRC) layer, a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, a MAC layer, and a PHY layer. The RRC layer implements the RRC protocol and can transmit or receive RRC messages such as those described in this disclosure. The NTN BS 1406 (and the satellite 106B) also have an RRC layer. The NR-Uu interface (between RRC layers of the UE 102 and the NTN BS 1406 or satellite 106B) are part of the access stratum (AS) of the control plane. In contrast, the NAS protocol is implemented between the NAS layer of the UE 102 and a NAS layer of an entity in the core network 108.
[0085] FIG. 15 is a block diagram of an example wireless communication system 1500 showing hardware features and communication interfaces. The depicted hardware configurations may omit certain components well-understood to be frequently implemented in such electronic devices, such as displays, peripherals, power supplies, and the like. The example wireless communication system 1500 includes the same elements as described with reference to FIG.1, including the UE 102, the BS 106A, the satellite 106B as well as the core network 108 and NTN BS 1406 described with reference to FIG.14. The UE 102 can support at least a 5G NR (or simply, “NR”) or E-UTRA air interface to communicate with the BS 106A or satellite 106B. The network entities of the RAN (such as BS 106A and satellite 106B) connects to the core network 108 via an interface (e.g., S1 or NG interface). A network entity (such as BS 106A or NTN BS 1406) can connect to other base stations via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes.Docket No. 14730683000PCT
[0086] The core network 108 can be an Evolved Packet Core (EPC) and / or a 5G core (5GC). Among other components, the EPC can include a Serving Gateway (SGW), a Mobility Management Entity (MME), and a Packet Data Network Gateway (PGW). The SGW in general is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME is configured to manage authentication, registration, paging, and other related functions. The PGW provides connectivity from the UE to one or more external packet data networks, e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC includes a User Plane Function (UPF) and an Access and Mobility Management Function (AMF), and / or Session Management Function (SMF). Generally speaking, the UPF is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF is configured to manage authentication, registration, paging, and other related functions, and the SMF is configured to manage PDU sessions.
[0087] The base station BS 106A is equipped with processing hardware 1506 that can include a receiver 1507B configured to receive data in the uplink direction. The processing hardware 1506 can also include a transmitter 1507A configured to transmit data in the downlink direction. The processing hardware further can one or more general-purpose processor(s) 1507C (e.g., CPUs) and a non-transitory computer-readable memory 1507D storing instructions that the one or more general-purpose processors execute. Additionally, or alternatively, the processing hardware 1506 can include special-purpose processing units. The processor 1507C may include, for example, one or more central processing units, graphics processing units (GPUs), or other application-specific integrated circuits (ASIC), and the like. CRM 1507D may include any suitable memory or storage device such as random-access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), or Flash memory usable to store device data of the TN BS 106A.
[0088] The satellite 106B can include processing hardware 1508, such as a transmitter 1509A, a receiver 1509B, a processor 1509C, and CRM 1509D (similar to components 2506, 1507A, 1507B, 1507C and 1507D of the TN BS 106A). The satellite 106B can include generally similar components (not shown) as the processing hardware 1506.
[0089] The UE 102 is equipped with processing hardware 1502 that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memoryDocket No. 14730683000PCT 1503D storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 1502 can also include a transmitter 1503A configured to transmit data in the downlink direction. The processing hardware further can include a receiver 1503B configured to receive data in the uplink direction. The processing hardware 1502, in an example implementation, includes a processor 1503C to process data that the UE 102 will transmit in the uplink direction, or process data received by UE 102 in the downlink direction. The processor(s) 1503C may include, for example, one or more central processing units, graphics processing units (GPUs), or other application-specific integrated circuits (ASIC), and the like. To illustrate, the processor(s) 1503C may include an application processor (AP) utilized by the UE 102 to execute an operating system and various user-level software applications, as well as one or more processors utilized by modems or a baseband processor. The computer readable media / memory (CRM) 1503D may include any suitable memory or storage device such as random- access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), Flash memory, solid-state drive (SSD) or other mass- storage devices, and the like useable to store one or more sets of executable software instructions and associated data that manipulate the one or more processor(s) 1503C and other components of the processing hardware 1502 to perform the various functions described herein and attributed to the UE 102. The sets of executable software instructions include, for example, an operating system (OS) and various drivers (not shown), and various software applications (not shown), which are executable by processor(s) 1503C to enable user-plane communication, control-plane signaling, and user interaction with the UE 102. For example, the processor(s) 1503C can implement an application layer, NAS layer, and AS layer, as described with reference to FIG.1.
[0090] The following description may be applied to the description above.
[0091] Generally speaking, description for one of the above figures can apply to another of the above figures. Examples, implementations and methods described above can be combined, if there is no conflict. An event or block described above can be optional or omitted. For example, an event or block with dashed lines in the figures can be optional. In some implementations, “message” is used and can be replaced by “information element (IE),” and vice versa. In some implementations, “IE” is used and can be replaced by “field,” and viceDocket No. 14730683000PCT versa. In some implementations, “configuration” can be replaced by “configurations” or “configuration parameters,” and vice versa. In some implementations, “some” means “one or more.” In some implementations, “at least one” means “one or more.”
[0092] A user device in which the techniques of this disclosure can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (IoT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.
[0093] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules can be software modules (e.g., code, or machine-readable instructions stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can include dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also include programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
[0094] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more special-purpose processors.Docket No. 14730683000PCT
[0095] Upon reading this disclosure, those of skill in the art will appreciate still additional and alternative structural and functional designs for handling mobility between base stations through the principles disclosed herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those of ordinary skill in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein.
[0096] FIG. 1 through FIG. 15 and the operations described herein are examples meant to aid in understanding example implementations and should not be used to limit the potential implementations or limit the scope of the claims. some implementations may perform additional operations, fewer operations, operations in parallel or in a different order, and some operations differently.
[0097] Another innovative aspect of the subject matter described in this disclosure can be implemented as a computer-readable medium having stored therein instructions which, when executed by a processor, causes the processor to perform any one of the above-mentioned functionalities.
[0098] Another innovative aspect of the subject matter described in this disclosure can be implemented as a system having means for implementing any one of the above-mentioned functionalities.
[0099] Another innovative aspect of the subject matter described in this disclosure can be implemented as an apparatus having one or more processors configured to perform one or more operations from any one of the above-mentioned methods.
[0100] As used herein, the terms “component” and “module” are intended to be broadly construed as hardware, firmware, or a combination of hardware and software. As used herein, a processor is implemented in hardware, firmware, or a combination of hardware and software. As used herein, the phrase “based on” is intended to be broadly construed to mean “based at least in part on.”
[0101] As used herein, a phrase referring to a list of items separated by “or” refers to any combination of those items, including single members. For example, “a, b, or c” is intendedDocket No. 14730683000PCT to cover the possibilities of: a only, b only, c only, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a and b and c.
[0102] In this disclosure, an expression of “X / Y” may include meaning of any of the following: “X or Y” or “X and Y” or “X and / or Y." An expression of “(A) B” or “B (A)” may include concept of “only B.” An expression of “(A) B” or “B (A)” may include the concept of “A+B” or “B+A.”
[0103] In this disclosure, the term "can" indicates a capability, or alternatively indicates a possible implementation option. The term "may" indicates a permission or a possible implementation option.
[0104] Some aspects are described herein in connection with thresholds. As used herein, satisfying a threshold may refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, or the like.
[0105] The various illustrative components, logic, logical blocks, modules, circuits, operations and algorithm processes described in connection with the implementations disclosed herein may be implemented as electronic hardware, firmware, software, or combinations of hardware, firmware or software, including the structures disclosed in this specification and the structural equivalents thereof. The interchangeability of hardware, firmware and software has been described generally, in terms of functionality, and illustrated in the various illustrative components, blocks, modules, circuits and processes described above. Whether such functionality is implemented in hardware, firmware or software depends upon the particular application and design constraints imposed on the overall system.
[0106] The hardware and data processing apparatus used to implement the various illustrative components, logics, logical blocks, modules and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose single- or multi-chip processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, or any conventional processor, controller,Docket No. 14730683000PCT microcontroller, or state machine. A processor also may be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In some implementations, particular processes, operations and methods may be performed by circuitry that is specific to a given function.
[0107] As described above, some aspects of the subject matter described in this specification can be implemented as software. For example, various functions of components disclosed herein, or various blocks or steps of a method, operation, process or algorithm disclosed herein can be implemented as one or more modules of one or more computer programs. Such computer programs can include non-transitory processor-executable or computer-executable instructions encoded on one or more tangible processor-readable or computer-readable storage media for execution by, or to control the operation of, a data processing apparatus including the components of the devices described herein. By way of example, and not limitation, such storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store program code in the form of instructions or data structures. Combinations of the above should also be included within the scope of storage media.
[0108] As used herein, the terms “user device”, “user equipment” (for example, UE 110), “wireless communication device”, “mobile communication device”, “communication device”, or “mobile device” refer to any one or all of cellular telephones, smartphones, portable computing devices, personal or mobile multi-media players, laptop computers, tablet computers, smartbooks, Internet-of-Things (IoT) devices, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, wireless gaming controllers, display sub-systems, driver assistance systems, vehicle controllers, vehicle system controllers, vehicle communication system, infotainment systems, vehicle telematics systems or subsystems, vehicle display systems or subsystems, vehicle data controllers, point- of-sale (POS) terminals, health monitoring devices, drones, cameras, media-streaming dongles or another personal media devices, wearable devices such as smartwatches, wireless hotspots, femtocells, broadband routers or other types of routers, and similar electronic devices which include a programmable processor and memory and circuitry configured toDocket No. 14730683000PCT perform operations as described herein. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer- readable memory, a user interface, one or more network interfaces, one or more sensors, etc.
[0109] Various modifications to the implementations described in this disclosure may be readily apparent to persons having ordinary skill in the art, and the generic principles defined herein may be applied to other implementations without departing from the scope of this disclosure. Thus, the claims are not intended to be limited to the implementations shown herein but are to be accorded the widest scope consistent with this disclosure, the principles and the novel features disclosed herein.
[0110] Additionally, various features that are described in this specification in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination. As such, although features may be described above as acting in particular combinations, and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.
[0111] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Further, the drawings may schematically depict one or more example processes in the form of a flowchart or flow diagram. However, other operations that are not depicted can be incorporated in the example processes that are schematically illustrated. For example, one or more additional operations can be performed before, after, simultaneously, or between any of the illustrated operations. In some circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged intoDocket No. 14730683000PCT multiple software products. Additionally, other implementations are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results.
[0112] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the aspects to the precise form disclosed. Modifications and variations may be made in light of the above disclosure or may be acquired from practice of the aspects. While the aspects of the disclosure have been described in terms of various examples, any combination of aspects from any of the examples is also within the scope of the disclosure. The examples in this disclosure are provided for pedagogical purposes. APPENDIX A
[0113] Appendix A includes additional examples discussing the shortcomings of current access control mechanisms and proposals to overcome those shortcomings, such as enhancements to access control mechanisms for UEs using Satellite RAT.
[0114] When considering RAN (gNB / eNB) boarding on the NGSO satellite, the nature of the communication characteristics between the UE on the ground and the gNB / eNB boarding on the Satellite in the sky would result in some limitations to the applicable services.
[0115] In view of required QoS provisioning, long latency and varied jitter would impose restrictions on accommodating UEs using Satellite access for delay sensitive services, e.g. streaming video. As a result, UEs using satellite access might not be able to get required QoS of some services.
[0116] For NTN, a satellite in geosynchronous orbit (GEO) may have a beam footprint diameter ranging from 100 Km to 3500 Km. For low-earth orbit satellite systems (LEO), the beam footprint diameter can range from 50 m to 1000 km (Ref: 3GPP TR 38.821). In contrast, TN typically have a coverage diameter of 0.5-10 Km. Because of its large footprint, a satellite beam / cell serves more users than a TN cell. The altitude at which satellites operate can range from approximately 36000 Kms for GEOs to 600 Kms for LEOs. Since these distances are several orders of magnitude larger than comparable distances for TN, link capacity for NTN can be relatively low, compared to TN. As a result, NTN with gNB / eNB boarding on the satellite might experience more congestion than TN with gNB / eNB on the ground because a NTN cell typically serves more users and has lower capacity than a TN cell.Docket No. 14730683000PCT
[0117] Currently, in 3GPP TS 23.501 [5] clause 5.4.11.8, the access control mechanism is based on mobility Forbidden area information and service area restrictions mechanism. The AMF provides the UE with mobility Forbidden Area information defined by TAI(s) or Service Area Restrictions which consist of either Allowed Areas or Non-Allowed Areas. If the UE detects that the gNB broadcasts SIB indicating TAI(s) which is within its configured mobility Forbidden Area or Service area Restrictions, the UE does not use the Satellite access. The restriction is too extreme to accommodate the traffic that may be suitable for Satellite access.
[0118] For RAN boarding on NGSO satellite, the nature of the communication characteristics between the UEs on the ground and the RAN boarding on the Satellite in the sky would result in some limitations to the applicable services. The access control mechanisms in disclosure overcome the above-mentioned shortcomings and provide more sophisticated access control mechanisms than currently available in the 3GPP specifications. Any of the described access control mechanisms (or a combination thereof) allow the 5GS to determine which services / traffic flows (e.g., applications and / or type of application) can get access for a UE using Satellite access to RAN boarding on NGSO satellite.
Claims
Docket No. 14730683000PCT CLAIMS What is claimed is:
1. A method for wireless communication by a user equipment (UE) (102), comprising: receiving, from a network entity (106), at least a first UE route selection policy (URSP) rule (422) that includes access control information for barring access to a non-terrestrial network (NTN) based on a first traffic type; and refraining from accessing the NTN for the first traffic type based on the first URSP rule.
2. The method of claim 1, wherein the first URSP rule includes at least one of: a URSP rule additional indications field (432) associated with the first URSP rule, a Traffic Descriptor (TD) field (434), or Route Selector Descriptor (RSD) field (436).
3. The method of claim 1 or 2, wherein the first URSP rule includes a field (430) for indicating that the first URSP rule is for either allowing or barring the access.
4. The method of any one of claims 1 to 3, wherein the first URSP rule includes at least one validity condition (540), and wherein the at least one validity condition indicates a radio access technology (RAT) type (440) that matches the NTN.
5. The method of any one of claims 1 to 3, wherein the first URSP rule includes at least one validity condition in association with a Route Selection Descriptor (RSD) field (436), and wherein the at least one validity condition indicates that the first URSP rule corresponds to an access category, AC, (230) for the NTN.
6. The method of claim 5, wherein the AC (230) for the NTN is one of: a standardized AC (232) that is specific to a RAT type of the NTN, or an operator-defined AC (234) that is specific to the RAT type of the NTN.
7. The method of any one of claims 1 to 6, wherein the receiving the first URSP rule includes:Docket No. 14730683000PCT receiving, from the network entity, a UE policy message (420) containing one or more URSP rules including the first URSP rule, wherein the access control information includes an indication (430) that indicates the first URSP rule (422) is for barring access.
8. The method of any one of claims 1 to 7, further comprising: launching an application for the first traffic type; matching the first traffic type to the first URSP rule; and preventing the application from accessing the NTN based on the first URSP rule.
9. The method of any one of claims 1 to 8, wherein the access control information indicates that the access is barred for an indefinite period of time or until a subsequent URSP rule indicates that the access is allowed.
10. The method of any one of claims 1 to 9, wherein the access control information indicates a radio access technology (RAT) type of the NTN in association with at least one of a Connection Capability field, an AC, or application identifier (ID).
11. The method of any one of claims 1 to 10, further comprising: receiving the first UE route selection policy (URSP) rule via at least one of: a non-access stratum (NAS) registration accept message, a NAS registration reject message, a NAS configuration message, or a downlink NAS transport message.
12. The method of any one of claims 1 to 11, wherein the access control information indicates barring for the NTN based on traffic type, wherein the first traffic type is barred and a second traffic type is not barred.
13. The method of claim 12, further comprising: accessing the NTN for the second traffic type based on the access control information; and refraining from accessing the NTN for the first traffic type based on the access control information.Docket No. 14730683000PCT 14. A method for wireless communication by a network entity, the method comprising: configuring access control information (130) indicating barring for a non-terrestrial network (NTN) based on traffic type; and transmitting (120A, 120B) the access control information to a user equipment (UE) via a UE route selection policy (URSP) rule.
15. The method of claim 14, wherein the transmitting the access control information includes transmitting the URSP rule via at least one of: a non-access stratum (NAS) registration accept message, a NAS registration reject message, a NAS configuration message, or a downlink NAS transport message.
16. An apparatus, comprising: a communication unit; and a processing system configured to control the communication unit to implement any one of the methods of any one of claims 1 to 15.
Citation Information
Patent Citations
Cell barring procedure in ntn
US20230319686A1
Data transmission method and related device, computer-readable storage medium, and computer program product
US20230337108A1
Method for satellite selection
WO2023004757A1