Access Network Node, UE, and Method

Abstract

A method is disclosed that is performed by a first network entity including a RAN device (5) in a communication system, the method including obtaining information regarding a mobility state of a UE (3), determining a mobility specific configuration for the UE (3) based on the mobility state, and providing configuration information for configuring the UE (3) with the mobility specific configuration.

Description

Technical Field

[0001] The present disclosure relates to a communication system. The present disclosure is particularly, but not limited to, related to a wireless communication system and its apparatus operating in accordance with 3rd Generation Partnership Project (3GPP (registered trademark)) standards or equivalent standards or derived standards (including LTE-Advanced and next generation or 5G networks). The present disclosure is particularly related to, but not necessarily exclusive to, improved apparatuses and methods for supporting various different low-mobility or (quasi-) stationary user equipments (UEs).

Background Art

[0002] Recent developments of 3GPP standards are referred to as Long Term Evolution (LTE) of the Evolved Packet Core (EPC) network and the Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), and are generally also referred to as "4G". Further, the terms "5G" and "new radio" (NR) refer to evolved communication technologies expected to support various applications and services. Various details of 5G networks are described, for example, in "NGMN 5G White Paper" V1.0 (Non-Patent Document 1). 3GPP plans to support 5G through the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and 3GPP NextGen core network.

[0003] In the 3GPP standard, a NodeB (or an eNB in LTE, a gNB in 5G) is a base station (or a "radio access network (RAN) node") to which a communication device (referred to as a user equipment or "UE") connects, connects to the core network, and communicates with other communication devices or remote servers. For simplicity, in this application, the term base station, RAN node, or simply "RAN" is used to refer to such a device or equivalent apparatus that provides access to the network.

[0004] For example, in the current 5G architecture, the structure of the gNB may be split into two or more parts. In some RAN implementations, there are two parts known as a Central Unit (CU) or gNB-CU, sometimes also referred to as an "aggregation unit", and a Distributed Unit (DU) or gNB-DU, which are connected by an F1 interface. This enables the use of a "split" architecture that separates a typical "upper" CU layer (such as, but not necessarily limited to, the Packet Data Convergence Protocol (PDCP) layer and the Radio Resource Control (RRC) layer) from a "lower" DU layer (such as, but not necessarily limited to, the Radio Link Control (RLC) layer, the Media Access Control (MAC) layer, and the Physical (PHY) layer) between a particular CU and one or more DUs connected and controlled by that CU via the F1 interface. Thus, for example, while some of the upper layer CU functions of the gNB can be implemented centrally (e.g., by a single processing unit, or in a cloud-based or virtualized system), the lower layer DU functions can be held locally and individually for each gNB.

[0005] In the recently proposed RAN distributed architecture, in addition to the CU and DU, the concept of a Radio Unit (RU), sometimes also referred to as a "remote unit", has been introduced. In this architecture, the RU is responsible for processing the digital front end (DFE), the digital beamforming function, and typically the functions of the lower part of the PHY layer, while the DU typically processes the upper part of the PHY layer, the RLC layer, and the MAC layer. The CU of this architecture continues to be responsible for controlling one or more DUs (each DU corresponding to a different respective gNB) and processing the signaling of the upper layers (typically the RRC layer and the PDCP layer).

[0006] The actual functional split between the CU and DU (and, optionally, the RU) of these distributed architectures is flexible, and the functions can be optimized according to various use cases. In fact, with the split architecture, 5G networks can utilize different distributions of the protocol stack between the CU and DU (and, optionally, the RU) depending on, for example, the availability of the midhole and the network design.

[0007] The choice of how to split the functions within the architecture depends, among other things, on factors related to the radio network deployment scenario, constraints, and the intended supported use cases. The main considerations include the need to support specific service qualities for each provided service and for real-time / non-real-time applications, the support of specific user density and load demands in a given geographical area, and the transport network available at various performance levels.

[0008] In the effort to transition from vendor-specific deployments to deployments where hardware and software components from different vendors are interoperable and can be used in combination, the migration to so-called "open" interfaces between various elements of the RAN has been promoted. In previous generations, the RAN incorporated a controller responsible for RAN orchestration and management. With the development of 4G, the overall network architecture became flatter, and in order to achieve an optimal subscriber experience, base stations were expected to communicate with each other using a standardized inter-base station (X2) interface and handle resource allocation. However, although the X2 application protocol is almost standardized, various RAN vendors still produce their own variations of the X2 interface, making it difficult for mobile network operators (MNOs) to use equipment from multiple RAN vendors in a specific location. Recently, there has been a movement back to the concept of a controller that enables the separation of hardware and software and the development of open interfaces between them. This movement is known as "open RAN" and is particularly relevant to 5G and future generations, but is also applicable to previous generations of RAN development.

[0009] In the context of 5G, in many 5G scenarios where low latency is required, the implementation of 5G concepts such as Control and User Plane Separation (CUPS), functional RAN splitting, and network slicing requires a combination of advanced RAN virtualization and software defined networking (SDN). This has led to the concept of the RAN Intelligent Controller (RIC), which is being developed as part of the open RAN movement. The RIC consists of a Non-Real-time (non-RT) RIC (supporting tasks that require a latency greater than 1 second) and a Near-Real time RIC (latency less than 1 second).

[0010] Near-RT RIC is responsible for load balancing, RB management, and interference detection and mitigation, which are controlled per UE. To facilitate this, Near-RT RIC provides a cloud-based infrastructure for controlling a collection of distributed RAN nodes (eNB, gNB, CU, DU) within a specific geographical area via an open "southbound" interface (E2) protocol. Near-RT RIC also provides open "northbound" interfaces (A1 and O1) to the service management and orchestration (SMO) framework for the operator. Near-RT RIC hosts microservice-based applications called xApps that can execute on the Near-RT RIC and collect near-real-time information (UE-based or cell-based) using the E2 interface. These xApps cover functions such as mobility management, admission control, and interference management. In addition, Near-RT RIC applies network policies via the E2 interface to the radio and provides advanced control functions aimed at enhancing efficiency and providing improved radio resource management (RRM). These control functions utilize an analysis and data-driven approach that includes advanced machine learning (ML) / artificial intelligence (AI) tools to improve resource management capabilities. The control of Near-RT RIC over the E2 nodes (e.g., eNB, gNB, CU, or DU, etc.) is guided by policies and data provided from the Non-RT RIC via the A1 interface. The allocation of RRM functions between Near-RT RIC and the E2 nodes is controlled by Near-RT RIC according to the capabilities of the E2 nodes. For example, Near-RT RIC can monitor, suspend / stop, override, or control the nodes via Non-RT RIC-compliant policies.Near-RT RIC can be deployed in various ways, such as, for example, virtual network function (VNF), a set of virtual machines (VMs), or cloud native function (CNF).

[0011] Non-RT RIC forms part of the SMO framework and connects to Near-RT RIC for RAN management and optimization. The network management applications of Non-RT RIC receive data from the DU and CU provided in a standardized format via the A1 interface and operate based on it. Non-RT RIC functions include configuration management, device management, fault management, performance management, and lifecycle management for all network elements within the network. Since all new RUs are self-configured by Non-RT RIC, the need for manual intervention is reduced. By providing insights into network operation by Non-RT RIC, the MNO can better understand and, as a result, more appropriately optimize the network by applying pre-determined service and policy parameters. Non-RT RIC supports intelligent RAN optimization and can optimize the RAN efficiently and effectively by providing policy-based guidance, model management, and enrichment information to Near-RT RIC. Non-RT RIC can identify appropriate RAN optimization actions that can use the SMO service by using data analysis and machine learning (ML) / artificial intelligence (AI) training / inference.

[0012] To enable the RIC to customize network optimization for each network environment and use case, separating the functions of the southbound interface and the northbound interface allows for more efficient and cost-effective radio resource management of real-time and non-real-time functions.

[0013] For simplicity, in this application, the terms mobile device, user device, or UE are used to refer to any communication device that can be connected to a core network via one or more base stations (in a split / distributed architecture or otherwise). Although this application may refer to a "mobile" device in the specification, the technology described is applicable to any (mobile and / or normally stationary) communication device that can be connected to a communication network to send and receive data, regardless of whether such a communication device is controlled by human input or by software instructions stored in memory.

[0014] While traditional cellular phone - form UEs remain the dominant device type in the market, 3GPP is working towards the goal of "connecting everything everywhere" as communication technology evolves towards 5G and future generations. This has led to an increase in both the diversity of device types and the relative proportion of all connected devices that those device types comprise. Such device types can include, for example, devices that utilize specific advancements in communication technology such as Ultra Reliable Low Latency Communication (URLLC), Device - to - Device (D2D) communication and related technologies (e.g., Vehicle - to - Vehicle (V2V), Vehicle - to - Everything (V2X), and Vehicle - to - Infrastructure (V2I)), Integrated Access Backhaul (IAB), as well as Internet of Things (IoT) - related technologies such as NarrowBand - Internet of Things (NB - IoT) and Industrial Internet of Things (IIoT), and Virtual Reality (VR), Extended Reality (XR), and Augmented Reality (AR) applications, and advancements related to Non - Terrestrial Network (NTN) technology. R LLC), Device - to - Device (D2D) communication and related technologies (e.g., Vehicle - to - Vehicle (V2V), Vehicle - to - Everything (V2X), and Vehicle - to - Infrastructure (V2I)), Integrated Access Backhaul (IAB), as well as Internet of Things (IOT) - related technologies such as NarrowBand - Internet of Things (NB - IoT) and Industrial Internet of Things (IIoT), and Virtual Reality (VR), Extended Reality (XR), and Augmented Reality (AR) applications, and advancements related to Non - Terrestrial Network (NTN) technology.

[0015] Many basic functions designed with traditional mobile phones in mind are complex and may incur unwanted and unnecessary costs because they are not strictly necessary for all devices, especially (quasi)-stationary devices such as smart meters or Fixed Wireless Access (FWA). Although dedicated configurations are available for low-mobility UEs, the RAN device (e.g., gNB) needs to have knowledge of the UE's mobility in order to properly configure the RAN device and / or the UE. To avoid inappropriate configurations being misused, a generally cautious configuration approach is adopted, and as a result, conservative configurations are often used.

[0016] Examples of procedures for using configurations related to the UE's mobility state include the following. · Paging - For example, a configuration that makes the size of the paging area or tracking area (TA) a small TA or a large TA, · Periodic or regular Tracking Area Update (TAU) and / or Routing Area Update (RAU) - For example, a configuration that makes the period of TAU or RAU in the UE a short period or a longer period, · Handover - For example, the measurement configuration of a low-mobility UE compared to a high-mobility UE, · Timing Advance maintenance - For example, a configuration of the Time Alignment Timer (TAT) from a short TAT to an infinite TAT, · Channel Adaptive Scheduling - For example, a configuration of reporting buffer status reports (BSR) and / or power headroom reports (PHR) in the UE, and / or · Power control - For example, a configuration that enables or disables open loop power control (OLPC) and / or closed loop power control (CLPC).

[0017] Currently, two different types of mobility information are identified.

