Network entity fallback signaling optimization

Abstract

Example embodiments of the present disclosure relate to network entity fallback signaling optimization. According to example embodiments, a system may include: a first network entity configured to: provide, to a second network entity, a request that includes information associated with a primary action and a preferred fallback action; receive, from the second network entity, a response to the request; determine, based on the response, whether the preferred fallback action is triggered; and based on determining that the preferred fallback action is triggered, perform the preferred fallback action.

Description

NETWORK ENTITY FALLBACK SIGNALING OPTIMIZATION TECHNICAL FIELD

[0001] The present disclosure relates to network entity fallback signaling optimization.BACKGROUND

[0002] The information disclosed in this background section is only for the enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0003] A telecommunications network is constituted of multiple network entities that communicate and interoperate with each other through signaling exchanges. Fallback signaling is a signaling mechanism that may be implemented by the network entities to request for an alternative, fallback action when a primary requested action is rejected. A typical procedure involves a first network entity sending a request signal to a second network entity for requesting a primary action (e.g., modification of a resource, etc.), and the second network entity responds with a rejection signal if the requested primary action is not feasible and / or has failed. Accordingly, the first network entity may decide a fallback action (e.g., initiation of a release procedure, etc.) and send another request signal to the second network entity to request for the fallback action.SUMMARY

[0004] Example embodiments of the present disclosure provide systems, methods, and the like, that effectively and efficiently optimize fallback signaling among network entities.

[0005] According to example embodiments, a system may include: a first network entity configured to: provide, to a second network entity, a request that includes information associated with a primary action and a preferred fallback action; receive, from the second network entity, aresponse to the request; determine, based on the response, whether the preferred fallback action is triggered; and based on determining that the preferred fallback action is triggered, perform the preferred fallback action.

[0006] According to example embodiments, method may include: providing, to a network entity, a request that includes information associated with a primary action and a preferred fallback action; receiving, from the network entity, a response to the request; determining, based on the response, whether the preferred fallback action is triggered; and based on determining that the preferred fallback action is triggered, performing the preferred fallback action.

[0007] According to example embodiments, a method may include: receiving, from a network entity, a request that includes information associated with a primary action and a preferred fallback action; determining whether the primary action is feasible; based on determining that the primary action is feasible, providing, to the network entity, a first response indicating that the primary action is accepted; and based on determining that the primary action is not feasible, providing, to the network entity, a second response indicating that the fallback action is triggered.

[0008] 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 realized by practice of the presented embodiments of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0010] FIG. 1 A to FIG. IE each illustrates a diagram of an example system configuration, according to one or more example embodiments;

[0011] FIG. 2A to FIG. 2B each illustrates a diagram of an example method, according to one or more example embodiments.

[0012] FIG. 3A to FIG. 8B each illustrates a call flow of an example use case, in which one or more example embodiments may or may not be implemented;

[0013] FIG. 9 illustrates a diagram of an example device in which one or more example embodiments may be implemented; and

[0014] FIG. 10 illustrates a diagram of an example environment in which systems, devices, and / or methods, according to one or more example embodiments, may be implemented.DETAILED DESCRIPTION

[0015] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to one of the various embodiments. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part).

[0016] It will be apparent that systems and / or methods, described herein, may be implemented in different 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 / ormethods is not limited to the described implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0017] Even though particular combinations of features are disclosed in the claims and / or in the specification, these combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

[0018] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. 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.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B]”, “[A] and / or [B]”, or “at least one of [A] or [B]”, are to be understood as including only A, only B, or both A and B.

[0019] Expressions such as “at least one processor,” where configured to implement a plurality of operations, execute a plurality of instructions, etc., are to be understood as a single processor implementing the plurality of operations, etc., or each of plural processors implementing at least some (but not necessarily all) of the plurality of operations, etc.

[0020] Reference throughout this specification to “one embodiment,” “embodiment,” “non-limiting exemplary embodiment,” “example embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the indicated embodiment is included in at least one embodiment of the present solution. Thus, the phrases “in one embodiment”, “in an embodiment,” “in one non-limiting exemplary embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0021] Further, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more example embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the present disclosure can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0022] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the Open Radio Access Network (O-RAN) Alliance, the 3rd Generation Partnership Project (3 GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, and the like. For instance, the terms “CU”, “DU”, “CU-UP”, “CU-CP”, “Fl Interface”, “El Interface”, “X2 Interface”, “Xn Interface”, “EN-DC”, “NR-DC”, “NGEN-DC”, and the like, as well as the associated features, operations, and messages involved therein, are to be interpreted as consistent with those specified in one or more technical specifications, unless being described otherwise. Further, the terms “SN”, “S-Node”, and the like as described herein may refer to the “Secondary Node” and such terms may be used interchangeably.

[0023] As described above, a telecommunication network includes multiple network entities that may communicate and interoperate with each other via signaling exchanges. In this regard, the performance of the network can be affected by the efficiency and volume of the signaling among the network entities. For instance, excessive signaling may lead to higher processing delays at the network entities, thereby raising overall latency, delaying the release of resources or services, and resulting in a slower response to changing network conditions. Additionally, excessive signaling may increase the energy consumption of the network entities and reduce the efficiency of resource allocation and utilization.

[0024] Fallback signaling, while essential for maintaining network operation continuity, may contribute a major portion of signaling among the network entities. Specifically, in the related art, a first network entity may signal a message to a second network entity to request a primary action. In this regard, when the second network entity determines that the requested primary action is not feasible or has failed, the second network entity may signal a message to the first network entity to refuse the requested action or indicate that the requested action has failed. Accordingly, the first network entity may determine a secondary, fallback action and then signal another message to the second entity to request the fallback action. Namely, in the related art, the signaling of the fallback action is decided and triggered by the first network entity after the first network entity receives a rejection or an indication that the requested primary action has failed, thereby resulting in additional signaling overhead among the network entities and further exacerbating the impacts on network performance (e.g., latency, energy consumption, resource efficiency, etc.).

[0025] Example embodiments of the present disclosure, as described in the following, provide devices, systems, methods, and the like, that effectively and efficiently optimize fallbacksignaling among the network entities, and ultimately address the shortcomings of the related art systems and methods.

[0026] Specifically, according to example embodiments, when requesting a primary action, a network entity may provide information associated with a preferred fallback operation (e.g., including the information of the primary action and preferred fallback action in the same request message), such that the opposite network entity that receives the request may automatically trigger the signaling of the preferred fallback action and provide a message that includes an indication that the preferred fallback action is triggered to the network entity, when the requested primary action is not feasible or has failed. Ultimately, example embodiments may efficiently and effectively reduce the signaling among the network entities, thereby optimizing fallback signaling among network entities, reducing signaling overhead, optimizing energy consumption, and improving efficiency in releasing resources and services.

[0027] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions of the features, components, configuration, operations, and implementations of the example embodiments of the present disclosure are provided in the following.Example System Architecture and Configurations

[0028] FIG. 1 A to FIG. IE each illustrates a diagram of an example system configuration, according to one or more example embodiments.

[0029] Referring to FIG. 1 A, which illustrates a diagram of a generic system configuration 100, according to one or more example embodiments. As illustrated in FIG. 1A, the system configuration 100 includes a first network entity 110 and a second network entity 120. The firstnetwork entity 110 and the second network entity 120 may be communicatively coupled to each other via an appropriate interface, and may be configured to communicate and interoperate with each other via exchanging signaling through the interface.

[0030] The first network entity 110 and second network entity 120 may include any suitable entities, elements, components, nodes, devices, equipment, and the like, in any suitable type of network. Further, the first network entity 110 and second network entity 120 may be implemented in software form (e.g., virtualized, cloudified, or containerized network functions, etc.), hardware form (e.g., servers, antennas, routers, switches, transceivers, etc.), or a combination thereof. Several examples of the first network entity 110 and the second network entity 120 are further described below with reference to FIG. IB to FIG. IE.

[0031] Referring to FIG. IB, which illustrates a diagram of an example system configuration 101 in a network that implements dual connectivity, according to one or more example embodiments. As illustrated in FIG. IB, the system configuration 101 includes a Master Node (MN) 111 and a Secondary Node (SN) 121. The MN 111 and SN 121 may be communicatively coupled to each other via an X2 or Xn interface, depending on the underlying technology (e.g., LTE, 5G, dual connectivity, etc.). For instance, each of the MN 111 and SN 121 may include an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) node (e.g., an LTE-based eNodeB, etc.), a Next Generation Radio Access Network (NG-RAN) node (e.g., a 5G-based gNodeB, etc.), or a combination thereof.

[0032] In LTE dual connectivity, the MN 111 may include a first LTE eNB that serves as the primary anchor for a user equipment (UE), while the SN 121 may include a second LTE eNB that provides additional radio resources. Similarly, in NR Dual Connectivity (NRDC), the MN 111 may include an NR gNB that serves as the primary anchor for the UE, while the SN 121 mayinclude a second NR gNB that provides additional radio resources. In multi-Radio Access Technology (RAT) dual connectivity (e.g., Evolved-Universal Terrestrial Radio Access-New Radio (E-UTRA NR) Dual Connectivity (EN-DC), NR E-UTRA Dual Connectivity (NE-DC), Next Generation E-UTRA NR Dual Connectivity (NG-ENDC), etc.), the MN 111 may include an LTE eNB or NR gNB that serves as the primary anchor for UE, while the SN 121 may include an NR gNB or LTE eNB respectively.

[0033] Referring next to FIG. 1C, which illustrates a diagram of an example system configuration 102 in a Radio Access Network (RAN), according to one or more example embodiments. As illustrated in FIG. 1C, the system configuration 102 includes a Central Unit (CU) 112 and a Distributed Unit (DU) 122. The CU 112 and DU 122 may be communicatively coupled to each other via an Fl interface.

[0034] The CU 112 may be configured to manage higher-layer processing and centralized control operations, while the DU 122 may be configured to manage lower-layer radio operations closer to the UE. In some example implementations, the CU 112 may be implemented at a central server, while the DU 122 may be implemented at an edge server.

[0035] According to example embodiments, the RAN may be based on a 5G network architecture. In this regard, the CU 112 may include a gNB-CU while the DU 122 may include a gNB-DU. Additionally or alternatively, the RAN may be based on an Open RAN (0-RAN) network architecture. In this case, the CU 112 may include an 0-RAN CU (O-CU) while the DU 122 may include an 0-RAN DU (0-DU).

[0036] Referring next to FIG. ID, which illustrates a diagram of an example system configuration 103 in a split-CU architecture, according to one or more example embodiments. In this example configuration, a Central Unit (e.g., CU 112) is functionally split into a CU-ControlPlane (CU-CP) 113 and a CU-User Plane (CU-UP) 123. As illustrated in FIG. ID, the CU-CP 113 may be communicatively coupled to the CU-UP 123 via an El interface.

[0037] The CU-CP 113 may be configured to manage control plane signaling, such as Radio Resource Control (RRC) signaling, mobility management signaling, and the like. On the other hand, the CU-UP 123 may be configured to manage user plane signaling, such as user data signaling, Packet Data Convergence Protocol (PDCP) signaling, and the like. By splitting the control and user plane functionalities, each segment can be independently managed, scaled, and optimized.

[0038] Referring next to FIG. IE, which illustrates a diagram of an example configuration 104 of between an NG-RAN node and a core network, according to one or more example embodiments. In this example configuration, the NG-RAN Node 114 may include a gNB, a nextgeneration eNB (ng-eNB), and any other suitable network, that may be communicatively coupled to an Access and Mobility Management Function (AMF) 124 of a 5G Core (5GC) network via an N2 interface, although it can be understood that the AMF 124 may be replaced by any other suitable function of any other suitable types of core network, without departing from the scope of the present disclosure. The AMF 124 may handle control-plane functions such as UE’s connectivity and mobility management, UE registration, and the like.

[0039] It is contemplated that the entities and the associated configurations described above with reference to FIG. 1A to FIG. IE are merely examples simplified for descriptive and illustrative purposes, and the scope of the present disclosure should not be limited thereto. For instance, additional entities and configurations are applicable (e.g., the CU-CP 113 may communicate with the DU 122 via an Fl -c interface, whilethe CU-UP 123 may communicate with the DU 122 via an Fl-u interface, the MN 111 and SN 121 may each communicate with a UE,etc.), and the like. Further descriptions of the functionalities and operations of the components in FIG. 1 A to FIG. IE are provided below with reference to FIG. 2A to FIG. 8B.

