WO2023030945A2

WO2023030945A2 - Data synchronization between active and standby nodes for service continuity

Info

Publication number: WO2023030945A2
Application number: PCT/EP2022/073312
Authority: WO
Inventors: Subramanya CHANDRASHEKAR; Ömer BULAKCI; Ethiraj Alwar
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2021-09-06
Filing date: 2022-08-22
Publication date: 2023-03-09
Also published as: CN117917116A; WO2023030945A3

Abstract

A method comprising, transmitting, from an access network element in a first state, a setup request for requesting setup of a communication path between the access network element in the first state and an access network element in a second state; receiving a setup response; and, based thereon, establishing the communication path between the access network element in the first state and the access network element in the second state.

Description

DATA SYNCHRONIZATION BETWEEN ACTIVE AND STANDBY NODES FOR SERVICE CONTINUITY

DESCRIPTION

Technical Field

The present disclosure relates to a method and an apparatus for data synchronization between active and standby nodes for service continuity.

Background Art

The following description of background art may include insights, discoveries, understandings or disclosures, or associations, together with disclosures not known to the relevant prior art, to at least some examples of embodiments of the present disclosure but provided by the disclosure. Some of such contributions of the disclosure may be specifically pointed out below, whereas other of such contributions of the disclosure will be apparent from the related context.

In the last years, an increasing extension of communication networks, e.g. of wire based communication networks, such as the Integrated Services Digital Network (ISDN), Digital Subscriber Line (DSL), or wireless communication networks, such as the cdma2000 (code division multiple access) system, cellular 3^rd generation (3G) like the Universal Mobile Telecommunications System (UMTS), fourth generation (4G) communication networks or enhanced communication networks based e.g. on Long Term Evolution (LTE) or Long Term Evolution-Advanced (LTE-A), fifth generation (5G) communication networks, cellular 2^nd generation (2G) communication networks like the Global System for Mobile communications (GSM), the General Packet Radio System (GPRS), the Enhanced Data Rates for Global Evolution (EDGE), or other wireless communication system, such as the Wireless Local Area Network (WLAN), Bluetooth or Worldwide Interoperability for Microwave Access (WiMAX), took place all over the world. Various organizations, such as the European Telecommunications Standards Institute (ETSI), the 3^rd Generation Partnership Project (3GPP), Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN), the International Telecommunication Union (ITU), 3^rd Generation Partnership Project 2 (3GPP2), Internet Engineering Task Force (IETF), the IEEE (Institute of Electrical and Electronics Engineers), the WiMAX Forum and the like are working on standards or specifications for telecommunication network and access environments.

In such context, data synchronization for service continuity is of growing relevance. In this regard, geo-redundant resiliency of a Next Generation Node B (gNB) is of high importance.

With reference to Figure 1 , there is shown a Radio Access Network (RAN) architecture with internal interfaces associated to a gNB 100. Accordingly, a disaggregated gNB architecture is defined with a 1 :M (1 to M) relation. Thus, a gNB-Distributed Unit (gNB- DU) 110, 120 is connected to only one gNB-Central Unit-Control Plane (gNB-CU-CP) 130 via an F1-C interface. Further, a gNB-Central Unit-User Plane (gNB-CU-UP) 140 is connected to only one gNB-CU-CP 130 via an E1 interface. Hence, resiliency of a gNB-CU- CP 130 is extremely crucial to provide service continuity and avoid downtime and it is allowed by 3GPP without indication on how to achieve it. For instance, it is cited in [TS 38.401]: “NOTE 1: For resiliency, a gNB-DU and/or a gNB-CU-UP may be connected to multiple gNB-CU-CPs by appropriate implementation".

After failure of an active gNB-CU-CP, an establishment of a new F1 interface from scratch would lead to a mass user equipment (UE) release and a large downtime before the system is back. However, establishment of more than one F1 “active” connection poses several other problems, like for example violation of RAN3 cardinality rule. Another problem may represent a radio resource management (RRM) by multiple gNB-CU-CPs, leading to fragmentation of resources. Further, there may be a problem of new co-ordination overhead between gNB-CU-CPs.

It is therefore an object of the present disclosure to improve the prior art.

The following meanings for the abbreviations used in this specification apply:

2G Second Generation

3G Third Generation

3GPP 3^rd Generation Partnership Project

3GGP2 3^rd Generation Partnership Project 2

4G Fourth Generation 5G Fifth Generation 5GC 5G Core 6G Sixth Generation AMF Access and Mobility Management Function AN Access Node AP Access Point API Application Programming Interface BS Base Station CDMA Code Division Multiple Access CM Connection Management CN-RNTI Core Network-Radio Network Temporary Identification CP Control Plane CU Central Unit DSL Digital Subscriber Line EDGE Enhanced Data Rates for Global Evolution EEPROM Electrically Erasable Programmable Read-only Memory eNB Evolved Node B gNB-CU-CP gNB-Central Unit-Control Plane gNB-CU-UP gNB-Central Unit-User Plane gNB-DU gNB-Distributed Unit ETSI European Telecommunications Standards Institute gNB Next Generation Node B GPRS General Packet Radio System GSM Global System for Mobile communications GUTI Global Unique Temporary Identifier IE Information Element

IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IPSEC IP Security ISDN Integrated Services Digital Network ITU International Telecommunication Union LTE Long Term Evolution LTE-A Long Term Evolution-Advanced MANETs Mobile Ad-Hoc Networks MDAF Management Data Analytics Function NAS Non-access Stratum NB Node B

NGAP Next Generation Application Protocol

NG-C NG control plane interface

NWDAF Network Data Analytics Function

GAM Operations, Administration and Management

ORAN Open RAN

P2P Peer to peer

PDCP Packet Data Convergence Protocol

RA-RNTI Radio Access - Radio Network Temporary Identification

RAM Random Access Memory

RAN Radio Access Network

RIC RAN Intelligent Controller

RM Registration Management

ROM Read Only Memory

RRC Radio Resource Management

SBI Service Based Interface

SCTP Stream Control Transmission Protocol

SLA Slice Requirement

TISPAN Telecoms & Internet converged Services & Protocols for Advanced Networks

TMSI Temporary Mobile Subscriber Identities

TNL Transport Network Layer

UE User Equipment

UMTS Universal Mobile Telecommunications System

UWB Ultra- Wideband

WCDMA Wideband Code Division Multiple Access

WiMAX Worldwide Interoperability for Microwave Access

WLAN Wireless Local Area Network

SUMMARY

It is an objective of various examples of embodiments of the present disclosure to improve the prior art. Hence, at least some examples of embodiments of the present disclosure aim at addressing at least part of the above issues and/or problems and drawbacks. Various aspects of examples of embodiments of the present disclosure are set out in the appended claims and relate to methods, apparatuses and computer program products relating to data synchronization between active and standby nodes for service continuity.

The objective is achieved by the methods, apparatuses and non-transitory storage media as specified in the appended claims. Advantageous further developments are set out in respective dependent claims.

Any one of the aspects mentioned according to the appended claims enables data synchronization between active and standby nodes for service continuity, thereby allowing to solve at least part of the problems and drawbacks as identified/derivable from above.

Thus, improvement is achieved by methods, apparatuses and computer program products enabling data synchronization between active and standby nodes for service continuity.

Various embodiments and examples presented herein have the following example advantages. For example, a multi-vendor standby-node would increase the diversity of the resiliency solution scope, since multi-vendor stand-by node cannot work with proprietary data synchronization solutions. Additionally, resiliency for a gNB representing an active node (i.e. node in active mode) for a mobile terminal like e.g. a user equipment (UE) may be supported using multiple stand-by nodes (i.e. nodes in standby mode), wherein (at least one of) the multiple stand-by nodes may be an active node (i.e. node in active mode) for at least one other mobile terminal. This implies that a standby node may be in a different IP network and non-collocated with the active node. This scenario can be preferred for geo- redundant resiliency cases. Accordingly, the standby-nodes may belong to a different vendor, particularly relevant for operators that apply geographical split among vendors. Moreover, a standard interface may enable security of synchronization data using Stream Control Transmission Protocol (SCTP) and IP Security (IPSEC), for which alternatives have to be designed in a proprietary solution, especially when active and standby nodes are in different IP networks.

Further advantages become apparent from the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments of the present disclosure are described below, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 shows a RAN architecture with internal interfaces;

Figure 2 shows a setup of INACTIVE Xn for data synchronization according to various examples of embodiments;

Figure 3 shows data synchronization with standby CLI-CP according to various examples of embodiments;

Figure 4 shows a flowchart illustrating steps corresponding to a method executable by an access network element in a first state according to various examples of embodiments;

Figure 5 shows a flowchart illustrating steps corresponding to a method executable by an access network element in a second state according to various examples of embodiments;

Figure 6 shows a flowchart illustrating steps corresponding to a method executable by a network management entity or function according to various examples of embodiments;

Figure 7 shows a flowchart illustrating steps corresponding to a method executable by a network management entity or function according to various examples of embodiments;

Figure 8 shows a block diagram illustrating an apparatus in a first state according to various examples of embodiments;

