Service registration method, related device, medium and program product

Abstract

The invention provides a service registration method, related equipment, a medium and a program product, relates to the technical field of communication, and aims to solve the problem of low flexibility of network deployment. The method comprises the steps that under the condition that a first timer is overtime, first registration request information is sent to a first service of network side equipment, and the first registration request information is used for requesting the first service to register a first Xn service; receiving first registration reply information sent by the first service, wherein the first registration reply information is used for indicating the first service to complete the first Xn service registration; under the condition that the first registration reply information is received and a second timer is overtime, second registration request information is sent to a control platform, and the second registration request information comprises configuration information of the first Xn service; and receiving second registration reply information sent by the control platform, wherein the second registration reply information is used for indicating the control platform to complete the first Xn service registration. The flexibility of network deployment can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, and in particular to a service registration method, related equipment, a medium and a program product. BACKGROUND

[0002] In a traditional 5G Radio Access Network (RAN) architecture, an Xn interface is an open interface between NG-RAN nodes. The Xn interface is a point-to-point logical interface, and does not require a physical direct connection. The Xn interface supports functions including signaling information interaction between NG-RAN nodes, data forwarding in handover, mobility between NG-RAN nodes, and dual connection operation between NG-RAN nodes. However, because the traditional Xn interface is implemented in a static and fixed point-to-point logical interface mode, the processing capability of the Xn interface is strongly bound to the hardware of the network side device, thereby resulting in low flexibility of network deployment. SUMMARY

[0003] Embodiments of the present application provide a service registration method, related equipment, a medium and a program product to solve the problem of low flexibility of related network deployment.

[0004] To solve the above technical problems, the present application is implemented as follows: In a first aspect, the embodiments of the present application provide a service registration method applied to a network side device, and the method comprises the following steps: In a case where a first timer expires, a first registration request information is sent to a first service of the network side device, and the first registration request information is used to request the first service to register a first Xn service; First registration reply information sent by the first service is received, and the first registration reply information is used to indicate that the first service completes the first Xn service registration; In a case where the first registration reply information is received and a second timer expires, second registration request information is sent to a control platform, and the second registration request information comprises configuration information of the first Xn service; Second registration reply information sent by the control platform is received, and the second registration reply information is used to indicate that the control platform completes the first Xn service registration.

[0005] In a second aspect, the embodiments of the present application provide a network side device, which comprises: A first sending module is configured to, in a case where a first timer expires, send first registration request information to a first service of the network side device, and the first registration request information is used to request the first service to register a first Xn service; The first receiving module is configured to receive first registration reply information sent by the first service, the first registration reply information being used to indicate that the first service completes the first Xn service registration. The second sending module is configured to send second registration request information to a control platform in a case where the first registration reply information is received and a second timer is timed out, the second registration request information including configuration information of the first Xn service. The second receiving module is configured to receive second registration reply information sent by the control platform, the second registration reply information being used to indicate that the control platform completes the first Xn service registration.

[0006] In a third aspect, an embodiment of the present application provides a network side device, including a transceiver and a processor, the transceiver being configured to: send first registration request information to a first service of the network side device in a case where a first timer is timed out, the first registration request information being used to request the first service to register a first Xn service; receive first registration reply information sent by the first service, the first registration reply information being used to indicate that the first service completes the first Xn service registration; send second registration request information to a control platform in a case where the first registration reply information is received and a second timer is timed out, the second registration request information including configuration information of the first Xn service; receive second registration reply information sent by the control platform, the second registration reply information being used to indicate that the control platform completes the first Xn service registration.

[0007] In a fourth aspect, an embodiment of the present application provides an electronic device, including a processor, a memory, and a program stored in the memory and executable in the processor, the program being executed by the processor to implement the steps of the service registration method in the first aspect.

[0008] In a fifth aspect, an embodiment of the present application provides a computer readable storage medium, the computer readable storage medium storing a computer program, the computer program being executed by a processor to implement the steps of the service registration method in the first aspect.

[0009] In a sixth aspect, an embodiment of the present application provides a computer program product, including computer instructions, the computer instructions being executed by a processor to implement the steps of the service registration method in the first aspect.

[0010] In the embodiment of the present application, in the case that the first timer expires, a first registration request information is sent to a first service of the network side device, the first registration request information is used to request the first service to register a first Xn service; a first registration reply information sent by the first service is received, the first registration reply information is used to indicate that the first service completes the first Xn service registration; in the case that the first registration reply information is received and the second timer expires, a second registration request information is sent to a control platform, the second registration request information includes configuration information of the first Xn service; a second registration reply information sent by the control platform is received, the second registration reply information is used to indicate that the control platform completes the first Xn service registration. In this way, the first Xn service is added to the network as an independent micro service through the registration process of the first Xn service, so that the Xn service can be created independently, the Xn service is decoupled from the hardware, and thus the flexibility of network deployment can be improved. BRIEF DESCRIPTION OF DRAWINGS

[0011] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the description of the embodiments of the present application will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0012] Figure 1 is a schematic diagram of a service-based RAN CUCP architecture provided by the embodiments of the present application; Figure 2 is a flowchart of a service registration method provided by the embodiments of the present application; Figure 3 is an interaction schematic diagram of an Xn service registration process provided by the embodiments of the present application; Figure 4 is an interaction schematic diagram of an Xn service connection establishment process provided by the embodiments of the present application; Figure 5 is an interaction schematic diagram of an Xn service release process provided by the embodiments of the present application; Figure 6 is one of the structural schematic diagrams of a network side device provided by the embodiments of the present application; Figure 7 is another structural schematic diagram of a network side device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0013] With reference to the drawings, the technical solutions in the embodiments of the present application will be described clearly and completely. Obviously, the described embodiments are only some of the embodiments of the present application, but not all of them. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of the present application.

[0014] For the convenience of understanding, some contents related to the embodiments of the present application are described as follows: The 5G core network (5th Generation Core Network, 5GC) revolutionarily takes the service-oriented architecture as the network infrastructure, realizes independent expansion, independent evolution and on-demand deployment of network functions, and continuously promotes the enhancement and optimization of service-oriented functions and frameworks. Based on 5G, 6G will carry out full-service design around the three dimensions of “field expansion, mechanism deepening and element expansion”. In terms of field expansion, the service-oriented mechanism will be expanded to the radio access network (Radio Access Network, RAN), and will be developed in stages from interface service to function service. In terms of mechanism deepening, further exploration of service decoupling and service call efficiency improvement will be carried out on the basis of the existing 5G service. In terms of element expansion, further introduction of artificial intelligence (Artificial Intelligence, AI), computing and data elements will promote the deep integration of data, operations, information and communication technology (Data, Operations, Information and Communication Technology, DOICT).

[0015] In order to meet the requirements of diversified businesses for the agility, flexibility and scalability of the network, the network is inevitably transformed to virtualization and cloud native, and cloud native RAN has been widely favored by global operators. Cloud native RAN helps operators build high-cost-effective, high-operation-efficiency, green and fully-automated wireless networks, and provides innovative services for customers.

[0016] Similar to other cloud native architectures, containerization, microservice architecture and Kubernetes orchestration are the core features of cloud native RAN. Containerization and Kubernetes orchestration are more implementation methods, and the microservice architecture is reflected in the reconstruction of functions. Based on the microservice architecture, the RAN is built as a collection of loosely coupled services. Each service performs a specific function and can be developed, deployed and expanded independently, and can be developed, deployed and expanded on any infrastructure and container platform. However, the microservice architecture is not the only architecture pattern that can be adopted in the RAN transformation process, so the RAN that is functionally reconstructed based on the cloud native design principles can be called service-oriented RAN.

[0017] The research of service-based RAN conforms to the development trend of next-generation communication technology, and will be iteratively optimized with the evolution of cloud-native technology ecosystem. However, service-based RAN is not only technology-driven, but also values the improvement of network adaptability to the whole industry and all applications, especially the needs of industry application function customization, cost control, agile deployment, on-demand expansion, and rapid iteration. Overall, service-based RAN mainly includes the following four technical features: Functional decoupling: Only by building high-cohesion and low-coupling services can we maximize the reuse of functions and take advantage of cloud-native platforms, so functional decoupling is a necessary step to achieve service-based RAN; On-demand combination: The core value of service-based RAN. By combining necessary function services on demand, it meets the needs of customization, cost control, flexible adaptation, and agile response of operators and customers; Capability exposure: Basic capabilities provided by service-based RAN, service-based RAN is one of the important means to achieve efficient capability exposure.

