Configuration for Layer 1 / Layer 2 trigger mobility

Abstract

One example provides a method implemented by a central unit-control plane (CU-CP) network node. This method involves sending a message to a central unit-user plane (CU-UP) network node identifying the configuration of the CU-UP network node for a Layer 1 / Layer 2 triggered mobility (LTM) cell switching procedure by a user device (UE).

Description

[Technical Field]

[0001] Examples of the disclosure relating to Layer 1 / Layer 2 triggered mobility (LTM) include, for example, sending or receiving messages that identify the configuration of a network node for an LTM cell switching procedure by a user device (UE), or receiving one or more transport network layer (TNL) addresses assigned to one or more LTM candidate target cells. [Background technology]

[0002] In Rel-18, 3GPP agreed on work items concerning further New Radio (NR) mobility extensions, particularly in the technical area entitled L1 / L2 base-cell mobility. For further details, please refer to the Work Item Description (WID) in RP-213565.

[0003] According to the WID, when a user equipment (UE) moves from the coverage area of ​​one cell to another, a serving cell change must be performed at some point. Currently, serving cell changes are triggered by Layer 3 (L3) measurements and performed by a synchronous Radio Resource Control (RRC) signaling-triggered reconfiguration for changes to primary cells (PCells) and primary secondary cells (PSCells), as well as for the release or addition of secondary cells (SCells) when applicable. All instances involve a complete Layer 2 (L2) and Layer 1 (L1) reset, resulting in longer latency, greater overhead, and longer downtime than beam switching mobility. The goal of L1 / L2 mobility expansion is to enable serving cell changes via L1 / L2 signaling to reduce latency, signaling overhead, and downtime.

[0004] As part of the L1-L2 inter-cell mobility measurement framework, it was agreed to support at least L1 reference signal received power (L1-RSRP) as a reported quantity. This means that UEs are required to report the L1-RSRP of candidate cells to the network (NW), and therefore the NW can use them for LTM handover (HO) determination.

[0005] In Rel-17, the solution is standardized as part of inter-cell beam management, and L1-RSRP is measured and reported for channel status information (CSI) resources that are not related to the physical cell identifier (PCI) of the serving cell.

[0006] The L3 HO delay requirements from 3GPP TS38.133 V18.0.0 are copied below. **************************************** 6.1.1.2.1 Handover Delay When the UE receives an RRC message that implies a handover, the UE moves from the end of the last TTI containing the RRC command to D handover Assume that you are ready to begin transmitting on the new uplink PRACH channel within milliseconds. Here, D handover This is equal to the applicable RRC procedure delay specified in Section 12 of TS38.331[2] + the interruption time described in Section 6.1.1.2.2. 6.1.1.2.2 Suspension time The interruption time is the time between the end of the last TTI containing the RRC command on the old PDSCH (excluding RRC procedure delays) and the time when the UE starts sending a new PRACH. When a handover within or between frequencies is commanded, the interruption time is T interrupt It shall be less than [amount]. T interrupt =Tsearch +T IU +T processing +T Δ +T margin ms Here, T search is the time required to search for the target cell when the target cell is not yet known when the handover command is received by the UE. When the target cell is known, T search = 0 ms. When the target cell is an in-frequency cell that is not known and the target cell Es / Iot ≥ -2 dB, T search = T rs ms. When the target cell is an inter-frequency cell that is not known and the target cell Es / Iot ≥ -2 dB, T search = 3 * T rs ms. Regardless of whether DRX is being used by the UE, T search shall still be based on the non-DRX target cell search time. T Δ is the time for fine time tracking and obtaining complete timing information of the target cell. For both known and unknown target cells, T Δ = T rs is. T processing is the time for UE processing. T processing can be up to 20 ms. T margin is the time for SSB post-processing. T margin can be up to 2 ms. T IU is the interruption uncertainty when obtaining the first available PRACH occasion in a new cell. T IU can be at most the sum of the SSB-PRACH occasion association period and 10 ms. The SSB-PRACH occasion association period is defined in Table 8.1-1 of TS38.213 [3]. T rsIf the UE provides an SMTC setting for the target cell in the handover command, Trs is the SMTC periodicity of the target NR cell; otherwise, Trs is the SMTC set in the measObjectNR having the same SSB frequency and subcarrier interval. If the measObjectNRs set by MN and SN have different SMTCs but the same SSB frequency and subcarrier interval, Trs is the periodicity of one of the SMTCs, which depends on the UE implementation. If the UE does not provide an SMTC setting or measurement object on this frequency, the requirement in this section is, assuming the SSB transmission periodicity is 5ms, T rs = Applies at 5ms. There are no requirements if the SSB transmission periodicity is not 5ms. If the UE provides the upper layer in smtc2's TS38.331[2] signaling before the handover command, T rs It follows either smtc1 or smtc2 depending on the physical cell ID of the target cell. Under the interruption requirements, the cell is known if the relevant cell identification requirements were met during the last 5 seconds, but otherwise the cell is unknown. The relevant cell identification requirements are described in Section 9.2.5 for intra-frequency handovers and in Section 9.3.4 for inter-frequency handovers. ****************************************

[0007] Based on the above requirements, the L3 HO delay (D handover ) is equal to the RRC processing delay and interruption time of the HO command. The interruption delay has the following components: ·SW and HW processing • Cell search • Acquiring precise timing • Delay uncertainty in obtaining the PRACH preamble

[0008] Early discussions of Rel-18 LTM have presented two potential approaches and two potential timelines.

[0009] In 3GPP Release 18, a work item known as further NR mobility enhancements was agreed. This work item includes the technical area titled L1 / L2 based inter-cell mobility. According to its WID, when a UE moves from the coverage area of one cell to another cell, at a certain point, a serving cell change needs to be carried out. Currently, the serving cell change is triggered by L3 measurements and is performed by RRC signaling trigger reconfiguration with synchronization for the change of PCell and PSCell, and the addition of release for SCell when applicable. All cases involve a complete L2 and L1 reset, leading to longer latency, greater overhead, and longer interruption time compared to beam switching mobility. The purpose of L1 / L2 based inter-cell mobility is to enable serving cell changes via L1 / L2 signaling in order to reduce latency, overhead, and interruption time.

[0010] According to its WID, in this work item, the following is included as one of the purposes of the work. 1. Specify the mechanisms and procedures for L1 / L2 based inter-cell mobility for reducing mobility latency. 〇 Configuration and maintenance for multiple candidate cells to enable fast application of configurations for candidate cells [RAN2, RAN3] 〇 Dynamic switching mechanism between candidate serving cells (including SpCell and SCell) for potential applicable scenarios based on L1 / L2 signaling [RAN2, RAN1] 〇 L1 extensions for inter-cell beam management, including L1 measurements and reports and beam indication [RAN1, RAN2] - Note 1: Early RAN2 involvement is required, including the possibility of making the interrelationship between this bullet point and the previous bullet point clearer. 〇 Timing advance management [RAN1, RAN2] 〇 CU-DU interface signaling for supporting L1 / L2 mobility when necessary [RAN3] Note 2: The extensions inherent to FR2, if any, are not excluded. Note 3: The procedure for mobility between L1 / L2-based cells is applicable to the following scenarios. · Standalone, CA, and NR-DC cases involving serving cell change within one CG · Intra-DU cases and inter-DU cases within CU (applicable to standalone and CA: no new RAN interface is expected) · Both intra-frequency and inter-frequency · Both FR1 and FR2 · The source cell and the target cell may or may not be synchronized.

[0011] In 3GPP, discussions have started on solutions for L1 / L2-based mobility between cells (which may also be called LTM, L1 / L2-triggered mobility, or lower layer-triggered mobility).

[0012] The basic principle with L1 / L2-triggered mobility is that for each LTM candidate target cell, which may also be known to the UE by the network as an LTM candidate target cell setting, RRC configurations are pre-configured for the UE. Such LTM candidate target cell settings can be an RRCReconfiguration message or one or more IEs / fields / parameters such as CellGroupConfig. The UE performs measurements on these candidate LTM candidate target cells and sends corresponding measurement reports to the network. The network then triggers the execution of LTM cell switching in the UE by sending a lower layer signal (such as MAC CE or DCI) to the UE, and the UE then connects to the target cell and switches to the settings of the LTM candidate target cell.

[0013] In the RAN3#117-e, RAN3#117bis-e, RAN3#118, and RAN3#119 meetings, there were multiple agreements regarding L1 / L2-based mobility between cells, among which are the following. Both intra-DU scenarios and intra-CU / inter-DU scenarios are supported for L1 / L2 mobility. RAN3 aims to be a single solution for network signaling design for L1 / L2-based inter-cell mobility to support all agreed-upon scenarios. The details of the solution are in FFS. The gNB-CU initiates the L1 / L2 mobility configuration procedure. The configuration of (one or more) candidate target cells for L1 / L2 mobility is initiated by the gNB-CU. WA:RAN3 assumes that the UE sends an L1 measurement report to the gNB-DU, which then triggers UE mobility to a target candidate cell. All further details depend on the discussions in RAN1 and RAN2. During L1 / L2 handover setup, the gNB-CU sends (one or more) suggested candidate cells to the gNB-DU in the UE context modification request procedure, either in one message or in multiple messages, to the FFS. The gNB-DU can accept target cells for L1 / L2 handover and responds to the gNB-CU with access control results in (one or more) UE context modification response messages. The gNB-DU can accept all or some of the target candidate cells. The gNB-DU starting type L1 / L2 handover setting is not possible. The UE sends lower-layer measurement reports to the gNB-DU, which triggers UE mobility to target candidate cells. WA:gNB-DU informs gNB-CU of the successful access of the UE to the target cell with an access success message. In the case of inter-DU cell mobility, the UE context setup procedure is reused for handover setup. The CU suggests (one or more) candidate cells to the DU, and the statement "gNB-DU can suggest candidate cells after gNB-CU initiates L1 / L2 inter-cell mobility configuration" has a low priority. CU can update the suggested candidate cells. In a DU (Device Under Unit) scenario, the gNB-DU uses an access success message to inform the gNB-CU (Device Under Unit) of the successful access of the UE (User Environment) to the target cell. In inter-DU cases, the target gNB-DU informs the gNB-CU of the successful access of the UE to the target cell via an access success message. RAN3 uses the same signaling procedure for both the initial and subsequent cell switching for L1 / L2 handovers within a DU. During execution, when gNB-DU signals to CU depends on the gNB-DU implementation. This does not mean that gNB-DU is "enabled" to signal to gNB-CU before LTM commands are sent to UE. In the case of LTM within a DU, the gNB-CU assigns a new UL GTP TEID for each DRB and provides it to the gNB-DU via one or more UE context correction request messages. The gNB-DU assigns a new DL GTP TEID for each candidate cell and each DRB (whether this should be per candidate cell needs further discussion) and provides them to the gNB-CU in one or more UE context correction response messages. In the case of inter-DU LTM, the gNB-CU allocates a new UL GTP TEID for each DRB and provides it to the target gNB-DU via one or more UE context setup request messages. The target gNB-DU allocates a new DL GTP TEID for each candidate cell and each DRB (whether this should be per candidate cell needs further discussion) and provides them to the gNB-CU in one or more UE context setup response messages. CU UP example: The CU will begin transmitting data after the LTM cell switches signaling from the DU, which includes the target cell ID.

[0014] Currently, there are (one or more) challenges. For example, one of the objectives of LTM is to reduce user plane (UP) downtime during handover (HO). However, in the case of control plane (CP) / UP separation, the exchange of GPRS Tunneling Protocol (GTP)-U tunnel endpoints for F1-U tunnels between the target distributed unit (DU) and the CU-UP, and through the CU-CP, can only be initiated after the target DU detects that the UE has successfully accessed the target cell. In the meantime, the CU-UP and DU must buffer DL data and UL data, respectively. This adds further user plane (UP) downtime during LTM. [Overview of the project]