[0040] It can be understood that the terms “network entity,” “first network entity,” and “second network entity” described herein may refer to any suitable types of network entities, without departing from the scope of the present disclosure. Further, the terms “first” and “second” should not limit the network entity to a specific type. For instance, a “first network entity” may refer to any of the MN 111 and SN 121, any of the CU 112 and DU 122, any of the CU-CP 113 and CU-UP 123, any of the network node 114 and AMF 124, and the like. Similarly, a “second network entity” may refer to any of the MN 111 and SN 121, any of the CU 112 and DU 122, any of the CU-CP 113 and CU-UP 123, any of the network node 114 and AMF 124, and the like

[0041] According to example embodiments, the first network entity 110 and the second network entity 120 may be configured to interoperate with each other and perform one or more methods / operations to optimize fallback signaling therebetween.

[0042] Generally, when the first network entity 110 provides a request for a primary action to the second network entity 120, the first network entity 110 may include, in the request, both the information associated with the primary action and the information of a preferred fallback action. The preferred fallback action may be, for example, a predetermined fallback action when the primary action is not feasible or has failed. For instance, the fallback action may be predetermined by a user (e.g., a network operator, a vendor, etc.), by design choice, and the like. Accordingly, the first network entity 110 may receive, from the second network entity, a response to the request, and then determine whether the preferred fallback action is triggered. Specifically, the response provided by the second network entity may include an indication (e.g., a flag, an Information Element (IE), a message header, etc.) as to whether the preferred fallback action is triggered. Basedon determining that the preferred fallback action is triggered, the first network entity 110 may be configured to perform one or more operations associated with the preferred fallback action.

[0043] On the other hand, the second network entity 120 may receive, from the first network entity 110, the request that includes the information associated with the primary action and the preferred fallback action. Accordingly, the second network entity 120 may determine whether the requested primary action is feasible. For instance, the second network entity 120 may determine whether the requested primary action is conflicting with an ongoing / pending operation (e g., handover, etc.), whether sufficient resources for implementing the requested primary action is available, and the like. Based on determining that the requested primary action is feasible, the second network entity 120 may implement the requested primary action, and then provide, to the first network entity 110, a response indicating that the primary action is accepted. Conversely, based on determining that the requested primary action is not feasible (and / or the requested primary action has failed), the second network entity 120 may trigger the fallback action and then provide, to the first network entity 110, a response indicating that the fallback action is triggered.

[0044] Further descriptions of several example methods and associated operations for optimizing fallback signaling, as well as several example use cases associated therewith, are provided below with reference to FIG. 2A to FIG. 8B.

[0045] In view of the above, example embodiments provide systems and configurations that effectively and efficiently optimize fallback signaling among the network entities. Specifically, a first network entity may be configured to provide information associated with the preferred fallback action along with the information associated with the primary action (e.g., when requesting the primary action, etc.), and then receive a response indicates that preferred fallback action is triggered (when the requested primary action is failed), without requiring to decide whichfallback action to be performed when the requested primary action is failed and initiate the decided fallback action thereafter. In addition, a second network entity may be configured to receive information associated with a preferred fallback action along with information associated with the primary action requested by the first network entity. Accordingly, when the second network entity determines that the requested primary action is not feasible or has failed, the second network entity may automatically initiate or trigger the preferred fallback action, without waiting for further communication from the first network entity. Ultimately, example embodiments may efficiently and effectively simplify and reduce the fallback signaling among the network entities, thereby optimizing fallback signaling among network entities, reducing signaling overhead, optimizing energy consumption, and improving efficiency in releasing resources and services.Example Methods and Operations

[0046] For descriptive purposes, some of the example methods and operations of example embodiments may be mainly described herein as being performed by one or more specific network entities, although it can be understood that, in actual implementations, another related network entity(s) may perform similar / related operations, without departing from the scope of the present disclosure.

[0047] According to example embodiments, one or more components of a network entity may be implemented in one or more devices or hardware components, and one or more operations described hereinbelow may be performed by the one or more devices / hardware components. For instance, the network entity may be implemented in a device that includes a processor and a memory storage (or any other suitable storage mediums), wherein the memory storage may include computer-executable instructions which, when being executed by the processor, cause the processor to perform one or more operations of the network entity.

[0048] FIG. 2A illustrates a diagram of an example method 201, according to one or more example embodiments. The operations in method 201 may be performed or implemented by a network entity or a device that implements the network entity. For descriptive purposes, the network entity (or the associated device) that performs the operations of method 201 may be referred to as the “first network entity”. The “first network entity” may refer to one of the first network entity 110 and the second network 120 in FIG. 1A, one of the MN 111 and SN 121 in FIG. IB, one of the CU 112 and DU 122 in FIG. 1C, one of the CU-CP 113 and CU-UP 123 in FIG. ID, or one of the NG-RAN node 114 and AMF 124 in FIG. IE.

[0049] Referring to FIG. 2A, at operation S211, the first network entity may be configured to provide, to a second network entity, a request for a primary action. The request may include information of a preferred fallback action. The “second network entity” may refer to another one of the first network entity 110 and the second network 120 in FIG. 1 A, another one of the MN 111 and SN 121 in FIG. IB, another one of the CU 112 and DU 122 in FIG. 1C, another one of the CU-CP 113 and CU-UP 123 in FIG. ID, or another one of the NG-RAN node 114 and AMF 124 in FIG. IE.

[0050] At operation S221, the first network entity may be configured to receive, from the second network entity, a response to the request. The response may include a result of the request, i.e., whether the requested primary action is accepted or rejected, whether the preferred fallback action is triggered, etc. According to example embodiments, as a response to the primary action requested or initiated by the first network entity, the second network entity may (a) invoke a response indicating whether the requested primary action is successful, and / or (b) initiate the fallback action (i.e., triggering / initiating the fallback action implies that the requested primary action is not feasible or has failed). The first network entity shall receive a response or messageassociated with either (a) or (b) as a response to the request. If the response / message is associated with (b) (i.e., the response / message is associated with the initiation of the fallback action), the response / message may include a reasoning of the initiation of the fallback action (e.g., the requested primary action is conflicting with an ongoing operation, the requested primary action is attempted but is unsuccessful, etc.).

[0051] Accordingly, at operation S231, the first network entity may be configured to determine, based on the response, whether the preferred fallback action is triggered. Based on determining that the preferred fallback action is triggered, method 201 may proceed to operation S241, in which the first network entity may be configured to perform one or more operations associated with the preferred fallback action (e.g., perform one or more operations according to the response provided by the second network entity, provide one or more messages to the second network entity and / or other network entities as a part of fallback action, etc.). Otherwise, based on determining that the preferred fallback action is not triggered (i.e., the requested primary action is accepted by the second network entity or is successfully implemented), method 201 may be completed.

[0052] FIG. 2B illustrates a diagram of an example method 202, according to one or more example embodiments. The operations in method 202 may be performed or implemented by a network entity (or a device that implements the network entity) which are different from the network entity (or the associated device) that performs method 201, such as the second network entity in method 201. For descriptive purposes, the network entity (or the associated device) that performs the operations of method 202 may be referred to as the “second network entity”.

[0053] Referring to FIG. 2B, at operation S212, the second network entity may be configured to receive, from a first network entity (e.g., the network entity that performs method201), a request for a primary action. The request may include information of a preferred fallback action. Operation S212 may be performed by the second network entity, in response to operation S211 in method 201.

[0054] At operation S222, the second network entity may be configured to determine whether the requested primary action is feasible. For instance, the second network entity may determine whether an ongoing operation of the second network entity is conflicting with the requested primary action, whether the network condition is suitable for performing the requested primary action, and the like. Additionally or alternatively, the second network entity may execute the requested primary action and determine whether the implementation of the requested primary action is successful. Accordingly, based on determining that the implementation of the requested primary action is feasible or successful, method 202 may proceed to operation S232, or otherwise method 202 may proceed to operation S232.

[0055] At operation S232, the second network entity may provide, to the first network entity, a response indicating that the requested primary action is accepted. For descriptive purposes, said response may also be referred to herein as the “first response”. In some example embodiments, upon providing the response, the first network entity may be configured to implement or execute one or more operations associated with the requested primary action (e.g., perform or instruct another network entity to perform one or more operations associated with the primary action and the associated / subsequent actions (if any), provide approval to the first network entity to perform one or more operations associated with the primary action and the associated / subsequent actions (if any), etc.).

[0056] On the other hand, at operation S242, the second network entity may provide, to the first network entity, a response indicating that the preferred fallback action is triggered. Fordescriptive purposes, said response may also be referred to herein as the “second response”. This response may also implicitly or explicitly indicate to the first network entity (e.g., the response may include an indication such as a flag, an IE, a message header, and the like) that the requested primary action is rejected / has failed and the preferred fallback action is triggered. Operation 242 may be considered as the initiation or trigger of the fallback action defined in the request provided by the first network entity. For instance, assuming that the preferred fallback action is to release resources of the first network entity, the response provided by the second network entity at operation S242 may include a request or command that instructs the first network entity to release the associated resources. Several examples of primary action and the associated fallback action, as well as the technical advantages and significances of implementing example embodiments therein, are further described below with reference to the use cases in FIG. 3 A to FIG. 8B.

[0057] In view of the above, example embodiments provide methods and operations that effectively and efficiently optimize fallback signaling among the network entities. Specifically, method and operations in FIG. 2A may be implemented to enable a network entity (e.g., a first network entity) to provide information associated with the preferred fallback action along with the information associated with the primary action (e.g., when requesting for the primary action, etc.), and then receive a response for performing one or more operations associated with the preferred fallback action (when the requested primary action is failed), without requiring the network entity to decide which fallback action to be performed when the requested primary action is failed and initiate the decided fallback action thereafter. On the other hand, method and operations in FIG.2B may be implemented to enable a network entity (e.g., a second network entity) to receive information associated with a preferred fallback action along with information associated with the primary action requested by another network entity (e.g., the first network entity). Accordingly,when the network entity determines that the requested primary action is not feasible or has failed, the network entity may automatically initiate or trigger the preferred fallback action. Ultimately, example embodiments may efficiently and effectively simplify and reduce the fallback signaling among the network entities, thereby optimizing fallback signaling among network entities, reducing signaling overhead, optimizing energy consumption, and improving efficiency in releasing resources and services.

[0058] It is contemplated that, the methods, operations, advantages, and significances described above with reference to FIG. 2A and FIG. 2B are merely examples and the scope of the present disclosure should not be limited thereto. Specifically, one or more operations in FIG. 2A and FIG. 2B may be performed differently, less or additional operations may be involved, additional advantages may be achieved, and the like, without departing from the scope of the present disclosure.Example Use Cases

[0059] Descriptions of several example use cases, with which the example embodiments associated with FIG. 1A to FIG. 2B may be associated, are provided below with reference to FIG.3 A to FIG. 8B.

[0060] Specifically, FIG. 3 A to FIG. 4B are associated with example use cases in a network that implements dual connectivity (e.g., network that includes MN 111 and SN 121 of FIG. IB), FIG. 5A to FIG. 6B are associated with example use cases in a RAN (e.g., RAN that includes CU 112 and DU 122 in FIG. 1C), FIG. 7A to FIG. 7B are associated with example use cases in a CU (e g. a CU that includes CU-CP 113 and CU-UP 123 of FIG. ID), and FIG. 8A to FIG. 8B are associated with example use cases in a network that implements a core network (e.g., a corenetwork that includes AMF 124 and communicates with NG-RAN node 114 of FIG. IE). Detailed descriptions of each of the example use cases are provided below.Example Use Cases associated with Dual Connectivity Network

