FORM 2
THE PATENTS ACT, 1970 (39 OF 1970)
& THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“METHOD AND SYSTEM FOR RESTORING CONNECTION BETWEEN PEER
NETWORK NODES”
We, Jio Platforms Limited, an Indian National, of Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India.
The following specification particularly describes the invention and the manner in which
it is to be performed.
1

METHOD AND SYSTEM FOR RESTORING CONNECTION BETWEEN PEER
NETWORK NODES
FIELD OF THE DISCLOSURE
5
[0001] The present disclosure relates generally to the field of wireless communication systems. More particularly, the present disclosure relates to methods and systems for restoring connection (such as Xn connection) between peer network nodes (such as gNodeB (gNB)). 10
BACKGROUND
[0002] The following description of related art is intended to provide background
information pertaining to the field of the disclosure. This section may include certain
15 aspects of the art that may be related to various features of the present disclosure. However,
it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
[0003] Wireless communication technology has rapidly evolved over the past few
20 decades, with each generation bringing significant improvements and advancements. The
first generation of wireless communication technology was based on analog technology
and offered only voice services. However, with the advent of the second-generation (2G)
technology, digital communication and data services became possible, and text messaging
was introduced. 3G technology marked the introduction of high-speed internet access,
25 mobile video calling, and location-based services. The fourth-generation (4G) technology
revolutionized wireless communication with faster data speeds, better network coverage,
and improved security. Currently, the fifth-generation (5G) technology is being deployed,
promising even faster data speeds, low latency, and the ability to connect multiple devices
simultaneously. With each generation, wireless communication technology has become
30 more advanced, sophisticated, and capable of delivering more services to its users.
[0004] In the existing 5G Radio Network architecture, the Xn interface plays a crucial role in facilitating seamless handovers between neighboring gNodeBs. However, the current
2

mechanisms for managing this interface have been found to be inadequate in certain
scenarios. Specifically, the reliance on the Stream Control Transmission Protocol (SCTP)
for establishing and maintaining the transport layer of the Xn interface has limitations. One
of the primary issues observed is that the Xn connections between a gNodeB and some of
5 its neighboring gNodeBs can become "inoperative" due to various reasons, such as the
reboot of a peer node. In the current setup, there is no automatic recovery mechanism to re¬establish these downed Xn connections. This leads to a situation where handovers have to be routed through the core network nodes, resulting in increased latency and a potential degradation in the user experience. Moreover, the SCTP layer typically attempts to
10 establish connections with neighboring gNodeBs only during the initial boot-up process or
when a new neighbor is detected. If the initial attempts fail, there is no periodic retry mechanism in place to re-attempt the establishment of the Xn connections. This can be problematic in dynamic network environments where gNodeBs may be rebooted frequently, for example, during software upgrades.
15
[0005] Thus, there is an imperative need in the art to provide methods and systems for restoring connection between peer network nodes and overcome the limitations of the existing technologies, which the present disclosure aims to address.
20 OBJECTS OF THE INVENTION
[0006] Some of the objects of the present disclosure, which at least one embodiment disclosed herein satisfies are listed herein below.
25 [0007] It is an object of the present disclosure to provide a methods and systems for
restoring connection between peer network nodes.
[0008] It is another object of the present disclosure to provide a system and method for
restoring connection between peer network nodes, which enhances the robustness of the
30 Xn interface and improves handover performance in 5G Radio Network architecture.
[0009] It is another object of the present disclosure to provide a system and method for restoring connection between peer network nodes, which reduces the reliance on the core
3

network nodes for handover execution, thereby decreasing latency and improving user experience during mobility cases.
[0010] It is another object of the present disclosure to provide a system and method for
5 restoring connection between peer network nodes, which includes a monitoring unit to
continuously check the status of Xn connections and a processing unit to schedule Xn setup requests based on predefined time intervals.
[0011] It is another object of the present disclosure to provide a system and method for
10 restoring connection between peer network nodes, which allows for dynamic adjustment
of the predefined time interval for Xn setup requests based on network conditions or user traffic.
[0012] It is another object of the present disclosure to provide a system and method for
15 restoring connection between peer network nodes, which employs a transceiver unit to
transmit and receive Xn setup requests and responses, ensuring the timely restoration of downed Xn connections.
[0013] It is another object of the present disclosure to provide a system and method for
20 restoring connection between peer network nodes, which includes a storage unit to facilitate
the restoration of Xn connections with neighbouring gNodeBs for upcoming Xn setup requests.
[0014] It is another object of the present disclosure to provide a system and method for
25 restoring connection between peer network nodes, which enables the identification of valid
source cells based on determined source cell information in the Xn setup request, thereby increasing the handover success rate.
SUMMARY
30
[0015] This section is provided to introduce certain aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
4

[0016] An aspect of the present disclosure may relate to a method for restoring an Xn
connection with neighbouring gNodeBs. The method includes monitoring, by a monitoring
unit, the Xn connection status between a source gNodeB and at least one corresponding
5 neighbouring target gNodeB. The method further includes upon detection of at least one of
a lost or weakened Xn connection with the target gNodeB, scheduling, by a processing unit,
an Xn setup request based on a predefined time interval for initiating periodic Xn setup
requests. The method further includes transmitting, by a transceiver unit, the scheduled Xn
setup request from the source gNodeB to the target gNodeB. Thereafter, the method further
10 includes receiving, by the transceiver unit, a response to the Xn setup request at the source
gNodeB, wherein the response indicates the restored connection status with the target gNodeB.
[0017] In an aspect, the method comprises modifying, by the processing unit, the
15 predefined time interval based on at least one of a network condition or a user traffic.
[0018] In an aspect, the predefined time interval is dynamically determined based on historical Xn connection data between the source gNodeB and a set of neighbouring gNodeBs. 20
[0019] In an aspect, the method comprises storing, by a storage unit, the Xn setup request and the response to the Xn setup to facilitate the restoration of Xn connection with neighbouring gNodeBs for the upcoming Xn setup requests.
25 [0020] In an aspect, the lost or weakened Xn connection is detected based on at least one
of a set of predefined thresholds of signal quality or connection stability metrics.
[0021] In an aspect, identifying, by the processing unit via the target gNodeB, at least one valid source cell based on a determined source cell information in the Xn setup request. 30
[0022] In an aspect, the source cell information in the Xn setup request facilitates an increase in handover success rate by preventing the addition of invalid source cells in the NRT list.
5

