WO2025214634A1

WO2025214634A1 - Rrc profile management

Info

Publication number: WO2025214634A1
Application number: PCT/EP2025/054282
Authority: WO
Inventors: Ilkka Antero Keskitalo; Malgorzata Tomala; Janne Veikko Kaasalainen; Tero Henttonen; Lars Dalsgaard; Guillaume DECARREAU; Shashika Manosha Kapuruhamy Badalge; Parham KAZEMI
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2024-04-11
Filing date: 2025-02-18
Publication date: 2025-10-16
Anticipated expiration: 2026-10-11

Abstract

There is provided method performed by a network node of a first cell (such as a target cell), the method comprising: acquiring information of a plurality of second cell radio resource control (RRC) profiles associated with a user equipment in a second cell, wherein each RRC profile comprises a set of parameters for at least RRC configuration of the user equipment; and generating a plurality of first cell RRC profiles for use in the first cell based on the plurality of second cell RRC profiles.

Description

RRC PROFILE MANAGEMENT

TECHNICAL FIELD

Various example embodiments relate generally to management of radio resource control (RRC) configurations during mobility of a user equipment.

BACKGROUND

When a user equipment (UE) moves, it may undergo a handover or cell re-selection. In any case, management of RRC configurations/profiles is needed. This requires lot of resources, which may not be efficient.

BRIEF DESCRIPTION

According to some aspects, there is provided the subject matter of the independent claims. Some further aspects are defined in the dependent claims. The embodiments that do not fall under the scope of the claims are to be interpreted as examples useful for understanding the disclosure.

LIST OF THE DRAWINGS

In the following, the invention will be described in greater detail with reference to the embodiments and the accompanying drawings, in which

Figure 1 presents a network to which one or more embodiments are applicable;

Figures 2, 4, 5 and 6 shows example signaling flow diagrams, according to some embodiments;

Figures 3, and 7 to 12 show methods, according to some embodiments; and

Figure 13 illustrates an apparatus, according to some embodiments.

DESCRIPTION OF EMBODIMENTS

The following embodiments are exemplary. Although the specification may refer to “an”, "one”, or "some" embodiment(s) in several locations of the text, this does not necessarily mean that each reference is made to the same embodi- ment(s), or that a particular feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments. Further, when a particular feature, structure, or characteristic is described in connection of an embodiment, it is within the knowledge of one skilled in the art to apply such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. It shall be understood that although the terms "first/’ "second" and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another.

For the purposes of the present disclosure, the phrases "at least one of A or B”, "at least one of A and B”, and "A and/or B” means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase "A, B, and/or C” means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).

Embodiments described may be implemented in a communication network, such as any of the following radio access technologies (RATs): Worldwide Interoperability for Micro-wave Access (WiMAX), Global System for Mobile communications (GSM, 2G), GSM EDGE radio access Network (GERAN), General Packet Radio Service (GRPS), Universal Mobile Telecommunication System (UMTS, 3G) based on basic wideband-code division multiple access (W-CDMA), high-speed packet access (HSPA), Long Term Evolution (LTE), LTE-Advanced, and enhanced LTE (eLTE), 5G (also called NR), or any future RAT such as 6G. Moreover, communication within the communication network may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Frequency Division Duplex (FDD), Time Division Duplex (TDD), Multiple-Input Multiple-Output (MIMO), Orthogonal Frequency Division Multiple (OFDM), and/or Discrete Fourier Transform spread OFDM (DFT-s-OFDM).

As used herein, the term "network device" or "network node” refers to a node in a communication network via which user equipment may access the network and/or which is capable of controlling radio communication and managing radio resources within a cell. The network node or network device may be referred to as a base station (BS), an access point (AP) or an access node. The network device may be, depending on the applied technology, for example, a node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), an NR NB (also referred to as a gNB), a Remote Radio Unit (RRU), a radio head (RH), a remote radio head (RRH), a relay, an Integrated Access and Backhaul (IAB) node, a low power node, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, or an aircraft network device.

Moreover, in connection of split radio access network (RAN), the network device may refer to a centralised unit (CU) of a base station and/or a distributed unit (DU) of a base station. An interface between CU and DU may be referred to as an Fl interface in NR. In the split RAN architecture, node operations may be carried out, at least partly, in the central/centralized unit, CU, (e.g. server, host or node) operationally coupled to the DU, (e.g. a radio head/node). One CU may control one or more DUs, acting at least as transmit/receive (Tx/Rx) nodes. In some embodiments, the DUs may comprise e.g. a radio link control (RLC), medium access control (MAC) layer and a physical (PHY) layer, whereas the CU may comprise the layers above RLC layer, such as a packet data convergence protocol (PDCP) layer, a radio resource control (RRC) and an internet protocol (IP) layers. Other functional splits are possible too. In practice, any processing task may be performed in either the CU or the DU and the boundary where the responsibility is shifted between the CU and the DU may depend on the applied implementation.

The term "terminal device” refers to any end device that may be capable of wireless communication. By way of example, a terminal device may be referred to as a communication device, user equipment (UE), a Subscriber Station (SS), or a Mobile Station (MS). The terminal device may include a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones a tablet, a wearable terminal device, a personal digital assistant (PDA), portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, USB dongles, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like.

A term "resource", as used herein, may refer to radio resources in time domain, in frequency domain, in space domain, and/or in code domain. Some examples of resources include e.g. a physical resource block (PRB), a radio frame, a subframe, a time slot, a subband, a frequency region, a sub-carrier, a beam, etc. The term "transmission” and/or "reception” may refer to wirelessly transmitting and/or receiving via a wireless propagation channel on radio resources.

Figure 1 illustrates an example of a communication network to which examples disclosed herein may be applied. The communication network or a cellular communication network may comprise a network node 110 providing one or more cells, such as cell 100, and a network node 112 providing one or more other cells, such as cell 102. Each cell may be, e.g., a macro cell, a micro cell, femto, or a pico cell, for example. The cell may define a coverage area or a service area of the corresponding access node.

The network node 110 may provide a user equipment (UE) 120 (one or more UEs) with wireless access to the communication network. The wireless access may comprise downlink (DL) communication from the network node to the UE 120 and uplink (UL) communication from the UE 120 to the network node. Examples of uplink channels comprise physical uplink control channel (PUCCH) for transmitting control information and physical uplink shared channel (PUSCH) for transmitting data towards the network. Examples of downlink channels comprise physical downlink control channel (PDCCH) for transmitting control information and physical downlink shared channel (PDSCH) for transmitting data towards the user equipment.

There may be a plurality of UEs 120, 122 in the system. Each of them may be served by the same or by different control nodes 110, 112. The UEs 120, 122 may communicate with each other, in case device-to-device (D2D) communication interface is established between them via a so-called sidelink (SL). Such D2D communications may be referred to as machine-to-machine, peer-to-peer (P2P) communications, or vehicle-to-vehicle (V2V), for example.

In the case of multiple network nodes in the communication network, the network nodes may be connected to each other via an interface. LTE specifications call such an interface as X2 interface. An interface between an LTE node and a 5G node, or between two 5G nodes may be called Xn interface.