[0061] In the implementation of dual connectivity, a UE may first connect to a master node (MN) and a secondary node (SN) may be added subsequently, thereby providing supplementary connectivity, capacity, or coverage to the UE. Various types of network dual connectivity may be implemented, such as LTE Dual Connectivity where both MN and SN are LTE eNBs, NR Dual Connectivity (NRDC) where both MN and SN are 5G gNBs, Multi-RAT Dual Connectivity such as EN-DC (where the MN is LTE eNB and the SN is 5G gNB), NE-DC (where the MN is 5G gNB and the SN is LTE eNB), NG-ENDC (where the MN is NG-eNB and the SN is 5G gNB), and the like.

[0062] In the following example use cases, it is assumed that a first network entity (i.e., either one of the MN and SN) triggers a process to modify configuration of the SN, such as add / remove / configure resources in SN or the secondary cell group (SCG), modify the UE context at the SN, modify / establish / release bearer context at the SN, query the current SCG configuration, and the like (may be referred to as “SN Modification” herein). Further, it is assumed that the network is configured such that, in case the process of SN modification has failed or the request for the SN modification is rejected, an SN Release procedure should be initiated to release the UE context at the SN. In some embodiments, the SN Release may include an SeNB Release (when the SN is an LTE eNB), an SgNB Release (when the SN is a 5G gNB), and the like. In the following example use cases, it is assumed that the “primary action” includes an “SN Modification” and the “preferred fallback action” includes an “SN Release”. It is contemplated that the implementationof example embodiments is not limited thereto, and any other suitable actions or operations among the MN and SN may be encompassed.

[0063] In the following, example use cases associated with MN-initiated SN Modification are firstly described with reference to FIG. 3 A and FIG. 3B, and example use cases associated with SN-initiated SN modification are described with reference to FIG. 4A and FIG. 4B thereafter.

[0064] Specifically, FIG. 3A illustrates a call flow of a first example use case 301 associated with SN Modification initiated by the MN, without implementing the example embodiments. On the other hand, FIG. 3B illustrates a call flow of a second example use case 302 associated with SN Modification initiated by the MN, with the implementation of one or more example embodiments. As illustrated in FIG. 3 A and FIG. 3B, the example use case 301 and example use case 302 includes an MN 310, an SN 320, and a UE 330. In this regard, since the SN Modification is initiated by the MN 310, the MN 310 may also be referred to as the “first network entity” while the SN 320 may be referred to as the “second network entity”. It is assumed that, at the beginning of the call flows, a UE 330 is attached to the network and the SN 320 is added, thereby enabling the network to provide dual connectivity to the UE 330.

[0065] Referring to FIG. 3A, at step 1, the MN 310 may trigger an SN Modification procedure. For instance, the MN 310 may trigger the SN Modification procedure to change configurations of an SCG associated with the SN 320, such as adding / modifying / releasing SCG bearer(s), changes of SN terminated master cell group (MCG) bearer(s), and the like. In addition, the MN 310 may also trigger the SN Modification procedure to query the current SCG configuration, activate / deactivate the SCG, and the like.

[0066] At step 2, the MN 310 may send a Secondary Node (S-Node) Modification Request message to the SN 320 to request or instruct the SN 320 to perform the requested SN Modification(i.e., the primary action). According to example embodiments where the SN 320 is a gNB, the S-Node Modification Request message may be labeled as an “SgNB Modification Request message”. Similarly, according to example embodiments where the SN 320 is an eNB, the S-Node Modification Request message may be labeled as an “SeNB Modification Request message”.

[0067] At step 3, the SN 320 receives the request message and determine whether or not the requested modification is feasible. Based on determining that the requested modification is feasible, the SN 320 may provide an S-Node Modification Request Acknowledge message to the MN 310 and perform the requested modification. According to example embodiments where the SN 320 is a gNB, the S-Node Modification Request Acknowledge message may be labeled as an “SgNB Modification Request Acknowledge message”. Similarly, according to example embodiments where the SN 320 is an eNB, the S-Node Modification Request Acknowledge message may be labeled as an “SeNB Modification Request Acknowledge message”.

[0068] Otherwise, based on determining that the requested modification is not feasible (e.g., SN 320 does not admit the modification requested by the MN 310 due to an ongoing operation like a Handover, a failure occurs during the S-Node Modification preparation stage, the S-Node Modification Request message provided by the MN 310 does not include the required information, etc.), the SN 320 may provide an S-Node Modification Request Reject message to the MN 310. This S-Node Modification Request Reject message may include information (e.g., Information Element (IE), etc.) describing the cause(s) of the failure or rejection. According to example embodiments where the SN 320 is a gNB, the S-Node Modification Request Reject message may be labeled as an “SgNB Modification Request Reject message”. Similarly, according to example embodiments where the SN 320 is an eNB, the S-Node Modification Request Reject message may be labeled as an “SeNB Modification Request Reject message”.

[0069] For descriptive purposes, it is assumed that in example use case 301, the SN 320 determines that the requested modification is not feasible or has failed. Accordingly, at step 4, the SN 320 may send the S-Node Modification RequestReject message to the MN 310. Subsequently, at step 5, the MN 310 receives the S-Node Modification Request Reject message and determines a fallback action. In this example use case, the MN 310 decides to trigger or initiate an SN Release procedure as the fallback action, such that the SN 320 may release resources associated with the UE 330 and the UE 330 will only connect to the MN 310 thereafter.

[0070] Accordingly, at step 6, the MN 310 may send an S-Node Release Request message to the SN 320 to request the SN to release resources associated with the UE 330, thereby initiating the fallback action. Assuming that the SN 320 receives the S-Node Release Request message and accepts the request, the SN 320 may stop providing data to the UE 330 and release resources associated with UE 330. According to example embodiments where the SN 320 is a gNB, the S-Node Release Request message may be labeled as an “SgNB Release Request message” (EN-DC). Similarly, according to example embodiments where the SN 320 is an eNB, the S-Node Release Request message may be labeled as an “SeNB Release Request message” (LTE Dual Connectivity), “S-Node Release Request message” (NE-DC, NGEN-DC, NRDC), or the like.

[0071] Subsequently, at step 7, the SN 320 may send an S-Node Release Request Acknowledge message to the MN 310 to confirm that SN resources associated with UE 330 will be or has been released. According to example embodiments where the SN 320 is a gNB, the S-Node Release Request Acknowledge message may be labeled as an “SgNB Release Request Acknowledge message”. Similarly, according to example embodiments where the SN 320 is an eNB, the S-Node Release Request Acknowledge message may be labeled as an “SeNB ReleaseRequest Acknowledge message” (LTE Dual Connectivity), “SeNB Release Request Acknowledge message” (NEDC), or the like.

[0072] Accordingly, at step 8, the MN 310 may initiate an RRC reconfiguration procedure to request or instruct the UE 330 to release from the SN 320 (or an SCG associated with the SN 320). In the example use case 301, the MN 310 sends an RRC Reconfiguration message to the UE 330 to request the UE 330 to release from the SN 320 (or the associated SCG). Thus, the RRC Reconfiguration message may also be labeled as an “RRC Reconfiguration (SN Release) message” or an “RRC Reconfiguration (SCG Release) message” herein. This message may instruct the UE 330 to release the radio link associated with SN 320, thereby freeing up the associated resources and ensuring the UE 330 seamlessly transitions from dual connectivity to single connectivity (i.e., anchored at the MN 310 only).

[0073] FIG. 3B illustrates a call flow of a second example use case 302 associated with SN Modification initiated by the MN, with the implementation of one or more example embodiments. Similar to example use case 301 in FIG. 3A, example use case 302 may also include an MN 310 (i.e., a first network entity) and an SN 320 (i.e., a second network entity) that constitute a network, and a UE 330 is assumed to be attached to the network and the SN 320 is assumed to be added, at the beginning of the call flow.

[0074] One or more operations or steps in example use case 302 may be similar to those described above with reference in example use case 301. For instance, steps 1 and 6 in example use case 302 may be similar to step 1 and 8 in example use case 301, respectively. Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0075] Example use case 302 is different from example use case 301 in that, upon implementing one or more example embodiments, the MN 310 may include information of apreferred fallback action (e.g., an SN Release procedure in this example use case) in the S-Node Modification Request message and send the message to the SN 320 at step 2. Accordingly, at step 3, when the SN 320 determines that the modification requested by the MN 310 cannot be accepted or has failed, the SN 320 may trigger the preferred fallback action specified in the request message. For instance, at step 4 of this example use case, the SN 320 may provide an S-Node Release Required message to the MN 310 to initiate the SN Release. The provision of the S-Node Release Required message may inherently or explicitly indicate to the MN 310 that the preferred fallback action is triggered by the SN 320. For instance, said message may include information (e.g., a flag, an IE, a message header, etc.) that indicates or notifies the MN 310 that the preferred fallback action is triggered. According to example embodiments where the SN 320 is a gNB, the S-Node Release Required message may be labeled as an “SgNB Release Required message”. Similarly, according to example embodiments where the SN 320 is an eNB, the S-Node Release Required message may be labeled as an “SeNB Release Required message”.

[0076] Accordingly, at step 5, the MN 310 may receive the response from the SN 320 (e.g., the S-Node Release Required message) and perform one or more operations associated with the fallback action (e.g., SN Release) based thereon. In this example use case, the MN 310 may perform the fallback action by sending an S-Node Release Confirm message to the SN 320 and send an RRC Reconfiguration message to the UE 330, in response to the S-Node Release Required message. Upon receiving the S-Node Release Confirm message, the SN 320 may stop providing data to the UE 330 and release resources associated with UE 330. According to example embodiments where the SN 320 is a gNB, the S-Node Release Confirm message may be labeled as an “SgNB Release Confirm message”. Similarly, according to example embodiments where theSN 320 is an eNB, the S-Node Release Required message may be labeled as an “SeNB Release Confirm message”.

[0077] By comparing the example use case 302 (with the implementation of example embodiments) with the example use case 301 (without the implementation of example embodiments), in the example use case 302, the fallback action (e.g., SN Release) is triggered by the SN 320 when it determines that the primary action (e.g., SN Modification) requested by the MN 310 is not acceptable or has failed. Specifically, instead of sending a message that simply indicates a rejection or failure of the requested primary action (e.g., S-Node Modification Request Reject message) to the MN 310 as in example use case 301, the SN 320 in example use case 302 sends a message that initiates or triggers the preferred fallback action (e.g., S-Node Release Required message) to the MN 310. Accordingly, by implementing the example embodiments, the preferred fallback action can be initiated and performed faster (i.e., in example use case 301 that does not implement example embodiments, the SN Release procedure is initiated at step 6 and performed at step 7 and step 8; On the other hand, in example use case 302 that implements example embodiments, the SN Release procedure is initiated at step 4 and performed at step 5 and step 6) and the signaling overhead and computing before initiating the fallback action can be reduced (i.e., in example use case 301 that does not implement example embodiments, two additional steps 4 and 5 are required before the fallback action is triggered; in example use case 302 that implements example embodiments, the fallback action is triggered at step 4 without requiring said additional steps 4 and 5 as in the example use case 301, thereby reducing the total number of steps from 8 steps in the example use case 301 to 6 steps in the example use case 302).

[0078] Next, example use cases associated with SN-initiated SN Modification are described with reference to FIG. 4A and FIG. 4B. Specifically, FIG. 4 A illustrates a call flow of athird example use case 401 associated with SN Modification initiated by the SN, without implementing the example embodiments. On the other hand, FIG. 4B illustrates a call flow of a fourth example use case 402 associated with SN Modification initiated by the SN, with the implementation of one or more example embodiments.

[0079] Similar to the example use cases in FIG. 3A and FIG. 3B, the example use cases in FIG. 4A and FIG. 4B also include an SN 410, an MN 420, and a UE 430. In this regard, since the SN Modification is initiated by the SN 410, the SN 410 may also be referred to as the “first network entity” while the MN 420 may be referred to as the “second network entity”. It is assumed that, at the beginning of the call flows, the UE 430 is attached to the network and the SN 410 is added, thereby enabling the network to provide dual connectivity to the UE 430.

[0080] Referring to FIG. 4A, at step 1, the SN 410 may trigger an SN Modification procedure. The conditions of triggering the SN Modification may be similar to those described above with reference to FIG. 3A and FIG. 3B. For instance, the SN 410 may trigger the SN Modification procedure to change configurations of an SCG within the SN 410, and the like.

