Method for deriving periodic RAN notification area (RNA) update timer (T380) for RRC-inactive UEs

Abstract

A method, apparatus, and computer-readable medium for configuring a periodic radio access network (RAN) notification area (RNA) update timer based on a periodic registration update timer, the method including: obtaining a periodic registration update timer value provided by a core network; and determining, based on the obtained periodic registration update timer value, a RNA update timer value, such that the RNA update timer value is less than the obtained periodic registration update timer value and less than a predetermined maximum value for the RNA update timer.

Description

[Technical Field]

[0001] Apparatus and methods consistent with example embodiments of the present disclosure relate to configuring a periodic Radio Access Network (RAN) notification area update timer (e.g., T380) based on a periodic registration update timer provided by the core network. [Background technology]

[0002] In related art telecommunications standards (e.g., 3GPP® specifications for 5G), the Radio Resource Control (RRC) protocol defines signaling exchanged between User Equipment (UE) and base stations over the air interface. RRC operation is guided by a state machine that defines various RRC states that a UE can be in. 3GPP has defined an RRC-Inactive state mechanism (introduced in the 5G standard) in which a User Equipment (UE) context is maintained in an inactive (e.g., hibernated) state within the Radio Access Network (RAN) while the UE's Connection Management (CM) with the core network is still maintained in a CM-CONNECTED state.

[0003] When the UE is in the RRC-Inactive state, the UE does not notify the RAN of a cell change as long as it is within the RAN Notification Area (RNA) provided to the UE. To this end, the UE performs periodic RNA updates to the RAN based on a periodic RNA update timer (e.g., T380) provided to the UE. The UE also maintains a periodic registration update area timer (e.g., T3512) for performing periodic registration update procedures towards the core network. The T380 value provided to the UE should not exceed the T3512 value, as otherwise the UE may wake up and signal to the core network before waking up and signaling to the RAN. Summary of the Invention [Means for solving the problem]

[0004] According to embodiments, systems and methods are provided for adjusting a periodic RAN notification area update timer (eg, T380) based on a periodic registration area timer provided by a core network.

[0005] According to one or more embodiments, a method implemented by at least one processor for configuring a periodic registration update timer based on a periodic registration update timer includes obtaining a periodic registration update timer value provided by a core network, and determining an RNA update timer value based on the obtained periodic registration update timer value, such that the RNA update timer value is less than the obtained periodic registration update timer value and less than a predetermined maximum value for the RNA update timer.

[0006] Determining the RNA update timer value may include determining a parameter based on a periodic registration update timer, and determining the RNA update timer value based on the parameter and the periodic registration update timer value.

[0007] Determining the RNA update timer value may include configuring and / or updating parameters via an O1 interface between a Service Management and Orchestration (SMO) framework and a centralized unit of the RAN.

[0008] Determining the parameter may include receiving, by an xApp of a near real-time RAN Intelligent Controller (RIC), a periodic registration update timer value, and determining, by the xApp, the parameter based on the received periodic registration update timer value. Determining the RNA update timer value based on the parameter and the periodic registration update timer value may include receiving, by a centralized unit of the RAN, the parameter from the near real-time RIC via an E2 interface, and determining, by the centralized unit, the RNA update timer based on the parameter and the periodic registration update timer value.

[0009] Determining the parameter may include determining whether the received periodic registration update timer value is greater than a predetermined maximum value for the RNA update timer, determining that the parameter is equal to (predetermined maximum value for the RNA update timer / received periodic registration update timer value) based on the received periodic registration update timer value being greater than the predetermined maximum value for the RNA update timer, and determining that the parameter is equal to ((predetermined maximum value for the RNA update timer-received periodic registration update timer value) / predetermined maximum value for the RNA update timer) based on the received periodic registration update timer value being less than or equal to the predetermined maximum value for the RNA update timer.

[0010] Determining, by the centralized unit, the RNA update timer value based on the parameter and the periodic registration update timer value may include determining that the RNA update timer value is equal to (parameter * periodic registration update timer value) and rounding to the nearest value of an enumeration of RNA update timer values ​​specified in the 3GPP specifications.

[0011] The RNA update timer value may be determined by the xApp of the near real-time RIC using the periodic registration update timer value and provided to the RAN centralized unit via the E2 interface.

[0012] Determining the RNA update timer value may include determining whether the periodic registration update timer value is greater than a predetermined maximum value for the RNA update timer, determining that the RNA update timer value is equal to the predetermined maximum value for the RNA update timer based on the periodic registration update timer value being greater than the predetermined maximum value for the RNA update timer, and determining that the RNA update timer value is equal to (periodic registration update timer value - (periodic registration update timer value squared / predetermined maximum value for the RNA update timer)) based on the periodic registration update timer value being less than or equal to the predetermined maximum value for the RNA update timer.

[0013] Determining the RNA update timer value may include determining, by the xApp, the RNA update timer value based on an average user equipment (UE) residence time within the RAN.

[0014] The average UE residence time in the RAN may be calculated by the xApp based on the UE grant time and UE release time averaged over multiple UEs.

[0015] The xApp determines the UE grant time and UE release time based on the UE grant and UE release events notified by the centralized unit (via E2).

