Domestic roaming mobility denial management

Abstract

The present invention provides a device and method for receiving mobility denial information and neighbor information from each of multiple eNodeBs (eNBs). [Solution] A method for performing roaming mobility denial management includes: receiving mobility denial information and proximity information from each of a plurality of eNBs by service management and orchestration (SMO); identifying changes in the registered configuration for at least one eNB based on the received mobility denial information and proximity information; and sending at least one of a configuration change command and a notification to each of the neighboring eNBs corresponding to at least one eNB. A configuration change command is sent to the corresponding neighboring eNB to change the registered configuration of at least one eNB based on the identified changes in the registered configuration. A notification indicates a change in the registered configuration of at least one eNB.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims priority to Indian Non - Provisional Patent Application No. 202411072767, filed on September 26, 2024, the entire content of which is incorporated herein by reference.

[0002] This disclosure relates to domestic roaming mobility denial management.

Background Art

[0003] The information disclosed in this background art section is only for enhancing the understanding of the general background of this disclosure and should not be construed as an admission or any form of suggestion that this information forms prior art already known to those skilled in the art.

[0004] Wireless communication of mobile devices (or User Equipment: UEs) in transit is partially based on handover (HO) between a serving cell and a target cell. Handover occurs when a UE moves from the coverage area of ​​one cell to the coverage area of ​​another cell. Handover can occur for a variety of reasons, including the UE moving outside the current cell's range (e.g., driving outside the coverage area) or changes in network conditions (e.g., congestion or bad signal). Handovers are typically classified as either intra-operator handovers or inter-operator handovers. Intra-operator handovers occur when a UE moves from one cell to another cell managed by the same Mobile Network Operator (MNO). Intra-operator handovers generally result in minimal disruption, as the network is designed to manage these transitions seamlessly. Inter-operator handovers refer to the handover process between cells managed by different MNOs. Inter-operator handovers present further complexities due to differences in network architecture, policies, and agreements between operators. [Overview of the Initiative] [Means for solving the problem]

[0005] This summary is provided to introduce selected concepts in a simplified form, which are further described in the detailed description of this disclosure. This summary is not intended to identify any important or essential inventive concepts of this disclosure, nor to determine the scope of this disclosure.

[0006] This specification discloses an apparatus. The apparatus is configured to receive mobility denial information and neighbor information from each of a plurality of eNodeBs (eNBs). Based on the received mobility denial information and neighbor information, the apparatus is configured to identify changes in the registered configuration of at least one of the plurality of eNBs. The apparatus is also configured to send at least one of a configuration change command and a notification to each of the neighbor eNBs corresponding to that at least one eNB. A configuration change command is sent to change the registered configuration of the at least one eNB in ​​the corresponding neighbor eNB based on the identified changes in the registered configuration. A notification indicates a change in the registered configuration of that at least one eNB.

[0007] This specification discloses a method comprising receiving mobility denial information and neighbor information from each of a plurality of eNodeBs (eNBs) by Service Management and Orchestration (SMO). The method also comprises the SMO identifying a change in the registered configuration of at least one of the plurality of eNBs based on the received mobility denial information and neighbor information. The method also comprises the SMO sending at least one of a configuration change command and a notification to each of the neighbor eNBs corresponding to the at least one eNB. A configuration change command is sent to change the registered configuration of the at least one eNB in ​​the corresponding neighbor eNB based on the identified change in the registered configuration. A notification indicates a change in the registered configuration of the at least one eNB.

[0008] This specification discloses a non-temporary computer-readable medium for storing instructions. An instruction includes one or more instructions executed by Service Management and Orchestration (SMO). An instruction causes one or more processors to receive mobility denial information and neighbor information from each of a plurality of eNodeBs (eNBs). An instruction causes one or more processors to identify a change in the registered configuration of at least one of the plurality of eNBs based on the received mobility denial information and neighbor information. An instruction causes one or more processors to send at least one of a configuration change command and a notification to each of the neighbor eNBs corresponding to that at least one eNB. A configuration change command is sent to change the registered configuration of the at least one eNB in ​​the corresponding neighbor eNB based on the identified change in the registered configuration. A notification indicates a change in the registered configuration of the at least one eNB.

[0009] To further clarify the merits and features of this disclosure, a more detailed description of this disclosure is provided with reference to the specific embodiments illustrated in the accompanying drawings. It will be understood that these drawings illustrate only typical embodiments of this disclosure and should therefore not be considered limiting its scope. This disclosure is described and illustrated in more specific and detail with reference to the accompanying drawings. [Brief explanation of the drawing]