[0018] Service interface: Access the services provided by specific network functions through Application Programming Interface (API).

[0019] Overall, the evolution of service-based RAN can be divided into two stages: interface service and function service. In the interface service stage, it can be divided into two options: N2 interface partial service (option 1) and N2 interface full service (option 2). Among them, option 1 mainly faces the RAN capability exposure scenario, so at least one RAN capability exposure service needs to be defined, and the core network functions including Network Data Analytics Function (NWDAF) can directly call this service to obtain RAN information. If you want to realize direct service invocation between RAN functions and core network functions, option 2 is essential, but this will also mean that the traditional Non-Access Stratum (NAS) model needs to be changed. The first stage of interface service can enable some scenarios, but the service and on-demand combination of RAN functions in the second stage can truly realize the value of service. This stage can be divided into service for traditional RAN functions (option 3) and service for new DOICT capabilities (option 4). In the design process of option 3, not only do we need to consider how RAN capabilities can be split into services, but we also need to further consider the fusion design of RAN and core network related function services and processes to better meet the design principles of high cohesion and low coupling, and simplify network design.

[0020] In summary, the 5GC is based on a service-oriented architecture, enabling independent scaling and evolution of network functions. 6G will further expand in terms of domain, mechanism, and elements, and will be designed in a full-service manner. Cloud-native RAN is favored by global operators due to its alignment with network virtualization and cloud-native trends. Service-oriented RAN, as an important form of cloud-native RAN, has four technical features: function decoupling, on-demand combination, capability exposure, and service-oriented interface. Its evolution path can be divided into two stages: interface service and function service, to gradually release the value of service.

[0021] In general, services refer to reusable business capabilities that network elements can present externally, while atomic services are business functions obtained by further splitting services, which are more granular services. Service-oriented RAN decouples traditional network functions with rigid and tightly coupled integrated design into atomic service functions with low coupling and high cohesion, providing on-demand combination of basic functions. The service-oriented RAN control plane not only supports the functions of the traditional 5G RAN control plane, but also upgrades each function of the control plane to atomic services. Therefore, the service-oriented RAN control plane has higher on-demand combination capability, more targeted dynamic scaling capability, and deeper integration capability with AI and perception applications than the traditional 5G RAN control plane.

[0022] Currently, with the evolution of service-oriented RAN control plane technology, some functions of the control plane in the traditional 5G RAN architecture have been implemented in the form of atomic services in the service-oriented RAN control plane architecture. However, the functions corresponding to the Xn interface module in the traditional architecture have not yet been implemented in the form of services in the service-oriented RAN architecture, which presents the following technical problems: Technical problem one: some functions of the control plane in the current traditional 5G RAN architecture have been implemented in the service-oriented RAN, but the functions corresponding to the Xn interface module in the traditional architecture still need to be implemented.

[0023] The Xn interface in the traditional architecture is an open interface between NG-RAN nodes. The Xn interface is a point-to-point logical interface that does not require a physical direct connection. The functions supported by the Xn interface include signaling information exchange between NG-RAN nodes, data forwarding in handover, mobility between NG-RAN nodes, and dual connectivity operations between NG-RAN nodes. Among them, the Xn control plane interface is defined as Xn-C, and its application layer signaling protocol is called Xn Application Protocol (XnAP).

[0024] Currently, although the Xn interface module plays an important role in the traditional RAN architecture, there is no atomic service upgrade scheme for the interface module in the related technology, and how to design the atomized XnAP service (referred to as Xn service) in the service-based RAN architecture to realize the functions of inter-base station information synchronization, user equipment (User Equipment, UE) mobility management, and UE data forwarding still needs further research.

[0025] Technical problem two: the Xn interface module plays an important role in the traditional RAN architecture, and how to design the atomized Xn service to realize the functions of inter-base station information interaction still needs further research.

[0026] Currently, before the interface module (E1, F1, NG, Xn) in the traditional RAN architecture sends relevant interface information to the corresponding receiving end, it needs to perform specific ASN.1 encoding, and the corresponding receiving end also needs to perform corresponding ASN.1 decoding after receiving the information. The encoding and decoding process is relatively cumbersome, and the ASN.1 encoding efficiency is relatively low, which may not be conducive to network flexible deployment.

[0027] Unlike the fixed format interface information in the traditional architecture, the interface type service such as the Xn service in the service-based RAN architecture can optimize the assembly method of the interface information, reduce the amount of information data that needs to be transmitted by the control plane external interface, and improve the information transmission efficiency. However, how to coordinate the service-based RAN platform and the modules of the control plane to achieve the above goals still needs to be studied. Finally, the interface information flow in the traditional RAN architecture is relatively complex, and how to reduce the complexity of the flow in the service-based RAN and improve the efficiency of the related flow needs further research.

[0028] Technical problem three: the interface message structure in the traditional RAN architecture is relatively complex, which may not be conducive to network flexible deployment, and how to solve this problem in the service-based RAN architecture and improve the interface openness needs further research.

[0029] Technical problem four: the interface information flow in the traditional RAN architecture is relatively complex, and how to reduce the complexity of the flow in the service-based RAN and improve the efficiency of the related flow needs further research.

[0030] The service-based RAN system architecture is described as follows: The service-based RAN system architecture takes the virtualized cloud platform as the carrier, fuses the underlying network framework, and provides support for the upper multi-service system. Among them, the underlying network framework is derived from the 5GC service architecture and continuously iterated for 6G, aiming to achieve the network vision of "everything as a service" and realize seamless collaboration and architecture unification of core network, access network and user terminal. The upper multi-service system aims to break the solidification mode of traditional network elements, disassemble functions into independent modular components, and introduce a third-party developer ecosystem to gather a variety of application services. The components are independent of each other, like flexible "digital building blocks", which can adapt to different business scenarios. In actual deployment, the network can dynamically arrange component combinations, call logic and data links according to business needs, so that the basic network framework drives the components to run in an orderly manner, completes various network service processes in a agile and efficient way, and significantly improves the network flexibility and business adaptation ability.

[0031] The service-based RAN control domain (CtrlDomain) is responsible for managing the routing information, state information and private information of each service. Among them, the content contained in the private information of each service is determined by the service type, for example: the private information of the Ueh service needs to contain the UE quantity related information. After the start of most services in the service-based RAN centralized unit control plane (Centralized Unit-Control Plane, CUCP), the registration process needs to be initiated to the CtrlDomain. The CtrlDomain can periodically send service routing indication information to all registered services, and the specific process can be referred to the Xn service connection establishment process.

[0032] It should be noted that all services that need to be independently deployed in the service-based RAN CUCP need to initiate a registration process to the CtrlDomain. Some services that need to use routing state information and other information during operation can optionally initiate a registration process to the CtrlDomain.

[0033] The service-based RAN CUCP architecture is a service-based RAN CU control plane architecture, or can be referred to as a service-based RAN control plane architecture. The architecture needs to realize the CUCP function defined in the current 3rd Generation Partnership Project (3GPP) standard based on the principles and methods defined by the service-based RAN. Specifically, the service-based RAN CUCP architecture can include a CUCP main service (Ctrl service + Srv service) module, a Ueh service (CUC service) module, an OAM service module, and an interface type service (F1AP service, E1AP service, NGAP service, and Xn service) module. Among them, the CUCP main service module can only create one service instance, and is mainly responsible for gateway and routing forwarding, cell management, protocol instance management, and UE ID allocation functions; the Ueh service module can create multiple service instances, and is mainly responsible for connection management, session and bearer, mobility management, and service publishing functions; the Operations, Administration and Maintenance (OAM) service module can only create one service instance, and is mainly responsible for Performance Management (PM), Fault Management (FM), and Configuration Management (CM) functions; the interface type service can only create one service instance, and / or use the same service instance as the CUCP main service module, and is mainly responsible for DU message management, CUUP message management, Access and Mobility Management Function (AMF) message management, and neighboring Xn message management.

[0034] It should be noted that in the current service-based RAN CUCP architecture, the CUC service includes the functions of the Ueh service and the PDCP service, and is mainly responsible for managing UE-related resources and message processing procedures and control plane-related transmission functions. Since the detailed description of the PDCP service is omitted in this application, the CUC service can be defined as the Ueh service here.

