To provide user-specific services in a wireless access network.

Abstract

Generally, the present subject matter relates to providing user equipment-specific services in a radio access network. In some implementations, usage information uniquely associated with a user equipment (UE) having a UE context can be received from a radio access network (RAN) in a core network. The usage information can be collected by the RAN. After the UE context is released, the received usage information can be stored in the core network.

Description

Technical Field

[0001] In some implementations, the present subject matter relates to communication systems, and more particularly, to providing services specific to user equipment in a wireless access network.

Background Art

[0002] In today's world, cellular networks provide on-demand communication capabilities to individuals and business entities. Typically, a cellular network is a wireless network that can be distributed across terrestrial areas called cells. Each such cell is served by at least one fixed-position transceiver represented as a cell site or base station. Each cell can use a different set of frequencies from its neighboring cells to avoid interference and provide improved services within each cell. By combining cells, wireless coverage over a wide geographic area is provided such that a large number of mobile phones and / or other wireless devices or portable transceivers can communicate with each other and with fixed transceivers and telephones anywhere in the network. Such communication is carried out through base stations and is realized even when the mobile transceiver in communication passes through more than one cell. Major wireless communication providers have deployed such cell sites around the world, enabling mobile phones and mobile computing devices to connect to the public switched telephone network and the public Internet.

[0003] A mobile phone is a portable phone capable of receiving and / or making phone and / or data calls via a cell site or communication tower by using radio waves to transmit signals to and from a mobile phone. From the perspective of a large number of mobile phone users, current mobile phone networks provide limited and shared resources. In this regard, cell sites and handsets can change frequencies and use low-power transmitters to allow simultaneous use of the network by many callers with less interference. Cell site coverage can depend on a particular geographical location and / or the number of users who could potentially use the network. For example, in a city, a cell site may have a range of up to about half a mile. In suburban areas, the range can be as much as 5 miles. In some areas, users can receive signals from cell sites as far as 25 miles away.

[0004] The following are some examples of digital cellular technologies used by telecommunications providers: Global System for Mobile Communications (“GSM”), General Packet Radio Service (“GPRS”), cdmaOne, CDMA2000, Evolution-Data Optimized (“EV-DO”), Enhanced Data Rates for GSM Evolution (“EDGE”), Universal Mobile Telecommunications System (“UMTS”), Digital Enhanced Cordless Telecommunications (“DECT”), Digital AMPS (“IS-136 / TDMA”), and Integrated Digital Enhanced Network (“iDEN”). Long Term Evolution, or 4G LTE, developed by the Third Generation Partnership Project (“3GPP”) standardization body, is a standard for high-speed data wireless communication for mobile phones and data terminals. Currently, 5G standards are under development and deployment. 3GPP cellular technologies such as LTE and 5G NR are evolutions of previous generation 3GPP technologies such as GSM / EDGE and UMTS / HSPA digital cellular technologies, enabling increased capacity and speed through improvements to the core network and the use of different radio interfaces.

[0005] A cellular network can be divided into a radio access network and a core network. The radio access network (RAN) may include network functions capable of handling radio layer communication processing. The core network may include network functions capable of handling higher layer communications (e.g., Internet Protocol (IP), transport layer, and application layer). In some cases, the RAN functions can be divided into baseband unit functions and radio unit functions. Here, radio units connected to baseband units via a fronthaul network may handle lower layer processing of the radio physical layer, for example, while baseband units may handle higher layer radio protocols (e.g., MAC, RLC, etc.). [Overview of the project] [Problems that the invention aims to solve]

[0006] Each mobile phone or other user device (UE) has a unique identifier (International Mobile Subscriber Identity (IMSI) for LTE systems or Subscription Permanent Identifier (SUPI) for 5G systems). Under 3GPP standards, for security reasons, the unique identifier is permitted to be shared with the core network but not with the RAN. Therefore, it has been difficult, if not impossible, for the RAN to store and use information uniquely associated with a UE after the UE has been disconnected from the cellular network. Consequently, even if a UE was previously connected to the RAN and is reconnected to the RAN, the RAN may not be able to optimally serve a particular UE. [Means for solving the problem]

[0007] In some implementations, the subject concerns computer implementation methods. These methods may include receiving usage information uniquely associated with user devices (UEs) having a UE context from a radio access network (RAN) within the core network. The usage information may be collected by the RAN. The methods may also include storing the received usage information within the core network after the UE context has been released.

[0008] The method may allow the core network to send usage information about the stored UE to the RAN if the UE later reconnects to the RAN. This allows the RAN to access usage information uniquely associated with the UE immediately after the UE reconnects to the RAN, improving the RAN's service to the UE.

[0009] In some implementations, the subject may include one or more of the following optional features:

[0010] In some implementations, usage information may include one or more of the following for the UE: Physical Downlink Control Channel (PDCCH) control channel element (CCE) allocation statistics, block error rate (BLER) distribution for the UE, modulation and coding scheme (MCS) distribution for the UE, uplink power allocation history based on transmit power control (TPC) commands transmitted in relation to the UE, carrier aggregation (CA) band combinations used in relation to the UE, and dual connectivity (DC) band combinations used in relation to the UE. Furthermore, the method may also include transmitting an octet stream along with the usage information from the RAN to the core network.

[0011] In some implementations, usage information may be sent from the RAN to the core network in the UE Context Release Complete message.

[0012] In some implementations, the method may further include sending stored usage information from the core network to the RAN after the UE context has been released. Furthermore, the RAN may be configured to use the received usage information to fine-tune UE-specific scheduling behavior and CA and DC carrier addition strategies. The RAN may be configured to use the received usage information in one or more of the following: tuning proportional-equal scheduler alpha / beta parameters, tuning UE-specific PDCCH search space, tuning CCE aggregation levels, tuning uplink power allocation so as to start from the power level last used by the RAN for approximately the UE, tuning initial MCS and / or BLER targets, and tuning the UE's Discontinuous Reception (DRX) configuration. The core network may send stored usage information to the RAN in an Initial Context Setup Message associated with a UE reconnecting to the RAN.

[0013] In some implementations, the method may further include a User Plane Function (UPF) of the core network that collects average packet arrival time information associated with the UE for each Quality of Service (QoS) flow. Furthermore, the method may also include a UPF that transmits the collected information to the Session Management Function (SMF) of the core network. Furthermore, the UPF can transmit the collected information to the SMF in a Packet Forwarding Control Protocol (PFCP) Session Report Request message. Furthermore, the method may further include an SMF that transmits the collected information to the Access and Mobility Management Function (AMF) of the core network. Furthermore, the SMF can transmit the collected information to the AMF in an Update Session Management (Update SM) Context Response message. Furthermore, the method may further include an AMF that transmits the collected information and stored usage information to the RAN. Furthermore, AMF can send collected and stored usage information to the RAN in an Initial Context Setup Message. AMF can also send one or more of the uplink and downlink volumes and uplink and downlink flow times per QoS flow to the RAN.

[0014] In some implementations, the core network can store usage information associated with a unique identifier for the UE, which can be an IMSI (International Mobile Subscriber Identity) or SUPI (Subscription Permanent Identifier).

[0015] In some implementations, the RAN may include base stations, including eNodeBs, and the core network may be the core network of the LTE system.

[0016] In some implementations, the RAN may include base stations, including gNodeBs, and the core network may be the core network of a 5G system or a post-5G next-generation system.

[0017] Also described are non-temporary computer program products (i.e., physically embodied computer program products) that store instructions causing at least one data processor to perform the operations described herein when executed by one or more data processors of one or more computing systems. Similarly, computer systems that may include one or more data processors and memory coupled to one or more data processors are also described. The memory may temporarily or permanently store instructions causing at least one processor to perform one or more of the operations described herein. In addition, the method may be implemented by one or more data processors within a single computing system or distributed across two or more computing systems. Such computing systems are connected and can exchange data and / or commands or other instructions via one or more connections (including, but not limited to, connections on a network (e.g., the Internet, a wireless wide area network, a local area network, a wide area network, a wired network, etc.)) such as direct connections between one or more multi-computing systems.

[0018] Details of one or more variations of the subject matter described herein are presented in the accompanying drawings and the following description. Other features and advantages of the subject matter described herein will become apparent from the description, drawings, and claims. [Brief explanation of the drawing]