[0010] Features, aspects, and advantages of embodiments of this disclosure are described below with reference to the accompanying drawings, where similar figures indicate similar elements. [Figure 1] This illustrates a roaming scenario with limited handover using conventional technology. [Figure 2] A schematic block diagram illustrating a system for performing roaming mobility denial management according to one embodiment of this disclosure is provided. [Figure 3]A sequence flow diagram illustrating the establishment of a NETCONF session according to one embodiment of this disclosure is provided. [Figure 4] A sequence flow diagram illustrating the termination of a NETCONF session according to one embodiment of this disclosure is provided. [Figure 5] A flowchart illustrating a method for performing roaming mobility denial management according to one embodiment of this disclosure is provided as an example. [Figure 6] This is a diagram of an exemplary component of a wireless communication device according to one embodiment of the present disclosure. [Modes for carrying out the invention]

[0011] A detailed description of exemplary embodiments follows with reference to the accompanying drawings. This disclosure provides examples and descriptions, but is not intended to be exhaustive or to limit implementations to the forms disclosed. Modifications and changes are possible in light of this disclosure or can be obtained from implementation practice. Furthermore, 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). In addition, the flowcharts and descriptions of operations provided below relate to at least one of the embodiments of this disclosure. It should be noted that it is possible to make other embodiments that do not exactly correspond to the flowcharts and descriptions therein. It will be understood that in other embodiments, one or more operations may be omitted, one or more operations may be added, and one or more operations may be performed (at least partially) simultaneously.

[0012] It will be apparent that the systems and / or methods described herein can be implemented in various forms of hardware, software, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods should not be limited to their implementation. Therefore, this specification describes the operation and behavior of the systems and / or methods without referring to specific software code. It will be understood that software and hardware can be designed to implement the systems and / or methods based on the descriptions herein.

[0013] While certain combinations of features are described in the claims and / or disclosed herein, no particular combination is intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically described in the claims and / or disclosed herein. Even if a dependent claim depends directly on only one claim, this disclosure may suggest that the dependent claim depends on other claims within the set of claims.

[0014] Any element, action, or command used herein should not be construed as important or essential unless expressly stated otherwise. Furthermore, as used herein, the articles “a” and “an” (in other words, nouns not referred to in the plural) are intended to include one or more items and may be used interchangeably with “one or more.” Also, as used herein, terms such as “has,” “have,” “having,” “include,” and “including” are intended to be non-restrictive. Additionally, the phrase “based on” is intended to mean “at least partially based on” unless otherwise specified. Furthermore, expressions such as “at least one of [A] and [B],” “[A] and / or [B],” or “at least one of [A] or [B]” should be understood as including only A, only B, or both A and B.

[0015] The terms “mobile device,” “user device,” “user equipment,” and “UE” may be used interchangeably throughout this explanation.

[0016] Figure 1 illustrates a conventional limited handover (HO) roaming scenario 100. Figure 1 illustrates Mobile Network Operators (MNOs) A 102 and MNO B, which operate one or more cells. In the illustrated embodiment, MNO A 102 operates cells 1 and 4, and MNO B 104 operates cells 2 and 3. Cells 1 and 2 may operate adjacent to each other. For example, cell 1 may function as a neighbor of cell 2, and vice versa. MNOs A 102 and MNO B 104 provide wireless communication services to mobile devices such as smartphones, tablets, and IoT devices. MNOs A 102 and MNO B 104 are responsible for managing, operating, and maintaining the infrastructure necessary for mobile networking, including cellular networks, radio access networks (RANs), and core network elements. Cells 1, 2, 3, and 4 may refer to the geographical areas covered by the corresponding eNodeB (eNB) in the mobile network provided by MNO A 102 and MNO B 104. Cells 1, 2, 3, and 4 work together to manage the mobility of user devices. For example, when a mobile device moves from one cell to another, the MNO's network facilitates a handover to ensure continuous service and minimal disruption.

[0017] However, in conventional wireless systems, handover is limited for mobile devices moving from a cell where roaming is "open" to another cell where roaming is "not open."

[0018] For example, in the illustrated embodiment, MNO A 102 and MNO B 104 agree to enable roaming to cell 2 for MNO B 104, but roaming to cell 3 remains disabled. Furthermore, if MNO A 102 faces a service disruption in the area including cell 1, MNO A 102 requests MNO B 104 to allow its subscribers to roam in the area covering cell 1. However, MNO B 104 sets cellReservedForOperatorUse = "not reserved" for the Public Land Mobile Network (PLMN) ID used for roaming in System Information Block 1 (SIB1) broadcast in cell 2. Additionally, cellReservedForOperatorUse is set to "reserved" in cell 3 to prevent the roaming UE from accessing cell 3. Also, MNO A 102's UE (i.e., subscriber) is configured with the PLMN ID used for roaming. Therefore, when a UE loses its connection in cell 1, it initiates a cell selection procedure. In cell 2, cellReservedForOperatorUse is set to "not reserved" for the roaming PLMN ID, so the UE selects the PLMN and connects to cell 2. When the UE moves from cell 2 to cell 3, a handover may be triggered by the eNB associated with cell 2. However, for cell 3, the handover to cell 3 may be refused because cellReservedForOperatorUse is set to "reserved" for the roaming PLMN ID. Specifically, in a cell, cellReservedForOperatorUse = "reserved" may mean that the corresponding MNO is restricting the roaming UE to prevent access to the corresponding cell.