[0081] At step 2, the SN 410 may send an S-Node Modification Required message to the MN 420 to request the MN 420 to approve the requested SN Modification (i.e., the primary action). According to example embodiments where the SN 410 is a gNB, the S-Node Modification Required message may be labeled as an “SgNB Modification Required message”. Similarly, according to example embodiments where the SN 410 is an eNB, the S-Node Modification Required message may be labeled as an “SeNB Modification Required message”.

[0082] At step 3, the MN 420 receives the request message and determines whether or not the requested modification is feasible. Based on determining that the requested modification is feasible, the MN 420 may provide an S-Node Modification Confirm message to notify the SN 410that the requested SN Modification is accepted or successful. According to example embodiments where the SN 410 is a gNB, the S-Node Modification Confirm message may be labeled as an “SgNB Modification Confirm message”. Similarly, according to example embodiments where the SN 410 is an eNB, the S-Node Modification Confirm message may be labeled as an “SeNB Modification Confirm message”.

[0083] Otherwise, based on determining that the requested modification is not feasible (e.g., MN 420 does not admit the modification requested by the SN 410 due to an ongoing operation like a Handover, a failure occurs during the S-Node Modification preparation stage, the S-Node Modification Required message provided by the SN 410 does not include the required information, etc.), the MN 420 may provide an S-Node Modification Refuse message to the SN 410. This S-Node Modification Refuse message may include information (e.g., IE, etc.) describing the cause(s) of the failure or rejection. According to example embodiments where the SN 410 is a gNB, the S-Node Modification Refuse message may be labeled as an “SgNB Modification Refuse message”. Similarly, according to example embodiments where the SN 410 is an eNB, the S-Node Modification Refuse message may be labeled as an “SeNB Modification Refuse message”.

[0084] For descriptive purposes, it is assumed that in example use case 401, the MN 420 determines that the requested modification is not feasible or cannot be accepted. Accordingly, at step 4, the MN 420 may send the S-Node Modification Refuse message to the SN 410. Subsequently, at step 5, the SN 410 receives the S-Node Modification Refuse message and determines a fallback action. In this example use case, the SN 410 decides to trigger or initiate an SN Release procedure as the fallback action, such that the SN 410 may release resources associated with the UE 430 and the UE 430 will only connect to the MN 420 thereafter.

[0085] Accordingly, at step 6, the SN 410 may send an S-Node Release Required message to the MN 420 to notify the MN 420 that the SN 410 will release resources associated with the UE 430. Upon receiving the S-Node Release Required message, the MN 420 may send an S-Node Release Confirm message to the SN 410, and the SN 410 may stop providing data to the UE 430 and release resources associated with UE 430. According to example embodiments where the SN 410 is a gNB, the S-Node Release Required message may be labeled as an “SgNB Release Required message”, while the S-Node Release Confirm message may be labeled as an “SgNB Release Confirm message”. Similarly, according to example embodiments where the SN 410 is an eNB, the S-Node Release Required message may be labeled as an “SeNB Release Required message”, while the S-Node Release Confirm message may be labeled as an “SeNB Release Confirm message”.

[0086] Accordingly, at step 8, the MN 420 may initiate an RRC reconfiguration procedure to request or instruct the UE 430 to release from the SN 410 (or an SCG associated with the SN 410). Similar to step 8 described above in the first example use case 301 of FIG. 3A, the MN 420 may send an RRC Reconfiguration message (e g., RRC Reconfiguration (SN Release) message, RRC Reconfiguration (SCG Release) message, etc.) to the UE 430 to request the UE 430 to release from the SN 410 (or the associated SCG).

[0087] Referring next to FIG. 4B, which illustrates a call flow of a fourth example use case 402 associated with SN Modification initiated by the SN, with the implementation of one or more example embodiments. Similar to example use case 401 in FIG. 4A, example use case 402 may also include an SN 410 (i.e., a first network entity) and an MN 420 (i.e., a second network entity) that constitute a network, and a UE 430 is assumed to be attached to the network and the SN 410 is assumed to be added, at the beginning of the call flow.

[0088] One or more operations or steps in example use case 402 may be similar to those described above with reference in example use case 401. For instance, steps 1 and 6 in example use case 402 may be similar to step 1 and 8 in example use case 401, respectively. Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0089] Example use case 402 is different from example use case 401 in that, upon implementing one or more example embodiments, the SN 410 may include information of a preferred fallback action (e.g., an SN Release procedure in this example use case) in the S-Node Modification Required message and send the message to the MN 420 at step 2. Accordingly, at step 3, when the MN 420 determines that the modification requested by the SN 410 is not feasible or has failed, the MN 420 may trigger the preferred fallback action specified in the request message. For instance, at step 4 of this example use case, the MN 420 may provide an S-Node Release Request message to the SN 410 to initiate the SN Release procedure. The provision of the S-Node Release Request message may inherently or explicitly indicate to the SN 410 that the preferred fallback action is triggered by the MN 420. For instance, said message may include information (e.g., a flag, an IE, etc.) that indicates or notifies the SN 410 that the preferred fallback action is triggered. According to example embodiments where the SN 410 is a gNB, the S-Node Release Request message may be labeled as an “SgNB Release Request message”. Similarly, according to example embodiments where the SN 410 is an eNB, the S-Node Release Request message may be labeled as an “SeNB Release Request message”.

[0090] Accordingly, at step 5, the SN 410 may receive the response from the MN 420 (e.g., the S-Node Release Request message) and perform one or more operations associated with the fallback action (e.g., SNRelease) based thereon. In this example use case, the SN 410 may perform the fallback action by releasing resources associated with UE 430. Further, the SN 410 may sendan S-Node Release Request Acknowledge message to the MN 420, in response to the S-Node-Release Request message. According to example embodiments where the SN 410 is a gNB, the S-Node Release Request Acknowledge message may be labeled as an “SgNB Release Request Acknowledge message”. Similarly, according to example embodiments where the SN 410 is an eNB, the S-Node Release Request Acknowledge message may be labeled as an “SeNB Release Request Acknowledge message”.

[0091] By comparing the example use case 402 (with the implementation of example embodiments) with the example use case 401 (without the implementation of example embodiments), in the example use case 402, the fallback action (e.g., SN Release) is triggered by the MN 420 when it determines that the primary action (e.g., SN Modification) requested by the SN 410 is not feasible or has failed. Specifically, instead of sending a message that simply indicates a refusal or failure of the requested primary action (e.g., S-Node Modification Refuse message) to the SN 410 as in example use case 401, the MN 420 in example use case 402 sends a message that initiates or triggers the preferred fallback action (e.g., S-Node Release Request message) to the SN 410. Accordingly, by implementing the example embodiments, the preferred fallback action can be initiated and performed faster (i.e., in example use case 401 that does not implement example embodiments, the SN Release procedure is initiated at step 6 and performed at step 7 and step 8; On the other hand, in example use case 402 that implements example embodiments, the SN Release procedure is initiated at step 4 and performed at step 5 and step 6) and the signaling overhead and computing before initiating the fallback action can be reduced (i.e., in example use case 401 that does not implement example embodiments, two additional steps 4 and 5 are required before the fallback action is triggered; in example use case 402 that implements example embodiments, the fallback action is triggered at step 4 without requiring said additional steps 4and 5 as in the example use case 401, thereby reducing the total number of steps from 8 steps in the example use case 401 to 6 steps in the example use case 402).

[0092] In view of the above, the example use cases in FIG. 3A to FIG. 4B illustrate that, by implementing one or more example embodiments, the fallback signaling among an MN and an SN in a telecommunication that implements dual connectivity can be effectively and efficiently optimized, thereby optimizing the overhead, energy consumption, and efficiency of the network. It is contemplated that the example use cases in FIG. 3A to FIG. 4B are merely examples for illustrating possible implementations of example embodiments to optimize fallback signaling among the MN and SN. The scope of the present disclosure is not limited to the specific use cases described above, and the example embodiments may be applicable to any other suitable operations between the MN and SN, without departing from the scope of the present disclosure.Example Use Cases associated with RAN Components

[0093] As described above with reference to the example configuration 102 in FIG. 1C, a Radio Access Network (RAN) may include a Central Unit (CU) and a Distributed Unit (DU), each of which may be communicatively coupled to one another. For instance, the CU may include a 5G CU (e.g., gNB-CU), an 0-RAN architecture-based CU (e.g., O-CU), or a combination thereof. Similarly, the DU may include a 5GDU (e.g., gNB-DU), an 0-RAN architecture-based DU (e.g., O-DU), or a combination thereof. The CU and DU may constitute, for example, a network node (e.g., an MN, an SN, etc.) described above. The CU and DU may communicate and interoperate with each other via an Fl interface. The operations and interactions among the CU and DU may be implemented via Fl Application Protocol (F1AP) signaling, and may be categorized into, for example, UE-associated operations, non-UE-associated operations, Multicast and Broadcast Services (MBS)-associated operations, and the like.

[0094] In operations, a UE may connect to a core network via the RAN (split into CU and DU). When the UE is attached to the RAN, both the CU and DU may maintain and manage the UE contexts (e.g., UE identifiers, radio bearer configurations, UE capability information, etc.). Since both the CU and DU may maintain and manage different parts of the UE context, either one of the CU and DU may trigger a UE Context Modification to modify the UE context when required. For instance, the DU may initiate the UE Context Modification based on determining the need to reconfigure the radio bearers (e.g., due to deteriorating radio conditions, etc.). As another example, the CU may initiate the UE Context Modification based on determining changes in core network parameters (e.g., updated security parameters, etc.).

[0095] In the following example use cases, it is assumed that a first network entity (i.e., either one of the CU and DU) triggers the UE Context Modification. Further, it is assumed that the network is configured such that, in case the UE Context Modification has failed or the request for the UE Context Modification is rejected, a UE Context Release procedure is initiated to release the resources and the UE context associated with the UE. Thus, in the following example use cases, it is assumed that the “primary action” includes a “UE Context Modification” and the “preferred fallback action” includes a “UE Context Release”. It is contemplated that the implementation of example embodiments is not limited thereto, and any other suitable actions or operations among the CU and DU may be encompassed.

[0096] In the following, example use cases associated with CU-initiated UE Context Modification are firstly described with reference to FIG. 5A and FIG. 5B, and example use cases associated with DU-initiated UE Context Modification are described with reference to FIG. 6A and FIG. 6B thereafter.

[0097] Specifically, FIG. 5 A illustrates a call flow of a fifth example use case 501 associated with UE Context Modification initiated by the CU, without implementing the example embodiments. On the other hand, FIG. 5B illustrates a call flow of a sixth example use case 502 associated with UE Context Modification initiated by the CU, with the implementation of one or more example embodiments. As illustrated in FIG. 5 A and FIG. 5B, the example use case 501 and example use case 502 include a CU 510, a DU 520, and a UE 530. In this regard, since the UE Context Modification is initiated by the CU 510, the CU 510 may also be referred to as the “first network entity” while the DU 520 may be referred to as the “second network entity”. It is assumed that, at the beginning of the call flows, a UE 530 is attached to the network.

[0098] Referring to FIG. 5 A, at step 1 , the CU 510 may trigger a UE Context Modification procedure. For instance, the CU 510 may trigger the UE Context Modification procedure to modify or change the established UE context (e.g., establishing, modifying, and releasing radio resources or sidelink resources, etc.), command the DU 520 to stop data transmission for the UE 530 for mobility management purposes, and the like.

[0099] At step 2, the CU 510 may send a UE Context Modification Request message to the DU 520 to instruct or request the DU 520 to perform the modification. Subsequently, at step 3, the DU 520 may receive the request message. Upon receiving the UE Context Modification Request message, the DU 520 may determine whether or not the requested modification is feasible. Accordingly, based on determining that the requested modification is feasible, the DU 520 may perform the modification on the associated UE context accordingly. If the modification is performed successfully on one or more of the associated UE context, the DU 520 may send a UE Context Modification Response message to the CU 510 to report thereto the modification or update in the UE context. On the other hand, based on determining that the requested modification is notfeasible or in case none of the requested modification(s) can be successfully performed, the DU 520 may send a UE Context Modification Failure message to the CU 510 to notify thereto the associated cause or reason of modification failure.