[0023] In an aspect, the Xn setup request comprises an identifier for each of the served cells of the source gNodeB to allow the target gNodeB to selectively update the NRT list based on relevancy and proximity. 5
[0024] Another aspect of the present disclosure provides a system for restoring an Xn connection with neighbouring gNodeBs. The system includes a monitoring unit, configured to monitor the Xn connection status between a source gNodeB and at least one corresponding neighbouring target gNodeB. The system further includes a processing unit,
10 configured to schedule an Xn setup request based on a predefined time interval for initiating
periodic Xn setup requests upon detection of a lost or weakened Xn connection with the target gNodeB. The system further includes a transceiver unit, configured to transmit the scheduled Xn setup request from the source gNodeB to the target gNodeB. The system further includes the transceiver unit, configured to receive a response to the Xn setup
15 request at the source gNodeB, wherein the response indicates the restored connection status
with the target gNodeB.
[0025] Yet another aspect of the present disclosure may relate to a non-transitory computer-readable storage medium storing instruction for restoring an Xn connection with
20 neighbouring gNodeBs, the storage medium comprising executable code which, when
executed by one or more units of a system, causes: a monitoring unit to monitor the Xn connection status between a source gNodeB and at least one corresponding neighbouring target gNodeB; a processing unit to schedule an Xn setup request based on a predefined time interval for initiating periodic Xn setup requests upon detection of a lost or weakened
25 Xn connection with the target gNodeB; a transceiver unit to transmit the scheduled Xn
setup request from the source gNodeB to the target gNodeB; and the transceiver unit to receive a response to the Xn setup request at the source gNodeB, wherein the response indicates the restored connection status with the target gNodeB.
30 BRIEF DESCRIPTION OF DRAWINGS
[0026] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems
6

in which like reference numerals refer to the same parts throughout the different drawings.
Components in the drawings are not necessarily to scale, emphasis instead being placed
upon clearly illustrating the principles of the present disclosure. Some drawings may
indicate the components using block diagrams and may not represent the internal circuitry
5 of each component. It will be appreciated by those skilled in the art that disclosure of such
drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components.
[0027] FIG. 1 illustrates an exemplary block diagram representation of a system for
10 restoring connection between peer network nodes, in accordance with an embodiment of
the present disclosure.
[0028] FIG.2 illustrates an exemplary system architecture indicating the process for
restoring connection between peer network nodes, in accordance with exemplary
15 embodiments of the present disclosure.
[0029] FIG.3 illustrates an exemplary method flow chart of a system for restoring connection between peer network nodes, in accordance with exemplary embodiments of the present disclosure. 20
[0030] FIG.4 illustrates an exemplary method for restoring connection between peer network nodes, in accordance with exemplary embodiments of the present disclosure.
[0031] FIG. 5 illustrates an exemplary block diagram of a computing device upon which
25 an embodiment of the present disclosure may be implemented.
[0032] The foregoing shall be more apparent from the following more detailed description of the disclosure.
30 DETAILED DESCRIPTION
[0033] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the
7

present disclosure. It will be apparent, however, that embodiments of the present disclosure
may be practiced without these specific details. Several features described hereafter can
each be used independently of one another or with any combination of other features. An
individual feature may not address any of the problems discussed above or might address
5 only some of the problems discussed above. Some of the problems discussed above might
not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.
10 [0034] The ensuing description provides exemplary embodiments only, and is not
intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements
15 without departing from the spirit and scope of the disclosure as set forth.
[0035] It should be noted that the terms "mobile device", "user equipment", "user device", “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the
20 invention or imply any specific functionality or limitations on the described embodiments.
The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.
25
[0036] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as
30 components in block diagram form in order not to obscure the embodiments in unnecessary
detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
8

[0037] Also, it is noted that individual embodiments may be described as a process which
is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a
block diagram. Although a flowchart may describe the operations as a sequential process,
5 many of the operations can be performed in parallel or concurrently. In addition, the order
of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure.
[0038] The word “exemplary” and/or “demonstrative” is used herein to mean serving as
10 an example, instance, or illustration. For the avoidance of doubt, the subject matter
disclosed herein is not limited by such examples. In addition, any aspect or design described
herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as
preferred or advantageous over other aspects or designs, nor is it meant to preclude
equivalent exemplary structures and techniques known to those of ordinary skill in the art.
15 Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar
words are used in either the detailed description or the claims, such terms are intended to be inclusive—in a manner similar to the term “comprising” as an open transition word— without precluding any additional or other elements.
20 [0039] As used herein, an “electronic device”, or “portable electronic device”, or “user
device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical and computing device. The user device is capable of receiving and/or transmitting one or parameters, performing function/s, communicating with other user devices and transmitting data to the other user devices. The user equipment
25 may have a processor, a display, a memory, a battery and an input-means such as a hard
keypad and/or a soft keypad. The user equipment may be capable of operating on any radio access technology including but not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone,
30 smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a
general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure.
9