[0019] For example, in the case of a handover request to a target cell where cellReservedForOperatorUse = "reserved" and the rejectToreserved cell is set to true for the PLMN, the target cell sends a handover preparation failure with the cause "cell not available". In such a case, the source cell and / or the corresponding eNB may move that cell (i.e., the neighbor) to the non-priority list, and handover may not be permitted until a predetermined timer expires. For example, the predetermined timer may be the "hoRestrictionTimerForReservedCell" timer with an expiration time of 0, 5 minutes, 10 minutes, 20 minutes, or 60 minutes.

[0020] Furthermore, in the above scenario, if the target cell settings are dynamically changed, i.e., if cellReservedForOperatorUse is changed from "reserved" to "unreserved", or if the "rejectToreserved" flag is set to false, the source eNB and / or the cell may not detect such an update. A UE that attempts a HO to that cell, which is currently in the non-priority list, is prohibited from performing a HO to that cell until the set timer expires. Thus, even if the target cell can currently serve the UE, the UE is prevented from accessing the target cell in the non-priority list until the set timer. This results in an unfavorable user experience for the UE.

[0021] The present disclosure aims to solve one or more of the above-described problems in order to improve handover management during mobility.

[0022] Figure 2 illustrates a schematic block diagram of a system 200 for performing roaming mobility denial management according to one embodiment of the present disclosure. System 200 may include a plurality of eNBs (e.g., eNB-1 202-1 to eNB-N 202-N) and an SMO 210. For simplicity, the plurality of eNBs may be referred to as eNB 202. An eNB 202 may correspond to one or more cells associated with one or more MNOs. An eNB 202 may be configured to provide radio access to mobile devices. An eNB 202 can function as an interface between the UE and the core network. An eNB 202 may be configured to perform a variety of signal processing functions, including, but not limited to, modulation, demodulation, coding, and decoding. Each eNB 202 can manage radio resources for UEs in its corresponding coverage area (i.e., cell). An eNB 202 can facilitate inter-cell handovers to maintain active connectivity as users move in and out of individual coverage areas. Each eNB 202 can coordinate with neighboring eNBs (also called neighbors) to ensure seamless transitions. The eNB 202 may also be configured to track the location of its associated UE for mobility management. The eNB 202 may be further configured to establish and release connections with UEs and / or other entities in the network. Such sessions may include Network Configuration Protocol (NETCONF) sessions.

[0023] In one or more non-limiting embodiments of the present disclosure, each eNB 202 may include one or more Subscriber Managers (SMs) and an O1 node. The O1 node may include a neighbor update engine. For example, eNB-1 202-1 may include SM 204-1 and O1 node 206-1. The O1-node 206-1 may include a neighbor update engine 208-1. SM 204-1 can function as a functional component configured to manage interactions and data related to mobile subscribers connected to eNB-1 202-1. SM 204-1 may be configured to identify and authenticate mobile devices (or UEs) connected to eNB-1 202-1. For example, SM 204-1 can verify International Mobile Subscriber Identity (IMSI), Temporary Mobile Subscriber Identity (TMSI), and other related information associated with each of the mobile devices connected to eNB-1 202-1. In one embodiment, SM 204-1 can manage the establishment, modification, and release of data sessions for each of the mobile devices (and / or subscribers). SM 204-1 can also allocate radio resources for each connected subscriber based on the current network situation, subscriber profile, and policies. In some embodiments, SM 204-1 can also perform mobility management. For example, SM 204-1 can cooperate with a Mobility Management Entity (MME) (not shown) to manage location updates and handovers corresponding to each of the subscribers. In one or more embodiments, SM 204-1 may be implemented as one or more applications configured to perform one or more of the above-described functions / operations.

[0024] The O1 node 206-1 can function as an interface between the SM 204-1 and the SMO 210. The O1 node 206-1 can communicate with the SMO 210 via the O1 interface. The O1 node 206-1 may be configured to collect and report network data, configuration management, fault management, and network monitoring performance. The O1 node 206-1 may be configured to receive configuration updates and / or parameters from the SMO 210 via the O1 interface. In some embodiments, configuration updates and / or parameters may relate to Radio Resource Management (RRM), Quality of Service (QoS) policies, and software or firmware updates. In one or more embodiments, the O1 node 206-1 can enable the eNB-1 202-1 to report faults or alarms to the SMO 210. The O1 node 206-1 can also facilitate the transmission of performance data and statistics from the eNB-1 202-1 to the SMO 210. O1 node 206-1 can also support other necessary interfaces required to perform data transmission and reception to and from SMO 210.