[0100] For descriptive purposes, it is assumed that in step 3 of example use case 501, the DU 520 determines that the requested modification is not feasible or none of the requested modification is successfully performed. Accordingly, at step 4, the DU 520 may send the UE Context Modification Failure message to the CU 510. Subsequently, at step 5, the CU 510 receives the UE Context Modification Failure message and determines a fallback action. In this example use case, the CU 510 decides to trigger or initiate a UE Context Release procedure as the fallback action, such that the DU 520 may resources associated with the UE 530

[0101] Accordingly, at step 6, the CU 510 may send a UE Context Release Command message to the DU 520 to instruct or request the DU 520 to release the resources associated with the UE 530. Upon receiving the UE Context Release Command message, the DU 520 may release the resources associated with the UE 530. Accordingly, at step 7, the DU 520 may send a UE Context Release Complete message to the CU 510 to notify thereto the completion of the UE Context Release procedure. In addition, at step 8, the DU 520 may send an RRC Release message to the UE 530 to request or instruct the UE 530 to disconnect from the DU 520 and / or CU 510. It is contemplated that steps 7 and 8 are both triggered by the reception of the UE Context Release Command message, and may be performed in any suitable sequence manner (e.g., steps 7 and 8 may be performed concurrently, etc.).

[0102] FIG. 5B illustrates a call flow of a sixth example use case 502 associated with UE Context Modification initiated by the CU, with the implementation of one or more example embodiments. Similar to example use case 501 in FIG. 5 A, example use case 502 may also includea CU 510 (i.e., a first network entity) and a DU 520 (i.e., a second network entity) that constitute a network, and a UE 530 is assumed to be attached to the network.

[0103] One or more operations or steps in example use case 502 may be similar to those described above with reference in example use case 501. For instance, steps 1, 5, 6, and 7 in example use case 502 may be similar to step 1, 6, 7, and 8 in example use case 501, respectively. Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0104] Example use case 502 is different from example use case 501 in that, upon implementing one or more example embodiments, the CU 510 may include information of a preferred fallback action (e g., a UE Context Release procedure in this example use case) in the UE Context Modification Request message and send the message to the DU 520 at step 2. Accordingly, at step 3, when the DU 520 determines that the modification requested by the CU 510 cannot be accepted or has failed, the DU 520 may trigger the preferred fallback action specified in the request message. For instance, at step 4 of example use case 502, the DU 520 may provide a UE Context Release Request message to the CU 510 to initiate the UE Context Release procedure. The provision of the UE Context Release Request message may inherently or explicitly indicate to the CU 510 that the preferred fallback action is triggered by the DU 520. For instance, said message may include information (e.g., a flag, an IE, a message header, etc.) that indicates or notifies the CU 510 that the preferred fallback action is triggered.

[0105] Upon receiving the UE Context Release Request message from the DU 520, the CU 510 may provide a UE Context Release Command to the DU 520 (at step 5). Subsequently, the DU 520 may provide a UE Context Release Complete message to the CU 510 (at step 6) and provide an RRC Release message to the UE 530 (at step 7).

[0106] By comparing the example use case 502 (with the implementation of example embodiments) with the example use case 501 (without the implementation of example embodiments), in the example use case 502, the fallback action (e.g., UE Context Release) is triggered by the DU 520 when it determines that the primary action (e.g., UE Context Modification) requested by the CU 510 is not feasible or has failed. Specifically, instead of sending a message that simply indicates a failure of the requested primary action (e.g., UE Context Modification Failure message) to the CU 510 as in example use case 501, the DU 520 in example use case 502 sends a message that initiates or triggers the preferred fallback action (e.g., UE Context Release Request message) to the CU 510. Accordingly, by implementing the example embodiments, the preferred fallback action can be initiated and performed faster (i.e., in example use case 501 that does not implement example embodiments, the UE Context Release procedure is initiated at step 6 and performed at step 7 and step 8; On the other hand, in example use case 502 that implements example embodiments, the UE Context Release procedure is initiated at step 4 and performed at step 5 to step 7) and the signaling overhead and computing before initiating the fallback action can be reduced (i.e., in example use case 501 that does not implement example embodiments, an additional step 5 is required before the fallback action is triggered; in example use case 502 that implements example embodiments, the fallback action is triggered at step 4 without requiring said additional step 5 as in the example use case 501, thereby reducing the total number of steps from 8 steps in the example use case 501 to 7 steps in the example use case 502).

[0107] Next, example use cases associated with DU-initiated UE Context Modification are described with reference to FIG. 6A and FIG. 6B. Specifically, FIG. 6A illustrates a call flow of a seventh example use case 601 associated with UE Context Modification initiated by the DU, without implementing the example embodiments. On the other hand, FIG. 6B illustrates a call flowof an eighth example use case 602 associated with UE Context Modification initiated by the DU, with the implementation of one or more example embodiments.

[0108] Similar to the example use cases in FIG. 5A and FIG. 5B, the example use cases in FIG. 6A and FIG. 6B includes a DU 610, a CU 620, and a UE 630. In this regard, since the UE Context Modification is initiated by the DU 610, the DU 610 may also be referred to as the “first network entity” while the CU 620 may be referred to as the “second network entity”. It is assumed that, at the beginning of the call flows, the UE 630 is attached to the network.

[0109] Referring to FIG. 6A, at step 1 , the DU 610 may trigger a UE Context Modification procedure. The conditions of triggering the UE Context Modification may be similar to those described above with reference to FIG. 5 A and FIG. 5B.

[0110] At step 2, the DU 610 may send a UE Context Modification Required message to the CU 620 to initiate the UE Context Modification (i.e., the primary action). At step 3, the CU 620 receives the request message and determines whether or not the requested modification is feasible. Based on determining that the requested modification is feasible, the CU 620 may provide a UE Context Modification Confirm message to the DU 610 to notify the DU 610 about the same. Otherwise, based on determining that the requested modification is not feasible or the requested modification has failed, the CU 620 may provide a UE Context Modification Refuse message to the DU 610. This UE Context Modification Refuse message may include information (e.g., IE, etc.) describing the cause(s) of the failure or rejection.[0U1] For descriptive purposes, it is assumed that in example use case 601, the CU 620 determines that the requested modification is not feasible or the requested modification has failed. Accordingly, at step 4, the CU 620 may send the UE Context Modification Refuse message to the DU 610. Subsequently, at step 5, the DU 610 receives the UE Context Modification Refusemessage and determines a fallback action. In this example use case, the DU 610 decides to trigger or initiate a UE Context Release procedure as the fallback action.

[0112] Accordingly, at step 6, the DU 610 may send a UE Context Release Request message to the CU 620 to request the CU 620 to release resources, configurations, and / or contexts associated with the UE 630. The UE Context Release Request message may also include information (e.g., IE, etc.) that indicates the reason for the Release request.

[0113] Upon receiving the UE Context Release Request message from the DU 610, the CU 620 may provide a UE Context Release Command to the DU 610 (at step 7). Subsequently, the DU 610 may provide an RRC Release message to the UE 630 (at step 8) and provide a UE Context Release Complete message to the CU 620 (at step 9).

[0114] FIG. 6B illustrates a call flow of an eighth example use case 602 associated with UE Context Modification initiated by the DU, with the implementation of one or more example embodiments. Similar to example use case 601 in FIG. 6A, example use case 602 may also include a DU 610 (i.e., a first network entity) and a CU 620 (i.e., a second network entity) that constitute a network, and a UE 630 is assumed to be attached to the network.

[0115] One or more operations or steps in example use case 602 may be similar to those described above with reference in example use case 601. For instance, steps 1, 5, and 6 in example use case 602 may be similar to step 1, 8, and 9 in example use case 601, respectively. Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0116] Example use case 602 is different from example use case 601 in that, upon implementing one or more example embodiments, the DU 610 may include information of a preferred fallback action (e g., a UE Context Release procedure in this example use case) in the UE Context Modification Required message and send the message to the CU 620 at step 2.Accordingly, at step 3, when the CU 620 determines that the modification requested by the DU 610 cannot be accepted or has failed, the CU 620 may trigger the preferred fallback action specified in the request message. For instance, at step 4 of example use case 602, the CU 620 may provide a UE Context Release Command message to the DU 610 to initiate or trigger the UE Context Release. The provision of the UE Context Release Command message may inherently or explicitly indicate to the DU 610 that the preferred fallback action is triggered by the CU 620. For instance, said message may include information (e.g., a flag, an IE, a message header, etc.) that indicates or notifies the DU 610 that the preferred fallback action is triggered. Upon receiving the UE Context Release Command message from the CU 620, the DU 610 may provide an RRC Release message to the UE 630 (at step 5) and provide a UE Context Release Complete message to the CU 620 (at step 6).

[0117] By comparing the example use case 602 (with the implementation of example embodiments) with the example use case 601 (without the implementation of example embodiments), in the example use case 602, the fallback action (e.g., UE Context Release) is triggered by the CU 620 when it determines that the primary action (e.g., UE Context Modification) requested by the DU 610 is not feasible or has failed. Specifically, instead of sending a message that simply indicates a failure of the requested primary action (e.g., UE Context Modification Refuse message) to the DU 610 as in example use case 601, the CU 620 in example use case 602 sends a message that initiates or triggers the preferred fallback action (e.g., UE Context Release Command message) to the DU 610. Accordingly, by implementing the example embodiments, the preferred fallback action can be initiated and performed faster (i.e., in example use case 601 that does not implement example embodiments, the UE Context Release procedure is initiated at step 6 and performed at step 7 to step 9; On the other hand, in example use case 602 that implementsexample embodiments, the UE Context Release procedure is initiated at step 4 and performed at step 5 to step 6) and the signaling overhead and computing before initiating the fallback action can be reduced (i.e., in example use case 601 that does not implement example embodiments, three additional steps 4 to 6 are required before the CU 620 provide the UE Context Release Command; on the other hand, in example use case 602 that implements example embodiments, the CU 620 may trigger the fallback action and directly provide the UE Context Release Command at step 4, without requiring said additional steps 4 to 6 as in the example use case 601, thereby reducing the total number of steps from 9 steps in the example use case 601 to 6 steps in the example use case 602).

[0118] In view of the above, the example use cases in FIG. 5 A to FIG. 6B illustrate that, by implementing one or more example embodiments, the fallback signaling among a CU and a DU in a RAN can be effectively and efficiently optimized, thereby optimizing the overhead, energy consumption, and efficiency of the network. It is contemplated that the example use cases in FIG.5A to FIG. 6B are merely examples for illustrating possible implementations of example embodiments to optimize fallback signaling among the CU and DU. The scope of the present disclosure is not limited to the specific use cases described above, and the example embodiments may be applicable to any other suitable operations between the CU and DU, without departing from the scope of the present disclosure.Example Use Cases associated with Split-CU Functionalities

[0119] As described above with reference to FIG. ID, in a split-CU architecture, the functionalities of a Central Unit (CU) may be split into a CU-Control Plane (CU-CP) and a CU-User Plane (CU-UP). According to example embodiments where the CU is a 5G-based gNB-CU, the CU-CP may be labeled as a “gNB-CU-CP” and the CU-UP may be labeled as a “gNB-CU-UP”. Similarly, according to example embodiments where the CU is an O-RAN-based O-CU, the CU-CP may be labeled as an “O-CU-CP” and the CU-UP may be labeled as an “O-CU-UP”. The CU-CP and CU-UP may communicate and interoperate with each other via an El interface. The operations and interactions among the CU-CP and CU-UP may be implemented via El Application Protocol (El AP) signaling, and may be categorized into, for example, bearer-associated operations, non-bearer-associated operations, and the like.

[0120] When a UE is connected and attached to the network, a bearer may be established and setup to carry data (e.g., user data, control data, etc.) between the UE and the core network. In this regard, the CU-CP and CU-UP may interoperate to perform one or more bearer-associated operations, such as Bearer Context Establishment, Bearer Context Modification, Bearer Context Release, and the like.