Figure 9 shows a block diagram illustrating an apparatus in a second state according to various examples of embodiments; Figure 10 shows a block diagram illustrating an apparatus according to various examples of embodiments; and

Figure 11 shows a block diagram illustrating an apparatus according to various examples of embodiments.

DESCRIPTION OF EMBODIMENTS

Basically, for properly establishing and handling a communication between two or more end points (e.g. communication stations or elements or functions, such as terminal devices, user equipments (UEs), or other communication network elements, a database, a server, host etc.), one or more network elements or functions (e.g. virtualized network functions), such as communication network control elements or functions, for example access network elements like access points (APs), radio base stations (BSs), relay stations, eNBs, gNBs etc., and core network elements or functions, for example control nodes, support nodes, service nodes, gateways, user plane functions, access and mobility functions etc., may be involved, which may belong to one communication network system or different communication network systems.

In the following, different exemplifying embodiments will be described using, as an example of a communication network to which examples of embodiments may be applied, a communication network architecture based on 3GPP standards for a communication network, such as a 5G/NR, without restricting the embodiments to such an architecture, however. It is obvious for a person skilled in the art that the embodiments may also be applied to other kinds of communication networks like 4G and/or LTE (and beyond 5G, e.g., 6G) where mobile communication principles are integrated, e.g. Wi-Fi, worldwide interoperability for microwave access (WiMAX), Bluetooth®, personal communications services (PCS), ZigBee®, wideband code division multiple access (WCDMA), systems using ultra-wideband (UWB) technology, mobile ad-hoc networks (MANETs), wired access, etc.. Furthermore, without loss of generality, the description of some examples of embodiments is related to a mobile communication network, but principles of the disclosure can be extended and applied to any other type of communication network, such as a wired communication network or datacenter networking.

The following examples and embodiments are to be understood only as illustrative examples. Although the specification may refer to “an”, “one”, or “some” example(s) or embodiment(s) in several locations, this does not necessarily mean that each such reference is related to the same example(s) or embodiment(s), or that the feature only applies to a single example or embodiment. Single features of different embodiments may also be combined to provide other embodiments. Furthermore, terms like “comprising” and “including” should be understood as not limiting the described embodiments to consist of only those features that have been mentioned; such examples and embodiments may also contain features, structures, units, modules etc. that have not been specifically mentioned.

A basic system architecture of a (tele)communication network including a mobile communication system where some examples of embodiments are applicable may include an architecture of one or more communication networks including wireless access network subsystem(s) and core network(s). Such an architecture may include one or more communication network control elements or functions, access network elements, radio access network elements, access service network gateways or base transceiver stations, such as a base station (BS), an access point (AP), a NodeB (NB), an eNB or a gNB, a distributed or a centralized unit (CU), which controls a respective coverage area or cell(s) and with which one or more communication stations such as communication elements or functions, like user devices (e.g. customer devices), mobile devices, or terminal devices, like a UE, or another device having a similar function, such as a modem chipset, a chip, a module etc., which can also be part of a station, an element, a function or an application capable of conducting a communication, such as a UE, an element or function usable in a machine-to-machine communication architecture, or attached as a separate element to such an element, function or application capable of conducting a communication, or the like, are capable to communicate via one or more channels via one or more communication beams for transmitting several types of data in a plurality of access domains. Furthermore, (core) network elements or network functions ((core) network control elements or network functions, (core) network management elements or network functions), such as gateway network elements/functions, mobility management entities, a mobile switching center, servers, databases and the like may be included.

The general functions and interconnections of the described elements and functions, which also depend on the actual network type, are known to those skilled in the art and described in corresponding specifications, so that a detailed description thereof is omitted herein. However, it is to be noted that several additional network elements and signaling links may be employed for a communication to or from an element, function or application, like a communication endpoint, a communication network control element, such as a server, a gateway, a radio network controller, and other elements of the same or other communication networks besides those described in detail herein below.

A communication network architecture as being considered in examples of embodiments may also be able to communicate with other networks, such as a public switched telephone network or the Internet. The communication network may also be able to support the usage of cloud services for virtual network elements or functions thereof, wherein it is to be noted that the virtual network part of the telecommunication network can also be provided by non-cloud resources, e.g. an internal network or the like. It should be appreciated that network elements of an access system, of a core network etc., and/or respective functionalities may be implemented by using any node, host, server, access node or entity etc. being suitable for such a usage. Generally, a network function can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

Furthermore, a network element, such as communication elements, like a UE, a mobile device, a terminal device, control elements or functions, such as access network elements, like a base station (BS), an eNB/gNB, a radio network controller, a core network control element or function, such as a gateway element, or other network elements or functions, as described herein, (core) network management element or function and any other elements, functions or applications may be implemented by software, e.g. by a computer program product for a computer, and/or by hardware. For executing their respective processing, correspondingly used devices, nodes, functions or network elements may include several means, modules, units, components, etc. (not shown) which are required for control, processing and/or communication/signaling functionality. Such means, modules, units and components may include, for example, one or more processors or processor units including one or more processing portions for executing instructions and/or programs and/or for processing data, storage or memory units or means for storing instructions, programs and/or data, for serving as a work area of the processor or processing portion and the like (e.g. ROM, RAM, EEPROM, and the like), input or interface means for inputting data and instructions by software (e.g. floppy disc, CD-ROM, EEPROM, and the like), a user interface for providing monitor and manipulation possibilities to a user (e.g. a screen, a keyboard and the like), other interface or means for establishing links and/or connections under the control of the processor unit or portion (e.g. wired and wireless interface means, radio interface means including e.g. an antenna unit or the like, means for forming a radio communication part etc.) and the like, wherein respective means forming an interface, such as a radio communication part, can be also located on a remote site (e.g. a radio head or a radio station etc.). It is to be noted that in the present specification processing portions should not be only considered to represent physical portions of one or more processors, but may also be considered as a logical division of the referred processing tasks performed by one or more processors.

It should be appreciated that according to some examples, a so-called “liquid” or flexible network concept may be employed where the operations and functionalities of a network element, a network function, or of another entity of the network, may be performed in different entities or functions, such as in a node, host or server, in a flexible manner. In other words, a “division of labor” between involved network elements, functions or entities may vary case by case.

According to at least some examples of embodiments, "Data Synchronization” can be defined as that procedure which synchronizes all configuration and session data between active and standby nodes and enables service continuity after switchover due to an active node failure.

Further, data synchronization between an active CU (e.g., with reference to the gNB 100 according to Figure 1 , an active gNB-CU-CP 130 and/or (one out of a plurality of) active gNB-CU-UP 140 (i.e. in active mode) for at least one mobile device) and a standby CU or standby CU set (e.g., with reference to the gNB 100 according to Figure 1 , a standby gNB- CU-CP 130 and/or (one out of a plurality of) standby gNB-CU-UP 140 (i.e. in standby mode) for at least one active CU) is essential for the geo-redundancy solutions. It shall be noted that the active CU and the standby CU may be associated to the same gNB 100, but may also be associated to different gNBs. The crux of the present specification is to propose a geo-redundant solution for data synchronization. At least some examples of embodiments are outlined in the following.

Hence, according to various examples of embodiments, Xn-C is established between an active gNB-CU-CP and a standby gNB-CU-CP, regardless of whether they belong to the same gNB. This proposed communication interface is called INACTIVE Xn connection. The Inactive Xn interface may be configured by Operations, Administration and Management (OAM) and initiated by the active gNB-CU-CP. New procedures are proposed over INACTIVE Xn (Xn for Data Synchronization) to address data synchronization aspects. Data synchronization could be performed per slice or per UE or a group of UEs.

It may be noted that network slicing forms so-called slices (i.e. communication capabilities or communication functions) which allow a network operator to provide dedicated (virtual) networks with functionality specific to a service or customer over a common network infrastructure.

Alternatively, data synchronization can also be performed via Access and Mobility Management Function (AMF), e.g. when Xn cannot be established or not available. In this case, AMF can transparently transfer the data received from the active gNB-CU-CP toward the standby gNB-CU-CP. For example, a procedure similar to configuration transfer can be utilized. In the case where there is no Xn Link, this functionality can be enabled/disabled by AMF in the active and standby nodes as part of the NG Setup Procedure. Further, the address of the target standby gNB-CU-CP is required, e.g., Global RAN Node ID and its IP address. The address(es) of the target standby gNB-CU-CP(s) or the target standby gNB- CU-CP set can be pre-configured by GAM. According to at least some examples of embodiments, the communication between the active gNB-CU-CP and the standby gNB- CU-CP could be handled over INACTIVE NG interface and/or a dedicated container.

Moreover, according to various examples of embodiments, Transport Network Layer (TNL) discovery procedure via serving AMF could include discovery of standby gNB-CU- CP. This is to support standby gNB-CU-CP address discovery by explicitly indicating INACTIVE Xn, in case the standby gNB-CU-CP is assigned dynamically.

Moreover, according to at least some examples of embodiments, data to be synchronized have to be determined and/or identified and/or selected. Such determination and/or identification and/or selection may be performed by e.g. the active gNB-CU-CP and/or the AMF and/or any further network management entity or function.