[0035] Figure 1 is a schematic diagram of a service-based RAN CUCP architecture provided by an embodiment of the present application, as Figure 1 shown, including a CUCP main service module (Ctrl service + Srv service), a Ueh service (CUC service), an OAM service, a F1AP service, an E1AP service, an NGAP service: The CUCP master service is a gateway in the traditional RAN architecture and is a manager of control plane interface type services (F1AP service, E1AP service, NGAP service and Xn service), and provides a transmission service between the control plane internal service and the four interface type services. The functions of the CUCP master service module mainly include routing forwarding, cell management, Ueh service instance management and UE ID allocation, and the specific functions are as follows: 1. Gateway and routing forwarding: As an anchor point of the interface type service, the received external F1, E1, NG, Xn interface messages are forwarded to a specific service instance for processing, while the internal F1, E1, NG, Xn interface messages are forwarded to the outside. At the same time, a message interaction service between the OAM service module is provided.

[0036] 2. Cell management: The functions of cell establishment, modification, deletion and the like are provided, the cell information is synchronized to the Ueh service, and the cell system information (MIB / SIB, etc.) is broadcast.

[0037] 3. Ueh service instance management: The Ueh service stack instances are managed, including Ueh service instance registration and deregistration, routing configuration, user management, interface with the control domain and the like.

[0038] It should be noted that the CUCP master service module can be split into a Ctrl service and a Srv service, wherein the Ctrl service is mainly responsible for the functions of gateway and routing forwarding and Ueh service instance management, and the Srv service is mainly responsible for the function of cell management.

[0039] The Ueh service module is a manager of the control plane UE process in the traditional RAN architecture, has dynamic expansion and contraction capability, provides wireless connection service, session bearer service and mobility management service of the control plane, and supports access network control plane function together with the rest of the CUCP functions. The main functions of the Ueh service module are as follows: 1. UE connection management: The UE context is managed, and the main signaling process of the traditional control plane is managed and executed, such as: the processes of UE access release, reestablishment, handover, paging and the like are managed; the functions of SRB message processing and NAS message transmission in the signaling process are provided; and the messages related to the UE for the E1, F1, NG and Xn interfaces are processed.

[0040] 2. UE session and bearer: The Protocol Data Unit Session (PDU) session and Data Radio Bearer (DRB) context are managed, and the processes related to the PDU session and DRB for the E1 and NG interfaces are processed.

[0041] 3. UE mobility management Manages UE mobility and handover, processes UE measurement report information, makes measurement event decisions, performs related handover procedures, and interacts with NG and Xn services to exchange information.

[0042] The OAM service is the main interface of the CUCP to the network management platform, providing performance management, fault management, and configuration management functions. It is responsible for receiving and forwarding information such as base station configurations and cell configurations obtained from the network management platform, and reporting relevant performance and configuration information obtained from the CUCP main service module to the network management platform. The main functions of the OAM service module are as follows: 1. Performance management: It is mainly responsible for providing means for measuring the quality of service parameters of network connections, and providing network performance parameters for network management. It detects performance degradation of user information using management entities, and takes action to ensure that service quality targets are met.

[0043] 2. Fault management: It detects and locates defects and failures that affect information transmission through continuous or periodic check steps, generates records and alarms of maintenance events. In addition, it can also start system protection through blocking or conversion processes.

[0044] 3. Configuration management: It covers all functions related to providing connections and resources in network elements, and is responsible for configuration information management of network devices, including device parameter setting, software version management, network topology management, etc. Through configuration management, it can ensure that the configuration of network devices meets the requirements of network operation, and can adjust the configuration in a timely manner according to the changes in business demand.

[0045] F1AP is a control protocol between CUCP and DU in traditional RAN architecture. The F1AP service module is mainly responsible for signaling exchange on the F1 interface, and its functions include cell configuration, UE context management, resource control, measurement configuration and reporting, etc., to ensure efficient coordination and flexible management between CU and one or more DUs.

[0046] E1AP is a control protocol between CUCP and CUUP in traditional RAN architecture. The E1AP service module is mainly responsible for signaling interaction on the E1 interface, and its functions include UE context separation and establishment, bearer control, Quality of Service (QoS) flow management, etc., to ensure functional decoupling and coordination between CU control plane and user plane, and support flexible centralized architecture deployment.

[0047] NGAP is a control protocol between CUCP and 5GC (AMF) in the traditional RAN architecture. The NGAP service module is mainly responsible for signaling interaction on the NG interface, and its functions include UE access management, NAS message delivery, PDU session management, context release, etc., to ensure efficient connection and resource coordination between the radio access network and the core network.

[0048] In the embodiments of the present application, a service registration method, related equipment, medium and program product are provided to solve the problem of low flexibility of related network deployment.

[0049] Referring to Figure 2 , Figure 2 is a flowchart of a service registration method provided by the embodiments of the present application, applied to a network side device, such as Figure 2 As shown in the figure, the method comprises the following steps: Step 201, in the case of expiration of a first timer, sending first registration request information to a first service of the network side device, the first registration request information being used to request the first service to register a first Xn service.

[0050] In this step, the above-mentioned first timer can be a software timer, used to delay registration, ensure that the first service has started, and avoid registration failure. The timeout threshold of the above-mentioned first timer can be set to 5s, 10s or other values, which are not limited by the present application.

[0051] The above-mentioned first service can be a control service inside the network side device, used to manage the internal registration of the Xn service, for example, a Ctrl service.

[0052] The above-mentioned first registration request can be used to trigger the Xn service registration process of the first service.

[0053] The above-mentioned first Xn service can be an instance (atomized microservice) of the Xn service, that is, a service-based RAN Xn service. It should be noted that the XnAP in the traditional architecture is a control protocol between the source NG-RAN node and the target NG-RAN node, and the Xn interface is an open interface between the source NG-RAN node and the target NG-RAN node. Referring to the definition of the XnAP and the Xn interface, the above-mentioned service-based RAN Xn service is mainly used for related function processing between NG-RAN nodes, which can include inter-base station information synchronization, UE mobility management, UE data forwarding, etc.

[0054] It should be noted that the service-based RAN CUCP architecture can include a CUCP main service, a Ueh service, an OAM service and an interface type service. As an important interface type service, the Xn service is an inter-base station communication interface service, which needs to be responsible for inter-base station configuration information interaction and other functions.

[0055] Step 202, receiving first registration reply information sent by the first service, the first registration reply information being used to indicate that the first service completes the first Xn service registration.

[0056] In the step, the first registration reply information can be a response of the first service to the first registration request, and can include initial configuration information required for the first Xn service to work, such as base station initial configuration information, CUCP configuration information, etc. The first Xn service can store the base station initial configuration information, the CUCP configuration information, etc. based on the first registration reply information.

[0057] In some embodiments, the first registration reply information includes configuration information of the network side device, and the configuration information of the network side device includes at least one of the following: a maximum number of cells, a maximum number of UE per cell, data radio bearer (DRB) configuration, signaling radio bearer (SRB) configuration, key performance indicator (KPI) measurement interval, public land mobile network (PLMN) information, network side device identifier, access and mobility management function (AMF) number, paging discontinuous reception (DRX) and tracking area (TA) number.

[0058] Step 203, in the case that the first registration reply information is received and the second timer is timed out, sending second registration request information to a control platform, the second registration request information including configuration information of the first Xn service.

[0059] In the step, the second timer can be a software timer, used to delay triggering registration.

[0060] The control platform can be a service-based RAN platform in a micro-service architecture, used to manage global service discovery, such as CtrlDomain.

[0061] The second registration request information can be used to register the first Xn service to a global control plane domain.

[0062] The configuration information of the first Xn service can be used to uniquely identify the first Xn service in the control platform.

[0063] In some embodiments, the configuration information of the first Xn service includes at least one of the following: a type of the first Xn service, a name of the first Xn service, and a network side device identifier.

[0064] Step 204, receiving second registration reply information sent by the control platform, the second registration reply information being used for indicating that the control platform completes the first Xn service registration.

[0065] In this step, the second registration reply information can be a response of the control platform to the second registration request, and is used for indicating the confirmation of the control platform to the registration success.

[0066] In the embodiments of the present application, in the case that the first timer is timed out, first registration request information is sent to the first service of the network side device, the first registration request information being used for requesting the first service to register the first Xn service; first registration reply information sent by the first service is received, the first registration reply information being used for indicating that the first service completes the first Xn service registration; in the case that the first registration reply information is received and the second timer is timed out, second registration request information is sent to the control platform, the second registration request information including configuration information of the first Xn service; second registration reply information sent by the control platform is received, the second registration reply information being used for indicating that the control platform completes the first Xn service registration. In this way, the first Xn service is added to the network as an independent micro service through the registration process of the first Xn service, so that the Xn service can be created independently, the Xn service is decoupled from the hardware, and thus the flexibility of network deployment can be improved.