The network nodes 110 and 112 may be further connected via another interface to a core network 116 of the communication network. The LTE specifications specify the core network as an evolved packet core (EPC), and the core network may comprise e.g. a mobility management entity (MME) and a gateway node. The MME may handle mobility of terminal devices in a tracking area encompassing a plurality of cells and handle signalling connections between the terminal devices and the core network. The gateway node may handle data routing in the core network and to/from the terminal devices. The 5G specifications specify the core network as a 5G core (5GC). The 5G core may comprise e.g. an access and mobility management function (AMF) and a user plane function /gate way (UPF) and other functions. The AMF may handle termination of non-access stratum (NAS) signalling, NAS ciphering & integrity protection, registration management, connection management, mobility management, access authentication and authorization, security context management. The UPF node may support packet routing and forwarding, packet inspection and quality of service [QoS] handling, for example.

Reducing the energy consumptions of networks is one its key elements in future wireless networks. RRC protocol and its operations affect overall network performance including energy efficiency. In standards, 5G RRC procedures have predetermined processing delay requirements, in which the UE should be able to complete an RRC procedure. For example, RRC setup is required to be processed in 10ms, RRC resume in 6ms or 10 ms, RRC reconfiguration in 10ms and access stratum (AS) security activation in 5ms. However, in practical deployments the RRC processing times [in both the UE and the network) may get even longer, especially for more demanding RRC configurations (higherbandwidths, higher number of frequencies). Yet, it is observed that the longer RRC processing delays make 5G RRC not quick enough. Hence, a re-design is required to enable a robust and energy efficient control plane with competitive key performance indicators for future 6G networks.

The overall problem with RRC being suboptimal or not fast enough results from conservative 5G control signaling design and capabilities offered by the 5G RRC procedures. Even for the establishment of same type of connection (e.g. in transition from RRC IDLE state), the UE needs to exchange and repeat the same set of messages with the network, decode and apply the same content of configurations. Highest rate of repetition concern RRC reconfiguration message, which contains configuration of radio bearers, lower layers configuration (Physical Layer, MAC, RLC, PDCP configuration parameters) and any RRC specific configuration for a given feature (with a list of related parameters). Similarly, the network providing the UE with a certain RRC configuration needs to repeat the same list of parameters with the same sent message sequences (see Figure 2) in all successive connection set ups. For example, the activation of a configuration for a feature (for example see in Figure 2 activation of feature 1 in UE Reconfiguration 2) always needs to be done after a) setup of a basic connectivity (RRC Setup), b) Security Activation, c) UE Reconfiguration 2 for initial RRC reconfiguration (e.g. SRB2 setup), and d) UE Capabilities Transfer. As such, the existing 5G RRC procedural sequence, being repeated each time for any UE transition to RRC CONNECTED state, is neither optimal nor efficient.

Another problem with the usage of RRC configurations (also called RRC profiles) is how to maintain and utilize the configured profiles in mobility scenarios. While staying served by the same gNB, the profiles can be kept and used, as the UE contexts including profile configurations (also simply called profiles or configurations] are stored at the same gNB as well as at the UE itself. A problem arises when the UE is handed over to another gNB and the profiles do not match with the target cell configurations. Specific issues to be solved may include: what enhancements are needed for the handover (HO) procedure to allow continued utilization of existing profiles, what shall be the HO signaling extensions to support the profile usage (e.g. inter-gNB (Xn-type) signaling, RRC signaling between RAN nodes (source and target gNB) and UE)), and what shall be the behaviour of the UE and RAN nodes to support profile usage in mobility scenarios.

To at least partially tackle these problems, there are proposed solutions for managing RRC profiled during UE mobility, both for a UE in RRC connected state and for a UE in RRC idle or inactive state.

In various examples, a profile may be referred to as an RRC profile or a module. The profile may include a profile identifier, such as an index (0,1,2...) or label, and set of parameters of the RRC configuration(s), which may characterize a related type of connection. In some examples, a profile may provide one or more RRC configurations, and may be stored as an RRC Object. In this regard, a profile may represent an object with set of RRC configuration parameters, which may be grouped on the network side. A profile may be learned from one or more RRC configurations, and generated by the network node based on at least one connection (e.g., RRC connection). In some examples, the profile may also be generated based on UE capabilities (UE capability information). The profile may include a set of RRC parameters for the RRC configuration(s), with optionally some additional instructions such as UE capabilities specific to the profile. In this regard in some examples, a UE may be able to use some features only with a specific profile. Once generated, a profile may be stored by the network node and the UE, and referenced in a subsequent procedure to activate a UE connection (by the profile’s identifier), without a need to renegotiate and repeat a full configuration transfer or resend a previously used set of parameters. In some of these examples, the profile identifiers (e.g., index, label) may indicate a use case, feature or connection purpose, such as a power saving I energy saving / efficient operation, high throughput I performance I eMBB operation.

Figure 3 depicts an example method. The method may be computer-implemented. The method may be performed by a network node, such as target node (e.g. gNB of a target cell) of a handover, or by network node to which a UE attempts to perform a connection resume procedure. Let us assume that it is gNB 110 of Figure 1 that performs the method of Figure 3. It can be assumed that it is the UE 120 that is either handed over from cell 102 (source cell) to a cell 100 (target cell), or is resuming connection with cell 100.

As shown in Figure 3, the gNB 110 in step 300 acquires information of a plurality of second cell RRC profiles associated with the UE 120 in the second cell. The second cell is the cell 102 controlled by the gNB 112 in this example. Each RRC profile comprises a set of parameters for at least one RRC configuration of the UE. Each RRC profile may comprise a UE specific part and a cell specific part. That is, the UE may have been communicating or at least been in RRC connected state with the gNB 112, and may have negotiated or set up a plurality of RRC profiles in the second cell for communication with the second cell. Thus, the second cell RRC profiles are associated with the UE in the second cell. In an embodiment, the plurality of second cell RRC profiles are based on at least one of services or power saving mode associated with the UE in the second cell.

In an embodiment, the acquiring may comprise acquiring the plurality of second cell RRC profiles from a network node of the second cell (e.g. from gNB 112) or from the UE 120. This can take place e.g. in a HO request message, as an additional UE content to the legacy UE context. Acquiring, obtaining or receiving a RRC profile may denote acquiring the respective set of parameters of the RRC profile, which parameters form the respective RRC configuration of the RRC profile. Additionally, it may comprise acquiring also the respective profile identifier (ID).

In an embodiment, the acquiring comprises acquiring the plurality of second cell RRC profiles from a database accessible to the gNB 110. In one embodiment where the profiles are acquired from the database, the gNB 110 receives an identifier of the UE 120 from the gNB 112 (e.g. in connection of a handover request) or from the UE (in connection of RRC resume request from RRC idle state UE). The gNB 110 may then, based on the identifier of the UE, acquire the plurality of second cell RRC profiles from the database. The database may thus store RRC profiles of several UEs, and the gNB 110 sending a profile retrieval request identifying a certain UE to the database may allow the database to return RRC profiles of the correct UE to the gNB 110. That is, the plurality of second cell RRC profiles may be fetched by the gNB 110 from the (RAN) DB using the UE ID.