Such data to be synchronized may comprise at least one of the following: UE context information and configuration data from GAM. The UE context information may comprise at least one of the following information: UE state information indicating a UE’s state, like e.g. active state or standby state, session and bearer information indicating a session and/or bearer associated to a UE, any historic network generated intelligence based on AI-ML algorithms, and a Packet Data Convergence Protocol context information including ciphering keys etc. (wherein if the active and standby gNB-CU-CPs are not in a same security domain, it will be an issue. Hence, synchronization of the entire PDCP context along with security keys may be preferred). The configuration data from OAM may comprise operator configured parameters and their values.

Furthermore, according to various examples of embodiments, synchronization points (i.e. time instants where all the data need to be synchronized) have to be determined and/or identified and/or selected. Such determination and/or identification and/or configuration may be performed by e.g. the active gNB-CU-CP and/or the AMF and/or any further network management entity or function.

Such synchronization points may represent only UE contexts that underwent change from the last synchronization. This could be remembered by using a FLAG to mark this in the UE context. Alternatively and/or additionally, such synchronization points may represent only UE contexts having stable state changes since the previous synchronization. This could also be remembered by using a FLAG to mark this in the UE context. Such stable state may be any of the following: RRC state change (IDLE, CONNECTED, INACTIVE), security key change, any procedure completion over Next Generation Application Protocol (NGAP), or any procedure completion over RRC. Further, such synchronization points may represent periodically synchronization data.

Furthermore, according to various examples of embodiments, data clean-up may be required/preferred. For examples, an active gNB-CU-CP may indicate via a FLAG when a UE context is released (due to e.g. a handover or moved to IDLE) and synchronization-data needs to be removed in a standby gNB-CU-CP as well.

Furthermore, according to at least some examples of embodiments, a selection of UE/slice/service/gNB and/or slice/service group for data synchronization could be based on an indication from AMF to NG-RAN node or operator configured. Alternatively and/or additionally, depending on the slice requirements (SLAs) and/or service requirements, the data synchronization may be applied to certain slices/services and/or slice/service groups. The periodicity (for performing data synchronization) may also depend on such slice/service requirements. Further alternatively and/or additionally, fault detection mechanisms, e.g., located in a gNB-CU, OAM, or Open-RAN RAN Intelligent Controller (O-RAN RIC), can trigger and determine the periodicity of the data synchronization. For instance, in case of a higher likelihood of fault, the data synchronization may be performed more frequently, and the extent of the synchronized data may be larger.

With reference to Figure 2, Figure 2 shows in a signaling diagram a setup of INACTIVE Xn for data synchronization according to various examples of embodiments. The signaling diagram is representative of the data synchronization procedures as outlined above in detail.

Accordingly, an activation of an Inactive Xn interface can be triggered by AMF 210, CAM, or ORAN RIC. This can be determined by the analytics functions, e.g., network data analytics function (NWDAF) in 5GC and/or Management Data Analytics Function (MDAF) in OAM and/or RAN data analytics function

Furthermore, according to at least some examples of embodiments, conditions to trigger data synchronization may be pre-configured in the (active) gNB-Cll 220, which may e.g. rely on the own fault-detection mechanisms. Such mechanisms may be implemented in gNB-DUs, as well. Data synchronization may also be triggered based on natural disaster information from AMF 210, e.g., via NGAP Write Replace Warning Request message.

According to at least some examples of embodiments, referring to Figure 2 in more detail, the active gNB-Cll 220 may issues, in step S201 , a NG Setup Request to the AMF 210. Such request may comprise, that the AMF 210 is requested to establish a communication path (via the AMF 210) to a standby gNB-Cll 230. Alternatively and/or additionally, such request may comprise, that the AMF 210 is requested to provide at least one address of a respective standby gNB-Cll. Accordingly, the AMF 210 may issue, in step S202, a NG Setup Response, which may indicate at least one of different data synchronization mechanisms to be applied. Such response may comprise synchronization control information, which may be indicative of data relevant for AMF 210 to be synchronized and of at least one synchronization control parameter, like e.g. the address of the standby gNB-Cll 230. Alternatively and/or additionally, such synchronization control information may comprise slice resiliency information, e.g. indicating for which slice a data synchronization has to be performed.

In step S230, e.g. based on the information obtained from the AMF 210 in step S202, the active gNB-Cll 220 may issue a Xn Setup Request (INACTIVE) to the standby gNB-Cll 230 in relation to a data synchronization, which needs to be performed/which is scheduled/intended to be performed. Accordingly, the active gNB-Cll 220 may request (thereby e.g. initiating) to the standby gNB-Cll 230 that a direct communication path (the address of which may be preconfigured) between the active gNB-Cll 220 and the standby gNB-Cll 230 may be established. Based on a response of the standby gNB-Cll 230 as issues, in step S204, with the Xn Setup Response, the standby gNB-Cll 230 may participate in establishing/may accept the direct communication path. As result, the direct communication may be established and data synchronization may be performed between the active gNB-Cll 220 and the standby gNB-Cll 230 via such direct communication path.

It shall further be noted that, actually, for address discovery, a different procedure is used over NG (not NG setup). Here, it is indicated NG Setup just to provide any specific input regarding slice resiliency information (if any) from the AMF 210. For example, the AMF 210 may indicate whether there are any specific slices that need data synchronization and those slices that do not need data synchronization.

With reference to Figure 3, Figure 3 shows data synchronization with a standby CU- CP according to various examples of embodiments. The signaling diagram is representative of the data synchronization procedures as outlined above in detail.

As mentioned before, different data synchronization mechanisms (that may e.g. be indicated by the AMF 210 in the NG Setup Response as outlined above in relation to Figure 2) can be applied. For mission-critical services/slices, the data synchronization may be event based, where any significant update to the UE context can trigger a data synchronization. For less critical slices, the data synchronization may be performed once a certain number of events have occurred, e.g., a threshold in terms of the number of UEs.

According to at least some examples of embodiments, RAN node related configuration updates, e.g., an AMF configuration update or an GAM configuration update, may also trigger the data synchronization.

According to at least some examples of embodiments, referring to Figure 3 in more detail, two UEs, UE1 320 and UE2 310, are illustrated, wherein UE1 320 in step S331 is in an idle state in relation to an active gNB-CU 220 and wherein UE2 310 in step S333 is in a connected state in relation to the active gNB-CU 220. In relation to both UEs, UE1 320 and UE2 310, a standby gNB-CU 230 is to be understood to be in a standby state. Further, both UEs, UE1 320 and UE2 310, may be understood be independent from each other. In this regard, in step S331 , UE1 320 issues a RRC Setup Request to the active gNB-Cll 220 to request a RRC setup. In response thereto, in step S334, the active gNB- Cll 220 issues a RRC Setup to the UE1 320 and the UE1 320, in S335, moves from the idle state to a connected state.

Regarding UE2 310, the active gNB-Cll 220 issues in step S336 a RRC Release to the UE2 310 and the UE2 310, in step S337, moves from the connected state to an idle state.

In step S338, the active gNB-Cll 220 handles the state changes with regard to UE1 320 and UE2 310. In particular, UE1 320 is added to a network slice provided by the active gNB-Cll 220, e.g. “Slice A”. UE2 is removed from a network slice provided by the active gNB-Cll 220. Thus, resiliency with regard to UE1 310 is enabled. Each one of such two state changes as handled in step S338 may represent event, which leads to/which triggers an event-based data synchronization.

Therefore, in step S339, the active gNB-Cll 220 issues (for data synchronization purposes) an Xn: Data Synchronization Indication in relation to UE1 320 and to UE2 310 to the standby gNB-Cll 230. In response thereto, the standby gNB-Cll 230 issues, in step S340, an Xn: Data Synchronization Acknowledgement to acknowledge data synchronization for UE1 320 and for UE2 310 to the active gNB-Cll 220.

Alternatively and/or additionally, the data synchronization may be a periodic data synchronization as illustrated in step S341. Accordingly, the active gNB-Cll 220 issues, in step S342, an Xn: Data Synchronization Indication in relation to OAM data to the standby gNB-Cll 230. In response thereto, the standby gNB-Cll 230 issues, in step S343, an Xn: Data Synchronization Acknowledgement to acknowledge data synchronization to the active gNB-CU 220.

In the following, further examples of embodiments are described in relation to the above described methods and/or apparatuses.

Referring now to Figure 4, there is shown a flowchart illustrating steps corresponding to a method executable by an access network element in a first state according to various examples of embodiments. Such network entity or function in a first state may represent such active gNB-Cll 220, wherein the first state represents the active state, as outlined above with reference to Figures 1 to 3.

In particular, according to Figure 4, in S410, the method comprises transmitting, from the access network element in the first state, a setup request for requesting setup of a communication path between the access network element in the first state and an access network element in a second state.

It shall be noted that the access network element in a second state may represent such standby gNB-Cll 230, wherein the second state represents the standby state, as outlined above with reference to Figures 1 to 3.

Further, in S420, the method comprises receiving a setup response. In S430, the method comprises establishing the communication path between the access network element in the first state and the access network element in the second state.