[0067] In some embodiments, the method further includes: receiving first synchronization information sent by the first service, the first synchronization information being used for indicating configuration information of the activated cell; setting a first information synchronization state to synchronized, the first information synchronization state being used for indicating a synchronization state of the first Xn service and the first service.

[0068] It can be understood that in the case that the first service constructs the first registration reply information, if the cell has completed the establishment, the first service can send the first synchronization information at the same time. The first synchronization information is used for synchronizing the current network state to the first Xn service.

[0069] The activated cell can mean a cell that has been created and started, and normally provides services for user terminals.

[0070] The configuration information of the activated cell can include detailed parameters of the cell, for example, static configuration of the cell, and current running state, etc.

[0071] In some embodiments, the configuration information of the activated cell can include cell information and AMF information, wherein the cell information includes Cell Global Identifier (CGI), serving cell index, Physical Cell Identifier (PCI), cell measurement configuration, cell state, cell multiplexing mode, number of cell neighbor cells, and cell neighbor cell configuration, and the AMF information includes AMF serial number, Globally Unique AMF Identifier (GUAMI), and AMF state.

[0072] The first information synchronization state can be a state flag maintained internally in the first Xn service, and is used to indicate the synchronization state of the first Xn service and the first service.

[0073] In this embodiment, by receiving the first synchronization information sent by the first service, the first Xn service can synchronize the configuration information of the currently activated cell in time, and thus can quickly and correctly guide the user equipment to access, avoiding switching failure or service interruption.

[0074] In some embodiments, after receiving the first registration reply information sent by the first service, the method further includes: stopping the first timer; After receiving the second registration reply information sent by the control platform, the method further includes: setting the registration state of the first Xn service to registered based on the second registration reply information; stopping the second timer.

[0075] The registration state can be a state variable maintained internally in the first Xn service, and is used to record the registration of the first Xn service in the control platform.

[0076] It can be understood that setting the registration state of the first Xn service to registered can be used to indicate that the first Xn service instance has been successfully registered in the control platform, and can be discovered and called by other services.

[0077] In this embodiment, by stopping the first timer and the second timer, timer resources can be released in time, and repeated triggering of registration in the future can be avoided, so that resource waste can be avoided.

[0078] In some embodiments, the method further includes: receive service route indication information sent by the control platform, the service route indication information including route information corresponding to at least one newly registered second Xn service and / or at least one newly deregistered third Xn service; update the route information table based on the service route indication information.

[0079] The service route indication information can be a message actively broadcast by the control platform periodically or event-triggered, and can specifically include information such as a newly registered Xn service list and a newly deregistered Xn service list.

[0080] In some embodiments, the control platform starts a periodic timer, for example, a route information broadcast timer, and in the case that the route information broadcast timer expires, determines whether there is a newly registered or deregistered Xn service based on the registration state information of the Xn service, constructs service route indication information if there is, the service route indication information including information such as a newly registered Xn service list and a newly deregistered Xn service list, and sends the service route indication information to at least one Xn service. It can be understood that the at least one Xn service includes the first Xn service.

[0081] The newly registered second Xn service can refer to an Xn service instance of another base station that is newly online. The newly deregistered third Xn service can refer to an Xn service instance of another base station that is offline. The route information can be understood as address information of the Xn service, such as IP address, port number, service name, and other network positioning information.

[0082] The route information table can be a route information table maintained by the first Xn service itself, which can include related route information of neighboring Xn services.

[0083] In this embodiment, by receiving the service route indication information sent by the control platform and updating the route information table based on the service route indication information, the first Xn service can update the route information of the neighboring Xn service in a timely manner, thereby improving the reliability of the network.

[0084] In some embodiments, the updating of the route information table based on the service route indication information includes at least one of the following: In the case that the route information of the at least one second Xn service is not stored in the route information table, adding the route information of the at least one second Xn service in the route information table; deleting the route information of the at least one third Xn service in the route information table; The method further includes at least one of the following: adding configuration information of the at least one second Xn service in the neighboring Xn service information table; deleting the configuration information of the at least one third Xn service in the neighbor Xn service information table.

[0085] The neighbor Xn service information table described above can be a neighbor Xn service information table maintained by the first Xn service itself, which can include service capability information and identity information of the neighbor Xn service, etc.

[0086] The configuration information of the second Xn service and the configuration information of the third Xn service described above can be base station identification information of the Xn service, etc.

[0087] In this embodiment, by distinguishing and cooperatively updating the routing information table and the neighbor Xn service information table, the decoupling of communication and service can be achieved, the processing efficiency is improved, and the accuracy of network connection and service decision can be ensured, thereby improving the experience of the terminal.

[0088] In some embodiments, the method further includes: In a case where the first information synchronization state is set to synchronized, sending second synchronization information to the at least one second Xn service, the second synchronization information being used to indicate the configuration information of the first Xn service, and the first information synchronization state being used to indicate the synchronization state of the first Xn service and the first service.

[0089] The configuration information of the first Xn service described above can include service identification, base station identification, TAI information, cell information, and AMF information of the first Xn service, etc.

[0090] In this embodiment, by sending the second synchronization information to the at least one second Xn service, the second synchronization information being used to indicate the configuration information of the first Xn service, the at least one second Xn service, i.e., the newly registered Xn service, can obtain the configuration information of the neighbor Xn service in time, thereby further improving the reliability of the network.

[0091] In some embodiments, the method further includes: receiving first release indication information sent by the control platform, the first release indication information being used to indicate that the first Xn service requests deregistration; generating a deregistration request information based on the first release indication information; sending the deregistration request information to the control platform; receiving deregistration request reply information sent by the control platform, the deregistration request reply information being used to indicate that the first Xn service completes deregistration; generating second release indication information based on the deregistration request reply information, the second release indication information being used to indicate that the first Xn service completes deregistration; sending the second release indication information to the first service, so that the first service releases configuration information of a neighbor Xn service information table maintained by the first service based on the second release indication information.

[0092] The first release indication information can be an instruction or a notification sent by the control platform, and can include an identifier of the first Xn service.

[0093] It can be understood that the control platform can generate the first release indication information based on a service-based RAN platform, and the service-based RAN platform can determine to start or release a certain Xn service based on UE state, cell load, and service demand.

[0094] The deregistration request information can be information requested by the first Xn service from the control platform, and can include a service type, a service route, and a service identifier of the first Xn service.

[0095] In some embodiments, the control platform can determine a service type based on the first release indication information, and delete an entry corresponding to the service in a service registration table maintained by the control platform.

[0096] The second release indication information can be used to notify the first service that the first Xn service has completed deregistration.

[0097] In this embodiment, the first Xn service completes deregistration based on the first release indication information received from the control platform, so that the control platform can release service instances that are no longer needed according to demand, and immediately release computing resources occupied by the service instances, thereby improving resource utilization of the network.

[0098] Meanwhile, the first service can release configuration information of a neighbor Xn service information table maintained by the first service based on the second release indication information sent by the control platform, so that the first service can update the neighbor Xn service information table in a timely manner, thereby avoiding terminal handover failure and saving resources.

[0099] In some embodiments, before the first registration request information is sent to the first service of the network side device, the method further includes: starting an initialization process of the first Xn service, the initialization process including a version acquisition process, a main module initialization process, a working module initialization process, and an information processing function initialization process. The version obtaining procedure is used to obtain related information of the first Xn service, the main module initialization procedure is used to initialize a function providing object, functions and global information tables of the first Xn service, the worker module initialization procedure is used to start the first timer, and the information processing function initialization procedure is used to initialize a received information queue.

[0100] It can be understood that the initialization procedure of the first Xn service as an interface type service in the service-based RAN control plane architecture can be designed with reference to other interface type services (F1AP service, E1AP service and NGAP service).

[0101] Specifically, the first Xn service is started by the platform with reference to a service starting sequence after the service-based RAN platform is started, and the procedures of version obtaining (GetVersion), main module initialization (MainInit), worker module initialization (WorkerInit), information processing function initialization (MsgProcInit) and timer function processing initialization (TimerProcInit) are sequentially executed.