[0040] Further, the user device may also comprise a “processor” or “processing unit”
includes processing unit, wherein processor refers to any logic circuitry for processing
instructions. The processor may be a general-purpose processor, a special purpose
5 processor, a conventional processor, a digital signal processor, a plurality of
microprocessors, one or more microprocessors in association with a DSP core, a controller,
a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate
Array circuits, any other type of integrated circuits, etc. The processor may perform signal
coding data processing, input/output processing, and/or any other functionality that enables
10 the working of the system according to the present disclosure. More specifically, the
processor is a hardware processor.
[0041] As portable electronic devices and wireless technologies continue to improve and grow in popularity, the advancing wireless technologies for data transfer are also expected
15 to evolve and replace the older generations of technologies. In the field of wireless data
communications, the dynamic advancement of various generations of cellular technology are also seen. The development, in this respect, has been incremental in the order of second generation (2G), third generation (3G), fourth generation (4G), and now fifth generation (5G), and more such generations are expected to continue in the forthcoming time.
20
[0042] Radio Access Technology (RAT) refers to the technology used by mobile devices/ user equipment (UE) to connect to a cellular network. It refers to the specific protocol and standards that govern the way devices communicate with base stations, which are responsible for providing the wireless connection. Further, each RAT has its own set of
25 protocols and standards for communication, which define the frequency bands, modulation
techniques, and other parameters used for transmitting and receiving data. Examples of RATs include GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access), UMTS (Universal Mobile Telecommunications System), LTE (Long-Term Evolution), and 5G New Radio. The choice of RAT depends on a variety of factors,
30 including the network infrastructure, the available spectrum, and the mobile
device's/device's capabilities. Mobile devices often support multiple RATs, allowing them to connect to different types of networks and provide optimal performance based on the available network resources.
10

[0043] "Xn" is defined as the interface between two neighbouring gNodeBs (gNBs),
which are the base stations in a 5G network. The Xn interface enables direct
communication between these gNodeBs, supporting essential functions such as the
5 execution of handovers when a 5G phone (UE or User Equipment) moves from the
coverage area of one gNodeB to another. It is responsible for carrying both the control signalling necessary for handovers and the user plane data during the UE's transition between gNodeBs.
10 [0044] As used herein, gNodeB refers to a next-generation NodeB. The gNodeB serves as
the base station in the New Radio (NR) access technology, providing connectivity between the User Equipment (UE) and the 5G core network. The gNodeB supports the functionality required for radio resource management, mobility management, and the handling of signalling and data traffic. It operates within the framework of the 5G System (5GS)
15 architecture, interfacing with the Access and Mobility Management Function (AMF) and
the User Plane Function (UPF) to facilitate end-to-end communication and service delivery.
[0045] As used herein, the Xn interface refers to the logical interface between any two
20 neighbouring gNodeBs in a 5G network. The Xn interface supports the Xn-Application
Protocol (Xn-AP) over the Stream Control Transmission Protocol (SCTP), enabling the
exchange of signalling messages necessary for handovers and coordination between
gNodeBs. The Xn interface facilitates direct communication for control plane and user
plane data, optimizing handover procedures and reducing latency by avoiding the need for
25 routing traffic through core network elements such as the Access and Mobility
Management Function (AMF) and User Plane Function (UPF).
[0046] As used herein, the Xn connection refers to the logical connection established
between two neighbouring gNodeB for the purpose of exchanging control plane and user
30 plane information as specified. The Xn connection enables the execution of handover
procedures, coordination of radio resources, and transfer of user data between gNodeB. The Xn connection operates over the Xn interface and includes protocols such as Xn-AP over SCTP for low-latency communication between the gNodeB.
11

[0047] As used herein, the NRT list refers to the Neighbour Relation Table in which
contains information about neighbouring cells that are candidates for handover. The NRT
list is maintained by the gNodeB and includes identifiers and parameters for each
5 neighbouring cell, facilitating efficient handover management and optimization. The NRT
list is dynamically updated based on network conditions and measurements, ensuring that the gNodeB has an accurate and current view of potential target cells for seamless user mobility.
10 [0048] As used herein, the gNodeB neighbour table refers to a data structure maintained
by a gNodeB that contains information about its neighbouring gNodeBs within the 5G network. The gNodeB neighbour table includes details such as the identifiers of neighbouring cells, their respective signal quality metrics, and the status of Xn connections.
15 [0049] As used herein, the gNodeB CU application refers to the centralized unit
component of a gNodeB in 5G network architecture, responsible for handling higher-layer protocols for both the control plane (CP) and user plane (UP). The CU application separates the protocols from the distributed unit (DU), which manages lower-layer protocols and radio resource management. The separation enables more flexible deployment and efficient
20 resource allocation.
[0050] As used herein, the gNodeB SCTP module refers to the component within a
gNodeB for the Stream Control Transmission Protocol (SCTP) functions. The gNodeB
SCTP module handles the establishment, maintenance, and termination of SCTP
25 associations between gNodeBs, providing transport for signalling messages over the Xn
interface.
[0051] As used herein, the Xn setup requests refers to the procedure initiated by a gNodeB
to establish Xn interface connectivity with a neighbouring gNodeB. The Xn setup
30 comprises transmission of an Xn-Setup-Request message from the source gNodeB to the
target gNodeB. The target gNodeB responds with an Xn-Setup-Response message, indicating the acceptance or rejection of the setup request. Successful completion of this
12

exchange ensures that the Xn interface is established, enabling efficient handovers and communication between neighbouring gNodeBs.
[0052] As used herein, the Xn status refers to the operational condition of the Xn interface
5 between two gNodeBs. The Xn status indicates whether the Xn connection is currently
"Up" or "Down," where "Up" signifies an active and functional connection capable of handling control and user plane data, and "Down" signifies a non-operational state where the connection is unable to perform these functions.
10 [0053] As used herein, the Xn-AP connection refers to the interface protocol used for
communication between neighbouring gNodeBs. The Xn-Application Protocol (Xn-AP) operates over the Stream Control Transmission Protocol (SCTP) to support functions such as handovers, load management, and radio resource management. The Xn-AP connection ensures robust and reliable connectivity between gNodeBs, facilitating seamless user
15 transitions and efficient network performance.
[0054] As used herein, the Xn-AP refers to the Xn Application Protocol, which is a part
of the control plane in the Xn interface. Xn-AP is responsible for the signalling procedures
required for the coordination and management of handovers between neighbouring
20 gNodeBs, as well as other functions such as load management and mobility management.
[0055] As used herein, the Xn setup request refers to a procedure for initiating the
establishment of an Xn interface between two gNodeBs. The Xn setup request is sent by a
source gNodeB to a target gNodeB to establish the necessary signalling connection for
25 managing handovers and other inter-node communication. The Xn setup request includes
various parameters and identifiers that facilitate the configuration of the Xn interface, enabling the exchange of control messages and user plane data to ensure seamless connectivity and efficient network operations.
30 [0056] As discussed in the background section, In the existing 5G Radio Network
architecture, the Xn interface plays a crucial role in facilitating seamless handovers between neighbouring gNodeBs. However, the current mechanisms for managing this interface have been found to be inadequate in certain scenarios. Specifically, the reliance
13