[0025] The O1 node 206-1 may also include a neighbor update engine 208-1. The neighbor update engine 208-1 may be implemented in hardware, software, or a combination of hardware and software. The neighbor update engine 208-1 may be configured to maintain information for each of the neighboring eNBs and / or cells. Information related to neighboring eNBs and / or cells may include, but is not limited to, the state of the cellReservedForOperatorUse and the state of the rejectToreserved flag corresponding to each of the neighboring eNBs / cells (e.g., eNB-2 202-2 to eNB-N 202-N). In one embodiment, this information may also include a non-preferred list of eNBs for the HO process.

[0026] The previous paragraph described the components related to eNB-1 202-1, but the component descriptions are equally applicable to other eNB 202s.

[0027] Each eNB 202 may be connected to an SMO 210. The SMO 210 facilitates the management, orchestration, and optimization of the Radio Access Network (RAN). The SMO 210 enables operators to effectively manage multi-vendor RAN deployments and implement flexible automated network operations, significantly improving efficiency and service delivery. In one embodiment, the SMO 210 may be configured to orchestrate resources across the RAN, which includes configuring, managing, and coordinating various elements of the eNB 202. The SMO 210 may be configured to maintain service assurance and quality. In one embodiment, the SMO 210 may be configured to define and enforce policies related to network behavior and / or resource management. In one or more embodiments, the SMO 210 can implement advanced analytics and machine learning (ML) techniques to take necessary actions based on data collected on the network. This allows the SMO 210 to optimize network performance and improve the user experience.

[0028] In one embodiment, the SMO 210 may include a Non-Real Time RAN Intelligent Controller (Non-RT RIC) platform 212. The Non-RT RIC platform 212 operates at a higher layer and can perform RAN management and optimization. In some embodiments, the Non-RT RIC platform 212 can leverage advanced data analytics and ML techniques to analyze RAN performance, optimize resource allocation, and enforce network policies, thereby improving overall network efficiency and user experience.

[0029] SMO 210 can also implement one or more rApps. The rApps may support modular applications designed to run on a non-RT RIC platform 212. The rApps can provide value-added services related to RAN optimization and procedure optimization through the non-RT RIC platform 212. In one embodiment, SMO can implement an HO reject-to-reserved (HO) analytics engine rApp 214 (also known as rApp 214). rApp 214 may be configured to perform domestic mobility handover rejection management in accordance with this disclosure. In one or more embodiments, rApp 214 may be configured to communicate with each of the eNBs 202. rApp 214 may be configured to maintain a list of cells with a handover rejection flag set to true, where the cells are reserved for the corresponding eNB. In one embodiment, each eNB 202 can notify / update rApp 214 of reject-to-reserved (also known as rejectToreserved) cell information, along with information for the corresponding neighboring eNBs. eNB 202 can communicate the aforementioned information to rApp 214 via the O1 interface. rApp 214 may be configured to monitor and / or identify any changes in the registered and / or previously stored configurations corresponding to any of the eNB 202s. If rApp 214 identifies any changes in the configuration corresponding to any of the eNB 202s, rApp 214 may be configured to notify each of its neighboring eNB 202s of the identified changes. This allows neighboring eNB 202s to dynamically update the state of their corresponding eNB 202s. For example, a neighboring eNB 202 can remove an eNB from a non-preferred list.

[0030] In one embodiment, each eNB 202 and rApp 214 can execute a set of Remote Procedure Call (RPC) procedures. For example, eNB-1 202-1 can execute one or more of the example steps 1-4. If eNB-1 202-1 makes a configuration change, eNB-1 202-1 can execute step 1 to notify rApp 214 of the configuration change. Step 1 may correspond to an RPC configuration edit command that instructs the creation and / or merging of configuration information. In response to the RPC command in step 1, rApp 214 can execute step 2 to notify that the configuration change information has been successfully recorded. For example, rApp 214 may reply with an RPC configuration edit message accompanied by the response "Ok". If rApp 214 identifies a change in the configuration information of a neighboring cell / eNB of eNB-1 202-1, rApp 214 can execute step 3 to instruct eNB-1 202-1 to implement the identified change. Step 3 may correspond to Step 1 performed by eNB-1 202-1. Depending on the instructions received regarding the identified changes, eNB-1 202-1 may perform Step 4. Step 4 may correspond to Step 2 performed by rApp 214. Similar operations may be performed between each of the eNB 202 and the SMO 210 and / or rApp 214.