[0102] The version obtaining procedure is used to obtain platform version, service starting time, service name and the like. Optionally, when the Xn service is successfully started, the information can be printed in a running interface of the service-based platform.

[0103] The main module initialization procedure first initializes an Xn service global function providing object, which can provide, but is not limited to, memory service, message passing service, log service, command line service, counter service and timer service. Then, log function, counter function, command line function and interface opening function are sequentially initialized. Finally, part of global information tables maintained by the Xn service are initialized, including Xn service information table, neighboring Xn service information table and log information table.

[0104] The worker module will execute different initialization procedures based on the current initialization stage of the platform. When the platform initialization proceeds to the second stage (stage 2), the worker module can create an Xn service registration timer, which is the first Xn registration timer. When the first Xn registration timer expires, a registration procedure to the Ctrl service is triggered, and the specific procedure can be seen from the registration procedure of the Xn service.

[0105] The information processing function maintains a received information queue and distributes the received information to corresponding modules for processing. Specifically, the information processing function needs to filter the received information based on information targets, etc. If the information target is not the Xn service, the received information is filtered; otherwise, the received information is stored in the received message queue, and the received information is distributed to corresponding modules for processing based on the source, type, etc. of the received information. In the initialization phase, the information processing function needs to initialize the received information queue so that the first received information can be successfully stored in the message queue and correctly processed.

[0106] The timer function is responsible for processing related events triggered after the timeout of each timer of the Xn service. For example, when the first timer times out, the registration process to the Ctrl service can be triggered. The timer function will construct registration information and send the information to the Ctrl service. Currently, the timer function does not need to perform the initialization process.

[0107] In this embodiment, by starting the initialization process of the first Xn service, the initialization process includes the version acquisition process, the main module initialization process, the working module initialization process, and the information processing function initialization process, so that the reliability and consistency of the start of the first Xn service can be ensured. Based on the initialization process, the Xn service can implement the basic functions of the service-based RAN atomic service, which can run in parallel with the rest of the control plane atomic service based on actual operation requirements and perform corresponding functions.

[0108] The method provided by the embodiments of the present application is illustrated as follows: Exemplarily, Figure 3 is an interaction schematic diagram of an Xn service registration process provided by an embodiment of the present application, as Figure 3 shown, after the Xn service starts, it will sequentially perform the preset initialization process of each module or function. Among them, the working module can start the Xn first registration timer (XN_TIMER_MAIN_LOOP_SECOND) when the platform initialization proceeds to the second stage (stage2) to trigger the registration process to the Ctrl service after a certain time, and send the Xn first registration request information (XN_CTRL_REGISTER_REQ) to the Ctrl service.

[0109] The Ctrl service can construct the Xn first registration reply information (CTRL_XN_REGISTER_RSP) and carry the base station initial configuration information, CUCP configuration information, etc. in it; Optionally, if the cell has completed establishment when the registration reply information is constructed, the Ctrl service can also send the CTRL first synchronization information (CTRL_XN_SYNC_IND) at the same time. When the Xn service receives the registration reply information sent by the Ctrl service, the Xn first registration timer can be stopped.

[0110] After the Xn service completes the registration procedure to the Ctrl service, the Xn second registration timer can be started to trigger the registration procedure to the Ctrl Domain after a certain time and send the Xn second registration request information (XN_CD_REGISTER_REQ) to the Ctrl Domain.

[0111] The Ctrl Domain can construct the Xn second registration reply information (CD_XN_REGISTER_RSP) and carry the initial service information of the Ctrl Domain therein.

[0112] When the Xn service receives the registration reply information sent by the Ctrl Domain, the Xn second registration timer can be stopped.

[0113] The specific procedure includes: Step 1, the Xn service will: 1> sequentially perform the version acquisition, main module initialization and working module initialization procedures, and when the working module initialization procedure proceeds to the second stage (stage 2), start the Xn first registration timer. The timeout threshold of the Xn first registration timer can be set to 5s, 10s or other values; 2> sequentially perform the information processing initialization and timer processing initialization procedures; 3> if the Xn first registration timer times out: 4> the timer processing function processes the timing event corresponding to the Xn first registration timer, which is a registration event to the Ctrl service; 5> construct the Xn first registration request information to the Ctrl service, which contains: Xn service registration state information, etc. 6> send the Xn first registration request information to the Ctrl service.

[0114] It should be noted that the Xn service will be started by the platform based on the service startup order after the service RAN platform is started.

[0115] Step 2, the Ctrl service will: 1> (optionally) if the registration procedure of the OAM service has been completed: 1> (optionally) if the OAM service registration state of the Ctrl service is set to registered: 1> receive the Xn first registration request information sent by the Xn service; 2> construct Xn first registration reply information based on the Xn first registration request information, the Xn first registration reply information containing: base station initial configuration information, CUCP configuration information, etc. Wherein, the base station initial configuration information contains: maximum number of cells, maximum number of UE per cell, DRB configuration, SRB configuration, KPI measurement interval, etc. Wherein, the CUCP configuration information contains: PLMN information, base station identifier, AMF number, paging DRX and TA number, etc.

[0116] 3> send the Xn first registration reply information to the Xn service; 3> set the Xn service registration state of the Ctrl service to registered.

[0117] and / or, 2> (optionally) if there is an activated cell: 2> (optionally) if there is a cell with activated state set to activated: 3> construct CTRL first synchronization information based on the relevant cell information stored by itself and the Xn first registration request information, the CTRL first synchronization information containing: cell information and AMF information, etc. Wherein, the cell information contains: cell CGI, serving cell index, cell PCI, cell measurement configuration, cell state, cell multiplexing mode, cell neighbor quantity and cell neighbor configuration, etc. The AMF information contains: AMF serial number, GUAMI, AMF state, etc. 4> send the CTRL first synchronization information to the Xn service.

[0118] Step 3, the Xn service will: 1> receive the Xn first registration reply information sent by the Ctrl service; 2> store the base station initial configuration information, CUCP configuration information, etc. based on the Xn first registration reply information; 3> (optionally) stop the Xn first registration timer; 3> (optionally) start the Xn second registration timer; and / or, 1> (optionally) receive the CTRL first synchronization information sent by the Ctrl service; 2> store the cell information and AMF information, etc. based on the CTRL first synchronization information; 3> set the Ctrl information synchronization state of the Xn service to synchronized.

[0119] Step 4, the Xn service will: 1> if the Xn second registration timer expires: 2> The timer processing function processes the timing event corresponding to the Xn second registration timer, which is the registration event to the CtrlDomain; 3> Constructs the Xn second registration request information to the CtrlDomain, which contains information such as service type, service name, base station identifier, etc. 4> Sends the Xn second registration request information to the CtrlDomain.

[0120] Step 5, the CtrlDomain will: 1> Receive the Xn second registration request information sent by the Xn service; 2> Determine the service type based on the Xn second registration request information, and add an entry in the service registration table maintained by itself to store the service information; 3> Constructs the Xn second registration reply information, which contains registration status information, etc. 4> Sends the Xn second registration reply information to the Xn service.

[0121] Step 6, the Xn service will: 1> Receive the Xn second registration reply information sent by the CtrlDomain; 2> Set the Xn service registration state of the CtrlDomain based on the Xn second registration reply information; 3> (Optionally) if the registration state is set to registered: 4> Stop the Xn second registration timer.

[0122] It should be noted that the above Xn service and the source Xn service in the figure are used to indicate the XN service of the source base station, i.e. SRC_CucpXn.

[0123] Exemplarily, Figure 4 is an interaction diagram of an Xn service connection establishment process provided by an embodiment of the present application, as Figure 4 shown, after the Xn service completes the registration process to the CtrlDomain, it can receive the service routing indication information (CD_XN_SRVROUTE_IND) sent by the CtrlDomain.

[0124] When the Xn service first receives the service routing indication information, it should initialize the service routing information table maintained by itself, and when it receives the information subsequently, it should add or delete the routing information of the corresponding target end Xn service based on the service routing information table.

[0125] Optionally, when the Xn service adds the routing information of the corresponding target Xn service, if the Xn service has received the CTRL first synchronization information sent by the Ctrl service, and / or the Ctrl information synchronization state is set to synchronized, the XN first synchronization information (XN_XN_SYN_IND) should be sent to all newly added corresponding target Xn services.

[0126] Optionally, when the Ctrl service receives the SRV first synchronization information (SRV_CTRL_SYN_IND) sent by the SRV service, if the Xn service has registered with the Ctrl service at this time, the CTRL first synchronization information should be sent to the Xn service, and if the Xn service has received the routing information sent by the CtrlDomain, the Xn service should send the XN first synchronization information to all added corresponding target Xn services.