[0015] Several aspects and embodiments of this disclosure may provide solutions to these or other problems. For example, to address the above problems, several embodiments provide a method for enabling the exchange of GTP-U tunnel endpoints for F1-U tunnels between a CU-UP and a target DU, so that the CU-UP and DU can send DL data and UL data as quickly as possible, respectively. Several embodiments provide a method for the CU-UP to provide Transport Network Layer (TNL) addresses in the case of LTM. Several embodiments provide a method for ensuring minimal impact on the CU-UP in the case of LTM. In some embodiments, the CU-UP provides only one UL TNL to all candidate cells. In some embodiments, candidate cells receive the UL TNL, but only the cell that will be selected in LTM cell switching is made able to use that UL TNL. In some embodiments, the method further includes signaling the remaining cells that the UL TNL address should be discarded after the UE accesses the target cell. In some embodiments, for LTM, it may be possible to enable a reduction in UP interruption time.

[0016] One aspect of the present disclosure provides a method implemented by a central unit-control plane (CU-CP) network node. The method includes sending a message to a central unit-user plane (CU-UP) network node identifying the configuration of the CU-UP network node for a Layer 1 / Layer 2 triggered mobility (LTM) cell switching procedure by a user device (UE).

[0017] Another aspect of the present disclosure provides a method implemented by a central unit-user plane (CU-UP) network node. The method includes receiving a message from a central unit-control plane (CU-CP) network node identifying the configuration of the CU-UP network node for a Layer 1 / Layer 2 triggered mobility (LTM) cell switching procedure by a user device (UE). The method also includes assigning one or more transport network layer (TNL) addresses to one or more LTM candidate target cells for the LTM cell switching procedure.

[0018] Further aspects of this disclosure provide a method implemented by a distributed unit (DU) network node. This method includes receiving one or more transport network layer (TNL) addresses assigned to one or more Layer 1 / Layer 2 trigger mobility (LTM) candidate target cells of a DU network node from a central unit-control plane (CU-CP) network node.

[0019] Another aspect of the present disclosure provides a computer program that, when executed on at least one processor, includes instructions causing at least one processor to perform any of the methods described above.

[0020] Another aspect of the present disclosure provides a central unit-control plane (CU-CP) network node. The CU-CP network node comprises a processor and memory. The memory contains processor-executable instructions such that the CU-CP network node can operate to send a message to a central unit-user plane (CU-UP) network node identifying the configuration of the CU-UP network node for a Layer 1 / Layer 2 triggered mobility (LTM) cell switching procedure by a user device (UE).

[0021] Another aspect of the present disclosure provides a central unit-user plane (CU-UP) network node. The CU-UP network node comprises a processor and memory. The memory includes processor-executable instructions such that the CU-UP network node can operate to receive messages from a central unit-control plane (CU-CP) network node identifying the configuration of the CU-UP network node for a user device (UE) Layer 1 / Layer 2 triggered mobility (LTM) cell switching procedure, and to allocate one or more transport network layer (TNL) addresses to one or more LTM candidate target cells for the LTM cell switching procedure.

[0022] Another aspect of the present disclosure provides a distributed unit (DU) network node. The DU network node comprises a processor and memory. The memory contains processor-executable instructions such that the DU network node can operate to receive from a central unit-control plane (CU-CP) network node one or more transport network layer (TNL) addresses allocated to one or more Layer 1 / Layer 2 trigger mobility (LTM) candidate target cells of the DU network node.

[0023] Another aspect of the present disclosure provides a central unit-control plane (CU-CP) network node configured to send messages to a central unit-user plane (CU-UP) network node that identify the configuration of the CU-UP network node for a Layer 1 / Layer 2 triggered mobility (LTM) cell switching procedure by a user device (UE).

[0024] Another aspect of the present disclosure provides a central unit-user plane (CU-UP) network node configured to receive messages from a central unit-control plane (CU-CP) network node identifying the configuration of the CU-UP network node for a Layer 1 / Layer 2 triggered mobility (LTM) cell switching procedure by a user device (UE), and to assign one or more transport network layer (TNL) addresses to one or more LTM candidate target cells for the LTM cell switching procedure.

[0025] Another aspect of the present disclosure provides a distributed unit (DU) network node configured to receive from a central unit-control plane (CU-CP) network node one or more transport network layer (TNL) addresses assigned to one or more Layer 1 / Layer 2 trigger mobility (LTM) candidate target cells of a DU network node.

[0026] To better understand embodiments of this disclosure and to illustrate how this disclosure may be implemented, references to the accompanying drawings are provided below, merely as examples. [Brief explanation of the drawing]

[0027] [Figure 1] This is a diagram illustrating an example of the overall system architecture. [Figure 2] This flowchart shows a method according to several embodiments. [Figure 3] This flowchart shows a method according to several embodiments. [Figure 4] This flowchart shows a method according to several embodiments. [Figure 5] This figure shows an example of a communication system according to several embodiments. [Figure 6] This figure shows a UE according to several embodiments. [Figure 7]This figure shows network nodes according to several embodiments. [Figure 8] This is a block diagram of the host. [Figure 9] This block diagram shows a virtualization environment where functions implemented by several embodiments can be virtualized. [Figure 10] This is a communication diagram illustrating how a host communicates with a UE via a network node over a partial wireless connection, according to several embodiments. [Modes for carrying out the invention]

[0028] With reference to the accompanying drawings, some of the embodiments intended herein will now be described in more detail. These embodiments are provided, by example, to convey the scope of the subject to those skilled in the art.

[0029] Figure 1 shows an example of an overall system architecture having both a next-generation radio access network (NG-RAN) and a 5G core (5GC), where the NG-RAN is separated into a central unit (CU) and distributed units (DUs) connected via an F1 interface. The overall architecture, according to some embodiments of this disclosure, comprises a CU and DU in the radio access network (RAN). The RAN (described herein) may correspond to a next-generation RAN (NG-RAN), sometimes referred to as a 5G RAN. However, the embodiments described herein are applicable to any RAN, such as a sixth-generation (6G) RAN architecture, which may follow similar or different functional separations.

[0030] A RAN (e.g., NG-RAN) comprises a set of RAN nodes (e.g., gNB, 6G g-node B) connected to a core network (e.g., 5GC, 6G core network) through a RAN / core network (CN) interface (e.g., NG interface, S1 interface, 6G NG1). In the case of an NG-RAN, it may comprise one or more ng-eNBs, and an ng-eNB may comprise an ng-eNB-CU and one or more ng-eNB-DUs. A gNB may comprise a gNB-CU and one or more gNB-DUs. The gNB-CU and gNB-DU are connected via an F1 interface. A gNB-DU may be connected to multiple gNB-CUs by appropriate implementation.

[0031] NG, Xn, and F1 are logical interfaces. In the case of NG-RAN, the NG interface and Xn-C interface for a gNB comprising a gNB-CU and a gNB-DU terminate at the gNB-CU. In the case of E-UTRA-NR dual connectivity (EN-DC), the S1-U interface and X2-C interface for a gNB comprising a gNB-CU and a gNB-DU terminate at the gNB-CU. The gNB-CU and connected gNB-DU appear only as gNBs to other gNBs and 5GCs. The terms “central entity” and “distributed entity” refer to physical network nodes. Therefore, when this disclosure refers to a CU, it refers to an action (one or more) being performed by a CU, e.g., a CU-CP, gNB-CU-CP, or any entity contained within it.

[0032] This disclosure refers to the term "L1 / L2 base cell-to-cell mobility" as used in the work item description in 3GPP, but this disclosure also uses the terms L1 / L2 triggered mobility (LTM), lower layer mobility (LLM), L1 / L2 mobility, L1 mobility, L1 base mobility, L1 / L2 central cell-to-cell mobility, or L1 / L2 cell-to-cell mobility interchangeably. The basic principle is that the UE receives lower layer signaling from the network that instructs the UE to change (or switch or activate) the serving cell of the UE (e.g., a change of Pcell from a source Pcell to a target Pcell), and lower layer signaling is a message / signaling of lower layer protocols, sometimes called L1 / L2 cell-to-cell mobility execution command or cell switching command / message. A change in a serving cell (e.g., a change in a Pcell) can also lead to a change in (one or more) Scells for the same cell group, for example, if a command is triggered to change the UE to a different cell group setting of the same type (e.g., a different MCG setting).

[0033] Lower layer protocols refer to lower layer protocols in the air interface protocol stack compared to RRC protocols. For example, Media Access Control (MAC) is considered a lower layer protocol because it is "lower" than RRC in the air interface protocol stack, in which case lower layer signaling / messages may correspond to MAC control elements (MAC CEs). Another example of a lower layer protocol is Layer 1 (or physical layer, L1), in which case lower layer signaling / messages may correspond to Downlink Control Information (DCI). Signaling information at protocol layers lower than RRC reduces processing time and therefore reduces downtime during mobility. Furthermore, it can also increase mobility robustness because the network can respond to faster changes in channel conditions. Another relevant aspect of L1 / L2 inter-cell mobility is that in multi-beam scenarios, a cell may be associated with multiple SSBs, and different SSBs may be transmitted in different spatial directions (i.e., using different beams across the cell's coverage area) within a 1 / 2 frame. A similar line of reasoning may apply to CSI-RS resources, which can also be transmitted in different spatial directions. Therefore, in L1 / L2 inter-cell mobility, the reception of lower-layer signaling instructs the UE to switch from one beam in the serving cell to another beam in a neighboring cell (which is a configured candidate cell), thereby changing the serving cell (cell switching for LTM).

[0034] The phrase "lower-layer signaling that instructs the UE to perform the LTM cell switching procedure" refers to the messages / signals / instructions sent to the UE by the source network node to provide the UE with the information required for the LTM cell switching procedure. The signaling being "lower-layer" means that it is at a lower layer of the protocol stack than the RRC layer, such as an L1 and / or L2 signaling, like a Media Access Control Control Element (MAC CE). The UE initiates the LTM cell switching procedure upon receiving the lower-layer signaling that instructs the UE to perform the LTM cell switching procedure. However, this does not preclude the UE from initiating the LTM cell switching procedure based on other triggers or events.

[0035] This disclosure refers to the configuration of at least one LTM candidate target cell and the configuration of at least one LTM candidate target cell in a UE. This configuration may be an RRC configuration, such as one encapsulated in an RRC reconfiguration message that the UE receives when inter-DU L1 / L2 inter-cell mobility is configured. The LTM candidate target cell configuration includes the configuration necessary for the UE to begin acting accordingly when the UE performs an LTM cell switching procedure for that LTM candidate target cell, for example, upon receiving lower-layer signaling instructing the UE to perform an LTM cell switching procedure for that LTM candidate target cell, the LTM candidate target cell becomes a target cell and the current (new) SpCell, or SCell at the serving frequency. The LTM candidate target cell configuration includes parameters for a serving cell (or a group of serving cells, such as a cell group), which includes one or more of a group of parameters, such as an RRCReconfiguration message, IE CellGroupConfig, or IE SpCellConfig (or, for a secondary cell, IE ScellConfig). The LTM candidate target cell configuration may include, for example, one or more of the following: i) Pcell configuration and one or more Scell ​​configurations for a master cell group (MCG), and i) PSCell configuration and one or more Scell ​​configurations for a secondary cell group (SCG). The terms (LTM) candidate configuration, LTM configuration, (LTM) candidate target cell configuration, and (LTM) target candidate (cell) configuration may be used interchangeably when referring to the LTM candidate target cell configuration.

[0036] The phrase LTM cell switching procedure refers to the process by which a UE changes a cell in the UE from a source cell to a target cell using L1 / L2 triggered mobility. In the context of L1 / L2 base cell-to-cell mobility or L1 / L2 triggered mobility (LTM), an LTM cell switching procedure may also be known as dynamic switching, LTM switching, (LTM) cell switching, (LTM) serving cell change, or (LTM) cell change.