[0016] Determining the RNA update timer value may include determining, by the xApp, the RNA update timer value based on an average downlink inter-packet arrival interval in the RRC-Inactive state.

[0017] The xApp determines the average downlink inter-packet arrival time based on the average time difference between two downlink data notifications received for the UE.

[0018] The arrival of downlink data notification at the Centralized Unit (CU) can be indicated to the xApp through the E2 interface.

[0019] According to one or more embodiments, an apparatus for configuring a periodic registration update timer based on a periodic registration update timer includes: a memory that stores instructions; and at least one processor that is configured to execute the instructions to obtain a periodic registration update timer value provided by a core network, and to determine an RNA update timer value based on the obtained periodic registration update timer value, such that the RNA update timer value is less than the obtained periodic registration update timer value and less than a predetermined maximum value for the RNA update timer.

[0020] The at least one processor may be further configured to determine the RNA update timer value by configuring and / or updating parameters via an O1 interface between the service management and SMO framework and a centralized unit of the RAN.

[0021] The at least one processor may be further configured to determine the parameter by receiving, by an xApp of the near real-time RIC, a periodic registration update timer value, and determining, by the xApp, a parameter based on the received periodic registration update timer value, wherein determining the RNA update timer value based on the parameter and the periodic registration update timer value may include receiving, by a centralized unit of the RAN, the parameter from the near real-time RIC via an E2 interface, and determining, by the centralized unit, the RNA update timer based on the parameter and the periodic registration update timer value.

[0022] The at least one processor is further configured to determine the parameter by determining whether the received periodic registration update timer value is greater than a predetermined maximum value for the RNA update timer, determining that the parameter is equal to (predetermined maximum value for the RNA update timer / received periodic registration update timer value) based on the received periodic registration update timer value being greater than the predetermined maximum value for the RNA update timer, and determining that the parameter is equal to ((predetermined maximum value for the RNA update timer-received periodic registration update timer value) / predetermined maximum value for the RNA update timer) based on the received periodic registration update timer value being less than or equal to the predetermined maximum value for the RNA update timer.

[0023] According to one or more embodiments, a non-transitory computer-readable storage medium having stored thereon instructions executable by at least one processor to perform a method for configuring a periodic registration update timer based on a periodic registration update timer includes obtaining a periodic registration update timer value provided by a core network, and determining an RNA update timer value based on the obtained periodic registration update timer value, such that the RNA update timer value is less than the obtained periodic registration update timer value and less than a predetermined maximum value for the RNA update timer.

[0024] Additional aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of presented embodiments of the present disclosure.

[0025] Features, aspects, and advantages of certain exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals refer to like elements. [Brief explanation of the drawings]

[0026] [Figure 1A] FIG. 1A is a diagram illustrating an O-RAN architecture in the related art. [Figure 1B]FIG. 1B is a diagram illustrating an O-RAN architecture in the related art.

[0027] [Figure 2] FIG. 2 is a diagram showing a RAN Intelligent Controller (RIC) architecture in the related art.

[0028] [Figure 3] FIG. 3 is a flowchart for calculating t380DerivationAssistancevalue according to one or more embodiments.

[0029] [Figure 4] FIG. 4 illustrates a call flow for adjustment of t380DerivationAssistancevalue from a near real-time RIC, according to one or more embodiments.

[0030] [Figure 5] FIG. 5 is a flowchart for calculating the T380 timer value according to one or more embodiments.

[0031] [Figure 6] FIG. 6 illustrates a call flow for T380 control from a near real-time RIC in accordance with one or more embodiments.

[0032] [Figure 7] FIG. 7 illustrates a call flow for deriving a T380 timer value based on continuous monitoring of all UE residence times within the RAN, in accordance with one or more embodiments.

[0033] [Figure 8] FIG. 8 illustrates a call flow for deriving a T380 timer value based on monitoring inter-packet arrival times in the downlink direction, according to one or more embodiments.

[0034] [Figure 9] FIG. 9 is a diagram of an example environment in which the systems and / or methods described herein may be implemented.

[0035] [Figure 10] FIG. 10 is a diagram of exemplary components of a device, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0036] The following detailed description of the exemplary embodiments refers to the accompanying drawings, in which the same reference numbers in different drawings may identify the same or similar elements.

[0037] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Moreover, one or more features or components of one embodiment may be combined with or incorporated into other embodiments (or one or more features of other embodiments). Furthermore, in the flowcharts and descriptions of operations provided below, it should be understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) concurrently, and the order of one or more operations may be rearranged.

[0038] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Accordingly, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It should be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0039] Although particular combinations of features are recited in the claims and / or disclosed herein, these combinations do not limit the disclosure of possible implementations. Indeed, many of these features may be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0040] No element, act, or instruction used herein should be construed as critical or required unless explicitly stated. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "one" or similar language is used. Also, as used herein, terms such as "has," "have," "having," "include," and "including" are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless specifically stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0041] The example embodiments provide a system and method for adjusting a periodic RAN notification area update timer based on a periodic registration area timer provided by a core network.