[0121] In the following example use cases, it is assumed that a first network entity (e.g., the CU-CP) triggers the Bearer Context Modification. Further, it is assumed that the network is configured such that, in case the Bearer Context Modification has failed, a Bearer Context Release procedure is initiated to delete an associated bearer. Thus, in the following example use cases, it is assumed that the “primary action” includes a “Bearer Context Modification” and the “preferred fallback action” includes a “Bearer Context Release”. It is contemplated that the implementation of example embodiments is not limited thereto, and any other suitable actions or operations among the CU-CP and CU-UP may be encompassed.

[0122] In the following, example use cases associated with CU-CP-initiated Bearer Context Modification are described with reference to FIG. 7A to FIG. 7B. Specifically, FIG. 7A illustrates a call flow of a ninth example use case 701 associated with Bearer Context Modification initiated by the CU-CP, without implementing the example embodiments. On the other hand, FIG.7B illustrates a call flow of a tenth example use case 702 associated with Bearer Context Modification initiated by the CU-CP, with the implementation of one or more example embodiments. As illustrated in FIG. 7A and FIG. 7B, the example use case 701 and example use case 702 include a CU-CP 710, a CU-UP 720, and a UE 730. In this regard, since the Bearer Context Modification is initiated by the CU-CP 710, the CU-CP 710 may also be referred to as the “first network entity” while the CU-UP 720 may be referred to as the “second network entity”. It is assumed that, at the beginning of the call flows, the UE 730 is attached to the network and a bearer is setup therebetween.

[0123] Referring to FIG. 7A, at step 1, the CU-CP 710 may trigger a Bearer Context Modification procedure. For instance, the CU-CP 710 may trigger the Bearer Context Modification during a handover, in response to a change in quality of service (QoS) requirements, and the like.

[0124] At step 2, the CU-CP 710 may send a Bearer Context Modification Request message to the CU-UP 720 to initiate the Bearer Context Modification (i.e., the primary action). At step 3, the CU-UP 720 receives the request message and determines whether or not the requested modification is feasible. Based on determining that the requested modification is feasible, the CU-UP 720 may attempt to perform the modification based on the Bearer Context Modification Request message. Accordingly, if the CU-UP 720 successfully modifies the bearer context as requested, the CU-UP 720 may provide a Bearer Context Modification Response message to the CU-CP 710 to notify the CU-CP 710 about the same. Otherwise, based on determining that the requested modification is not feasible or the requested modification has failed, the CU-UP 720 may provide a Bearer Context Modification Failure message to the CU-CP 710. This Bearer Context Modification Failure message may include information (e.g., IE, etc.) describing the cause(s) of the failure or rejection.

[0125] For descriptive purposes, it is assumed that in example use case 701, the CU-UP 720 determines that the requested modification is not feasible or the requested modification has failed. Accordingly, at step 4, the CU-UP 720 may send the Bearer Context Modification Failure message to the CU-CP 710. Subsequently, at step 5, the CU-CP 710 receives the Bearer Context Modification Failure message and determines a fallback action. In this example use case, the CU-CP 710 decides to trigger or initiate a Bearer Context Release procedure as the fallback action.

[0126] Accordingly, at step 6, the CU-CP 710 may send a Bearer Context Release Command message to the CU-UP 720 to instruct or command the CU-UP 720 to release the resources of the associated bearer. Upon receiving the Bearer Context Release Command message from the CU-CP 710, the CU-UP 720 may release resources associated with the UE 730. Accordingly, at step 7, the CU-UP 720 may send a Bearer Context Release Complete message to the CU-CP 710 to notify the completion of Bearer Release at the CU-UP 720.

[0127] Accordingly, at step 8, the CU-CP 710 may initiate an RRC reconfiguration procedure to request or instruct the UE 730 to delete resources of the associated bearer. In the example use case 701, the CU-CP 710 sends an RRC Reconfiguration message to the UE 730 to request the UE 730 to delete resources of the associated bearer. Thus, the RRC Reconfiguration message may also be labeled as an “RRC Reconfiguration (Bearer Delete) message” herein.

[0128] FIG. 7B illustrates a call flow of a tenth example use case 702 associated with Bearer Context Modification initiated by the CU-CP, with the implementation of one or more example embodiments. Similar to example use case 701 in FIG. 7A, example use case 702 may also include a CU-CP 710 (i.e., a first network entity) and a CU-UP 720 (i.e., a second network entity) that constitute a network, and a UE 730 is assumed to be attached to the network and a bearer is established therebetween.

[0129] One or more operations or steps in example use case 702 may be similar to those described above with reference in example use case 701. For instance, steps 1, 5, 6 and 7 in example use case 702 may be similar to step 1, 6, 7, and 8 in example use case 701, respectively. Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0130] Example use case 702 is different from example use case 701 in that, upon implementing one or more example embodiments, the CU-CP 710 may include information of a preferred fallback action (e.g., a Bearer Context Release procedure in this example use case) in the Bearer Context Modification Request message and send the message to the CU-UP 720 at step 2. Accordingly, at step 3, when the CU-UP 720 determines that the modification requested by the CU-CP 710 cannot be accepted or has failed, the CU-UP 720 may trigger the preferred fallback action specified in the request message. For instance, at step 4 of example use case 702, the CU-UP 720 may provide a Bearer Context Release Request message to the CU-CP 710 to initiate the Bearer Context Release. The provision of the Bearer Context Release Request message may inherently or explicitly indicate to the CU-CP 710 that the preferred fallback action is triggered by the CU-UP 720. For instance, said message may include information (e.g., a flag, an IE, a message header, etc.) indicates or notifies the CU-UP 710 that the preferred fallback action is triggered.

[0131] Upon receiving the Bearer Context Release Request message from the CU-UP 720, the CU-CP 710 may provide a Bearer Context Release Command message to the CU-UP 720 (at step 5), receives a Bearer Context Release Complete message from the CU-UP 720 (at step 6), and provide an RRC Reconfiguration (Bearer Delete) message to the UE 730 (at step 7).

[0132] By comparing the example use case 702 (with the implementation of example embodiments) with the example use case 701 (without the implementation of example embodiments), in the example use case 702, the fallback action (e.g., Bearer Context Release) istriggered by the CU-UP 720 when it determines that the primary action (e.g., Bearer Context Modification) requested by the CU-CP 710 is not feasible or has failed. Specifically, instead of sending a message that simply indicates a failure of the requested primary action (e.g., Bearer Context Modification Failure message) to the CU-CP 710 as in example use case 701, the CU-UP 720 in example use case 702 sends a message that initiates or triggers the preferred fallback action (e.g., Bearer Context Release Request message) to the CU-CP 710. Accordingly, by implementing the example embodiments, the preferred fallback action can be initiated and performed faster (i.e., in example use case 701 that does not implement example embodiments, the Bearer Context Release procedure is initiated at step 6 and performed at step 7 to step 8; On the other hand, in example use case 702 that implements example embodiments, the Bearer Context Release procedure is initiated at step 4 and performed at step 5 to step 7) and the signaling overhead and computing before initiating the fallback action can be reduced (i.e., in example use case 701 that does not implement example embodiments, an additional step 5 is required before the CU-CP 710 provides the Bearer Context Release Command; on the other hand, in example use case 702 that implements example embodiments, the CU-UP 720 may trigger the fallback action and provide the Bearer Context Release Request message to the CU-CP 710, which enables the CU-CP 710 to directly provide the Bearer Context Release Command in response thereto without requiring said additional step 5 as in the example use case 701, thereby reducing the total number of steps from 8 steps in the example use case 701 to7 steps in the example use case 702).

[0133] In view of the above, the example use cases in FIG. 7A and FIG. 7B illustrate that, by implementing one or more example embodiments, the fallback signaling among a CU-CP and a CU-UP in a CU can be effectively and efficiently optimized, thereby optimizing the overhead, energy consumption, and efficiency of the network. It is contemplated that the example use casesin FIG. 7A and FIG. 7B are merely examples for illustrating possible implementations of example embodiments to optimize fallback signaling among the CU-CP and CU-UP. The scope of the present disclosure is not limited to the specific use cases described above, and the example embodiments may be applicable to any other suitable operations between the CU-CP and CU-UP, without departing from the scope of the present disclosure.Example Use Cases associated with NG-RAN Node and Core Network

[0134] As described above with reference to FIG. IE, an NG-RAN node (e.g., gNB, ng-eNB, etc.) may communicate and interoperate with a function of a core network, such as an AMF of a 5GC, via an N2 interface. The operations and interactions among the NG-RAN node and the core network function may be implemented via Next Generation Application Protocol (NGAP) signaling. The operations and interactions among the NG-RAN node and the core network function may be categorized according to the type of the core network function. In the following example use case, it is assumed that the NG-RAN node is communicatively coupled to the AMF of a 5GC. In this regard, the operations and interactions among the NG-RAN node and the AMF may be categorized into, for example, UE-associated operations and non-UE-associated operations.

[0135] When a UE is connected to the network, the NG-RAN node may interoperate with the AMF to manage the initial UE registration and attachment, UE context setup, and the like. After the UE is attached to the network, the NG-RAN node and AMF may interoperate to manage the UE context associated with the UE. In this regard, the AMF may trigger a UE Context Modification procedure to modify or update the UE context in the NG-RAN node.

[0136] In the following example use cases, it is assumed that a first network entity (e.g., the AMF) triggers the UE Context Modification procedure. Further, it is assumed that the network is configured such that, in case the UE Context Modification has failed, a UE Context Releaseprocedure is initiated to release the UE and the associated UE context. Thus, in the following example use cases, it is assumed that the “primary action” includes a “UE Context Modification” and the “preferred fallback action” includes a “UE Context Release”. It is contemplated that the implementation of example embodiments is not limited thereto, and any other suitable actions or operations among the NG-RAN node and AMF may be encompassed.

[0137] In the following, example use cases associated with AMF-initiated UE Context Modification are described with reference to FIG. 8 A to FIG. 8B. Specifically, FIG. 8 A illustrates a call flow of an eleventh example use case 801 associated with UE Context Modification initiated by the AMF, without implementing the example embodiments. On the other hand, FIG. 8B illustrates a call flow of a twelfth example use case 802 associated with UE Context Modification initiated by the AMF, with the implementation of one or more example embodiments. As illustrated in FIG. 8A and FIG. 8B, the example use case 801 and example use case 802 include an AMF 810, an NG-RAN Node 820, and a UE 830. In this regard, since the UE Context Modification is initiated by AMF 810, the AMF 810 may also be referred to as the “first network entity” while the NG-RAN Node 820 may be referred to as the “second network entity”. It is assumed that, at the beginning of the call flows, the UE 830 is attached to the network.

[0138] Referring to FIG. 8A, at step 1, the AMF 810 may trigger a UE Context Modification procedure. For instance, the AMF 810 may trigger the UE Context Modification procedure to modify or change the established UE context (e.g., establishing, modifying, and releasing bearers, etc.), command the NG-RAN Node 820 to stop data transmission for the UE 830 for mobility management purposes, and the like.

[0139] At step 2, the AMF 810 may send a UE Context Modification Request message to the NG-RAN Node 820 to instruct or request the NG-RAN Node 820 to perform the modification.Subsequently, at step 3, the NG-RAN Node 820 may receive the request message. Upon receiving the UE Context Modification Request message, the NG-RAN Node 820 may determine whether or not the requested modification is feasible. Accordingly, based on determining that the requested modification is feasible, the NG-RAN Node 820 may perform the modification on the associated UE context accordingly. If the modification is performed successfully, the NG-RAN Node 820 may send a UE Context Modification Response message to the AMF 810 to report thereto the modification or update in the UE context. On the other hand, based on determining that the requested modification is not feasible or in case the requested modification(s) can be successfully performed, the NG-RAN Node 820 may send a UE Context Modification Failure message to the AMF 810 to notify thereto the associated cause or reason of modification failure.

[0140] For descriptive purposes, it is assumed that in step 3 of example use case 801, the NG-RAN Node 820 determines that the requested modification is not feasible or none of the requested modification is successfully performed. Accordingly, at step 4, the NG-RAN node 820 may send the UE Context Modification Failure message to the AMF 810. Subsequently, at step 5, the AMF 810 receives the UE Context Modification Failure message and determines a fallback action. In this example use case, the AMF 810 decides to trigger or initiate a UE Context Release procedure as the fallback action, such that the NG-RAN Node 820 may release UE Context and release resources associated with the UE 830