[0037] This disclosure also refers to the term "handling at least a secondary cell (Scell)," which means that in addition to a primary (secondary) cell (Pcell, PSCell) or special cell (SpCell), another cell is configured, and this cell is referred to as a secondary cell (Scell). This term may also include actions to create (generate) and / or release (discard) and / or change the configuration state of a secondary cell. For example, a UE configures an Scell ​​according to what was received in the LTM candidate target cell configuration and changes the "state" of the secondary cell to "activated" or "deactivated."

[0038] When this disclosure indicates that the action is “when the LTM cell switching procedure (also known as cell switching for LTM) is executed,” this includes any moment of reception of a lower-layer mobility command for cell switching in an LTM execution (e.g., a MAC CE instructing target candidate configuration), such as when the UE applies a lower-layer command (e.g., as part of an action in the UE’s MAC entity), or after the UE has performed random access to a target cell during LTM cell switching, or before the UE has performed random access to a target cell during LTM cell switching, or before / after the UE begins monitoring the PDCCH (or generally the control channel) in the target cell, or before the UE sends a first UL message to the target cell during LTM cell switching.

[0039] Figure 2 illustrates Method 200 according to a specific embodiment. Method 200 can be implemented by a network node (for example, network node QQ110 or network node QQ300, respectively, which will be described later with reference to Figures 5 and 7), such as a central unit-control plane (CU-CP) network node. Method 200 begins in step 202, which sends a message to a central unit-user plane (CU-UP) network node identifying the configuration of the CU-UP network node for a Layer 1 / Layer 2 triggered mobility (LTM) cell switching procedure by a user device (UE).

[0040] In some examples, method 200 may also include sending an instruction to the CU-UP network node that the LTM cell switching procedure has been executed by the UE. This instruction may be sent, for example, via E1AP signaling.

[0041] Method 200 may also, in some examples, include receiving from a CU-UP network node one or more transport network layer (TNL) addresses allocated to one or more LTM candidate target cells for the LTM cell switching procedure. The one or more TNL addresses may, for example, consist of one TNL address, or alternatively, for example, be allocated together to each of one or more LTM candidate target cells. Method 200 may also, in some examples, include sending a mapping to a CU-CP network node instructing the allocation between one or more TNL addresses and one or more LTM candidate target cells. The one or more TNL addresses may, in some examples, be uplink TNL addresses. In some examples, Method 200 may further include receiving from a CU-UP network node a status associated with one or more TNL addresses. The status associated with one or more TNL addresses may, for example, indicate that one or more TNL addresses should not be used unless specifically instructed, and / or should only be used after the UE has performed the LTM cell switching procedure on one or more LTM candidate target cells. Method 200 may, in some examples, also include sending one or more TNL addresses assigned to one or more LTM candidate target cells of one or more Distributed Unit (DU) network nodes to one or more Distributed Unit (DU) network nodes. The one or more TNL addresses may be sent, for example, via an F1 interface. In some examples, Method 200 may further include sending the status associated with the one or more TNL addresses to one or more Distributed Unit (DU) network nodes.

[0042] Method 200 may further include, in some examples, sending instructions to the CU-UP network node to buffer data packets until the LTM cell switching procedure is executed by the UE.

[0043] Messages identifying the configuration of a CU-UP network node may, for example, be a bearer context setup request or a bearer context modification request. In some examples, method 200, in response to the execution of an LTM cell switching procedure on a target cell that is one of one or more LTM candidate target cells for the LTM cell switching procedure, communicates to other LTM candidate target cells, as in the following non-limiting example: • An indication that one or more TNL addresses are unavailable. • An indication that the LTM cell switching procedure has been executed and / or completed. • An instruction that one or more TNL addresses should be deleted. • One or more new TNL addresses, and • TNL address associated with the target cell This may include sending one or more of the following.

[0044] Figure 3 illustrates Method 300 according to a particular embodiment. Method 300 can be implemented by a network node (for example, network node QQ110 or network node QQ300, respectively, as described later with reference to Figures 5 and 7), such as a central unit-user plane network node. Method 300 begins in step 302, receiving a message from a central unit-control plane (CU-CP) network node identifying the configuration of a CU-UP network node for a Layer 1 / Layer 2 triggered mobility (LTM) cell switching procedure by a user device (UE). In step 304, Method 300 includes assigning one or more transport network layer (TNL) addresses to one or more LTM candidate target cells for the LTM cell switching procedure.

[0045] In some examples, method 300 may further include sending one or more TNL addresses to a CU-CP network node. One or more TNL addresses may be included, for example, in a bearer context modification response message or a bearer context setup response message.

[0046] One or more TNL addresses may, in some examples, consist of a single TNL address, or alternatively, be allocated together to each of, for example, one or more LTM candidate target cells. One or more TNL addresses may, in some examples, be uplink TNL addresses.

[0047] Method 300 may, in some examples, include sending a mapping to a CU-CP network node instructing it to allocate one or more TNL addresses between one or more LTM candidate target cells. Additionally or alternatively, Method 300 may, in some examples, include receiving a status associated with one or more TNL addresses from a CU-UP network node. The status associated with one or more TNL addresses may, for example, indicate that one or more TNL addresses should not be used unless specifically instructed otherwise.

[0048] In some examples, method 300 further includes receiving an instruction from a CU-CP network node indicating that an LTM cell switchover has been performed to one of one or more LTM candidate target cells. Alternatively, in some examples, method 300 may include receiving a Downlink Data Delivery Service (DDDS) frame from a Distributed Unit (DU) network node indicating that an LTM cell switchover has been performed to one of one or more LTM candidate target cells. In either case, in some examples, method 300 may further include forwarding a data packet in response to receiving the instruction.

[0049] Figure 4 illustrates Method 400 according to a particular embodiment. Method 400 can be implemented by a network node (for example, network node QQ110 or network node QQ300, respectively, which will be described later with reference to Figures 5 and 7), such as a distributed unit (DU) network node. Method 400 begins in step 402, receiving one or more transport network layer (TNL) addresses assigned to one or more Layer 1 / Layer 2 trigger mobility (LTM) candidate target cells of a DU network node from a central unit-control plane (CU-CP) network node.

[0050] In some examples, method 400 further includes receiving a status associated with one or more TNL addresses from a CU-UP network node. One or more transport network layer (TNL) addresses and / or statuses may, in some examples, be included within a UE context correction request message. In any case, the status associated with one or more TNL addresses may indicate, for example, that one or more TNL addresses should not be used unless specifically instructed otherwise.

[0051] In some examples, Method 400 may further include updating the status of the TNL address assigned to a target cell to indicate that the TNL address is in use, in response to the execution of an LTM cell switching procedure for a target cell that is one of the one or more LTM candidate target cells. Additionally or alternatively, Method 400 may, in some examples, include discarding one or more TNL addresses and / or maintaining or updating the status associated with one or more TNL addresses to indicate that one or more TNL addresses should not be used unless specifically instructed, in response to the execution of an LTM cell switching procedure for a target cell that is not one of the one or more LTM candidate target cells. In some examples, Method 400 may also include sending a Downlink Data Delivery Service (DDDS) frame to a Central Unit-User Plane (CU-UP) network node indicating that an LTM cell switch has been performed to one of the one or more LTM candidate target cells.

[0052] Further exemplary embodiments implemented by a Central Unit-Control Plane (CU-CP) network node (also referred to herein as CU-CP) are presented below. These embodiments should be read and understood in the context of Method 200 presented with respect to Figure 2. Furthermore, further exemplary embodiments implemented by a Central Unit-User Plane (CU-UP) network node (also referred to herein as CU-UP) are presented below. These embodiments should be read and understood in the context of Method 300 presented with respect to Figure 3. Furthermore, further exemplary embodiments implemented by a Distributed Unit (DU) network node (also referred to herein as DU) are presented below. These embodiments should be read and understood in the context of Method 400 presented with respect to Figure 4. These embodiments are provided for illustrative purposes only.

[0053] In some embodiments, the CU-CP informs the CU-UP that the action being performed is an LTM. This method is referred to herein as "A1". For example, the CU-CP may send a bearer context modification request or a bearer context setup request instructing the CU-UP to perform an LTM configuration, or it may send a new message instructing an LTM configuration and / or informing the CU-UP that the action being performed is an LTM.

[0054] In some embodiments, the CU-CP informs the CU-UP that no new DL GTP-U TEIDs (one or more) will be used until the CU-UP is informed that a bearer context setup or bearer context modification procedure has been triggered by the initial setup of the LTM and that the UE has successfully accessed one of the target cells, or until early data forwarding is required. • The new UL GTP TEIDs (one or more) provided by CU-UP must be retained along with the old (i.e., already in use for that UE) UL GTP TEIDs (one or more) until the first PDCP packet is detected on the new F1-U tunnel (one or more). • New settings (such as PDCP settings or QoS remapping) will not be applied until the UE successfully accesses the target cell.

[0055] In one embodiment, a Downlink Data Delivery Service (DDDS) frame indicating that a switchover has occurred (that the UE has successfully accessed one of the target cells) is received by the CU-UP.

[0056] In another embodiment, CU-CP signals to CU-UP that the switchover occurred via E1AP signaling (that the UE successfully accessed one of the target cells).

[0057] In some embodiments, the CU-CP sends the CU-UP response to all DUs hosting the candidate cells via the F1 interface. This method is referred to herein as "A2".

[0058] For example, in some embodiments, the CU-CP forwards (one or more) UL TNL addresses received from the CU-UP to one or more candidate cells under the DU.

[0059] In some embodiments, when a CU-CP forwards (one or more) UL TNL addresses to a candidate cell, it may indicate that the status of a certain UL TNL address may be "deactivated," "not used," or "inactive," or any other technical term indicating that the UL TNL address should not be used unless specifically instructed otherwise.

[0060] In some embodiments, the CU-CP instructs the CU-UP to hold the packet until LTM execution. This method is referred to herein as "A3".

[0061] For example, in some embodiments, the CU-UP sends an indicator to the CU-UP in an E1AP message, such as a bearer context modification request.

[0062] In some embodiments, the CU-CP signals one or more of the following to the remaining candidate cells after the successful completion of the LTM (or LTM cell switching procedure): • Since the LTM (Long-Term Management) is complete, the UL TNL address is no longer usable and should be deleted. • The new UL TNL address that should be stored when an LTM cell switchover is triggered. • UL TNL addresses that were "activated" upon completion of the LTM cell switchover. (This implicitly indicates that UL TNL addresses with the status "activated" cannot be used.) This method is referred to as "A4" in this specification.

[0063] In some embodiments, signaling to the remaining candidate cells may include a request to modify the UE context or a new message.

[0064] In the case of LTM cell switching, in some embodiments where CU-CP (or CU-UP) has pre-configured two or more UL TNLs for a candidate cell, if no instruction is received by CU-CP, the candidate cell should keep the status of its UL TNL address as "deactivated," "not used," "inactive," or any other technical term indicating that the UL TNL address should not be used.

[0065] In some embodiments, the CU-CP restarts a procedure to obtain a new UL TNL address to be used for the LTM after the successful completion of the LTM (or LTM cell switching procedure), in accordance with the embodiments described above. This method is referred to herein as "A5".

[0066] In some embodiments, the CU-UP assigns only a single UL TNL address in response to being informed by the CU-CP that the action it is involved in is an LTM (for example, in response to receiving a message from the CU-CP informing the CU-UP that the action it is involved in is an LTM). This method is referred to herein as "B1".

[0067] In some embodiments, the CU-CP (or CU-UP) assigns only one UL TNL address, which is common to all candidate cells of one or more DUs.

[0068] In some embodiments, the CU-CP (or CU-UP) allocates a list of UL TNL addresses, which are common to all candidate cells of one or more DUs.

[0069] In this example, the initial status of all UL TNL addresses could be “deactivated,” “not in use,” “inactive,” or any other technical term indicating that the UL TNL address should not be used (or should not be used unless specifically instructed otherwise).

[0070] In one embodiment, the CU-CP (or CU-UP) allocates a list of UL TNL addresses, which includes a mapping of which UL TNL address should be assigned to which candidate cell of one or more DUs.

[0071] In some cases, the mapping may be ultimately determined by the CU-CP (or CU-UP) itself. Also, a single UL TNL address may be common to one or more candidate cells.