[0127] When the corresponding target Xn service receives the XN first synchronization information, it should send the synchronization information to the Ctrl service of the base station to which it belongs, and the Ctrl service should send the synchronization information to the corresponding CUC service, so that the corresponding CUC service can use the cell information of the base station to which the Xn service belongs when processing the subsequent switching related process.

[0128] The specific process includes: Step 1, the CtrlDomain will: 1> start a periodic timer CtrlDomain routing information broadcast timer (CD_TIMER_LOOP_PCF_ROUTE_IND); 2> if the CtrlDomain routing information broadcast timer expires: 3> determine whether there are newly registered or deregistered Xn services based on the Xn service registration state information, if so: 4> construct service routing indication information, which contains information such as newly registered Xn service list and newly deregistered Xn service list; 5> send the service routing indication information to the Xn service.

[0129] Step 2, the Xn service will: 1> receive the service routing indication information sent by the CtrlDomain; 2> update the routing information table maintained by itself based on the service routing indication information; 3> (optionally) if the routing information of the newly registered Xn service is not stored in the routing information table: 4> add the routing information of the newly registered Xn service in the routing information table; 5> Add the related configuration information of the newly registered Xn service in the self-maintained neighbor Xn service information table, and the configuration information includes: base station identifier and the like; 5> (Optionally) if the Ctrl information synchronization state is set to synchronized: 6> Send XN first synchronization information to all the newly registered Xn services, and the XN first synchronization information includes: service identifier, base station identifier, TAI information, cell information and AMF information and the like.

[0130] Or, 5> (Optionally) if the Ctrl information synchronization state is set to unsynchronized: 6> Wait for receiving the CTRL first synchronization information sent by the Ctrl service.

[0131] And / or, 3> (Optionally) if the routing information table stores the routing information of the newly deregistered Xn service: 4> Delete the routing information of the newly deregistered Xn service in the routing information table; 5> Delete the related configuration information of the newly deregistered Xn service in the self-maintained neighbor Xn service information table, and the configuration information includes: base station identifier and the like.

[0132] It should be noted that the content included in the XN first synchronization information does not need to be encoded based on the related technology process Xn ASN, and can be directly sent to the corresponding Xn service.

[0133] Step 3, the corresponding target end Xn service will: 1> Receive the XN first synchronization information sent by the Xn service; 2> Update the service identifier, base station identifier, TAI information, cell information and AMF information and the like of the corresponding base station stored by itself based on the XN first synchronization information; 3> Send XN first synchronization information (XN_CTRL_SYN_IND) to the corresponding target end Ctrl service.

[0134] Step 4, the corresponding target end Ctrl service will: 1> Receive the XN first synchronization information sent by the corresponding target end Xn service; 2> Store the base station identifier, TAI information, cell information and AMF information and the like of the corresponding cell in the self-maintained neighbor Xn service information table; 3> Send Xn second synchronization information (CTRL_CUC_NBR_SYN_IND) to all the registered corresponding target end CUC services.

[0135] Step 5, the corresponding target end CUC service will: 1> receives the Xn second synchronization information sent by the target end Ctrl service corresponding to the target end; 2> stores the base station identifier, TAI information, cell information and AMF information of the corresponding cell in the neighbor Xn service information table maintained by itself.

[0136] In the above embodiment, the Xn service connection establishment process of the service-based RAN Xn service is designed, and the basic function of the process is to realize the initial configuration information synchronization between base stations. Compared with the Xn connection establishment process in the traditional RAN architecture, the method provided in the embodiment of the application is based on the structure adjustment mode of each information in the information interaction process between base stations based on the Xn interface, which simplifies the number of parameters contained in part of the information or sets part of the parameters as optional to contain, and deletes the ASN coding process of Xn, so that the designed process is more simplified, the interface information structure is optimized, and thus the interface opening degree and the interface information transmission efficiency are improved. In addition, in view of the problem that the interface information process in the traditional RAN architecture is relatively complex, the method provided in the application greatly reduces the number of information transmission between modules and modules that need to be interacted, thereby further improving the interface information transmission efficiency.

[0137] Exemplarily, Figure 5 is an interaction schematic diagram of an Xn service release process provided by the embodiment of the application, as Figure 5 shown, when the service-based RAN platform decides to release a certain Xn service, it will first send the XN first release indication information (CD_XN_XNREMOVAL_IND) to the Xn service to the CtrlDomain; After the Xn service receives the XN release indication information, it can send the XN deregistration request information (XN_CD_DEREGISTER_REQ) to the CtrlDomain; After the CtrlDomain receives the XN deregistration request information, it can send the XN deregistration reply information (CD_XN_DEREGISTER_RSP) to the Xn service; After the Xn service receives the XN deregistration reply information, it can send the XN second release indication information (XN_CTRL_XNREMOVAL_IND) to the Ctrl service; After the Ctrl service receives the XN second release indication information, it can release the Xn service related configuration information, set the Xn service to the unregistered state, and send the XN third release indication information (CTRL_CUC_XNREMOVAL_IND) to all registered CUC services; After the CUC service receives the XN third release indication information, it can release the Xn service related configuration information stored by itself.

[0138] Further, all Xn services registered to the CtrlDomain can receive the service route indication information sent by the CtrlDomain, update the route information table maintained by itself based on the service route indication information, delete the route information of the relevant Xn service and the configuration information of the relevant Xn service maintained by itself, and send XN second release indication information to the relevant Ctrl service; The relevant Ctrl service receives the XN second release indication information, releases the relevant configuration information of the relevant Xn service, sets the relevant Xn service to an unregistered state, and sends XN third release indication information to all registered relevant CUC services; The relevant CUC service receives the XN third release indication information and can release the relevant configuration information of the relevant Xn service stored by itself.

[0139] It should be noted that the service-based RAN platform can decide to start or release a service according to UE state, cell load, and service demand information.

[0140] The specific process includes: Step 1, the CtrlDomain will: 1> construct XN first release indication information based on the relevant indication information of the service-based platform, wherein the XN first release indication information contains Xn service identification and other information; 2> send the XN first release indication information to the Xn service.

[0141] Step 2, the Xn service will: 1> receive the XN first release indication information sent by the CtrlDomain; 2> construct XN deregistration request information based on the XN first release indication information, wherein the XN deregistration request information contains service type, service route, and service identification and other information; 3> send the XN deregistration request information to the CtrlDomain.

[0142] Step 3, the CtrlDomain will: 1> receive the XN deregistration request information sent by the Xn service; 2> determine the service type based on the XN deregistration request information, and delete the corresponding entry of the service in the service registration table maintained by itself; 3> construct XN deregistration reply information, wherein the XN deregistration reply information contains service deregistration result information and the like; 4> send the XN deregistration reply information to the Xn service.

[0143] Step 4, the Xn service will: 1> receive the XN deregistration reply information sent by the CtrlDomain; 2> construct XN second release indication information based on the XN deregistration reply information, wherein the XN second release indication information contains self-service reset indication information, etc.; 3> send the XN second release indication information to the Ctrl service.

[0144] Step 5, the Ctrl service will: 1> receive the XN second release indication information sent by the Xn service; 2> release all configuration information in the adjacent Xn service information table maintained by itself based on the Xn second release indication information; 3> send XN third release indication information to all registered CUC services.

[0145] Step 6, the CUC service will: 1> receive the XN third release indication information sent by the Ctrl service; 2> release all configuration information in the adjacent Xn service information table maintained by itself based on the Xn third release indication information.

[0146] In addition, the remaining Xn services will receive the route information updated by the CtrlDomain, and perform relevant operations based on the route information, and the specific process is as follows: Step 7, the CtrlDomain will: 1> start a periodic timer CtrlDomain route information broadcast timer; 2> if the CtrlDomain route information broadcast timer expires: 3> determine whether there are newly registered or deregistered Xn services based on the Xn service registration state information, if so: 4> construct service route indication information, wherein the service route indication information contains information such as newly registered Xn service list and newly deregistered Xn service list; 5> send the service route indication information to all registered target end Xn services.