In an embodiment, each RRC profile is assigned with a profile identifier (ID). In an embodiment, acquiring the information comprises acquiring identifiers of the plurality of second cell RRC profiles. As said, the second cell RRC profiles may be obtained from the gNB 112 (e.g. source gNB of a handover). In this case, at least one of the identifiers is received from the gNB 112 in a HO request message. In another embodiment, at least one of the identifiers is received from the UE in a resume request. In yet one embodiment, the acquiring the information comprises acquiring the plurality of second cell RRC profiles corresponding to the identifiers from the database.

In step 302, the gNB 110 generates a plurality of first cell RRC profiles for use in the first cell based on the plurality of second cell RRC profiles. The first cell is in this example the cell 100 controlled by the network node 110.

It is to be noted that acquiring of the plurality of second cell RRC profiles or generating the first cell RRC profiles need not take place simultaneously, but can happen during a time period. E.g. in one embodiment only one second cell RRC profile is received and then one first cell RRC profile is generated. Then, the gNB 110 may communicate with the UE based on that one first cell RRC profile, after which at least one more second cell RRC profile is acquired and further generated into first cell RRC profile(s) which is/are useable in the first cell.

In an embodiment, the gNB 110 may determine at least one first cell specific configuration/parameter associated with at least one layer below the RRC layer in the first cell, and generate the plurality of first cell RRC profiles for use in the first cell further based on the at least one first cell specific configuration/parameter. This is because various radio configurations (e.g. common control and broadcast channel configurations and parameters] are different in cells and therefore the usage of existing profiles of the second cell (which may as well be generated by takin into account some lower layer configurations/parameters of the second cell) as such in the first cell is not necessarily possible. Therefore, lower layer configurations (such as RLC, MAC, PHY) in the first cell may advantageously be taken into account to modify the profiles used in the second cell in order to be able to apply those in the first cell. Lower layer configurations and/or parameters that depend on the first cell’s gNB’s configuration or load on radio channels are, for example, CORESET (Control Resource Set), CSI (Channel State Information) configuration, BWP (Band Width Part) configuration(s), PDCCH configuration, PUCCH configuration, or the like. Such parameters of the source cell cannot be re-used in the target cell as such but are advantageously re-configured to match with the target node.

In an embodiment, in a scenario where the functionalities of the gNB 110 are shared between CU and DU, the CU part may request associated the DU to provide the lower layer configuration(s) to the CU, e.g. to provide a cell group configuration relevant for the moving UE (unless already known by the CU]. This can be part of the CU-DU signalling required to define the access information that may be included in a HO command (in case of HO].

It is noted that the modification/generation/conversion of the second cell RRC profiles into the first cell RRC profiles is done per profile, thus maintaining corresponding profile IDs. For example, each of the plurality of second cell RRC profiles is identified with an identifier, such that there is a one-to-one mapping between the plurality of second cell RRC profiles and the plurality of first cell RRC profiles. The identifiers of the plurality of second cell RRC profiles are maintained in the plurality of first cell RRC profiles, such that a given first cell RRC profile is assigned with an identifier that is the same as the identifier of the second cell RRC profile which was used as a basis for generating the given first cell RRC profile. This may advantageously simplify the UEs operation in the first cell (e.g. in connection of handover from the second cell to the first cell].

In an embodiment, the converted first cell RRC profiles may advantageously provide same (or closest possible] capabilities for the UE power saving and required user plane data rates as the second cell RRC profiles, which have been negotiated in the second cell (e.g. as illustrated in Figure 4].

After generating the plurality of first cell RRC profiles, the gNB 110 may inform the UE about at least one of the generated first cell RRC profiles.

Then, the gNB 110 may communicate with the UE 120 in the first cell based on at least one of the generated plurality of first cell RRC profiles.

Before looking in more details regarding the RRC profile management in scenarios where UE is moving, let us look at how the last serving node may have established the RRC configurations (i.e. the second cell RRC configurations] with reference to Figure 4. That is, as a starting point, RRC profiles for a particular UE have been negotiated between RAN and UE. These RRC profiles may be based on UE capabilities (obtained with related signaling] and RAN node (e.g. gNB] configurations. These RRC profiles may be stored in the UE and in the RAN. In the RAN the storage can be in gNB-CU (assuming RRC is running in the CU] or there can be a database (DB] providing storage for UE contexts as well as RRC profiles accessible by multiple RAN nodes (e.g. access can be for both source and target gNB of a handover], In an embodiment, the number of profiles as well as the related configurations can be UE specific.

As shown in an example signaling procedure for profile negotiation in Figure 4, profiles can be negotiated during connection to any cell. This is assumed prerequisite for the mobility scenarios. Referring to the Figure 4, following steps may take place for the negotiation process.

In step 400, the UE 120 is RRC connected to the gNB 112, acting as a serving node, which in this example is shown to comprise CU and DU. In step 402, UE capabilities are signalled to the serving node.

In step 404, the UE may optionally request a profile configuration e.g., based on the service requirement (current or to be activated services) or power saving preference. This request may comprise proposed RRC profiles the UE may require.

In step 406, the gNB-CU initiates determination of the profile. This may comprise e.g. the gNB-CU requesting lower layer and cell status and configuration from the gNB-DU. At this stage, either the requested profile is configured, or multiple profiles are configured. Each profile will be assigned a Profile-ID. In step 408, the gNB-DU provides the requested configuration and set of lower layer and/or cell specific parameters associated with the requested profile(s). e.g. the DU provides configuration and parameter set for each profile. Profiles are referred by the assigned Profile-ID.

In step 410, the gNB-CU generates a message for profile configura- tion(s), possibly as per requested service/power saving mode, by using the information provided by the gNB-DU. Thatis, the CU sends RL RRC MESSAGE TRANSFER F1AP message carrying the RRC configuration including the profile configura- tion(s) and corresponding IDs. In step 412, the RRC reconfiguration message is sent to the UE including the profile configuration(s) and Profile-lD(s). If multiple profiles are configured, the message may indicate the profile (Profile-ID) to be activated. In step 414, the UE replies with RRC reconfiguration complete message to complete the procedure. This message can optionally include Profile-ID to confirm the activated profile. Alternative and additionally, the message can include all profiles supported and accepted by the UE. In step 416, the DU forwards the RRC message to gNB-CU.

In step 418, optionally, if a Data Base (DB) is used to store UE profiles (and other UE context), the gNB-CU sends UE specific profile configurations and Profile-ID (s) to the DB. And in step 420, the DB may confirm the successful reception of the UE data with an acknowledgement.

Then, let us take a look at, with reference to Figure 5, how the RRC profile management may take place in case of handover when the UE is in RRC connected state. The starting point is that the UE (e.g. UE 120) is RRC connected (as illustrated with a reference numeral 500) and configured with the RRM measurements and measurement reporting with appropriate reporting event (e.g. A3) to initiate measurement reporting, by the current serving RAN node, e.g. gNB 112. In this example, the UE context as well as the RRC profile configurations are stored in a data base (DB) accessible by the RAN nodes, in this case by both the source and target gNBs. In an alternative implementation (not shown in the Figure), the UE contexts and profiles may be stored in the serving node (first in the gNB 112 and then in the gNB 110).