on the Stream Control Transmission Protocol (SCTP) for establishing and maintaining the
transport layer of the Xn interface has limitations. One of the primary issues observed is
that the Xn connections between a gNodeB and some of its neighbouring gNodeBs can
become "inoperative" due to various reasons, such as the reboot of a peer node. In the
5 current setup, there is no automatic recovery mechanism to re-establish these downed Xn
connections. This leads to a situation where handovers have to be routed through the core
network nodes, resulting in increased latency and a potential degradation in the user
experience. Moreover, the SCTP layer typically attempts to establish connections with
neighbouring gNodeBs only during the initial boot-up process or when a new neighbour is
10 detected. If the initial attempts fail, there is no periodic retry mechanism in place to re-
attempt the establishment of the Xn connections. This can be problematic in dynamic network environments where gNodeBs may be rebooted frequently, for example, during software upgrades.
15 [0057] The present disclosure aims to overcome the above-mentioned and other existing
problems in this field of technology by introducing a novel method and system for managing the Xn interface in 5G Radio Network architecture. The core innovation lies in the implementation of a periodic monitoring and re-initiation mechanism for the Xn connections between neighbouring gNodeBs. This is achieved through a monitoring unit
20 that continuously checks the status of the Xn connections and a processing unit that
schedules Xn setup requests based on a predefined time interval. This ensures that attempts to re-establish the Xn connection are made periodically, addressing the limitations of the SCTP layer's one-time connection attempt during the initial boot-up process or when a new neighbour is detected. The transceiver unit then transmits the scheduled Xn setup request
25 to the target gNodeB, and upon receiving a response, the connection status is updated
accordingly. This approach enhances the robustness of the Xn interface, improves handover performance, and reduces the reliance on the core network nodes for handover execution, leading to a more efficient and reliable network with improved user experiences during mobility cases.
30
[0058] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.
14

[0059] Referring to FIG. 1, an exemplary block diagram of a system [100] for restoring
an Xn connection with neighbouring gNodeBs by initiating Xn setup periodically is shown,
in accordance with the exemplary implementations of the present disclosure. The system
[100] comprises a monitoring unit [102], a processing unit [104], a transceiver unit [106],
5 and a storage unit [108]. Also, all of the components/ units of the system [100] are assumed
to be connected to each other unless otherwise indicated below. Also, in FIG. 1 only a few
units are shown, however, the system [100] may comprise multiple such units or the system
[100] may comprise any such numbers of said units, as required to implement the features
of the present disclosure. In an implementation, the system [100] may reside in a server, or
10 a network entity.
[0060] The system [100] includes a monitoring unit [102] configured to monitor the Xn connection status between a source gNodeB and at least one corresponding neighbouring target gNodeB. The monitoring unit [102] facilitates in ensuring the seamless handover of
15 5G phones (UEs) from one gNodeB to another by continuously tracking the health and
status of the Xn connections. The Xn interface is essential for carrying both control signalling for handovers and user plane data while the UE is transitioning from the serving gNodeB to the target gNodeB. By monitoring the Xn connection status, the monitoring unit [102] can detect any disruptions or weakening in the Xn connections, which are vital for
20 maintaining low latency and efficient data flow in the 5G Radio Network architecture.
[0061] The system [100] includes a processing unit [104] communicatively coupled to the monitoring unit [102]. The processing unit [104] is configured to schedule an Xn setup request based on a predefined time interval for initiating periodic Xn setup requests upon
25 detection of a lost or weakened Xn connection with the target gNodeB. For example, the
source gNodeB continuously monitors the status of its Xn connections with neighbouring gNodeBs using predefined thresholds for signal quality and connection stability metrics. If the signal strength between the source gNodeB and a neighbouring gNodeB drops below a predefined threshold or the connection exhibits increased packet loss or latency. In that
30 case, the system detects this as a weakened Xn connection. Similarly, if the connection
stability metrics, such as the frequency of dropped connections, exceed predefined limit, the system recognizes the connection as lost. Upon detecting these conditions, the source gNodeB schedules an Xn setup request to restore the connection.
15

[0062] The scheduling facilitates in ensuring timely attempts to restore the Xn connection,
thereby maintaining the robustness of the 5G Radio Network architecture. Additionally,
the processing unit [104] is further configured to modify the predefined time interval based
5 on at least one of a network condition or user traffic. For example, in a 5G network, the
network experiences high user traffic during peak hours, resulting in increased handovers
and potential Xn link failures. In response, the processing unit [104] detects the elevated
traffic and reduces the time interval between successive Xn setup requests to ensure timely
restoration of lost or weakened connections. Conversely, during periods of low user
10 activity, the processing unit [104] may extend the time interval, optimizing resource
utilization and minimizing unnecessary signalling overhead.
[0063] This adaptability allows the system [100] to respond dynamically to varying network conditions, ensuring optimal performance and minimizing disruption to user
15 experiences. Furthermore, the processing unit [104] is also configured to identify, via the
target gNodeB, at least one valid source cell based on determined source cell information in the Xn setup request. The identification facilitates in increasing the handover success rate by preventing the addition of invalid source cells in the Neighbour Relation Table (NRT) list, thus enhancing the overall efficiency of the handover process in the 5G network.
20
[0064] The system [100] includes the transceiver unit [106] communicatively coupled to the processing unit [104]. The transceiver unit [106] is configured to transmit the scheduled Xn setup request from the source gNodeB to the target gNodeB for initiating the restoration process of the Xn connection by sending the necessary setup request to the target gNodeB,
25 allowing for the re-establishment of the direct interface essential for handovers and data
transmission in the 5G network. Additionally, the transceiver unit [106] is also configured to receive a response to the Xn setup request at the source gNodeB. The response indicates the restored connection status with the target gNodeB, providing feedback to the system [100] about the success of the restoration attempt.
30
[0065] In an embodiment, the Xn setup request comprises an identifier for each of the served cells of the source gNodeB to allow the target gNodeB to selectively update the NRT list based on relevancy and proximity. The Xn setup request comprises an identifier
16