[0072] In some embodiments, the bearer context modification response may include a list containing (one or more) allocated UL TNL addresses and / or mappings.

[0073] In some embodiments, the CU-UP refrains from forwarding packets until it receives notification that LTM execution is in progress, in response to being instructed by the CU-CP to hold packets until LTM execution. This method is referred to herein as "B2". This notification may, in one example, be implicit when the CU-CP sends DL TEID in a bearer context modification request message.

[0074] In some embodiments, the CU-UP forwards the packet after receiving the above notification. This method is referred to herein as "B3".

[0075] In some embodiments, one or more DUs receive one or more UL TNL addresses for all candidate cells for the LTM (following the allocation of one or more UL TNL addresses). This method is referred to herein as "C1". In some embodiments, one or more UL TNL addresses may be included with the UE context modification request.

[0076] In some embodiments, the cell selected as the target cell for LTM cell switching uses the (one or more) UL TNL addresses received above. This method is referred to herein as "C2".

[0077] In some embodiments, a DU that has selected a cell as a target cell for LTM cell switching changes the status of the UL TNL address to "activated," or "on," or "available," or any other status indicating that this UL TNL address is currently in use.

[0078] In some embodiments, one or more DUs that were not selected as target cells for LTM cell switching discard the (one or more) UL TNL addresses received above. This method is referred to herein as "C3".

[0079] In some embodiments, a DU that has not selected a cell as a target cell for LTM cell switching changes the status of the UL TNL address to “deactivate,” “not in use,” “off,” “inactive,” or any other technical term indicating that the UL TNL address should not be used.

[0080] Next, an implementation example will be explained for illustrative purposes.

[0081] In some embodiments, the message in method A1 may be a bearer context setup request or a bearer context modification request instructing LTM configuration. In one example, the message in method A4 may be a UE context modification request. In one example, the message in method B1 may be a bearer context modification response. In one example, the message in method C1 may be a UE context modification request.

[0082] The underlined portion is introduced by this disclosure. The following sections are taken from the E1 Application Protocol (E1AP). 9.2.2.4 Bearer Context Correction Request This message is sent by gNB-CU-CP to request gNB-CU-UP to correct the bearer context. Direction: gNB-CU-CP->gNB-CU-UP TIFF2026515675000002.tif255167TIFF2026515675000003.tif255167TIFF2026515675000004.tif27170TIFF2026515675000005.tif17170

[0083] The following example is from the F1 Application Protocol (F1AP). 9.2.2.7 UE Context Correction Request This message is sent by gNB-CU to provide gNB-DU with UE context information changes. Direction:gNB-CU->gNB-DU TIFF2026515675000006.tif255167TIFF2026515675000007.tif255166TIFF202 6515675000008.tif255166TIFF2026515675000009.tif255167TIFF2026515675 000010.tif255166TIFF2026515675000011.tif255167TIFF2026515675000012. tif255166TIFF2026515675000013.tif255167TIFF2026515675000014.tif38170

[0084] Figure 5 shows an example of the QQ100 communication system according to several embodiments.

[0085] In this example, the communication system QQ100 includes a communication network QQ102 which includes an access network QQ104 such as a radio access network (RAN) and a core network QQ106 which includes one or more core network nodes QQ108. The access network QQ104 includes one or more access network nodes (one or more of which may commonly be referred to as network node QQ110), such as network nodes QQ110a and QQ110b, or any other similar Third Generation Partnership Project (3GPP) access node or non-3GPP access point. Furthermore, as will be understood by those skilled in the art, the network nodes are not necessarily limited to an implementation in which the radio portion and baseband portion are supplied and integrated by a single vendor. That is, it will be understood that the network nodes include a separate implementation or a part thereof. For example, in some embodiments, the communication network QQ102 includes one or more open RAN (ORAN) network nodes. An ORAN network node is a node in the communications network QQ102 that supports the ORAN specification (for example, a specification published by the O-RAN Alliance or any similar organization) and can operate alone or with other nodes to implement one or more functions of any node in the communications network QQ102, including one or more network nodes QQ110 and / or core network node QQ108.

[0086] An example of an ORAN network node includes an Open Radio Unit (O-RU), an Open Distributed Unit (O-DU), an Open Central Unit (O-CU) including an O-CU Control Plane (O-CU-CP) or O-CU User Plane (O-CU-UP), RAN Intelligent Controller (Semi-Real-Time or Non-Real-Time) Hosting Software or Software Plugin such as a quasi-real-time control application (e.g., xApp) or a non-real-time control application (e.g., rApp), or any combination thereof (the adjective "open" specifies support for the ORAN specification). A network node may support the specification by supporting interfaces defined by the ORAN specification, such as A1, F1, W1, E1, E2, X2, Xn interfaces, an Open Fronthaul User Plane Interface, or an Open Fronthaul Management Plane Interface. Furthermore, an ORAN access node may be a logical node within a physical node. In addition, an ORAN network node may be implemented in a virtualized environment in which one or more network functions are virtualized (as further described below). For example, a virtualized environment may include an O-cloud computing platform organized by a service management and orchestration framework via an O-2 interface defined by the O-RAN Alliance or equivalent technology. Network node QQ110 facilitates direct or indirect connectivity of user equipment (UEs), such as by connecting UEs QQ112a, QQ112b, QQ112c, and QQ112d (one or more of which are commonly referred to as UE QQ112) to the core network QQ106 over one or more wireless connections.

[0087] Exemplary wireless communication over a wireless connection involves transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without using wires, cables, or other material conductors. Furthermore, in different embodiments, the communication system QQ100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals, whether via a wired or wireless connection. The communication system QQ100 may include and / or interface with any type of communication, telecommunication, data, cellular, wireless network, and / or other similar types of systems.

[0088] UE QQ112 may be any of a wide variety of communication devices, including a wireless device configured, set up, and / or operable to communicate wirelessly with network node QQ110 and other communication devices. Similarly, network node QQ110 may be configured, capable, set up, and / or operable to communicate directly or indirectly with UE QQ112 and / or with other network nodes or devices in communication network QQ102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in communication network QQ102.

[0089] In the illustrated example, the core network QQ106 connects network node QQ110 to one or more hosts, such as host QQ116. These connections may be direct or indirect, via one or more intermediate networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network QQ106 includes one or more core network nodes (e.g., core network node QQ108) structured with hardware and software components. The characteristics of these components may be substantially similar to those described for the UE, network nodes, and / or hosts, and therefore their descriptions are generally applicable to the corresponding components of core network node QQ108. An exemplary core network node includes one or more functions from among the following: Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscriber Identifier Decryption Function (SIDF), Unified Data Management (UDM), Security Edge Protected Proxy (SEPP), Network Exposure Function (NEF), and / or User Plane Function (UPF).

[0090] Host QQ116 may be owned or controlled by a service provider other than the operator or provider of the access network QQ104 and / or the communication network QQ102, and may be operated by or on behalf of the service provider. Host QQ116 may host a variety of applications to provide one or more services. Examples of such applications include providing live and / or pre-recorded audio / video content, data collection services, analytical functions, social media, functions for controlling or, in some cases, interacting with remote devices, functions for alarms and surveillance centers, or any other such functions performed by the server.

[0091] Overall, the QQ100 communication system in Figure 5 enables connectivity between the UE, network nodes, and hosts. In this sense, the communication system may be configured to operate according to predefined rules or procedures, including, but not limited to, any other suitable wireless communication standards, such as GSM (Global System for Mobile Communications), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future-generation standard (e.g., 6G), wireless local area network (WLAN) standards such as the IEEE 802.11 standard (WiFi), and / or any other suitable wireless communication standards such as global interoperability for microwave access (WiMAX), Bluetooth, Z-Wave, near-field communications (NFC) ZigBee, LiFi, and / or LoRa and Sigfox, or any low-power wide area network (LPWAN) standards.

[0092] In some examples, the communication network QQ102 is a cellular network that implements 3GPP standardized features. Therefore, the communication network QQ102 may support network slicing to provide different logical networks to different devices connected to the communication network QQ102. For example, the communication network QQ102 may provide ultra-high reliability low latency communication (URLLC) services to some UEs while providing extended mobile broadband (eMBB) services to other UEs, and / or also provide massive machine-type communication (mMTC) / massive IoT services to further UEs.

[0093] In some examples, UE QQ112 is configured to transmit and / or receive information without direct human interaction. For example, the UE may be designed to transmit information to access network QQ104 on a predetermined schedule when triggered by an internal or external event, or in response to a request from access network QQ104. Furthermore, the UE may be configured to operate in single, multi-RAT, or multi-standard modes. For example, the UE may operate with one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Enhanced UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC).

[0094] In the example shown in Figure 5, the hub QQ114 communicates with the access network QQ104 to facilitate indirect communication between one or more UEs (e.g., UE QQ112c and / or QQ112d) and a network node (e.g., network node QQ110b). In some examples, the hub QQ114 may be a controller, a router, a content source and analysis node, or any other communication device described herein with respect to the UE. For example, the hub QQ114 may be a broadband router that enables access to the core network QQ106 for the UE. In another example, the hub QQ114 may be a controller that sends commands or instructions to one or more actuators in the UE. The commands or instructions may be received from the UE, the network node QQ110, or from executable code, scripts, processes, or other instructions in the hub QQ114. In yet another example, the hub QQ114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, can perform data analysis or other processing. As another example, the Hub QQ114 can be a content source. For example, for a UE that is a VR headset, display, loudspeaker, or other media distribution device, the Hub QQ114 can retrieve VR assets, video, audio, or other media or data related to sensory information via network nodes, which the Hub QQ114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In yet another example, the Hub QQ114 can act as a proxy server or orchestrator for the UE, especially if one or more of the UEs are low-energy IoT devices.

[0095] Hub QQ114 may have always-on / persistent or intermittent connections to network node QQ110b. Hub QQ114 may also enable different communication methods and / or schedules between Hub QQ114 and UEs (e.g., UE QQ112c and / or QQ112d), and between Hub QQ114 and the core network QQ106. In other examples, Hub QQ114 connects to the core network QQ106 and / or one or more UEs via a wired connection. Furthermore, Hub QQ114 may be configured to connect to an M2M service provider on the access network QQ104 and / or another UE via a direct connection. In some scenarios, a UE may establish a wireless connection with network node QQ110 while still being connected via wired or wireless connections through Hub QQ114. In some embodiments, the hub QQ114 may be a dedicated hub, i.e., a hub whose primary function is to route communication from the UE to the network node QQ110b and from the network node QQ110b to the UE. In other embodiments, the hub QQ114 may be a non-dedicated hub, i.e., a device that can operate to route communication between the UE and the network node QQ110b, but can also operate as a communication start point and / or end point for several data channels.

[0096] Figure 6 shows the UE QQ200 in several embodiments. As used herein, UE refers to a device that is capable of, configured, and / or operable of communicating wirelessly with network nodes and / or other UEs. Examples of UEs include, but are not limited to, smartphones, mobile phones, cell phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptop computers, laptop embedded equipment (LEE), laptop mounted equipment (LME), smart devices, wireless customer premises equipment (CPE), vehicles, vehicle-mounted or vehicle-embedded / integrated wireless devices, etc. Other examples include any UE identified by the Third Generation Partnership Project (3GPP), including narrowband Internet of Things (NB-IoT) UEs, machine-type communications (MTC) UEs, and / or enhanced MTC (eMTC) UEs.

[0097] A UE may support device-to-device (D2D) communication by implementing 3GPP standards for sidelink communication, dedicated short-range communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE does not necessarily have a user in the sense of a human user who owns and / or operates the associated device. Instead, a UE may represent a device (e.g., a smart sprinkler controller) that is intended to be sold to or operated by a human user, but may not be associated with a particular human user, or may not be initially associated with a particular human user. Alternatively, a UE may represent a device (e.g., a smart electricity meter) that is not intended to be sold to or operated by an end user, but may be associated with a user or may operate for the user's benefit.