Although gNBs 110 and 112 are shown as single entities, both can utilize a split architecture where each (or only other) may comprise a centralised unit (CU) and a distributed unit (DU). In yet further implementation aspect, a CU comprise a user plane part (CU-UP) and a control plane part (CU-CP), although not shown in Figure 5 for simplicity.

In step 502, a configured criterion (e.g. A3 event) is fulfilled initiating measurement reporting, and the UE sends measurement report to the serving node gNB 112. In step 504, based on the measurement report, the gNB 112 (e.g. CU-CP) decides about the initiation of HO procedure.

Consequently, in step 506, the gNB 112 sends a HO request to the target gNB 110 (e.g. to the CU-CP of gNB 110). The request includes at least the Profile-ID used in the source cell 102 (i.e. the ID of the source cell RRC profile). In an embodiment, the Profile-ID could also be another ID selected by the source cell e.g., based on the measurement results from the UE, i.e. not necessarily the one the UE is currently using with the source node 112. The HO request may also comprise an ID of the UE 120 that is to be handed over. Optionally, the source gNB 112 indicates the RRC configuration (i.e. RRC parameters) associated to the profile ID, which is used in the source cell prior to the HO.

In step 508, the gNB 110 requests the profile configuration(s) from the DB for this particular UE indicated by the UE-ID. This message may request all the RRC profiles associated with the UE in the source cell (i.e. all second cell RRC profiles) or only a subset. In case the request asks only one RRC profile from the data base, the request may comprise the RRC profile ID, which was included in the HO request.

In case the RRC profiles are stored in the access nodes (e.g. there is no database), the gNB 112 may include in the handover request the RRC parameters of the relevant source cell RRC profile, or the gNB 112 may ask this from the gNB 110 separately after receiving the HO request. In step 510, the DB provides the profile configuration(s) associated with the Profile-ID(s), and, if stored, possibly also the rest of the UE context.

In step 512, the target gNB (e.g. CU-CP of gNB 110) performs the derivation of the source cell RRC profile(s) to be applicable in the target cell.

Optionally, the CU-CP sends a request to the DU of the gNB 110 in order to obtain any lower layer (below RRC layer) and/or cell specific configurations associated with the RRC profile(s) included in the request to the DU. In an embodiment, an F1AP UE CONTEXT SETUP REQUEST message can be used for this request. If a request to the DU is made, the DU may reply with a response message including the lower layer/cell specific configuration and parameters for the requested profiles. The DU determines the lower layer configurations for the requested profile to match with the target DU/cell configurations as needed.

Using the lower layer and/or cell specific configurations, the source cell RRC profile(s) indicated in the HO request, and possibly some CU specific information, the gNB 110 (e.g. the CU of the gNB 110) generates in step 512 the first cell (=target cell) RRC profile(s) for use in the target cell. In this way, the target gNB 110 generates the new target cell RRC profiles, each corresponding to a source cell RRC profile of the source gNB 112.

In an embodiment, the ID(s) of the RRC profile(s) is/are maintained for the generated/converted first cell RRC profile(s) such that the ID(s) of the first cell RRC profile(s) correspond to the second cell (=source cell) RRC profile(s) used /stored during the connection in the source cell.

The gNB 110 generates a HO command -message for the UE and sends it to the source gNB 112 in step 514. The HO command may be encapsulated in an RRC reconfiguration message. The HO command, including required access parameters (for the UE to access the target cell) as well as the derived/modified RRC profile’s configuration parameters (and possibly corresponding profile ID) to be activated in the target cell, is transmitted to the source gNB 112. In other words, the target gNB (e.g. CU) generates the HO command including the modified RRC profile, which may be modified based on the RRC profile used in the source cell (and obtained in the HO request). The related profile ID of the target cell RRC profile is the same as in the HO request and is known by the UE. Alternatively, the profile ID can be included in the HO command to confirm that, even if the source RRC configuration is modified, the profile ID is associated with the RRC configuration of the HO command will be the ID to be used in the target cell. This is to allow the same pro- file-IDs to be used for the same power saving mode or service requirements, even with the converted RRC profile configurations.

For example, a HO request ACK is sent from the target gNB 110 to the source gNB 112 including the generated HO command. This converted RRC profile configuration included in the HO command can, instead of full configuration, be also a delta configuration with respect to the source cell RRC profile configuration to reduce signaling. The source gNB 112 sends RRC reconfiguration message to the UE 120 in step 516, including the HO command. In case of split architecture, the CU of the gNB 112 first sends the HO command to the DU of gNB 112 in DL RRC MESSAGE TRANSFER message, and the source DU then transmits the HO command to the UE as RRC reconfiguration message to trigger HO execution at the UE.

In an embodiment, sequence number (SN) status transfer message is sent from the source gNB 112 to the target gNB 110, while the UP data forwarding is initiated.

In step 518, according to an embodiment, the UE keeps/maintains all the configured source cell RRC profiles and Profile-IDs, even though the HO command has been received and the UE is moving to another cell. This may be beneficial in order to take use of delta configurations, as explained later.

In step 520, a random access procedure takes place between the UE and the target gNB 110. For example, the UE initiates access procedure by sending RACH preamble (msgl) to the target cell. The target cell replies with a random access response RAR] message including a resource grant for the following UE uplink transmission. Then, the UE sends RRC reconfiguration complete (HO complete) message to the gNB 110, including the Profile-ID that is to be activated. It is noted that the gNB-DU receiving the HO complete message may or may not be able to interpret the RRC message so that the profile configuration could become activated. The gNB-DU forwards the HO complete message to the CU of gNB 110. After decoding the RRC message, the CU may inform the DU about successful reception of HO complete message. That is, the UE moves to the target cell and after accessing, the UE takes the indicated profile in use. Then, the UE 1210 may communicate with the target gNB (current serving node) 110 by using the indicated target cell RRC profile.

In step 522, the target gNB 110 sends a UE context release to the source gNB 112. Then, the source gNB (e.g. both CU and DU) releases the UE context information, if such was stored at the gNB 112. It is noted that in some embodiments the UE context and profile configurations may be kept stored at the DB.

At this point the HO procedure has been completed and UE connection is moved to the target cell 100 of the gNB 110.

In an embodiment, for the user plane [UP], a path switch procedure may be initiated by the target gNB towards the core network (CN). Further, assuming a gNB functional split, the UP part of the CU of the gNB 110 may be configured for the data path transfer for the UE by sending e.g. a bearer context setup request to the CU-UP. In such case, the CU-UP may reply with a bearer context setup response to confirm the successful UP path configuration.

In step 524, the gNB 110 may send the converted RRC profile and profile ID to the DB for storage. In this example, only the activated profile is stored to DB after HO completion. Additionally, the rest of the UE context that is updated for the target cell is included in the information to the DB. The DB may confirm the storage of new UE data (optional).

In step 526, at some point of time (the exact time can be up to implementation), the target gNB 110 can initiate the conversion of the source cell RRC profiles that were not converted during the HO procedure (if any is left unconverted). This may comprise fetching other source cell RRC profiles from the DB (if not done already in step 508-510). Optionally, this step may also comprise sending these source cell RRC profiles and -IDs to the DU for the adaptation to the target cell configurations, and the DU replying with the adapted RRC profile configurations and profile IDs, each corresponding to the source cell RRC profiles and assigned source cell profile IDs. For example, some of the parameters of the target cell are under the control of DU and those maybe provided by the DU. The CU may then form the whole RRC profile as the RRC can be assumed to reside in the CU.