Moreover, according to at least some examples of embodiments, the communication path may be a direct communication path and a preconfigured communication interface between the access network element in the first state and the access network element in the second state. In addition, the transmitting may comprise initiating the preconfigured communication interface by transmitting the setup request to the access network element in the second state. Further, the establishing may comprise establishing the preconfigured communication interface based on the setup response received from the access network element in the second state.

It shall be noted that such preconfigured communication interface may represent such INACTIVE Xn connection as outlined above in detail. In this regard, the setup request may represent such Xn Setup Request (INACTIVE) as outlined above with reference to Figures 2 (see e.g. step S203) and 3, wherein the setup response may represent such Xn Setup Response as outlined above with reference to Figures 2 (see e.g. step S204) and 3.

Furthermore, according to various examples of embodiments, the method may further comprise obtaining address information from a network management entity or function, indicative of at least an address of the access network element in the second state; and transmitting the setup request to the access network element in the second state based on the address. It shall be noted that the network management entity or function may represent such AMF 210 or OAM as outlined above with reference to Figures 2 and 3.

Additionally, according to various examples of embodiments, wherein the communication path between the access network element in the first state and the access network element in the second state may include a network management entity or function. In addition, the transmitting may comprise transmitting the setup request to the network management entity or function for requesting setup of the communication path between the access network element in the first state and the access network element in the second state; and wherein the establishing may comprise establishing the communication path based on the setup response received from the network management entity or function.

It shall be noted that such communication path including the network management entity or function may represent such communication path via the AMF 210 (or OAM) as outlined above in detail.

Optionally, according to at least some examples of embodiments at least one mobile terminal may be associated to the access network element in the first state having a respective mobile terminal context. The method may further comprise signalling, from the access network element in the first state to the access network element in the second state, of at least synchronization control information indicative of data to be synchronized and of at least one synchronization control parameter. Additionally, the method may further comprise synchronizing data related to the at least one mobile terminal between the access network element in the first state and the access network element in the second state via the established communication path, based on the synchronization control information.

It shall be noted that the mobile terminal/the mobile terminal context may represent, in general, such UE 310, 320/such UE context as outlined above with reference to Figures 2 and 3.

Further, according to various examples of embodiments, wherein the synchronization control information may be indicative of a data content to be synchronized, and wherein the at least one synchronization control parameter is at least one of a frequency of a data synchronization and an indication whether the data synchronization is eventbased. It shall be noted that a non-limiting example for an event-based data synchronization may be represent in Figure 3, step S338 (see e.g. steps S331 to S337, illustrating a connected-idle-switch for a UE2 310 as well as an idle-connected-switch for UE1 320), wherein a non-limiting example for a periodic data synchronization may be represent in Figure 3, step S341.

Moreover, according to at least some examples of embodiments, wherein the data content may comprise at least the mobile terminal context of the at least one mobile terminal and/or access network element configuration data. The mobile terminal context may comprise at least one of mobile terminal state information indicative of a state of at least one mobile terminal associated to the access network element in the first state, session and/or bearer information related to at least one mobile terminal associated to the access network element in the first state, a Packet Data Convergence Protocol, PDCP, context, optionally further including security keys used to secure the PDCP context, and mobile terminal historical information and/or information generated based on artificial intelligence - machine learning algorithms. Further, the access network element configuration data may comprise at least configuration parameters and their values for configuring at least the access network element in the first state, the access network element configuration data being set by a network operator operating at least the access network element in the first state.

Furthermore, according to various examples of embodiments, the method may further comprise receiving, as an event-based synchronization control parameter, a data synchronization trigger from a network management entity or function; and performing the synchronizing based on the data synchronization trigger. Alternatively and/or additionally, the method may further comprise receiving, as an event-based synchronization control parameter, natural disaster information from the network management entity or function; and performing the synchronizing based on the natural disaster information. Optionally and/or additionally, the method may further comprise acquiring, as an event-based synchronization control parameter, preconfigured data synchronization trigger conditions; determining whether at least one of the preconfigured data synchronization trigger conditions is met; and performing the synchronizing based on a result of the determination. It shall be noted that such network management entity or function may represent e.g. such AMF 210 or such OAM (or another core network management entity or function) as outlined above with reference to Figures 2 and 3.

Additionally, according to various examples of embodiments, the method may further comprise performing the synchronizing per network slice provided by the access network element in the first state, and/or per mobile terminal associated to the access network element in the first state, and/or per group of mobile terminals associated to the access network element in the first state.

Optionally, according to at least some examples of embodiments, the at least one synchronization control parameter may be further indicative of at least synchronization points that represent time instants at which the synchronizing of target data is to be performed. The target data is a mobile terminal context that underwent a change since a previous synchronizing, or a mobile terminal context having stable state changes since the previous synchronizing, or periodically synchronized data.

Further, according to various examples of embodiments, the method may further comprise indicating that a mobile terminal context is released due to a handover of the mobile terminal away from the access network element in the first state and/or a transition of the mobile terminal to an idle state; and/or indicating that synchronization data is to be removed in the access network element in the second state.

It shall be noted that such indicating of a release and/or a removing may represent such Data Sync Indication as outlined above in detail with reference to Figure 3 (see e.g. steps S339 and S342).

Moreover, according to at least some examples of embodiments, the method may further comprise receiving selection information from a network management entity or function, wherein the selection information is indicative of at least one of the at least one mobile terminal associated to the access network element in the first state, at least one network slice provided by the access network element in the first state, at least one service provided by the access network element in the first state, and at least one target access network element in the second state including the access network element in the second state. The method may further comprise selecting for the synchronizing at least one of the at least one mobile terminal, network slice, service and access network element in the second state based on the selection information.

Furthermore, according to various examples of embodiments, wherein the at least one synchronization control parameter may further comprise predetermined network slice requirements and/or predetermined service requirements to be satisfied for at least one network slice and/or for at least one service provided by the access network element in the first state. The method may further comprise applying the synchronizing based on the predetermined network slice requirements and/or the predetermined service requirements; and/or determining a periodicity of the synchronizing based on the predetermined network slice requirements and/or the predetermined service requirements.

It shall be noted that the predetermined network slice requirements and/or predetermined service requirements to be satisfied for at least one network slice may be provided by such above-mentioned network management entity or function, like e.g. such AMF 210 (or such OAM) as outlined above with reference to Figures 2 and 3.

Additionally, according to various examples of embodiments, the method may further comprise acquiring a likelihood level of a fault to occur in a connection to a mobile terminal provided by the access network element in the first state; and, if the acquired likelihood level reaches a predetermined likelihood level threshold, modifying a synchronization control parameter by increasing a frequency of the synchronizing and/or by extending an amount of data to be synchronized.

The above-outlined solution allows for data synchronization between active and standby nodes for service continuity. Therefore, the above-outlined solution is advantageous in that it enables for efficient and/or secure and/or robust and/or failure resistant and/or flexible data synchronization between active and standby nodes for service continuity.

Referring now to Figure 5, Figure 5 shows a flowchart illustrating steps corresponding to a method executable by an access network element in a second state according to various examples of embodiments. Such network entity or function in a second state may represent such standby gNB-Cll 230, wherein the second state represents the standby state, as outlined above with reference to Figures 1 to 3. In particular, in S510, the method comprises receiving a setup request in relation to a setup of a communication path between an access network element in a first state and the access network element in the second state.

It shall be noted that the access network element in the first state may represent such active gNB-Cll 220, wherein the first state represents the active state, as outlined above with reference to Figures 1 to 3.

The method further comprises, in S520, transmitting in response to S510 a setup response in relation to the setup of the communication path; and, based thereon, in S530, participating in establishing the communication path between the access network element in the first state and the access network element in the second state.

Moreover, according to at least some examples of embodiments, wherein the communication path may be a direct communication path and a preconfigured communication interface between the access network element in the second state and the access network element in the first state; and wherein the receiving may comprise receiving the setup request from the access network element in the first state; and wherein the transmitting may comprise transmitting the setup response to the access network element in the first state.

Furthermore, according to various examples of embodiments, wherein the communication path between the access network element in the first state and the access network element in the second state may include a network management entity or function; and wherein the receiving may comprise receiving the setup request from the network management entity or function; and wherein the transmitting may comprise transmitting the setup response to the network management entity or function. It shall be noted that such communication path including the network management entity or function may represent such communication path via the AMF 210 (or OAM) as outlined above in detail.

Additionally, according to various examples of embodiments, the method may further comprise receiving a signalling, from the access network element in the first state, of at least synchronization control information indicative of data to be synchronized and of at least one synchronization control parameter; and participating in synchronizing data between the access network element in the first state and the access network element in the second state via the established communication path, based on the synchronization control information.

Optionally, according to at least some examples of embodiments, the method may further comprise receiving a release indication from the access network element in the first state, indicative of a mobile terminal context to be released; and, based thereon, releasing the mobile terminal context; and/or receiving a removing indication from the access network element in the first state, indicative of synchronization data to be removed; and, based thereon, removing the synchronization data.

It shall be noted that such release indication and/or removing indication may represent such Data Sync Indication as outlined above in detail with reference to Figure 3 (see e.g. steps S339 and S342).