[0141] Accordingly, at step 6, the AMF 810 may send a UE Context Release Command message to the NG-RAN Node 820 to instruct or request the NG-RAN Node 820 to release UE context and resources associated with the UE 830. Upon receiving the UE Context Release Command message, the NG-RAN Node 820 may release resources associated with the UE 830. Accordingly, at step 7, the NG-RAN Node 820 may send a UE Context Release Complete messageto the AMF 810 to notify thereto the completion of the UE Context Release procedure. In addition, the NG-RAN Node 820 may send an RRC Release message to the UE 830 to request or instruct the UE 830 to disconnect from the NG-RAN Node 820 and / or AMF 810. It is contemplated that both steps 7 and 8 may be triggered based on the reception of the UE Context Release Command message, and steps 7 and 8 may be performed in any suitable sequential manner (e.g., steps 7 and 8 may be performed concurrently, etc.).

[0142] FIG. 8B illustrates a call flow of a twelfth example use case 802 associated with UE Context Modification initiated by the AMF, with the implementation of one or more example embodiments. Similar to example use case 801 in FIG. 8A, example use case 802 may also include an AMF 810 (i.e., a first network entity) and an NG-RAN Node 820 (i.e., a second network entity) that constitute a network, and a UE 830 is assumed to be attached to the network.

[0143] One or more operations or steps in example use case 802 may be similar to those described above with reference in example use case 801. For instance, steps 1, 5, 6, and 7 in example use case 802 may be similar to steps 1, 6, 7, and 8 in example use case 801, respectively. Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0144] Example use case 802 is different from example use case 801 in that, upon implementing one or more example embodiments, the AMF 810 may include information of a preferred fallback action (e.g., a UE Context Release procedure in this example use case) in the UE Context Modification Request message and send the message to the NG-RAN Node 820 at step 2. Accordingly, at step 3, when the NG-RAN Node 820 determines that the modification requested by the AMF 810 cannot be accepted or has failed, the NG-RAN Node 820 may trigger the preferred fallback action specified in the request message. For instance, at step 4 of example use case 802, the NG-RAN Node 820 may provide a UE Context Release Request message to theAMF 810 to initiate or trigger the UE Context Release. The provision of the UE Context Release Request message may inherently or explicitly indicate to the AMF 810 that the preferred fallback action is triggered by the NG-RANNode 820. For instance, said message may include information (e.g., a flag, an IE, a message header, etc.) that indicates or notifies the AMF 810 that the preferred fallback action is triggered.

[0145] Upon receiving the UE Context Release Request message from the NG-RAN Node 820, the AMF 810 may provide a UE Context Release Command to the NG-RAN Node 820 (at step 5). Subsequently, the NG-RAN NODE 820 may provide a UE Context Release Complete message to the AMF 810 (at step 6) and provide an RRC Release message to the UE 830 (at step 7).

[0146] By comparing the example use case 802 (with the implementation of example embodiments) with the example use case 801 (without the implementation of example embodiments), in the example use case 802, the fallback action (e.g., UE Context Release) is triggered by the NG-RAN Node 820 when it determines that the primary action (e.g., UE Context Modification) requested by the AMF 810 is not feasible or has failed. Specifically, instead of sending a message that simply indicates a failure of the requested primary action (e.g., UE Context Modification Failure message) to the AMF 810 as in example use case 801, the NG-RAN Node 820 in example use case 802 sends a message that initiates or triggers the preferred fallback action (e.g., UE Context Release Request message) to the AMF 810. Accordingly, by implementing the example embodiments, the preferred fallback action can be initiated and performed faster (i.e., in example use case 801 that does not implement example embodiments, the UE Context Release procedure is initiated at step 6 and performed at step 7 and step 8; On the other hand, in example use case 802 that implements example embodiments, the UE Context Release procedure is initiatedat step 4 and performed at step 5 to step 7) and the signaling overhead and computing before initiating the fallback action can be reduced (i.e., in example use case 801 that does not implement example embodiments, an additional step 5 is required before the fallback action is triggered; in example use case 802 that implements example embodiments, the fallback action is triggered at step 4 without requiring said additional step 5 as in the example use case 801, thereby reducing the total number of steps from 8 steps in the example use case 801 to 7 steps in the example use case 802).

[0147] In view of the above, the example use cases in FIG. 8A to FIG. 8B illustrate that, by implementing one or more example embodiments, the fallback signaling among a core network function (e.g., an AMF) and an NG-RAN node can be effectively and efficiently optimized, thereby optimizing the overhead, energy consumption, and efficiency of the network. It is contemplated that the example use cases in FIG. 8A to FIG. 8B are merely examples for illustrating possible implementations of example embodiments to optimize fallback signaling among the core network function and NG-RAN node. The scope of the present disclosure is not limited to the specific use cases described above, and the example embodiments may be applicable to any other suitable operations between the core network function and NG-RAN node, without departing from the scope of the present disclosure.Examples of Device

[0148] One or more components of the example embodiments (e.g., network entity, etc.), as well as the operations associated therewith, may be implemented in one or more devices or hardware components. For instance, one or more components / operations of the network entity may be implemented in one or more devices like a server(s), and the like.

[0149] In the following, descriptions of a device in which the example embodiments may be implemented are provided. It is contemplated that one or more features, operations, and methods described above may be performed by the device. For instance, the one or more operations or methods associated with a network entity may be performed by at least one processor of the device upon executing machine-readable instructions or computer-readable instructions stored in a memory or a storage component of the device.

[0150] FIG. 9 illustrates an embodiment of a device 900. As shown in FIG. 9, the device 900 may include a processor 910, a memory 920, a storage component 930, an input component 940, an output component 950, a communication interface 960, and a bus 970.

[0151] The processor 910, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 910 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and / or one or more single core processors, a distributed processing system, or the like. The processor 910 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0152] Memory 920 includes a non-transitory computer readable medium. Memory 920 includes a random-access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 910. The memory 920 comprises machine-readable instructions which are executable by the processor 910. These machine-readable instructions when executed by the processor 910 cause the processor 910 to perform one or more method steps of an embodiment described above.

[0153] Storage component 930 stores information and / or software related to the operation and use of the device 900. For example, storage component 930 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0154] Input component 940 is configured to receive information, such as user input. For example, the input component 940 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, or alternatively, the input component 940 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0155] Output component 950 is configured to provide output information from the device 900. For example, the output component 950 may be, but not limited to, a display, a speaker, instructions to an external device, and / or one or more light-emitting diodes (LEDs).

[0156] Communication interface 960 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 960 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the device 900 and other devices. In other words, the standard of the communication interface 960 is not limited.

[0157] The bus 970 acts as an interconnect between the processor 910, the memory 920, the storage component 930, the input component 940, the output component 950, and the communication interface 960 of the device 900. The bus 970 may include a wired interconnection or a wireless interconnection.

[0158] The number and arrangement of components shown in FIG. 9 are provided as an example. In practice, device 900 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 9. Additionally, or alternatively, a set of components (e.g., one or more components) of device 900 may perform one or more functions described as being performed by another set of components of device 900. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 900 in communication with one another.Example Implementation Environment

[0159] Example embodiments of the present disclosure may be implemented in any suitable type of environment. In the following, an example environment (in which the example embodiments may be implemented) is described.

[0160] FIG. 10 illustrates a diagram of an example environment 1000 in which systems and / or methods, described herein, may be implemented. The implementation environment 1000 includes a UE (User equipment) 1010, a service environment 1020, and a network 1030. The service environment 1020 includes one or more sub-environments 1021. To illustrate this, FIG. 10 shows, for convenience, examples of a 1st sub-environment 1021-1, a 2nd sub-environment 1021-2, and an N-th sub-environment 1021-N (where N is any natural number).

[0161] The UE 1010 is connected to the network 1030, and the network 1030 is connected to the service environment 1020. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 1010 and the service environment 1020 are connected via the network 1030.

[0162] The UE 1010 is a device that communicates with the service environment 1020. The UE 1010 receives information from the service environment 1020 and / or sends informationto the service environment 1020. Also, the UE 1010 may generate and / or store information to be transmitted, as necessary. Also, the UE 1010 may store and / or process information that is received, as necessary.

[0163] The example FIG. 10 refers to the “UE”. However, it should be understood by those skilled in the art that general terms such as “user device,” “terminal,” “terminal device,” “communication device,” and “communication terminal” can be used interchangeably with the term “UE.”

[0164] For example, the UE 1010 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 smart phone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or a similar device.

[0165] The service environment 1020 is an environment that communicates with the UE 1010 to provide one or more services. The service environment 1020 receives information from the UE 1010 and / or sends information to the UE 1010. Also, the service environment 1020 may generate and / or store information to be transmitted, as necessary. Also, the service environment 1020 may store and / or process information that is received, as necessary. For example, the service environment 1020 may provide computing resources as one of the services. It should be noted that the service is not limited to being provided to the UE; it may also be provided to devices other than the UE. For example, based on communication from the UE, the service may perform processes such as anomaly detection or traffic analysis and notify the results to a predetermined destination.

[0166] The example FIG. 10 refers to the “service environment”. The term "service environment" is used to refer to the broader context within which services operate. For example,cloud environments, platforms, computing systems, network systems, and cloud systems generally represent the environments in which services are conducted, and these are included within the "service environment." However, the "service environment" is not limited to these examples. Additionally, the specific types of environments within the "service environment" are not restricted. For instance, cloud environments and cloud systems can be categorized as private cloud, public cloud, hybrid cloud, or multi-cloud, all of which are included within the "service environment."

[0167] The one or more services provided by the service environment 1020 is not specifically limited and can be adjusted according to the embodiments. For example, the services may include a service that provides information to the UE 1010, a service that stores information from the UE 1010, or a service that performs processing based on information from the UE 1010 and returns the results of the processing.

[0168] In an embodiment, the Service Environments 1020 may also provide computing resources as the service. The computing resources can be hardware resources and / or software resources. For example, applications, processors, memory, and storage can be included in the provided computing resources. Each computing resource can communicate with other computing resources via wired connections, wireless connections, or a combination of wired and wireless connections.

[0169] The provided computing resources can be actual resources (also referred to as physical resources) and / or virtual resources. Furthermore, means of virtualization for virtual resources can be selected as appropriate. That is, in this disclosure, the use of adjectives such as "Virtual" or "Virtualized" to describe names does not imply that they are virtualized by a specific means of virtualization. For example, “virtual machine” refers to software that operates like an actual computer, realized through means of virtualization, and it is not intended to exclude thoserealized by specific means of virtualization such as Hypervisors or Containers. Conversely, when means of virtualization such as Hypervisors or containers are mentioned in this disclosure, it is merely cited as a general method of implementation. It should also be interpreted that embodiments implemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0170] The service environment 1020 includes one or more devices, such as servers and network devices, which provide services or perform processes. The placement of these devices within the service environment 1020 can be determined as appropriate. Additionally, if the service environment 1020 includes one or more sub-environments 1021, the placement of devices can be determined based on predetermined policies for each sub-environment 1021. For example, devices related to the first service may be placed in the 1st sub-environment 1021-1, and devices related to the second service may be placed in the 2nd sub-environment 1021-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st sub-environment 1021-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 1021-2. In this way, specific devices can be placed in specific sub-environments 1021. Conversely, each sub-environment 1021 can be specialized for a particular purpose.

[0171] In an embodiment, all processes executed in a single service may run within a single service environment, or in multiple service environments. Multiple processes executed in a single service could be provided by different service environments.

[0172] The network 1030 is a network that exchanges information between the HE 1010 and the service environment 1020. The network 1030 includes one or more wired and / or wireless networks.

[0173] For example, the network 1030 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., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, or the like, a non-terrestrial network (NTN), and / or a combination of these or other types of networks.

[0174] The network 1030 can be a part of a network. For example, in a 5G network that includes a RAN, a transport network, and a core network, the network 1030 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 1020 could be in the core network, in which case the network 1030 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0175] The number and arrangement of devices and networks shown in FIG. 10 are provided as an example. It should be understood that any changes that may be implemented by those skilled in the art, such as the addition or rearrangement of well-known devices or networks at the time of implementation, are included in this disclosure.Various Aspects of Embodiments