[0042] In the prior art, the Access and Mobility Management Function (AMF) of a 5G core network transmits RRC inactive assistance information to a 5G radio access network (NG-RAN). In this regard, the AMF provides assistance information to the NG-RAN to assist the NG-RAN in determining whether the UE can be placed in an RRC-inactive state. The RRC inactive assistance information includes, among other things, a registration area provided to the UE, a periodic registration update timer (T3512), and other information. The periodic registration update procedure is performed by the UE toward the core network to periodically notify the network of the UE's availability. This procedure is performed in the UE based on a periodic registration update timer (T3512) that is started in 5GMM-REGISTERED mode when the UE exits 5GMM-CONNECTED mode. The value of the T3512 timer according to the 3GPP standard in the related art can be up to 320 hours.

[0043] Furthermore, 3GPP provides that when the UE transitions to a CM-CONNECTED state for communication with the core network while in an RRC Inactive state, the NG-RAN configures the UE with a periodic RNA update timer (T380) that can be up to 12 hours. Therefore, the maximum value of the T3512 timer is much greater than the maximum value of the T380 timer.

[0044] Also, the T3512 timer is started in the UE only after the UE enters the CM-IDLE state. While in the RRC-Inactive state in the RAN, the UE remains in the CM-CONNECTED state with the core network, and therefore the UE does not start the T3512 timer. Therefore, the T380 timer does not need to be larger than the T3512 timer in the UE.

[0045] While related art standards may specify that a periodic registration update timer (T3512) be transmitted as assistance information from a core network to a RAN, the related art does not specify how the RAN uses the T3512 timer to adjust or configure the T380 timer for a UE. As described below, one or more exemplary embodiments provide a method for configuring the T380 timer for a UE based on the periodic registration update timer (T3512) from a core network. An advantage of configuring the T380 timer in accordance with one or more embodiments is that it provides flexibility to operators to optimize the T380 timer based on the periodic registration update timer used in the core network to efficiently and accurately ensure that the T380 timer is configured to be less than the T3512 timer.

[0046] The T380 timer may be provided to the UE from the RAN (e.g., base station, gNB-CU-CP, or ng-eNB-CU-CP) in the RRCRelease message in the following container: SuspendConfig::=SEQUENCE { fullI-RNTI I-RNTI-Value, shortI-RNTI ShortI-RNTI-Value, ran-PagingCycle PagingCycle, ran-NotificationAreaInfo RAN-NotificationAreaInfo OPTIONAL,--Need M t380 PeriodicRNAU-TimerValue OPTIONAL,--Need R nextHopChainingCount NextHopChainingCount, ... }

[0047] According to one or more embodiments, a configuration parameter (referred to herein as t380DerivationAssistancevalue) is used to derive the T380 timer value. According to an exemplary embodiment, the t380DerivationAssitancevalue may be made available to the base station or gNB-CU-CP / ng-eNB-CUP-CP as an O1 configuration / parameter. That is, this parameter may be configured in the CU-CP and / or updated / modified from the SMO via the O1 interface. This parameter represents the ratio of the T380 timer to the Periodic Registration Update (PRU) timer (T3512) value. Since the T380 timer value cannot be greater than the PRU timer value, the t380DerivationAssistancevalue is a decimal number ranging from 0 to 1. The UE is provided with the T380 timer value, for example, using the following calculation: T380=t380DerivationAssistancevalue * periodicRegistrationUpdateTimer

[0048] According to one or more other embodiments, the t380DerivationAssitance value is derived or determined in a near-real-time RIC in an Open RAN (O-RAN) architecture. In the O-RAN architecture, RAN functions are divided into a Centralized Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU). The CU is a logical node for hosting the Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers of the RAN. The CU can be further divided into a CU-CP that hosts the RRC and a CU-UP that hosts the SDAP and PDCP. The DU is a logical node for hosting the Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. The RU is a physical node that converts radio signals from the antenna into digital signals that can be transmitted to the DU via the fronthaul. These entities have open protocols and interfaces between them, so they can be developed by different vendors.

[0049] 1A and 1B are diagrams illustrating the O-RAN architecture of the related art, and FIG. 2 is a diagram illustrating the RIC architecture of the related art. Referring to FIGS. 1A, 1B, and 2, RAN functions in the O-RAN architecture are controlled and optimized by the RIC. The RIC is a software-defined component that implements modular applications to facilitate the multi-vendor operability required in the O-RAN system and to automate and optimize RAN operations. RICs are divided into two types: non-real-time RIC (NRT-RIC) and near-real-time RIC (nRT-RIC).

[0050] The non-real-time RIC is the control point for non-real-time control loops and operates on timescales greater than one second within the SMO framework. Its functions are implemented through modular applications called rApps (rApp1, ..., rAppN in Figure 1A) and include: providing policy-based guidance and reinforcement over the A1 interface, which is the interface enabling communication between non-real-time RICs and near-real-time RICs; performing data analytics; artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions via the O1 interface, which is the interface connecting the SMO to RAN managed elements (e.g., near-real-time RICs, O-RA Centralized Unit (O-CU), O-RAN Distributed Units (O-DU), etc.).