Referring now to Figure 6, Figure 6 shows a flowchart illustrating steps corresponding to a method executable by a network management entity or function according to various examples of embodiments. Such network management entity or function may represent such AMF 210 or OAM as outlined above with reference to Figures 1 to 3. In particular, in S610, the method comprises receiving a first setup request from an access network element in a first state in relation to a setup of a communication path between the access network element in the first state and an access network element in a second state.

It shall be noted that the access network element in the first state may represent such active gNB-Cll 220, wherein the first state represents the active state, as outlined above with reference to Figures 1 to 3. Further, the access network element in the second state may represent such standby gNB-Cll 230, wherein the second state represents the standby state, as outlined above with reference to Figures 1 to 3.

The method further comprises, in S620, based on S610, transmitting a second setup request in relation to the setup of the communication path to the access network element in the second state. The method further comprises, in S630, based on S620, receiving a first setup response from the access network element in the second state. The method further comprises, in S640, based on S630, transmitting a second setup response to the access network element in the first state; and the method further comprises, in S650, based on S640, participating in establishing the communication path between the access network element in the first state and the access network element in the second state.

Further, according to various examples of embodiments, the method may further comprise transparently transferring synchronization data received from the access network element in the first state to the access network element in the second state.

Optionally, according to at least some examples of embodiments, the method may further comprise acquiring at least one preconfigured address of at least one target access network element in the second state for the setup of the communication path; and selecting one of the at least one target access network element in the second state for transmitting the second setup request.

Referring now to Figure 7, Figure 7 shows a flowchart illustrating steps corresponding to a method executable by a network management entity or function according to various examples of embodiments. Such network management entity or function may represent such AMF 210 as outlined above with reference to Figures 1 to 3. In particular, in S710, the method comprises acquiring at least one preconfigured address of a respective access network element in a second state for setup of a communication path between an access network element in a first state and the access network element in the second state.

The method further comprises, in S720, based on S710, generating address information indicative of the at least one preconfigured address, and, in S730, based on S720, transmitting the address information to the access network element in the first state.

Further, with reference to the methods according to Figures 6 and 7, according to various examples of embodiments, the methods may further comprise obtaining a data synchronization trigger; and transmitting the data synchronization trigger to the access network element in the first state to trigger data synchronization between the access network element in the first state and the access network element in the second state. Alternatively and/or additionally, the methods may comprise obtaining natural disaster information; and transmitting the natural disaster information to the access network element in the first state to trigger data synchronization between the access network element in the first state and the access network element in the second state. In one aspect, the natural disaster information may be provided to the access network element in the first state by the above-mentioned network management entity or function, like e.g. such AMF 210 as outlined above with reference to Figures 2 and 3.

Moreover, according to at least some examples of embodiments, the methods may further comprise, in relation to a data synchronization between the access network element in the first state and the access network element in the second state, acquiring and providing selection information to the access network element in the first state. The selection information may be indicative of at least one of at least one mobile terminal associated to the access network element in the first state, at least one network slice provided by the access network element in the first state, at least one service provided by the access network element in the first state, and at least one target access network element in the second state including the access network element in the second state.

Each of the above-outlined solutions allow for data synchronization between active and standby nodes for service continuity. Therefore, the above-outlined solution is advantageous in that it enables for efficient and/or secure and/or robust and/or failure resistant and/or flexible data synchronization between active and standby nodes for service continuity.

Referring now to Figure 8, Figure 8 shows a block diagram illustrating an apparatus in a first state according to various examples of embodiments.

Specifically, Figure 8 shows a block diagram illustrating an apparatus 800 in a first state, which may represent an access network element in a first state, like e.g. such active gNB-Cll 220 as outlined above with reference to Figures 1 to 3, according to various examples of embodiments, which may participate in data synchronization between active and standby nodes for service continuity. Furthermore, even though reference is made to an access network element in a first state, the access network element may be also another device or function having a similar task, such as a chipset, a chip, a module, an application etc., which can also be part of a network element or attached as a separate element to a network element, or the like. It should be understood that each block and any combination thereof may be implemented by various means or their combinations, such as hardware, software, firmware, one or more processors and/or circuitry.

The apparatus 800 shown in Figure 8 may include a processing circuitry, a processing function, a control unit or a processor 810, such as a CPU or the like, which is suitable to enable data synchronization between active and standby nodes for service continuity. The processor 810 may include one or more processing portions or functions dedicated to specific processing as described below, or the processing may be run in a single processor or processing function. Portions for executing such specific processing may be also provided as discrete elements or within one or more further processors, processing functions or processing portions, such as in one physical processor like a CPU or in one or more physical or virtual entities, for example. Reference signs 831 and 832 denote input/output (I/O) units or functions (interfaces) connected to the processor or processing function 810. The I/O units 831 and 832 may be a combined unit including communication equipment towards several entities/elements, or may include a distributed structure with a plurality of different interfaces for different entities/elements. Reference sign 820 denotes a memory usable, for example, for storing data and programs to be executed by the processor or processing function 810 and/or as a working storage of the processor or processing function 810. It is to be noted that the memory 820 may be implemented by using one or more memory portions of the same or different type of memory, but may also represent an external memory, e.g. an external database provided on a cloud server.

The processor or processing function 810 is configured to execute processing related to the above described processing. In particular, the processor or processing circuitry or function 810 includes one or more of the following sub-portions. Sub-portion 811 is a transmitting portion, which is usable as a portion for transmitting a setup request. The portion 811 may be configured to perform processing according to S410 of Figure 4. Further, sub-portion 812 is a receiving portion, which is usable as a portion for receiving a setup response. The portion 812 may be configured to perform processing according to S420 of Figure 4. Moreover, sub-portion 813 is an establishing portion, which is usable as a portion for establishing a communication path to an access network element in a second state. The portion 813 may be configured to perform processing according to S430 of Figure 4.

Further, according to various examples of embodiments, at least one of the following may be considered regarding the apparatus 800 and/or the apparatus 800 may further be caused to perform at least one of the following:

- wherein the communication path may be a direct communication path and a preconfigured communication interface between the apparatus 800 and the access network element in the second state; and wherein the transmitting may comprise initiating the preconfigured communication interface by transmitting the setup request to the access network element in the second state; and wherein the establishing may comprise establishing the preconfigured communication interface based on the setup response received from the access network element in the second state;

- optionally obtaining address information from a network management entity or function, indicative of at least an address of the access network element in the second state; and transmitting the setup request to the access network element in the second state based on the address;

- wherein the communication path between the apparatus 800 and the access network element in the second state may include a network management entity or function; and wherein the transmitting may comprise transmitting the setup request to the network management entity or function for requesting setup of the communication path between the access network element in the second state and the apparatus 800; and wherein the establishing may comprise establishing the communication path based on the setup response received from the network management entity or function;

- wherein at least one mobile terminal may be associated to the apparatus 800, having a respective mobile terminal context; and wherein the apparatus 800 may further be caused to signalling, from the apparatus 800 to the access network element in the second state, of at least synchronization control information indicative of data to be synchronized and of at least one synchronization control parameter; and synchronizing data related to the at least one mobile terminal between the apparatus 800 and the access network element in the second state via the established communication path, based on the synchronization control information;

- wherein the synchronization control information may be indicative of a data content to be synchronized, and, wherein the at least one synchronization control parameter may be, at least one of a frequency of a data synchronization and an indication whether the data synchronization is event-based;

- wherein the data content may comprise at least the mobile terminal context of the at least one mobile terminal and/or access network element configuration data; wherein the mobile terminal context may comprise at least one of mobile terminal state information indicative of a state of at least one mobile terminal associated to the apparatus 800, session and/or bearer information related to at least one mobile terminal associated to the apparatus 800, a Packet Data Convergence Protocol, PDCP, context, optionally further including security keys used to secure the PDCP context, and mobile terminal historical information and/or information generated based on artificial intelligence - machine learning algorithms; and wherein the access network element configuration data may comprise at least configuration parameters and their values for configuring at least the apparatus 800, the access network element configuration data being set by a network operator operating at least the apparatus 800;

- the apparatus 800 may further be caused to receiving, as an event-based synchronization control parameter, a data synchronization trigger from a network management entity or function; and performing the synchronizing based on the data synchronization trigger; and/or receiving, as an event-based synchronization control parameter, natural disaster information from the network management entity or function; and performing the synchronizing based on the natural disaster information; and/or acquiring, as an eventbased synchronization control parameter, preconfigured data synchronization trigger conditions; determining whether at least one of the preconfigured data synchronization trigger conditions is met; and performing the synchronizing based on a result of the determination;

- the apparatus 800 may further be caused to performing the synchronizing per network slice provided by the apparatus 800, and/or per mobile terminal associated to the apparatus 800, and/or per group of mobile terminals associated to apparatus 800;

- wherein the at least one synchronization control parameter may further be indicative of at least synchronization points that represent time instants at which the synchronizing of target data is to be performed, wherein the target data may be a mobile terminal context that underwent a change since a previous synchronizing, or a mobile terminal context having stable radio resource control state changes since the previous synchronizing, or periodically synchronized data;

- the apparatus 800 may further be caused to indicating that a mobile terminal context is released due to a handover of the mobile terminal away from the apparatus 800, and/or a transition of the mobile terminal to an idle state; and/or indicating that synchronization data is to be removed in the access network element in the second state;