[0176] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely examples of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure.

[0177] Specifically, 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 frompractice of the implementations.

[0178] Some embodiments may relate to a device, a system, a method, and / or a computer-readable medium at any possible technical detail level of integration. Further, 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 thereon for causing a processor to carry out operations.

[0179] The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), electrically erasable programmable read-only memory (EEPROM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through afiber-optic cable), or electrical signals transmitted through a wire.

[0180] Computer-readable program instructions described herein can be downloaded to respective computing / processing devices from a computer-readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0181] Computer-readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages.

[0182] The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the 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 the connection may be made to an external computer (for example, through the Internet using an Internet ServiceProvider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0183] 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, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0184] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0185] The flowchart 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 flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer-readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted 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, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0186] It will be apparent that systems and / or methods, described herein, may be implemented in different 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 limited to the implementations. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code — it is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0187] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: A system comprising: a first network entity configured to: provide, to a second network entity, a request that includes information associated with a primary action and a preferred fallback action; receive, from the second network entity, a response to the request; determine, based on the response, whether the preferred fallback action is triggered; and based on determining that the preferred fallback action is triggered, perform the preferred fallback action.Item [2]: The system according to item [1], wherein the system further comprises the second network entity, and wherein the second network entity is configured to: receive, from the first network entity, the request that includes the information associated with the primary action and the preferred fallback action; determine whether the primary action is feasible; based on determining that the primary action is feasible, provide, to the first network entity, a response indicating that the primary action is accepted; and based on determining that the primary action is not feasible, provide, to the first network entity, a response indicating that the fallback action is triggered.Item [3]: The system according to one or more of items [l]-[2], wherein the first network entity is one of a master node (MN) and a secondary node (SN) in a network that implements dual connectivity, and wherein the second network entity is another one of the MN and the SN.Item [4]: The system according to one or more of items [l]-[2], wherein the first network entity is one of a distributed unit (DU) and a central unit (CU) of a radio access network (RAN), and wherein the second network entity is another one of the DU and CU.Item [5]: The system according to item [3], wherein the first network entity is the MN and the second network entity is the SN, wherein the preferred fallback action comprises an SNRelease procedure, wherein the response received from the second network entity comprises an S-Node Release Required message, and wherein the first network entity is configured to perform the preferred fallback action by: providing, to the second network entity and in response to the S-Node Release Require message, an S-Node Release Confirm message to instruct the second network entity to release resources associated with the a user equipment (UE); and providing, to the UE and in response to the S-Node Release Required message, a Radio Resource Control (RRC) Reconfiguration message.Item [6]: The system according to item [3], wherein the first network entity is the SN and the second network entity is the MN, wherein the preferred fallback action comprises an SN Release procedure, wherein the response received from the second network entity comprises an S-Node Release Request message, and wherein the first network entity is configured to perform the preferred fallback action by: providing, to the second network entity and in response to the S-Node Release Request message, an S-Node Release Request Acknowledge message.Item [7]: The system according to item [4], wherein the first network entity is the DU and the second network entity is the CU, wherein the preferred fallback action comprises a User Equipment (UE) Context Release procedure, wherein the response received from the second network entity comprises a UE Context Release Command message, and wherein the first network entity is configured to perform the preferred fallback action by: sending, to a UE and in response to the UE Context Release Command message, a Radio Resource Control (RRC) Release message to request to the UE to disconnect from the RAN; and sending, to the second network entity and in response to the UE Context Release Command message, a UE Context Release Complete message.Item [8]: The system according to one or more of items [3], [5], and [6], wherein the MN and the SN comprises at least one of: an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) node and a Next Generation Radio Access Network (NG-RAN) node.Item [9]: The system according to one or more of items [4] and [7], wherein the CU includes at least one of: a gNB-CU and an Open RAN (O-RAN) CU (O-CU), and wherein the DU includes at least one of: a gNB-DU and an O-RAN DU (O-DU).Item

[0010] : A method comprising: providing, to a network entity, a request that includes information associated with a primary action and a preferred fallback action; receiving, from the network entity, a response to the request; determining, based on the response, whether the preferred fallback action is triggered; and based on determining that the preferred fallback action is triggered, performing the preferred fallback action.Item

[0011] : The method according to item

[0010] , wherein the preferred fallback action comprises a Secondary Node (SN) Release procedure, wherein the response received from the network entity comprises an S-Node Release Required message, and wherein the performing the preferred fallback action comprises: providing, to the network entity and in response to the S-Node Release Require message, an S-Node Release Confirm message to instruct the network entity to release resources associated with the a user equipment (UE); and providing, to the UE and in response to the S-Node Release Required message, a Radio Resource Control (RRC) Reconfiguration message.Item

[0012] : The method according to item

[0010] , wherein the preferred fallback action comprises a Secondary Node (SN) Release procedure, wherein the response received from the network entity comprises an S-Node Release Request message, and wherein theperforming the preferred fallback action comprises: providing, to the second network entity and in response to the S-Node Release Request message, an S-Node Release Request Acknowledge message.Item

[0013] : The method according to item

[0010] , wherein the preferred fallback action comprises a User Equipment (UE) Context Release procedure, wherein the response received from the network entity comprises a UE Context Release Command message, and wherein the perform the preferred fallback action comprises: sending, to a UE and in response to the UE Context Release Command message, a Radio Resource Control (RRC) Release message; and sending, to the second network entity and in response to the UE Context Release Command message, a UE Context Release Complete message.Item

[0014] : The method according to one or more of items

[0010] ,

[0011] , and

[0012] , wherein the network entity is one of a master node (MN) and an SN in a network that implements dual connectivity.Item

[0015] : The method according to one or more of items

[0010] and

[0013] , wherein the network entity is one of a distributed unit (DU) and a central unit (CU) of a radio access network (RAN).Item

[0016] : A method comprising: receiving, from a network entity, a request that includes information associated with a primary action and a preferred fallback action; determining whether the primary action is feasible; based on determining that the primary action is feasible, providing, to the network entity, a first response indicating that the primary action is accepted; and based on determining that the primary action is not feasible, providing, to the network entity, a second response indicating that the fallback action is triggered.Item

[0017] : The method according to item

[0016] , wherein the second response comprises an S-Node Release Required message.Item

[0018] : The method according to item

[0016] , wherein the second response comprises an S-Node Release Request message.Item

[0019] : The method according to item

[0016] , wherein the second response comprises a User Equipment (UE) Context Release Command message.Item

[0020] : The method according to item one or more of items

[0016] -

[0018] , wherein the network entity is one of: a master node (MN) in a network that implements dual connectivity, a secondary node (SN) in the network that implements dual connectivity, a distributed unit (DU) of a radio access network (RAN), and a central unit (CU) of the RAN.

[0188] It can be understood that numerous modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.

Claims

What is claimed is:

1. A system comprising:a first network entity configured to:provide, to a second network entity, a request that includes information associated with a primary action and a preferred fallback action;receive, from the second network entity, a response to the request; determine, based on the response, whether the preferred fallback action is triggered; andbased on determining that the preferred fallback action is triggered, perform the preferred fallback action.

2. The system according to claim 1, wherein the system further comprises the second network entity, and wherein the second network entity is configured to:receive, from the first network entity, the request that includes the information associated with the primary action and the preferred fallback action;determine whether the primary action is feasible;based on determining that the primary action is feasible, provide, to the first network entity, a response indicating that the primary action is accepted; andbased on determining that the primary action is not feasible, provide, to the first network entity, a response indicating that the fallback action is triggered.

3. The system according to claim 1, wherein the first network entity is one of a master node (MN) and a secondary node (SN) in a network that implements dual connectivity, and wherein the second network entity is another one of the MN and the SN.

4. The system according to claim 1, wherein the first network entity is one of a distributed unit (DU) and a central unit (CU) of a radio access network (RAN), and wherein the second network entity is another one of the DU and CU.

5. The system according to claim 3, wherein the first network entity is the MN and the second network entity is the SN, wherein the preferred fallback action comprises an SN Release procedure, wherein the response received from the second network entity comprises an S- Node Release Required message, and wherein the first network entity is configured to perform the preferred fallback action by:providing, to the second network entity and in response to the S-Node Release Require message, an S-Node Release Confirm message to instruct the second network entity to release resources associated with the a user equipment (UE); and providing, to the UE and in response to the S-Node Release Required message, a Radio Resource Control (RRC) Reconfiguration message.

6. The system according to claim 3, wherein the first network entity is the SN and the second network entity is the MN, wherein the preferred fallback action comprises an SN Release procedure, wherein the response received from the second network entity comprises an S-Node Release Request message, and wherein the first network entity is configured to perform the preferred fallback action by:providing, to the second network entity and in response to the S-Node Release Request message, an S-Node Release Request Acknowledge message.

7. The system according to claim 4, wherein the first network entity is the DU and the second network entity is the CU, wherein the preferred fallback action comprises a User Equipment (UE) Context Release procedure, wherein the response received from the second network entity comprises a UE Context Release Command message, and wherein the first network entity is configured to perform the preferred fallback action by:sending, to a UE and in response to the UE Context Release Command message, a Radio Resource Control (RRC) Release message to request to the UE to disconnect from the RAN; andsending, to the second network entity and in response to the UE Context Release Command message, a UE Context Release Complete message.

8. The system according to claim 3, wherein the MN and the SN comprises at least one of:an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) node and a Next Generation Radio Access Network (NG-RAN) node.

9. The system according to claim 4, wherein the CU includes at least one of: a gNB-CU and an Open RAN (0-RAN) CU (O-CU), and wherein the DU includes at least one of: a gNB- DU and an 0-RAN DU (O-DU).

10. A method comprising:providing, to a network entity, a request that includes information associated with a primary action and a preferred fallback action;receiving, from the network entity, a response to the request;determining, based on the response, whether the preferred fallback action is triggered; andbased on determining that the preferred fallback action is triggered, performing the preferred fallback action.

11. The method according to claim 10, wherein the preferred fallback action comprises a Secondary Node (SN) Release procedure, wherein the response received from the network entity comprises an S-Node Release Required message, and wherein the performing the preferred fallback action comprises:providing, to the network entity and in response to the S-Node Release Require message, an S-Node Release Confirm message to instruct the network entity to release resources associated with the a user equipment (UE); andproviding, to the UE and in response to the S-Node Release Required message, a Radio Resource Control (RRC) Reconfiguration message.

12. The method according to claim 10, wherein the preferred fallback action comprises a Secondary Node (SN) Release procedure, wherein the response received from the networkentity comprises an S-Node Release Request message, and wherein the performing the preferred fallback action comprises:providing, to the second network entity and in response to the S-Node Release Request message, an S-Node Release Request Acknowledge message.

13. The method according to claim 10, wherein the preferred fallback action comprises a User Equipment (UE) Context Release procedure, wherein the response received from the network entity comprises a UE Context Release Command message, and wherein the perform the preferred fallback action comprises:sending, to a UE and in response to the UE Context Release Command message, a Radio Resource Control (RRC) Release message; andsending, to the second network entity and in response to the UE Context Release Command message, a UE Context Release Complete message.

14. The method according to claim 10, wherein the network entity is one of a master node (MN) and a secondary node (SN) in a network that implements dual connectivity.

15. The method according to claim 10, wherein the network entity is one of a distributed unit (DU) and a central unit (CU) of a radio access network (RAN).

16. A method comprising:receiving, from a network entity, a request that includes information associated with a primary action and a preferred fallback action;determining whether the primary action is feasible;based on determining that the primary action is feasible, providing, to the network entity, a first response indicating that the primary action is accepted; andbased on determining that the primary action is not feasible, providing, to the network entity, a second response indicating that the fallback action is triggered.

17. The method according to claim 16, wherein the second response comprises an S-Node Release Required message.

18. The method according to claim 16, wherein the second response comprises an S-Node Release Request message.

19. The method according to claim 16, wherein the second response indicating comprises a User Equipment (UE) Context Release Command message.

20. The method according to claim 16, wherein the network entity is one of a master node (MN) in a network that implements dual connectivity, a secondary node (SN) in the network that implements dual connectivity, a distributed unit (DU) of a radio access network (RAN), and a central unit (CU) of the RAN.

Images