[0051] The near-real-time RIC operates on a timescale between 10 milliseconds and 1 second and connects to the O-DU, O-CU (split into the O-CU control plane (O-CU-CP) and the O-CU user plane (O-CU-UP)), and Open Evolved NodeB (O-eNB) via the E2 interface. The near-real-time RIC uses the E2 interface to control the underlying RAN elements (E2 nodes / Network Functions (NFs)) via near-real-time control loops. The near-real-time RIC monitors, suspends / suspends, overrides, and controls the E2 nodes (O-CU, O-DU, and O-eNB) via policies. For example, the near-real-time RIC sets policy parameters on the activated functions of the E2 nodes. Additionally, the near-real-time RIC hosts xApps to implement functions such as Quality of Service (QoS), mobility optimization, slicing optimization, interference mitigation, load balancing, and security. The two types of RICs work together to optimize the O-RAN. For example, the non-real-time RIC provides policies, data, and AI / ML models over the A1 interface that are executed and used by the near-real-time RIC for RAN optimization, and the near-real-time returns policy feedback (i.e., how the policies set by the non-real-time RIC are performing).

[0052] The SMO framework, within which the non-real-time RIC is located, manages and orchestrates RAN elements. Specifically, the SMO manages and orchestrates what is referred to as the O-RAN Cloud (O-Cloud). The O-Cloud is a collection of physical RAN nodes that host the RIC, O-CU, and O-DU, supporting software components (e.g., operating systems and runtime environments), and the SMO itself. In other words, the SMO manages the O-Cloud from within. The O2 interface is the interface between the SMO and the O-Cloud in which the SMO resides. Through the O2 interface, the SMO provides infrastructure management services (IMS) and deployment management services (DMS).

[0053] As described above, in various exemplary embodiments, the T380 derivation assistance value (referred to as t380DerivationAssistancevalue, for example) is determined or calculated at the gNB-CU-CP / ng-eNB-CUP-CP or near-real-time RIC.

[0054] FIG. 3 illustrates a flowchart for calculating a T380 derivation assistance value for a T380 timer, according to one or more embodiments. According to an exemplary embodiment, an xApp hosted in a near-real-time RIC calculates the t380DerivationAssistanceValue using the T3512 value. The T3512 value may be obtained from a CU-CP (e.g., a gNB-CU-CP or an ng-eNB-CU-CP) that receives the value from a core network (e.g., an AMF) via RRC inactive assistance information. As described above, the t380DerivationAssistanceValue may be a decimal value ranging from 0 to 1, which is multiplied with the T3512 value to obtain T380. However, the maximum T3512 value (320 hours) is substantially greater than the maximum T380 value (12 hours). Therefore, according to an exemplary embodiment, the xApp may include logic that implements various rules to ensure that the t380DerivationAssistanceValue does not result in a T380 value that exceeds the maximum value.

[0055] Referring to FIG. 3, in step 311, the T3512 value is obtained from the gNB-CU-CP / ng-eNB-CU-CP, and a variable x is set to T3512 in minutes. In step 312, it is determined whether x is greater than the maximum value of T380 (720 minutes). If x is greater than 720 minutes, the t380DerivationAssistanceValue is set to 720 / x (step 313). If x is less than or equal to 720 minutes, the t380DerivationAssistanceValue is set to (720-x) / 720 (step 314). The above calculation is merely an example embodiment. Other mechanisms for deriving the t380DerivationAssistanceValue that are in the range of 0 to 1 and provide a T380 less than or equal to the maximum value may also be used.

[0056] 4 illustrates a call flow diagram for control of the t380DerivationAssistancevalue from a near-real-time RIC, according to one or more embodiments. In this embodiment, the xApp calculates the t380DerivationAssistancevalue (e.g., as described above with reference to FIG. 3) and provides it to the gNB-CU-CP / ng-eNB-CU-CP (e.g., via an E2 control request over the E2 interface). In this case, the CU-CP derives or configures the T380 value using the t380DerivationAssistancevalue (e.g., T380=T3512*t380DerivationAssistancevalue).

[0057] Referring to Figure 4, in steps [1] to [8], a T3512 timer value is provided from the CU-CP to the xApp. Specifically, the xApp transmits an E2 subscription request to the CU-CP via the near-real-time RIC (steps [1] and [2]), and the CU-CP returns a subscription acknowledgement or confirmation via a subscription response (steps [3] and [4]). Furthermore, based on the NGAP initial context setup request and response in steps [5] and [6], RRC inactive assistance information is received and acknowledged by the CU-CP from the core network (AMF). The assistance information includes a T3512 timer value, which is subsequently provided by the CU-CP to the xApp in steps [7] and [8].

[0058] According to an example embodiment, the xApp derives the t380DerivationAssistanceValue in step [9] using the core network assistance information for RRC inactivity (including the T3512 value) as input. An algorithm for deriving the T380 timer value, according to one or more embodiments, is shown in FIG.

[0059] In step

[10] , the xApp sends an E2 control request to the near-real-time RIC. The E2 control request may include an O-RAN E2 service model (e.g., E2SM-RC) or a custom E2SM that includes the t380DerivationAssistance value. As described in step