[0098] UE QQ200 includes a processing circuit QQ202 operably coupled via bus QQ204 to an input / output interface QQ206, a power supply QQ208, a memory QQ210, a communication interface QQ212, and / or any other components, or any combination thereof. Some UEs may utilize all or a subset of the components shown in Figure 6. The level of integration between components may vary from UE to UE. Furthermore, some UEs may contain multiple instances of components, such as multiple processors, memories, transceivers, transmitters, and receivers.

[0099] The processing circuit QQ202 may be configured to process instructions and data and to implement any sequential state machine capable of executing instructions stored in memory QQ210 as a machine-readable computer program. The processing circuit QQ202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.), programmable logic with appropriate firmware, a microprocessor or digital signal processor (DSP) with appropriate software, one or more stored computer programs, a general-purpose processor, or any combination of the above. For example, the processing circuit QQ202 may include multiple central processing units (CPUs). The processing circuit QQ202 may be capable of providing UE QQ200 functionality either on its own or in conjunction with other UE QQ200 components, such as memory QQ210.

[0100] In this example, the input / output interface QQ206 may be configured to provide an input device, an output device, or one or more interfaces to one or more input and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, emitters, smart cards, other output devices, or any combination thereof. Input devices may allow a user to capture information to the UE QQ200. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, webcams, etc.), microphones, sensors, mice, trackballs, directional pads, trackpads, scroll wheels, smart cards, etc. Presence-sensitive displays may include capacitive or resistive touch sensors for detecting user input. Sensors may include, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, light sensors, proximity sensors, biosensors, or any combination thereof. Output devices may use the same type of interface port as input devices. For example, a Universal Serial Bus (USB) port may be used to provide input and output devices.

[0101] In some embodiments, the power supply QQ208 is structured as a battery or battery pack. Other types of power sources may be used, such as an external power source (e.g., an electrical outlet), a photovoltaic device, or a battery. The power supply QQ208 may further include a power circuit for distributing power from the power supply QQ208 itself and / or from an external power source via an interface such as an input circuit or power cable. Distributing power may, for example, be for charging the power supply QQ208. The power circuit may perform any formatting, conversion, or other modifications to the power from the power supply QQ208 to make that power suitable for each component of the UE QQ200 to which it is supplied.

[0102] Memory QQ210 may be memory, or configured to contain memory, such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, or flash drives. For example, memory QQ210 may contain one or more application programs QQ214, such as an operating system, web browser application, widget, gadget engine, or other application, and corresponding data QQ216. Memory QQ210 may store any of a variety of operating systems or combinations of operating systems for use by the UE QQ200.

[0103] The QQ210 memory can be configured to include several physical drive units, such as a redundant array of independent disks (RAID), flash memory, USB flash drives, external hard disk drives, thumb drives, pen drives, key drives, high-density digital versatile disk (HD-DVD) optical drives, internal hard disk drives, Blu-ray optical drives, holographic digital data storage (HDDS) optical drives, external mini dual in-line memory modules (DIMMs), synchronous dynamic random access memory (SDRAM), external microDIMM SDRAM, smart card memory such as a tamper-proof module in the form of a universal integrated circuit card (UICC) containing one or more subscriber identification modules (SIMs) such as USIM and / or ISIM, other memory, or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly known as a "SIM card". Memory QQ210 may enable UE QQ200 to access instructions, application programs, etc., stored in temporary or non-temporary memory media, to offload data, or to upload data. Products such as products utilizing communication systems may be tangibly embodied as or within memory QQ210, and memory QQ210 may be a device-readable storage medium or may contain a device-readable storage medium.

[0104] The processing circuit QQ202 may be configured to communicate with an access network or other networks using the communication interface QQ212. The communication interface QQ212 may comprise one or more communication subsystems, including or communicatively coupled to an antenna QQ222. The communication interface QQ212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or network node in the access network). Each transceiver may include a transmitter QQ218 and / or a receiver QQ220 suitable for providing network communication (e.g., optical, electrical, frequency-allocated, etc.). Furthermore, the transmitter QQ218 and receiver QQ220 may be coupled to one or more antennas (e.g., antenna QQ222), and may share circuit components, software, or firmware, or alternatively, may be implemented separately.

[0105] In some embodiments, the communication functions of the communication interface QQ212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication such as the use of the Global Positioning System (GPS) to determine location, other similar communication functions, or any combination thereof. Communication may be implemented in accordance with one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMAX, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.

[0106] Regardless of the sensor type, a UE may provide the output of data captured by its sensors to network nodes via a wireless connection through the UE's communication interface QQ212. The data captured by the UE's sensors may be communicated to network nodes via another UE through a wireless connection. The output may be periodic (e.g., once every 15 minutes if reporting detected temperature), in response to a triggering event (e.g., an alarm is sent when humidity is detected), in response to a request (e.g., a user-initiated request), random (e.g., to equalize the load from reports from several sensors), or a continuous stream (e.g., a live video feed of a patient).

[0107] As another example, the UE may include an actuator, motor, or switch relating to a communication interface configured to receive radio input from a network node via a wireless connection. In response to the received radio input, the state of the actuator, motor, or switch may change. For example, the UE may include a motor that adjusts the control surface or rotor of a drone in flight according to the received input, or controls a robotic arm that performs a medical procedure according to the received input.

[0108] A UE, in the form of an Internet of Things (IoT) device, can be a device for use in one or more application domains, which include, but are not limited to, urban wearable technology, augmented industrial applications, and healthcare. Non-exclusive examples of such IoT devices are devices that are connected refrigerators or freezers, TVs, connected lighting devices, energy meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / humidity sensors, electric door locks, connected doorbells, air conditioning systems such as heat pumps, autonomous vehicles, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearables for haptic augmentation or perceptual augmentation, water sprinklers, animal or product tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any kind of medical device such as a heart rate monitor or remotely controlled surgical robot, or devices embedded in them. The UE in the form of an IoT device includes, in addition to the other components described with respect to the UE QQ200 shown in Figure 6, circuitry and / or software depending on the intended application of the IoT device.

[0109] In another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another UE and / or network node. In this case, the UE could be an M2M device, which is sometimes called an MTC device in a 3GPP context. In one specific example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, the UE may represent a vehicle, such as a car, bus, truck, ship, and airplane, or other equipment capable of monitoring its operational status and / or reporting on its operational status, or other functions associated with its operation.

[0110] In practice, any number of UEs can be used together for a single use case. For example, the first UE may be the drone itself, or integrated within the drone, providing the drone's speed information (obtained through a speed sensor) to the second UE, which is the remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (for example, by controlling an actuator) to increase or decrease the drone's speed. The first and / or second UEs may also include two or more of the functions described above. For example, the UE may have sensors and actuators and handle the communication of data about both the speed sensor and the actuator.

[0111] Figure 7 shows a network node QQ300 according to several embodiments. As used herein, a network node refers to a device that is configured, set up, and / or operable to communicate directly or indirectly with UEs in a communication network and / or with other network nodes or devices. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, node B, evolved node B (eNB), and NR node B (gNB)), O-RAN nodes, or components of O-RAN nodes (e.g., O-RU, O-DU, O-CU). In some embodiments, the network node QQ300 may be a central unit-control plane network node, a central unit-user plane network node, or a distributed network node.

[0112] Base stations can be categorized based on the amount of coverage they provide (or, in other words, the base station's transmit power level), and are therefore sometimes called femto base stations, pico base stations, micro base stations, or macro base stations, depending on the amount of coverage they provide. A base station can be a relay node or relay donor node that controls relays. Network nodes may also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit, a distributed unit (e.g., one in an O-RAN access node), and / or a remote radio unit (RRU), sometimes called a remote radio head (RRH). Such remote radio units may or may not be integrated with an antenna as an antenna-integrated radio. Parts of a distributed radio base station are sometimes called nodes in a distributed antenna system (DAS).

[0113] Other examples of network nodes include multiple transmit point (multi-TRP) 5G access nodes, MSR equipment such as multi-standard radio (MSR) BS, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base station transceiver stations (BTSs), transmit points, transmit nodes, multi-cell / multicast coordinated entities (MCEs), operation and maintenance (O&M) nodes, operation support system (OSS) nodes, self-organizing network (SON) nodes, positioning nodes (e.g., evolved serving mobile location centers (E-SMLCs)), and / or drive test minimization (MDTs).

[0114] Network node QQ300 includes a processing circuit QQ302, memory QQ304, communication interface QQ306, and power supply QQ308, and / or any other components, or any combination thereof. Network node QQ300 can be assembled from multiple physically distinct components (e.g., node B components and RNC components, or BTS components and BSC components), each of which may have its own respective components. In some scenarios where network node QQ300 has multiple distinct components (e.g., BTS components and BSC components), one or more of the distinct components may be shared among several network nodes. For example, a single RNC may control multiple node Bs. In such a scenario, each unique node B-RNC pair may, in some cases, be considered a single distinct network node. In some embodiments, network node QQ300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory QQ304 for different RATs), and some components may be reused (e.g., the same antenna QQ310 may be shared by different RATs). Network node QQ300 may also include multiple sets of various shown components for different radio technologies, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth radio technologies, integrated into network node QQ300. These radio technologies may be integrated into the same or different chips or sets of chips, and other components within network node QQ300.

[0115] The processing circuit QQ302 may comprise one or more combinations of microprocessors, controllers, microcontrollers, central processing units, digital signal processors, application-specific integrated circuits, field-programmable gate arrays, or any other suitable computing devices, resources, or combinations of hardware, software, and / or encoded logic, capable of operating to provide network node QQ300 functionality, either alone or in conjunction with other network node QQ300 components such as memory QQ304. For example, the processing circuit QQ302 may be configured to cause a network node to implement the methods described with reference to any of Figures 2 to 4.

[0116] In some embodiments, the processing circuit QQ302 includes a system-on-a-chip (SOC). In some embodiments, the processing circuit QQ302 includes one or more of the radio frequency (RF) transceiver circuit QQ312 and the baseband processing circuit QQ314. In some embodiments, the radio frequency (RF) transceiver circuit QQ312 and the baseband processing circuit QQ314 may be on separate chips (or sets of chips), boards, or units such as radio and digital units. In alternative embodiments, some or all of the RF transceiver circuit QQ312 and the baseband processing circuit QQ314 may be on the same chip or set of chips, board, or unit.

[0117] Memory QQ304 may include, but is not limited to, any form of volatile or non-volatile computer-readable memory, including persistent storage, solid memory, remote-mount memory, magnetic media, optical media, random-access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disks), removable storage media (e.g., flash drives, compact discs (CDs), or digital video discs (DVDs)), and / or any other volatile or non-volatile, non-temporary device-readable and / or computer-executable memory devices that store information, data, and / or instructions that can be used by the processing circuit QQ302. Memory QQ304 may store any suitable instructions, data, or information, including other instructions, that can be executed by the processing circuit QQ302 and utilized by the network node QQ300, including applications that include one or more computer programs, software, logic, rules, code, and tables. Memory QQ304 may be used to store calculations performed by the processing circuit QQ302 and / or data received via the communication interface QQ306. In some embodiments, the processing circuit QQ302 and memory QQ304 are integrated.