[0031] Figure 3 illustrates a sequence flow diagram 300 illustrating the establishment of a NETCONF session according to one embodiment of the present disclosure. The sequence flow diagram 300 may illustrate a series of operations between a Provisioning Management Service (MnS) consumer 302 (also called MnS consumer 302) and a Provisioning MnS provider 304 (also called MnS provider 304). In one embodiment, the MnS consumer 302 may correspond to one of the eNBs 202, and the MnS provider 304 may correspond to an SMO 210. In one embodiment, each eNB 202 establishes a NETCONF connection with the SMO 210 and / or rApp 214 according to the O1 interface standard. For example, in step 306, a Secure Shell (SSH) or Transport Layer Security (TLS) session is established between the MnS consumer 302 and the MnS provider 304. If NETCONF uses the SSH protocol as the transport protocol, an SSH session is established; if NETCONF uses TLS as the transport protocol, a TLS session is established. In step 308, the MnS consumer 302 sends a NETCONF hello message to the MnS provider 304. Accordingly, in step 310, the MnS provider 304 can send a NETCONF hello message containing a session ID and a list of capabilities. The exchange of NETCONF hello messages initiates a session and verifies the capabilities of both the MnS consumer 302 and the MnS provider 304. In one embodiment, the MnS consumer 302 may correspond to an MnS client, and the MnS provider 304 may correspond to an MnS server. When the MnS client sends a NETCONF hello message, the MnS client includes a payload containing a list of capabilities supported by the MnS client. Similarly, the MnS server responds with a NETCONF hello message containing a list of capabilities supported by the MnS server.Once a NETCONF session is established, the MnS consumer 302 and / or each eNB 202 can share a list of corresponding neighboring eNBs and cells registered as mobility-denied cells with the SMO 210 and / or rApp 214. In one embodiment, the eNB 202 can send the list of corresponding neighboring eNBs and cells in a configuration edit RPC message, as shown in step 1 of Figure 2. The MnS provider 304 and / or SMO 210 can maintain a list of neighboring eNBs and cells received from each of the eNBs 202 and keep a record of the received information. The MnS provider 304 and / or SMO 210 can respond with a configuration edit RPC message conveying an "OK" response, as shown in step 2 of Figure 2.

[0032] If any change is detected in a cell registered as a mobility-denied cell, rApp 214 and / or SMO 210 can notify each of the neighboring eNBs of the mobility-denied setting. In one embodiment, rApp 214 and / or SMO 210 can notify the mobility-denied setting in a setting edit RPC message, as shown in step 3 of Figure 2. In one embodiment, the O1 node of each eNB 202 (e.g., O1-node 206-1) can receive the mobility-denied setting from rApp 214. O1-node 206-1 can pass the received mobility-denied setting to one of the SMs 204-1. SM 204-1 can remove / add neighbors from or to the non-preferred list of the eNB / cell. Therefore, SMO 210 enables each eNB 202 to dynamically update the non-priority list of eNBs / cells and effectively perform mobility denial handover procedures.

[0033] Figure 4 illustrates a sequence flow diagram 400 illustrating NETCONF session termination according to one embodiment of the present disclosure. In order to terminate the NETCONF session, in step 402, the MnS consumer 302 can send a NETCONF session termination command / message to the MnS provider 304. In response to the received NETCONF session termination command / message, in step 404, the MnS provider 304 can reply with a NETCONF RPC response with a status of "OK". The NETCONF RPC response can indicate the successful termination of the NETCONF session between the MnS consumer 302 and the MnS provider 304.

[0034] Figure 5 illustrates a flowchart illustrating a method 500 for performing roaming mobility denial management according to one embodiment of the present disclosure. Method 500 may be performed by SMO 210.

[0035] In step 502, the SMO 210 can receive mobility denial information and neighbor information from each of the eNBs 202. In one embodiment, the mobility denial information may include a list of cells reserved for the corresponding eNB 202. The list of cells reserved for the corresponding eNB 202 prevents a handover for the mobility UE. The neighbor information may include a non-preferred list of neighboring eNBs. The non-preferred list of eNBs may include eNBs and / or cells whose handover requests have been denied.

[0036] In step 504, the SMO 210 can identify changes in the registered settings for at least one eNB 202 based on the received mobility denial information and neighborhood information. The registered confirmation may correspond to the stored mobility denial information and the neighborhood information stored in the SMO 210 for the corresponding eNB 202.

[0037] In step 506, SMO 210 can send a configuration change command to each of the neighboring eNBs corresponding to the at least one eNB 202 to change the registered configuration of that at least one eNB, based on the identified changes in the registered configuration. Furthermore, SMO 210 can send a notification to each of the neighboring eNBs corresponding to the at least one eNB indicating the change in the registered configuration of that at least one eNB.

[0038] In one embodiment, the SMO 210 can establish a NETCONF session with each of the eNBs 202. The NETCONF session may be established based on the O1 standard.

[0039] In one embodiment, the SMO 210 can receive mobility denial information and neighborhood information after a predetermined time interval set in each of the multiple eNBs 202.