[11] , a RIC control request including the E2SM-RC or custom E2SM that includes the t380DerivationAssistance value may be sent from the near-real-time RIC to the gNB-CU-CP or ng-eNB-CU-CP. A RIC control response (step

[12] in Figure 4) is then sent to the near-real-time RIC, and an E2 control response is sent to the xApp (step

[13] in Figure 4). The t380DerivationAssistance value is then used by the CU-CP to derive the T380 timer value. For example, the gNB-CU-CP / ng-eNB-CU-CP may calculate the T380 value as follows: T380=t380DerivationAssistancevalue*periodicRegistrationUpdateTimer, rounded up and / or down to the nearest choice of T380 as defined in 3GPP TS 38.331.

[0060] According to an embodiment, the T380 timer value may be used when the UE is RRC released with SuspendConfig (step

[14] in Figure 4) to move the UE to the RRC-Inactive state (step

[15] in Figure 4).

[0061] In the above-described embodiment, the T380 timer value is calculated or derived at the CU-CP based on the t380DerivationAssistance value provided by the xApp, but it should be understood that one or more other embodiments are not limited in this respect. For example, according to another embodiment, the xApp itself may derive the T380 timer value and provide it to the CU-CP, as described below with reference to Figures 5 and 6.

[0062] 5 illustrates a flowchart for calculating the T380 timer value in a near-real-time RIC, according to one or more embodiments. As illustrated in FIG. 5, according to one embodiment, an xApp may derive the T380 timer value using the T3512 value as input. In step 511, the T3512 timer value may be obtained from the gNB-CU-CP / ng-eNB-CU-CP, and a variable X may be set to the T3512 timer value in minutes. In step 512, it is determined whether X is greater than 720 minutes. If X is greater than (or equal to) 720 minutes, the T380 timer value may be set to 720 minutes (step 513). If X is less than 720 minutes (step 514), the T380 timer value may be set as follows:

number

[0063] 6 illustrates a call flow for T380 control from a near-real-time RIC, according to one or more embodiments. Unlike the embodiment of FIG. 4, in which the CU-CP comprises the t380DerivationAssistanceValue and derives the T380 timer value accordingly, in this exemplary embodiment, the T380 timer value is derived at the near-real-time RIC. Thus, as illustrated in FIG. 6, the xApp updates or configures the T380 timer value to the gNB-CU-CP / ng-eNB-CU-CP through an E2 control request.

[0064] Referring to Figure 6, the T3512 timer value is provided to the xApp as described in steps [1] to [8]. This process is similar to the process described above with reference to Figure 4, and therefore will not be repeated below.

[0065] Next, in step [9], the xApp derives an appropriate T380 timer value using core network assistance information for RRC inactivity, including a periodic registration update timer. The T380 timer value may be derived according to the process described in FIG. 5, although it should be understood that one or more other embodiments are not limited thereto and the T380 timer value may be derived using other rules to ensure that the T380 timer is less than both its maximum allowed value and the value of the T3512 timer. For example, in another embodiment, the xApp may calculate a t380DerivationAssistancevalue (e.g., as described above with reference to FIG. 3) and derive the T380 timer value accordingly (e.g., T380 = t380DerivationAssistancevalue * T3512).

[0066] In step

[10] , the xApp sends an E2 control request to the near-real-time RIC. The E2 control request may include an O-RAN E2 service model (e.g., E2SM-RC) or a custom E2SM, including a T380 timer value. As described in step

[11] , a RIC control request including an E2SM-RC or a custom E2SM including a T380 timer value may be sent from the near-real-time RIC to the gNB-CU-CP. A RIC control response (step

[12] in FIG. 6) is then sent to the near-real-time RIC, and an E2 control response is sent to the xApp (step

[13] in FIG. 6). According to an embodiment, the T380 timer value may be used when the UE is RRC released with SuspendConfig (step

[14] in FIG. 6) to move the UE to the RRC-Inactive state (step

[15] in FIG. 6).

[0067] According to another embodiment, the T380 value may be derived by the xApp based on continuous monitoring of all UE residence times within the RAN, as described below with reference to FIG.

[0068] FIG. 7 illustrates a call flow for deriving a T380 timer value based on continuous monitoring of all UE residence times within the RAN, in accordance with one or more embodiments.

[0069] Referring to Figure 7, an NGAP initial context setup request is provided to the xApp as described in steps [1] to [8]. This process is similar to the process described above with reference to Figure 4, and therefore will not be repeated below.

[0070] As shown in steps [9] and

[14] , the UE context creation timestamp is determined at time T1 and T2, respectively, and is used to update the running average of the UE RAN residence time. For a given UE, T380 may be calculated in xApp as a predetermined decimal value (e.g., 0.9) multiplied by the running average. If the calculated T380 is greater than T3512, T380 is determined to be equal to T3512 - (T3512 * T3512) / 720. Otherwise, the calculated T380 is maintained.

[0071] The average RAN residence time can also be calculated per UE category or per slice (S-NSSAI). The T380 value for a given UE can be provided based on the UE category or the S-NSSAI that the UE is using. The xApp can know the UE category and / or the S-NSSAI that the UE is using based on the message copy of the initial context setup request received via the E2 interface. For example, the initial context setup request message includes the following information: [Table 1]

[0072] According to yet another exemplary embodiment, the T380 value may be optimized by the xApp by monitoring the inter-packet arrival interval in the downlink direction for UEs in RRC-Inactive state, as described below with reference to FIG. 8.