[0019] The following accompanying drawings, which are incorporated in and form a part of this specification, illustrate specific aspects of the subject matter disclosed herein and serve to explain some of the principles related to the disclosed implementations in conjunction with the description.

[0020] FIG. 1a shows an exemplary conventional "long term evolution" ("LTE") communication system.

[0021] FIG. 1b shows further details of the exemplary LTE system shown in FIG. 1a.

[0022] FIG. 1c shows additional details of the "evolved packet core" of the exemplary LTE system shown in FIG. 1a.

[0023] FIG. 1d shows an exemplary "evolved Node B" of the exemplary LTE system shown in FIG. 1a.

[0024] FIG. 2 illustrates further details of the "evolved Node B" shown in FIGS. 1a - d.

[0025] FIG. 3 shows an exemplary virtual radio access network according to some implementations of the present subject matter.

[0026] FIG. 4 shows an exemplary 3GPP split architecture for providing use of a higher frequency band to its users.

[0027] FIG. 5a shows an exemplary 5G wireless communication system.

[0028] FIG. 5b shows an exemplary layer architecture of a split gNB and / or split ng-eNB (e.g., "next generation eNB" which may be connected to 5GC).

[0029] FIG. 5c shows an exemplary functional split in the gNB architecture shown in FIGS. 5a - b.

[0030] Figure 6 shows other exemplary 5G wireless communication systems relating to several implementations of the current subject.

[0031] Figure 7 shows other exemplary LTE wireless communication systems relating to several implementations of the current subject.

[0032] Figure 8 shows illustrative methods for several implementations of the current topic.

[0033] Figure 9 shows exemplary systems related to several implementations of the current topic.

[0034] Figure 10 shows other exemplary systems relating to several implementations of the current subject.

[0035] Figure 11 shows other exemplary methods relating to several implementations of the current subject. [Modes for carrying out the invention]

[0036] The present subject can provide systems and methods that can be implemented in wireless communication systems. Such systems may include a variety of wireless communication systems, including 5G New Radio communication systems, "long term evolution" communication systems, and so on.

[0037] In general, the subject matter concerns providing user-specific services in wireless access networks.

[0038] In some implementations of the current subject, a radio access network (RAN) may be configured to collect usage information uniquely associated with user devices (UEs) that are communicatively coupled to the RAN. A core network configured to communicatively coupled to the RAN may be configured to bring about the release of UE contexts for UEs stored in the RAN. The RAN may be configured to transmit the collected usage information to the core network in relation to the release of the UE contexts. The core network may be configured to store the usage information received from the RAN. Thus, usage information uniquely associated with a particular UE may be stored in the core network even after the UE context for that particular UE has been released in the RAN. If the UE later reconnects to the RAN, the core network may be configured to transmit the stored usage information for that particular UE to the RAN. Therefore, immediately after the UE reconnects to the RAN, the RAN can access the usage information uniquely associated with the UE, improving the RAN's service to the UE. Because the usage information was previously collected by the RAN, it is also uniquely associated with the RAN, improving the RAN's service to the UE.