[0118] The communication interface QQ306 is used in wired or wireless signaling and / or data between network nodes, access networks, and / or UEs. As shown, the communication interface QQ306 includes (one or more) ports / (one or more) terminals QQ316 for sending and receiving data to and from the network, for example, over a wired connection. The communication interface QQ306 also includes a wireless front-end circuit QQ318, which is coupled to or, in some embodiments, may be part of the antenna QQ310. The wireless front-end circuit QQ318 includes a filter QQ320 and an amplifier QQ322. The wireless front-end circuit QQ318 may be connected to the antenna QQ310 and the processing circuit QQ302. The wireless front-end circuit may be configured to adjust signals communicated between the antenna QQ310 and the processing circuit QQ302. The wireless front-end circuit QQ318 may receive digital data to be sent to other network nodes or UEs via the wireless connection. The wireless front-end circuit QQ318 can convert digital data into a radio signal with appropriate channel and bandwidth parameters using a combination of filter QQ320 and / or amplifier QQ322. The radio signal can then be transmitted via antenna QQ310. Similarly, when receiving data, antenna QQ310 can collect a radio signal, which is then converted into digital data by the wireless front-end circuit QQ318. The digital data can then be passed to processing circuit QQ302. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0119] In some alternative embodiments, the network node QQ300 does not include a separate radio front-end circuit QQ318; instead, the processing circuit QQ302 includes the radio front-end circuit and is connected to the antenna QQ310. Similarly, in some embodiments, all or part of the RF transceiver circuit QQ312 is part of the communication interface QQ306. In yet another embodiment, the communication interface QQ306, as part of a radio unit (not shown), includes one or more ports or terminals QQ316, the radio front-end circuit QQ318, and the RF transceiver circuit QQ312, and the communication interface QQ306 communicates with a baseband processing circuit QQ314, which is part of a digital unit (not shown).

[0120] Antenna QQ310 may include one or more antennas or antenna arrays configured to transmit and / or receive radio signals. Antenna QQ310 may be coupled to the radio front-end circuit QQ318 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna QQ310 is separate from the network node QQ300 and can be connected to the network node QQ300 through an interface or port.

[0121] The antenna QQ310, the communication interface QQ306, and / or the processing circuit QQ302 may be configured to perform any receiving operations and / or certain acquisition operations as described herein as being performed by a network node. Any information, data, and / or signals may be received from the UE, another network node, and / or any other network equipment. Similarly, the antenna QQ310, the communication interface QQ306, and / or the processing circuit QQ302 may be configured to perform any transmitting operations as described herein as being performed by a network node. Any information, data, and / or signals may be transmitted to the UE, another network node, and / or any other network equipment.

[0122] Power supply QQ308 provides power to the various components of network node QQ300 in a form suitable for each component (for example, at the voltage and current levels required for each respective component). Power supply QQ308 may further include, or be coupled to, a power management circuit for supplying power to the components of network node QQ300 to perform the functions described herein. For example, network node QQ300 may be connectable to an external power source (e.g., a power grid, an electrical outlet) via an input circuit or interface such as an electrical cable, thereby the external power source powers the power circuit of power supply QQ308. As a further example, power supply QQ308 may include a power source in the form of a battery or battery pack, connected to or integrated into the power circuit. The battery may provide backup power in the event of an external power failure.

[0123] Embodiments of network node QQ300 may include additional components other than those shown in Figure 7 to provide several aspects of the network node's functionality, including any of the functions described herein and / or functions necessary to support the subject matter described herein. For example, network node QQ300 may include user interface equipment for enabling information input to and output from network node QQ300. This may enable a user to perform diagnostic, maintenance, repair, and other administrative functions for network node QQ300.

[0124] Figure 8 is a block diagram of host QQ400, which may be one embodiment of host QQ116 in Figure 5, according to various aspects described herein. Host QQ400 as used herein may be a variety of hardware and / or software combinations, or comprise a variety of hardware and / or software combinations, including standalone servers, blade servers, cloud implementation servers, distributed servers, virtual machines, containers, or processing resources in a server farm. Host QQ400 may provide one or more services to one or more UEs.

[0125] The host QQ400 includes a processing circuit QQ402 operably coupled to an input / output interface QQ406, a network interface QQ408, a power supply QQ410, and memory QQ412 via a bus QQ404. Other embodiments may include other components. The characteristics of these components may be substantially the same as those described with respect to the devices in previous figures, such as Figures 6 and 7, and therefore their descriptions are generally applicable to the corresponding components of the host QQ400.

[0126] Memory QQ412 may include one or more computer programs, including one or more host application programs QQ414 and data QQ416, where data QQ416 may include user data, for example, data generated by the UE for host QQ400, or data generated by host QQ400 for the UE. Embodiments of host QQ400 may utilize only a subset or all of the components shown. Host application program QQ414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Multipurpose Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementation forms of the UE (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application program QQ414 can also provide user authentication and license checks, and can periodically report health, root, and content availability to a central node, such as devices in the core network or devices at the edge of the core network. Thus, the host QQ400 can select and / or direct different hosts for over-the-top services for the UE. The host application program QQ414 can support various protocols, including HTTP Live Streaming (HLS), Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), and Dynamic Adaptive Streaming over HTTP (MPEG-DASH).

[0127] Figure 9 is a block diagram showing a virtualized environment QQ500 in which functions implemented by several embodiments can be virtualized. In this context, virtualization means creating a virtual version of a device or apparatus, which may include virtualizing hardware platforms, storage devices, and networking resources. The virtualization used herein may apply to any device or its components described herein and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components, executed by one or more virtual machines (VMs) implemented in one or more virtualized environments QQ500 hosted by one or more hardware nodes, such as network nodes, UEs, core network nodes, or hardware computing devices acting as hosts. Furthermore, in embodiments in which the virtual nodes do not require radio connectivity (e.g., core network nodes or hosts), the nodes may be fully virtualized. In some embodiments, the virtualized environment QQ500 includes components defined by the O-RAN Alliance, such as an O-cloud environment organized by a service management and orchestration framework via an O-2 interface.

[0128] Application QQ502 (which may alternatively be referred to as a software instance, virtual appliance, network function, virtual node, virtual network function, etc.) runs in the virtualized environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0129] Hardware QQ504 includes processing circuits, memory for storing software and / or instructions executable by the hardware processing circuits, and / or other hardware devices described herein, such as network interfaces and input / output interfaces. The software is executed by the processing circuits to instantiate one or more virtualization layers QQ506 (also called a hypervisor or virtual machine monitor (VMM)), providing VM QQ508a and QQ508b (one or more of which may commonly be referred to as VM QQ508), and / or may implement any of the functions, features, and / or benefits described with respect to some embodiments described herein. The virtualization layer QQ506 may present VM QQ508 with a virtual operating platform that appears to be networking hardware.

[0130] VM QQ508 features virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be powered by the corresponding virtualization layer QQ506. Different embodiments of the virtual appliance QQ502 may be implemented on one or more VM QQ508s, and the implementation may be carried out in different ways. Hardware virtualization is referred to as network function virtualization (NFV) in several contexts. NFV can be used to consolidate many types of network equipment onto industry-standard high-volume server hardware, physical switches, and physical storage, which may reside in data centers and customer premises equipment.

[0131] In the context of NFV, a VM QQ508 can be a software implementation of a physical machine, where programs run as if they were running on a physical, non-virtualized machine. Each VM QQ508 and its portion of the hardware QQ504 on which it runs, whether dedicated hardware for that VM and / or hardware shared by that VM with other VMs in the VM, form a separate virtual network element. Furthermore, in the context of NFV, the virtual network function is responsible for handling specific network functions running in one or more VM QQ508s on the hardware QQ504, and corresponds to the application QQ502.

[0132] Hardware QQ504 can be implemented in a standalone network node with general or specific components. Hardware QQ504 can implement some functions through virtualization. Alternatively, Hardware QQ504 may be part of a larger cluster of hardware (such as in a data center or CPE) where many hardware nodes cooperate and are managed via management and orchestration QQ510, which oversees the lifecycle management of applications QQ502. In some embodiments, Hardware QQ504 is coupled to one or more radio units, each including one or more transmitters and one or more receivers, which may be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more suitable network interfaces and may be used in combination with virtual components to provide a virtual node with radio capabilities, such as a radio access node or base station. In some embodiments, some signaling may be provided using a control system QQ512, which may be used alternatively for communication between hardware nodes and radio units.

[0133] Figure 10 shows a communication diagram of host QQ602 communicating with UE QQ606 via network node QQ604 over a partial wireless connection, according to several embodiments. Next, exemplary implementations of various embodiments of the UE (such as UE QQ112a in Figure 5 and / or UE QQ200 in Figure 6), network nodes (such as network node QQ110a in Figure 5 and / or network node QQ300 in Figure 7), and hosts (such as host QQ116 in Figure 5 and / or host QQ400 in Figure 8), as described in the previous paragraph, will be described with reference to Figure 10.

[0134] Similar to the host QQ400, embodiments of the host QQ602 include hardware such as a communication interface, processing circuitry, and memory. The host QQ602 also includes software that is stored in or accessible by the host QQ602 and executable by the processing circuitry. The software includes a host application that may be capable of operating to serve a remote user, such as a UE QQ606 connected via an over-the-top (OTT) connection QQ650 extending between the UE QQ606 and the host QQ602. When serving a remote user, the host application may provide user data transmitted using the OTT connection QQ650.

[0135] Network node QQ604 includes hardware that enables network node QQ604 to communicate with host QQ602 and UE QQ606. Connectivity QQ660 can be direct or traverse one or more other intermediate networks, such as a core network (similar to core network QQ106 in Figure 5) and / or one or more public networks, private networks, or hosted networks. For example, the intermediate network could be a backbone network or the internet.

[0136] The UE QQ606 includes hardware and software that is stored in or accessible by the UE QQ606 and executable by the UE's processing circuitry. The software includes client applications, such as a web browser or operator-specific “app,” which may be capable of operating to serve human or non-human users through the UE QQ606, with the support of the host QQ602. On the host QQ602, the running host application may communicate with the running client application via the UE QQ606 and the OTT connection QQ650, which terminates on the host QQ602. When serving a user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection QQ650 may transfer both the request data and the user data. The UE's client application may interact with the user to generate user data that the UE's client application provides to the host application via the OTT connection QQ650.

[0137] The OTT connection QQ650 may extend via connection QQ660 between host QQ602 and network node QQ604, and via radio connection QQ670 between network node QQ604 and UE QQ606, in order to provide connectivity between host QQ602 and UE QQ606. The connections QQ660 and radio connection QQ670, which the OTT connection QQ650 may provide, are depicted abstractly to illustrate communication between host QQ602 and UE QQ606 via network node QQ604, without explicit reference to the intermediary devices and the precise routing of messages through these devices.

[0138] As an example of transmitting data via an OTT connection QQ650, in step QQ608, host QQ602 provides user data, which may be done by running a host application. In some embodiments, the user data is associated with a specific human user interacting with UE QQ606. In other embodiments, the user data is associated with UE QQ606 sharing data with host QQ602 without explicit human interaction. In step QQ610, host QQ602 initiates a transmission to carry the user data toward UE QQ606. Host QQ602 may initiate a transmission in response to a request sent by UE QQ606. The request may be triggered by human interaction with UE QQ606 or by the operation of a client application running on UE QQ606. The transmission may proceed through network node QQ604, as taught in the embodiments described throughout this disclosure. Accordingly, in step QQ612, network node QQ604 transmits the user data carried in the transmission initiated by host QQ602 to UE QQ606, in accordance with the teachings of the embodiments described throughout this disclosure. In step QQ614, UE QQ606 receives the user data carried in the transmission, which may be done by a client application running on UE QQ606 associated with a host application run by host QQ602.

[0139] In some examples, UE QQ606 runs a client application that provides user data to host QQ602. User data may be provided in response to or in reaction to data received from host QQ602. Thus, in step QQ616, UE QQ606 may provide user data, which may be done by running a client application. When providing user data, the client application may further consider user input received from the user via the input / output interface of UE QQ606. Regardless of the particular format in which the user data is provided, UE QQ606 initiates the transmission of the user data to host QQ602 via network node QQ604 in step QQ618. In step QQ620, in accordance with the teachings of embodiments described throughout this disclosure, network node QQ604 receives user data from UE QQ606 and initiates the transmission of the received user data to host QQ602. In step QQ622, host QQ602 receives user data carried in a transmission initiated by UE QQ606.

[0140] One or more of the various embodiments improve the performance of OTT services provided to UE QQ606 by using an OTT connection QQ650 in which the wireless connection QQ670 forms the final segment. More precisely, the teachings of these embodiments may improve latency and thereby provide benefits such as reduced user latency.