[0073] 8 illustrates a call flow for deriving a T380 timer value based on monitoring inter-packet arrival time in the downlink direction, according to one or more embodiments. For example, the T380 value can be optimized by xApp for a UE in an RRC-Inactive state by monitoring inter-packet arrival time in the downlink direction. When the UE transitions to the RRC-Inactive state, an initial T380 value can be provided to the UE, for example, using one of the methods described above. T380 can be further adjusted and / or optimized by the process illustrated in FIG. 8.

[0074] UEs in RRC-Inactive state may put their user plane context on hold in the CU-UP as defined in 3GPP. Once the user plane context is on hold, the arrival of any downlink packet destined for the UE from the core network (e.g., UPF) may trigger a DL data notification from the CU-UP to the CU-CP over the E1 interface. The CU-CP may then trigger RAN-initiated paging to the UE to resume the UE context. Adjusting the T380 timer to a value smaller than the downlink inter-packet arrival interval (e.g., 1 or 2 seconds less) ensures that the UE resumes the context in time and avoids RAN-initiated paging when a packet actually arrives.

[0075] The adjusted T380 value may be calculated per UE category or per slice using the Network Slice Selection Assistance Information (S-NSSAI) instead of calculating a common average across all UEs. A recommended T380 value for a given UE may be provided based on the UE category or the S-NSSAI that the UE is using. The xApp may know the UE category and / or the S-NSSAI that the UE is using based on a message copy of the initial context setup request received over the E2 interface.

[0076] It should be appreciated that while the above-described embodiments relate to RAN architectures in which base station functionality is split and the T380 timer value is determined by or provided to the CU-CP, one or more other embodiments are not so limited and may, for example, be implemented in or with respect to base stations that are not split or virtualized.

[0077] 9 is a diagram of an example environment 900 in which the systems and / or methods described herein may be implemented. As shown in FIG. 9, environment 900 may include a user device 910, a platform 920, and a network 930. The devices in environment 900 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In embodiments, any of the functions and operations described with reference to FIGS. 3 through 5 above may be performed by any combination of the elements illustrated in FIG. 9.

[0078] User device 910 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to platform 920. For example, user device 910 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smartphone, a wireless phone, etc.), a wearable device (e.g., smart glasses or a smart watch), or similar device. In some implementations, user device 910 may receive information from and / or transmit information to platform 920.

[0079] Platform 920 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, platform 920 may include a cloud server or a collection of cloud servers. In some implementations, platform 920 may be designed to be modular, such that certain software components can be swapped in or out depending on particular needs. Thus, platform 920 may be easily and / or quickly reconfigured for different uses.

[0080] In some implementations, as shown, platform 920 may be hosted in a cloud computing environment 922. Notably, although the implementations described herein describe platform 920 as being hosted within cloud computing environment 922, in some implementations platform 920 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0081] Cloud computing environment 922 includes an environment that hosts platform 920. Cloud computing environment 922 may provide services such as computation, software, data access, and storage, without requiring end-user (e.g., user device 910) knowledge of the physical location and configuration of the systems and / or devices that host platform 920. As shown, cloud computing environment 922 may include computing resources 924 (collectively referred to as “computing resources 924” and individually as “computing resource 924”).

[0082] Computing resources 924 include one or more personal computers, clusters of computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, computing resources 924 may host platform 920. Cloud resources may include compute instances executing within computing resources 924, storage devices included within computing resources 924, data transfer devices provided by computing resources 924, etc. In some implementations, computing resources 924 may communicate with other computing resources 924 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0083] As further shown in FIG. 9, the computing resources 924 include a group of cloud resources such as one or more applications ("Applications: APP") 924-1, one or more virtual machines ("Virtual Machines: VM") 924-2, virtualized storage ("Virtualized Storage: VS") 924-3, and one or more hypervisors ("Hypervisors: HYP") 924-4.

[0084] Applications 924-1 include one or more software applications that may be provided to or accessed by user device 910. Applications 924-1 may eliminate the need for software applications to be installed and run on user device 910. For example, applications 924-1 may include software associated with platform 920 and / or any other software that may be provided via cloud computing environment 922. In some implementations, one application 924-1 may send and receive information to one or more other applications 924-1 via virtual machine 924-2.

[0085] Virtual machine 924-2 includes a software-implemented machine (e.g., a computer) that executes programs like a physical machine. Virtual machine 924-2 can be either a system virtual machine or a process virtual machine, depending on the application and the degree to which virtual machine 924-2 corresponds to any actual machine. A system virtual machine may provide a complete system platform that supports the execution of a complete operating system (“OS”). A process virtual machine may execute a single program and support a single process. In some implementations, virtual machine 924-2 may run on behalf of a user (e.g., user device 910) and manage the infrastructure of cloud computing environment 922, such as data management, synchronization, or long-term data transfer.

[0086] Virtualized storage 924-3 includes one or more storage systems and / or one or more devices that use virtualization technology within the storage systems or devices of computing resources 924. In some implementations, in the context of storage systems, types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage so that the storage system can be accessed regardless of the physical storage or heterogeneous structure. The separation provides storage system administrators with flexibility in how they manage storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and where the file is physically stored. This may enable performance optimization of storage usage, server consolidation, and / or non-disruptive file migration.