for each of the served cells of the source gNodeB, enabling the target gNodeB to selectively
update the Neighbour Relation Table (NRT) based on relevancy and proximity. When the
source gNodeB initiates the Xn setup request, it includes detailed identifiers for all the cells
it serves. The target gNodeB uses this information to determine which neighbouring cells
5 are most relevant and in closest proximity, allowing it to make informed updates to its
NRT.
[0066] For example, a source gNodeB in a 5G network experiences a reboot, causing the Xn connections with its neighbouring gNodeBs to go down. Following the reboot, the
10 SCTP module attempts to re-establish these connections but fails for some neighbors. The
gNB then periodically initiates Xn setup requests for these neighbour gNBs whose connections are still down. Each setup request includes identifiers for the served cells of the source gNodeB. The neighbouring target gNodeBs use these identifiers to update their Neighbour Relation Tables (NRT) by including only those source cells that are relevant
15 and in close proximity (such as within a certain range such as 100 meter).
[0067] The system [100] includes the storage unit [108] communicatively coupled to the transceiver unit [106]. The storage unit [108] is configured to store the Xn setup request and the response to the Xn setup to facilitate restoration of Xn connection with
20 neighbouring gNodeBs for one or more upcoming Xn setup requests. The storage unit [108]
maintains data related to Xn setup requests and responses. By maintaining a record of these interactions, the system [100] can utilize this information for future Xn connection restoration attempts, thereby enhancing the efficiency and reliability of the recovery process.
25
[0068] Referring to FIG. 2, an exemplary block diagram of a system architecture [200] for restoring an Xn connection with neighbouring gNodeBs by initiating Xn setup periodically is shown, in accordance with the exemplary implementations of the present disclosure. The system architecture [200] comprises a source gNodeB [202], and one or more neighbour
30 gNodeB [204]. The source gNodeB [202] may include gNode Neighbour Table [202A],
gNode centralized unit (CU) application [202B], and gNode Stream Control Transmission Protocol (SCTP) Module [202C].
17

[0069] The one or more neighbour gNodeB [204] comprises Neighbour gNode CU
application [204A], and Neighbour gNode SCTP Module [204B]. Also, all of the
components/ units of the system architecture [200] are assumed to be connected to each
other unless otherwise indicated below. Also, in FIG. 2 only a few units are shown,
5 however, the system architecture [200] may comprise multiple such units or the system
architecture [200] may comprise any such numbers of said units, as required to implement the features of the present disclosure. In an implementation, the system architecture [200] may reside in a server, or a network entity.
10 [0070] The source gNodeB [202] may include the gNodeB Neighbour Table [202A]
containing a list of neighbouring gNodeBs with which the source gNodeB [202A] can potentially establish Xn connections. The source gNodeB [202] may further include gNodeB CU application [202B] that orchestrates the overall control plane functions of the source gNodeB [202A], including initiating recovery mechanisms for Xn connections that
15 are marked as "Down" (such as inoperative) in the gNodeB Neighbour Table [202A]. The
gNodeB SCTP Module [202C] handles the establishment and maintenance of the SCTP associations [208] necessary for Xn connection communication, thereby ensuring reliable message delivery over IP networks.
20 [0071] The one or more neighbouring gNodeB [204] includes the Neighbour gNode CU
application [204A] and a Neighbour gNode SCTP Module [204B]. These counterparts interact with the corresponding modules of the source gNodeB [202] to maintain the Xn connections. The Neighbouring gNode CU application [204A] responds to Xn-Setup-Requests sent by the source gNodeB's CU application [202B]. Meanwhile, the Neighbour
25 gNode SCTP Module [204B] ensures that SCTP associations [208] are appropriately
established and maintained with the source gNodeB's SCTP Module [202C].
[0072] It would be appreciated by the person skilled in the art that the system's innovative
approach involves the gNode CU application [202B] periodically sending Xn-Setup-
30 Requests to the one or more neighbouring gNodeB [204] based on a pre-configured timer,
especially when the Xn Status is "Down." Upon successful establishment of the Xn
connection, marked by the receipt of Xn-Setup-Response, the status is updated to "Up" in
the gNode Neighbour Table [202A], ensuring the Xn connection’s viability for handover
18