- the apparatus 800 may further be caused to receiving selection information from a network management entity or function, wherein the selection information may be indicative of at least one of the at least one mobile terminal associated to the apparatus 800, at least one network slice provided by the apparatus 800, at least one service provided by the apparatus 800, and at least one target access network element in the second state including the access network element in the second state; and selecting for the synchronizing at least one of the at least one mobile terminal, network slice, service and access network element in the second state based on the selection information;

- wherein the at least one synchronization control parameter may further comprise predetermined network slice requirements and/or predetermined service requirements to be satisfied for at least one network slice and/or for at least one service provided by the apparatus 800; wherein the apparatus 800 may further be caused to applying the synchronizing based on the predetermined network slice requirements and/or the predetermined service requirements; and/or determining a periodicity of the synchronizing based on the predetermined network slice requirements and/or the predetermined service requirements; and

- the apparatus 800 may further be caused to acquiring a likelihood level of a fault to occur in a connection to a mobile terminal provided by the apparatus 800; and, if the acquired likelihood level reaches a predetermined likelihood level threshold, modifying a synchronization control parameter by increasing a frequency of the synchronizing and/or by extending an amount of data to be synchronized. Referring now to Figure 9, Figure 9 shows a block diagram illustrating an apparatus in a second state according to various examples of embodiments.

Specifically, Figure 9 shows a block diagram illustrating an apparatus 900 in a second state, which may represent an access network element in a second state, like e.g. such standby gNB-Cll 230 as outlined above with reference to Figures 1 to 3, according to various examples of embodiments, which may participate in data synchronization between active and standby nodes for service continuity. Furthermore, even though reference is made to an access network element in a second state, the access network element may be also another device or function having a similar task, such as a chipset, a chip, a module, an application etc., which can also be part of a network element or attached as a separate element to a network element, or the like. It should be understood that each block and any combination thereof may be implemented by various means or their combinations, such as hardware, software, firmware, one or more processors and/or circuitry.

The apparatus 900 shown in Figure 9 may include a processing circuitry, a processing function, a control unit or a processor 910, such as a CPU or the like, which is suitable to enable data synchronization between active and standby nodes for service continuity. The processor 910 may include one or more processing portions or functions dedicated to specific processing as described below, or the processing may be run in a single processor or processing function. Portions for executing such specific processing may be also provided as discrete elements or within one or more further processors, processing functions or processing portions, such as in one physical processor like a CPU or in one or more physical or virtual entities, for example. Reference signs 931 and 932 denote input/output (I/O) units or functions (interfaces) connected to the processor or processing function 910. The I/O units 931 and 932 may be a combined unit including communication equipment towards several entities/elements, or may include a distributed structure with a plurality of different interfaces for different entities/elements. Reference sign 920 denotes a memory usable, for example, for storing data and programs to be executed by the processor or processing function 910 and/or as a working storage of the processor or processing function 910. It is to be noted that the memory 920 may be implemented by using one or more memory portions of the same or different type of memory, but may also represent an external memory, e.g. an external database provided on a cloud server. The processor or processing function 910 is configured to execute processing related to the above described processing. In particular, the processor or processing circuitry or function 910 includes one or more of the following sub-portions. Sub-portion 911 is a receiving portion, which is usable as a portion for receiving a setup request. The portion 911 may be configured to perform processing according to S510 of Figure 5. Further, subportion 912 is a transmitting portion, which is usable as a portion for transmitting a setup response. The portion 912 may be configured to perform processing according to S520 of Figure 5. Moreover, sub-portion 913 is a participating portion, which is usable as a portion for participating in establishing a communication path to an access network element in a first state. The portion 913 may be configured to perform processing according to S530 of Figure 5.

Further, according to various examples of embodiments, at least one of the following may be considered regarding the apparatus 900 and/or the apparatus 900 may further be caused to perform at least one of the following:

- wherein the communication path may be a direct communication path and a preconfigured communication interface between the apparatus 900 and the access network element in the first state; and wherein the receiving may comprise receiving the setup request from the access network element in the first state; and wherein the transmitting may comprise transmitting the setup response to the access network element in the first state;

- wherein the communication path between the access network element in the first state and the apparatus 900 may include a network management entity or function; and wherein the receiving may comprise receiving the setup request from the network management entity or function; and wherein the transmitting may comprise transmitting the setup response to the network management entity or function;

- the apparatus 900 may further be caused to receiving a signalling, from the access network element in the first state, of at least synchronization control information indicative of data to be synchronized and of at least one synchronization control parameter; and participating in synchronizing data between the access network element in the first state and apparatus 900 via the established communication path, based on the synchronization control information; and

- the apparatus 900 may further be caused to receiving a release indication from the access network element in the first state, indicative of a mobile terminal context to be released; and, based thereon, releasing the mobile terminal context; and/or receiving a removing indication from the access network element in the first state, indicative of synchronization data to be removed; and, based thereon, removing the synchronization data. Referring now to Figure 10, Figure 10 shows a block diagram illustrating an apparatus according to various examples of embodiments.

Specifically, Figure 10 shows a block diagram illustrating an apparatus 1000, which may represent a network management entity or function, like e.g. such AMF 210 (or OAM) as outlined above with reference to Figures 1 to 3, according to various examples of embodiments, which may participate in data synchronization between active and standby nodes for service continuity. Furthermore, even though reference is made to a network management entity or function, the network management entity or function may be also another device or function having a similar task, such as a chipset, a chip, a module, an application etc., which can also be part of a network element or attached as a separate element to a network element, or the like. It should be understood that each block and any combination thereof may be implemented by various means or their combinations, such as hardware, software, firmware, one or more processors and/or circuitry.

The apparatus 1000 shown in Figure 10 may include a processing circuitry, a processing function, a control unit or a processor 1010, such as a CPU or the like, which is suitable to enable data synchronization between active and standby nodes for service continuity. The processor 1010 may include one or more processing portions or functions dedicated to specific processing as described below, or the processing may be run in a single processor or processing function. Portions for executing such specific processing may be also provided as discrete elements or within one or more further processors, processing functions or processing portions, such as in one physical processor like a CPU or in one or more physical or virtual entities, for example. Reference signs 1031 and 1032 denote input/output (I/O) units or functions (interfaces) connected to the processor or processing function 1010. The I/O units 1031 and 1032 may be a combined unit including communication equipment towards several entities/elements, or may include a distributed structure with a plurality of different interfaces for different entities/elements. Reference sign 1020 denotes a memory usable, for example, for storing data and programs to be executed by the processor or processing function 1010 and/or as a working storage of the processor or processing function 1010. It is to be noted that the memory 1020 may be implemented by using one or more memory portions of the same or different type of memory, but may also represent an external memory, e.g. an external database provided on a cloud server. The processor or processing function 1010 is configured to execute processing related to the above described processing. In particular, the processor or processing circuitry or function 1010 includes one or more of the following sub-portions. Sub-portion 1011 is a receiving portion, which is usable as a portion for receiving a first setup request. The portion 1011 may be configured to perform processing according to S610 of Figure 6. Further, sub-portion 1012 is a transmitting portion, which is usable as a portion for transmitting a second setup request. The portion 1012 may be configured to perform processing according to S620 of Figure 6. Moreover, sub-portion 1013 is a receiving portion, which is usable as a portion for receiving a first setup response. The portion 1013 may be configured to perform processing according to S630 of Figure 6. Further, sub-portion 1014 is a transmitting portion, which is usable as a portion for transmitting a second setup response. The portion 1014 may be configured to perform processing according to S640 of Figure 6. Furthermore, sub-portion 1015 is a participating portion, which is usable as a portion for participating in establishing a communication path to an access network element in a first state. The portion 1015 may be configured to perform processing according to S650 of Figure 6.

Further, according to various examples of embodiments, at least one of the following may be considered regarding the apparatus 1000 and/or the apparatus 1000 may further be caused to perform at least one of the following:

- the apparatus 1000 may further be caused to transparently transferring synchronization data received from the access network element in the first state to the access network element in the second state;

- the apparatus 1000 may further be caused to acquiring at least one preconfigured address of at least one target access network element in the second state for the setup of the communication path; and selecting one of the at least one target access network element in the second state for transmitting the second setup request;

- the apparatus 1000 may further be caused to obtaining a data synchronization trigger; and transmitting the data synchronization trigger to the access network element in the first state to trigger data synchronization between the access network element in the first state and the access network element in the second state; and/or obtaining natural disaster information; and transmitting the natural disaster information to the access network element in the first state to trigger data synchronization between the access network element in the first state and the access network element in the second state; and

- the apparatus 1000 may further be caused to, in relation to a data synchronization between the access network element in the first state and the access network element in the second state, acquiring and providing selection information to the access network element in the first state, wherein the selection information may be indicative of at least one of at least one mobile terminal associated to the access network element in the first state, at least one network slice provided by the access network element in the first state, at least one service provided by the access network element in the first state, and at least one target access network element in the second state including the access network element in the second state.

Referring now to Figure 11 , Figure 11 shows a block diagram illustrating an apparatus according to various examples of embodiments.