[0141] In an exemplary scenario, factory status information may be collected and analyzed by the host QQ602. As another example, the host QQ602 may process audio and video data that may be extracted from the UE for use in creating maps. As yet another example, the host QQ602 may collect and analyze real-time data to help control vehicle congestion (e.g., control traffic signals). As yet another example, the host QQ602 may store surveillance video uploaded by the UE. As yet another example, the host QQ602 may store or control access to media content, such as video, audio, VR, or AR, which the host QQ602 can broadcast, multicast, or unicast to the UE. As yet another example, the host QQ602 may be used for energy pricing, remote control of non-time-constrained electrical loads to balance generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, extracting, storing, analyzing, and / or transmitting data.

[0142] In some embodiments, measurement procedures may be provided for the purpose of monitoring data rate, latency, and other factors, which are improved by one or more embodiments. Further optional network functions may be available to reconfigure the OTT connection QQ650 between host QQ602 and UE QQ606 in response to variations in measurement results. Measurement procedures and / or network functions for reconfiguring the OTT connection may be implemented in the software and hardware of host QQ602 and / or UE QQ606. In some embodiments, sensors (not shown) may be deployed in or in relation to other devices through which the OTT connection QQ650 passes, and the sensors may participate in the measurement procedure by supplying values ​​of the monitored quantities exemplified above, or values ​​of other physical quantities that the software can calculate or estimate the monitored quantities of. Reconfiguring the OTT connection QQ650 may include message formatting, retransmission settings, preferred routing, etc., and the reconfiguration does not require direct modification of the operation of network node QQ604. Such procedures and functions are known and practiced in the art. In some embodiments, the measurements may involve proprietary UE signaling by the host QQ602 to facilitate measurements such as throughput, propagation time, and latency. The measurements may be implemented in which software uses an OTT-connected QQ650 to cause messages, particularly empty or "dummy" messages, to be sent while monitoring propagation time, errors, etc.

[0143] This disclosure includes the following listed embodiments.

[0144] Group A Embodiment 1. A method implemented by a central unit-control plane (CU-CP) network node, wherein the method is Send a message to the central unit-user plane (CU-UP) network node to identify the configuration of the CU-UP network node for the Layer 1 / Layer 2 triggered mobility (LTM) cell switching procedure performed by the user equipment (UE). Methods that include... 2. Send an instruction to the CU-UP network node that an LTM cell switchover has been performed to one of the one or more LTM candidate target cells. The method according to Embodiment 1, further comprising: 3. The method according to Embodiment 2, wherein instructions are sent via E1AP signaling. 4. Receiving one or more Transport Network Layer (TNL) addresses assigned to one or more LTM candidate target cells from a CU-UP network node. The method according to any one of embodiments 1 to 3, further comprising: 5. The method according to Embodiment 4, wherein one or more TNL addresses include one TNL address. 6. The method according to Embodiment 4, wherein one or more TNL addresses are collectively assigned to each of one or more LTM candidate target cells. 7. The method according to any one of embodiments 4 to 6, further comprising sending a mapping to a CU-CP network node that instructs the allocation between one or more TNL addresses and one or more LTM candidate target cells. 8. The method according to any one of embodiments 4 to 7, wherein one or more TNL addresses are uplink TNL addresses. 9. The method is Receive status information associated with one or more TNL addresses from CU-UP network nodes. The method according to any one of embodiments 4 to 8, further comprising: 10. The method according to Embodiment 9, wherein the status associated with one or more TNL addresses indicates that one or more TNL addresses should not be used unless specifically instructed, and / or should only be used after the UE has performed an LTM cell switching procedure on one or more LTM candidate target cells. 11. Send one or more TNL addresses assigned to one or more LTM candidate target cells of one or more Distributed Unit (DU) network nodes to one or more Distributed Unit (DU) network nodes. The method according to any one of embodiments 4 to 10, further comprising: 12. The method according to embodiment 11, wherein one or more TNL addresses are sent via the F1 interface. 13. When dependent on Embodiment 9 or 10, Sending status associated with one or more TNL addresses to one of one or more DU network nodes. The method according to embodiment 11 or 12, further comprising: 14. Send an instruction to the CU-UP network node to buffer data packets until the LTM cell switching procedure to one of the one or more LTM candidate target cells is executed. The method according to any one of embodiments 1 to 13, further comprising: 15. The method according to any one of embodiments 1 to 14, wherein a message identifying the configuration of a CU-UP network node includes a bearer context setup request or a bearer context modification request. 16. In response to the execution of an LTM cell switching procedure on a target cell that is one of one or more LTM candidate target cells, the other LTM candidate target cells An indication that one or more TNL addresses are unavailable. An indication that the LTM cell switching procedure has been executed and / or completed. An instruction that one or more TNL addresses should be deleted. One or more new TNL addresses, as well as TNL address associated with the target cell Send one or more of the following The method according to any one of embodiments 1 to 15, further comprising: 17. Obtaining user data, Forwarding user data to a host or user device and The method according to any one of embodiments 1 to 16, further comprising:

[0145] Group B Embodiment 18. A method implemented by a central unit-user plane (CU-UP) network node, the method being Receiving messages from the central unit-control plane (CU-CP) network node to identify the configuration of the CU-UP network node for the Layer 1 / Layer 2 triggered mobility (LTM) cell switching procedure by the user equipment (UE), Assigning one or more Transport Network Layer (TNL) addresses to one or more LTM candidate target cells Methods that include... 19. Send one or more TNL addresses to a CU-CP network node. The method according to Embodiment 18, further including the method described in Embodiment 18. 20. The method according to Embodiment 19, wherein one or more TNL addresses are included in the bearer context modification response message or the bearer context setup response message. 21. The method according to any one of embodiments 18 to 20, wherein one or more TNL addresses include one TNL address. 22. The method according to any one of embodiments 18 to 20, wherein one or more TNL addresses are collectively assigned to each of one or more LTM candidate target cells. twenty three. Sending a mapping to a CU-CP network node instructing it to allocate one or more TNL addresses between one or more LTM candidate target cells. The method according to any one of embodiments 18 to 22, further comprising: 24. The method according to any one of embodiments 18 to 23, wherein one or more TNL addresses are uplink TNL addresses. 25. The method is Receive status information associated with one or more TNL addresses from CU-UP network nodes. The method according to any one of embodiments 18 to 24, further comprising: 26. The method of Embodiment 25, wherein the status associated with one or more TNL addresses indicates that one or more TNL addresses should not be used unless specifically indicated otherwise. 27. The method is, Receiving an instruction from the CU-CP network node that an LTM cell switchover has been performed to one of the one or more LTM candidate target cells. The method according to any one of embodiments 18 to 26, further including the method described above. 28. The method is, Receiving a Downlink Data Delivery Service (DDDS) frame from a Distributed Unit (DU) network node indicating that an LTM cell switchover has been performed to one of one or more LTM candidate target cells. The method according to any one of embodiments 18 to 26, further including the method described above. 29. The method is To forward data packets in response to receiving instructions. The method according to embodiment 27 or 28, further comprising: 30. Obtaining user data, Forwarding user data to a host or user device and The method according to any one of embodiments 18 to 29, further including the method described above.

[0146] Group C Embodiment 31. A method implemented by a distributed unit (DU) network node, the method is Receiving one or more Transport Network Layer (TNL) addresses assigned to one or more Layer 1 / Layer 2 Trigger Mobility (LTM) candidate target cells of a DU network node from a Central Unit-Control Plane (CU-CP) network node. Methods that include... 32. The method is Receive status information associated with one or more TNL addresses from CU-UP network nodes. The method according to Embodiment 31, further comprising: 33. The method according to embodiment 31 or 32, wherein one or more transport network layer (TNL) addresses and / or statuses are included in the UE context correction request message. 34. The method according to embodiment 32 or 33, wherein the status associated with one or more TNL addresses indicates that one or more TNL addresses should not be used unless specifically indicated otherwise. 35. In response to the execution of an LTM cell switching procedure on a target cell that is one of one or more LTM candidate target cells, the method: Update the status of the TNL address assigned to the target cell to indicate that the TNL address is in use. The method according to any one of embodiments 31 to 34, further including the method described above. 36. In response to the execution of an LTM cell switching procedure on a target cell that is not one of the one or more LTM candidate target cells, the method: Discarding one or more TNL addresses, and Maintain or update the status associated with one or more TNL addresses to indicate that one or more TNL addresses should not be used unless specifically instructed otherwise. The method according to any one of embodiments 31 to 35, further comprising one or more of the above. 37. Send a Downlink Data Delivery Service (DDDS) frame to a Central Unit-User Plane (CU-UP) network node indicating that an LTM cell switchover to one of the one or more LTM candidate target cells has been performed. The method according to any one of embodiments 31 to 36, further including the method described above. 38. Obtaining user data, Forwarding user data to a host or user device and The method according to any one of embodiments 31 to 37, further including the method described above.

[0147] Group D Embodiment 39. A network node, and the network node is A processing circuit configured to cause a network node to perform any of the steps described in any one of the embodiments of groups A to C, A power supply circuit configured to supply power to the processing circuit and A network node equipped with these features. 40. A network node, and the network node is A processing circuit configured to cause a network node to perform any of the steps described in any one of the embodiments of groups A to C, A power supply circuit configured to supply power to the processing circuit and A network node equipped with these features. 41. A network node, and the network node is A processing circuit configured to cause a network node to perform any of the steps described in any one of the embodiments of groups A to C, A power supply circuit configured to supply power to the processing circuit and A network node equipped with these features. 42. A host configured to operate in a communication system for providing over-the-top (OTT) services, wherein the host is A processing circuit configured to provide user data, A network interface configured to initiate the transmission of user data to a network node in a cellular network for transmission to a user equipment (UE), wherein the network node has a communication interface and a processing circuit, and the processing circuit of the network node is configured to perform any of the operations described in any one of the embodiments of groups A to C in order to transmit user data from a host to a UE, and A host equipped with these features. 43. The host processing circuit is configured to run a host application that provides user data. The UE includes processing circuitry configured to run a client application associated with the host application in order to receive user data transmitted from the host. The host described in Embodiment 42. 44. A method implemented on a host configured to operate in a communication system further including network nodes and user equipment (UE), the method being: To provide user data for UE, Initiating a transmission to transport user data to a UE via a cellular network comprising network nodes, wherein the network node performs any of the operations described in any one of the embodiments of groups A to C in order to transmit user data from a host to a UE. Methods that include... 45. The method of embodiment 44, further comprising transmitting user data provided by the host for the UE at a network node. 46. ​​The method according to Embodiment 44 or 45, wherein user data is provided on the host by running a host application that interacts with a client application running on the UE, and the client application is associated with the host application. 47. A communication system configured to provide over-the-top (OTT) services, wherein the communication system is Being a host, A processing circuit configured to provide user data for a user equipment (UE), wherein the user data is associated with an over-the-top service, A network interface configured to initiate the transmission of user data to a cellular network node for transmission to a UE, wherein the network node has a communication interface and a processing circuit, and the processing circuit of the network node is configured to perform any of the operations described in any one of the embodiments of groups A to C in order to transmit user data from the host to the UE. A communication system that includes a host. 48. Network nodes, and / or UE The communication system according to embodiment 47, further comprising: 49. A host configured to operate in a communication system for providing over-the-top (OTT) services, wherein the host is A processing circuit configured to initiate the reception of user data, A network interface configured to receive user data from a network node in a cellular network, wherein the network node has a communication interface and a processing circuit, and the processing circuit of the network node is configured to perform any of the operations described in any one of the embodiments of groups A to C in order to receive user data from a user equipment (UE) on behalf of a host, and A host equipped with these features. 50. The host processing circuit is configured to run a host application that receives user data. The host application is configured to interact with a client application running on the UE, and the client application is associated with the host application. The host described in Embodiment 49. 51. A host according to Embodiment 49 or 50, wherein initiating the reception of user data includes requesting user data. 52. A method implemented by a host configured to operate in a communication system further including network nodes and user equipment (UE), the method being: Initiating reception of user data from the UE on the host, wherein the user data originates from a transmission received by the network node from the UE, and the network node initiates reception by performing one of the steps described in any one of the embodiments of groups A to C in order to receive user data from the UE for the host. Methods that include... 53. The method according to Embodiment 52, further comprising transmitting the received user data to a host at a network node.