operations. If a neighbour gNodeB [204] fails to respond, indicating a problem with the
SCTP association [208] or other issues, the Xn-Retry mechanism within the gNode CU
application [202B] will re-initiate the Xn-Setup-Request after the set time period has
elapsed, maintaining efforts to restore the connection until all connections are confirmed
5 as "Up."
[0073] In an implementation, the system architecture [200] is configured to initiate new Xn connection. Now, the source gNodeB CU application [202B] may periodically initiate the Xn connection establishment as per a pre-configured timer for one or more
10 neighbouring gNodeB [204] when Xn Status may be “Down”. Now, one or more neighbour
gNodeB [204] whose SCTP association [208] may be successful are likely to respond to the Xn-Setup-Request with Xn-Setup-Response. Once Xn-Setup-Response may be received from one or more neighbour gNodeB [204], the “Xn Status” for that neighbour gNodeB [204] may be updated in the internal database as “Up”.
15
[0074] The Xn-AP connection [206] refers to the Xn Application Protocol connection, which is a part of the 5G Radio Network architecture. It represents the application layer protocol used for communication between different gNodeBs (next-generation NodeBs). The Xn-AP connection is responsible for the management of signalling for procedures such
20 as handovers and dual connectivity of User Equipment (UE) across different gNodeBs.
This protocol operates over the SCTP (Stream Control Transmission Protocol) transport layer, ensuring reliable message delivery. The Xn-AP connection [206] facilitates in inter-gNodeB signalling, facilitating the transfer of control plane information necessary for the coordination and execution of network functions like handover. It is what allows a UE to
25 seamlessly move from the coverage area of one gNodeB to another without losing
connection or experiencing degraded service.
[0075] An SCTP Association [208] refers to a relationship established between endpoints
in a network to facilitate communication using the Stream Control Transmission Protocol
30 (SCTP). The SCTP association [208] is the connection set up between two gNodeBs or
between a gNodeB and another network entity that requires reliable transport of signalling messages. SCTP is known for providing reliable, message-oriented communication with congestion control. Unlike TCP, SCTP allows for multiple streams within a single
19

connection (association), thereby preventing a single point of message failure from
affecting the entire communication channel. It also supports multi-homing, which enables
an endpoint to be represented by multiple IP addresses, providing redundancy and failover
capabilities in the event of a path failure. In the case of Xn-AP communications, an SCTP
5 association [208] would be used to reliably transmit the application layer's signalling
messages, such as Xn-Setup-Request and Xn-Setup-Response, between gNodeBs to manage UE handovers and other inter-gNodeB procedures.
[0076] A person skilled in the art would appreciate that the above listed features are only
10 exemplary and do not restrict the present disclosure in any possible manner. In an
exemplary implementation, the features listed above may be considered to be in the order of their importance.
[0077] Referring to FIG. 3 an exemplary flow chart, for restoring an Xn connection with
15 neighbouring gNodeBs by initiating Xn setup periodically, in accordance with exemplary
embodiments of the present invention is shown.
[0078] At step S1, the process begins when the gNodeB is fully operational and the Xn
Status is available for each of the "T" neighbouring gNodeBs. It involves checking whether
20 the Xn connection with each of the neighbouring gNBs are currently "Up" or "Down."
[0079] At step S2, the system checks whether the timer, which is set to a period of "P
minutes," has expired. The timer determines when the next evaluation and potential re¬
initiation of Xn setup requests should occur. For example, if the P is 3 minutes, then the
25 system will wait for 3 seconds before checking status of the neighbour.
[0080] At step S3, for each neighbour in the list, the system evaluates the current Xn-Status. If the Xn-Status for a neighbour is "Down," it means the Xn connection with that neighbour is lost or not established. 30
[0081] At step S4, if the Xn-Status is found to be "Down" for a neighbour, the system initiates an Xn-Setup-Request. The Xn-Setup-Request is sent from the source gNodeB to
20

the neighbouring gNodeB whose Xn connection is down, in an attempt to re-establish the connection.
[0082] At step S5, the system waits to receive an Xn-Setup-Response from the target
5 gNodeB. This response indicates whether the Xn setup was successful or not.
[0083] At step S6, if the Xn-Setup-Response is received successfully from the neighbouring gNodeB, the system updates the Xn Status for that neighbour to "Up" in the database indicating that the Xn connection has been successfully re-established. 10
[0084] At step S7, if the Xn-Setup-Response is not received, the system maintains the Xn Status for that neighbour gNB as "Down." indicating that the attempt to re-establish the Xn connection was unsuccessful.
15 [0085] At step S8, the system checks if all neighbour gNBs in the list have been evaluated
for their Xn Status.
[0086] At step S9, if all neighbour gNBs have been evaluated, the system restarts the Xn
Retry Timer with the periodicity of "P minutes" The retry timer controls the interval at
20 which the system will reattempt to establish Xn connections with neighbour gNBs that are
still down.
[0087] At step S10, if the timer has not expired yet, the system maintains the Xn Status
for connections that are "Up" and takes no further action for those Xn links until the next
25 timer expiration.
[0088] Referring to FIG. 4 an exemplary method flow diagram [400], for restoring an Xn
connection with neighbouring gNodeBs by initiating Xn setup periodically, in accordance
with exemplary embodiments of the present disclosure is shown. In an implementation, the
30 method [400] is performed by the system [100], or the system architecture [200]. As shown
in FIG. 4, the method [400] starts at step [402].
21

[0089] At step [404], the method [400] encompasses monitoring, by a monitoring unit
[102], the Xn connection status between a source gNodeB and at least one corresponding
neighbouring target gNodeB. The monitoring facilitates in ensuring the seamless handover
of 5G phones (UEs) from one gNodeB to another by continuously tracking the health and
5 status of the Xn connections. The Xn interface is essential for carrying both control
signalling for handovers and user plane data while the UE is transitioning from the serving gNodeB to the target gNodeB. By monitoring the Xn connection status, the monitoring unit [102] can detect any disruptions or weakening in the Xn connections, which are vital for maintaining low latency and efficient data flow in the 5G Radio Network architecture.
10
[0090] Now, at step [406], the method [400] comprises upon detection of a lost or weakened Xn connection with the target gNodeB, scheduling, by a processing unit [104], an Xn setup request based on a predefined time interval for initiating periodic Xn setup requests. The scheduling facilitates in ensuring timely attempts to restore the Xn
15 connection, thereby maintaining the robustness of the 5G Radio Network architecture.
Additionally, the processing unit [104] is further configured to modify the predefined time interval based on at least one of a network condition or user traffic. This adaptability allows the system [100] to respond dynamically to varying network conditions, ensuring optimal performance and minimizing disruption to user experiences. Furthermore, the processing
20 unit [104] is also configured to identify, via the target gNodeB, at least one valid source
cell based on determined source cell information in the Xn setup request. The identification facilitates in increasing the handover success rate by preventing the addition of invalid source cells in the Neighbour Relation Table (NRT) list, thus enhancing the overall efficiency of the handover process in the 5G network. As used herein, the invalid source
25 cells refer to cells that are incorrectly included in the NRT due to outdated or erroneous
configuration data, leading to inefficient or failed handovers. The invalid source cells can result from issues such as changes in cell configurations, removal of cells from service, or inaccuracies in the cell identity information. The presence of invalid source cells in the NRT can degrade network performance by preventing successful handovers and increasing
30 signalling overhead, thereby adversely affecting the overall user experience.
[0091] Next, at step [408], the method [400] encompasses transmitting, by a transceiver unit [106], the scheduled Xn setup request from the source gNodeB to the target gNodeB.
22