[0087] The hypervisor 924-4 may provide hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer, such as the computing resource 924. The hypervisor 924-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of different operating systems may share virtualized hardware resources.

[0088] Network 930 may include one or more wired and / or wireless networks. For example, network 930 may include a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, an optical fiber-based network, etc., and / or combinations thereof or other types of networks.

[0089] The number and arrangement of devices and networks shown in Figure 9 are provided as an example. In practice, there may be more, fewer, different, or differently arranged devices and / or networks than those shown in Figure 9. Furthermore, two or more devices shown in Figure 9 may be implemented within a single device, or a single device shown in Figure 9 may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices in environment 900 (e.g., one or more devices) may perform one or more functions that are described as being performed by another set of devices in environment 900.

[0090] 10 is a diagram of example components of a device 1000. The device 1000 may correspond to a user device 910 and / or a platform 920. As shown in FIG. 10, the device 1000 may include a bus 1010, a processor 1020, a memory 1030, a storage component 1040, an input component 1050, an output component 1060, and a communication interface 1070.

[0091] The bus 1010 includes components that enable communication between components of the device 1000. The processor 1020 may be implemented in hardware, firmware, or a combination of hardware and software. The processor 1020 may be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or another type of processing component. In some implementations, the processor 1020 includes one or more processors that can be programmed to perform functions. Memory 1030 may include random access memory (RAM), read only memory (ROM), and / or another form of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions used by processor 1020.

[0092] Storage component 1040 stores information and / or software related to the operation and use of device 1000. For example, storage component 1040 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, magnetic tape, and / or other type of non-transitory computer-readable medium, along with a corresponding drive. Input component 1050 includes components that enable device 1000 to receive information, such as via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Additionally or alternatively, input component 1050 may include sensors for sensing information (e.g., a Global Positioning System (GPS) component, an accelerometer, a gyroscope, and / or an actuator). Output components 1060 include components that provide output information from device 1000 (eg, a display, a speaker, and / or one or more Light-Emitting Diodes (LEDs)).

[0093] The communication interface 1070 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable the device 1000 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 1070 may enable the device 1000 to receive information from and / or provide information to another device. For example, the communication interface 1070 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0094] The device 1000 may perform one or more processes described herein. The device 1000 may perform these processes in response to the processor 1020 executing software instructions stored by a non-transitory computer-readable medium, such as memory 1030 and / or storage component 1040. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.

[0095] The software instructions may be loaded into memory 1030 and / or storage component 1040 from another computer-readable medium or from another device via communication interface 1070. When executed, the software instructions stored in memory 1030 and / or storage component 1040 may cause processor 1020 to perform one or more processes described herein.

[0096] Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0097] The number and arrangement of components shown in Figure 10 are provided as an example. In practice, device 1000 may include more, fewer, different, or differently arranged components than those shown in Figure 10. Additionally or alternatively, a set of components (e.g., one or more components) of device 1000 may perform one or more functions that are described as being performed by another set of components of device 1000.

[0098] In embodiments, any one of the operations or processes of FIGS. 3 through 8 may be performed by or using any one of the elements illustrated in FIGS.

[0099] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0100] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail. Furthermore, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or media) having computer-readable program instructions for causing a processor to perform operations.

[0101] A computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, or semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile discs (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium as used herein should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted through a wire.

[0102] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0103] The computer-readable program code / instructions for carrying out operations may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, Instruction-Set-Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or object-oriented programming languages ​​such as Smalltalk, C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects or operations.

[0104] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, whereby the instructions, executed by the processor of the computer or other programmable data processing apparatus, generate means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored within a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, whereby the computer-readable storage medium having instructions stored therein comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0105] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, whereby the instructions executing on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0106] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function(s). The methods, computer systems, and computer-readable media may include more, fewer, different, or differently arranged blocks than those shown in the figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by a dedicated hardware-based system that performs the specified functions or acts or executes a combination of dedicated hardware and computer instructions.

[0107] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 1. A method, executed by at least one processor, for configuring a periodic radio access network (RAN) notification area (RNA) update timer based on a periodic registration update timer, the method comprising: Obtaining a periodic registration update timer value provided by a core network; and determining an RNA update timer value based on the obtained periodic registration update timer value, such that the RNA update timer value is less than the obtained periodic registration update timer value and less than a predetermined maximum value of the RNA update timer; method.

2. Determining the RNA update timer value includes: determining a parameter based on the periodic registration update timer; and determining the RNA update timer value based on the parameter and the periodic registration update timer value. The method of claim 1.

3. Determining the RNA update timer value further comprises: and configuring and / or updating said parameters via an O1 interface between a Service Management and Orchestration (SMO) framework and a centralized unit of a Radio Access Network (RAN). The method of claim 2.

4. Determining the parameter includes: receiving the periodic registration update timer value by an xApp of a Near Real-Time RAN Intelligent Controller (RIC); and determining, by the xApp, the parameter based on the received periodic registration update timer value; Determining the RNA update timer value based on the parameter and the periodic registration update timer value includes: receiving, by a centralized unit of a RAN, said parameters from said near real-time RIC via an E2 interface; and determining, by the centralized unit, the RNA update timer based on the parameter and the periodic registration update timer value. The method of claim 2.