[0040] In one embodiment, the SMO 210 can receive mobility denial information and neighbor information in response to changes identified by the corresponding eNB 202. In one embodiment, the mobility denial information indicates a flag (i.e., rejectToreserved) as true or false based on the corresponding cell setting (i.e., cellReservedForOperatorUse) as reserved or unreserved, respectively.

[0041] The steps described above in Figure 5 are shown and explained in a specific order, but these steps may be performed in a different order depending on the various embodiments. Furthermore, detailed explanations related to the various steps in Figure 5 have already been covered in the explanations related to Figures 2 to 4, and are omitted here for brevity.

[0042] Figure 6 shows exemplary components of a wireless communication device 600 (also referred to as device / apparatus 600) according to one embodiment of the present disclosure. In one or more embodiments, the wireless communication device 600 may correspond to an eNB 202 and / or SMO 210. As shown in Figure 6, the device 600 includes a processor 610, a memory 620, a storage component 630, an input component 640, an output component 650, a communication interface 660, and a bus 670.

[0043] As used herein, processor 610 means any type of computing circuit that may comprise hardware and software elements. Processor 610 may be embodied as a multicore processor, a single-core processor, a combination of one or more multicore processors and / or one or more single-core processors, a distributed processing system, and so on. Processor 610 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.

[0044] Memory 620 includes a non-temporary computer-readable medium. Memory 620 includes random-access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) for storing information and / or instructions used by the processor 610. Memory 620 is provided with machine-readable instructions that can be executed by the processor 610. When these machine-readable instructions are executed by the processor 610, they cause the processor 610 to perform one or more method steps of the embodiments described above.

[0045] The storage component 630 stores information and / or software related to the operation and use of device 600. For example, the storage component 630, along with a corresponding drive, may include hard disks (e.g., magnetic disks, optical disks, magneto-optical disks, and / or solid-state disks), compact discs (CDs), digital versatile discs (DVDs), floppy disks, cartridges, magnetic tapes, and / or other types of non-temporary computer-readable media.

[0046] The input component 640 is configured to receive information such as user input. For example, the input component 640 may include, but is not limited to, a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or a microphone. In addition, or instead, the input component 640 may include sensors that sense information (e.g., a Global Positioning System (GPS), accelerometer, gyroscope, and / or actuator).

[0047] The output component 650 is configured to provide output information from the device 600. For example, the output component 650 may be, but is not limited to, a display, a speaker, a command device for an external device, and / or one or more light-emitting diodes (LEDs).

[0048] The communication interface 660 is an interface that provides communication connectivity to other devices, such as external or internal devices. The connection via the communication interface 660 can be wired, wireless, or a combination of wired and wireless connections, and can be direct or indirect, via a communication network existing between device 600 and the other devices. In other words, the specifications for the communication interface 660 are not limited.

[0049] Bus 670 functions as an interconnection between the processor 610, memory 620, storage component 630, input component 640, output component 650, and communication interface 660 of device 600. Bus 670 may include wired interconnections or wireless interconnections.

[0050] The number and arrangement of components shown in Figure 6 are provided as an example. In practice, device 600 may include additional components, fewer components, different components, or components in different arrangements than those shown in Figure 6. In addition, or instead, one set of components of device 600 (e.g., one or more components) may perform one or more functions that are described as being performed by another set of components of device 600. Furthermore, one or more method steps described in any of the embodiments may be performed using multiple devices 600 communicating with one another.

[0051] Finally, it is understood that any term containing “unit” or “module” may refer to a unit for handling at least one function or operation, and may be implemented in hardware, software, or a combination of hardware and software.

[0052] In one embodiment, a device is described. This device is configured to receive mobility denial information and neighbor information from each of a plurality of eNodeBs (eNBs). Based on the received mobility denial information and neighbor information, this device is configured to identify changes in the registered configuration of at least one of the plurality of eNBs. This device is configured to send at least one of a configuration change command and a notification to each of the neighboring eNBs corresponding to that at least one eNB. A configuration change command is sent to change the registered configuration of the at least one eNB in ​​the corresponding neighboring eNB based on the identified changes in the registered configuration. A notification indicates a change in the registered configuration of that at least one eNB.

[0053] Before receiving mobility denial information and nearby information, this device: The device described in

[0051] is configured to establish a Network Configuration (NETCONF) session with each of the eNBs.

[0054] The device is one of the devices described in any one of

[0051] to

[0052] , comprising at least one rApp, and a NETCONF session being established based on the O1 interface standard.

[0055] Depending on the received mobility denial information and nearby information, this device will: The apparatus according to any one of

[0051] to

[0053] , configured to maintain a record corresponding to each eNB based on received mobility denial information and neighborhood information.

[0056] The device is configured to receive mobility denial information and proximity information after a predetermined time interval set in each of the multiple eNBs, as described in any one of

[0051] to

[0054] .

[0057] The device described in any one of

[0051] to