The gNB 110 may generate an RRC reconfiguration message for configuring the UE with the rest of the target cell RRC profiles and send it to the UE 120 in step 528. This message may comprise e.g. further target cell RRC profiles and their profile IDs. In an embodiment, instead of full RRC configurations, delta configurations with respect to the source cell RRC profiles (that have been maintained at the UE) can be used. The UE may acknowledge the received target cell RRC profiles in step 530. At this step, the UE may release the source cell RRC profiles. If needed, CU of gNB 110 may indicate the DU of the gNB 110 about successful reception of RRC reconfiguration complete message (in case of split architecture). After this negotiation, the converted RRC profiles are available to quickly change the UE’s operational mode in the target cell, depending on the desire for power saving or required service (e.g. UP data rate).

In step 532, the gNB 110 may transfer the new target cell RRC profile configurations to the DB for storage. The DB may confirm the reception.

Let us then take a look at a scenario where the UE is in RRC inactive state and is moving or at least connecting to a new cell than the previous serving cell. This is shown in Figure 6 in a signaling flow diagram applicable for cases where the UE is in an inactive mode and resuming connection (reconnecting). In other words, the UE has moved while being in the inactive mode and is re-selecting a new cell to connect with. Here it is assumed that gNB 112 is the last serving node and gNB 110 is the new node with which the UE tries to connect.

In Figure 6 same principles may be used for this resume as in the HO procedure for UE in RRC CONNECTED of Figure 5. In this example of Figure 6, as will be explained below, also the option of storing the profiles (and UE context) at the gNB is shown. The principle remains as in the case where the UE context is stored in DB, but the location of the storage and related signaling is different.

In step 600, the UE decides to initiate connection setup /resume via another cell for a desired service utilizing stored context of profile(s). That is, in the depicted procedure, UE is initiating connection (after suspension) in another cell than where it was previously RRC connected. The UE may have maintained the RRC profiles utilized/applicable in the previous serving cell 102.

Legacy (NR type) signaling is applied in this example with the additional information included in certain messages. For example, steps 602 and 604 may comprise transmission and reception of random access (RA) messages Msgl and Msg2, as in legacy random access procedure.

In step 606, Msg3 of the RA procedure is transmitted from the UE to the target gNB 110. The Msg3 may comprise an indication of a requested profile with ID x which can be any profile configured and stored in the UE and RAN during the previous RRC CONNECTED state in the previous serving cell. The requested profile may be based on the service the UE desires to use in the target cell (e.g. there may be different RRC profiles per different services). In the RA procedure the network may also become aware of the identity of the UE. The Msg3 may carry a resume request message.

In one option, shown with reference numeral 607, the database stores the UE context and thus the RRC profiles for the UE. In such case, in step 608, the gNB 110 may send a UE context request to the DB, the request indicating at least the UE ID, and possibly the profile ID(s) that are requested (e.g. IDx). In step 610, the DB returns the requested RRC profile(s) to the gNB 110, possibly along with the IDs of the RRC profile(s), at least if the DB returns more RRC profiles than just the one corresponding to IDx.

In another option, shown with reference numeral 611, the last serving gNB 112 stores the UE context and thus the RRC profiles for the UE. In such case, in step 612, the gNB 110 may send a UE context request to the gNB 112, the request indicating at least the UE ID, and possibly the profile ID(s) that are requested (e.g. IDx). In step 614, the gNB 112 returns the requested RRC profile(s) to the gNB 110, possibly along with the IDs of the RRC profile(s), at least if the gNB 112 returns more RRC profiles than just the one corresponding to IDx.

At this point, either due to option 607 or 611, the gNB 110 is aware of the second cell (=last serving cell) RRC profile(s). Thereafter, in step 616, the gNB 110 may modify these second cell RRC profile(s) to first cell -target cell) RRC profile^), similarly as explained in connection of steps 512 and or 526 of Figure 5. That is, the gNB 110 in step 616 derives one or more of the first cell RRC profiles based on the corresponding one or more second cell RRC profiles, while maintaining the IDs of the RRC profiles. The generation may further be at least partly based on the lower layer configurations of the first cell 100 (controlled by the gNB 110).

Similarly as in Figure 5, also in Figure 6 (although not shown) path switch procedure maybe initiated towards the core network (CN). Further, assuming a gNB functional split, the UP part of the CU of the gNB 110 may be configured for the data path transfer for the UE by sending e.g. a bearer context setup request to the CU-UP. In such case, the CU-UP may reply with a bearer context setup response to confirm the successful UP path configuration.

The gNB 110 may then generate a resume message and transmit that to the UE in step 618. The message includes in an embodiment all the first cell RRC profiles (i.e. the modified RRC profiles), their corresponding IDs and optionally also IDx which indicates to the UE which RRC profile the UE is to use with the target gNB 110. In the same way as in Figure 5, the configuration(s) may be delta configuration^) with respect to the previous serving cells RRC profile(s) (=second cell RRC profile(s)). In an embodiment, only the RRC configuration corresponding to the IDx is indicated to the UE in the resume message, and the other first cell RRC configurations are informed to the UE later in time. The resume message may be called Msg4 of the RA procedure.

After this, the UE may reactivate integrity protection and ciphering with new keys, based on the received RRC profile corresponding to profile IDx.

In step 620, the UE may respond to the gNB 110 with RRC setup/resume complete message (Msg5), with which the US acknowledges that the RRC profile with IDx is to be used.

In step 622, the gNB may store the target cell RRC profile(s) and their ID(s) in the DB, if DB is used to store UE context. The message may also comprise ID of the UE. The database may confirm the reception with ACK message to the gNB 110.

As illustrated in connection of Figure 3, the gNB 110 may perform in Figures 5 and 6 at least the following functions: acquire information of a plurality of second cell RRC profiles associated with the UE 120 in the second cell 102, generate a plurality of first cell RRC profiles for use in the first cell based on the plurality of second cell RRC profiles, and provide information of at least one of the first cell RRC profiles to the UE, and possibly communicate with the UE in the first cell based on at least one of the generated plurality of first cell RRC profiles. Acquiring the information may take place at one point of time or at different point of times. Similarly, generating the new RRC profiles for the first cell may take place at one point of time or at different point of times, as shown with steps 512 and 526 of Figure 5.

In an embodiment, with reference to Figure 7, (as also shown as some steps of Figures 5 and 6], the gNB 110 may in step 700 acquire information of a particular second cell RRC profile (e.g. indication of IDx in the HO request of Figure 5 or in the resume request of Figure 6). This particular RRC profile may be one among the plurality of second cell RRC profiles. In an embodiment, the particular second cell RRC profile is the latest RRC profile associated with the UE in the second cell.

Then, the gNB 110 may in step 702 generate a particular first cell RRC profile based on the particular second cell RRC profile (and possibly based on relevant first cell lower layer configurations, as explained above). Or the gNB 110 may select a particular first cell RRC profile among already generated plurality of first cell RRC profiles, wherein the selection is based on the particular second cell RRC profile. For example, the gNB 110 may select that first cell RRC profile which is associated with an ID that corresponds the ID associated with the particular second cell RRC profile.