5. Determining the parameter includes: determining whether the received periodic registration update timer value is greater than the predetermined maximum value for the RNA update timer; determining, based on the received periodic registration update timer value being greater than the predetermined maximum value of the RNA update timer, that the parameter is equal to (the predetermined maximum value of the RNA update timer / the received periodic registration update timer value); and determining, based on the received periodic registration update timer value being less than or equal to the predetermined maximum value of the RNA update timer, that the parameter is equal to ((the predetermined maximum value of the RNA update timer - the received periodic registration update timer value) / the predetermined maximum value of the RNA update timer); The method of claim 4.

6. determining, by the centralized unit, the RNA update timer value based on the parameter and the periodic registration update timer value; determining that the RNA update timer value is equal to (the parameter * the periodic registration update timer value), and rounding up to the nearest enumeration of the RNA update timer value specified in the 3GPP specifications; The method of claim 4.

7. the RNA update timer value is determined by an xApp of a near real-time RAN intelligent controller (RIC) using the periodic registration update timer value and provided to a centralized unit of the RAN via an E2 interface; The method of claim 1.

8. Determining the RNA update timer value includes: determining whether the periodic registration update timer value is greater than the predetermined maximum value of the RNA update timer; determining that the RNA update timer value is equal to the predetermined maximum value of the RNA update timer based on the periodic registration update timer value being greater than the predetermined maximum value of the RNA update timer; and determining, based on the periodic registration update timer value being less than or equal to the predetermined maximum value of the RNA update timer, that the RNA update timer value is equal to (the periodic registration update timer value - (the square of the periodic registration update timer value / the predetermined maximum value of the RNA update timer)); The method of claim 7.

9. Determining the RNA update timer value includes: determining, by the xApp, the RNA update timer value based on an average user equipment (UE) residence time within the RAN; The method of claim 7.

10. The average UE residence time in the RAN is calculated in xApp based on the UE grant time and UE release time averaged over multiple UEs.

10. The method of claim 9.

11. the xApp determines the UE authorization time and the UE release time based on the UE authorization event and UE release event notified by the centralized unit (via E2); The method of claim 10.

12. Determining the RNA update timer value includes: determining, by the xApp, the RNA update timer value based on an average downlink inter-packet arrival interval in an RRC-Inactive state; The method of claim 7.

13. The xApp determines an average downlink inter-packet arrival time based on an average time difference between two downlink data notifications received for the UE. The method of claim 12.

14. The arrival of a downlink data notification at the centralization unit (CU) is indicated to the xApp through the E2 interface. The method of claim 13.

15. 1. An apparatus for configuring a periodic radio access network (RAN) notification area (RNA) update timer based on a periodic registration update timer, comprising: The apparatus comprises: a memory for storing instructions; and at least one processor configured to execute the instructions; The instructions: Obtaining a periodic registration update timer value provided by the core network; and determining an RNA update timer value based on the acquired periodic registration update timer value such that the RNA update timer value is smaller than the acquired periodic registration update timer value and smaller than a predetermined maximum value of the RNA update timer; Device.

16. The at least one processor further comprises: determining a parameter based on the periodic registration update timer; and determining the RNA update timer value based on the parameter and the periodic registration update timer value; 16. The apparatus of claim 15.

17. The at least one processor further comprises: configured to determine the RNA update timer value by configuring and / or updating the parameters via an O1 interface between a Service Management and Orchestration (SMO) framework and a centralized unit of a Radio Access Network (RAN); 17. The apparatus of claim 16.

18. The at least one processor further comprises: Determining the parameters includes: receiving the periodic registration update timer value by an xApp of a Near Real-Time RAN Intelligent Controller (RIC); and determining, by the xApp, the parameter based on the received periodic registration update timer value; Determining the RNA update timer value based on the parameter and the periodic registration update timer value: receiving, by a centralized unit of a RAN, said parameters from said near real-time RIC via an E2 interface; and determining, by the centralized unit, the RNA update timer based on the parameter and the periodic registration update timer value.

17. The apparatus of claim 16.

19. The at least one processor further comprises: Determining the parameters comprises: determining whether the received periodic registration update timer value is greater than the predetermined maximum value for the RNA update timer; determining, based on the received periodic registration update timer value being greater than the predetermined maximum value of the RNA update timer, that the parameter is equal to (the predetermined maximum value of the RNA update timer / the received periodic registration update timer value); and determining, based on the received periodic registration update timer value being less than or equal to the predetermined maximum value of the RNA update timer, that the parameter is equal to ((the predetermined maximum value of the RNA update timer - the received periodic registration update timer value) / the predetermined maximum value of the RNA update timer); 20. The apparatus of claim 18.

20. 1. A non-transitory computer-readable storage medium having instructions stored thereon executable by at least one processor to perform a method for configuring a periodic radio access network (RAN) notification area (RNA) update timer based on a periodic registration update timer, the method comprising: The method comprises: Obtaining a periodic registration update timer value provided by a core network; and determining an RNA update timer value based on the obtained periodic registration update timer value, such that the RNA update timer value is less than the obtained periodic registration update timer value and less than a predetermined maximum value of the RNA update timer; A non-transitory computer-readable storage medium.

Images