[0055] is configured to receive mobility denial information and neighborhood information in response to changes being identified by a corresponding eNB.

[0058] The mobility denial information is provided by the device according to any one of

[0051] to

[0056] , which indicates a flag as true or false based on the corresponding cell setting as reserved or not reserved.

[0059] The device described in any one of

[0051] to

[0057] shows a non-preferential list of neighboring eNBs for a corresponding eNB among multiple eNBs.

[0060] This device is a device described in any one of

[0051] to

[0058] that supports Service Management and Orchestration (SMO).

[0061] In one embodiment, a method is described. This method includes receiving mobility denial information and neighbor information from each of a plurality of eNodeBs (eNBs) by Service Management and Orchestration (SMO). The method also includes the SMO identifying changes in the registered configuration of at least one of the plurality of eNBs based on the received mobility denial information and neighbor information. The method includes the SMO sending at least one of a configuration change command and a notification to each of the neighbor eNBs corresponding to the at least one eNB. A configuration change command is sent to change the registered configuration of the at least one eNB in ​​the corresponding neighbor eNB based on the identified changes in the registered configuration. A notification indicates a change in the registered configuration of the at least one eNB.

[0062] Before receiving mobility denial information and nearby information, this method The method described in

[0060] , which includes establishing a Network Configuration (NETCONF) session with each of the eNBs using the SMO.

[0063] A NETCONF session is established based on the O1 interface standard, according to any one of the methods described in

[0060] to

[0061] .

[0064] Depending on the received mobility denial information and neighborhood information, this method will The method according to any one of

[0060] to

[0062] , comprising maintaining a record corresponding to each eNB based on received mobility denial information and neighborhood information by the SMO.

[0065] The method is one of the methods described in

[0060] to

[0063] , which includes receiving mobility denial information and proximity information after a predetermined time interval set in each of the multiple eNBs.

[0066] The method is one of the methods described in any one of

[0060] to

[0064] , which includes receiving mobility denial information and proximity information in response to a change being identified by a corresponding eNB.

[0067] The method according to any one of

[0060] to

[0065] , wherein mobility denial information indicates a flag as true or false based on the corresponding cell setting as reserved or not reserved.

[0068] The method according to any one of

[0060] to

[0066] , wherein neighbor information indicates a non-preferred list of neighboring eNBs for a corresponding eNB among multiple eNBs.

[0069] A non-temporary computer-readable medium for storing instructions is described. The instructions include one or more instructions executed by Service Management and Orchestration (SMO). The SMO comprises one or more processors. The instructions cause one or more processors to receive mobility denial information and neighbor information from each of a plurality of eNodeBs (eNBs). The instructions cause one or more processors to identify a change in the registered configuration of at least one of the plurality of eNBs based on the received mobility denial information and neighbor information. The instructions cause one or more processors to send at least one of a configuration change command and a notification to each of the neighboring eNBs corresponding to that at least one eNB. The configuration change command is sent to change the registered configuration of the at least one eNB in ​​the corresponding neighboring eNB based on the identified change in the registered configuration. The notification indicates a change in the registered configuration of that at least one eNB.

[0070] Before receiving mobility denial information and neighbor information, the instruction sends to one or more processors: A non-temporary computer-readable medium as described in

[0068] for establishing a Network Configuration (NETCONF) session with each of the eNBs.

[0071] The SMO comprises at least one rApp, and the NETCONF session is established based on the O1 interface standard, in a non-temporary computer-readable medium as described in any one of

[0068] to

[0069] .

[0072] Certain language is used to illustrate this disclosure, but no limitations are intended to arise from it. As will be apparent to those skilled in the art, various practical modifications can be made to the methods to realize the inventive concepts taught herein.

[0073] The drawings and the preceding description provide examples of embodiments. Those skilled in the art will understand that one or more of the elements described can be successfully combined into a single functional element. Alternatively, a particular element may be divided into multiple functional elements. Elements of one embodiment may be added to another embodiment. For example, the order of processes described herein may be changed and is not limited to the manner described herein.

[0074] Furthermore, the actions in any of the flowcharts do not need to be performed in the order shown, nor do all actions necessarily need to be performed. Also, actions that do not depend on other actions may be performed in parallel with other actions. The scope of the embodiments is by no means limited by these specific examples. Numerous modifications are possible, whether expressly stated herein or not, including differences in structure, dimensions, and the use of materials. The scope of the embodiments is broad, as given by at least the following claims.

[0075] Benefits, other advantages, and solutions to problems have been described above in relation to specific embodiments. However, those benefits, advantages, solutions to problems, and any components that may produce or make more apparent any benefits, advantages, or solutions should not be construed as essential, necessary, or required features or components of any or all of the claims.