[0147] Step 8, the target end Xn service will: 1> receive the service route indication information sent by the CtrlDomain; 2> update the route information table maintained by itself based on the service route indication information; 3> (optionally) if the route information table stores the route information of the newly deregistered Xn service: 4> delete the route information of the newly deregistered Xn service contained in the route information table; 5> Delete the relevant configuration information for registering Xn services added to the neighbor Xn service information table maintained by itself. The configuration information includes: base station identifier and other information; 6> Send the XN second release instruction information to the target Ctrl service. The XN second release instruction information includes information such as the number of neighboring Xn services deleted and the identifier of the neighboring Xn service base station.

[0148] Step 9: The target Ctrl service will: 1> Receive the second release instruction information XN sent by the target Xn service; 2> Based on the second release instruction information of Xn, release the configuration information of the relevant Xn service in the neighboring Xn service information table maintained by itself; 3> Send the XN third release instruction message to all registered target CUC services.

[0149] Step 10: The target-side CUC service will: 1> Receive the XN third release instruction information sent by the target Ctrl service; 2> Based on the third release instruction information of Xn, release the configuration information of the relevant Xn service in the neighboring Xn service information table maintained by itself.

[0150] The method provided in this application embodiment not only realizes some basic functions of the Xn interface in the traditional RAN architecture, but also meets the design principles of atomic services in service-oriented RAN, and initially completes the technical framework of atomic Xn services, allowing subsequent designs to continue based on the method. Furthermore, the service-oriented RAN platform can dynamically start or release relevant Xn services based on actual deployment or operational needs. When the network load is low or the number of neighboring cells is small, the service-oriented RAN platform can dynamically release some Xn services; when the network load is low or the number of neighboring cells is large, the service-oriented RAN platform can dynamically start some Xn services, realizing the dynamic scaling function of service level, thereby improving the functional control capability, resource utilization efficiency, and deployment flexibility of the service-oriented RAN control plane.

[0151] See Figure 6 , Figure 6 This is one of the structural schematic diagrams of a network-side device provided in the embodiments of this application, such as... Figure 6 As shown, the network-side device 600 includes: The first sending module 601 is used to send a first registration request information to the first service of the network-side device when the first timer expires. The first registration request information is used to request the first service to register the first Xn service. The first receiving module 602 is configured to receive first registration reply information sent by the first service, where the first registration reply information is used to indicate that the first service completes the first Xn service registration. The second sending module 603 is configured to send second registration request information to a control platform in a case where the first registration reply information is received and a second timer is timed out, where the second registration request information includes configuration information of the first Xn service. The second receiving module 604 is configured to receive second registration reply information sent by the control platform, where the second registration reply information is used to indicate that the control platform completes the first Xn service registration.

[0152] Optionally, the network side device further includes: The third receiving module is configured to receive first synchronization information sent by the first service, where the first synchronization information is used to indicate configuration information of an activated cell. The first setting module is configured to set a first information synchronization state to synchronized, where the first information synchronization state is used to indicate a synchronization state of the first Xn service and the first service.

[0153] Optionally, the network side device further includes: The first stopping module is configured to stop the first timer. The second setting module is configured to set a registration state of the first Xn service to registered based on the second registration reply information. The second stopping module is configured to stop the second timer.

[0154] Optionally, the network side device further includes: The fourth receiving module is configured to receive service routing indication information sent by the control platform, where the service routing indication information includes routing information corresponding to at least one newly registered second Xn service and / or at least one newly deregistered third Xn service. The updating module is configured to update a routing information table based on the service routing indication information.

[0155] Optionally, the updating module includes at least one of the following: The adding unit is configured to add routing information of the at least one second Xn service in the routing information table in a case where the routing information of the at least one second Xn service is not stored in the routing information table. The deleting unit is configured to delete routing information of the at least one third Xn service in the routing information table. The network side device further includes at least one of the following: an adding module, configured to add configuration information of the at least one second Xn service in a neighbor Xn service information table; a deleting module, configured to delete configuration information of the at least one third Xn service in the neighbor Xn service information table.

[0156] Optionally, the network-side device further comprises: a third sending module, configured to, in a case where the first information synchronization state is set to synchronized, send second synchronization information to the at least one second Xn service, the second synchronization information being used to indicate configuration information of the first Xn service, and the first information synchronization state being used to indicate a synchronization state of the first Xn service and the first service.

[0157] Optionally, the network-side device further comprises: a fifth receiving module, configured to receive first release indication information sent by the control platform, the first release indication information being used to indicate that the first Xn service requests deregistration; a first generating module, configured to generate deregistration request information based on the first release indication information; a fourth sending module, configured to send the deregistration request information to the control platform; a sixth receiving module, configured to receive deregistration request reply information sent by the control platform, the deregistration request reply information being used to indicate that the first Xn service completes deregistration; the network-side device further comprises: a second generating module, configured to generate second release indication information based on the deregistration request reply information, the second release indication information being used to indicate that the first Xn service completes deregistration; a fifth sending module, configured to send the second release indication information to the first service, and the first service is used to release configuration information of a neighbor Xn service information table maintained by the first service based on the second release indication information.

[0158] Optionally, the network-side device further comprises: a starting module, configured to start an initialization process of the first Xn service, the initialization process comprising a version acquisition process, a main module initialization process, a working module initialization process, and an information processing function initialization process; wherein the version acquisition process is used to acquire related information of the first Xn service, the main module initialization process is used to initialize a function providing object, a function, and a global information table of the first Xn service, the working module initialization process is used to start the first timer, and the information processing function initialization process is used to initialize a received information queue.

[0159] Optionally, the first registration reply information comprises configuration information of the network-side device, and the configuration information of the network-side device comprises at least one of the following: a maximum number of cells, a maximum number of UEs per cell, data radio bearer (DRB) configuration, signaling radio bearer (SRB) configuration, key performance indicator (KPI) measurement interval, public land mobile network (PLMN) information, network-side device identifier, access and mobility management function (AMF) number, paging discontinuous reception (DRX), and tracking area (TA) number; and / or, The configuration information of the first Xn service comprises at least one of the following: a type of the first Xn service, a name of the first Xn service, and network-side device identifier.

[0160] It should be noted that the network-side device provided by the embodiments of the present application is an apparatus capable of performing the service registration method described above, and all implementation manners in the service registration method embodiments are applicable to the apparatus and can achieve the same or similar beneficial effects. To avoid repetition, the embodiments will not be described again.

[0161] Specifically, referring to FIG. 7, Figure 7 The network-side device provided by the embodiments of the present application comprises a bus 701, a transceiver 702, an antenna 703, a bus interface 704, a processor 705, and a memory 706.

[0162] The transceiver 702 is configured to, in a case where the first timer expires, send first registration request information to a first service of the network-side device, the first registration request information being used to request the first service to register a first Xn service; receive first registration reply information sent by the first service, the first registration reply information being used to indicate that the first service completes the first Xn service registration; In a case where the first registration reply information is received and the second timer expires, send second registration request information to a control platform, the second registration request information comprising configuration information of the first Xn service; receive second registration reply information sent by the control platform, the second registration reply information being used to indicate that the control platform completes the first Xn service registration.

[0163] In a case where the first registration reply information is received and the second timer expires, send second registration request information to a control platform, the second registration request information comprising configuration information of the first Xn service; Figure 7In particular embodiments, the bus architecture (represented by bus 701) can include any number of interconnecting buses and bridges needed to link various circuitry, including a processor 705 represented by one or more processors and a memory 706 represented by a memory. Bus 701 can also link various other circuitry, such as peripheral devices, voltage regulators, and power management circuitry, all of which are well known in the art, and therefore, not described further. Bus interface 704 provides an interface between bus 701 and transceiver 702. Transceiver 702, which can be a single element or a plurality of elements such as a plurality of receivers and transmitters, provides a means for communicating with various other apparatus over a transmission medium. Antenna 703 transmits data processed by processor 705 over a wireless medium, and further, antenna 703 receives data and communicates the data to processor 705.

[0164] Processor 705 is responsible for managing the bus 701 and general processing, including the execution of software stored in memory 706. The software, when executed by the processor 705, causes the processing circuitry to perform the various functions described herein.

[0165] Processor 705 can be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other processing logic.

[0166] Optionally, transceiver 702 is further configured to: receive first synchronization information sent by the first service, the first synchronization information being used to indicate configuration information of an activated cell; Processor 705 is further configured to: set a first information synchronization state to synchronized, the first information synchronization state being used to indicate a synchronization state of the first Xn service and the first service.

[0167] Optionally, processor 705 is further configured to: stop the first timer; set a registration state of the first Xn service to registered based on the second registration reply information; stop the second timer.