The gNB 110 may then in step 704 provide information of the particular first cell RRC profile to the UE (e.g. in HO command of Figure 5 or in RRC setup /resume message of Figure 6). The information may be the ID of the RRC profile or the full/delta RRC configuration. Then, the gNB 110 may communicate with the UE in the first cell based on the particular first cell RRC profile. In an embodiment, the other RRC profiles associated to the UE in the second cell may be later used as a basis to generate the first cell RRC profiles, and then indicated to the UE (e.g. not during the handover or during the RRC setup/re- sumej. This may be more efficient as the UE can obtain RRC Connected state with gNB 110 with less signaling.

From the point of view of the source gNB 112, Figure 8 depicts an example method. The method may be computer-implemented. The method may be performed by a network node of a source cell of a handover, such as the gNB 112. As illustrated in Figure 8, the source gNB 112 may perform at least the following functions. In step 800, the gNB 112 may include in the handover request (to the target gNB 110) an identifier of a particular second cell RRC profile. The gNB 112 may select the particular second cell RRC profile to be included in the handover request, the selection being among a plurality of second cell RRC profiles and being based on at least one of the following: measurement results received from the UE, a profile ID in the measurement report, services used by the UE in the source cell, latest second cell RRC profile used by the UE in the second cell. For example, the measurement report triggering the HO procedure may indicate an RRC profile ID that seems from UE point of view suitable in the target cell and would e.g. provide the closest match with the services (or in general with the operating mode) the UE wishes to use in the first cell once being handed over there.

In step 802, the gNB 112 may transmit the handover request to the gNB 110. In step 804, the gNB 112 may receive from the target gNB 110 in a handover command an identifier of a particular first cell RRC profile. In an embodiment, the first cell RRC profile may be determined by the gNB 110 based on the particular second cell RRC profile. The source gNB 112 may then transmit/forward this HO command to a UE 120 in step 806, so that the UE can access the target cell of the target gNB 110 based on the HO command.

Still, from the point of view of the source gNB 112, Figure 9 depicts an example method. The method maybe computer-implemented. The method may be performed by a network node of a source cell of a handover, such as the gNB 112. As shown in Figure 9, the gNB 112 optionally stores (as shown in step 900) the source cell RRC profiles (instead or in addition to the DB). In step 902, the source gNB 112 provides, to the gNB 110 (of the target/first cell), information of the plurality of second cell RRC profiles associated with a user equipment (UE) in the second cell. The providing may take place iteratively in many time instances or at one time instance. In an embodiment, this information may be e.g. the plurality of second cell RRC profiles and a profile-specific identifier for each of the plurality of second cell RRC profiles.

In an embodiment, the providing of step 902 may happen after receiving a request, from the network node of the first cell (e.g. from the gNB 110), to provide the information. In an embodiment, the request comprises an identifier of the UE, and the acquiring comprises acquiring the information based on the identifier of the UE.

In an embodiment, the gNB 112, before providing the information to gNB 110, fetches the information from a database accessible by the gNB 112.

Figure 10 depicts an example method. The method may be computer- implemented. The method may be performed by a user equipment, such as the UE 120. In step 1000, the UE stores a plurality of second cell RRC profiles associated with the UE in a second cell. In step 1002, the UE maintains the plurality of stored profiles during mobility of the UE from a second cell to a first cell. In step 1004, the UE acquires a plurality of first cell RRC profiles associated with the UE in the first cell, the plurality of first cell RRC profiles being generated based at least partially on the plurality of second cell RRC profiles. The UE may acquire the first cell RRC profiles in one shot or during a time period (e.g. in Figure 5 the UE acquires information of the RRC profiles associates with the UE in the first cell in two steps (516 and 528). In an embodiment, the acquiring is done via reception of a HO command comprising information of the plurality of first cell RRC profiles. In another embodiment, the acquiring is done via reception of a RRC setup/resume message (also known as a connection resume message, sent as a response to a connection resume request message) from the network node of the first cell, the message comprising information of the plurality of first cell RRC profiles. Then, the UE may communicate in the first cell based on at least one of the plurality of first cell RRC profiles.

Figure 11 depicts another example method. The method may be computer-implemented. The method may be performed by a user equipment, such as the UE 120. In step 1100, the UE provides to a network node of a first cell an indication of a particular second cell RRC profile. This indication can be included e.g. in a RRC setup/resume request (see Figure 6). In step 1102, the UE receives an indication of particular first cell RRC profile from the network node of the first cell. The particular first cell RRC profile may be generated based on the particular second cell RRC profile indicated in step 1100. This indication of step 1102 may be received e.g. in RRC setup/resume message (see Figure 6). In step 1104 the UE may apply the particular first cell RRC profile for communication in the first cell. Applying a given RRC profile for communication may comprise e.g. applying a respective set of parameters of the given RRC profile to at least one radio resource control configuration of the user equipment for the current or subsequent connection /communication.

Figure 12 depicts another example method. The method may be computer-implemented. The method may be performed by a user equipment, such as the UE 120. In step 1200, the UE, which is to be handed over to a first cell or which is connecting to the first cell, acquires information of a plurality of first cell RRC profiles associated with the UE in the first cell. In an embodiment, this acquisition may take place in a HO command (e.g. the information is comprised in the handover command), and user equipment receives the handover command via the gNB 112 during a handover of the user equipment from the second cell to the first cell. In another embodiment, the acquisition takes place in an RRC setup /resume message (e.g. the information is comprised in a connection resume message), and the user equipment receives the connection resume message from the gNB 110 during the UE is attempting a connection resume with the gNB 110. The information may comprise e.g. RRC profiles and related profile IDs, for example. In an embodiment, the UE, prior to acquiring the information, sends information of a particular second cell RRC profile to the gNB 110 (e.g. in a resume request message). Then, the UE in step 1202 selects one of the plurality of first cell RRC profiles to use for communication in the first cell. In an embodiment, the selection is based on service requirements and/or power saving requirements of the UE in the first cell. In an embodiment, the UE indicates the selected profile (e.g. with a Profile-ID) in a HO complete message.

The following list some aspects of the above presented embodiments. According to one aspect, there is a HO command indicating an RRC profile to be used when accessing the target cell where, RRC profiles are defined in the source (or previous) cell(s), the profile to be used in the target cell is indicated in the HO request from source to target gNB, and the target gNB adapts the requested profile with cell specific parameters to match with the target cell configuration, as needed. In an aspect, the profile is indicated with the Profile-ID. In an aspect, the profile configuration(s) is (are) either included in the HO request or accessible by the target gNB with UE ID and Profile-ID. In an aspect, other profile configurations are provided by the source gNB to the target gNB with specific signaling procedure, or the target cell fetches the configuration from a common RAN data base. In an aspect, each RRC Profile comprises UE specific part and cell specific part. In an aspect, a DU part of the target gNB provides the lower layer or cell specific parameters that are required to convert the RRC profiles to match with the target cell configuration. In an aspect, multiple or all configured profile configurations/Profile IDs are included in the HO request, and the UE may select the profile to be used in the target cell matching best the desired service requirements and/or power saving level considering the radio conditions on the target link. In an aspect, the UE indicates the selected profile (Profile-ID) in the HO complete message.

An embodiment, as shown in Figure 13, provides an apparatus 10 comprising a control circuitry (CTRL) 12, such as at least one processor, and at least one memory 14 storing instructions that, when executed by the at least one processor, cause the apparatus at least to carry out any one of the above-described processes. In an example, the at least one memory and the computer program code (software), are configured, with the at least one processor, to cause the apparatus to carry out any one of the above-described processes. The control circuitry 12 may comprise relevant circuitry/ies for performing the functions, according to any of the embodiments.

The memory may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The memory may comprise a database for storing data.

In an embodiment, the apparatus 10 is or is comprised in a network node, such as the gNB 110. The apparatus may be caused to execute some of the functionalities of the above described processes, such as the steps of any of Figures 3 and 7.

In another embodiment, the apparatus 10 is or is comprised in a network node, such as the gNB 112. The apparatus may be caused to execute some of the functionalities of the above described processes, such as the steps of any of Figures 8 or 9, for example.

In another embodiment, the apparatus 10 is or is comprised in a user equipment, such as the UE 120. The apparatus may be caused to execute some of the functionalities of the above described processes, such as the steps of any of Figures 10, 11 or 12, for example.

The apparatus may further comprise a radio interface (TRX) 16 comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. The TRX may provide the apparatus with communication capabilities to a user equipment and/or to a base station, for example.

The apparatus may also comprise a user interface 18 comprising, for example, at least one keypad, a microphone, a touch display, a display, a speaker, etc. The user interface may be used to control the apparatus by the user.

The control circuitry 12 may comprise relevant circuitry/ies for performing the functions, according to any of the embodiments.

As used in this application, the term ‘circuitry’ refers to all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b] combinations of circuits and soft- ware (and/or firmware], such as (as applicable]: (i] a combination of processors] or (ii] portions of processors] /software including digital signal processor(s), software, and memory(ies] that work together to cause an apparatus to perform various functions, and (c] circuits, such as a microprocessors] or a portion of a microprocessors], that require software or firmware for operation, even if the software or firmware is not physically present. This definition of ‘circuitry’ applies to all uses of this term in this application. As a further example, as used in this application, the term ‘circuitry’ would also cover an implementation of merely a processor (or multiple processors] or a portion of a processor and its (or their] accompanying software and/or firmware. The term ‘circuitry’ would also cover, for example and if applicable to the particular element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or another network device.