[0039] According to 3GPP standards, the core network can access the unique identifier of a UE (e.g., an identifier stored on the UE's SIM (Subscriber Identity Module) card, such as the International Mobile Subscriber Identity (IMSI) for LTE systems or the Subscription Permanent Identifier (SUPI) for 5G systems). For security reasons, according to 3GPP standards, the RAN cannot access the unique identifier of a UE. Therefore, according to 3GPP standards, while a UE is connected to the RAN, it can be uniquely identified in the RAN by a temporary identifier (e.g., S-Temporary Mobile Subscriber Identity (S-TMSI) for LTE systems or S-Temporary Mobile Subscription Identifier (5G-S-TMSI) for 5G systems). Thus, after the UE's context is released in the RAN, the RAN no longer has an identifier to uniquely identify the UE, and therefore cannot store information uniquely associated with a particular UE. A RAN configured to send usage information uniquely associated with a specific UE to the core network, and a core network configured to store the received usage information, enables the storage of usage information for a specific UE even after the UE context has been released from the RAN. The core network can store usage information associated with a UE's unique identifier even when the UE is in an idle (IDLE) state, so that the usage information remains uniquely associated with a specific UE and available for return to the RAN if the UE reconnects to the RAN.

[0040] 3GPP standards that define one or more aspects of the current subject include: 3GPP TS 23.401 "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.501 "System architecture for the 5G System (5GS); Stage 2", 3GPP TS 29.244 "Interface between the Control Plane and the User Plane Nodes; Stage 3", 3GPP TS 29.274 "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunneling Protocol for Control plane (GTPv2 C); Stage 3", 3GPP TS 29.501 "5G System; Principles and Guidelines for Services Definition; Stage 3", 3GPP TS 29.502 "5G System; Session Management Services; Stage 3", and 3GPP This includes TS 36.413 “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)” and 3GPP TS 38.413 “NG-RAN; NG Application Protocol (NGAP)”. O-RAN Alliance standards, such as those of Working Group 1 (WG1), the Use Cases and Overall Architecture workgroup, may also be relevant to one or more aspects of the current subject.

[0041] One or more aspects of the current subject can be integrated into the transmitter and / or receiver components of base stations (e.g., gNodeB, eNodeB, etc.) in such communication systems. The following is a general discussion of long-term evolutionary communication systems and 5G New Radio communication systems. I. "Long-term evolution" communication systems

[0042] Figures 1a-c and 12 illustrate an exemplary conventional long-term evolution ("LTE") communication system 100 with its various components. The LTE system, or 4G LTE, conforms to the standards for high-speed data wireless communication for mobile phones and data terminals, as is commercially known. The standards are an evolution of GSM / EDGE ("Global System for Mobile Communications" / "Enhanced Data rates for GSM Evolution") and UMTS / HSPA ("Universal Mobile Telecommunications System" / "High Speed ​​Packet Access") network technologies. The standards were developed by 3GPP ("3rd Generation Partnership Project").

[0043] As shown in Figure 1a, System 100 may include an "evolved universal terrestrial radio access network" ("EUTRAN") 102, an "evolved packet core" ("EPC") 108, and a "packet data network" ("PDN") 101, which provides communication between user devices 104 and PDN 101 via EUTRAN 102 and EPC 108. EUTRAN 102 may include multiple "evolved Node B" ("eNodeB" or "ENODEB" or "enodeb" or "eNB") or base stations 106 (a, b, c) (as shown in Figure 1b) that provide communication capabilities to multiple user devices 104 (a, b, c). User devices 104 may be mobile phones, smartphones, tablets, personal computers, personal digital assistants ("PDAs"), servers, data terminals, and / or any other type of user device, and / or any combination thereof. The user device 104 can connect to the EPC 108 and subsequently to the PDN 101 via any eNodeB 106. Typically, the user device 104 can connect to the eNodeB 106 closest in terms of distance. In the LTE system 100, the EUTRAN 102 and EPC 108 work together to provide connectivity, mobility, and services to the user device 104.

[0044] Figure 1b illustrates further details of the network 100 shown in Figure 1a. As previously mentioned, EUTRAN 102 includes multiple eNodeB 106, also known as cell sites. The eNodeB 106 provides radio functionality and performs key control functions, including scheduling of airlink resources or radio resource management, active mode mobility or handover, and admission control for services. The eNodeB 106 is responsible for selecting which mobility management entity (MME, as shown in Figure 1c) serves the user equipment 104, and for protocol features such as header compression and encryption. The eNodeB 106 constituting EUTRAN 102 cooperate with each other for radio resource management and handover.

[0045] Communication between user equipment 104 and eNodeB 106 occurs via air interface 122 (also known as the “LTE-Uu” interface). As shown in Figure 1b, air interface 122 provides communication between user equipment 104b and eNodeB 106a. Air interface 122 uses orthogonal frequency division multiple access (“OFDMA”) and single-carrier frequency division multiple access (“SC-FDMA”), OFDMA variants, on the downlink and uplink, respectively. OFDMA enables the use of multiple known antenna techniques, such as “Multiple Input Multiple Output” (“MIMO”).

[0046] The air interface 122 uses various protocols, including Radio Resource Control ("RRC") for signaling between user equipment 104 and eNodeB 106, and Non-Access Layer ("NAS") for signaling between user equipment 104 and MME (as shown in Figure 1c). In addition to signaling, user traffic is forwarded between user equipment 104 and eNodeB 106. Both signaling and traffic in system 100 are carried by physical layer ("PHY") channels.

[0047] Multiple eNodeB106s can be interconnected using X2 interfaces 130(a, b, c). As shown in Figure 1b, X2 interface 130a provides interconnection between eNodeB106a and eNodeB106b, X2 interface 130b provides interconnection between eNodeB106a and eNodeB106c, and X2 interface 130c provides interconnection between eNodeB106b and eNodeB106c. The X2 interface can be established between two eNodeBs to provide signal exchange, which may include load or interference-related information and handover-related information. The eNodeB106 communicates with the "evolved packet core" 108 via S1 interfaces 124(a, b, c). S1 interface 124 can be divided into two interfaces. One is the control plane (shown as the control plane interface (S1-MME interface) 128 in Figure 1c), and the other is the user plane (shown as the user plane interface (S1-U interface) 125 in Figure 1c).

[0048] The EPC108 establishes and enables "Quality of Service" ("QoS") for user services, allowing user equipment 104 to maintain a consistent Internet Protocol ("IP") address while in transit. Each node in network 100 has its own IP address. The EPC108 is designed to work with legacy wireless networks. The EPC108 is also designed to separate the control plane (i.e., signaling) and the user plane (i.e., traffic) in the core network architecture, enabling greater flexibility in implementation and independent scalability of control and user data functions.

[0049] The architecture of EPC108 is for packet data and is shown in more detail in Figure 1c. EPC108 includes a Serving Gateway (S-GW) 110, a PDN Gateway (P-GW) 112, a Mobility Management Entity ("MME") 114, a Home Subscriber Server ("HSS") 116 (subscriber database for EPC108), and a Policy Control and Billing Rule Function ("PCRF") 118. Some of these (S-GW, P-GW, MME, and HSS, etc.) are often combined into a node according to the manufacturer's implementation.

[0050] S-GW110 functions as an IP packet data router and is the bearer path anchor for user equipment in EPC108. Therefore, as user equipment moves from one eNodeB106 to another during mobility operations, S-GW110 remains the same, and the bearer path toward EUTRAN102 is switched to speak with the new eNodeB106 serving user equipment 104. If user equipment 104 moves to the domain of another S-GW110, MME114 forwards all of the user equipment's bearer paths to the new S-GW. S-GW110 establishes bearer paths toward one or more P-GW112 for the user equipment. When downstream data is received for idle user equipment, S-GW110 buffers the downstream packets and requests MME114 to identify and re-establish the bearer paths toward and through EUTRAN102.

[0051] P-GW112 is the gateway between EPC108 (and user devices 104 and EUTRAN102) and PDN101 (shown in Figure 1a). P-GW112 acts as a router for user traffic, performing functions on behalf of the user devices. These include assigning IP addresses to user devices, packet filtering of downstream user traffic to ensure it is placed on the appropriate bearer path, and enabling downstream QoS, including data rates. Depending on the services used by the subscriber, there may be multiple user data bearer paths between user device 104 and P-GW112. Subscribers can use services on the PDN served by different P-GWs. In this case, user devices have at least one bearer path established to each P-GW112. If the S-GW110 also changes during a handover of user devices from one eNodeB to another, the bearer path from P-GW112 is switched to the new S-GW.

[0052] The MME114 manages user devices 104 within the EPC108 (including managing subscriber authentication, maintaining context for authenticated user devices 104, establishing data bearer paths in the network for user traffic, and continuing to track the location of idle mobile devices that are not disconnected from the network). For idle user devices 104 that need to be reconnected to the access network to receive downstream data, the MME114 initiates paging to identify the user device and re-establish the bearer path to and through the EUTRAN102. The MME114 for a particular user device 104 is selected by the eNodeB106 from which the user device 104 initiates system access. MMEs are typically part of a collection of MMEs in the EPC108 for load sharing and redundancy purposes. In establishing the user's data bearer path, the MME114 is responsible for selecting the P-GW112 and S-GW110 that constitute the ends of the data path through the EPC108.

[0053] PCRF118 is responsible for policy control decision-making and controlling the flow-based billing function within the policy control enablement function ("PCEF") located within P-GW110. PCRF118 determines how specific data flows are handled in PCEF and provides QoS authorization (QoS class identifier ("QCI") and bitrate) to ensure that this is in line with the user's subscription profile.

[0054] As previously mentioned, IP service 119 is provided by PDN101 (shown in Figure 1a).

[0055] Figure 1d shows an exemplary configuration of eNodeB106. eNodeB106 may include at least one “remote radio head” (“RRH”) 132 (typically there may be three RRHs) and a baseband unit (“BBU”) 134. The RRH 132 may be connected to the antenna 136. The RRH 132 and BBU 134 may be connected using an optical interface compliant with the “common public radio interface” (“CPRI”) / “enhanced CPRI” (“eCPRI”) 142 standard, using a custom control and user plane framing method specific to the RRH or a control and user plane framing method compliant with the O-RAN Alliance. The operation of the eNodeB106 can be characterized using the following standard parameters (and specifications): radio frequency band (Band 4, Band 9, Band 17, etc.), bandwidth (5, 10, 15, 20 MHz), access scheme (downlink: OFDMA; uplink: SC-OFDMA), antenna technology (single-user and multi-user MIMO; uplink: single-user and multi-user MIMO), number of sectors (up to 6), maximum transmit rate (downlink: 150 Mb / s; uplink: 50 Mb / s), S1 / X2 interface (1000Base-SX, 1000Base-T), and mobile environment (up to 350 km / h). The BBU134 can handle digital baseband signal processing, S1 line termination, X2 line termination, call processing, and monitoring control processing. IP packets received from EPC108 (not shown in Figure 1d) can be modulated into digital baseband signals and transmitted to RRH132. Conversely, digital baseband signals received from RRH132 can be demodulated into IP packets for transmission to EPC108.

[0056] The RRH132 can transmit and receive radio signals using antenna 136. The RRH132 can convert digital baseband signals from BBU134 into radio frequency ("RF") signals (using converter ("CONV") 140) and amplify the power for transmission to user equipment 104 (not shown in Figure 1d) (using amplifier ("AMP") 138). Conversely, RF signals received from user equipment 104 are amplified (using AMP 138) and converted into digital baseband signals for transmission to BBU134 (using CONV 140).

[0057] Figure 2 shows additional details of an exemplary eNodeB106. The eNodeB106 comprises multiple layers ("LTE Layer 1" 202, "LTE Layer 2" 204, and "LTE Layer 3" 206). LTE Layer 1 includes the physical layer ("PHY"). LTE Layer 2 includes Media Access Control ("MAC"), Radio Link Control ("RLC"), and Packet Data Convergence Protocol ("PDCP"). LTE Layer 3 includes various functions and protocols, including Radio Resource Control ("RRC"), Dynamic Resource Allocation, eNodeB Measurement Configuration and Provisioning, Radio Admission Control, Connectivity Mobility Control, and Radio Resource Management ("RRM"). The RLC protocol is an "automatic repeat request" ("ARQ") fragmentation protocol used on the cellular air interface. The RRC protocol handles LTE Layer 3 control plane signaling between user equipment and EUTRAN. RRC includes functions for connection establishment and release, broadcasting system information, establishing / reconfiguring and releasing radio bearers, RRC connection mobility procedures, paging notifications and releases, and outer loop power control. PDCP performs IP header compression and decompression, user data transfer, and maintaining sequence numbers for radio bearers. BBU134, shown in Figure 1d, may include LTE layers L1-L3.

[0058] One of the main functions of eNodeB106 is radio resource management, including scheduling of both uplink and downlink air interface resources for user equipment 104, control of bearer resources, and admission control. As an agent for EPC108, eNodeB106 is responsible for forwarding paging messages used to identify idle mobiles. eNodeB106 also communicates common control channel information for the radio, header compression, encryption and decryption of user data transmitted over the radio, and establishes handover reporting and trigger criteria. As previously mentioned, eNodeB106 can collaborate with other eNodeB106s on the X2 interface for handover and interference management purposes. eNodeB106 communicates with the EPC's MME via the S1-MME interface and with the S-GW on the S1-U interface. Furthermore, eNodeB106 exchanges user data with the S-GW on the S1-U interface. eNodeB106 and EPC108 have a many-to-many relationship to support load sharing and redundancy between MMEs and S-GWs. eNodeB106 selects an MME from a group of MMEs so that the load can be shared by multiple MMEs to avoid congestion. II.5G NR Wireless Communication Network

[0059] In some implementations, the current subject concerns the 5G New Radio ("NR") communication system. 5G NR is the successor communication standard to the 4G / IMT-Advanced standard. 5G networks offer higher capacity than current 4G, accommodating more mobile broadband users per unit area and enabling greater and / or unlimited data consumption in gigabytes per month and per user. This could allow users to stream high-definition media on their mobile devices for much of the day (even when it's not possible to do the same on a Wi-Fi network). 5G networks also offer improved support for device-to-device communication, lower costs, lower latency than 4G equipment, and lower battery consumption, among other things. Such networks offer data rates of tens of megabits per second for a large number of users, 100 Mb / s for metropolitan areas, 1 Gb / s for simultaneous users in restricted areas (e.g., office floors), numerous simultaneous connections for wireless sensor networks, improved spectral efficiency, improved coverage, improved signaling efficiency, 1-10 ms latency, and reduced latency compared to existing systems.

[0060] Figure 3 shows an exemplary virtual radio access network 300. The network 300 can provide communication between various components, including base stations (e.g., eNodeB, gNodeB) 301, radio equipment 307, aggregation units 302, digital units 304, and radio devices 306. Components in system 300 may be communicatively coupled to the core using backhaul links 305. An aggregation unit ("CU") 302 may be communicatively coupled to a distributed unit ("DU") 304 using a midhaul connection 308. A radio frequency ("RU") component 306 may be communicatively coupled to a DU 304 using a fronthaul connection 310.

[0061] In some implementations, CU302 can provide intelligent communication capabilities to one or more DU units 308. Units 302, 304 may include one or more base stations, macro base stations, micro base stations, "remote radio heads," etc., and / or any combination thereof.

[0062] In lower layer-split architecture environments, CPRI bandwidth requirements for NR can be several hundred Gb / s. CPRI compression can be implemented in DU and RU (shown in Figure 3). In 5G communication systems, compressed CPRI on Ethernet frames is represented as eCPRI and is the recommended fronthaul network. The architecture can enable fronthaul / midhaul standardization, which may include fronthaul with higher layer-split architectures (e.g., "Option 2" or "Option 3-1" (higher / lower RLC split architectures)) and L1 split architectures ("Option 7").

[0063] In some implementations, a lower layer-split architecture (e.g., "Option 7") may include joint processing across multiple transmit points (TPs) for both receivers in the uplink and DL / UL, and transport bandwidth and latency requirements for ease of deployment. Furthermore, the lower layer-split architecture of the present subject may include a split between cell-level and user-level processing, including cell-level processing at remote units ("RUs") and user-level processing at DUs. Moreover, by using the lower layer-split architecture of the present subject, frequency-domain samples that can be compressed to reduce fronthaul bandwidth may be transmitted over the Ethernet fronthaul.

[0064] Figure 4 shows an exemplary communication system 400 that can implement 5G technology and provide users with the use of higher frequency bands (e.g., above 10 GHz). System 400 may include macrocells 402 and small cells 404, 406.

[0065] The mobile device 408 may be configured to communicate with one or more small cells 404, 406. System 400 may enable the separation of the control plane (C-plane) and user plane (U-plane), which utilize different frequency bands, between the macrocell 402 and the small cells 404, 406. In particular, the small cells 404, 406 may be configured to utilize higher frequency bands when communicating with the mobile device 408. The macrocell 402 can utilize existing cellular bands for C-plane communication. The mobile device 408 may be communicatively coupled via the U-plane 412. Here, the small cell (e.g., small cell 406) can provide higher data rates and more flexible / cost-effective / energy-efficient operations. The macrocell 402 can maintain good connectivity and mobility via the C-plane 410. Furthermore, in some cases, LTE and NR may be transmitted on the same frequency.

[0066] Figure 5a shows an exemplary 5G wireless communication system 500 relating to several implementations of the present subject. System 500 may be configured to have a lower layer-split architecture in accordance with "Option 7-2". System 500 may include a core network 502 (e.g., 5G Core) and one or more gNodeBs (or gNBs) which may have aggregation units gNB-CUs. A gNB-CU may be logically separated into a control plane portion (gNB-CU-CP) 504 and one or more user plane portions (gNB-CU-UP) 506. The control plane portion 504 and the user plane portion 506 may be configured to be communicatively coupled using an E1 communication interface 514 (as defined in the 3GPP standard). The control plane portion 504 may be configured to be responsible for executing the RRC and PDCP protocols of the radio stack.

[0067] The control plane and user plane portions 504, 506 of the gNB aggregation unit may be configured to communicate with one or more distributed units (DUs) 508, 510 according to a higher layer-split architecture. The distributed units 508, 510 may be configured to run the upper layers of the radio stack's RLC, MAC, and PHY layer protocols. The control plane portion 504 may be configured to communicate with the distributed units 508, 510 using an F1-C communication interface 516, and the user plane portion 506 may be configured to communicate with the distributed units 508, 510 using an F1-U communication interface 518. The distributed units 508, 510 can communicate with one or more remote radio units (RUs) 512 via a fronthaul network 520 (which may include switches, links, etc.) and communicate with one or more user devices (not shown in Figure 5a). The remote radio unit 512 may be configured to perform lower-level parts of the PHY layer protocol and provide antenna capabilities to the remote unit for communication with user equipment (similar to the above discussion regarding Figures 1a-2).

[0068] Figure 5b shows an exemplary layer architecture 530 of a split gNB. Architecture 530, which can be configured as a virtualized and decomposed radio access network (RAN) architecture (where layers L1, L2, L3 and radio processing can be virtualized and decomposed in the aggregate unit, distributed unit and radio unit), can be implemented in the communication system 500 shown in Figure 5a. As shown in Figure 5b, the gNB-DU 508 can be communicatively coupled with the gNB-CU-CP control plane portion 504 (also shown in Figure 5a) and the gNB-CU-UP user plane portion 506. Each of components 504, 506, and 508 can be configured to include one or more layers.

[0069] The gNB-DU508 may include RLC, MAC, and PHY layers, and various communication sublayers. These may include the F1 Application Protocol (F1-AP) sublayer, the GPRS Tunneling Protocol (GTPU) sublayer, the Stream Controlled Transmit Protocol (SCTP) sublayer, the User Datagram Protocol (UDP) sublayer, and the Internet Protocol (IP) sublayer. As previously stated, the distributed unit 508 may be communicatively coupled to the control plane portion 504 of the aggregation unit, which may include the F1-AP, SCTP, and IP sublayers, as well as the Radio Resource Control and PDCP Control (PDCP-C) sublayers. Furthermore, the distributed unit 508 may be communicatively coupled to the user plane portion 506 of the aggregation unit of the gNB. The user plane portion 506 may include the Service Data Adaptation Protocol (SDAP), PDCP User (PDCP-U), GTPU, UDP, and IP sublayers.

[0070] Figure 5c shows an exemplary functional split in the gNB architecture shown in Figures 5a and 5b. As shown in Figure 5c, gNB-DU508 may be communicatively coupled with gNB-CU-CP504 and GNB-CU-UP506 using the F1-C communication interface. gNB-CU-CP504 and GNB-CU-UP506 may be communicatively coupled using the E1 communication interface. The higher portion of the PHY layer (or Layer 1) may be performed by gNB-DU508, and the lower portion of the PHY layer may be performed by RU (not shown in Figure 5c). As shown in Figure 5c, the RRC and PDCP-C portions may be performed by the control plane portion 504, and the SDAP and PDCP-U portions may be performed by the user plane portion 506.

[0071] Some of the functions of the PHY layer in a 5G communication network may include error detection on the transport channel and suggestion to higher layers, FEC encoding / decoding of the transport channel, hybrid ARQ soft synthesis, rate matching of coded transport channels to physical channels, mapping of coded transport channels onto physical channels, power weighting of physical channels, modulation and demodulation of physical channels, frequency and time synchronization, radio characteristics measurement and suggestion to higher layers, MIMO antenna processing, digital and analog beamforming, RF processing, and other functions.

[0072] The Layer 2 MAC sublayer can perform beam management, random access procedures, mapping between logical and transport channels, concatenation of multiple MAC service data units (SDUs) belonging to a single logical channel into a transport block (TB), multiplexing / demultiplexing of SDUs belonging to logical channels to / from TBs delivered to / from the physical layer over transport channels, scheduling of information reporting, error correction via HARQ, priority handling between logical channels of a single UE, priority handling between UEs through dynamic scheduling, transport format selection, and other functions. The functions of the RLC sublayer may include forwarding upper layer packet data units (PDUs), error correction via ARQ, sorting of data PDUs, duplication and protocol error detection, and re-establishment. The PDCP sublayer may be responsible for forwarding user data, various functions during re-establishment procedures, retransmission of SDUs, discarding SDUs on the uplink, forwarding control plane data, and others.

[0073] The Layer 3 RRC sublayer can perform functions such as broadcasting system information to NAS and AS, establishing, maintaining, and releasing RRC connections, security, establishing, configuring, maintaining, and releasing point-to-point radio bearers, mobility functions, reporting, and other functions. III. Providing UE-specific services in RAN

[0074] In some implementations of the present subject, a core network (e.g., a core network in an LTE system such as EPC108 in Figures 1a-1c and 2, a core network in a 5G system such as core network 502 in Figure 5a, or a core network in a 6G or later generation system) which is communicatively coupled to a radio access network (RAN) (e.g., a RAN in an LTE system such as EUTRAN102 in Figures 1a-1c and 2, a core network in a 5G system such as core network 502 in Figure 5a, or a core network in a 6G or later generation system) may be configured to establish a user equipment (UE) context in the RAN for a specific UE (e.g., UE104 in Figures 1a-1c, UE408 in Figure 4, etc.). The UE context may be established in accordance with 3GPP standards. The UE may have a unique identifier (e.g., an identifier stored on the UE's SIM card, such as an IMSI for an LTE system or a SUPI for a 5G system). However, for security reasons, according to the 3GPP standard, the unique identifier of a UE is known to the core network but not to the RAN. Therefore, according to the 3GPP standard, a UE connected to the RAN is uniquely identified in the RAN by a temporary identifier (e.g., S-TMSI in LTE systems or 5G-S-TMSI for 5G systems).

[0075] In some implementations of the current subject, the RAN may be configured to collect usage information uniquely associated with the UE connected to it. The RAN may be configured to store collected information uniquely associated with the UE, such as by storing information collected in relation to the UE's temporary identifier. The usage information collected by the RAN in relation to a particular UE is also referred to here as "RAN context information."

[0076] The core network may be configured, for example, to bring about a release of the UE context in accordance with the 3GPP standard when the UE transitions to IDLE. The RAN may be configured to transmit usage information associated with the UE to the core network, relating it to the release of the UE context. The RAN may be configured to transmit usage information as uniquely associated with the UE, for example, by associating the usage information with a temporary identifier.

[0077] The core network may be configured to store usage information received from the RAN even when the UE is idle. The core network may be configured to identify usage information as uniquely associated with a particular UE, for example, by using a temporary identifier received from the RAN in relation to the usage information. In this way, the core network stores received usage information that is uniquely associated with a UE, for example, by storing the received usage information related to a unique identifier of the UE that is known to the core network. Therefore, usage information uniquely associated with a particular UE is stored in the core network even after the UE context for that particular UE has been released in the RAN, and security is not compromised because the unique identifier of the UE remains unknown to the RAN.

[0078] If a UE later reconnects to the RAN, the core network may be configured to send stored usage information about that specific UE to the RAN. Therefore, immediately after the UE reconnects to the RAN, the RAN can access usage information uniquely associated with the UE, improving the RAN's service to the UE. Because the usage information was previously collected by the RAN, it is also uniquely associated with the RAN, further improving the RAN's service to the UE.

[0079] The RAN is configured to use usage information collected by the RAN in relation to a specific UE and later sent back from the core network when that UE reconnects to the RAN, thereby improving service to the reconnected UE. Generally, the service improvement comes from the RAN using usage information to fine-tune UE-specific scheduling and radio resource management (RRM) behavior.

[0080] Various usage information associated with a specific UE connected to the RAN can be collected by the RAN. Generally, usage information may include UE-specific usage statistics and UE-specific usage profiles.

[0081] In some implementations of the current subject, the information used may include one or more of the following parameters: physical downlink control channel (PDCCH) control channel element (CCE) allocation statistics for the UE, block error rate (BLER) distribution for the UE, modulation and coding scheme (MCS) distribution for the UE, uplink power allocation history based on transmit power control (TPC) commands transmitted in association with the UE, carrier aggregation (CA) band combinations used in association with the UE, and dual connectivity (DC) band combinations used in association with the UE.

[0082] RAN can be configured to adjust the UE-specific PDCCH search space based on PDCCH CCE allocation statistics for the UE. In other words, RAN can be configured to adjust the UE-specific PDCCH search space based on the UE's historical PDCCH CCE allocation statistics.

[0083] RAN can be configured to adjust the CCE aggregation level of a UE based on PDCCH CCE allocation statistics for that UE. In other words, RAN can be configured to adjust the CCE aggregation level of a UE based on the PDCCH CCE allocation statistics of the UE's history.

[0084] The RAN may be configured to adjust the UE's Connectivity Mode Discontinuous Receive (DRX) configuration based on PDCCH CCE allocation statistics for the UE. In other words, the RAN may be configured to adjust the UE's Connectivity Mode DRX configuration based on the UE's historical PDCCH CCE allocation statistics.

[0085] RAN can be configured to adjust the initial MCS target for a UE based on the MCS distribution for that UE. In other words, RAN can be configured to adjust the initial MCS target for a UE based on the MCS distribution of the UE's history.

[0086] The RAN can be configured to adjust the initial BLER target for a UE based on the BLER distribution rate for that UE. In other words, the RAN can be configured to adjust the initial BLER target for a UE based on the BLER distribution rate of the UE's history.

[0087] The RAN may be configured to adjust the uplink power allocation of a UE based on its uplink power allocation history using TPC commands sent in relation to the UE. In other words, the RAN may be configured to adjust the uplink power allocation of a UE based on its historical uplink power allocation. Adjusting the UE's uplink power allocation may allow the uplink power allocation to start from a power level closer to the power level last used by the UE (for example, when the UE was previously connected to the RAN), rather than gradually ramping up to the power level.

[0088] RAN can be configured to adjust secondary cell (SCell) addition strategies based on the CA band combination used in relation to UE. In other words, RAN can be configured to adjust UE's SCell addition strategy based on UE's historical use of CA band combinations. Adjusting UE's SCell addition strategy may include SCell addition based on event A1 (triggered when the serving cell performs above a threshold) or blind SCell addition.

[0089] RAN may be configured to adjust secondary node (e.g., SgNB) addition strategies based on the DC band combination used in relation to the UE. In other words, RAN may be configured to adjust the UE's secondary node addition strategy based on the UE's historical use of DC band combinations. Adjusting the UE's secondary node addition strategy may include SCell addition or blind sequence number (SN) addition based on event A1 (triggered when the serving cell performs better than a threshold).

[0090] In some implementations of the current subject, the core network may be configured to collect information associated with a particular UE while the UE is connected to the RAN. The core network may also be configured to store the collected information within the core network, uniquely associated with the UE (for example, storing the collected information in the UE context). In this way, the core network can store information collected by the core network and uniquely associated with a particular UE, even after the UE context for that particular UE has been released in the RAN. The information collected by the core network (CN) in relation to a particular UE is also referred to here as "core network context information".

[0091] If a UE later reconnects to the RAN, the core network may be configured to send CN context information collected by the core network during the UE's previous connection to the RAN to the RAN. This allows the RAN to access the UE-specific information collected by the core network immediately after the UE's reconnection, improving the RAN's service to the UE. The core network may also be configured to send CN context information to the RAN along with RAN context information, which is also sent from the core network to the RAN.

[0092] Various pieces of information associated with a specific UE connected to the RAN can be collected by the core network. In some implementations of the subject, UE-specific information collected by and stored in the core network (e.g., the UE context) may include the average downlink and uplink packet size per QoS flow (5G QoS Identifiers (5QI) / QoS Class Identifiers (QCI)), the average downlink and uplink packet arrival interval per QoS flow (5QI / QCI), and time-based traffic usage patterns related to the average downlink and uplink packet size and average downlink and uplink packet arrival interval per QoS flow (5QI / QCI).

[0093] The RAN can be configured to perform QCI / 5QI-specific scheduling alpha / beta tuning based on packet arrival intervals and volume. In other words, based on the UE's historical QoS flow (5QI / QCI) packet arrival intervals and volume, the RAN can be configured to perform QCI / 5QI-specific scheduling alpha / beta tuning for the UE. QCI / 5QI-specific scheduling alpha / beta tuning for the UE may include tuning the proportionally fair scheduler alpha / beta parameters for the UE.

[0094] RAN can be configured to perform UE admission control based on PDCCH CCE allocation statistics for UEs, MCS distribution for UEs, and time-based traffic usage patterns for UEs. In other words, RAN can be configured to perform UE admission control based on the historical PDCCH aggregation level, MCS distribution, and time-based traffic usage patterns of UEs. For example, if a UE has historically used aggressive data and its MCS distribution requires a large number of physical resource blocks (PRBs) to meet the traffic demand, and the current cell load cannot consistently provide such a large number of PRBs, then admission of the UE may not be necessary.

[0095] In some implementations of the present subject, a unique identifier for the UE (e.g., IMSI or SUPI) may be made available from the core network to the O-RAN non-real-time RAN intelligent controller (Non-RT RIC) or O-RAN near-real-time RAN intelligent controller (Near-RT RIC). In such implementations, the RAN may be configured to collect and transmit RAN context information to the core network and to receive RAN context information (and CN context information) from the core network, as described herein.

[0096] In some implementations of the current subject, the RAN may be configured to send usage information collected in relation to a specific UE in a UE context release complete message to the core network. The UE context release complete message is defined by 3GPP. Thus, the usage information may be sent from the RAN to the core network using messages already sent from the RAN to the core network in accordance with the 3GPP standard.

[0097] Figure 6 shows an exemplary system 600 relating to several implementations of the present subject, which includes a RAN configured to transmit usage information to the core network. System 600 in Figure 6 is a 5G system. Thus, the RAN (e.g., the RAN in Figure 3) includes a gNB 602 (e.g., the gNBs in Figures 5a-5c), and the core network (e.g., the core network 502 in Figure 5a) includes an Access and Mobility Management Function (AMF) 604.

[0098] As shown in the implementation in Figure 6, gNB602 sends a UE context release request to AMF604 in relation to a specific UE in accordance with the 3GPP standard (606). In response, AMF604 sends a UE context release command to gNB602 in relation to a specific UE in accordance with the 3GPP standard (608). In response, gNB602 sends a UE context release command to AMF604 in relation to a specific UE in accordance with the 3GPP standard (610). The UE context release command is sent in accordance with the 3GPP standard, except that the UE context release command also includes RAN context information collected by the RAN (610). The core network may be configured to send usage information back to the RAN in relation to UEs reconnecting to the RAN, as described herein.

[0099] The system 600 in Figure 6 can be similarly implemented in a 6G or later generation system that has a RAN that transmits usage information to the core network of a 6G or later generation system.

[0100] Figure 7 shows another exemplary system 700 relating to several implementations of the present subject, which includes a RAN configured to transmit usage information to the core network. The system 700 in Figure 7 is an LTE system. Thus, the RAN (e.g., EUTRAN102 in Figures 1a-1c and 2) includes eNB702 (e.g., eNBs106 in Figures 1b-2, eNB301 in Figure 3), and the core network (e.g., EPC108 in Figures 1a-1c and 2) includes a Mobility Management Entity (MME) 704 (e.g., MME114 in Figures 1c and 2).

[0101] As shown in the implementation in Figure 7, eNB702 sends a UE context release request to MME704 in relation to a specific UE in accordance with the 3GPP standard (706). In response, MME704 sends a UE context release command to eNB702 in relation to a specific UE in accordance with the 3GPP standard (708). In response, eNB702 sends a UE context release command to MME704 in relation to a specific UE in accordance with the 3GPP standard (710). The UE context release command is sent in accordance with the 3GPP standard, except that the UE context release command also includes RAN context information collected by the RAN (710). The core network may be configured to send usage information back to the RAN in relation to UEs reconnecting to the RAN, as described herein.

[0102] In some implementations, usage information may be transmitted to the core network as an octet string that is transparent to the core network (610, 710). Since the usage information is useful and understandable to the RAN but not useful or understandable to the core network, the octet string may also be an opaque binary blob. Thus, transmitting usage information as an opaque binary blob (610, 710) is useful for transferring RAN vendor-specific information to the core network that does not need to be interpreted by the core network.

[0103] Figure 8 shows exemplary methods 800 relating to several implementations of the present subject. For convenience of explanation, methods 800 are described in relation to the exemplary system 900 shown in Figure 9, but can be implemented in other systems as well. Although system 900 in Figure 9 is a 5G system, as previously mentioned, providing user equipment-specific services in a wireless access network as described here can also be done in other types of wireless communication systems.

[0104] Method 800 includes a UE902 that connects to the RAN904 (802) in accordance with the 3GPP standard. The RAN904 of the 5G system 900 in Figure 9 (e.g., the RAN in Figure 3) includes a gNB906 (e.g., the gNB in ​​Figures 5a-5c, the gNB602 in Figure 6). The UE's connection to the RAN904 (802) may be the first connection of the UE902 to the RAN904 configured to provide UE-specific services as described herein, or it may be the first connection of the UE902 to the RAN904 after the RAN904 has been updated to provide UE-specific services as described herein. With the UE902 connected to the RAN904, the RAN904 collects or gathers RAN context information about the UE902 as described herein (804).

[0105] Furthermore, a core network 908 (e.g., core network 502 in Figure 5a) that is communicatively coupled with RAN904 collects or gathers CN context information about UE902 as described herein (804). The core network 908 of the 5G system 900 in Figure 9 includes AMF910 (e.g., AMF604 in Figure 6), SMF912, and UPF914.

[0106] As shown in Figure 9, the core network 908 (804) that collects CN context information may include a UPF914 that monitors packet volume and packet arrival rate per QoS flow for UE902. The UPF916 can send a PFCP session report request to the SMF912 in accordance with the 3GPP standard, except that the PFCP session report request also includes the collected (804) CN context information as a session report to the SMF912 (918). Thus, the CN context information collected by the UPF914 may be transmitted to the SMF912 using a message already sent from the UPF914 to the SMF912 in accordance with the 3GPP standard. The SMF912 stores the received CN context information (920). Also, upon receiving the PFCP session report request, the SMF912 sends a PFCP session report response to the UPF914 in accordance with the 3GPP standard (922).

[0107] At some point during the UE's connection to RAN904, for example, when UE902 transitions to IDLE, RAN904 may send a UE context release request message to core network 908 in accordance with the 3GPP standard (806). Upon receiving the UE context release request message, core network 908 sends a UE context release command to RAN904 in accordance with the 3GPP standard (808). Upon receiving the UE context release command, RAN904 sends a UE context release completion message to core network 908 in accordance with the 3GPP standard, except that it also transmits the RAN context information collected by RAN904 (804) as described herein (810). Core network 908 stores the received RAN context information as described herein (812).

[0108] At some point after the UE context has been released, UE902 can reconnect with RAN904 (814). RAN904 receives RAN context information and CN context information from core network 902 (814) and may use this information to provide services to UE902, as discussed here.

[0109] More specifically, as shown in the implementation in Figure 9, the connection of UE902 to RAN904 (814) includes UE902 sending an RRC setup request message to RAN904 (e.g., gNB904) (924) in accordance with the 3GPP standard. Upon receiving the RRC setup request message, RAN904 (e.g., gNB904) sends an RRC setup message to UE902 (926) in accordance with the 3GPP standard. Upon receiving the RRC setup message, UE902 sends an RRC setup complete (NAS service request) message to RAN904 (e.g., gNB906) (928) in accordance with the 3GPP standard. Upon receiving the RRC setup complete (NAS service request) message, RAN904 (e.g., gNB906) sends an initial UE message (service request) to the core network 908 (e.g., AMF910) (930) in accordance with the 3GPP standard.

[0110] Upon receiving the initial UE message (service request), AMF910 sends an update SM context message to SMF912 in accordance with the 3GPP standard (932). Upon receiving the update SM context message, SMF912 sends an update SM context response to AMF910 in accordance with the 3GPP standard, except that the update SM context response also transmits RAN context information and CN context information for UE902 (934). Upon receiving the update SM context response, core network 908 (e.g., AMF910) sends an initial context setup request to RAN904 (e.g., gNB906) in accordance with the 3GPP standard, except that the initial context setup request also transmits RAN context information and CN context information received by AMF910 from SMF912 (936). In other words, in addition to the initial context setup request that transmits information such as expected UE activity behavior (including expected UE activity period and expected UE idle period), expected handover (HO) interval, and expected UE mobility, as defined by 3GPP, the initial context setup request also transmits RAN context information and CN context information. Then, as discussed here, RAN904 can use the RAN context information and CN context information when providing services to UE902.

[0111] Upon receiving the initial context setup request, RAN904 (e.g., gNB906) sends an RRC reconfiguration request to UE902 in accordance with the 3GPP standard (938). Upon receiving the RRC reconfiguration request, UE902 sends an RRC reconfiguration response to RAN904 (e.g., gNB906) in accordance with the 3GPP standard (940).

[0112] Upon receiving the RRC reconfiguration response, RAN904 (e.g., gNB906) sends an initial context setup response to core network 908 (e.g., AMF910) in accordance with the 3GPP standard (942).

[0113] Upon receiving the initial context setup response, AMF910 sends an update SM context message to SMF912 in accordance with the 3GPP standard (944). Upon receiving the update SM context message, SMF912 sends an update SM context message to AMF910 (946).

[0114] Then, UE902 can communicate over wireless communication system 900 in accordance with 3GPP standards, and method 800 continues as described above (RAN collects RAN context information (804), and core network 908 collects CN context information (804)).

[0115] Method 800 may be performed in relation to each UE that is communicatively coupled to RAN 904. Method 800 may be performed in relation to each RAN that is communicatively coupled to core network 908.

[0116] In some implementations, the subject may be configured to be implemented in system 1000 as shown in Figure 10. System 1000 may include one or more of the following: processor 1010, memory 1020, storage device 1030, and input / output device 1040. Each of the components 1010, 1020, 1030, and 1040 may be interconnected using the system bus 1050. Processor 1010 may be configured to process instructions for execution within system 600. In some implementations, processor 1010 may be a single-threaded processor. In alternative implementations, processor 1010 may be a multi-threaded processor. Processor 1010 may be further configured to process instructions stored in memory 1020 or storage device 1030, including receiving or transmitting information through the input / output device 1040. Memory 1020 can store information within system 1000. In some implementations, memory 1020 may be computer-readable media. In alternative implementations, memory 1020 may be a volatile memory unit. In some further implementations, memory 1020 may be a non-volatile memory unit. Storage device 1030 may provide mass storage for system 1000. In some implementations, storage device 1030 may be a computer-readable medium. In alternative implementations, storage device 1030 may be a floppy disk device, a hard disk device, an optical disk device, a tape device, a non-volatile solid-state memory, or any other type of storage device. Input / output device 1040 may be configured to provide input / output operations for system 1000. In some implementations, input / output device 1040 may include a keyboard and / or a pointing device. In alternative implementations, input / output device 1040 may include a display unit for displaying a graphical user interface.

[0117] Figure 11 shows an exemplary method 1100 for providing user-specific services in a wireless access network, relating to several implementations of the present subject. Method 1100 may be performed using, for example, the implementations shown and described with respect to Figures 6-9.

[0118] Method 1100 includes receiving usage information (e.g., RAN context information) uniquely associated with a UE having a UE context from a RAN (e.g., EUTRAN 102 in Figures 1a-1c and 2, RAN in Figure 3, RAN in Figure 9, etc.) in a core network (e.g., EPC 108 in Figures 1a-1c and 2, core network 502 in Figure 5a, core network 908 in Figure 9, etc.) (1102). Usage information may be collected by the RAN. The method may also include storing the received usage information in the core network (e.g., the memory of the core network) after the UE context has been released (1104).

[0119] In some implementations, the subject may include one or more of the following optional features:

[0120] In some implementations, usage information may include one or more of the following: Physical Downlink Control Channel (PDCCH) control channel element (CCE) allocation statistics for the UE, block error rate (BLER) distribution for the UE, modulation and coding scheme (MCS) distribution for the UE, uplink power allocation history based on transmit power control (TPC) commands transmitted in relation to the UE, carrier aggregation (CA) band combinations used in relation to the UE, and dual connectivity (DC) band combinations used in relation to the UE. Furthermore, the method may further include transmitting an octet stream along with the usage information from the RAN to the core network.

[0121] In some implementations, usage information may be sent from the RAN to the core network in the UE Context Release Complete message.

[0122] In some implementations, the method may further include sending stored usage information from the core network to the RAN after the UE context has been released. Furthermore, the RAN may be configured to use the received usage information to fine-tune UE-specific scheduling behavior and CA and DC carrier addition strategies. The RAN may be configured to use the received information in one or more of the following: tuning proportional-equal scheduler alpha / beta parameters, tuning UE-specific PDCCH search space, tuning CCE aggregation levels, tuning uplink power allocation to start from approximately the power level last used by the RAN for the UE, tuning initial MCS and / or BLER targets, and tuning the UE's connection mode DRX configuration. The core network may send stored usage information to the RAN in an Initial Context Setup Message associated with a UE reconnecting to the RAN.

[0123] In some implementations, the method may further include a User Plane Function (UPF) of the core network (e.g., UPF914 in Figure 9) that collects average packet arrival time information associated with the UE for each Quality of Service (QoS) flow. Furthermore, the method may further include a UPF that transmits the collected information to the Session Management Function (SMF) of the core network (e.g., SMF912 in Figure 9). Furthermore, the UPF can transmit the collected information to the SMF in a Packet Forwarding Control Protocol (PFCP) Session Report Request message. Furthermore, the method may further include an SMF that transmits the collected information to the Access and Mobility Management Function (AMF) of the core network (e.g., AMF604 in Figure 6, AMF910 in Figure 9). Furthermore, the SMF can send the collected information to the AMF in an Update Session Management (Update SM) Context Response message. The method may further include the AMF sending the collected and stored usage information to the RAN. Additionally, the AMF can send the collected and stored usage information to the RAN in an Initial Context Setup Message. The AMF can also send one or more uplink and downlink volumes and uplink and downlink flow times per QoS flow to the RAN.

[0124] In some implementations, the core network can store usage information associated with a unique identifier for the UE, which can be an IMSI (International Mobile Subscriber Identity) or SUPI (Subscription Permanent Identifier).

[0125] In some implementations, the RAN includes base stations, including eNodeBs (e.g., eNBs106 in Figures 1b-2, eNB301 in Figure 3, eNB702 in Figure 7, etc.), and the core network may be the core network of the LTE system.

[0126] In some implementations, the RAN includes base stations, including gNodeBs (e.g., gNBs in Figures 5a-5c, gNB602 in Figure 6, gNB906 in Figure 9, etc.), and the core network can be the core network of a 5G system or a post-5G next-generation system.

[0127] The systems and methods disclosed herein can be embodied in various forms, including, for example, data processors such as computers, which may also include databases, digital electronic circuits, firmware, software, or combinations thereof. Furthermore, the aforementioned features and other aspects and principles of the disclosed implementations can be implemented in various environments. Such environments and associated applications may be specifically configured to perform various processes and operations relating to the disclosed implementations, or they may include general-purpose computers or computing platforms that are selectively activated or reconfigured by code to provide the necessary functions. The processes disclosed herein are not inherently related to any particular computer, network, architecture, environment, or other device, and can be implemented by an appropriate combination of hardware, software, and / or firmware. For example, various general-purpose devices may be used with programs written in accordance with the teachings of the disclosed implementations, or they may be more convenient for configuring dedicated devices or systems to perform the necessary methods and techniques.

[0128] The systems and methods disclosed herein may be implemented as computer program products (i.e., computer programs tangibly embodied in information carriers (e.g., machine-readable storage devices or propagating signals) for execution by or control of the operation of data processing devices (e.g., programmable processors, computers, or multicomputers)). Computer programs may be written in any form of programming language, including compiled or interpreted languages, and may be deployed in any form, including standalone programs or modules, components, subroutines, or other units appropriate for use in a computing environment. Computer programs may be deployed to run on a single computer or multicomputers, distributed across multiple sites and interconnected by a communication network, either at a single site or across multiple sites.

[0129] As used herein, the term “user” can refer to any entity, including a person or a computer.

[0130] While sequential numbers such as "1st," "2nd," etc., may indicate order in some contexts, the sequential numbers used in this document do not necessarily imply order. For example, sequential numbers may simply be used to distinguish one item from another. For instance, distinguishing the first event from the second event does not necessarily imply a temporal order or a fixed reference system (just as the first event in one paragraph of the description may differ from the first event in another paragraph of the description).

[0131] The above description is for illustrative purposes only and is not intended to limit the scope of the invention as defined by the attached claims. Other implementations are also within the scope of the following claims.

[0132] These computer programs, software, software applications, applications, components, or code, which may also be referred to as programs, contain machine instructions for a programmable processor and may be implemented in high-level procedural and / or object-oriented programming languages ​​and / or assembly / machine languages. As used herein, the term “machine-readable medium” refers to any computer program product, apparatus and / or device (e.g., magnetic disks, optical disks, memory and programmable logic devices (PLDs)) used to provide machine instructions and / or data to a programmable processor, and includes machine-readable medium that receives machine instructions as machine-readable signals. The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor. Machine-readable medium may store such machine instructions non-temporarily (e.g., non-temporarily solid-state memory or magnetic hard drives or any equivalent storage medium). Alternatively, machine-readable medium may store such machine instructions in a temporary manner (e.g., processor cache or other random-access memory associated with one or more physical processor cores).

[0133] To provide user interaction, the subject described herein may be implemented on a computer having a display device such as a cathode ray tube (CRT) or liquid crystal display (LCD) monitor for displaying information to the user, and a pointing device such as a keyboard and mouse or trackball to which the user can provide input to the computer. Other types of devices may also be used to provide user interaction. For example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or haptic feedback. Input from the user may be received in any form, including but not limited to acoustic, speech, or haptic input.

[0134] The subject matter described herein may be implemented in a computing system that includes one or more backend components such as data servers, or one or more middleware components such as application servers, or one or more frontend components such as client computers having a graphical user interface or web browser on which users can interact with the implementation of the subject matter described herein, or any combination of such backend, middleware, or frontend components. The components of the system may be interconnected by digital data communication in any form or medium such as a communication network. Examples of communication networks include, but are not limited to, local area networks ("LANs"), wide area networks ("WANs"), and the Internet.

[0135] A computing system may include clients and servers. Clients and servers are generally (but not limited to) separate from each other and typically interact through a communication network. The client-server relationship arises from computer programs running on each computer, and these programs have a client-server relationship with each other.

[0136] The implementations presented in the above description do not represent all implementations consistent with the subject matter described herein. Rather, they are merely some examples consistent with aspects related to the subject matter described herein. A few variations have been described in detail prior to this, but other modifications or additions are possible. In particular, further features and / or variations may be provided in addition to those presented herein. For example, the implementations described herein may be directed toward various combinations and subcombinations of the disclosed features, and / or combinations and subcombinations of some of the further features disclosed above. In addition, the logical flows shown in the accompanying diagrams and / or described herein do not necessarily require a specific order or sequence shown to achieve the desired result. Other implementations may also be within the scope of the following claims.

Claims

1. In the core network, the network receives usage information collected by the Radio Access Network (RAN) that is uniquely associated with user devices (UEs) having a UE context. After the UE context is released, the received usage information is stored in the core network, After the UE context is released, the stored usage information is transmitted from the core network to the RAN. Equipped with, The RAN is configured to use the usage information received from the core network to fine-tune UE-specific scheduling behavior and carrier aggregation (CA) and dual connectivity (DC) carrier addition strategies. Computer implementation method.

2. The method according to claim 1, wherein the usage information includes one or more of the following: physical downlink control channel (PDCCH) control channel element (CCE) allocation statistics for the UE, block error rate (BLER) distribution for the UE, modulation and coding scheme (MCS) distribution for the UE, uplink power allocation history based on transmit power control (TPC) commands transmitted in connection with the UE, carrier aggregation (CA) band combinations used in connection with the UE, and dual connectivity (DC) band combinations used in connection with the UE.

3. The method according to claim 1, wherein the usage information is transmitted from the RAN to the core network in a UE Context Release Complete message.

4. The method according to claim 1, wherein the RAN is configured to use the usage information received from the core network in one or more of the following: tuning of proportional-equal scheduler alpha / beta parameters, tuning of UE-specific physical downlink control channel (PDCCH) search space, tuning of control channel element (CCE) aggregation levels, tuning of uplink power allocation to start from approximately the power level last used by the RAN for the UE, tuning of initial modulation and coding scheme (MCS) and / or block error rate (BLER) targets, and tuning of the UE's connection mode discontinuous reception (DRX) configuration.

5. The method according to claim 1, wherein the core network transmits the stored usage information to the RAN in an initial context setup message associated with the UE reconnecting to the RAN.

6. The method according to claim 1, further comprising a User Plane Function (UPF) of the core network that collects average packet arrival interval information associated with the aforementioned UE for each Quality of Service (QoS) flow.

7. The method according to claim 6, further comprising the UPF for transmitting the collected information to the Session Management Function (SMF) of the core network.

8. The method according to claim 7, wherein the UPF transmits the collected information to the SMF in a Packet Forwarding Control Protocol (PFCP) Session Report Request message.

9. The method according to claim 7, further comprising the SMF which transmits the collected information to the Access and Mobility Management Function (AMF) of the core network.

10. The method according to claim 7, wherein the SMF transmits the collected information to the AMF in an Update Session Management (Update SM) Context Response message.

11. The method according to claim 9, further comprising the AMF for transmitting the collected information and the stored usage information to the RAN.

12. The method according to claim 11, wherein the AMF transmits the collected information and the stored usage information to the RAN in an initial context setup message.

13. The method according to claim 11, wherein the AMF also transmits one or more of the uplink and downlink volumes and uplink and downlink flow times for each QoS flow to the RAN.

14. The method according to claim 1, wherein the core network stores the usage information in association with a unique identifier of the UE, which is an IMSI (International Mobile Subscriber Identity) or SUPI (Subscription Permanent Identifier).

15. The aforementioned RAN includes a base station including an eNodeB, The aforementioned core network is the core network of the LTE system. The method according to claim 1.

16. The aforementioned RAN includes a base station including a gNodeB, The aforementioned core network is the core network of a 5G system or a next-generation system after 5G. The method according to claim 1.

17. In the core network, the network receives usage information collected by the Radio Access Network (RAN) that is uniquely associated with user devices (UEs) having a UE context. After the UE context is released, the received usage information is stored in the core network, After the UE context is released, the stored usage information is transmitted from the core network to the RAN. Perform an operation that includes the following: The RAN is configured to use the usage information received from the core network to fine-tune UE-specific scheduling behavior and carrier aggregation (CA) and dual connectivity (DC) carrier addition strategies. Device.

18. When executed by at least one processor, In the core network, the network receives usage information collected by the Radio Access Network (RAN) that is uniquely associated with user devices (UEs) having a UE context. After the UE context is released, the received usage information is stored in the core network, After the UE context is released, the stored usage information is transmitted from the core network to the RAN. The instructions for causing at least one processor to perform an operation comprising the above are stored, The RAN is configured to use the usage information received from the core network to fine-tune UE-specific scheduling behavior and carrier aggregation (CA) and dual connectivity (DC) carrier addition strategies. At least one non-temporary storage medium.

19. The method according to claim 1, wherein the usage information is received from the RAN in the core network together with a temporary identifier of the UE, and stored in the core network in association with a non-temporary identifier of the UE.

20. The usage information is transmitted from the RAN to the core network in a "UE CONTEXT RELEASE COMPLETE" message in response to a UE context release command transmitted from the core network to the RAN, The aforementioned UE context release command is transmitted by the core network in response to a UE context release request received from the RAN. The method according to claim 1.

Images