Specifically, Figure 11 shows a block diagram illustrating an apparatus 1100, which may represent a network management entity or function, like e.g. such AMF 210 (or OAM) as outlined above with reference to Figures 1 to 3, according to various examples of embodiments, which may participate in data synchronization between active and standby nodes for service continuity. Furthermore, even though reference is made to a network management entity or function, the network management entity or function may be also another device or function having a similar task, such as a chipset, a chip, a module, an application etc., which can also be part of a network element or attached as a separate element to a network element, or the like. It should be understood that each block and any combination thereof may be implemented by various means or their combinations, such as hardware, software, firmware, one or more processors and/or circuitry.

The apparatus 1100 shown in Figure 11 may include a processing circuitry, a processing function, a control unit or a processor 1110, such as a CPU or the like, which is suitable to enable data synchronization between active and standby nodes for service continuity. The processor 1110 may include one or more processing portions or functions dedicated to specific processing as described below, or the processing may be run in a single processor or processing function. Portions for executing such specific processing may be also provided as discrete elements or within one or more further processors, processing functions or processing portions, such as in one physical processor like a CPU or in one or more physical or virtual entities, for example. Reference signs 1131 and 1132 denote input/output (I/O) units or functions (interfaces) connected to the processor or processing function 1110. The I/O units 1131 and 1132 may be a combined unit including communication equipment towards several entities/elements, or may include a distributed structure with a plurality of different interfaces for different entities/elements. Reference sign 1120 denotes a memory usable, for example, for storing data and programs to be executed by the processor or processing function 1110 and/or as a working storage of the processor or processing function 1110. It is to be noted that the memory 1120 may be implemented by using one or more memory portions of the same or different type of memory, but may also represent an external memory, e.g. an external database provided on a cloud server.

The processor or processing function 1110 is configured to execute processing related to the above described processing. In particular, the processor or processing circuitry or function 1110 includes one or more of the following sub-portions. Sub-portion 1111 is an acquiring portion, which is usable as a portion for acquiring at least one preconfigured address. The portion 1111 may be configured to perform processing according to S710 of Figure 7. Further, sub-portion 1112 is a generating portion, which is usable as a portion for generating address information. The portion 1112 may be configured to perform processing according to S720 of Figure 7. Moreover, sub-portion 1113 is a transmitting portion, which is usable as a portion for transmitting the address information. The portion 1113 may be configured to perform processing according to S730 of Figure 7.

Further, according to various examples of embodiments, at least one of the following may be considered regarding the apparatus 1100 and/or the apparatus 1100 may further be caused to perform at least one of the following:

- the apparatus 1100 may further be caused to obtaining a data synchronization trigger; and transmitting the data synchronization trigger to the access network element in the first state to trigger data synchronization between the access network element in the first state and the access network element in the second state; and/or obtaining natural disaster information; and transmitting the natural disaster information to the access network element in the first state to trigger data synchronization between the access network element in the first state and the access network element in the second state; and

- the apparatus 1100 may further be caused to, in relation to a data synchronization between the access network element in the first state and the access network element in the second state, acquiring and providing selection information to the access network element in the first state, wherein the selection information may be indicative of at least one of at least one mobile terminal associated to the access network element in the first state, at least one network slice provided by the access network element in the first state, at least one service provided by the access network element in the first state, and at least one target access network element in the second state including the access network element in the second state. It shall be noted that the apparatuses 800, 900, 1000 and 1100 as outlined above with reference to Figures 8 to 11 may comprise further/additional sub-portions, which may allow the apparatuses 800, 900, 1000 and 1100 to perform such methods/method steps as outlined above with reference to Figures 1 to 3.

Furthermore, according to various examples of embodiments, the first and second states as outlined above with reference to Figures 4 to 11 , may be understood as follows. Namely, that the first state is an active state and that the second state is a standby state. However, the first and second states are not limited thereto. For example, the second state may also be an idle state.

It should be appreciated that

- an access technology via which traffic is transferred to and from an entity in the communication network may be any suitable present or future technology, such as WLAN (Wireless Local Access Network), WiMAX (Worldwide Interoperability for Microwave Access), LTE, LTE-A, 5G, Bluetooth, Infrared, and the like may be used; additionally, embodiments may also apply wired technologies, e.g. IP based access technologies like cable networks or fixed lines.

- embodiments suitable to be implemented as software code or portions of it and being run using a processor or processing function are software code independent and can be specified using any known or future developed programming language, such as a high-level programming language, such as objective-C, C, C++, C#, Java, Python, Javascript, other scripting languages etc., or a low-level programming language, such as a machine language, or an assembler.

- implementation of embodiments is hardware independent and may be implemented using any known or future developed hardware technology or any hybrids of these, such as a microprocessor or CPU (Central Processing Unit), MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), and/or TTL (Transistor-Transistor Logic).

- embodiments may be implemented as individual devices, apparatuses, units, means or functions, or in a distributed fashion, for example, one or more processors or processing functions may be used or shared in the processing, or one or more processing sections or processing portions may be used and shared in the processing, wherein one physical processor or more than one physical processor may be used for implementing one or more processing portions dedicated to specific processing as described, - an apparatus may be implemented by a semiconductor chip, a chipset, or a (hardware) module including such chip or chipset;

- embodiments may also be implemented as any combination of hardware and software, such as ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field- programmable Gate Arrays) or CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components.

- embodiments may also be implemented as computer program products, including a computer usable medium having a computer readable program code embodied therein, the computer readable program code adapted to execute a process as described in embodiments, wherein the computer usable medium may be a non-transitory medium.

Although the present disclosure has been described herein before with reference to particular embodiments thereof, the present disclosure is not limited thereto and various modifications can be made thereto.

Claims

37 CLAIMS:

1. A method comprising, transmitting (S410), from an access network element in a first state (220, 800), a setup request for requesting setup of a communication path between the access network element in the first state (220, 800) and an access network element in a second state (230, 900); receiving (S420) a setup response; and, based thereon, establishing (S430) the communication path between the access network element in the first state (220, 800) and the access network element in the second state (230, 900).

2. The method according to claim 1 , wherein the communication path is a direct communication path and a preconfigured communication interface between the access network element in the first state (220, 800) and the access network element in the second state (230, 900); and wherein the transmitting comprises initiating the preconfigured communication interface by transmitting the setup request to the access network element in the second state (230, 900); and wherein the establishing comprises establishing the preconfigured communication interface based on the setup response received from the access network element in the second state (230, 900).

3. The method according to claim 2, further comprising obtaining address information from a network management entity or function (210, 1000), indicative of at least an address of the access network element in the second state (230, 900); and transmitting the setup request to the access network element in the second state (230, 900) based on the address.

4. The method according to claim 1 , wherein the communication path between the access network element in the first state (220, 800) and the access network element in the second state (230, 900) includes a network management entity or function (210, 1000); and wherein the transmitting comprises transmitting the setup request to the network management entity or function (210, 1000) for requesting setup of the communication path 38 between the access network element in the second state (230, 900) and the access network element in the first state (220, 800); and wherein the establishing comprises establishing the communication path based on the setup response received from the network management entity or function (210, 1000).

5. The method according to any one of claims 1 to 4, wherein at least one mobile terminal is associated to the access network element in the first state (220, 800) having a respective mobile terminal context; and wherein the method further comprises signalling, from the access network element in the first state to the access network element in the second state, of at least synchronization control information indicative of data to be synchronized and of at least one synchronization control parameter; and synchronizing data related to the at least one mobile terminal between the access network element in the first state (220, 800) and the access network element in the second state (230, 900) via the established communication path, based on the synchronization control information.

6. The method according to claim 5, wherein the synchronization control information is indicative of a data content to be synchronized, and, wherein the at least one synchronization control parameter is, at least one of a frequency of a data synchronization and an indication whether the data synchronization is event-based.

7. The method according to claim 6, wherein the data content comprises at least the mobile terminal context of the at least one mobile terminal and/or access network element configuration data; wherein the mobile terminal context comprises at least one of mobile terminal state information indicative of a state of at least one mobile terminal associated to the access network element in the first state (220, 800), session and/or bearer information related to at least one mobile terminal associated to the access network element in the first state (220, 800), a Packet Data Convergence Protocol, PDCP, context, optionally further including security keys used to secure the PDCP context, and mobile terminal historical information and/or information generated based on artificial intelligence - machine learning algorithms; and wherein the access network element configuration data comprises at least configuration parameters and their values for configuring at least the access network element in the first state (220, 800), the access network element configuration data being set by a network operator operating at least the access network element in the first state 220, 800).

8. The method according to any one of claims 5 to 7, further comprising receiving, as an event-based synchronization control parameter, a data synchronization trigger from a network management entity or function (210, 1000, 1100); and performing the synchronizing based on the data synchronization trigger; and/or receiving, as an event-based synchronization control parameter, natural disaster information from the network management entity or function (210, 1000, 1100); and performing the synchronizing based on the natural disaster information; and/or acquiring, as an event-based synchronization control parameter, preconfigured data synchronization trigger conditions; determining whether at least one of the preconfigured data synchronization trigger conditions is met; and performing the synchronizing based on a result of the determination.