[0148] The computing devices described herein (e.g., UEs, network nodes, hosts) may include the shown combinations of hardware components, but other embodiments may comprise computing devices with different combinations of components. It should be understood that these computing devices may comprise any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determining, calculating, acquiring, or similar operations described herein may be performed by processing circuits, which may process information by, for example, converting acquired information to other information, comparing acquired or converted information to information stored in a network node, and / or performing one or more operations based on the acquired or converted information and as a result of the processing making decisions. Furthermore, although components are illustrated as a single box located within a larger box, or as a single box nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that constitute a single shown component, and functions may be separated between the distinct components. For example, a communication interface may be configured to include any of the components described herein, and / or the functions of those components may be separated between the processing circuit and the communication interface. In another example, the non-computation-intensive functions of any of such components may be implemented in software or firmware, while the computation-intensive functions may be implemented in hardware.

[0149] In some embodiments, some or all of the functions described herein may be provided by a processing circuit that executes instructions stored in memory, which in some embodiments may be a computer program product in the form of a non-temporary computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by a processing circuit without executing instructions stored in a separate or individual device-readable storage medium, such as in a hardwired manner. In any of those particular embodiments, whether or not it executes instructions stored in a non-temporary computer-readable storage medium, the processing circuit may be configured to perform the functions described. The benefits provided by such functions are enjoyed by the processing circuit alone, or by the computing device as a whole, but not limited to other components of the computing device, and / or generally by the end user and the wireless network.

Claims

1. A method (200) implemented by a central unit-control plane (CU-CP) network node, wherein the method is Sending a message to a central unit-user plane (CU-UP) network node to identify the settings of the CU-UP network node for the Layer 1 / Layer 2 triggered mobility (LTM) cell switching procedure by a user device (UE) (202) Method (200), including the method (200).

2. Sending an instruction to the CU-UP network node that the LTM cell procedure has been executed by the UE. The method according to claim 1, further comprising:

3. The method according to claim 2, wherein the instruction is sent via E1AP signaling.

4. Receiving one or more transport network layer (TNL) addresses from the CU-UP network node that have been assigned to one or more LTM candidate target cells for the LTM cell switching procedure. The method according to any one of claims 1 to 3, further comprising:

5. The method according to claim 4, wherein the one or more TNL addresses include one TNL address.

6. The method according to claim 4, wherein the one or more TNL addresses are collectively assigned to each of the one or more LTM candidate target cells.

7. The method according to any one of claims 4 to 6, further comprising sending a mapping to the CU-CP network node instructing the allocation between the one or more TNL addresses and the one or more LTM candidate target cells.

8. The method according to any one of claims 4 to 7, wherein the one or more TNL addresses are uplink TNL addresses.

9. The above method (200) To receive the status associated with the one or more TNL addresses from the CU-UP network node. The method according to any one of claims 4 to 8, further comprising:

10. The method according to claim 9, wherein the status associated with the one or more TNL addresses indicates that the one or more TNL addresses should not be used unless specifically instructed, and / or should only be used after the UE has performed an LTM cell switching procedure on one of the one or more LTM candidate target cells.

11. Sending the one or more TNL addresses assigned to the one or more LTM candidate target cells of the DU network node to one or more distributed unit (DU) network nodes. The method according to any one of claims 4 to 10, further comprising:

12. The method according to claim 11, wherein the one or more TNL addresses are sent via the F1 interface.

13. When dependent on claim 9 or 10, Send the status associated with the one or more TNL addresses to one of the one or more DU network nodes. The method according to claim 11 or 12, further comprising:

14. An instruction is sent to the CU-UP network node to buffer data packets until the LTM cell switching procedure is executed by the UE. The method according to any one of claims 1 to 13, further comprising:

15. The method according to any one of claims 1 to 14, wherein the message identifying the configuration of the CU-UP network node includes a bearer context setup request or a bearer context modification request.

16. In response to the execution of the LTM cell switching procedure on a target cell which is one or more LTM candidate target cells for the LTM cell switching procedure, to other LTM candidate target cells, An instruction that the aforementioned one or more TNL addresses are unavailable, An indication that the LTM cell switching procedure has been executed and / or completed. An instruction that one or more TNL addresses should be deleted, One or more new TNL addresses, and The TNL address associated with the target cell Send one or more of the following The method according to any one of claims 1 to 15, further comprising:

17. A method (300) implemented by a central unit-user plane (CU-UP) network node, wherein the method is Receiving a message from the central unit-control plane (CU-CP) network node that identifies the settings of the CU-UP network node for the Layer 1 / Layer 2 trigger mobility (LTM) cell switching procedure by the user equipment (UE) (302), (304) Assigning one or more transport network layer (TNL) addresses to one or more LTM candidate target cells for the LTM cell switching procedure Method (300), including the method (300).

18. Send the aforementioned 1-term TNL address to the CU-CP network node. The method according to claim 17, further comprising:

19. The method according to claim 18, wherein the one or more TNL addresses are included in a bearer context modification response message or a bearer context setup response message.

20. The method according to any one of claims 17 to 19, wherein the one or more TNL addresses include one TNL address.

21. The method according to any one of claims 17 to 19, wherein the one or more TNL addresses are collectively assigned to each of the one or more LTM candidate target cells.

22. Sending a mapping to the CU-CP network node instructing the allocation between the one or more TNL addresses and the one or more LTM candidate target cells. The method according to any one of claims 17 to 21, further comprising:

23. The method according to any one of claims 17 to 22, wherein the one or more TNL addresses are uplink TNL addresses.

24. The method described above is To receive the status associated with the one or more TNL addresses from the CU-UP network node. The method according to any one of claims 17 to 23, further comprising:

25. The method according to claim 24, wherein the status associated with the one or more TNL addresses indicates that the one or more TNL addresses should not be used unless specifically instructed otherwise.

26. The above method (300) is, The CU-CP network node receives an instruction that an LTM cell switch has been performed to one of the one or more LTM candidate target cells. The method according to any one of claims 17 to 25, further comprising:

27. The above method (300) is, Receiving a Downlink Data Delivery Service (DDDS) frame from a Distributed Unit (DU) network node indicating that an LTM cell switch has been performed to one of the one or more LTM candidate target cells. The method according to any one of claims 17 to 25, further comprising:

28. The above method (300) To forward data packets in response to receiving the aforementioned instructions. The method according to claim 26 or 27, further comprising:

29. A method (400) carried out by a distributed unit (DU) network node, wherein the method is (402) Receiving one or more transport network layer (TNL) addresses assigned to one or more Layer 1 / Layer 2 trigger mobility (LTM) candidate target cells of the DU network node from the central unit-control plane (CU-CP) network node. Method (400), including.

30. The above method (400) To receive the status associated with the one or more TNL addresses from the CU-UP network node. The method according to claim 29, further comprising:

31. The method according to claim 29 or 30, wherein the one or more transport network layer (TNL) addresses and / or the status are included in the UE context correction request message.

32. The method according to claim 30 or 31, wherein the status associated with the one or more TNL addresses indicates that the one or more TNL addresses should not be used unless specifically instructed otherwise.

33. In response to the execution of an LTM cell switching procedure on a target cell which is one of the one or more LTM candidate target cells, the method The status of the TNL address assigned to the target cell is updated to indicate that the TNL address is in use. The method according to any one of claims 29 to 32, further comprising:

34. In response to the execution of an LTM cell switching procedure for a target cell that is not one of the one or more LTM candidate target cells, the method (400) Discarding one or more of the aforementioned TNL addresses, and Maintain or update the status associated with the one or more TNL addresses in order to indicate that the one or more TNL addresses should not be used unless specifically instructed otherwise. The method according to any one of claims 29 to 33, further comprising one or more of the above.

35. The method according to any one of claims 29 to 34, further comprising sending a downlink data delivery service (DDDS) frame to a central unit-user plane (CU-UP) network node indicating that an LTM cell switch to one of the one or more LTM candidate target cells has been performed.

36. A computer program, when executed on at least one processor, comprising instructions causing the at least one processor to perform the method according to any one of claims 1 to 35 (200, 300, 400).

37. A carrier comprising the computer program described in claim 36, wherein the carrier comprises one of an electronic signal, an optical signal, a wireless signal, or a computer-readable storage medium.

38. A computer program product comprising a non-temporary computer-readable medium storing the computer program described in claim 36.

39. A central unit-control plane (CU-CP) network node, wherein the CU-CP network node comprises a processor and memory, and the memory is configured such that the CU-CP network node Sending a message to a central unit-user plane (CU-UP) network node to identify the settings of the CU-UP network node for the Layer 1 / Layer 2 triggered mobility (LTM) cell switching procedure by a user device (UE) (202) A central unit-control plane (CU-CP) network node containing instructions executable by the processor, which are capable of performing the following actions.

40. The CU-UP network node according to claim 39, wherein the memory includes instructions executable by the processor such that the CU-UP network node can operate to perform the method (200) according to any one of claims 2 to 16.

41. A central unit-user plane (CU-UP) network node, wherein the CU-UP network node comprises a processor and memory, and the memory is configured such that the CU-UP network node Receiving a message from the central unit-control plane (CU-CP) network node that identifies the settings of the CU-UP network node for the Layer 1 / Layer 2 trigger mobility (LTM) cell switching procedure by the user equipment (UE) (302), (304) Assigning one or more transport network layer (TNL) addresses to one or more LTM candidate target cells for the LTM cell switching procedure A central unit-user plane (CU-UP) network node containing instructions executable by the processor, which are capable of performing the following actions.

42. The CU-UP network node according to claim 41, wherein the memory includes instructions executable by the processor such that the CU-UP network node can operate to carry out the method (300) according to any one of claims 18 to 28.

43. A distributed unit (DU) network node, wherein the DU network node comprises a processor and memory, and the memory is provided by the DU network node, (402) Receiving one or more transport network layer (TNL) addresses assigned to one or more Layer 1 / Layer 2 trigger mobility (LTM) candidate target cells of the DU network node from the central unit-control plane (CU-CP) network node. A distributed unit (DU) network node containing instructions executable by the processor, which enable it to perform the following actions.

44. The DU network node according to claim 43, wherein the memory includes instructions executable by the processor such that the DU network node can operate to carry out the method (400) described in any one of claims 30 to 35.

45. A central unit-control plane (CU-CP) network node, Sending a message to a central unit-user plane (CU-UP) network node to identify the settings of the CU-UP network node for the Layer 1 / Layer 2 triggered mobility (LTM) cell switching procedure by a user device (UE) (202) A central unit-control plane (CU-CP) network node configured to perform this function.

46. The CU-CP network node according to claim 45, wherein the CU-CP network node is configured to carry out the method (200) described in any one of claims 2 to 16.

47. A central unit-user plane (CU-UP) network node, Receiving a message from the central unit-control plane (CU-CP) network node that identifies the settings of the CU-UP network node for the Layer 1 / Layer 2 trigger mobility (LTM) cell switching procedure by the user equipment (UE) (302), (304) Assigning one or more transport network layer (TNL) addresses to one or more LTM candidate target cells for the LTM cell switching procedure A central unit-user plane (CU-UP) network node configured to perform this task.

48. The CU-UP network node according to claim 47, wherein the CU-UP network node is configured to carry out the method (300) described in any one of claims 18 to 28.

49. A distributed unit (DU) network node, (402) Receiving one or more transport network layer (TNL) addresses assigned to one or more Layer 1 / Layer 2 trigger mobility (LTM) candidate target cells of the DU network node from the central unit-control plane (CU-CP) network node. A distributed unit (DU) network node configured to perform the above, with one or more LTM candidate target cells set on the user equipment (UE).

50. The DU network node according to claim 49, wherein the DU network node is configured to carry out the method (400) described in any one of claims 30 to 35.

Images