In an embodiment, at least some of the processes described may be carried out by an apparatus comprising corresponding means for carrying out at least some of the described processes. Some example means for carrying out the processes may include at least one of the following: detector, processor (including dual-core and multiple-core processors], digital signal processor, controller, receiver, transmitter, encoder, decoder, memory, RAM, ROM, software, firmware, display, user interface, display circuitry, user interface circuitry, user interface software, display software, circuit, antenna, antenna circuitry, and circuitry.

A term non-transitory, as used herein, is a limitation of the medium itself (i.e. tangible, not a signal] as opposed to a limitation on data storage persistency (e.g. RAM vs. ROM],

As used herein the term “means” is to be construed in singular form, i.e. referring to a single element, or in plural form, i.e. referring to a combination of single elements. Therefore, terminology "means for [performing A, B, C]”, is to be interpreted to cover an apparatus in which there is only one means for performing A, B and C, or where there are separate means for performing A, B and C, or partially or fully overlapping means for performing A, B, C. Further, terminology “means for performing A, means for performing B, means for performing C" is to be interpreted to cover an apparatus in which there is only one means for performing A, B and C, or where there are separate means for performing A, B and C, or partially or fully overlapping means for performing A, B, C.

The techniques and methods described herein may be implemented by various means. For example, these techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the apparatuses) of embodiments may be implemented within one or more applicationspecific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. For firmware or software, the implementation can be carried out through modules of at least one chip set (e.g. procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be implemented within the processor or externally to the processor. In the latter case, it can be communicatively coupled to the processor via various means, as is known in the art. Additionally, the components of the systems described herein may be rearranged and/or complemented by additional components in order to facilitate the achievements of the various aspects, etc., described with regard thereto, and they are not limited to the precise configurations set forth in the given figures, as will be appreciated by one skilled in the art.

Embodiments as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodiments of the methods described may be carried out by executing at least one portion of a computer program comprising corresponding instructions. The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carrying the program. For example, the computer program maybe stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunications signal, and software distribution package, for example. The computer program medium maybe a non-transitory medium. Coding of software for carrying out the embodiments as shown and described is well within the scope of a person of ordinary skill in the art.

Following is a list of some aspects of the invention.

According to a first aspect, there is provided a method performed by a network node of a first cell, the method comprising: acquiring information of a plurality of second cell radio resource control (RRC) profiles associated with a user equipment in a second cell, wherein each RRC profile comprises a set of parameters for at least RRC configuration of the user equipment; and generating a plurality of first cell RRC profiles for use in the first cell based on the plurality of second cell RRC profiles.

Various embodiments of the first aspect may comprise at least one feature from the following bulleted list:

• communicating with the UE in the first cell based on at least one of the generated plurality of first cell RRC profiles.

• determining at least one first cell specific configuration associated with at least one layer below the RRC layer in the first cell; and generating the plurality of first cell RRC profiles for use in the first cell further based on the at least one first cell specific configuration.

• wherein acquiring the information comprises acquiring the plurality of second cell RRC profiles from a network node of the second cell or from the user equipment.

• receiving an identifier of the user equipment from a network node of the second cell or from the user equipment; and acquiring, based on the identifier of the UE, the plurality of second cell RRC profiles from a database accessible to the network node of the first cell.

• wherein acquiring the information comprises acquiring at least one identifier of the plurality of second cell RRC profiles and acquiring the plurality of second cell RRC profiles based on the at least one identifier.

• acquiring information of a particular second cell RRC profile among the plurality of second cell RRC profiles; determining a particular first cell RRC profile based on the particular second cell RRC profile; communicating with the user equipment in the first cell based on the particular first cell RRC profile.

• acquiring the information of the particular second cell RRC profile in a handover request from a network node of the second cell; generating a handover command, the handover command comprising information of the particular first cell RRC profile; and transmitting the handover command towards the user equipment.

• acquiring the information of the particular second cell RRC profile in a resume request message from the user equipment; generating a connection resume message comprising information of the particular first cell RRC profile; and transmitting the connection resume message to the user equipment.

• herein the particular second cell RRC profile is the latest RRC profile associated with the user equipment in the second cell.

• wherein each of the plurality of second cell RRC profiles is identified with an identifier, wherein the identifiers of the plurality of second cell RRC profiles are maintained in the plurality of first cell RRC profiles such that a given first cell RRC profile is assigned with an identifier that is the same as the identifier of the second cell RRC profile which was used as a basis for generating the given first cell RRC profile.

According to a second aspect, there is provided a method, performed by a network node of a second cell, the method comprising: providing, to a network node of a first cell, information of a plurality of second cell RRC profiles associated with a user equipment in the second cell, wherein each RRC profile comprises a set of parameters for at least RRC configuration of the user equipment.

Various embodiments of the second aspect may comprise at least one feature from the following bulleted list:

• storing the information of the plurality of second cell RRC profiles.

• obtaining the information of the plurality of second cell RRC profiles from a database accessible by the network node of the second cell.

• receiving a request, from the network node of the first cell, to provide the information, wherein the request comprises an identifier of the user equipment; and responding to the request by providing the information to the network node of the first cell.

• Wherein providing the information comprises providing to the network node of the first cell the sets of parameters associated with the plurality of second cell RRC profiles and a profile-specific identifier for each of the plurality of second cell RRC profiles.

According to a third aspect, there is provided a method, performed by a user equipment, the method comprising: receiving, from a network node of a first cell, information of a plurality of first cell radio resource control (RRC) profile associated with the user equipment in the first cell, wherein each RRC profile comprises a set of parameters for at least RRC configuration of the user equipment; and selecting one of the plurality of first cell RRC profiles for communication in the first cell.

Various embodiments of the third aspect may comprise at least one feature from the following bulleted list:

• Wherein the selecting is based on at least one of service requirements or power saving requirements of the UE in the first cell.

• Wherein the information is comprised in a handover command; and the method further comprises receiving the handover command via a network node of a second cell during a handover of the user equipment from the second cell to the first cell.

• Wherein the information is comprised in a connection resume message; and the method further comprises receiving the connection resume message from the network node of the first cell during a connection resume with the network node of the first cell.

• transmitting information of a particular second cell RRC profile to the network node of the first cell before acquiring the information of the plurality of first cell RRC profiles. According to a fourth aspect, there is provided a network node of a first cell, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network node at least to: acquire information of a plurality of second cell radio resource control (RRC) profiles associated with a user equipment in a second cell, wherein each RRC profile comprises a set of parameters for at least RRC configuration of the user equipment; and generate a plurality of first cell RRC profiles for use in the first cell based on the plurality of second cell RRC profiles. Various embodiments of the fourth aspect may comprise at least one feature from the bulleted list under the first aspect.

According to a fifth aspect, there is provided a network node of a second cell, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network node at least to: provide, to a network node of a first cell, information of a plurality of second cell RRC profiles associated with a user equipment in the second cell, wherein each RRC profile comprises a set of parameters for at least RRC configuration of the user equipment. Various embodiments of the fifth aspect may comprise at least one feature from the bulleted list under the second aspect.

According to a sixth aspect, there is provided a user equipment, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the user equipment at least to: receive, from a network node of a first cell, information of a plurality of first cell radio resource control (RRC) profile associated with the user equipment in the first cell, wherein each RRC profile comprises a set of parameters for at least RRC configuration of the user equipment; and select one of the plurality of first cell RRC profiles for communication in the first cell. Various embodiments of the sixth aspect may comprise at least one feature from the bulleted list under the third aspect.

According to a seventh aspect, there is provided a computer program product embodied on a distribution medium and comprising program instructions which, when executed by an apparatus, cause the apparatus to carry out the method according to the first aspect, the second aspect, or the third aspect.

According to an eight aspect, there is provided a computer program product comprising program instructions which, when executed by an apparatus, cause the apparatus to carry out the method according to the first aspect or according to the first aspect, the second aspect, or the third aspect.

According to a ninth aspect, there is provided an apparatus, comprising means for performing the method according to the first aspect, the second aspect, or the third aspect, and/or means configured to cause the apparatus to perform the method according to the first aspect, the second aspect, or the third aspect.

Even though the invention has been described above with reference to an example according to the accompanying drawings, it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be combined with other embodiments in various ways.

Claims

1. A network node of a first cell, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network node at least to: acquire information of a plurality of second cell radio resource control (RRC) profiles associated with a user equipment in a second cell, wherein each RRC profile comprises a set of parameters for at least RRC configuration of the user equipment; and generate a plurality of first cell RRC profiles for use in the first cell based on the plurality of second cell RRC profiles.

2. The network node of claim 1, wherein the network node is further caused to: communicate with the UE in the first cell based on at least one of the generated plurality of first cell RRC profiles.

3. The network node of any of claims 1 to 2, wherein the network node is further caused to: determine at least one first cell specific configuration associated with at least one layer below the RRC layer in the first cell; and generate the plurality of first cell RRC profiles for use in the first cell further based on the at least one first cell specific configuration.

4. The network node of any of claims 1 to 3, wherein acquiring the information comprises acquiring the plurality of second cell RRC profiles from a network node of the second cell or from the user equipment.

5. The network node of any of claims 1 to 3, wherein the network node is further caused to: receive an identifier of the user equipment from a network node of the second cell or from the user equipment; and acquire, based on the identifier of the UE, the plurality of second cell RRC profiles from a database accessible to the network node of the first cell.

6. The network node of any of claims 1 to 5, wherein acquiring the information comprises acquiring at least one identifier of the plurality of second cell RRC profiles and acquiring the plurality of second cell RRC profiles based on the at least one identifier.

7. The network node of any of claims 1 to 6, wherein the network node is further caused to: acquire information of a particular second cell RRC profile among the plurality of second cell RRC profiles; determine a particular first cell RRC profile based on the particular second cell RRC profile; communicate with the user equipment in the first cell based on the particular first cell RRC profile.

8. The network node of claim 7, wherein the network node is further caused to: acquire the information of the particular second cell RRC profile in a handover request from a network node of the second cell; generate a handover command, the handover command comprising information of the particular first cell RRC profile; and transmit the handover command towards the user equipment.

9. The network node of claim 7, wherein the network node is further caused to: acquire the information of the particular second cell RRC profile in a resume request message from the user equipment; generate a connection resume message comprising information of the particular first cell RRC profile; and transmit the connection resume message to the user equipment.

10. The network node of any of claims 7 to 9, wherein the particular second cell RRC profile is the latest RRC profile associated with the user equipment in the second cell.

11. The network node of any of claims 1 to 10, wherein each of the plurality of second cell RRC profiles is identified with an identifier, wherein the identifiers of the plurality of second cell RRC profiles are maintained in the plurality of first cell RRC profiles such that a given first cell RRC profile is assigned with an identifier that is the same as the identifier of the second cell RRC profile which was used as a basis for generating the given first cell RRC profile.

12. A network node of a second cell, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network node at least to: provide, to a network node of a first cell, information of a plurality of second cell RRC profiles associated with a user equipment in the second cell, wherein each RRC profile comprises a set of parameters for at least RRC configuration of the user equipment.

13. The network node of claim 12, wherein providing the information comprises providing to the network node of the first cell the sets of parameters associated with the plurality of second cell RRC profiles and a profile-specific identifier for each of the plurality of second cell RRC profiles.

14. A user equipment, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the user equipment at least to: receive, from a network node of a first cell, information of a plurality of first cell radio resource control (RRC) profiles associated with the user equipment in the first cell, wherein each RRC profile comprises a set of parameters for at least RRC configuration of the user equipment; and select one of the plurality of first cell RRC profiles for communication in the first cell.

15. The user equipment of claim 14, wherein one of: the information is comprised in a handover command, and user equipment is further caused to receive the handover command via a network node of a second cell during a handover of the user equipment from the second cell to the first cell; or the information is comprised in a connection resume message; and the user equipment is further caused to receive the connection resume message from the network node of the first cell during a connection resume with the network node of the first cell.