The scheduled Xn setup request from the source gNodeB to the target gNodeB allows for the re-establishment of the direct interface essential for handovers and data transmission in the 5G network.
5 [0092] Further, at step [410], the method [400] comprising receiving, by the transceiver
unit [106], a response to the Xn setup request at the source gNodeB, wherein the response
indicates the restored connection status with the target gNodeB. Additionally, the
transceiver unit [106] is also configured to receive a response to the Xn setup request at the
source gNodeB. The response indicates the restored connection status with the target
10 gNodeB, providing feedback to the system [100] about the success of the restoration
attempt.
[0093] The method terminates at step [412].
15 [0094] As is evident from the above, the present disclosure provides a technically
advanced solution for re-initiating Xn connection creation at Application Layer (Xn-AP)
that may improve the robustness of Xn interface and handover performance. Further, the
present disclosure may provide a solution for an additional recovery mechanism in order
to restore the Xn connection by periodically monitoring of Xn Status and triggering of Xn-
20 Setup-Request for those neighbours where Xn Status is down.
[0095] FIG. 5 illustrates an exemplary block diagram of a computing device [500] (also referred to herein as a computer system [500]) upon which an embodiment of the present disclosure may be implemented. In an implementation, the computing device implements
25 the method for restoring connection between peer network nodes. In another
implementation, the computing device itself implements the method for restoring connection between peer network nodes by using one or more units configured within the computing device, wherein said one or more units are capable of implementing the features as disclosed in the present disclosure.
30
[0096] The computing device [500] may include a bus [502] or other communication mechanism for communicating information, and a processor [504] coupled with the bus [502] for processing information. The processor [504] may be, for example, a general-
23

purpose microprocessor. The computing device [500] may also include a main memory
[506], such as a random-access memory (RAM), or other dynamic storage device, coupled
to the bus [502] for storing information and instructions to be executed by the processor
[504]. The main memory [506] also may be used for storing temporary variables or other
5 intermediate information during execution of the instructions to be executed by the
processor [504]. Such instructions, when stored in non-transitory storage media accessible
to the processor [504], render the computing device [500] into a special-purpose machine
that is customized to perform the operations specified in the instructions. The computing
device [500] further includes a read only memory (ROM) [508] or other static storage
10 device coupled to the bus [502] for storing static information and instructions for the
processor [504].
[0097] A storage device [510], such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to the bus [502] for storing information and instructions. The
15 computing device [500] may be coupled via the bus [502] to a display [512], such as a
cathode ray tube (CRT), for displaying information to a computer user. An input device [514], including alphanumeric and other keys, may be coupled to the bus [502] for communicating information and command selections to the processor [504]. Another type of user input device may be a cursor controller [516], such as a mouse, a trackball, or cursor
20 direction keys, for communicating direction information and command selections to the
processor [504], and for controlling cursor movement on the display [512]. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow the device to specify positions in a plane.
25 [0098] The computing device [500] may implement the techniques described herein using
customized hard-wired logic, one or more Application-Specific Integrated Circuits (ASICs) or Field Programmable Gate Arrays (FPGAs), firmware and/or program logic which in combination with the computing device [500] causes or programs the computing device [500] to be a special-purpose machine. According to one embodiment, the
30 techniques herein are performed by the computing device [500] in response to the processor
[504] executing one or more sequences of one or more instructions contained in the main memory [506]. Such instructions may be read into the main memory [506] from another storage medium, such as the storage device [510]. Execution of the sequences of
24

instructions contained in the main memory [506] causes the processor [504] to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.
5 [0099] The computing device [500] also may include a communication interface [518]
coupled to the bus [502]. The communication interface [518] provides a two-way data communication coupling to a network link [520] that is connected to a local network [522]. For example, the communication interface [518] may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data
10 communication connection to a corresponding type of telephone line. As another example,
the communication interface [518] may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, the communication interface [518] sends and receives electrical, electromagnetic or optical signals that carry digital data streams
15 representing various types of information.
[0100] The computing device [500] can send messages and receive data, including
program code, through the network(s), the network link [520] and the communication
interface 518. In the Internet example, a server [530] might transmit a requested code for
20 an application program through the Internet [528], the Internet Service Provider (ISP)
[526], the Host [524] the local network [522] and the communication interface [518]. The received code may be executed by the processor [504] as it is received, and/or stored in the storage device [510], or other non-volatile storage for later execution.
25 [0101] According to an aspect, the present disclosure may relate to a non-transitory
computer-readable storage medium storing instruction for restoring an Xn connection with neighbouring gNodeBs, the storage medium comprising executable code which, when executed by one or more units of a system, causes: a monitoring unit [102] to monitor the Xn connection status between a source gNodeB and at least one corresponding
30 neighbouring target gNodeB; a processing unit [104] to schedule an Xn setup request based
on a predefined time interval for initiating periodic Xn setup requests upon detection of a lost or weakened Xn connection with the target gNodeB; a transceiver unit [106] to transmit the scheduled Xn setup request from the source gNodeB to the target gNodeB; and the
25