[0018] The first type of mobility information (Mobility Information #1) basically defines three mobility states: normal, medium, and high, based on the number of cell reselections during a configured period for two parameters. The two parameters are N CR_M that specifies the maximum number of cell reselections to enter the medium mobility state, and N CR_H that specifies the maximum number of cell reselections to enter the high mobility state. During a certain period within the period specified to evaluate at least one cell reselection allowance (T CRmax ), if the number of cell reselections is less than N CR_M , the UE is determined to be in the normal mobility state. If the number of cell reselections within this period is greater than or equal to N CR_M and less than or equal to N CR_H , the UE is determined to be in the medium mobility state. If the number of cell reselections within this period is greater than N CR_H , the UE is determined to be in the High mobility state. The determined mobility state is used for speed-dependent scaling of cell reselection parameters. In fact, these specified mobility states are defined for the advantage of ensuring faster cell reselection for UEs moving faster (i.e., medium / high).

[0019] The second type of mobility information (Mobility Information #2) includes a mobility history report (in the form of a mobilityHistoryReport Information Element (IE)) that contains a list of visited cell information (in the form of a VisitedCellInfoList IE). The list of visited cell information includes mobility history information for the most recently visited up to 16 cells, and / or information identifying the time spent in any cell selection state in NR or E-UTRA and / or the time camped in any cell state. The most recently visited cell is stored first in the list. This list includes cells visited in the idle state, inactive state, or connected state (RRC_IDLE, RRC_INACTIVE, and RRC_CONNECTED) in the case of NR, and cells visited in the idle state or connected state (RRC_IDLE and RRC_CONNECTED) in the case of E-UTRA. This information is reported to the network upon request via a request / response procedure (e.g., UE Information Request from the RAN device and the related UE Information Response message from the UE).

Prior Art Documents

Non-Patent Documents

[0020]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0021] The above-described first and second specific mobility information typically targets traditional mobile phone-type devices that exhibit at least some movement. However, there are many problems in using such mobility information to enhance configuration flexibility. First, for example, a significant delay may occur related to the long observation time window required to obtain the information needed to optimize certain high-level parameters such as paging / tracking areas. Second, such a configuration assumes a certain level of UE capabilities that may not match the actual UE capabilities (especially in the case of low-cost and reduced-capability UEs, which are often used in (quasi)-stationary scenarios). For example, obtaining mobility information assumes that the UE has the ability to store the required information and the associated reporting capabilities, which may not be available for low-end devices such as smart meters. Third, the information is at the cell level and relatively granular.

[0022] Recently, there have been several discussions about mechanisms for detecting low UE mobility based on the measurement of reference signal received power (RSRP) and / or reference signal received quality (RSRQ). Specifically, the network can configure the UE using RSRP / RSRQ-based (e.g., threshold-based) low mobility criteria that can be used to detect the low mobility UE state. If the UE's mobility is determined to be low, the UE can perform relaxed RRM measurements for intra / inter frequency cells. There is also a discussion about whether further RRM measurement relaxation can be applied to the neighboring cells of "stationary" UEs, but since its definition is still under discussion, it is not yet clear what constitutes a "stationary" UE. One option is to define a stationary UE based on low mobility criteria but use different thresholds specifically configured to identify stationary UEs. Another option is to use the "stationary" property in the UE's subscription information, but no consensus has been reached on whether such a property should be included in the UE's subscription.

[0023] For the detection of low mobility or stationary devices based on corresponding low mobility or stationary RSRP / RSRQ-based criteria, some flexibility in configuration is considered, but this is only used for relaxation of RRM measurements and cannot be used for other optimization tasks by the network. Furthermore, it is not clear how the stationary property (even if introduced in the UE's subscription information) can be initialized and updated within the UE subscription information.

[0024] Therefore, an approach that supports higher flexibility is needed to adaptively configure devices such as user equipment and RAN equipment in an optimal manner based on the mobility characteristics of the devices.

[0025] The present disclosure aims to provide an improved apparatus and method that addresses one or more of the above problems, or at least partially improves them, or at least partially contributes to meeting the above needs.

Means for Solving the Problems

[0026] In one example described herein, a method executed by a first network entity in a communication system includes obtaining information regarding a mobility state of a user equipment (UE), determining a mobility-specific configuration of the UE based on the mobility state, and providing configuration information for configuring the UE with the mobility-specific configuration.

[0027] The method includes performing authentication of the information regarding the mobility state of the UE before determining the mobility-specific configuration, and the determining may be performed when the authentication is successful. The verification may be performed based on a comparison between a predicted position and / or predicted movement of the UE and position information and / or measurement data of the UE collected from the UE. The authentication may be performed based on a comparison between the information regarding the mobility state of the UE and other information regarding the mobility state of the UE generated by the first network entity or another network entity.

[0028] The information regarding the mobility state of the UE includes information identifying the current and / or predicted mobility state of the UE, and the determining may be performed based on the current and / or predicted mobility state of the UE. The information regarding the mobility state of the UE may include an indicator for indicating whether the UE is stationary or near stationary, and / or an indicator for indicating one of a plurality of mobility categories into which the movement of the UE is categorized. The information regarding the mobility state of the UE may include an indicator for indicating a configuration priority regarding mobility. The information regarding the mobility state of the UE may include at least any one of a Radio Resource Control (RRC) message, a UE Assistance Information message, a Media Access Control (MAC) Control Element (CE) message, and a Non-Access Stratum (NAS) message. The mobility-specific configuration of the UE may include any one, or any combination, of a mobility-specific measurement configuration, a mobility-specific Power Control (PC) configuration, a mobility-specific Power Headroom Reporting (PHR) configuration, a mobility-specific Time Alignment Timer configuration, and / or a mobility-specific paging area / tracking area configuration. Providing the configuration information may be performed using either Radio Resource Control (RRC) signaling or an RRC Reconfiguration message. The information regarding the mobility state of the UE may be included in a UE profile.

[0029] The obtaining may include receiving, from a second network entity, the information regarding the mobility state of the UE, and the providing may include providing deferred configuration information to the UE or a third network entity. The obtaining may include receiving, from the UE, the information regarding the mobility state of the UE, and the providing may include providing the configuration information to the UE or a second network entity.

[0030] The second network entity may include at least any one of a Radio Access Network (RAN) Intelligent Controller (RIC) entity, a non-real time RIC, and a near-real time RIC. The second network entity may include at least any one of a core network control plane function, a Unified Data Management (UDM) function, and a Home Subscriber Server (HSS). The second network entity may include an Operations, Administration and Maintenance (OAM) function.

[0031] The first network entity may include at least any one of a Radio Access Network (RAN) device, a Central Unit (CU) of a base station, a Distributed Unit (DU) of a base station, and an integrated base station. The first network entity may include at least any one of a Radio Access Network (RAN) Intelligent Controller (RIC) entity, a near-real time RIC, and a non-real time RIC. The first network entity may include at least any one of a core network control plane function and a Session Management Function (SMF).

[0032] In one example described in this specification, a method performed by a user equipment (UE) in a communication system is disclosed, the method including providing information regarding the mobility state of the UE to a network entity to support determining a mobility-specific configuration of the UE.

[0033] The method may include receiving, from the network entity or another network entity, configuration information for configuring the UE with the mobility-specific configuration. The information regarding the mobility state of the UE may include information identifying a device type of the UE corresponding to the mobility state of the UE. The information regarding the mobility state of the UE may include information identifying a location of the UE. The information regarding the mobility state of the UE may include at least any one, or at least any combination of, information identifying a time or period when the UE is expected to be stationary, information identifying a location where the UE is expected to be stationary, information identifying a time or period when the UE is expected to be moving, information identifying a destination or source location where the UE is expected to be moving, information identifying a geographical area within which the movement of the UE is expected to be restricted, and / or information identifying a reliability of the information regarding the mobility state of the UE. The information regarding the mobility state of the UE includes information identifying a reliability of the information regarding the mobility state of the UE, and the determining may be performed based on the reliability.

[0034] In one example described in this specification, when a program is executed by a computer device, a computer program product including instructions for causing the computer to execute one of the steps of the above method is provided.

[0035] In an example described in this specification, there is disclosed a first network entity for a communication system, comprising means for obtaining information regarding the mobility state of a user equipment (UE), means for determining a mobility-specific configuration of the UE based on the mobility state, and means for providing configuration information for configuring the UE with the mobility-specific configuration.

[0036] In an example described in this specification, there is disclosed a user equipment (UE) for a communication system, comprising means for providing information regarding the mobility state of the UE to a network entity to support determining a mobility-specific configuration of the UE.

[0037] Aspects of the present disclosure are set forth in the appended independent claims. Optional but advantageous features are set forth in the appended dependent claims. Aspects of the present disclosure extend to computer program products such as computer-readable storage media storing operational instructions to program a programmable processor to perform the corresponding system, apparatus, and method described in the above or in the aspects described in the claims, and / or to program a computer suitably adapted to provide the apparatus described in any of the claims.

[0038] Each feature disclosed in this specification (including the claims) and / or shown in the drawings may be incorporated into the present disclosure independently of (or in combination with) other disclosed and / or illustrated features. In particular, without limitation, any feature of a claim dependent on a particular independent claim may be introduced into that independent claim in any combination or individually.

Brief Description of the Drawings

[0039] Embodiments of the present disclosure will be described by way of example with reference to the following accompanying drawings.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

[0040] Overview With reference to FIG. 1, an exemplary communication system will be described by way of example only.

[0041] FIG. 1 schematically shows a mobile (“cellular” or “wireless”) communication system 1 to which embodiments of the present disclosure are applicable.

[0042] In communication system 1, user equipment (UE) 3-1, 3-2, 3-3 (e.g., mobile phones and / or other mobile devices) can communicate with each other via radio access network (RAN) equipment 5 that operates according to one or more compatible radio access technologies (RAT). In the illustrated example, RAN equipment 5 comprises a distributed NR / 5G base station or "gNB" that operates one or more associated cells 9. Communication via base station 5 is typically routed through core network 7 (e.g., a 5G core network or an evolved packet core (EPC) network).

[0043] As will be understood by those skilled in the art, although three UEs 3 and one RAN device 5 are shown in FIG. 1 for illustrative purposes, this system will typically include other RAN devices and UEs when implemented.

[0044] Each RAN device 5 directly controls at least one associated cell, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, and / or distributed units). It will be understood that RAN device 5 can be configured to support both 4G and 5G, and / or any 3GPP or non-3GPP communication protocol.

[0045] In this example, the illustrated RAN device 5 comprises a distributed base station including a plurality of radio units (RU) 5a, a distributed unit (DU) 5b, and a central unit (CU) 5c. The CU 5c employs a separated control plane and user plane, and is itself divided into a control plane function (CU-CP) and a user plane function (CU-UP) that communicate with the DU via an F1-C logical interface and an F1-U logical interface (which together form the F1 interface (or "reference point")), respectively, and communicate with each other via an E1 logical interface.

[0046] The illustrated RAN device 5 is controlled by a RAN intelligent controller (RIC) 13 that includes a non-real time RIC (non-RT-RIC) 13-1 and a near-real time RIC (near-RT-RIC) 13-2 that communicate with each other via an A1 interface. The near-real time RIC 13-2 supports tasks that require short (less than 1 second) latency, and the non-real time RIC 13-1 supports tasks that can be executed with long (more than 1 second) Large latency. The near-RT RIC 13-2 is responsible for load balancing, resource (resource block (RB)) management, interference detection and mitigation, which are controlled for each UE. The non-RT RIC 13-1 forms part of the service management and orchestration (SMO) layer and communicates with the near-RT RIC 13-2 via the A1 interface for the management and optimization of the RAN device 5.

[0047] Although a distributed RAN device 5 is illustrated and described, it will be understood that the RAN device 5 may be provided in a non-distributed form, such as an integrated gNB or eNB, for example.

[0048] UEs 3 and their serving RAN devices 5 are connected via an appropriate air interface (e.g., the so-called "Uu" interface, etc.). Adjacent RAN 5 devices may be interconnected with each other via an appropriate inter-base station interface (the so-called "X2" interface, or "Xn" interface, etc.).

[0049] The core network 7 includes several logical nodes (or "functions") for supporting communications in the communication system 1. In this example, the core network 7 comprises several control plane functions (CPF) 10, and one or more user plane functions (UPF) 11. The CPF 10 includes one or more access and mobility management functions (AMF) 10-1, one or more session management functions (SMF) 10-2, one or more unified data management (UDM) functions 10-3, and several other functions 10-n (e.g., an authentication server function (AUSF) that facilitates 5G security processes, etc.).

[0050] The communication system also includes an OAM system 14 with one or more Operations, Administration and Maintenance (OAM) functions for provisioning and managing networks or elements within a broader communication system 1. OAM 14 can be responsible for storing and analyzing some radio-related measurement values and can perform some data analysis functions including some RAN analysis.

[0051] The RAN device 5 is connected to the core network nodes via appropriate interfaces (or "reference points"), such as the N2 reference point between the base station 5 and the AMF 10-1 for control signaling communication and the N3 reference point between the base station 5 and each UPF 11 for user data communication. Each UE 3 is connected to the AMF 10-1 via a logical non-access stratum (NAS) connection on the N1 reference point (similar to the S1 reference point in LTE). It will be understood that N1 communication is transparently routed through the RAN device 5.

[0052] At least one UPF 11 is connected to an external data network (e.g., an IP network such as the Internet) 20 via a reference point N6 for user data communication.

[0053] The AMF 10-1 performs mobility management-related functions, maintains an AS signaling connection with each UE 3, and manages UE registration. The AMF 10-1 receives user information sent via the network and transfers that information to the SMF 10-2. The AMF 10-1 is also responsible for paging management. N AS signaling connection to maintain and manage UE registration. The AMF 10-1 receives user information sent via the network and transfers that information to the SMF 10-2. The AMF 10-1 is also responsible for paging management.

[0054] The SMF10-2 provides a session management function (which forms part of the MME function of LTE), and further combines some control plane functions (provided by the serving gateway and packet data network gateway of LTE). The SMF10-2 uses the user information provided via the AMF10-1 to determine which session manager is optimally assigned to the user. The SMF10-2 may actually be regarded as a gateway from the user plane to the control plane of the network. Also, the SMF10-2 assigns an IP address to each UE3.

[0055] The UDM function 10-3 manages network user data in a single centralized element. For example, the UDM10-3 manages data for access authorization, user registration, and data network profiles, and provides subscriber data to the SMF. The UDM function 10-3 is typically provided as a cloud-native function and is typically paired with one or more user data repositories (UDRs) that store user data such as customer profile information, customer authentication information, and encryption keys for information. Effectively, the user information is stored in the UDR, and the UDM function 10-3 retrieves the data, sends it to other network functions, and generally manages it. The UDM function 10-3 uses microservices to communicate between the user plane and the control plane.

[0056] UE (「mobility」) profile Advantageously, the communication system 1 adopts a dedicated UE-specific mobility-related UE profile and uses this to easily identify the mobility state of the UE 3 to which the UE profile pertains. The UE profile may include, for example, a mobility profile that explicitly identifies whether the UE 3 is a fixed device, a low-mobility device, or a high-mobility device, etc. The UE profile may include information regarding the mobility state of the UE. Alternatively or additionally, the UE profile (e.g., information regarding the mobility state of the UE) may include a device profile that explicitly identifies the device type of the UE 3 (e.g., the device is an internet-of-things (IOT) device, or a fixed wireless access (FWA) device, etc. The device type is the device type of the UE corresponding to the mobility state of the UE). The UE profile may generally be referred to as a "mobility profile" or a "device profile".

[0057] In some examples, to be described in more detail later, the UE profile is constructed by the UE 3 or preconfigured (e.g., hard-written) in the memory of the UE 3. In some examples, to be described in more detail later, the UE profile is constructed by a higher-level (core) network entity such as the near-RT RIC 13-2, non-RT RIC 13-1, UDM 10-3, or OAM 14, and / or an integrated RAN device, or preconfigured (e.g., hard-written) in its memory. These different possibilities will be described as different examples later, but are not mutually exclusive, and it will be understood that both the UE 3 and one or more network entities may be able to construct the UE profile (or different elements thereof).

[0058] As described above, the information for forming the UE profile may be pre-configured (e.g., hard-written) in the memory of the UE 3 and / or the network entity. This pre-configured information may form all or only a part of the information for forming the UE profile. The pre-configured information can be explicitly identified, for example, as the UE 3 being a "mounted" or "stationary" device. When the information is constructed at the UE 3 or the network entity, artificial intelligence (AI) / machine learning (ML)-based tools may be used to construct a profile based on the prediction of mobility based on other forms of data.

[0059] These AI / ML tools may include, for example, a trained artificial neural network or other similar AI models or tools that receive one or more inputs of information transmitted (or derived from such information) from the UE 3 and generate at least one output for forming a UE ("mobility") profile (or information for forming such a profile) from these inputs.

[0060] For example, possible inputs include positioning information (e.g., Global Positioning System (GPS) information, or other information representing the location of the UE (such as the identity of the serving cell, etc.)), information identifying one or more visited cells (e.g., information identifying the currently visited cell and / or one or more previously visited cells), measurement results (e.g., RSRP and / or RSRQ associated with the serving cell and / or one or more neighboring cells), information representing records of handovers (and / or cell (re)-selections), and / or time and / or date in a suitable format (such as Coordinated Universal Time (UTC)) associated with one or more other items of the input information.

[0061] Possible outputs for forming a UE profile (e.g., information regarding the mobility state of the UE) include, for example, information identifying the current and / or expected mobility state or mobility category associated with the UE (e.g., whether the device is stationary, moving within a narrow area, moving within a wide area, and / or moving between known positions, etc.), whether the UE is moving in an identifiable pattern if the UE is moving, information representing the identified (or expected) movement pattern of the UE (e.g., information identifying the expected position or area, and / or the expected mobility state or category at different times and / or different dates), and / or a level of credibility or reliability associated with one or more other items of the output information (e.g., information identifying the confidence level of the information regarding the mobility state of the UE).

[0062] Advantageously, the UE profile is ultimately shared with RAN devices (e.g., gNB-CU and / or gNB-DU) and is used to simplify the handling of the UE (e.g., measurement configuration, power control (PC), power headroom reporting (PHR) configuration, time alignment timer (TAT) configuration, paging area / tracking area configuration, etc.) as needed, based on the mobility-related characteristics of the UE. The mobility-related profile of the UE may be provided to the RAN device 5 in any suitable manner, as part of the RAN-UE request / response procedure and / or as part of the radio resource control (RRC) signaling in the RRC connection establishment procedure.

[0063] The content of the UE profile may be relatively simple. For example, it may simply include information indicating that UE3 is a mounted device (therefore having no mobility). Optionally, the UE profile may also include information for identifying the location of UE3.

[0064] Nevertheless, the UE profile can be made more comprehensive, for example, indicating when and where UE3 is stationary or very likely to be stationary, or when and where UE3 is moving or very likely to be moving. Such information may be accompanied by a reliability indicator indicating the degree to which the profile or that part of the profile can be trusted (or "persists"). Examples of such parts of the profile are as follows. [Table 1]

[0065] The UE profile may also indicate that while UE3 is mobile, it is usually only mobile within the boundaries of a fixed area. For example, UE3 in the form of an item of medical equipment used in a hospital may have associated information included in the corresponding UE profile that identifies that UE3 is (usually) only used within the hospital grounds. Similarly, an industrial UE used and connected within a factory, warehouse, or distribution center may have associated information included in the corresponding UE profile that identifies that UE3 is (usually) only used within the location of that industry. In another example, an educational device used and connected in a school, university, or college may have associated information included in the corresponding UE profile that identifies that UE3 is (usually) only used within the location of that educational institution.

[0066] Network-based UE Profile In one example, which will be described in more detail later, the non-RT RIC 13-1 constructs a UE profile. This profile may be constructed based on information from several sources, including, for example, mobility information #1 (described at the beginning), measurement results provided by the UE 3 in an RRC measurement report (or multiple such reports), geographical location information provided by the UE 3 (e.g., as part of the measurement log of that UE 3), and / or other information.

[0067] The non-RT RIC 13-1 shares the UE profile with the most relevant near-RT RIC 13-2, for example, via the A1 interface (although it will be understood that it can be shared directly with RAN devices, such as gNB, eNB, gNB-CU, and / or gNB-DU).

[0068] More specifically, during the RRC connection establishment phase, the near-RT RIC 13-2 may check the UE mobility profile provided by the non-RT RIC 13-1 and notify the RAN device 5 of the current mobility state and / or the expected future mobility state. The RAN device 5 may use the received information to configure the UE 3 and / or communicate with the UE 3 appropriately. For example, the RAN device 5 may determine the UE's mobility-specific configuration based on the mobility state included in the UE profile and provide configuration information for configuring the UE with that mobility-specific configuration. The RAN device 5 may make this determination based on the reliability of the information about the UE's mobility state. The near-RT RIC 13-2 may (re)configure the UE 3 itself, for example, based on mobility prediction via the E2 interface with a RAN device (gNB DU 5b, gNB CU 5c, or an integrated gNB).

[0069] This example is described in the context of a RIC13-based solution contributed by non-RT RIC 13-1 and near-RT RIC 13-2. However, it will be understood that the UE profile may be constructed by any suitable network entity, such as UDM 10-3 and / or OAM 14, etc., and passed to the RAN device 5. Instead of non-RT RIC 13-1, near-RT RIC 13-2 may also (if applicable) construct the UE profile.

[0070] RRC / MAC Layer Provision of UE Profile In another example, to be described in more detail later, UE 3 constructs a UE profile. This profile may be constructed based on information from several sources, including, for example, mobility information #1 (described at the beginning), measurement results obtained by UE 3, geographical location information obtained at UE 3 (e.g., as part of the measurement log of that UE 3), and / or other information. This UE profile ル (or related information therefrom) may be provided to the RAN device 5 in response to connection setup and / or a change in the mobility state.

[0071] UE profile ル (or its related information) may be provided using Radio Resource Control (RRC) or media access control (MAC) signaling (e.g., within a MAC control element (CE)). For example, the UE profile ルThe information from [[ID=]] can be provided to the RAN device 5 directly or indirectly using an RRC message (such as a message like the RRC UE assistance information message) or a MAC CE as the initial (or updated) mobility assistance / preference information. The direct indicator may include, for example, a stationary indicator indicating that the UE3 is (quasi)-stationary (e.g., a single bit is set to "1" to indicate that the UE3 is (quasi)-stationary and set to "0" to indicate that the UE is not (quasi)-stationary (or vice versa)). The direct indicator may (or instead) include an indicator of one of a plurality of mobility categories (e.g., (quasi)-stationary, movement within a limited geographical area, movement between specific two points, random movement, low mobility, medium mobility, or high mobility, etc.). The indirect indicator may include, for example, a configuration preference related to mobility (e.g., a larger / infinite TAT is good, relaxed radio resource management (RRM) measurements are good, no (or few) measurement configurations are good, and no handover is good, etc.).

[0072] When the RAN device 5 adopts a CU-DU split architecture in which DU5b is responsible for the lower layer including the MAC layer and CU5c is responsible for the upper layer including the RRC, if the assistance / preference information is received by the gNB CU5c via an RRC message (such as a UE assistance message), the gNB CU5c may share the assistance / preference information with the DU5b via the F1 interface. Similarly, if the assistance / preference information is received by the gNB DU5b via a MAC CE message, the gNB DU5b may share the assistance / preference information with the CU5c via the F1 interface. The RAN device 5 (gNB CU 5c and / or gNB DU5b) may use the received information to determine an appropriate configuration of the UE.

[0073] NAS / Upper Layer Provisioning of UE Profile In another example, to be described in more detail later, similar to the above example, UE3 constructs a UE profile. However, unlike the above example, the UE reports / updates the profile to the core network (e.g., via a non-access stratum (NAS) message sent to AMF10-1 or an equivalent control plane entity). And this profile may optionally be stored in UDM10-3 (or HSS if such an HSS exists within the core network). And in this example, the UE profile becomes available at SMF10-2 and is used for the purpose of generating mobility-specific NAS configurations. For example, based on the UE profile, the core network 7 may optimize the NAS configuration for a particular UE to prioritize where to page the UE first based on an expectation of where the UE is located (e.g., a specific cell or an optimized paging area). Such an expectation may identify a single location (cell or optimized paging area), or a list of such locations sorted in descending order of reliability (or confidence level). Similarly, the core network may adjust or optimize the registration area associated with the UE based on information derived from the UE profile.

[0074] When the UE context is being set up, in this example, during the UE context setup phase, the UE profile (or a short term UE mobility state derived based on the UE profile) becomes available to the RAN device 5 for access stratum (AS) configuration. The AS configuration may, for example, configure the TAT of UE3 (long or infinite), disable the power control of UE3, and configure no measurement report / handover for UE3 (only release of the RRC connection since measurement report and handover actions cannot be performed).

[0075] Hybrid Example - UE and Network Involved in UE Profile Generation In another example, to be described in more detail later, both the UE3 and the network (e.g., non-RT RIC, near-RT RIC, UDM, OAM, or other network entities) are involved in the generation and update of the UE profile.

[0076] In one variation of this example, the network entity is involved in the authentication of the reported or updated UE profile constructed and reported by the UE3 (e.g., using NAS / upper layer signaling as described in the above example). This verification may be performed, for example, by comparing the expected location and / or expected movement of the UE3 based on the UE profile reported by the UE3 with the live location information and / or measurement data of that UE3 collected by the network from the UE3. The UE profile may be used if the authentication is successful, as described in the above example. Advantageously, this authentication may be performed within the OAM system since the OAM function 14 collects a lot of live network information, thereby enabling the actual location of the UE to be confirmed at the predicted location based on the UE profile (although it will be understood that such authentication may be performed elsewhere within the network).

[0077] In another variation of this example, both the network entity and the UE3 are involved in separately and concurrently constructing the UE profile of that UE3. And, as described in the above example, the UE profile may be used as the subject of authentication based on a comparison between the UE profiles respectively generated by the UE3 and the network entity, indicating that there is a sufficient (pre-defined) level of similarity between the UE profile generated by the UE and the UE profile generated by the network. The authentication may be performed by the network entity responsible for constructing the network-originating UE profile in the case of authentication by comparison (although it will be understood that such authentication may be performed elsewhere within the network).

[0078] User Equipment Figure 2 is a schematic block diagram showing the main components of the UE3 shown in Figure 1.

[0079] As shown, the UE3 has a transceiver circuit 231 operable to transmit signals to and receive signals from the RAN device 5 via one or more antennas 233. The UE3 has a controller 237 that controls the operation of the UE3. The controller 237 is associated with a memory 239 and coupled to the transceiver circuit 231. Although not necessarily required for its operation, the UE3 may of course have all the normal functions of a traditional UE3 (e.g., a user interface 235 such as a touch screen / keypad / microphone / speaker that enables direct control by the user and interaction with the user). This may be provided by any one or any combination of hardware, software, and firmware, as required. The software may be pre-installed in the memory 239 and / or downloaded, for example, via a communication network or from a removable data storage device (RMD).

[0080] In this example, the controller 237 is configured to control the overall operation of the UE3 by program instructions or software instructions stored in the memory 239. As shown, these software instructions include, among other things, an operating system 241, a communication control module 243, a UE management module 245, and a UE profile management module 247.

[0081] The communication control module 243 is operable to control communication between the UE 3 and its serving RAN device 5 (as well as other communication devices connected to the RAN device 5, such as additional UEs and / or core network nodes). The communication control module 243 is configured to overall process uplink communication transmitted by the UE towards the network and process the reception of downlink communication from the network.

[0082] The UE management module 245 is responsible for managing the overall operation of the UE and the overall performance of tasks required for the UE. These tasks include, among others, generation and transmission of appropriate messages using appropriate signaling application protocols such as, but not limited to, RRC signaling, MAC signaling, and NAS signaling, performance of measurements (e.g., RSRP and / or RSRQ measurements), generation of associated measurement reports for transmission to the RAN device 5 if necessary, acquisition and reporting of location, cell selection and reselection, monitoring of the number of cell (re)selections for identifying the mobility state (e.g., mobility information #1), compilation of access cell information (e.g., mobility information #2), etc.

[0083] The UE profile management module 247 is responsible for performing functions related to the UE (mobility) profile, including the construction, update, storage, and maintenance of the UE profile, the extraction of appropriate assistance information from the current UE profile stored in the memory 239, or the generation of configuration priority information based on its current UE profile, and the provision of assistance / priority information and / or the UE profile itself to the UE management module 245 for transmission to the RAN device 5 and / or the core network or other network entities using appropriate signaling, if applicable. It will be understood that in some implementations, the UE 3 may not implement at least some of these functions. For example, if the UE 3 profile is generated only on the network side, the UE profile management module 247 may be configured to provide any information necessary to support profile generation within the network (e.g., by providing pre-configured mobility-related information regarding the mobility state and / or device type of the UE 3 (e.g., IoT, FWA, mounted, etc.)).

[0084] Radio Access Network (RAN) equipment (RU) FIG. 3 is a schematic block diagram showing the main components of the RU 5a of the RAN device 5 of the communication system 1 shown in FIG. 1. As shown, the RU 5a transmits signals to a communication device (such as UE 3) via one or more antennas 353 (for example, an antenna array / massive antenna) and receives signals from the communication device, and transmits signals to the DU 5b of the RAN device 5 and receives signals from the DU 5b via a DU interface 354 (for example, including a DU-RU interface, etc.). The RU 5a has a transceiver circuit 351. The RU 5a has a controller 357 that controls the operation of the RU 5a. The controller 357 is associated with a memory 359. Software may be pre-installed in the memory 359 and / or may be downloaded, for example, via the communication network 1 or from a removable data storage device (RMD). The controller 357 is configured to control the overall operation of the RU 5a by program instructions or software instructions stored in the memory 359 in this example.

[0085] As shown, these software instructions include, among other things, an operating system 361, a communication control module 363, a DU-RU module 368, and an RU management module 372.

[0086] The communication control module 363 is operable to control communication between the RU 5a and the UE 3 and between the RU 5a and the DU 5b. The communication control module 363 is configured to overall control the reception of signals corresponding to uplink communication from the UE 3 at the physical layer level and process the transmission of downlink communication to the UE 3 at the physical layer level.

[0087] The DU-RU module 368 is responsible for proper processing of signals received from the DU 5b or transmitted to the DU 5b via at least one DU (for example, DU-RU) interface 354.

[0088] The RU management module 372 is responsible for managing the overall operation of RU5a and the overall performance of the tasks required for RU5a.

[0089] Although RU5a is not described as having specific functions related to the UE profile, it will be understood that RU5a receives, processes, and transfers signaling related to the UE profile to DU5b (e.g., carrying UE profile and / or assistance / priority information extracted or derived based on the UE profile to DU5b, and carrying configuration information based on the UE profile from DU5b to UE3). In the functional split between RU5a and DU5b, it is also possible for RU5a to perform some or all of the UE profile-related operations described herein as being performed at DU5b. It will be understood that the functions of RU5a may be integrated with the functions of DU5b in a more integrated DU5b, or may be integrated with the functions of DU5b and CU5c in a fully integrated gNB5.

[0090] RAN device (DU) FIG. 4 is a schematic block diagram showing the main components of DU5b of the RAN device 5 of the communication system 1 shown in FIG. 1. As shown, DU5b has a transceiver circuit 451 for transmitting signals to and receiving signals from a communication device (such as UE3) via RU5a and an associated DU-RU interface 453, for transmitting signals to and receiving signals from CU5c of the RAN device 5 via a CU interface 454 (which can include, for example, an F1 interface split into an F1-U for the user plane and an F1-C for control plane signaling, respectively), and for transmitting signals to and receiving signals from RIC13 (in particular, near-RT RIC13-2) via an RIC interface 452 (which includes, for example, an E2 interface).

[0091] DU5b has a controller 457 that controls the operation of DU5b. The controller 457 is associated with a memory 459. Software may be pre-installed in the memory 459 and / or may be downloaded, for example, via the communication network 1 or from a removable data storage device (RMD). The controller 457 is configured to control the overall operation of DU5b by program instructions or software instructions stored in the memory 459 in this example.

[0092] As shown, these software instructions include, among other things, an operating system 461, a communication control module 463, an F1 module 465, an E2 module 467, a DU-RU module 468, a DU management module 472, and a UE profile management module 473.

[0093] The communication control module 463 is operable to control communication between DU5b and at least one RU5a (thus, between DU5b and UE3), between DU5b and CU5c, and between DU5b and RIC13 (particularly near-RT RIC13-2). The communication control module 463 is configured to overall control the reception of signals corresponding to uplink communication from UE3 and process the transmission of downlink communication addressed to UE3.

[0094] The F1 module 465 is responsible for appropriate processing of signals received from CU5c or transmitted to CU5c via at least one CU (e.g., F1) interface 454. These signals can be separated into user plane signals received from or transmitted to the CU-UP part of CU5c via the F1-U interface and control plane signals received from or transmitted to the CU-CP part of CU5c via the F1-C interface.

[0095] The E2 module 467 is responsible for the proper processing of signals received from or transmitted to the RIC 13 (particularly the near-RT RIC 13-2) via at least one RIC (e.g., E2) interface 452.

[0096] The DU-RU module 468 is responsible for the proper processing of signals received from or transmitted to the RU 5a via at least one RU (e.g., DU-RU) interface 453.

[0097] The DU management module 472 is responsible for the overall operation of the DU 5b and the management of the overall performance of the tasks required for the DU 5b. These tasks include the generation and transmission of appropriate messages using an appropriate signaling application protocol according to the functional split between the RU 5a, DU 5b, and CU 5c, such as the interpretation of received MAC signaling and the generation of MAC signaling for transmission.

[0098] The UE profile management module 473 is responsible for the reception and storage of UE profiles or related assistance / priority information from the UE 3 or other locations within the network, and for determining appropriate mobility-specific configurations based on the UE profile / assistance information / priority information for implementation in the UE 3 and / or the RAN device 5, and / or for providing configuration information for properly configuring the UE with a mobility-based configuration, (when applicable) including the execution of functions related to the UE (mobility) profile. It will be understood that in some implementations, the gNB-DU 5b may not implement at least some of these functions.

[0099] RAN device (CU) FIG. 5 is a schematic block diagram showing the main components of the CU 5c of the RAN device 5 of the communication system 1 shown in FIG. 1. As shown in the figure, the CU 5c transmits signals to the DU 5b and receives signals from the DU 5b via at least one DU interface 554 (including, for example, an F1 interface that can be split into F1-U and F1-C interfaces for user plane and control plane signaling, respectively), transmits signals to the functions of the core network 7 and receives signals from the functions of the core network 7 via at least one core network interface 555 (including, for example, N2 and N3 interfaces, etc.), and transmits signals to the RIC 13 (especially the near-RT RIC 13-2) and receives signals from the RIC 13 via an RIC interface 552 (including, for example, an E2 interface), and is provided with a transceiver circuit 551.

[0100] The CU 5c has a controller 557 that controls the operation of the CU 5c. The controller 557 is associated with a memory 559. Software may be pre-installed in the memory 559 and / or downloaded, for example, via the communication network 1 or from a removable data storage device (RMD). In this example, the controller 557 is configured to control the overall operation of the CU 5b by program instructions or software instructions stored in the memory 559.

[0101] As shown in the figure, these software instructions include, among others, an operating system 561, a communication control module 563, an F1 module 565, an E1 module 566, an E2 module 567, an N2 module 568, an N3 module 569, a CU-UP management module 571, a CU-CP management module 572, and a UE profile management module 573.

[0102] The communication control module 563 is operable to control the communication between the CU5c and at least one DU5b (thus, between the CU5c and the UE3), between the CU5c and the core network 7, and between the CU5c and the RIC13 (especially the near-RT RIC13-2). The communication control module 563 is configured to overall control the reception of signals corresponding to the uplink communication from the UE3 and process the transmission of the downlink communication addressed to the UE3.

[0103] The F1 module 565 is responsible for the appropriate processing of signals received from or transmitted to the DU5b via at least one DU (e.g., F1) interface 554. These signals may be separated into user plane signals received at or transmitted by the CU-UP part of the CU5c via the F1-U interface and control plane signals received at or transmitted by the CU-CP part of the CU5c via the F1-C interface.

[0104] The E1 module 566 is responsible for the appropriate processing of signals transmitted between the CU-UP part and the CU-CP part of the CU5c via the corresponding internal CU interface (e.g., E1).

[0105] The E2 module 567 is responsible for the appropriate processing of signals received from or transmitted to the RIC13 (especially the near-RT RIC13-2) via at least one RIC (e.g., E2) interface 552.

[0106] The N2 module 568 is responsible for the appropriate processing of signals received from or transmitted to the AMF10-1 via at least one corresponding core network interface (e.g., N2) 555.

[0107] The N3 module 569 is responsible for the proper processing of signals received from or transmitted to the core network user plane function 11 via at least one corresponding core network interface (e.g., N3) 555.

[0108] The CU-UP management module 571 is responsible for the overall operation of the CU-UP part of CU5c and the overall performance management of the tasks required for CU-UP.

[0109] The CU-CP management module 572 is responsible for the overall operation of the CU-CP part of CU5c and the overall performance management of the tasks required for CU-CP. These tasks include the generation and transmission of appropriate messages using the appropriate signaling application protocol according to the functional split between RU5a, DU5b, and CU5c, such as the interpretation of received RRC signaling and the generation of RRC signaling for transmission.

[0110] The UE profile management module 573 is responsible for receiving and storing UE profiles or related assistance / priority information from UE3 or other locations in the network, determining appropriate mobility-specific configurations based on the UE profile / assistance information / priority information for implementation in UE3 and / or RAN device 5, and / or providing configuration information for properly configuring the UE with a mobility-based configuration (if applicable). It is understood that in some implementations, gNB-CU 5c may not implement at least some of these functions.

[0111] RAN device (integrated gNB) FIG. 6 is a schematic block diagram showing the main components of an integrated gNB that can be used as the RAN device 5 in the communication system 1 shown in FIG. 1. As shown, the gNB 5 has a transceiver circuit 651 for transmitting signals to a communication device (such as UE3) via one or more antennas 653 (e.g., antenna array / massive antenna) and receiving signals from the communication device, and for transmitting signals to the functions of the core network 7 via at least one core network interface 655 (including, for example, N2 and N3 interfaces) and receiving signals from the functions of the core network 7.

[0112] The gNB 5 has a controller 657 for controlling the operation of the gNB 5. The controller 657 is associated with a memory 659. Software may be pre-installed in the memory 659 and / or downloaded via the communication network 1 or from, for example, a removable data storage device (RMD). The controller 657 is configured to control the overall operation of the gNB 5 by program instructions or software instructions stored in the memory 659 in this example.

[0113] As shown, these software instructions include, among other things, an operating system 661, a communication control module 663, an N2 module 668, an N3 module 669, a RAN control module 672, and a UE profile management module 673.

[0114] The communication control module 663 is operable to control the communication between the gNB 5 and the UE3 and between the gNB 5 and the core network 7. The communication control module 663 is configured to overall control the reception of uplink communication from the UE3 and process the transmission of downlink communication to the UE3.

[0115] The N2 module 668 is responsible for the proper processing of signals received from or transmitted to the AMF 10-1 via at least one corresponding core network interface (e.g., N2) 655.

[0116] The N3 module 669 is responsible for the proper processing of signals received from or transmitted to at least one core network user plane function 11 via at least one corresponding core network interface (e.g., N3) 655.

[0117] RAN Control Module 6 72 is responsible for the overall operation of the gNB 5 and the management of the overall performance of the tasks required for the gNB 5. In practice, in this integrated gNB, the RAN control module 6 72 executes the RAN control tasks executed by the RIC 13 in FIG. 1. However, it will be understood that the integrated gNB 5 with the functions of the RU 5a, DU 5b, and CU 5c can be configured to operate under the control of the RIC 13 rather than having the functions of the RIC 13 integrated into the gNB.

[0118] The UE profile management module 673 is responsible for performing functions related to the UE (mobility) profile, including (where applicable) the construction, update, storage, and maintenance of the UE profile, the reception and storage of UE profiles or related assistance / priority information from the UE 3 or other locations within the network, the determination of appropriate mobility-specific configurations based on the UE profile / assistance information / priority information for implementation in the UE 3 and / or the RAN device 5, and / or the provision of mobility-specific configuration information for properly configuring the UE using the mobility-specific configuration. It will be understood that in some implementations, the gNB 5 may not implement at least some of these functions.

[0119] Near-RT RIC FIG. 7 is a schematic block diagram showing the main components of the near-RT RIC 13-2 of the communication system 1 shown in FIG. 1. As shown, the near-RT RIC 13-2 has a transceiver circuit 751 for transmitting signals to and receiving signals from the CU 5c of the RAN device 5 via at least one gNB-CU interface (e.g., E2) 752, and for transmitting signals to and receiving signals from the non-RT RIC 13-1 via at least one non-RT RIC interface (e.g., A1) 753.

[0120] The near-RT RIC 13-2 has a controller 757 that controls the operation of the near-RT RIC 13-2. The controller 757 is associated with a memory 759. Software may be pre-installed in the memory 759 and / or downloaded, for example, via the communication network 1 or from a removable data storage device (RMD). In this example, the controller 757 is configured to control the overall operation of the near-RT RIC 13-2 by program instructions or software instructions stored in the memory 759.

[0121] As shown, these software instructions include, among other things, an operating system 761, a communication control module 763, an A1 module 769, an E2 module 770, a near-RT RIC management module 772, and a UE profile management module 773.

[0122] The communication control module 763 is operable to control communication between the near-RT RIC 13-2 and the RAN device 5 and between the near-RT RIC 13-2 and the non-RT RIC 13-1.

[0123] The A1 module 769 is responsible for the proper processing of signals received from or transmitted to the non-RT RIC 13-1 via at least one corresponding non-RT RIC interface (e.g., A1) 753.

[0124] The E2 module 770 is responsible for the proper processing of signals received from or transmitted to the CU 5c of the RAN device 5 via at least one gNB-CU interface (e.g., E2) 752.

[0125] The near-RT RIC management module 772 is responsible for the overall operation of the near-RT RIC 13-2 and the management of the overall performance of the tasks required by the near-RT RIC 13-2. For example, the near-RT RIC management module 772 may be responsible for tasks such as monitoring, pausing / stopping, overriding, or controlling the RAN device 5 via the non-RT RIC enabling policy. The near-RT RIC management module 772 may support tasks that require short (less than 1 second) latency for per-UE controlled load balancing, resource (resource block; RB) management, interference detection and mitigation.

[0126] The UE profile management module 773 is responsible for performing functions related to the UE (mobility) profile, including (where applicable) the construction, update, storage, and maintenance of the UE profile, the reception and storage of the UE profile or related assistance / priority information from other locations within the network including the UE3 or non-RT RIC 13-1, the determination of appropriate mobility-specific configurations based on the UE profile / assistance information / priority information for implementation at the UE3 and / or RAN device 5, and the provision of the UE profile, related assistance information, and / or mobility-specific configuration information to the RAN device 5 for use by the RAN in determining the mobility-specific configuration of the UE3 represented by the UE profile. It should be understood that in some implementations, the near-RT RIC 13-2 may not implement at least some of these functions.

[0127] Non-RT RIC Figure 8 is a schematic block diagram showing the main components of the non-RT RIC 13-1 of the communication system 1 shown in Figure 1. As shown, the non-RT RIC 13-1 has a transceiver circuit 851 for transmitting signals to and receiving signals from the near-RT RIC 13-2 via at least one near-RT RIC interface (e.g., A1) 852.

[0128] The non-RT RIC 13-1 has a controller 857 that controls the operation of the non-RT RIC 13-1. The controller 857 is associated with a memory 859. Software may be pre-installed in the memory 859 and / or downloaded, for example, via the communication network 1 or from a removable data storage device (RMD). The controller 857 is configured to control the overall operation of the non-RT RIC 13-1 by program instructions or software instructions stored in the memory 859 in this example.

[0129] As shown, these software instructions include, among other things, an operating system 861, a communication control module 863, an A1 module 869, a non-RT RIC management module 872, and a UE profile management module 873.

[0130] The communication control module 863 is operable to control the communication between the non-RT RIC 13-1 and the near-RT RIC 13-2 (and, in some cases, directly with the RAN device 5).

[0131] The A1 module 869 is responsible for the proper processing of signals received from or transmitted to the near-RT RIC 13-2 via at least one corresponding near-RT RIC interface (e.g., A1) 853.

[0132] The non-RT RIC management module 872 is responsible for managing the overall operation of the non-RT RIC 13-1 and the overall performance of the tasks required for the non-RT RIC 13-1. For example, the non-RT RIC management module 872 may be responsible for tasks such as configuration management, device management, fault management, performance management, and lifecycle management for all network elements in the network. The non-RT RIC management module 872 may support tasks that require a longer (greater than 1 second) latency.

[0133] The UE profile management module 873 is responsible for performing functions related to the UE (mobility) profile, including (where applicable) the construction, update, storage, and maintenance of the UE profile, the reception and storage of the UE profile or related assistance / priority information from the UE 3 or other locations within the network, and the provision of the UE profile and / or related assistance / priority information directly or indirectly via the near-RT RIC 13-2 to the RAN device 5 for use in determining the mobility-specific configuration of the UE 3 represented by the UE profile. It should be understood that in some implementations, the non-RT RIC 13-1 may not implement at least some of these functions.

[0134] Network Node Figure 9 is a schematic block diagram showing the main components of a general network node of the communication system 1 shown in Figure 1. The network node may be configured as any network entity such as a control plane function 10 (AMF, UDM, SMF, etc.) or an OAM function 14.

[0135] As shown, the network node has a transceiver circuit 951 for transmitting signals to and receiving signals from other network nodes via a corresponding (network) interface 954 (e.g., N1, N2, N5, N7, N8, N10, N11, N12, N13, N14, N15, and / or at least one OAM interface such as with the core network / RAN device, etc.).

[0136] The network node has a controller 957 that controls the operation of the network node. The controller 957 is associated with a memory 959. Software may be pre-installed in the memory 959 and / or downloaded, for example, via the communication network 1 or from a removable data storage device (RMD). In this example, the controller 957 is configured to control the overall operation of the network node by program instructions or software instructions stored in the memory 959.

[0137] As illustrated, these software instructions include, among other things, an operating system 961, a communication control module 963, one or more interface protocol modules 965, a network node management module 972, and a UE profile management module 973.

[0138] The communication control module 963 is operable to control communication between the network node and one or more other network entities in the communication system.

[0139] At least one interface protocol module 965 is responsible for proper processing of signals received from or transmitted to other network entities via at least one corresponding (network) interface 954.

[0140] One or more management modules 972 are responsible for managing the overall operation of the network node and the overall performance of the tasks required for that network node. For example, when the network node is the UDM 10-3, the tasks include tasks related to access authorization, user registration, and management of data for the data network profile, and provision of subscriber data to the SMF. When the network node is the OAM 14, the tasks include tasks related to provisioning and management of networks or elements within a broader communication system. When the network node is the AMF 10-1, the tasks include N maintaining the AS signaling connection with each UE 3, managing UE registration, receiving user information transmitted through the network, transferring that information to the SMF 10-2, managing paging, and other tasks related to mobility management functions. When the network node is the SMF 10-2, the tasks include determining which session manager is optimally assigned to the user using the user information provided via the AMF 10-1, assigning an IP address to each UE 3, and determining the NAS configuration (which may include the mobility-specific NAS configuration of the UE 3 related to a specific UE profile), and other tasks related to providing session management functions.

[0141] The UE profile management module 973 is responsible for performing functions related to the UE (mobility) profile, including constructing, updating, storing, and maintaining the UE profile, receiving and storing UE profiles or related assistance / priority information from the UE 3 or other locations within the network, and providing the UE profile and / or related assistance / priority information directly or indirectly to the RAN device 5 for use in generating the mobility-specific configuration of the UE 3 represented by the UE profile, where applicable. It will be understood that in some implementations, the network node may not implement at least some of these functions.

[0142] Network-based UE profile An example of a network-based UE profile procedure will be described with reference to FIGS. 10 and 11 as a mere example.

[0143] FIG. 10 is a simplified timing diagram showing two possible procedures (labeled (a) and (b)) for providing mobility-specific configurations to UE3.

[0144] In both exemplary procedures, non-RT RIC 13-1 constructs (or updates) a UE profile for a specific UE3 at S1010. And this (updated) UE profile (or assistance information derived therefrom, such as an indicator of the mobility state) is shared with near RT RIC 13-2 (e.g., by the A1 interface) at (S1012).

[0145] In the first exemplary procedure (a), after the RRC connection setup procedure is initiated by UE3, during the RRC connection setup procedure (S1014), near RT RIC 13-2 checks the UE profile provided by non-RT RIC 13-1, determines the current mobility state at S1016-1, and / or predicts the future mobility state, and then provides this as mobility assistance information to RAN device 5 at S1018-1 (e.g., via the E2 interface). RAN device 5 (CU5c and / or DU5b in the case of distributed RAN) determines an appropriate mobility-specific configuration for UE3 using the provided information at S1020-1. And RAN device 5 provides configuration information for configuring UE3 with its mobility-specific configuration at S1022-1 using appropriate signaling (e.g., using appropriate RRC signaling such as an RRC reconfiguration message or other similar messages). And UE3 can configure itself based on the received configuration information.

[0146] In the second exemplary procedure (b), after the RRC connection setup procedure is initiated by UE3, during the RRC connection setup procedure (S1014), near RT RIC13-2 determines, at S1020-2, an appropriate mobility configuration for UE3 based on the UE profile of UE3 (e.g., based on the current and / or predicted mobility state derived from the UE profile), and then, at S1018-2, provides the configuration information representing the determined mobility-specific configuration to RAN device 5 to configure UE3. Then, RAN device 5 (CU5c and / or DU5b in the case of distributed RAN) provides, at S1022-2, the corresponding configuration information for configuring UE3 with its mobility-specific configuration using appropriate signaling (e.g., using appropriate RRC signaling). Then, UE3 can configure itself based on the received configuration information.

[0147] FIG. 11 is another simplified timing diagram showing a possible procedure for providing a mobility-specific configuration to UE3.

[0148] In this example, non-RT RIC13-1 constructs (or updates) a UE profile for a specific UE3 at S1110. Then, this (updated) UE profile (or assistance information derived therefrom, such as an indicator of the mobility state) is directly provided to RAN device 5 at (S1112).

[0149] After the RRC connection setup procedure is initiated by UE3, during the RRC connection setup procedure (S1114), the RAN device 5 (CU5c and / or DU5b in the case of distributed RAN) determines, at S1120, an appropriate mobility-specific configuration for UE3 using the provided information. Then, at S1122, the RAN device 5 provides, using appropriate signaling (e.g., using appropriate RRC signaling), configuration information for configuring UE3 with its mobility-specific configuration. Then, UE3 can configure itself accordingly based on the received configuration information.

[0150] RRC / MAC layer provision of UE profile

[0151] Examples of UE-based UE profile procedures including RRC / MAC layer signaling will be described, by way of example only, with reference to FIGS. 12 and 13.

[0152] FIG. 12 is a simplified timing diagram showing two possible procedures (labeled (a) and (b)) for providing a mobility-specific configuration to UE3.

[0153] In both exemplary procedures, UE3 constructs (or updates) its UE profile for that UE3 at S1210.

[0154] In the first exemplary procedure (a), in response to an RRC connection or a change in the mobility state of UE3 (at S1214), the UE uses RRC signaling (at S1218-1) to provide mobility assistance information to the RAN device 5, in this example, using a UE assistance information message. The RAN device 5 (CU5c and / or DU5b in the case of distributed RAN) determines an appropriate mobility-specific configuration for UE3 using the provided information at S1220-1. Then, at S1222-1, the RAN device 5 uses appropriate signaling (e.g., using appropriate RRC signaling such as an RRC reconfiguration message or other similar messages) to provide configuration information for configuring UE3 with its mobility-specific configuration. And UE3 can configure itself based on the received configuration information.

[0155] In the second exemplary procedure (b), in response to an RRC connection or a change in the mobility state of UE3 (at S1214), the UE uses a MAC CE (at S1218-2) to provide mobility assistance information to the RAN device 5. The RAN device 5 (CU5c and / or DU5b in the case of distributed RAN) determines an appropriate mobility-specific configuration for UE3 using the provided information at S1220-2. Then, at S1222-2, the RAN device 5 uses appropriate signaling (e.g., using appropriate RRC signaling such as an RRC reconfiguration message, a MAC CE, or other similar messages) to provide configuration information for configuring UE3 with its mobility-specific configuration. And UE3 can configure itself based on the received configuration information.

[0156] Figure 13 is a simplified timing diagram that shows the two possible procedures shown in Figure 12 in more detail in a specific situation of the distributed RAN device 5.

[0157] In both exemplary procedures, at S1310, the UE3 constructs (or updates) a UE profile for that UE3.

[0158] In the first exemplary procedure (a), in response to a change in the RRC connection or the mobility state of the UE3 (at S1314), the UE uses RRC signaling (at S1318-1) to provide mobility assistance information to the gNB-CU5c of the RAN device 5, using, in this example, a UE assistance information message. The gNB-CU5c of the RAN device 5 shares the received information with the gNB-DU5b of the RAN device 5 (e.g., via the F1 interface) at S1319-1. Then, the gNB-CU5c and / or the gNB-DU5b determine an appropriate mobility-specific configuration for the UE3 using the mobility assistance information at S1320-1. Then, the gNB-CU5c provides configuration information for configuring the UE3 with its mobility-specific configuration using appropriate signaling (e.g., using appropriate RRC signaling) at S1322-1. Then, the UE3 can configure itself accordingly based on the received configuration information.

[0159] In the second exemplary procedure (b), in response to a change in the RRC connection or the mobility state of UE3 (at S1314), the UE uses a MAC CE message (at S1318-2) to provide mobility assistance information to gNB-DU5b of RAN device 5. The gNB-DU5b of RAN device 5 shares the received information with gNB-CU5c of RAN device 5 (e.g., via the F1 interface) at S1319-2. Then, at S1320-2, gNB-CU5c and / or gNB-DU5b use the mobility assistance information to determine an appropriate mobility-specific configuration for UE3. Then, at S1322-1, gNB-CU5c uses appropriate signaling (e.g., using appropriate RRC signaling) to provide configuration information for configuring UE3 with its mobility-specific configuration. Then, UE 3 can configure itself based on the received configuration information.

[0160] The second exemplary procedure (b) shows the configuration signaled by CU5c, but it will be understood that DU5b can provide part or all of the mobility-specific configuration to CU5c (or in some cases, to UE3 using MAC CE). For example, DU5b can provide UE configurations such as lower layer related configurations (e.g., TAT, PC) to CU5c, and CU5c can transmit this configuration to UE3. Typically, in a CU-DU split architecture, lower layer configuration parameters are set by DU5b and upper layer configuration parameters are set by CU5c.

[0161] In any of the examples described with reference to FIGS. 12 and 13, the mobility assistance information may include a direct indicator, e.g., a stationary indicator for indicating whether UE3 is (quasi)-stationary (e.g., a single bit is set to "1" to indicate that UE3 is (quasi)-stationary and set to "0" to indicate that UE3 is not (quasi)-stationary (or vice versa)). Alternatively, or additionally, the direct indicator may include an indicator of one of a plurality of mobility categories (e.g., (quasi)-stationary, movement within a limited geographical area, movement between specific two points, random movement, low mobility, medium mobility, or high mobility, etc.). The mobility assistance information may alternatively or additionally include an indirect indicator. The indirect indicator may include, for example, a configuration priority related to mobility (e.g., a larger / infinite TAT is good, relaxed radio resource management (RRM) measurements are good, no (or few) measurement configurations are good, and no handover is good, etc.).

[0162] NAS / Upper Layer Provision of UE Profile Referring to FIG. 14, an example of a UE-based UE profile procedure with NAS / upper layer signaling will be described as a mere example.

[0163] FIG. 14 is a simplified timing diagram showing two possible procedures (labeled (a) and (b)) for providing mobility-specific configurations specific to UE3.

[0164] In both exemplary procedures, UE3 constructs (or updates) a UE profile for that UE3 at S1410. And this (updated) UE profile is provided to core network 7 (UDM10-3 in this example, but it may be another network node) at S1412.

[0165] In the first exemplary procedure (a), the (updated) UE profile is shared with the AMF 10-1 (e.g., via the N8 interface). After the RRC connection setup procedure is initiated by the UE 3, during the RRC connection setup procedure (S1414), more specifically, during the UE context setup (S1415), the AMF 10-1 obtains the (updated) UE profile from the UDM 10-3 as shown in S1416 (or, if the AMF has previously obtained the (updated) UE profile from the UDM 10-3, it may obtain the profile from memory). The AMF 10-1 provides, in S1418, this (updated) UE profile, or mobility assistance information derived therefrom (e.g., information identifying the current and / or expected future mobility state), to the RAN device 5 (e.g., via the N2 interface). The RAN device 5 (CU5c and / or DU5b in the case of distributed RAN) determines, in S1420, an appropriate mobility-specific configuration for the UE 3 using the provided information. Then, the RAN device 5 provides, in S1422, configuration information for configuring the UE 3 with its mobility-specific configuration using appropriate signaling (e.g., using appropriate RRC signaling). And the UE 3 can configure itself accordingly based on the received configuration information.

[0166] In the second exemplary procedure (b), at S1430, the (updated) UE profile is shared with SMF10-2 (e.g., via the N10 interface), and at S1432, an appropriate mobility-specific NAS configuration for the UE is determined. For example, based on the UE profile, the core network 7 may optimize the NAS configuration for a particular UE to prioritize where to page the UE first based on an expectation of where the UE is located (e.g., a specific cell or an optimized paging area). Such a prediction may identify a single location (cell or optimized paging area), or a list of such locations sorted in descending order of confidence (or reliability level). Similarly, the core network may adjust or optimize the registration area associated with the UE based on information derived from the UE profile.

[0167] Hybrid Example - UE and Network Involved in UE Profile Generation As a mere example, an example of a hybrid UE / network-based UE profile procedure will be described with reference to FIGS. 15 and 16.

[0168] FIG. 15 is a simplified timing diagram showing another possible procedure for providing a mobility-specific configuration to UE3.

[0169] In this exemplary procedure, at S1510, UE3 constructs (or updates) a UE profile for that UE3. Then, this (updated) UE profile is provided to the core network 7 (UDM10-3 in this example, but it may be other network nodes) at S1512.

[0170] (Updated) UE profiles are shared with AMF10-1 (e.g., via the N8 interface). After the RRC connection setup procedure is initiated by UE3, during the RRC connection setup procedure (S1514), and more specifically, during UE context setup (S1515), AMF10-1 obtains the (updated) UE profile from UDM10-3 as shown in S1516 (or, if the AMF has previously obtained the (updated) UE profile from UDM10-3, it may obtain the profile from memory). At S1518, AMF10-1 provides this (updated) UE profile, or mobility assistance information derived therefrom (e.g., information identifying the current and / or predicted future mobility state), to the RAN device 5 (e.g., via the N2 interface). Then, the RAN device 5 (CU5c and / or DU5b in the case of distributed RAN) and / or RIC13 (near-RT or non-RT) authenticates the UE profile as S1519. This authentication may be performed, for example, by comparing the expected location and / or expected movement of UE3 based on the UE profile reported by UE3 with the live location information and / or measurement data of UE3 collected by the network from UE3. The UE profile may be used if the authentication is successful, as explained in the above example.

[0171] If the authentication is successful, the RAN device 5 (or, in some cases, RIC13 described with reference to FIG. 10) determines an appropriate mobility-specific configuration for UE3 using the provided information at S1520. Then, at S1522, the RAN device 5 uses appropriate signaling (e.g., using appropriate RRC signaling) to provide configuration information for configuring UE3 with the mobility-specific configuration. Then, UE3 can configure itself based on the received configuration information.

[0172] FIG. 16 is a simplified timing diagram showing another possible procedure for providing a mobility-specific configuration to UE3.

[0173] In this exemplary procedure, UE3 constructs (or updates) a UE profile for that UE3 at S1610-1. In parallel, RIC13 (near-RT or non-RT) constructs (or updates) a network-based UE profile for that UE3 at S1610-2. The (updated) UE profile generated by UE3 is provided to core network 7 (UDM10-3 in this example, but it could be other network nodes) at S1612.

[0174] (Updated) UE profiles are shared with AMF10-1 (e.g., via the N8 interface). After the RRC connection setup procedure is initiated by UE3, during the RRC connection setup procedure (S1614), more specifically, during UE context setup (S1615), AMF10-1 obtains the (updated) UE profile from UDM10-3 as shown in S1616 (or, if the AMF has previously obtained the (updated) UE profile from UDM10-3, it may obtain the profile from memory). AMF10-1 provides this (updated) UE profile, or mobility assistance information derived therefrom (e.g., information identifying the current and / or predicted future mobility state), to the RAN device 5 (e.g., via the N2 interface) at S1618. Then, the RAN device 5 (CU5c and / or DU5b in the case of distributed RAN) and / or RIC13 (near-RT or non-RT) performs authentication of the UE profile by comparing the UE originating profile (constructed by UE at 1610-1) received from the core network with the network-based UE profile (constructed by the network at 1610-2) and determines whether there is sufficient agreement (a predefined level of similarity between different UE profiles) at S1619.

[0175] If the match is successful, the RAN device 5 (or, in some cases, RIC13 described with reference to FIG. 10) determines an appropriate mobility-specific configuration for UE3 using the provided information at S1620. Then, the RAN device 5 provides configuration information for configuring UE3 with that mobility-specific configuration using appropriate signaling (e.g., using appropriate RRC signaling) at S1622. And UE3 can configure itself based on the received configuration information.

[0176] Changes and Alternatives Various detailed examples of improvements have been described above. As will be understood by those skilled in the art, many changes and alternatives can be made to the above examples while deriving benefits from the disclosure embodied therein.

[0177] For example, while newly beneficial features of devices in a telecommunication network have been described with reference in particular to 5G / NR communication technology, it will be understood that the beneficial features may be implemented in devices of other telecommunication systems using other communication technologies, such as other communication technologies developed as part of 3GPP. For example, while base stations and UEs have been described as having several individual functional components or modules, it will be understood that these features can be applied to RAN nodes (eNB) and UEs implementing LTE / LTE-Advanced communication technology, or RAN nodes and UEs implementing other communication technologies developed using 3GPP-derived communication, for example, when an existing system is modified for a particular application, such as for implementing the present disclosure, or in other applications, such as in a system designed from the outset with the features of the present disclosure in mind.

[0178] In the above description, for ease of understanding, UEs and base stations have been described as having several individual functional components or modules. These modules can be provided in this way for a particular use, for example, when an existing system is modified for implementing the present disclosure, or in other uses, such as in a system designed from the outset with the features of the present disclosure in mind, but since these modules can be incorporated into the overall operating system or code, these modules may not be recognizable as individual entities.

[0179] In the above embodiments, several software modules have been described. As will be understood by those skilled in the art, software modules may be provided in a compiled form or an uncompiled form, and may be supplied to a base station, a mobility management entity, or a UE via a computer network or as a signal on a recording medium. Furthermore, the functions executed by some or all of this software may be executed using one or more dedicated hardware circuits. However, when updating the functions of a base station or a UE, it is preferable to use software modules to facilitate the update.

[0180] When a software module or program is loaded into a computer, it includes instructions (or software code) that cause the computer to execute one or more of the functions described in the embodiments. The program can be stored in a non-transitory computer-readable medium or a tangible storage medium. By way of non-limiting example, non-transitory computer-readable media or tangible storage media include random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD), or other types of memory technologies, CD-ROM, digital versatile disc (DVD), Blu-ray (registered trademark) disc, or other types of optical disc storage, and magnetic cassettes, magnetic tapes, magnetic disc storage, or other types of magnetic disc storage devices. The program may be transmitted on a transitory computer-readable medium or a communication medium. By way of non-limiting example, transitory computer-readable media or communication media can include electrical, optical, acoustic, or other forms of propagated signals.

[0181] Each controller may include, for example, one or more hardware-implemented computer processors, microprocessors, central processing units (CPUs), arithmetic logic units (ALUs), input / output (IO) circuits, internal memory / cache (program and / or data), register processing, communication buses (control bus, data bus, address bus, etc.), direct memory access (DMA) functions, hardware- or software-implemented counters, pointers, and / or timers, and / or the like, in any suitable form of processing circuitry (but not limited thereto). Various other modifications will be apparent to those skilled in the art and will not be described further herein.

[0182] A user equipment (or "UE", "mobile station", "mobile device", or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface.

[0183] It should be noted that, as described in the following paragraphs, the present disclosure is not limited to dedicated communication devices and can be applied to any device having a communication function.

[0184] The terms "user equipment" or "UE" (as a term used in 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with each other and include stand-alone mobile stations such as terminals, mobile phones, smartphones, tablets, cellular IoT devices, IoT devices, machinery, etc. It will be understood that the terms "mobile station" and "mobile device" also include devices that remain stationary for a long period of time.

[0185] The UE may be, for example, an item of equipment for production or manufacturing, and / or an item of energy-related machinery (such as, for example, the following equipment or machinery: boilers, engines, turbines, solar panels, wind turbines, hydroelectric generators, thermal power generators, nuclear power generators, batteries, nuclear systems and / or related equipment, heavy electrical machinery, pumps including vacuum pumps, compressors, fans, blowers, hydraulic equipment, pneumatic equipment, metalworking machinery, manipulators, robots and / or their application systems, tools, dies or molds, rolls, conveying equipment, lifting equipment, material handling equipment, textile equipment, sewing equipment, printing and / or related machinery, paper processing machinery, chemical machinery, mining and / or construction machinery and / or related equipment, machinery and / or implements for agriculture, forestry and / or fisheries, safety and / or environmental protection equipment, tractors, precision bearings, chains, gears, power transmission equipment, lubrication equipment, valves, piping fittings, and / or application systems of the aforementioned equipment or machinery, etc.).

[0186] The UE may be, for example, an item of transportation equipment (such as, for example, the following transportation equipment: rolling stock, automobiles, motorcycles, bicycles, trains, buses, carts, rickshaws, ships and other vessels, aircraft, rockets, satellites, drones, balloons, etc.).

[0187] The UE may be, for example, an item of information and communication equipment (such as, for example, the following information and communication equipment: electronic computers and related equipment, communication and related equipment, electronic components, etc.).

[0188] The UE may be, for example, an item of refrigerators, refrigerator-applied products, equipment for the trade and / or service industries, vending machines, automatic service machines, office machines or equipment, household electrical appliances and electronic devices (such as, for example, the following household appliances: audio equipment, video equipment, loudspeakers, radios, televisions, microwave ovens, rice cookers, coffee makers, dishwashers, washing machines, dryers, electric fans or related equipment, vacuum cleaners, etc.).

[0189] The UE may be, for example, an electric application system or device (for example, an electric application system or device such as: an X-ray system, a particle accelerator, a radioisotope device, an acoustic device, an electromagnetic application device, a power application device, etc.).

[0190] The UE may also be, for example, an electronic lamp, a lighting fixture, a measuring device, an analyzer, a tester, or a surveying or sensing device (for example, a surveying or sensing device such as a smoke detector, a human presence alarm sensor, a motion sensor, a wireless tag, etc.), a wristwatch or clock, a laboratory instrument, an optical device, a medical device and / or system, a weapon, a bladed item, a hand tool, etc.

[0191] The UE may also be, for example, a wireless-equipped personal digital assistant or a related device (such as a wireless card or module designed to be attached to or inserted into another electronic device (for example, a personal computer, an electrical measuring instrument)).

[0192] The UE may also be part of a device or system that uses various wired and / or wireless communication technologies to provide the applications, services, and solutions described below with respect to the "internet of things; IoT".

[0193] Internet of Things (IoT) devices (or "things") may have appropriate electronic devices, software, sensors, network connectivity, etc. implemented, and these devices can collect and exchange data with each other or with other communication devices. IoT devices may consist of automated devices that follow software instructions stored in internal memory. IoT devices may operate without the need for human management or interaction. IoT devices may remain stationary and / or inactive for long periods of time. IoT devices may be implemented as part of a stationary device (generally). IoT devices may be incorporated into non-stationary devices (such as vehicles) or attached to animals or people being monitored / tracked.

[0194] It will be understood that IoT technology can be implemented in any communication device that can be connected to a communication network to send and receive data, regardless of whether such a communication device is controlled by human input or by software instructions stored in memory.

[0195] It will be understood that IoT devices are also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be understood that a UE can support one or more IoT or MTC applications. Some examples of MTC applications are shown in the following table. This list is not exhaustive and is intended to show some examples of machine-type communication applications. [Table 2]

[0196] Applications, services, and solutions may include Mobile Virtual Network Operator (MVNO) services, emergency wireless communication systems, Private Branch eXchange (PBX) systems, PHS / digital cordless communication systems, Point of sale (POS) systems, advertise calling systems, Multimedia Broadcast and Multicast Service (MBMS), Vehicle to Everything (V2X) systems, train wireless systems, location-based services, disaster / emergency wireless communication services, community services, video streaming services, femtocell application services, Voice over LTE (VoLTE) services, charging services, radio on-demand services, roaming services, activity monitoring services, carrier / communication NW selection services, function-limited services, Proof of Concept (PoC) services, personal information management services, ad hoc network / Delay Tolerant Networking (DTN) services, etc.

[0197] Furthermore, the above UE categories are merely an example of the application of the technical ideas and exemplary embodiments described in this specification. Needless to say, these technical ideas and embodiments are not limited to the above UEs and can be variously modified.

[0198] Various other modifications will be apparent to those skilled in the art and are not further detailed herein.

[0199] The description of the above - disclosed examples is provided to enable a person skilled in the art to practice or use the present disclosure. Various changes to these examples will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other examples without departing from the spirit or scope of the present disclosure. Accordingly, the present disclosure is not intended to be limited to the examples shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0200] This application claims the benefit of priority based on UK Patent Application No. 2106571.9 filed on May 7, 2021, the entire disclosure of which is incorporated herein by reference.

[0201] All or part of the above - disclosed exemplary embodiments can be described as follows, but are not limited thereto. (Appendix 1) A method performed by a first network entity in a communication system, comprising: obtaining information regarding the mobility state of a User Equipment (UE); determining a mobility - specific configuration of the UE based on the mobility state; providing configuration information for configuring the UE with the mobility - specific configuration. A method comprising the above. (Appendix 2) The method according to Appendix 1, further comprising performing authentication of the information regarding the mobility state of the UE before determining the mobility - specific configuration, wherein the determining is performed when the authentication is successful. The method according to Appendix 1. (Appendix 3) The method according to Appendix 2, wherein performing the authentication is based on a comparison between the expected location and / or expected movement of the UE and the location information and / or measurement data of the UE collected from the UE. The method according to Appendix 2. (Appendix 4) Performing the authentication is based on a comparison between the information regarding the mobility state of the UE and other information regarding the mobility state of the UE generated by the first network entity or another network entity. The method according to Appendix 2. (Appendix 5) The information regarding the mobility state of the UE includes information for identifying the current and / or expected mobility state of the UE. Performing the determination is based on the current and / or expected mobility state of the UE. The method according to any one of Appendices 1 to 4. (Appendix 6) The information regarding the mobility state of the UE includes an indicator for indicating whether the UE is stationary or nearly stationary, and / or an indicator for indicating one of a plurality of mobility categories into which the movement of the UE is categorized. The method according to any one of Appendices 1 to 5. (Appendix 7) The information regarding the mobility state of the UE includes an indicator for indicating a configuration priority regarding mobility. The method according to any one of Appendices 1 to 6. (Appendix 8) The information regarding the mobility state of the UE is Radio Resource Control (RRC) message, UE Assistance Information message, Media Access Control (MAC) Control Element (CE) message, Non-Access Stratum (NAS) message, and includes at least any one of The method according to any one of Appendices 1 to 7. (Appendix 9) The UE-specific mobility configuration is a measurement configuration specific to mobility, Power Control (PC) configuration specific to mobility, Power Headroom Reporting (PHR) configuration specific to mobility, Time Alignment Timer configuration specific to mobility, and / or Paging area / tracking area configuration specific to mobility, any one of, or any combination of, the method according to any one of Appendices 1 to 8. (Appendix 10) Providing the configuration information is performed using any one of Radio Resource Control (RRC) signaling and the RRC Reconfiguration message, the method according to any one of Appendices 1 to 9. (Appendix 11) The information regarding the mobility state of the UE is included in the UE profile, the method according to any one of Appendices 1 to 10. (Appendix 12) The obtaining includes receiving the information regarding the mobility state of the UE from a second network entity, and the providing includes providing the configuration information to the UE or a third network entity, the method according to any one of Appendices 1 to 11. (Appendix 13) The obtaining includes receiving the information regarding the mobility state of the UE from the UE, and the providing includes providing the configuration information to the UE or a second network entity, the method according to any one of Appendices 1 to 11. (Appendix 14) The second network entity is A Radio Access Network (RAN) Intelligent Controller (RIC) entity, a non-real time RIC, a near-real time RIC, and at least one of the following: The method described in Appendix 12 or 13. (Appendix 15) The second network entity includes a core network control plane function, a Unified Data Management (UDM) function, a Home Subscriber Server (HSS), and at least one of the following: The method described in Appendix 12 or 13. (Appendix 16) The second network entity includes an Operations, Administration and Maintenance (OAM) function, The method described in Appendix 12 or 13. (Appendix 17) The first network entity includes Radio Access Network (RAN) equipment, a Central Unit (CU) of a base station, a Distributed Unit (DU) of a base station, an integrated base station, and at least one of the following: The method described in any one of Appendices 1 to 16. (Appendix 18) The first network entity includes a Radio Access Network (RAN) Intelligent Controller (RIC) entity, a near-real time RIC, a non-real time RIC, including at least any one of the method according to any one of Appendices 1 to 17. (Appendix 19) The first network entity includes at least any one of a core network control plane function and a Session Management Function (SMF), including at least any one of the method according to any one of Appendices 1 to 18. (Appendix 20) A method executed by a User Equipment (UE) in a communication system, including providing information regarding the mobility state of the UE to a network entity to support determining the UE's mobility-specific configuration. Method. (Appendix 21) including receiving configuration information for configuring the UE with the mobility-specific configuration from the network entity or another network entity. The method according to Appendix 20. (Appendix 22) The information regarding the mobility state of the UE includes information identifying the device type of the UE corresponding to the mobility state of the UE. The method according to any one of Appendices 1 to 21. (Appendix 23) The information regarding the mobility state of the UE includes information identifying the location of the UE. The method according to any one of Appendices 1 to 22. (Appendix 24) The information regarding the mobility state of the UE includes information identifying the time or period when the UE is expected to be stationary, information identifying the location where the UE is expected to be stationary, information identifying the time or period when the UE is expected to be moving, Information for identifying a location of a destination or a source where the UE is expected to move Information for identifying a geographical area where the movement of the UE is expected to be restricted within a range, and / or Information for identifying a reliability of information about the information regarding the mobility state of the UE Any one of, or any combination of, The method according to any one of Appendices 1 to 23. (Appendix 25) The information regarding the mobility state of the UE includes information for identifying a reliability of information about the information regarding the mobility state of the UE The determining is performed based on the reliability The method according to Appendix 24. (Appendix 26) A first network entity for a communication system, Means for obtaining information regarding a mobility state of a user equipment (UE), Means for determining a mobility-specific configuration of the UE based on the mobility state, Means for providing configuration information for configuring the UE with the mobility-specific configuration. A first network entity comprising the above. (Appendix 27) A user equipment (UE) for a communication system, Comprising means for providing information regarding a mobility state of the UE to a network entity for supporting determination of a mobility-specific configuration of the UE UE.

Description of Reference Numerals

[0202] 1 Communication system 3 User equipment (UE) 5 Radio access network (RAN) equipment 5a Radio unit (RU) 5b Distributed unit (DU) 5c Aggregation Unit (CU) 7-Core Network 9 Cells 10 Control Plane Function (CPF) 10-1 Access and Mobility Management Function (AMF) 10-2 Session Management Function (SMF) 10-3 Unified Data Management (UDM) Function 10-n Other Functions 11 User Plane Function (UPF) 13 RAN Intelligent Controller (RIC) 13-1 Non-real time RIC (non-RT-RIC) 13-2 Near-real time RIC (near-RT-RIC) 14 Operations, Administration and Maintenance (OAM) 20 External Data Network 231 Transceiver Circuit 233 Antenna 235 User Interface 237 Controller 239 Memory 241 Operating System 243 Communication Control Module 245 UE Management Module 247 UE Profile Management Module 351 Transceiver Circuit 353 Antenna 354 DU Interface 357 Controller 359 Memory 361 Operating System 363 Communication Control Module 368 DU-RU Module 372 RU Management Module 451 Transceiver Circuit 452 RIC Interface 453 RU Interface 454 CU Interface 457 Controller 459 Memory 461 Operating System 463 Communication Control Module 465 F1 Module 467 E2 Module 468 DU-RU Module 472 DU Management Module 473 UE Profile Management Module 551 Transceiver Circuit 552 RIC Interface 554 DU Interface 555 Core Network (CN) Interface 557 Controller 559 Memory 561 Operating System 563 Communication Control Module 565 F1 Module 566 E1 Module 567 E2 Module 568 N2 Module 569 N3 Module 571 CU-UP Management Module 572 CU-CP Management Module 573 UE Profile Management Module 651 Transceiver Circuit 653 Antenna 655 Core Network (CN) Interface 657 Controller 659 Memory 661 Operating System 663 Communication Control Module 668 N2 Module 669 N3 Module 672 RAN Control Module 673 UE Profile Management Module 751 Transceiver Circuit 752 gNB-CU Interface 753 Non-RT RIC Interface 757 Controller 759 Memory 761 Operating System 763 Communication Control Module 769 A1 Module 770 E2 Module 772 Near-RT RIC Management Module 773 UE Profile Management Module 851 Transceiver Circuit 853 Near-RT RIC Interface 857 Controller 859 Memory 861 Operating System 863 Communication Control Module 869 A1 Module 872 Non-RT RIC Management Module 873 UE Profile Management Module 951 Transceiver Circuit 954 Corresponding (Network) Interface 957 Controller 959 Memory 961 Operating System 963 Communication Control Module 965 Interface Protocol Module 972 Network Node Management Module 973 UE Profile Management Module

Claims

1. means for receiving, from the UE, a Radio Resource Control (RRC) message including information on a mobility state based on the history data of the UE in response to a change in the state of the UE; means for transmitting, to the UE, configuration information for configuring the UE with a mobility-specific configuration corresponding to the mobility state; comprising: The configuration information is an access network node used by the UE to perform relaxed radio resource management based on the mobility-specific configuration.

2. A User Equipment (UE), comprising: means for transmitting, to an access network node, a Radio Resource Control (RRC) message including information on the mobility state of the UE to support determining a mobility-specific configuration of the UE in response to a change in the state of the UE; means for receiving, from the access network node, configuration information for configuring the UE with a mobility-specific configuration corresponding to the mobility state; means for performing relaxed radio resource management based on the mobility-specific configuration. UE

3. The UE according to claim 2, wherein the RRC message is a UE assistance information message.

4. The UE according to claim 2 or 3, wherein the information on the mobility state is represented by 1 bit.

5. The UE according to claim 2 or 3, wherein the information on the mobility state is information on whether it is relaxed radio resource management measurement.

6. The UE according to claim 2 or 3, wherein the change in the state of the UE is determined based on measurements of reference signal received power (RSRP) and / or reference signal received quality (RSRQ).

7. receiving, from the UE, a Radio Resource Control (RRC) message including information on a mobility state based on the history data of the UE in response to a change in the state of the UE; Transmitting configuration information for configuring the UE with a mobility-specific configuration corresponding to the mobility state to the UE; comprising; The configuration information is a method in an access network node that is used for the UE to perform relaxed radio resource management based on the mobility-specific configuration.

8. A method in a User Equipment (UE), comprising: Transmitting a Radio Resource Control (RRC) message including information regarding the mobility state of the UE to support determining a mobility-specific configuration of the UE in response to a state change of the UE to an access network node; Receiving configuration information for configuring the UE with a mobility-specific configuration corresponding to the mobility state from the access network node; Performing relaxed radio resource management based on the mobility-specific configuration; comprising; a method.

Images