[0168] Optionally, transceiver 702 is further configured to: receive service route indication information sent by the control platform, the service route indication information including route information corresponding to at least one newly registered second Xn service and / or at least one newly deregistered third Xn service; The processor 705 is further configured to: update a route information table based on the service route indication information.

[0169] Optionally, the processor 705 is specifically configured to perform at least one of the following: add route information of the at least one second Xn service in the route information table in a case where the route information of the at least one second Xn service is not stored in the route information table; delete route information of the at least one third Xn service in the route information table; The processor 705 is further configured to perform at least one of the following: add configuration information of the at least one second Xn service in a neighboring Xn service information table; delete configuration information of the at least one third Xn service in the neighboring Xn service information table.

[0170] Optionally, the transceiver 702 is further configured to: in a case where a first information synchronization state is set to synchronized, send second synchronization information to the at least one second Xn service, the second synchronization information being used to indicate configuration information of the first Xn service, and the first information synchronization state being used to indicate a synchronization state of the first Xn service and the first service.

[0171] Optionally, the transceiver 702 is further configured to: receive first release indication information sent by the control platform, the first release indication information being used to indicate that the first Xn service requests deregistration; generate deregistration request information based on the first release indication information; send the deregistration request information to the control platform; receive deregistration request reply information sent by the control platform, the deregistration request reply information being used to indicate that the first Xn service completes deregistration; The processor 705 is further configured to: generate second release indication information based on the deregistration request reply information, the second release indication information being used to indicate that the first Xn service completes deregistration; The transceiver 702 is further configured to: The second release indication information is sent to the first service, and the first service is used to release configuration information of a neighbor Xn service information table maintained by the first service based on the second release indication information.

[0172] Optionally, the processor 705 is further configured to: start an initialization process of the first Xn service, the initialization process including a version acquisition process, a main module initialization process, a working module initialization process and an information processing function initialization process; The version acquisition process is configured to acquire related information of the first Xn service, the main module initialization process is configured to initialize a function providing object, a function and a global information table of the first Xn service, the working module initialization process is configured to start the first timer, and the information processing function initialization process is configured to initialize a received information queue.

[0173] Optionally, the first registration reply information includes configuration information of the network side device, and the configuration information of the network side device includes at least one of the following: a maximum number of cells, a maximum number of UE per cell, data radio bearer (DRB) configuration, signaling radio bearer (SRB) configuration, key performance indicator (KPI) measurement interval, public land mobile network (PLMN) information, network side device identifier, access and mobility management function (AMF) number, paging discontinuous reception (DRX) and tracking area (TA) number; and / or The configuration information of the first Xn service includes at least one of the following: a type of the first Xn service, a name of the first Xn service and a network side device identifier.

[0174] It should be noted that the electronic device provided by the embodiments of the present application is a device capable of executing the service registration method described above, and all implementation manners in the service registration method embodiments are applicable to the electronic device and can achieve the same or similar beneficial effects. To avoid repetition, the present embodiment will not be described again.

[0175] The embodiments of the present application further provide an electronic device, which includes a processor, a memory and a program stored in the memory and executable on the processor. The program is executed by the processor to implement various processes of the service registration method embodiments and achieve the same technical effects. To avoid repetition, this will not be described again.

[0176] The embodiment of the present application further provides a computer readable storage medium, and the computer readable storage medium stores a computer program. The computer program is executed by a processor to realize each process of the service registration method embodiment and achieve the same technical effects. To avoid repetition, details are not described herein. The computer readable storage medium includes a read-only memory (ROM), a random access memory (RAM), a magnetic disk, an optical disk, and the like.

[0177] The embodiment of the present application further provides a computer program product, which includes computer instructions. The computer instructions are executed by a processor to realize each process of the service registration method embodiment and achieve the same technical effects. To avoid repetition, details are not described herein.

[0178] It should be noted that, in this document, the term "comprising" or "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that processes, methods, articles, or devices including a series of elements not only include those elements, but also include other elements not explicitly listed, or further include elements inherent in such processes, methods, articles, or devices. Without more limitations, the element defined by the statement "including a" does not exclude the presence of additional identical elements in the process, method, article, or device including the element.

[0179] From the above description of the embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be realized by means of software and necessary general hardware platforms, and of course, they can also be realized by hardware, but in many cases, the former is a better embodiment. Based on this understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as a ROM / RAM, a magnetic disk, an optical disk), and includes a plurality of instructions for making a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) execute the methods described in each embodiment of the present application.

[0180] The embodiments of the present application are described above in combination with the drawings, but the present application is not limited to the above-mentioned specific embodiments, and the above-mentioned specific embodiments are only illustrative, not restrictive. Those skilled in the art can make many forms under the inspiration of the present application without departing from the scope of the present application and the protection scope of the claims.

[0181] It should be noted that the present application can be applied to a conventional base station device based on a dedicated server, to realize modular decoupling and independent upgrading of internal functions, and can also be applied to a 5G cloud base station based on a general server, to give full play to the advantages of virtualization and containerization technology, to realize elastic scaling, rapid deployment and efficient resource scheduling of Xn services.

Claims

1. A service registration method, characterized in that, Applied to network-side devices, the method includes: If the first timer expires, a first registration request message is sent to the first service of the network-side device. The first registration request message is used to request the first service to register the first Xn service. Receive the first registration reply information sent by the first service, the first registration reply information being used to instruct the first service to complete the registration of the first Xn service; Upon receiving the first registration reply information and the second timer expires, a second registration request information is sent to the control platform. The second registration request information includes the configuration information of the first Xn service. The system receives a second registration response message sent by the control platform, which instructs the control platform to complete the registration of the first Xn service.

2. The method according to claim 1, characterized in that, The method further includes: Receive first synchronization information sent by the first service, wherein the first synchronization information is used to indicate the configuration information of the activated cell; Set the first information synchronization status to synchronized. The first information synchronization status is used to indicate the synchronization status between the first Xn service and the first service.

3. The method according to claim 1, characterized in that, The method further includes: Receive service routing indication information sent by the control platform, the service routing indication information including routing information corresponding to at least one newly registered second Xn service and / or at least one newly deregistered third Xn service; The routing information table is updated based on the service routing indication information.

4. The method according to claim 3, characterized in that, The updating of the routing information table based on the service routing indication information includes at least one of the following: If the routing information of the at least one second Xn service is not stored in the routing information table, the routing information of the at least one second Xn service shall be added to the routing information table. Delete the routing information of the at least one third Xn service from the routing information table; The method further includes at least one of the following: Add the configuration information of at least one second Xn service to the neighboring Xn service information table; Delete the configuration information of at least one third Xn service from the neighboring Xn service information table.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: Receive a first release instruction message sent by the control platform, the first release instruction message being used to instruct the first Xn service to request registration; Based on the first release instruction information, generate a deregistration request information; Send the deregistration request information to the control platform; The system receives a deregistration request response from the control platform, the response being used to instruct the first Xn service to complete the deregistration process. Based on the deregistration request response information, a second release instruction information is generated, which is used to instruct the first Xn service to complete the deregistration; The second release instruction information is sent to the first service, and the first service is used to release the configuration information of the neighbor Xn service information table maintained by the first service based on the second release instruction information.

6. The method according to any one of claims 1 to 4, characterized in that, Before sending the first registration request information to the first service of the network-side device, the method further includes: The initialization process of the first Xn service is initiated, which includes a version acquisition process, a main module initialization process, a working module initialization process, and an information processing function initialization process. The version acquisition process is used to acquire relevant information of the first Xn service; the main module initialization process is used to initialize the function providing object, function and global information table of the first Xn service; the working module initialization process is used to start the first timer; and the information processing function initialization process is used to initialize the receiving information queue.

7. A network-side device, characterized in that, include: The first sending module is configured to send a first registration request message to the first service of the network-side device when the first timer expires, wherein the first registration request message is used to request the first service to register the first Xn service; The first receiving module is configured to receive the first registration reply information sent by the first service, wherein the first registration reply information is used to instruct the first service to complete the registration of the first Xn service; The second sending module is used to send a second registration request to the control platform when the first registration reply information is received and the second timer expires. The second registration request includes the configuration information of the first Xn service. The second receiving module is used to receive the second registration reply information sent by the control platform, the second registration reply information being used to instruct the control platform to complete the first Xn service registration.

8. An electronic device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the service registration method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the service registration method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the steps of the service registration method as described in any one of claims 1 to 6.

Images