transceiver unit [106] to receive a response to the Xn setup request at the source gNodeB, wherein the response indicates the restored connection status with the target gNodeB.
[0102] The present disclosure introduces a novel method and system for managing the Xn
5 interface in 5G Radio Network architecture. The core innovation lies in the implementation
of a periodic monitoring and re-initiation mechanism for the Xn connections between neighbouring gNodeBs. This is achieved through the monitoring unit [102] that continuously checks the status of the Xn connections and a processing unit [104] that schedules Xn setup requests based on a predefined time interval. This ensures that attempts
10 to re-establish the Xn connection are made periodically, addressing the limitations of the
SCTP layer's one-time connection attempt during the initial boot-up process or when a new neighbour is detected. The transceiver unit [106] then transmits the scheduled Xn setup request to the target gNodeB, and upon receiving a response, the connection status is updated accordingly. This approach enhances the robustness of the Xn interface, improves
15 handover performance, and reduces the reliance on the core network nodes for handover
execution, leading to a more efficient and reliable network with improved user experiences during mobility cases.
[0103] Further, in accordance with the present disclosure, it is to be acknowledged that
20 the functionality described for the various components/units can be implemented
interchangeably. While specific embodiments may disclose a particular functionality of
these units for clarity, it is recognized that various configurations and combinations thereof
are within the scope of the disclosure. The functionality of specific units, as disclosed in
the disclosure, should not be construed as limiting the scope of the present disclosure.
25 Consequently, alternative arrangements and substitutions of units, provided they achieve
the intended functionality described herein, are considered to be encompassed within the scope of the present disclosure.
[0104] While considerable emphasis has been placed herein on the disclosed
30 embodiments, it will be appreciated that many embodiments can be made and that many
changes can be made to the embodiments without departing from the principles of the
present disclosure. These and other changes in the embodiments of the present disclosure
26

will be apparent to those skilled in the art, whereby it is to be understood that the foregoing descriptive matter to be implemented is illustrative and non-limiting.
27

I/We Claim:
1. A method [400] for restoring an Xn connection with neighbouring gNodeBs, the
method comprising:
monitoring, by a monitoring unit [102], the Xn connection status between a
5 source gNodeB and at least one corresponding neighbouring target gNodeB;
upon detection of at least one of a lost or weakened Xn connection with the target gNodeB, scheduling, by a processing unit [104], an Xn setup request based on a predefined time interval for initiating periodic Xn setup requests;
transmitting, by a transceiver unit [106], the scheduled Xn setup request from
10 the source gNodeB to the target gNodeB; and
receiving, by the transceiver unit [106], a response to the Xn setup request at the source gNodeB, wherein the response indicates a restored connection status with the target gNodeB.
2. The method as claimed in claim 1, wherein the method comprises modifying, by the
15 processing unit [104], the predefined time interval based on at least one of a network
condition or a user traffic.
3. The method as claimed in claim 1, wherein the predefined time interval is
dynamically determined based on historical Xn connection data between the source
gNodeB and a set of neighbouring gNodeBs.
20 4. The method as claimed in claim 1, wherein the method comprises storing, by a
storage unit [108], the Xn setup request and the response to the Xn setup to facilitate the restoration of Xn connection with neighbouring gNodeBs for the upcoming Xn setup requests.
5. The method as claimed in claim 1, wherein the lost or weakened Xn connection is
25 detected based on at least one of a set of predefined thresholds of signal quality or
connection stability metrics.
6. The method as claimed in claim 1 further comprises identifying, by the processing
unit [104] via the target gNodeB, at least one valid source cell based on a determined
source cell information in the Xn setup request.
30 7. The method as claimed in claim 6, wherein the source cell information in the Xn
setup request facilitates an increase in handover success rate by preventing addition of invalid source cells in an NRT list.
28

8. The method as claimed in claim 7, wherein the Xn setup request comprises an
identifier for each of served cells of the source gNodeB to allow the target gNodeB
to selectively update the NRT list based on relevancy and proximity.
9. A system [100] for restoring an Xn connection with neighbouring gNodeBs, the
5 system comprises:
a monitoring unit [102], configured to monitor the Xn connection status between a source gNodeB and at least one corresponding neighbouring target gNodeB;
a processing unit [104], configured to schedule an Xn setup request
10 based on a predefined time interval for initiating periodic Xn setup requests
upon detection of at least one of a lost or weakened Xn connection with the target gNodeB;
a transceiver unit [106], configured to transmit the scheduled Xn setup
request from the source gNodeB to the target gNodeB; and
15 the transceiver unit [106], configured to receive a response to the Xn
setup request at the source gNodeB, wherein the response indicates a restored connection status with the target gNodeB.
10. The system as claimed in claim 9, wherein the processing unit [104] is further
configured to modify the predefined time interval based on at least one of a network
20 condition or a user traffic.
11. The system as claimed in claim 9, wherein the predefined time interval is
dynamically determined based on historical Xn connection data between the source
gNodeB and a set of neighbouring gNodeBs.
12. The system as claimed in claim 9 further comprises a storage unit [108], configured
25 to store the Xn setup request and the response to the Xn setup to facilitate restoration
of Xn connection with neighbouring gNodeBs for one or more upcoming Xn setup requests.
13. The system as claimed in claim 9, wherein the lost or weakened Xn connection is
detected based on at least one of a set of predefined thresholds of signal quality or
30 connection stability metrics.
14. The system as claimed in claim 9, wherein the processing unit [104] is further
configured to identify, via the target gNodeB, at least one valid source cell based on
a determined source cell information in the Xn setup request.

15. The system as claimed in claim 14, wherein the source cell information in the Xn
setup request facilitates an increase in handover success rate by preventing addition
of invalid source cells in an NRT list.
16. The system as claimed in claim 15, wherein the Xn setup request comprises an
identifier for each of served cells of the source gNodeB to allow the target gNodeB
to selectively update the NRT list based on relevancy and proximity.