[0076] The foregoing description of specific embodiments is intended to fully illustrate the general nature of the embodiments herein. Others may readily modify and / or adapt such specific embodiments for various uses without departing from the general concept by applying their current knowledge, and such adaptations and modifications should and are intended to be understood within the meaning and scope of the equivalent embodiments disclosed herein. It should be understood that any expressions or terms used herein are for illustrative purposes only and not for limitation. Thus, although the embodiments herein are described with respect to at least one embodiment, those skilled in the art will recognize that the embodiments herein can be practiced with modifications within the spirit and scope of the embodiments described herein.

Claims

1. Mobility denial information and nearby information are received from each of the multiple eNodeB (eNB) devices. Based on the received mobility denial information and the neighbor information, the system identifies changes in the registered settings for at least one of the multiple eNBs, and A configuration change command to change the registered settings of at least one eNB in ​​the corresponding neighboring eNB based on the identified changes in the registered settings, and Notification indicating the change to the registered settings of the at least one eNB At least one of these is configured to be transmitted to each of the neighboring eNBs corresponding to the at least one eNB, Device.

2. Before receiving the mobility denial information and the nearby information, the device: The apparatus according to claim 1, configured to establish a Network Configuration (NETCONF) session with each of the plurality of eNBs.

3. The apparatus according to claim 2, wherein the apparatus comprises at least one rApp, and the NETCONF session is established based on the O1 interface standard.

4. In accordance with the received mobility refusal information and the nearby information, the device shall The apparatus according to claim 1, configured to maintain a record corresponding to each eNB based on the received mobility denial information and the neighbor information.

5. The apparatus according to claim 1, wherein the apparatus is configured to receive the mobility denial information and the neighborhood information after a predetermined time interval set in each of the plurality of eNBs.

6. The apparatus according to claim 1, wherein the apparatus is configured to receive the mobility denial information and the neighborhood information in response to a change being identified by the corresponding eNB.

7. The apparatus according to claim 1, wherein the mobility denial information indicates a flag as true or false based on the corresponding cell setting as reserved or not reserved.

8. The apparatus according to claim 1, wherein the neighbor information indicates a non-priority list of neighboring eNBs for a corresponding eNB among the plurality of eNBs.

9. The apparatus according to claim 1, wherein the apparatus corresponds to Service Management and Orchestration (SMO).

10. Service Management and Orchestration (SMO) receives mobility denial information and proximity information from each of multiple eNodeB (eNB) units, Based on the received mobility denial information and the neighbor information, the SMO identifies changes in the registered settings for at least one of the multiple eNBs. According to the aforementioned SMO, A configuration change command to change the registered settings of at least one eNB in ​​the corresponding neighboring eNB based on the identified changes in the registered settings, and This includes sending at least one of the notifications indicating the change to the registered settings of the at least one eNB to each of the neighboring eNBs corresponding to the at least one eNB, method.

11. Before receiving the mobility denial information and the nearby information, the method The method according to claim 10, further comprising establishing a Network Configuration (NETCONF) session with each of the plurality of eNBs using the SMO.

12. The method according to claim 11, wherein the NETCONF session is established based on the O1 interface standard.

13. Depending on the received mobility refusal information and the nearby information, the method is as follows: The method according to claim 10, comprising maintaining a record corresponding to each eNB based on the received mobility denial information and the neighbor information using the SMO.

14. The method according to claim 10, wherein the method includes receiving the mobility denial information and the neighbor information after a predetermined time interval set in each of the plurality of eNBs.

15. The method according to claim 10, comprising receiving the mobility denial information and the neighborhood information in response to the change being identified by the corresponding eNB.

16. The method according to claim 10, wherein the mobility denial information indicates a flag as true or false based on the corresponding cell setting as reserved or not reserved.

17. The method according to claim 10, wherein the neighbor information indicates a non-preferential list of neighboring eNBs for a corresponding eNB among the plurality of eNBs.

18. A non-temporary computer-readable medium for storing instructions, which, when executed by a Service Management and Orchestration (SMO) comprising one or more processors, causes the one or more processors to: Mobility denial information and nearby information are received from each of the multiple eNodeB (eNB) devices. Based on the received mobility denial information and the neighbor information, the system identifies changes in the registered settings for at least one of the multiple eNBs, and A configuration change command to change the registered settings of at least one eNB in ​​the corresponding neighboring eNB based on the identified changes in the registered settings, and Notification indicating the change to the registered settings of the at least one eNB A non-temporary computer-readable medium in which the instruction includes one or more instructions that cause at least one of the eNBs to be transmitted to each of the neighboring eNBs corresponding to the at least one eNB.

19. Before receiving the mobility denial information and the neighbor information, the instruction sends to one or more processors: A non-temporary computer-readable medium according to claim 18, which establishes a Network Configuration (NETCONF) session with each of the plurality of eNBs.

20. The non-temporary computer-readable medium according to claim 19, wherein the SMO comprises at least one rApp, and the NETCONF session is established based on the O1 interface standard.

Images