9. The method according to any one of claims 5 to 8, further comprising performing the synchronizing per network slice provided by the access network element in the first state (220, 800), and/or per mobile terminal associated to the access network element in the first state (220, 800), and/or per group of mobile terminals associated to the access network element in the first state (220, 800).

10. The method according to any one of claims 5 to 9, wherein the at least one synchronization control parameter is further indicative of at least synchronization points that represent time instants at which the synchronizing of target data is to be performed, wherein the target data is a mobile terminal context that underwent a change since a previous synchronizing, or a mobile terminal context having stable radio resource control state changes since the previous synchronizing, or periodically synchronized data.

11 . The method according to any one of claims 5 to 10, further comprising indicating that a mobile terminal context is released due to a handover of the mobile terminal away from the access network element in the first state (220, 800), and/or a transition of the mobile terminal to an idle state; and/or indicating that synchronization data is to be removed in the access network element in the second state (230, 900).

12. The method according to any one of claims 5 to 11 , further comprising receiving selection information from a network management entity or function (210, 1000, 1100), wherein the selection information is indicative of at least one of the at least one mobile terminal associated to the access network element in the first state (220, 800), at least one network slice provided by the access network element in the first state (220, 800), at least one service provided by the access network element in the first state (220, 800), and at least one target access network element in the second state including the access network element in the second state (230, 900); and selecting for the synchronizing at least one of the at least one mobile terminal, network slice, service and access network element in the second state (230, 900) based on the selection information.

13. The method according to any one of claims 5 to 12, wherein the at least one synchronization control parameter further comprises predetermined network slice requirements and/or predetermined service requirements to be satisfied for at least one network slice and/or for at least one service provided by the access network element in the first state (220, 800); wherein the method further comprises applying the synchronizing based on the predetermined network slice requirements and/or the predetermined service requirements; and/or determining a periodicity of the synchronizing based on the predetermined network slice requirements and/or the predetermined service requirements.

14. The method according to any one of claims 5 to 13, further comprising acquiring a likelihood level of a fault to occur in a connection to a mobile terminal provided by the access network element in the first state (220, 800); and, if the acquired likelihood level reaches a predetermined likelihood level threshold, modifying a synchronization control parameter by increasing a frequency of the synchronizing and/or by extending an amount of data to be synchronized.

15. A method comprising, receiving (S510), at an access network element in a second state (230, 900), a setup request in relation to a setup of a communication path between an access network element in a first state (220, 800) and the access network element in the second state (230, 900); transmitting, in response thereto (S520), a setup response in relation to the setup of the communication path; and, based thereon, participating (S530) in establishing the communication path between the access network element in the first state (220, 800) and the access network element in the second state (230, 900).

16. The method according to claim 15, wherein the communication path is a direct communication path and a preconfigured communication interface between the access network element in the second state (230, 900) and the access network element in the first state (220, 800); and wherein the receiving comprises receiving the setup request from the access network element in the first state (220, 800); and wherein the transmitting comprises transmitting the setup response to the access network element in the first state (220, 800).

17. The method according to claim 15, wherein the communication path between the access network element in the first state (220, 800) and the access network element in the second state (230, 900) includes a network management entity or function (210, 1000); and wherein the receiving comprises receiving the setup request from the network management entity or function (210, 1000); and 42 wherein the transmitting comprises transmitting the setup response to the network management entity or function (210, 1000).

18. The method according to any one of claims 15 to 17, further comprising receiving a signalling, from the access network element in the first state, of at least synchronization control information indicative of data to be synchronized and of at least one synchronization control parameter; and participating in synchronizing data between the access network element in the first state (220, 800) and the access network element in the second state (230, 900) via the established communication path, based on the synchronization control information.

19. The method according to any one of claims 15 to 18, further comprising receiving a release indication from the access network element in the first state (220, 800), indicative of a mobile terminal context to be released; and, based thereon, releasing the mobile terminal context; and/or receiving a removing indication from the access network element in the first state (220, 800), indicative of synchronization data to be removed; and, based thereon, removing the synchronization data.

20. A method comprising, receiving (S610), at a network management entity or function (210, 1000), a first setup request from an access network element in a first state (220, 800) in relation to a setup of a communication path between the access network element in the first state (220, 800) and an access network element in a second state (230, 900); based thereon, transmitting (S620) a second setup request in relation to the setup of the communication path to the access network element in the second state (230, 900); based thereon, receiving (S630) a first setup response from the access network element in the second state (230, 900); based thereon, transmitting (S640) a second setup response to the access network element in the first state (220, 800); and based thereon, participating (S650) in establishing the communication path between the access network element in the first state (220, 800) and the access network element in the second state (230, 900).

21 . The method according to claim 20, further comprising 43 transparently transferring synchronization data received from the access network element in the first state (220, 800) to the access network element in the second state (230, 900).

22. The method according to claim 20 or 21 , further comprising acquiring at least one preconfigured address of at least one target access network element in the second state for the setup of the communication path; and selecting one of the at least one target access network element in the second state for transmitting the second setup request.

23. A method comprising, acquiring (S710), at a network management entity or function (210, 1100), at least one preconfigured address of a respective access network element in a second state (230, 900) for setup of a communication path between an access network element in a first state (220, 800) and the access network element in the second state (230, 900); generating (S720) address information indicative of the at least one preconfigured address, and transmitting (S730) the address information to the access network element in the first state (220, 800).

24. The method according to any one of claims 20 to 23, further comprising obtaining a data synchronization trigger; and transmitting the data synchronization trigger to the access network element in the first state (220, 800) to trigger data synchronization between the access network element in the first state (220, 800) and the access network element in the second state (230, 900); and/or obtaining natural disaster information; and transmitting the natural disaster information to the access network element in the first state (220, 800) to trigger data synchronization between the access network element in the first state (220, 800) and the access network element in the second state (230, 900).

25. The method according to any one of claims 20 to 24, further comprising, 44 in relation to a data synchronization between the access network element in the first state (220, 800) and the access network element in the second state (230, 900), acquiring and providing selection information to the access network element in the first state (220, 800), wherein the selection information is indicative of at least one of at least one mobile terminal associated to the access network element in the first state (220, 800), at least one network slice provided by the access network element in the first state (220, 800), at least one service provided by the access network element in the first state (220, 800), and at least one target access network element in the second state including the access network element in the second state (230, 900).

26. An apparatus (220, 800), comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the at least one processing circuitry, wherein the at least one memory and the instruction are configured to, with the at least one processing circuitry, cause the apparatus (220, 800) at least to: wherein the apparatus (220, 800) is in a first state, transmitting (S410) a setup request for requesting setup of a communication path between the apparatus (220, 800) and an access network element in a second state (230, 900); receiving (S420) a setup response; and, based thereon, establishing (S430) the communication path between the apparatus (220, 800) and the access network element in the second state (230, 900).

27. An apparatus (230, 900), comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the at least one processing circuitry, wherein the at least one memory and the instruction are configured to, with the at least one processing circuitry, cause the apparatus (230, 900) at least to: wherein the apparatus (230, 900) is in a second state, receiving (S510) a setup request in relation to a setup of a communication path between an access network element in a first state (220, 800) and the apparatus (230, 900); transmitting in response thereto (S520) a setup response in relation to the setup of the communication path; and, 45 based thereon, participating (S530) in establishing the communication path between the access network element in the first state (220, 800) and the apparatus (230, 900).

28. An apparatus (210, 1000), comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the at least one processing circuitry, wherein the at least one memory and the instruction are configured to, with the at least one processing circuitry, cause the apparatus (210, 1000) at least to: receiving (S610) a first setup request from an access network element in a first state (220, 800) in relation to a setup of a communication path between the access network element in the first state (220, 800) and an access network element in a second state (230, 900); based thereon, transmitting (S620) a second setup request in relation to the setup of the communication path to the access network element in the second state (230, 900); based thereon, receiving (S630) a first setup response from the access network element in the second state (230, 900); based thereon, transmitting (S640) a second setup response to the access network element in the first state (220, 800); and based thereon, participating (S650) in establishing the communication path between the access network element in the first state (220, 800) and the access network element in the second state (230, 900).

29. An apparatus (210, 1100), comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the at least one processing circuitry, wherein the at least one memory and the instruction are configured to, with the at least one processing circuitry, cause the apparatus (210, 1100) at least to: acquiring (S710) at least one preconfigured address of a respective access network element in a second state (230, 900) for setup of a communication path between an access network element in a first state (220, 800) and the access network element in the second state (230, 900); generating (S720) address information indicative of the at least one preconfigured address, and transmitting (S730) the address information to the access network element in the first state (220, 800). 46

30. According any one of the preceding claims, wherein the first state is an active state and the second state is a standby state.

31. A computer program product for a computer, including software code portions for performing the steps of any of claims 1 to 14 and 30, or any of claims 15 to 19 and 30, or any of claims 20 to 22, 24, 25 and 30, or any of claims 23 to 25 and 30, when said product is run on the computer.

32. The computer program product according to claim 31, wherein the computer program product includes a computer-readable medium on which said software code portions are stored, and/or the computer program product is directly loadable into the internal memory of the computer and/or transmittable via a network by means of at least one of upload, download and push procedures.