WO2023158396A1

WO2023158396A1 - Handling of multiple user equipment software versions in connected mobility

Info

Publication number: WO2023158396A1
Application number: PCT/TR2022/050154
Authority: WO
Inventors: Mehdi ABAD; Gunnar Mildh; Massimo CONDOLUCI; Icaro Leonardo DA SILVA
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2022-02-21
Filing date: 2022-02-21
Publication date: 2023-08-24

Abstract

A method (300) by a wireless device (112A) includes receiving (302) a mobility command indicating that the wireless device is to move from a source cell to a target cell and receiving (304) one or more indications related to usage of at least one software, SW, version associated with the target cell. The wireless device applies (306) the mobility command and performs at least one action according to the one or more indications related to the usage of the at least one SW version associated with the target cell.

Description

HANDLING OF MULTIPLE USER EQUIPMENT SOFTWARE VERSIONS IN

CONNECTED MOBILITY

TECHNICAL FIELD

The present disclosure relates, in general, to wireless communications and, more particularly, systems and methods for handling of multiple user equipment software versions in connected mobility.

BACKGROUND

In Third Generation Partnership Project (3GPP) systems, such as 5^th Generation (5G) New Radio (NR) and Long Term Evolution (LTE), there are various protocols that for a protocol stack for communication between a User Equipment (UE) and the Radio Access Network (RAN). They are divided into Control Plane (CP) for signaling and User Plane (UP) for data. FIGURE 1 illustrates the protocol stack for the user plane as including Service Data Adaption Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), and Medium Access Control (MAC) sublayers (terminated in a network node such as, for example, a gNodeB (gNB) on the network side).

FIGURE 2 illustrates the protocol stack for the control plane, as including:

PDCP, RLC and MAC sublayers (terminated in gNB on the network side);

Radio Resource Control (RRC) (terminated in gNB on the network side);

- Non-Access Stratum (NAS) control protocol (terminated in Applications Management Function (AMF) on the network side) performs the functions listed in 3GPP TS 23.501) such as, for instance, authentication, mobility management, security control.

The functions executed by these protocols are specified in 3GPP specifications. The main control plane protocol, RRC, for example, is specified in 3GPP TS 38.331 and comprise the following protocol functions to be implemented at the UE side:

Broadcast of System Information related to Access Stratum (AS) and NAS;

Paging initiated by 5^th Generation Core Network (5GC) or Next Generation-Radio Access Network (NG-RAN);

Establishment, maintenance and release of an RRC connection between the UE and NG-RAN including: - Addition, modification and release of carrier aggregation;

- Addition, modification and release of Dual Connectivity (DC) in NR or between Evolved Universal Terrestrial Radio Access (E-UTRA) and NR.

Security functions including key management;

Establishment, configuration, maintenance and release of Signalling Radio Bearers (SRBs) and Data Radio Bearers (DRBs);

Mobility functions including:

Handover and context transfer;

- UE cell selection and reselection and control of cell selection and reselection; Inter-Radio Access Technology (Inter-RAT) mobility.

Quality of Service (QoS) management functions;

- UE measurement reporting and control of the reporting; Detection of and recovery from radio link failure;

- NAS message transfer to/from NAS from/to UE.

The sidelink specific services and functions of the RRC sublayer over the Uu interface include:

Configuration of sidelink resource allocation via system information or dedicated signalling;

Reporting of UE sidelink information;

Measurement configuration and reporting related to sidelink;

Reporting of UE assistance information for SL traffic pattem(s).

Once these functions are specified, UE (chipset) manufacturers can implement them according to these specifications so that a network manufacturer can implement the counter-part of these functions taking into account what has been specified. However, whatever UE behavior the network manufacturer can expect when programming its software is limited to what has been specified. For example, a network vendor can design a handover algorithm based on A 1 -A6 events, under a certain configuration, and process measurement reports to take handover decision. But the introduction of a new event, new trigger, and/or new report associated, would require standardization.

Despite the success of the mobile telecom industry, driven by a global standardization forum like 3GPP, the innovation cycle is somewhat slower than in the Information Technology (IT) industry. The recent initiatives in the area of Software Define Network (SDN) opened up for new ideas introduced in the 5G Core Network, such as separation between CP and UP functions, and the opening of Application Programming Interfaces (APIs) that could be used by a third part so that control functions could be programmed. In addition to it, virtualization and cloud technologies have been used to program these API(s) on the network side.

In the RANs domain, initiatives in the area of RAN programmability have also started to pop up in the past few years. However, they have been limited to initiatives to open API(s) on the network side, so that a third part vendor (not the same vendor manufacturing that network equipment with the open API(s)) could use these API(s) to program algorithms.

The benefits of such initiates are limited to whatever terminals / User Equipment’s would support in a given version of the 3GPP specifications. In other words, while a programmer benefiting from these possibly opened API(s) could in theory design a new scheduling algorithm, he or she cannot influence the type of information a terminal report, or some specific behavior the program intends the UE to perform upon receiving a given command: these would still have to be introduced via standardization.

Additionally, even if UE behavior is updated in the standards, network vendors must support legacy behavior for a long period. This makes both standardization cautious and also network design more and more complex as the given generation of mobile network evolves.

SUMMARY

Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. For example, methods and systems are provided for handling of multiple user equipment software versions in connected mobility.

According to certain embodiments, a method by a wireless device includes receiving a mobility command indicating that the wireless device is to move from a source cell to a target cell. The wireless devices receives one or more indications related to usage of at least one SW version associated with the target cell. The wireless device applies the mobility command and performs at least one action according to the one or more indications related to the usage of the at least one SW version associated with the target cell.

According to certain embodiments, a wireless device is adapted to receive a mobility command indicating that the wireless device is to move from a source cell to a target cell. The wireless devices is adapted to receive one or more indications related to usage of at least one SW version associated with the target cell. The wireless device is adapted to apply the mobility command and perform at least one action according to the one or more indications related to the usage of the at least one SW version associated with the target cell.

According to certain embodiments, a method by a target network node associated with a target cell during a handover of a wireless device from a source network node associated with a source cell to the target network node associated with the target cell. The method includes receiving, from the source network node, a handover request message requesting handover of the wireless device to the target network node. The target network node transmits, to the source network node, a handover request acknowledgement. The target network node transmits, to the source network node, one or more indications related to usage of at least one SW version associated with the target cell and/or one or more software versions for use by the wireless device in the target cell.

According to certain embodiments, a target network node is associated with a target cell during a handover of a wireless device from a source network node associated with a source cell to the target network node. The target network node is adapted to receive, from the source network node, a handover request message requesting handover of the wireless device to the target network node. The target network node is adapted to transmit, to the source network node, a handover request acknowledgement. The target network node is also adapted to transmit, to the source network node, one or more indications related to usage of at least one SW version associated with the target cell and/or one or more software versions for use by the wireless device in the target cell.

According to certain embodiments, a method by a source network node associated with a source cell during a handover of a wireless device to target network node associated with a target cell is provided. The method includes transmitting, to the target network node, a handover request message requesting handover of the wireless device to the target network node. The source network node receives, from the target network node, a handover request acknowledgement. The source network node also receives from the target network node one or more indications related to usage of at least one SW version associated with the target cell and/or one or more software versions for use by the wireless device in the target cell. The source network node transmits, to the wireless device, a mobility command and the one or more indications related to the usage of the at least one SW version associated with the target cell.

According to certain embodiments, a source network node is associated with a source cell during a handover of a wireless device to target network node associated with a target cell. The source network node is adapted to transmit, to the target network node, a handover request message requesting handover of the wireless device to the target network node. The source network node is adapted to receive, from the target network node, a handover request acknowledgement. The source network node is also adapted to receive from the target network node one or more indications related to usage of at least one SW version associated with the target cell and/or one or more software versions for use by the wireless device in the target cell. The source network node is adapted to transmit, to the wireless device, a mobility command and the one or more indications related to the usage of the at least one SW version associated with the target cell.

Certain embodiments may provide one or more of the following technical advantage(s). For example, certain embodiments may provide a technical advantage of supporting network- controlled mobility for a wireless terminal in a connected state/mode (e.g., RRC_CONNECTED) with the source and target network nodes possibly determining to configure the UE with different SW versions and/or activate/deactivate and/or run different SW versions. Thus, it is may be possible for a target network node for an incoming UE, in a mobility procedure, to release, add, modify, activate, deactivate a SW version at the UE before the UE accesses the target node(e.g., S W version added by target node may even modify the way the UE accesses the target, if modifies random access and/or the handling of the RRC Reconfiguration Complete message).

As another example, certain embodiments may provide a technical advantage of enabling different network vendors and/or manufactures to possibly run different SW versions even if for the same SW functionality, in some circumstances. Likewise, certain embodiments provide a technical advantage of enabling a single network vendor to have multiple network nodes that support mobility bit with different upgrading/migration planning.

Other advantages may be readily apparent to one having skill in the art. Certain embodiments may have none, some, or all of the recited advantages.

BRIEF DESCRIPTION OF The DRAWINGS

For a more complete understanding of the disclosed embodiments and their features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:

FIGURE 1 illustrates the protocol stack for the user plane;

FIGURE 2 illustrates the protocol stack for the control plane;

FIGURE 3 illustrates an example scenario where a UE moves from a first network node to a second network node operating with different SW versions;

FIGURE 4 illustrates various different interpretations of a protocol stack SW version, according to certain embodiments;

FIGURE 5 illustrates example signaling for adding a SW version and releasing a SW function during handover, according to certain embodiments;

FIGURE 6 illustrates example signaling for activating a SW version and deactivating a SW version during handover, according to certain embodiments; FIGURE 7 illustrates a method at or by a wireless device, which may include a UE, according to certain embodiments;

FIGURE 8 illustrates a method at or by a target network node, according to certain embodiments;

FIGURE 9 illustrates an example method at or by a source network node, according to certain embodiments;

FIGURE 10 example signaling when there is no direct Xn interface between the source network node and the target network node, according to certain embodiments;

FIGURE 11 illustrates example signaling for requesting, by the source network node, information related to the usage of at least one SW version associated with the target network node, according to certain embodiments;

FIGURE 12 example signaling enabling a source network node to identify multiple candidate cells belonging to one or more candidate target network nodes for a potential future handover of a, according to certain embodiments;

FIGURE 13 illustrates an example communication system, according to certain embodiments;

FIGURE 14 illustrates an example UE, according to certain embodiments;

FIGURE 15 illustrates an example network node, according to certain embodiments;

FIGURE 16 illustrates a block diagram of a host, according to certain embodiments;

FIGURE 17 illustrates a virtualization environment in which functions implemented by some embodiments may be virtualized, according to certain embodiments; and

FIGURE 18 illustrates a host communicating via a network node with a UE over a partially wireless connection, according to certain embodiments.

DETAILED DESCRIPTION

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

As used herein, ‘node’ can be a network node or a UE. Examples of network nodes are NodeB, base station (BS), multi-standard radio (MSR) radio node such as MSR BS, eNodeB (eNB), gNodeB (gNB), Master eNB (MeNB), Secondary eNB (SeNB), integrated access backhaul (IAB) node, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), Central Unit (e.g., in a gNB), Distributed Unit (e.g., in a gNB), Baseband Unit, Centralized Baseband, C-RAN, access point (AP), transmission points, transmission nodes, Remote Radio Unit (RRU), Remote Radio Head (RRH), nodes in distributed antenna system (DAS), core network node (e.g., Mobile Switching Center (MSC), Mobility Management Entity (MME), etc.), Operations & Maintenance (O&M), Operations Support System (OSS), Self Organizing Network (SON), positioning node (e.g., E- SMLC), etc.

Another example of a node is user equipment (UE), which is a non-limiting term and refers to any type of wireless device communicating with a network node and/or with another UE in a cellular or mobile communication system. Examples of UE are target device, device to device (D2D) UE, vehicular to vehicular (V2V), machine type UE, MTC UE or UE capable of machine to machine (M2M) communication, Personal Digital Assistant (PDA), Tablet, mobile terminals, smart phone, laptop embedded equipment (LEE), laptop mounted equipment (LME), Unified Serial Bus (USB) dongles, etc.

In some embodiments, generic terminology, “radio network node” or simply “network node (NW node)”, is used. It can be any kind of network node which may comprise base station, radio base station, base transceiver station, base station controller, network controller, evolved Node B (eNB), Node B, gNodeB (gNB), relay node, access point, radio access point, Remote Radio Unit (RRU) Remote Radio Head (RRH), Central Unit (e.g., in a gNB), Distributed Unit (e.g., in a gNB), Baseband Unit, Centralized Baseband, C-RAN, access point (AP), etc.

The term radio access technology (RAT), may refer to any RAT such as, for example, Universal Terrestrial Radio Access Network (UTRA), Evolved Universal Terrestrial Radio Access Network (E-UTRA), narrow band internet of things (NB-IoT), WiFi, Bluetooth, next generation RAT, NR, 4G, 5G, 6G, etc. Any of the equipment denoted by the terms node, network node or radio network node may be capable of supporting a single or multiple RATs. The term protocol stack may refer to a set of one or more protocol(s) and/or protocol function(s) at an entity in a mobile network, such as a wireless terminal (also called a UE) and/or a network node (like a gNodeB, eNodeB, CU-eNodeB, DU-eNodeB, AMF, SMF, MME, etc.). This may refer to a 5G evolution system or a 6G system. To give example, a protocol stack at the UE may comprise the protocols Non-Access Stratum (NAS) for communication with the Access and Mobility Function (AMF) at the 5G Core Network, and the Radio Resource Control (RRC), PDCP, Radio Link Control (RLC), Medium Access Control (MAC), Physical layer (PHY) protocols for communication with the Radio Access Network (RAN), e.g., the gNodeB (gNB). The protocol stack can be classified as User Plane (related to functions for user plane data transmission/ reception) and Control Plane (related to functions for control).

The term protocol function (which may also be called protocol service) may correspond to a function and/or service of a protocol layer of a protocol stack. For example, when a protocol of the air interface is specified, its functions are specified. Certain functions described in 3 GPP TS 38.331 are described above. As additional examples, the protocol functions for the MAC protocol, or MAC functions (as defined in the MAC specifications TS 38.321 for 5G and 5G advanced) include:

• Mapping between logical channels and transport channels;

• Multiplexing/demultiplexing of MAC Service data Units (SDUs) belonging to one or different logical channels into/from transport blocks (TB) delivered to/from the physical layer on transport channels;

• Scheduling information reporting;

• Error correction through HARQ (one HARQ entity per cell in case of CA);

• Priority handling between UEs by means of dynamic scheduling;

• Priority handling between logical channels of one UE by means of logical channel prioritisation;

• Padding.

The protocol functions for the RLC protocol, or RLC functions (as defined in the RLC specifications 3GPP TS 38.322 for 5G and 5G advanced) include:

• Transfer of upper layer Protocol Data Units (PDUs);

• Sequence numbering independent of the one in PDCP (Unacknowledged Mode (UM) and Acknowledged Mode (AM));

• Error Correction through ARQ (AM only);

• Segmentation (AM and UM) and re-segmentation (AM only) of RLC SDUs;

• Reassembly of SDU (AM and UM); Duplicate Detection (AM only);

RLC SDU discard (AM and UM);

RLC re-establishment;

• Protocol error detection (AM only).

As still further examples, the protocol functions for the PDCP protocol, or PDCP functions (as defined in the PDCP specifications 3GPP TS 38.323 for 5G and 5G advanced) include:

• Transfer of data (user plane or control plane);

• Maintenance of PDCP SNs;

• Header compression and decompression using the ROHC protocol;

• Ciphering and deciphering;

• Integrity protection and integrity verification;

• Timer based SDU discard;

• For split bearers, routing;

• Duplication;

• Reordering and in-order delivery;

• Out-of-order delivery;

• Duplicate discarding.

The protocol function comprises the actions an entity (e.g., a UE) performs associated to that function e.g., the RRC function “Broadcast of System Information related to AS and NAS” comprises the UE actions such as acquiring a system information message (e.g., SIB1) and obtaining in a cell the cell and tracking areas identifiers and providing it to the higher layers.

The term protocol stack Software (SW) may correspond to a data file comprising a SW (possibly running/ executed and/or stored at the UE) that when executed enable the entity where the SW is executed to run at least one protocol function. S W versioning is a way to categorize the unique states of SW as it is developed and released and one may call that a S W version. There may be a SW version identifier which can be a word, or a number, or both. Below we show some examples of how SW functions, protocol stack SW and protocol stacks may be referred in the invention.

According to 3GPP TS 38.300 v. 16. 8.0, the intra-NR RAN handover performs the preparation and execution phase of the handover procedure performed without involvement of the 5GC. For example, preparation messages are directly exchanged between the gNBs. The release of the resources at the source gNB during the handover completion phase is triggered by the target gNB. As disclosed in 3GPP TS 38.300, the signaling flow includes the following steps: 0. The UE context within the source gNB contains information regarding roaming and access restrictions which were provided either at connection establishment or at the last TA update.

1. The source gNB configures the UE measurement procedures and the UE reports according to the measurement configuration.

2. The source gNB decides to handover the UE, based on MeasurementReport and Radio Resource Management (RRM) information.

3. The source gNB issues a Handover Request message to the target gNB passing a transparent RRC container with necessary information to prepare the handover at the target side.

4. Admission Control may be performed by the target gNB.

5. The target gNB prepares the handover with Layer 1 (Ll)/Layer 2 (L2) and sends the HANDOVER REQUEST ACKNOWLEDGE to the source gNB, which includes a transparent container to be sent to the UE as an RRC message to perform the handover.

6. The source gNB triggers the Uu handover by sending an RRCReconflguration message to the UE, containing the information required to access the target cell: at least the target cell ID, the new Cell-Radio Network Temporary Identifier (C- RNTI), the target gNB security algorithm identifiers for the selected security algorithms.

[... ]

8. The UE synchronises to the target cell and completes the RRC handover procedure by sending RRCReconflgurationComplete message to target gNB.

[... ]

9. The target gNB sends a PATH SWITCH REQUEST message to Application Management Function (AMF) to trigger 5GC to switch the downlink (DL) data path towards the target gNB and to establish an NG-C interface instance towards the target gNB.

10. 5GC switches the DL data path towards the target gNB. The User Plane Function (UPF) sends one or more "end marker" packets on the old path to the source gNB per Protocol Data Unit (PDU) session/tunnel and then can release any U- plane/Transport Network Layer resources towards the source gNB.

11. The AMF confirms the PATH SWITCH REQUEST message with the PATH SWITCH REQUEST ACKNOWLEDGE message. 12. Upon reception of the PATH SWITCH REQUEST ACKNOWLEDGE message from the AMF, the target gNB sends the UE CONTEXT RELEASE to inform the source gNB about the success of the handover. The source gNB can then release radio and C-plane related resources associated to the UE context. Any ongoing data forwarding may continue.

A UE programmability framework has been proposed, and to some extent, is currently being discussed in the 6G European project Hexa-X. According to the UE programmability framework, the UE stores and manages (e.g., adding, removing, activating, deactivating, updating, verifying, maintaining, etc.) multiple protocol stack software (SW) versions. These SW versions are either stored at the UE/chipset from factory (at a chipset level when the chipset is initially setup such as, for example, before leaving the factory (or other vendor premises)) or stored at a SIM card that may be placed at the UE. Alternatively, the SW versions can be downloaded by the UE from a server.

The UE may then select at least one of the multiple stored SW versions and perform a set of initialization actions. As used herein, the term SW version can be interpreted as a short name corresponding to the protocol stack software version. It can also include SW parts or configurations that are closely related to hardware (HW) and that are sometimes referred to as firmware (FW).

Similarly, on the network side, a network node may receive an indication from the UE that the UE has stored multiple protocol stack SW versions. The network node may select at least one of the multiple stored versions and perform a set of initialization actions.

One of the advantages of such a framework for UE programmability is that it would enable more flexibility in the design of mobile network protocols (or protocol functions) over the air interface such as, for example, asynchronous functions like RRC functions. However, one of the problems to realize a UE programmability framework for a 3 GPP protocol stack (or equivalent, like any protocol stack having protocols over an air interface for communication between a network node and a wireless terminal) in a typical commercial network deployment is the fact that mobility in connected state shall be supported, in order to allow some level of service continuity. In other words, the UE shall be able to move across the network while in connected state (e.g., RRC_CONNECTED as defined in 3GPP TS 38.331, between cells and beams) and have some level of service continuity.

According to these previous techniques, each SW version may be designed based on a programmability framework where the UE reports its available API(s) and the SW version is able to call them. Then, the UE having these SW versions stored may receive commands from the network indicating the UE to remove one or more SW versions and/or modify one or more SW versions and/or activate one or more SW versions and/or deactivate one or more SW versions. One or multiple versions of protocol stack SW can be stored at a UE. This enables the UE to run different SW version at different time instances depending on network demands such as, for example depending on load distribution, Operation and Maintenance configuration, which network / PLMN the UE tries to attach, etc. However, it is currently impossible to ensure that the right stack is used by both the network and the UE. As such, it is impossible to avoid possible error cases associated with using different SW versions, how to synchronize the network and the UE so one makes sure that both sides run the same (or compliant) software (SW or Firmware FW) version of a given protocol stack and/or specific SW function of a given protocol stack, such as an RRC function (e.g., for measurement reporting or reconfiguration). This is particularly true when the UE moves between network nodes (such as gNBs) and while the UE is in Connected mode, i.e., during handovers between gNB(s) and/or PSCell changes also referred as connected mobility.

These problems have not been fully addressed because a significant level of service continuity needs to be maintained while the UE moves (i.e. while the UE stops the connection with the source network node and establishes the connection with the target network node). Additionally, a target network node may be from a different manufacturer compared to the source network node. Consequently, the target network node may not support the UE programmability framework. Or, if a target network node supports a UE programmability framework, the target network node may not have the same SW version(s) the UE has stored in the UE memory. For example, FIGURE 3 illustrates an example scenario where a UE moves from a first network node (gNB-A) to a second network node (gNB-B). Whereas the first network node performs Software function X according to SW version (1) and SW version (2), the second network node performs the same Software function X according to version (3) and SW version (4).

Another problem exists in the way the UE manages the SW version(s). For example, certain previous methods and techniques include the network adding one or multiple SW version(s) to the UE. Specifically, the UE may receive one or multiple SW version(s) from the network (e.g., in a message). However, the UE is not given any information about the relation between the SW associated to a source network node and a SW version associated to a target network node. Additionally, the UE does not know the timing that these versions need to be executed/ activated as they relate and/or depend on the mobility actions (e.g., handover from source to target).

FIGURE 4 illustrates various different interpretations of a protocol stack SW version, which may be referred to simply as a SW version. Specifically, in a first example depicted in FIGURE 4, a protocol stack SW version (or simply SW version) refers to the whole protocol stack for a given interface such as, for example, Protocol stack for an NR air interface including RRC, PDCP, MAC, RLC, LI/ physical layer. In that case, the UE could have multiple versions such as, for example, one or more per RAT (e.g., one SW version for LTE and another for NR). Each of them could be independently added, modified, activated, replaced, etc.

In a second example depicted in FIGURE 4, a protocol stack SW version (or simply SW version) refers to one specific protocol in a protocol stack, such as the Radio Resource Control (RRC) protocol, or Non-Access Stratum (NAS) protocol.

In a third example depicted in FIGURE 4, a protocol stack SW version (or simply SW version) refers to one specific function within a protocol in a protocol stack (e.g., SW function X), such as a specific RRC protocol function, like measurement configuration and reporting, RRM measurements, reconfiguration, failure recovery, etc. In the case there is a SW version per SW function, the terms can be used interchangeably, but certain embodiments described herein also cover the case wherein the UE may have for a given SW function (e.g., for fast failure recovery) multiple SW versions, and at least one SW version is to be activated at time.

In a fourth example depicted in FIGURE 4, a protocol stack SW version (or simply SW version) refers to one specific atomic functionality (e.g., a content to be included in a message to be transmitted upon a given event) within a protocol in a protocol stack, such as a specific RRC protocol function, measurement configuration and reporting. The functionality is the inclusion of information (e.g., movement sensor) in a measurement report when triggered by event A3.

In a fifth example (not explicitly depicted), a protocol stack SW version (or simply SW version) refers to a specific protocol state e.g., RRC IDLE, RRD CONNECTED within a protocol in a protocol stack, such as RRC protocol.

As used herein, a SIM card corresponds to a subscriber identity module or subscriber identification module (SIM), which is an integrated circuit that is intended to securely store the international mobile subscriber identity (IMSI) number and its related key, which are used to identify and authenticate subscribers on mobile telephony devices (such as mobile phones and computers). It is also possible to store contact information on many SIM cards. The SIM circuit is part of the function of a universal integrated circuit card (UICC) physical smart card, which is usually made of PVC with embedded contacts and semiconductors.

As used herein, one or more SW versions can also be called a set of SW versions. In particular, that can be used when referring to a common property e.g., a first set of SW versions stored at the SIM card, a second set of SW versions stored at UE but received via a network message, a third set of SW versions stored at UE chipset, etc. That may also refer to a set of SW versions associate to a given protocol e.g., a first set of SW versions associated to RRC protocol, a second set of SW versions stored at UE but received via a network message, a third set of SW versions stored at UE chipset, etc.

According to previous systems and methods, each SW version was designed based on a programmability framework where the UE reports its available API(s) and the SW version is able to call them. Then, the UE having these SW versions stored may receive commands from the network indicating the UE to remove one or more SW versions and/or modify one or more SW versions and/or activate one or more SW versions and/or deactivate one or more SW versions.One or multiple versions of protocol stack SW can be stored at a UE. This enables the UE to run different SW version at different time instances depending on network demands such as, for example depending on load distribution, Operation and Maintenance configuration, which network / PLMN the UE tries to attach, etc. However, it is currently impossible to ensure that the right stack is used by both the network and the UE. As such, previous systems and techniques make it impossible to avoid possible error cases associated with using different SW versions. Previous systems and techniques also do not provide synchronization between the network and the UE so that both sides run the same (or compliant) software (SW or Firmware FW) version of a given protocol stack and/or specific SW function of a given protocol stack, such as an RRC function (e.g., for measurement reporting or reconfiguration).

Furthermore, previous techniques for handling SW versions do not account for different SW versions and/or functions when a UE moves between different network nodes (such as gNBs) that utilize different SW versions. For example, it may be especially challenging while the UE is in Connected mode during handovers between gNB(s) and/or during PSCell changes.

According to certain embodiments, for example, a method at a wireless terminal (which may include a UE) operating in a connected mode such as, for example, RRC_CONNECTED as defined in 3GPP TS 38.331, includes receiving a mobility command to move from one source cell (of a source network node e.g., gNB) to a target cell (of a target network node e.g., gNB). The mobility command includes one or more indication(s) for a management of SW versions to be used in the target cell (after the move from source cell to the target cell). As used herein, the management of SW versions may include one or more of: an addition of a SW version and/or a release of a SW version; a modification of a SW version; a selection of a SW version; and/or an activation/ deactivation of a stored/ received SW function. The UE, upon receiving the mobility command applies the mobility command and performs the actions according to the one or more indication(s) for the management of SW versions to be used in the target cell such as the addition of a SW version and/or the release of a SW version and/or the modification of a SW version and/or the selection of a SW version and/or the activation/ deactivation of a stored/ received SW function. According to certain embodiments, a method at a source network node serving a UE in a connected mode such as, for example, RRC CONNECTED as defined in 3GPP TS 38.331, includes transmitting, by the source network node, a mobility command to move the UE from one source cell (of a source gNB) to a target cell (target gNB). The mobility command includes one or more indication(s) for the management of SW versions to be used in the target cell (after the move from source cell to the target cell). For example, the indications may include an addition of a SW version, a release of a SW version, a modification of a SW version, the selection of a SW version, and/or the activation/ deactivation of a stored/ received SW function. The method further includes the source network node transmitting to a target network node a request message (e.g., Handover Request message) including information on the current SW version(s) the UE has stored and/or which SW versions the UE has activated/ deactivated (i.e. which version the UE is running for a certain SW function) and, receiving in response from the target network node (e.g., in a Handover Request Ack message) one or more indication(s) for the management of SW versions to be used in the target cell by the UE (after the move from source cell to the target cell), such as an addition of a SW version, a release of a SW version and/or a modification of a SW version and/or an activation of a SW version and/or a deactivation of a SW version and/or a selection command for selecting a SW version.

According to certain embodiments, a method at a target network node serving a UE in a connected mode such as, for example, RRC CONNECTED as defined in 3GPP TS 38.331, includes generating, by the target network node, a mobility command, which includes one or more indication(s) for the management of SW versions to be used in the target cell (after the move from source cell to the target cell), such as an addition of a SW version and/or a release of a SW version and/or a modification of a SW version and/or the selection of a SW version and/or the activation/ deactivation of a stored/ received SW function. The method further includes receiving, by the target network node, from a source network node, a request message (e.g., Handover Request message) including information on the current SW version(s) the UE has stored and/or which SW versions the UE has activated/ deactivated (i.e. which version the UE is running for a certain SW function) and transmitting, in response from the target network node (e.g., in a Handover Request Ack message), one or more indication(s) for the management of SW versions to be used in the target cell by the UE (after the move from source cell to the target cell), such as an addition of a SW version, a release of a SW version and/or a modification of a SW version and/or an activation of a SW version and/or a deactivation of a SW version and/or a selection command for selecting a SW version. Accordingly, certain embodiments described herein may address problems of previous methods and techniques that require a long 3GPP process that includes various discussions prior to the drafting of protocol specification upon the introduction of new protocol function(s) in the air interface. For example, certain embodiments may allow for standardizing of basic API(s) instead of standardizing protocol functions. Thus, an API can be associated to SW routines that can be common to various functions. For example, an API can be associated to a SW routine to perform a certain type of measurements that could be useful for various functions such as mobility, dual connectivity management, carrier aggregation, etc.

Thanks to these API(s), certain embodiments described herein may enable an entity at the network side (e.g., a programmer at the network vendor side and/or at operator’s premise’s) to generate SW protocol functions (and/or SW versions of these SW functions). As such, another level of network vendor differentiation may be reached and it may be possible to achieve interoperability between network nodes from different manufacturers. Whereas, previous techniques and systems required network vendors to rely on the same version of the specifications, certain embodiments described herein allow network vendors to differentiate themselves in terms of functions by implementing a number of optional features in the specifications and/or by implementing different algorithms, though relying on the same protocol functions. For example, two vendors can rely on same measurement reporting framework / measurement configuration (e.g., events A3, A5, etc.), and upon reception determine to perform a handover or not, then sending an RRC Reconfiguration to the UE. However, each vendor defines the logic determining to perform the handover or not, giving some level of differentiation.

Different infrastructure vendors using same version of standard specifications can differentiate themselves by using different set of optional features;

Different infrastructure vendors using same version of standard specifications can differentiate themselves by having different implementation of network algorithms (though using same protocol functions defined in the specs as other vendors);

Same goes for the operator utilizing the vendor’s equipment.

Thanks to UE programmability the network infrastructure vendor, the operator and/or a third part agent can in principle utilize protocol API(s) exposed by UE(s) to design different SW- based protocol functions (such as, for example, a new report within an existing message from the UE to the network, a new message triggered by an action also defined by an API, a new behavior upon the occurrence of a given event, etc.), making it work as the UE moves across the network. That would enable a higher level of differentiation among different operators, as if they would be using different versions of 3GPP specifications (to some extent) and, at the same time, allow the UE to move within the network and activate/ deactivate, add/ remove/ modify stored SW versions of a given SW function.

It could be argued that network vendors and UE vendors could reach an agreement to define functions outside the 3GPP scope. However, to reach the same level envisioned by a UE programmability framework with standardize API(s) each network vendor would need to talk to each UE vendor, and try to agree on the functions, basically making something like the 3 GPP process, but less efficient. Instead, a UE programmability framework where API(s) are standardized would lead to different UE (chipset) manufacturers implementing same API(s), giving some level of harmonization for the programmer that could create a SW version that runs in various and/or all UEs (at least for mandatory API(s)).

Additionally, certain embodiments described herein enable a UE to store one or multiple versions of protocol stack SW. As a result, the UE may be able to move to different networks or network areas and utilize different SW stacks in these areas without requiring the SW stack to be re-downloaded. Accordingly, certain embodiments may provide a technical advantage of significantly reducing latency when the UE moves between areas or networks using different SW stacks. Further, it may be possible to ensure that the right stack is used both in the network and in the UE avoid possible error cases associated with using different SW versions.

FIGURE 5 illustrates example signaling 100 for adding a SW version and releasing a SW function during handover, according to certain embodiments. As depicted, a source network node 110A stores SW version (1) and SW version (2) for performing SW function X. A UE 112A also stores SW version (1) and SW version (2) for performing SW function X. Though a UE 112A is specifically shown in FIGURE 5, it is recognized that UE 112A is used herein to refer to any type of wireless device.

At step 1, the source network node 110A sends a Handover Request to the target network node HOB. The Handover Request message includes information on SW function X and the UE’s stored SW versions (i.e., SW version (1) and (2)).

At step 2, the target network node HOB determines to add SW version (3) and release SW version (2). At step 3, the target network node 110B transmits a Handover Request Acknowledgment (ACK), which includes an indication that SW version (3) is to be added and an indication that SW version (2) is to be released.

At step 4, the source network node 110A sends a Mobility Command to the UE 112A. The Mobility Command includes an indication that SW version (3) is to be added and an indication that SW version (2) is to be released. The UE 112A then adds SW version (3) and releases SW version (2). At step 5, a Random Access procedure is performed between the UE 112A and the target network node HOB. Thereafter, the UE 112A transmits a Mobility Command Acknowledgement to the target network node 110B, at step 6.

FIGURE 6 illustrates example signaling 200 for activating a SW version and deactivating a SW version during handover, according to certain embodiments. Components depicted in FIGURE 6 that are similar to those described above have been depicted with similar reference numerals.

According to the example of FIGURE 6, a source network node 110A stores activated SW version (1) and deactivated SW version (2) for performing SW function X. UE 112A also stores an activated SW version (1) and a deactivated SW version (2) for performing SW function X. At step 1, the source network node 110A sends a Handover Request to the target network node 110B. The Handover Request message includes information on SW function X and which SW versions are activated (SW version (1)) and deactivated (SW version (2)).

At step 2, the target network node HOB determines to activate SW version (2) and deactivate SW version (1). At step 3, the target network node HOB transmits a Handover Request Acknowledgment (ACK), which includes an indication that SW version (2) is to be activated and an indication that SW version (1) is to be deactivated.

At step 4, the source network node 110A sends a Mobility Command to the UE 112A. The Mobility Command includes an indication that SW version (2) is to be activated and an indication that SW version (1) is to be deactivated. The UE 112A then deactivates SW version (1) and activates SW version (2).

At step 5, a Random Access procedure is performed between the UE 112A and the target network node 110B. Thereafter, the UE 112A transmits a Mobility Command Acknowledgement to the target network node 110B, at step 6.

FIGURE 7 illustrates a method 300 at or by a wireless device 112A, which may include a UE, according to certain embodiments. The method begins at step 302 when the wireless device 112A receives a mobility command indicating the wireless device 112A is to move from a source cell to a target cell. At step 304, the wireless device 112A receives one or more indications related to usage of at least one SW version associated with the target cell. At step 306, the wireless device 112A applies the mobility command and performs at least one action according to the one or more indications related to the usage of the at least one SW version associated with the target cell.

It may be noted that SW version(s) and/or indication of SW versions and/or indication(s) of activation/deactivation in the mobility command corresponds to one of the features described herein. Whereas the Mobility Command disclosed and used in existing 3GPP signaling contains only configuration(s), the new Mobility Command includes the indications of SW versions and/or SW functions described herein. Including this information in the Mobility Command and other messages allows different network node(s) (e.g., source and target gNodeBs), to run different SW version(s), even if this is for a similar functionality. The indications and information also provide service continuity to a UE in connected mode so that the UE can run a SW version when connected to a source network node and another SW version after being handed over to a target network node. This also enables different manufacturers to use different SW versions (or decide which SWS version to activate/ deactivate) in its own network node, i.e., without the need of a network wide policy set by the management system.

In a particular embodiment, the wireless device 112A is operating in a connected mode such as, for example, RRC Connected.

In particular embodiments, when applying the mobility command, the wireless device 112A may apply the handover configuration. An example operation that may be performed while applying the handover configuration may include tuning to the target cell.

In particular embodiments, performing the at least one action according to the one or more indications related to the usage of the at least one SW version associated with the target cell may include running and/or booting up the SW version, putting the SW version in active memory, adding the SW version, releasing the SW version, modifying the SW version, etc.

In a particular embodiment, the one or more indications and the mobility command are received in one message.

In another embodiment, the one or more indications and the mobility command are received in different messages. Thus, in a particular embodiment, the wireless device 112A may receive the mobility command ordering the wireless device 112A to the target cell and the indication of SW versions to be used in target cells in separate but associated messages. These may be different messages of the same type (e.g., a first RRC Reconfiguration message and a second RRC Reconfiguration message) or messages of different types (e.g., an RRC Resume message and an RRC Reconfiguration message; or an RRC Setup message and an RRC Reconfiguration message). Any of these messages could be associated by the target cell indication (e.g., target Cell ID), or some other identifier (e.g., transaction ID, configuration identifier, reconfiguration identifier, SW version identifier) or be associated in other ways such that both messages are grouped in a higher level message. For example, the wireless device 112A may be configured upon entering RRC_CONNECTED (e.g., RRC Reconfiguration message) with at least one target candidate cells and one or more SW versions associated with the target candidate cell so that when the wireless device 112A executes the mobility it perform the actions with the associated one or more SW versions.

In a particular embodiment, the mobility command corresponds to one or more of: a Handover command; a RRCReconfiguration message including IE MobilityControlInfo; and a RRCReconfiguration message including IE ReconfigurationWithSync (e.g., for a Master Cell Group (MCG) and/or for a Secondary Cell Group (SCG)).

As another example, in a particular embodiment, the mobility command comprises at least one of: a configuration that is specific for a target cell such that it allows the wireless device 112A to access the target cell (such as the ones in the IE ServingCellConfigCommon); a random access configuration for the target cell; and a physical cell identifier (PCI) for the target cell.

As yet another example, in a particular embodiment, the mobility command comprises information necessary for the wireless device 112A to access a target cell such as the information included the IE ReconfigurationWithSync as defined in 3GPP TS 38.331.

In a particular embodiment, the mobility command is configured as a conditional handover (CHO) and/or a conditional PScell Change (CPC), as defined in 3GPP TS 38.331. As such, the wireless device 112A may apply the mobility command and/or perform the actions associated with the one or mor indications upon fulfillment of a condition associated with the CHO or the CPC. In other words, the actions may be performed only upon CHO or CPC execution.

In a particular embodiment, the wireless device 112A detects an occurrence of an event triggering performance of the at least one action according to the one or more indications related to the usage of the at least one SW version. In this scenario, the at least one action is performed in response to detecting the occurrence of the event.

In a further particular embodiment, detecting the occurrence of the event comprises at least one of: detecting one or more out-of-sync events; detecting one or more beam failure indications (BFIs); determining that a value associated with a measurement is above a maximum threshold; determining that a value associated with a measurement is below a minimum threshold; determining that a battery level of the wireless device 112A is below a threshold amount; determining that an amount of downlink traffic to the wireless device 112A or uplink traffic from the wireless device 112A is greater than a maximum threshold; determining that an amount of downlink traffic to the wireless device 112A or uplink traffic from the wireless device 112A is less than a minimum threshold; and detecting a traffic type, traffic Quality of Service, and/or traffic category at the wireless device 112A. In a particular embodiment, the one or more indications comprise a plurality of indications, and each one of the plurality of indications is associated with a respective one of a plurality of target cells.

In a particular embodiment, the one or more indications related to the usage of the at least one SW version comprises at least one of: an addition of a SW version; a release of a SW version; a modification of a SW version; a selection of a SW version; an activation of a SW function; and a deactivation of a SW function.

In a particular embodiment, the one or more indications related to the usage of the at least one SW version comprises a selection of one of a plurality of SW versions to use for execution of the mobility command.

In a particular embodiment, performing the at least one action may include performing at least one of: adding a SW version; releasing a SW version; modifying a SW version; selecting a SW version; activating a SW function; deactivating a SW function; and selecting one of a plurality of S W versions to use for execution of the mobility command.

In a particular embodiment, a SW version (possibly associated to a SW function) which has been added and/or modified is activated (or deactivated, or selected) based on at least the triggering of an wireless device internal event (i.e. detected at the wireless device 112A), wherein the internal event is triggered when the wireless device 112A accesses the target, and wherein an internal event may be triggered based on one or a combination of:

• Triggering of the event based on radio conditions.

• For example, in a particular embodiment, when an out-of-sync event (or a number of out-of-sync events) is detected such as when a message is possibly received from lower layers performing radio link monitoring, a SW version is activated to mitigate a potential Radio Link failure (RLF) and/or to speed up the recovery (via re-establishment. In this example, it is assumed that a specific SW version is associated to RLF mitigation/ avoidance.

• For example, in another particular embodiment, when at least one BFI (or a number of BFIs) is detected such as when a message is received from lower layers performing Beam failure Detection (BFD) monitoring, a SW version is activated to mitigate a potential Beam Failure Detection (BFD) and/or to speed up the recovery (via Beam Failure Recovery). In this example, it is assumed that a specific SW version is associated to BFD mitigation/ avoidance.

• As another example, in a particular embodiment, a SW version is only activated if a measurement result, such as Reference Signal Received Power (RSRP), 1

Reference Signal Received Quality (RSRQ), and/or Signal Interference to Noise Ratio (SINR) for a given entity is above and/or below a threshold. Herein, an entity can correspond to at least a cell, at least a beam, at least an Synchronization Signal Block (SSB), at least a Channel State Information- Reference Signal (CSI-RS), at least a cell-specific reference signal, etc. Some further specific examples are shown below:

■ If RSRP of a serving cell < threshold activated SW version “n”, for a SW function X related to RRM measurements.

■ If RSRP > threshold activated SW version “k”, for a SW function Y related to RRM measurements.

• Triggering of the event based on the wireless device’s battery information or battery state.

• For example, in a particular embodiment, a SW version of SW function X is activated if the battery state is > Y% (or above a threshold representing a battery level). This could be a SW function for extreme power savings which is only activated when needed.

• Triggering of the event based on the wireless device’s traffic volume (e.g., in DL and/or UL).

• For example, in a particular embodiment, a SW version of a SW function is only activated if the traffic volume (e.g., on a given bearer) is greater than >M. This could be distinguished in the Downlink and Uplink.

• Triggering of the event based on the traffic type and/or traffic QoS and/or traffic category.

• For example, in a particular embodiment, a SW version of a SW function is activated if QoS flow ID=X and QoS flow ID =Y are configured, or if a certain 5QI X has been activated.

In a particular embodiment, the activation of the SW version (e.g., SW version 3 is activated for a wireless device which has stored SW version 1, SW version 2, and SW version 3) based on the at least one wireless device internal event is of a SW version associated to a given SW function (e.g., SW function 7, for RRM measurements), wherein different SW versions can have different wireless device internal event triggers.

In a particular embodiment, the activation of the SW function (e.g., SW version 3 is activated, UE has stored SW version 1, SW version 2, SW version 3) based on the at least one wireless device internal event is of a SW version associated to a given SW function (e.g., SW function 7, for RRM measurements), wherein different SW versions can have different wireless device internal event triggers.

In a particular embodiment, the one or more indication(s) indicates at least one of the following: an addition of a SW version and/or a release of a SW version and/or a modification of a SW version and/or a selection of a SW version and/or an activation/ deactivation of a stored/ received SW function and/or a field indicating one of the SW versions the wireless device 112A shall use for the execution of command the indication(s) refer to (e.g., for a given SW function, network provides versions vl, v2, v3 and indicates that wireless device 112A shall use v3).

In a further particular embodiment, the wireless device 112A receives multiple SW versions and selects one of the version according to pre-defined criteria such as, for example, its capability, speed, mobility, or any internal event as described herein.

In a particular embodiment, performing actions according to the one or more indication(s) f comprises one or more of the following: adding a SW version and/or release a SW version and/or modify a SW version and/or select a SW version and/or activate/ deactivate a stored/ received SW function.

In a particular embodiment, when receiving the mobility command, the wireless device 112A has stored one or more protocol stack software (SW) versions. One or more of the following example scenarios may apply:

• In a particular embodiment, the one or more SW versions are stored at the UE/chipset from factory, at a chipset level when the chipset is initially setup e.g., before leaving the factory (or other vendor premises).

• In another particular embodiment, the one or more SW versions are part of subscriber identity information available at the wireless device side. As one example, SW version(s) might be stored at a SIM card that may be placed at the wireless device 112A. When the SIM card is placed at the wireless device 112A, one can say the wireless device 112A has stored multiple SW versions. As another example, which may be considered an embedded SIM (eSIM) scenario, SW version(s) could be part of the information available at an embedded universal integrated circuit card (eUICC) and which were retrieved from a subscription manager (SM) together with subscriber identity information of one or more network operators. In that embodiment, it is possible then to associate different sets of SW versions to different mobile network operators (MNOs) to switch from a set of MNOs, without needing to physically change the SIM card itself, as subscriber information are different for the different operator(s). • In a particular embodiment, the one or more SW versions can be downloaded by the wireless device 112A from a server. In one example, the download is done by the network indicating during a signaling procedure (e.g., initial registration with a network, registration area update, initial attachment, etc.) a network location (e.g., IP address) of a server where the wireless device 112A can download/obtain the one or more SW version(s).

• In a particular embodiment, a SW version stored at the wireless device 112A (e.g., eSIM, SIM) may be valid across multiple network nodes, so that upon the handover / mobility procedure the target network (or the wireless device 112A in an autonomous manner) can activated and/or deactivate and/or select the SW version.

Combinations of these methods above for storing the SW version are also a possibility. For example, it may be defined that for protocols and/or protocol functions for one domain (e.g., Core Network domain) the associated SW versions are stored in one way, while protocols and/or protocol functions for a different domain (e.g., RAN) are stored in a different way.

In a particular embodiment, the wireless device 112A performs actions according to the one or more indie ation(s) upon applying the one or more indication(s).

In a particular embodiment, the mobility command is divided in two parts. The first part comprises the one or more indication(s) for usage of the one or more SW versions associated with the target cell, and the second part comprises remaining parameters and/or configurations (such as the IE ReconfigurationWithSync).

In a particular embodiment, the wireless device 112A is configured with a dual active protocol stack. One corresponds to serving cell and the other corresponds to the target cell. The one or more indication(s) for usage of SW versions associated with the target cell may only be applied to the protocol stack corresponding to the target cell or to the protocol stack corresponding to the source cell, as appropriate.

In a further particular embodiment, the wireless device 112A first applies the first part of the mobility command and then the second part (in case there is no need of a newly added SW version to interpret the configurations within the first part).

In a further particular embodiment, the wireless device 112A first applies the second part of the mobility command and then the first part, in case the wireless device 112A needs to add a new SW version (or select/ activate a new one) to interpret the configurations within the first part and/or to modify actions when accessing the target (such as if the S W version modifies the random access behavior). In a particular embodiment, each SW version to be used in the target cell has an associated identifier (e.g., SW version ID). One or multiple SW version(s) can be added to the wireless device 112A by the network in the mobility command. In other words, the UE 112A receives one or multiple SW version(s) from the network (e.g., in a message). These may be generated by the target network node HOB and transmitted to the wireless device 112A via the source network node 110A. Upon reception of one or multiple SW version(s) (e.g., each version being associated with an identifier), the UE stores the SW version(s) and the associated identifier(s) (e.g., in something like a list, sequence, map, or any other data structure to store sets of data). This can be used in the case the target network node HOB determines to add a new SW version to the wireless device 112A upon mobility, wherein this new SW version may be useful after the wireless device 112A performs the handover procedure.

In a particular embodiment, the wireless device 112A stores the at least one SW version in a wireless device variable, which is updated (SW version is added, released, modified, activated, deactivated) upon mobility procedure (reconfiguration with sync).

In a particular embodiment, the wireless device 112A receives one or more SW versions in an RRC message (e.g., from a Radio Access Network node); or in a NAS (Non-Access Stratum) message (e.g., from a Core Network function/network element); or in an Over the top application. In case this is not an RRC message, this message from another protocol may be embedded in a container within the RRC message (e.g., RRCReconfiguration) carrying the SW version (or information enabling the wireless device to obtain the SW version, such as an addressing information or Domain Naming Server (DNS)).

In a particular embodiment, the mobility command contains an indication of at least one of the SW versions that is to be used (i.e. executed), upon which the wireless device 112A includes an acknowledgement related to at last one SW version in the RRC Reconfiguration Complete message transmitted to the target network (e.g., within MSG3 during random-access with the target cell).

In a further particular embodiment, the RRC Reconfiguration Complete message is transmitted using the old SW version so that from that point onwards the target network node the wireless device 112A is accessing is aware that the wireless device 112A has successfully loaded the indicated SW version.

In another particular embodiment, the RRC Reconfiguration Complete message is transmitted using the indicated SW version so that from that point onwards the target network node 11 OB is aware that the wireless device 112A has successfully loaded the indicated SW version. In a particular embodiment, instead of receiving the SW version(s), the wireless device 112A receives an indication of a location (e.g., server address, domain name) from where the wireless device 112A can obtain (download) the SW version(s).

In further particular embodiment, the wireless device 112A obtains (e.g., downloads) the SW version(s) before accessing the target cell (e.g., before applying the first part of the mobility command). The SW version(s) may be obtained using the wireless device’s connection with the source cell (or other connectivity available such as WiFi/ WLAN).

In further particular embodiment, the wireless device 112A obtains (e.g., downloads) the SW version(s) after accessing the target cell.

In a further particular embodiment, the wireless device 112A obtains (e.g., downloads) the SW version(s) before accessing the target cell (e.g., before applying the first part of the mobility command) such as by using the wireless device’s connection with the source cell if the source cell still has good enough radio conditions. For example, if the RSRP and/or RSRQ is/are above a predefined or configured threshold, the wireless device 112A may obtain the SW version(s) from the source network node. Otherwise, the wireless device 112A obtains (e.g., downloads) the SW version(s) after accessing the target cell from the target network node.

In a particular embodiment, a SW version can be added to the wireless device 112A as part of the mobility procedure. In this scenario, the SW version is being added by the target network node HOB. In other words, the wireless device 112A may have already stored zero, one, or multiple SW versions (e.g., obtained in at least one of the various manners described above) and receive in the mobility command one or more indication(s) upon which the wireless device 112A adds a SW version by, for example, storing it.

In a further particular embodiment, the wireless device 112A receives a message (e.g., a RRC message) from the target network node HOB (via the source network node 110A). The message may contain the mobility command, with a field of a wireless device 112A having an AddModList structure, wherein:

• Each element of the list comprises a SW version identifier and the SW version to be stored. Upon reception, the wireless device 112A stores the SW version and the associated SW version identifier such as, for example, in a wireless device variable (named for example VarSW-Version).

• Or, alternatively, each element of the list comprises a SW version identifier and an address information (e.g., IP address of a server where function(s) are located) of the SW version where it can be downloaded. Upon reception, the wireless device 112A downloads the indicated SW version(s) and stores each with the associated SW version 1 identifier such as, for example, in a UE variable. The wireless device 112A may receive common address information for more than one SW version where for example they have the same IP address. In that case, there can be at least one parameter that distinguishes the SW versions such that the wireless device 112A is able to associate a SW version to its identifiers when the wireless device 112A downloads the SW versions from the location. For example, the server has the identification of each SW version as the wireless device 112A receives in the message.

Example Specification text for enabling some of the described features is provided below:

SW-Vers i onToAddModLi s t : : = SEQUENCE ( S I Z E ( 1 . . K1 ) ) OF SW-Vers i onToAddMod

SW-Vers i onToAddMod : : = SEQUENCE { sw-Vers ionld INTEGER ( 1 . . K2 ) sw-Vers ionAddres s OCTET STRING }

The UE shall: l>for each sw-Versionld included in the received sw-VersionToAddModList.

2> download for this sw-Versionld the associated SW version using the address in the associated sw-VersionAddress after connecting to the target cell;

2>add a new entry (i.e. store) for this sw-Versionld within the VarSW-Version, including the downloaded version associated to this sw-Versionld, Various manners have been described to store one or more SW version at the UE (e.g., SIM card, chipset, downloaded, received in signaling/messages, etc.). A combination of these embodiments may also be implemented e.g., the UE may have stored a set of SW version(s) in its chipset, it may have obtained another set of SW version(s) when a SIM card is installed, and another set may have been added by the network via network signaling. The stored SW version that is being added is not necessarily executed upon reception.

In a particular embodiment, a SW version can be removed from the wireless device 112A by the network during the mobility procedure. In other words, the wireless device 112A receives an indication from the target network node HOB (via the source network nodel lOA) in the mobility command including a SW version identifier (or something equivalent, enabling the wireless device 112A to identify which SW version is to be deleted) indicating which one of the multiple stored SW versions is to be deleted.

In a further particular embodiment, if the version that the target network node HOB is indicating to be deleted is a SW version the wireless device 112A is NOT currently running (e.g., a deactivated/inactive SW version), the wireless device 112A removes the SW version before or after it accesses the target cell. In further particular embodiment, the wireless device 112A removes (releases, deletes) at least one indicated SW version which is stored in a wireless device 112A variable upon mobility procedure (reconfiguration with sync).

In a further particular embodiment, if the version that the target network node HOB is indicating to be deleted/ removed is a SW version the wireless device 112A is currently running (e.g., an active/activated SW version), the wireless device 112A performs a set of actions such as, for example, the reset of protocol entities, the cleaning up of buffers, the reset of protocol variables, removal of configurations generated according to that SW version, reset of timers and constants generated according to that SW version. In one embodiment, these actions are performed before the wireless device 112A accesses the target cell and/or before the wireless device 112A starts to operate according to the configuration of that target cell and/or before the wireless device 112A even applies the RRC configuration according to the target cell.

In a particular embodiment, the wireless device 112A receives the command to remove the one or more SW version in an RRC message (e.g., from a Radio Access Network node); or in a NAS (Non-Access Stratum) message (e.g., from a Core Network function/network element); or in an Over the top application. In case this is not an RRC message, this message from another protocol may be embedded in a container within the RRC message (e.g., RRCReconfiguration) carrying the indication of which SW version(s) are/is to be removed (or information enabling the UE 112A to obtain information about the SW version to be removed).

In a particular embodiment, the wireless device 112A transmits to the target network node HOB (to the target cell) an indication confirming/acknowledging that the wireless device 112A removed the SW version(s) that the network is trying to remove. For example, the indication confirming/acknowledging may be included in a complete message sent to the target cell such as the RRC Reconfiguration Complete message transmitted to acknowledge the mobility procedure upon random access in the target cell.

In a particular embodiment, multiple SW versions can be removed in the same mobility command. For example, the mobility command may include a remove list structure where the network indicates via the SW version identifier which associated version(s) that is/are stored and is/are to be deleted upon reception of the message. This may operate like a delta signaling for the SW versions during mobility.

In a particular embodiment, a SW version stored at the wireless device 112A can be modified (e.g., updated, patched, replaced) by the target network node 11 OB upon a mobility procedure. In other words, the wireless device 112A receives an indication from the target network node 11 OB (via the source network node 110A), within a mobility command, including a SW version identifier (or something equivalent, enabling the wireless device 112A to identify which SW version is to be modified) indicating which one of the multiple stored SW version(s) is/are to be modified before or after accessing the target cell. Upon determining which SW version(s) is/are to be modified, the wireless device 112A perform a set of actions such as: replacing a SW version associated with an indicated identifier with a new SW version being provided by the network, updating parameters associated with the SW version being modified, etc.

In a particular embodiment, a SW version stored at the wireless device 112A can be activated (e.g. executed, applied, run) during the mobility procedure. For example, the activation of a given SW version may be indicated in the mobility command and such activation is set by the target network node. For example, the SW version may be activated by the reception of an indication (e.g., a command or field in a message) from the target network node (via the source network node in the mobility command), which may be either explicit or implicit.

For example, the wireless device 112A can receive an indication from the target network node 11 OB in the mobility command including a SW version identifier (or something equivalent) indicating which one of the multiple stored SW versions is to be activated. Upon determining which SW version is to be activated, the wireless device 112A activates the SW version, meaning that the wireless device 112A runs/execute the stored SW version to be used in the target cell.

In a particular embodiment, the wireless device 112A activates the indicated SW version before it accesses the target cell. In this scenario, it would be possible to have the SW version activated such that it modifies the mobility procedure (e.g., random access), the interpretation of parameters of the target cell being applied in the mobility command, the way the RRC Reconfiguration Complete to the target cell is generated, and/or information to be added within.

In a particular embodiment, the mobility command indicates whether the wireless device 112A shall activate a SW function after accessing the target cell. In this scenario, it would be possible to speed up the mobility procedure so that the SW version is activated only after the wireless device 112A accesses the target cell. This should be possible if the activation of the indicated SW version does not modify the mobility procedure and only modifies the operation in the target cell.

In a particular embodiment, the mobility command indicates whether the wireless device 112A shall apply the target cell configuration before a SW version is activated. In this scenario, it would be possible to speed up the mobility procedure in case the SW version does not modify the way the wireless device 112A processes the parameters for the target cell configuration such as, for example, if the features being modified/added by the S W version are related to implementations which are not configurable by these RRC parameters in the target cell configuration (e.g., how measurements are sampled, etc.).

In a particular embodiment, the mobility command indicates whether the wireless device 112A shall apply the target cell configuration after a SW function is activated. In this scenario, it would be possible for the target network node HOB to include parameters in its target cell configuration that cannot be interpreted by the current SW version the wireless device 112A has currently activated. This may be limited to the one being activated by the command. Hence, the wireless device 112A first activates the indicated SW version to only then apply the target cell configuration in the mobility command.

In a particular embodiment, a SW version stored at the wireless device 112A can be deactivated (e.g., stop being executed, stop being applied, stop running, released, etc.) during a mobility procedure and upon the reception of a mobility command. For example, the SW version may be deactivated upon the reception of an indication in the mobility command (e.g., a command or field in a message) from the target network node HOB (via the source network node 110A), which may be either explicit or implicit.

Similar to above, the wireless device 112A can receive an indication from the target network node 110B (via the source network node 110A) in a mobility command including a SW version identifier (or something equivalent) indicating which one of the multiple stored SW versions is to be deactivated. Upon determining which SW version is to be deactivated, the wireless device 112A deactivates the SW version. Accordingly, thereafter, the wireless device 112A stops running/executing the stored SW version.

In a particular embodiment, the wireless device 112A deactivates the indicated SV version before it accesses the target cell. In this scenario, it would be possible to have a SW version deactivated which then modifies the mobility procedure (e.g., random access), interpretation of parameters of the target cell being applied in the mobility command, the way the RRC Reconfiguration Complete to the target cell is generated, and/or information to be added within.

In a particular embodiment, the mobility command indicates whether the wireless device 112A shall deactivate a SW function after accessing the target cell. In this scenario, it would be possible to access the target cell still based on the SW version that is currently activated, which is to become deactivated in the target cell.

In a particular embodiment, the mobility command indicates whether the wireless device 112A shall apply the target cell configuration before a SW version is deactivated. In this scenario, it would be possible to speed up the mobility procedure in case the SW version does not modify the way the wireless device 112A processes the parameters for the target cell configuration such as, for example, if the features being modified/added by the SW version are related to implementations that are not configurable by these RRC parameters in the target cell configuration (e.g., how measurements are sampled, etc.)

In a particular embodiment, the mobility command indicates whether the wireless device 112A shall apply the target cell configuration after a SW version is deactivated. In this scenario, it would be possible for the target network node HOB to include parameters in its target cell configuration which would have been misinterpreted by the SW version that is indicated to be deactivated. Thus, the wireless device 112A first deactivates the indicated SW version to only then apply the target cell configuration in the mobility command.

In a particular embodiment, the wireless device 112A receives the command to deactivate a stored SW version in an RRC message (e.g., from a Radio Access Network node); in a NAS (Non-Access Stratum) message (e.g., from a Core Network function/network element); or in an Over the top application. The message may correspond to the same message carrying the mobility command (e.g., ReconfigurationWithSync IE).

In a particular embodiment, upon deactivation of a SW version, the wireless device 112A includes an acknowledgement related to the deactivated SW version(s) in the RRC Reconfiguration Complete message transmitted to the target network (e.g., within MSG3 during random-access with the target cell), indicating that the indicated SW version has been deactivated.

In further particular embodiment, the RRC Reconfiguration Complete message is transmitted using the SW version that is being deactivated. Specifically, the message is transmitted before deactivation of the SW version so that from that point onwards the target network node 110B the wireless device 112A is accessing is aware that the wireless device 112A has successfully loaded the indicated SW version.

In another particular embodiment, the RRC Reconfiguration Complete message is transmitted after the SW version has been deactivated.

In a particular embodiment, the SW version generates a token upon deactivation of the SW version. The wireless device 112A may include the token in the complete message (e.g., RRC Reconfiguration Complete) to the target network node 11 OB so that the target network node HOB is able to verify that the SW version has been successfully deactivated.

In another particular embodiment, upon receiving a message to add a one or more SW version(s) during mobility, they are all considered deactivated when the wireless device 112A accesses the target cell. Alternatively, upon receiving a message to add a one or more SW version(s) during mobility, they are all considered deactivated when the wireless device 112A accesses the target cell, except the SW version(s) having an indication that are to be activated. According to certain embodiments, the information regarding SW functions the wireless device 112A has stored is part of the UE Access Stratum (AS) context (which may also be called UE context or UE AS Context for a wireless device in Connected state) which is stored at the source network node 110A (and/or the network node serving the wireless device). That context is transferred to the target network node HOB during a handover such as, for example, in the Handover Request message.

In another embodiment, the wireless device 112A indicates to the target network node 110B (e.g., in the RRC Reconfiguration Complete message upon handover/ mobility) which SW versions it has stored so that the target network node HOB can determine, after the wireless device 112A is handed over, to release, modify, activate, deactivate, or add at least one of the stored SW versions. Based on that indication, the target network node 11 OB can understand which versions the wireless device 112A has stored (e.g., wireless device has stored in the IMSI and/or from factory). This report in the RRC Reconfiguration Complete message can be configured by the target network node 11 OB in the mobility command.

In another particular embodiment, more than one SW version can be activated at time upon reception of the same mobility command. In that case, there can be an indication in the mobility command to activate a SW version and/or an indication to deactivate a SW version. For example, if wireless device 112A has stored SW versions (1), (2) and (3) in the source cell and SW version (2) is the currently active SW version, and if the wireless device 112A receives in the mobility command the indication from the network for SW version (1), the wireless device 112A keeps both SW versions (1) and (2) after handover to the target cell.

In a particular embodiment, each SW version is group of SW packages, and each is associated to a protocol stack.

In a particular embodiment, the SW versions are provided by the network to the wireless device 112A. These may be SW versions created at the network side based on API(s) exposed by the wireless device 112A to the network and used by the network to create these SW versions that are added to the wireless device 112A.

FIGURE 8 illustrates an example method 400 at or by a target network node 114 associated with a target cell during a handover of a wireless device 112A from a source network node 110A associated with a source cell to the target network node 110B. The method begins at step 402 when the target network node HOB receives, from the source network node 110A, a handover request message requesting handover of the wireless device 112A to the target network node 110B. At step 404, the target network node 110B transmits, to the source network node 110A, a handover request acknowledgement. At step 406, the target network node HOB transmits to the source network node 110A at least one of: one or more indications related to usage of at least one SW version associated with the target cell and/or one or more software versions for use by the wireless device 112A in the target cell.

In a particular embodiment, the handover request message comprises one or more additional indications of at least one SW version stored at the wireless device 112A.

In a particular embodiment, the handover request message comprises one or more additional indications of at least one SW version associated with the source cell.

In a particular embodiment, the one or more indications related to the usage of the at least one SW version comprises a selection of one of a plurality of SW versions to use for execution of a mobility command by the wireless device 112A.

In a particular embodiment, the handover comprises a conditional handover or a conditional primary secondary cell change from the source cell to the target cell.

In a particular embodiment, the wireless device 112A is operating in a connected mode.

FIGURE 9 illustrates an example method 500 at or by a source network node 110A serving a wireless device 112A, according to certain embodiments. The method begins when the source network node 110A transmits, to a target network node HOB, a Handover Request message requesting handover of the wireless device 112A to the target network node 110B. At step 504, the source network node 110A receives, from the target network node 110B, a Handover Request Ack message. At step 506, the source network node 110A receives from the target network node 110B: one or more indications related to usage of at least one SW version associated with the target cell, and/or one or more SW versions for use by the wireless device 112A in the target cell. At step 508, the source network node 110A transmits, to the UE, a mobility command and the one or more indications related to the usage of the at least one SW version associated with the target cell.

In a particular embodiment, the one or more indications and the mobility command are transmitted to the wireless device 112A in one message. In a particular embodiment, the one or more indications and the mobility command are transmitted to the wireless device 112A in different messages.

In a particular embodiment, the one or more indications comprise a plurality of indications, and each one of the plurality of indications is associated with a respective one of a plurality of target cells.

In a particular embodiment, the mobility command is at least one of: a Handover command, and a Radio Resource Control Reconfiguration (RRCReconfiguration) message.

In a particular embodiment, the mobility command comprises at least one of: a configuration that is specific for the target cell; a random access configuration; and a physical cell identifier for the target cell.

In a particular embodiment, the mobility command is associated with a CHO or a CPC from the source cell to the target cell, and wherein the mobility command is applied and/or the actions are performed upon fulfillment of a condition associated with the CHO or the CPC.

In a particular embodiment, when there is no direct interface between source gNB and target gNB, the management of SW versions are done by a network node/ function at the core network (or another network domain such as, for example, management plane, SW plane, or UE programmability plane). For example, FIGURE 10 illustrates example signaling 600 when there is no direct Xn interface between the source network node 110A and the target network node 110B, according to certain embodiments.

In FIGURE 10, the source network node 110A is illustrated as a source NG-RAN node (S- NG-RAN) and the target network node HOB is illustrated as a target NG-RAN node (T-NG- RAN). The source network node 110A indicates information on the current SW version(s) the wireless device 112A has stored and/or which SW versions the wireless device has activated/deactivated (i.e. which version the UE is running for a certain SW function) to the target network node HOB through a series of signalling with the help of target- AMF (T-AMF) and source-AMF (S-AMF). Specifically, as depicted in FIGURE 10, the source network node 110A initiates aN2 based handover through its AMF (S-AMF) 616A by sending a Handover Request to the S-AMF 616A, at step 1. At step 2, the S-AMF 616A selects a T-AMF 616B. The S-AMF 616A forwards the Handover Request to T-AMF 616B, at step 3. Then, at step 4, the T-AM 616B forwards the Handover Request to the target network node 110B.

At step 5, the target network node HOB decides on SW management. For example, the target network node HOB may make SW management decisions based on the information related to the SW versions stored at and/or activated in the wireless device 112A, in a particular embodiment.

At step 6, the target network node 110B sends the Handover Request ACK, which includes a SW management command, to the T-AMF 616B. The T-AMF 616B then forwards the Handover Request ACK to the S-AMF 616A, at step 7.

At step 8, the S-AMF 616A sends a Mobility Command to the source network node 110A. The Mobility Command includes the SW management and/or the SW management command. At step 9, the source network node 110A sends the Mobility command (including the SW management and/or SW management command) to the wireless device 112A.

According to certain and various embodiments described herein, the information on the current SW version(s) the wireless device has stored and/or which SW versions the wireless device has activated/deactivated includes at least one of the following information:

• the functionality/layer/entity (e.g., PDCP routing, measurement, mobility enhancement, MAC layer) the SW version targets;

• an indication of the API(s) that is used by a SW version;

• an indication of whether or not a SW version is vital to the correct operation of the wireless device;

• at least a SW version identifier; and/or

• an indication of which SW function a given SW version refers to such as, for example, by indicating a SW function identifier.

According to certain and various embodiments described herein, the one or more indication(s) related to the usage of SW versions associated with the target cell may include at least one of: an indication of whether or not use of SW versions in the wireless device is allowed; an indication of types of APIs that is allowed to be used by the SW version; and/or an indication of types of APIs that are prohibited to be used by the SW version. In a particular embodiment, the interface between the source and target network nodes allows for the source network node to request information related to SW management and utilization. For example, FIGURE 11 illustrates example signaling 700 for requesting, by the source network node 110A, information related to SW management and utilization, according to certain embodiments. At step 1, the source network node 110A sends a request for the information to the target network node HOB. At step 2, the target network node HOB replies with the information related to SW management and utilization. In a particular embodiment, for example, the information may be related to the usage of at least one SW version.

In various particular embodiments, the source network node may request the information during a HO, as part of the Handover preparation, or even before a decision to perform a handover is taken. In the latter scenario, the requested information may be used by the source network node as a criteria when making a decision as to whether to handover the wireless device or not.

According to certain embodiments, the information related to SW management and utilization comprises at least one of the following or any combination of:

• an indication of whether or not use of one or more SW function/ version in the wireless device is allowed or not;

• an indication of types/versions of one or more SW function(s) that is/are already in use by the target network node;

• an indication of a size of the SW functions and versions such as, for example, in number of bits and/or bytes;

• an indication of a performance or characteristic of the SW function such as, for example, the power consumption of a SW function;

• an indication of a minimum capability the wireless device needs to be able to run a specific SW function;

• an indication of type(s) of API(s) that is/are allowed to be used by the SW function (e.g., any APIs that the target network node prohibits towards the application domain);

• an indication of information on the requirement of API(s) that is/are used in the SW versions of specific SW functions (e.g., a SW version requires an API that can provide inter/intra frequency measurements every x milliseconds); and/or

• an indication of whether or not the target network node supports inter node SW transfer.

A technical advantage of certain embodiments relating to FIGURE 11 is that the source network node can acquire necessary information about SW management and/or related to usage 1 of SW versions by a target network node well before a handover of a wireless device 112A is necessary.

FIGURE 12 illustrates example signaling 800 enabling a source network node 110A to identify multiple candidate cells belonging to one or more candidate target network nodes 1 I Bi.

2. ... x for a potential future handover of a wireless device 112A, according to certain embodiments.

As shown in FIGURE 12, UE 112A and source network node 110A perform early measurement and reporting, at step 1. At step 2, the source network node 110 A predicts a handover in the future based on the early measurement and reporting. At step 3A and 3B, the source network node 110A initiates a CHO to the identified target network nodes 1 10 B ] 2. ... _x and includes the information related to the utilized SW versions stored at and/or activated in the wireless device 112A.

At steps 4A and 4B, the target network nodes 1 10 B 1 2, ... x perform admission control and make SW management decisions based on the information related to the SW versions stored at and/or activated in the wireless device 112A. At steps 5A and 5B, the target network nodes 1 1 OB 1.

2. ... _x transmit a Handover Acknowledgement message to the source network node 110A. The Handover Acknowledgement message includes S W management information, which may include usage information relating to at least one SW version associated with the target network nodes 1 lOBy 2, ... x.

The source network node 110A receives the Handover Acknowledgment from the candidate target network nodes HOB and compiles a list of mobility commands (including SW management indications) for all the candidate target cells. In a particular embodiment, the source network node 110A also binds each mobility command with a trigger condition such as, for example, an event A3 as defined in 3 GPP TS 38.331. At step 6, the source network node 110A sends the list of the mobility commands and SW management indications to the wireless device 112A. In a particular embodiments, the list of mobility commands may also include the associated trigger conditions that are bound to the mobility commands.

At step 7, the wireless device 112A monitors for the triggering condition. When a target cell satisfies the triggering condition, the UE executes the mobility command (and SW management indication) associated to the target network node 11 OB to which its cell triggered the condition. Thereafter, a handover execution procedure is performed between the wireless device 112A and the target network nodes 110By 2, ... _x, at step 8.

FIGURE 13 shows an example of a communication system 900 in accordance with some embodiments. In the example, the communication system 900 includes a telecommunication network 902 that includes an access network 904, such as a radio access network (RAN), and a core network 906, which includes one or more core network nodes 908. The access network 904 includes one or more access network nodes, such as network nodes 110a and 110b (one or more of which may be generally referred to as network nodes 110), or any other similar 3^rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes 110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 112A, 112Bb, 112C, and 112D (one or more of which may be generally referred to as UEs 112) to the core network 906 over one or more wireless connections. Again, though UEs 112A-D are illustrated in FIGURE 13, it is recognized that UEs are used herein to refer to any type of wireless device.

Example wireless communications over a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 900 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections. The communication system 900 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.

The UEs 112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the network nodes 110 and other communication devices. Similarly, the network nodes 110 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 112 and/or with other network nodes or equipment in the telecommunication network 902 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network 902.

In the depicted example, the core network 906 connects the network nodes 110 to one or more hosts, such as host 916. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 906 includes one more core network nodes (e.g., core network node 908) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 908. Example core network nodes include functions of one or more of a 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), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF).

The host 916 may be under the ownership or control of a service provider other than an operator or provider of the access network 904 and/or the telecommunication network 902, and may be operated by the service provider or on behalf of the service provider. The host 916 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio/video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

As a whole, the communication system 900 of FIGURE 13 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); 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 Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and/or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

In some examples, the telecommunication network 902 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 902 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 902. For example, the telecommunications network 902 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)ZMassive loT services to yet further UEs.

In some examples, the UEs 112 are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 904 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 904. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

In the example, the hub 914 communicates with the access network 904 to facilitate indirect communication between one or more UEs (e.g., UE 112c and/or 112d) and network nodes (e.g., network node 110b). In some examples, the hub 914 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 914 may be a broadband router enabling access to the core network 906 for the UEs. As another example, the hub 914 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 110, or by executable code, script, process, or other instructions in the hub 914. As another example, the hub 914 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 914 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 914 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 914 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub 914 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy loT devices.

The hub 914 may have a constant/persistent or intermittent connection to the network node 110b. The hub 914 may also allow for a different communication scheme and/or schedule between the hub 914 and UEs (e.g., UE 112c and/or 112d), and between the hub 914 and the core network 906. In other examples, the hub 914 is connected to the core network 906 and/or one or more UEs via a wired connection. Moreover, the hub 914 may be configured to connect to an M2M service provider over the access network 904 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 110 while still connected via the hub 914 via a wired or wireless connection. In some embodiments, the hub 914 may be a dedicated hub - that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 110b. In other embodiments, the hub 914 may be a nondedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 110b, but which is additionally capable of operating as a communication start and/or end point for certain data channels. FIGURE 14 shows a UE 1000 in accordance with some embodiments.

As used herein, a UE refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicle embedded/integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.

A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard 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 may not necessarily have a user in the sense of a human user who owns and/or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

The UE 1000 includes processing circuitry 1002 that is operatively coupled via a bus 1004 to an input/output interface 1006, a power source 1008, a memory 1010, a communication interface 1012, and/or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in FIGURE 14. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

The processing circuitry 1002 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 1010. The processing circuitry 1002 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 together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 1002 may include multiple central processing units (CPUs).

In the example, the input/output interface 1006 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and/or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 1000. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

In some embodiments, the power source 1008 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 1008 may further include power circuitry for delivering power from the power source 1008 itself, and/or an external power source, to the various parts of the UE 1000 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 1008. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 1008 to make the power suitable for the respective components of the UE 1000 to which power is supplied.

The memory 1010 may be or be configured to include 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, flash drives, and so forth. In one example, the memory 1010 includes one or more application programs 1014, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1016. The memory 1010 may store, for use by the UE 1000, any of a variety of various operating systems or combinations of operating systems.

The memory 1010 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and/or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 1010 may allow the UE 1000 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 1010, which may be or comprise a device-readable storage medium.

The processing circuitry 1002 may be configured to communicate with an access network or other network using the communication interface 1012. The communication interface 1012 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1022. The communication interface 1012 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 a network node in an access network). Each transceiver may include a transmitter 1018 and/or a receiver 1020 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 1018 and receiver 1020 may be coupled to one or more antennas (e.g., antenna 1022) and may share circuit components, software or firmware, or alternatively be implemented separately.

In the illustrated embodiment, communication functions of the communication interface 1012 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and/or standards, such as IEEE 802.11, Code Division Multiplexing 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), and so forth. Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 1012, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

As still another example, it is recognized that the UEs of FIGURES 13 and 14 may be replaced with and/or FIGURES 13 and 14 may be modified to include one or more Internet of Things (loT) devices or other terminal and/or communication devices. An Internet of Things (loT) device, for example, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door/window sensor, a flood/moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a headmounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A wireless device in the form of an loT device comprises circuitry and/or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE 1000 shown in FIGURE 14.

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

In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g., by controlling an actuator) to increase or decrease the drone’s speed. The first and/or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

FIGURE 15 shows a network node 1100 in accordance with some embodiments.

As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a UE and/or with other network nodes or equipment, in a telecommunication network. 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 Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)).

Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and/or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). 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 may also be referred to as nodes in a distributed antenna system (DAS).

Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell/multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and/or Minimization of Drive Tests (MDTs).

The network node 1100 includes a processing circuitry 1102, a memory 1104, a communication interface 1106, and a power source 1108. The network node 1100 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 1100 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 1100 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1104 for different RATs) and some components may be reused (e.g., a same antenna 1110 may be shared by different RATs). The network node 1100 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1100, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 1100.

The processing circuitry 1102 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other network node 1100 components, such as the memory 1104, to provide network node 1100 functionality.

In some embodiments, the processing circuitry 1102 includes a system on a chip (SOC). In some embodiments, the processing circuitry 1102 includes one or more of radio frequency (RF) transceiver circuitry 1112 and baseband processing circuitry 1114. In some embodiments, the radio frequency (RF) transceiver circuitry 1112 and the baseband processing circuitry 1114 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1112 and baseband processing circuitry 1114 may be on the same chip or set of chips, boards, or units.

The memory 1104 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the processing circuitry 1102. The memory 1104 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and/or other instructions capable of being executed by the processing circuitry 1102 and utilized by the network node 1100. The memory 1104 may be used to store any calculations made by the processing circuitry 1102 and/or any data received via the communication interface 1106. In some embodiments, the processing circuitry 1102 and memory 1104 is integrated.

The communication interface 1106 is used in wired or wireless communication of signaling and/or data between a network node, access network, and/or UE. As illustrated, the communication interface 1106 comprises port(s)/terminal(s) 1116 to send and receive data, for example to and from a network over a wired connection. The communication interface 1106 also includes radio front-end circuitry 1118 that may be coupled to, or in certain embodiments a part of, the antenna 1110. Radio front-end circuitry 1118 comprises fdters 1120 and amplifiers 1122. The radio frontend circuitry 1118 may be connected to an antenna 1110 and processing circuitry 1102. The radio front-end circuitry may be configured to condition signals communicated between antenna 1110 and processing circuitry 1102. The radio front-end circuitry 1118 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 1118 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1120 and/or amplifiers 1122. The radio signal may then be transmitted via the antenna 1110. Similarly, when receiving data, the antenna 1110 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1118. The digital data may be passed to the processing circuitry 1102. In other embodiments, the communication interface may comprise different components and/or different combinations of components.

In certain alternative embodiments, the network node 1100 does not include separate radio front-end circuitry 1118, instead, the processing circuitry 1102 includes radio front-end circuitry and is connected to the antenna 1110. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1112 is part of the communication interface 1106. In still other embodiments, the communication interface 1106 includes one or more ports or terminals 1116, the radio frontend circuitry 1118, and the RF transceiver circuitry 1112, as part of a radio unit (not shown), and the communication interface 1106 communicates with the baseband processing circuitry 1114, which is part of a digital unit (not shown).

The antenna 1110 may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. The antenna 1110 may be coupled to the radio front-end circuitry 1118 and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In certain embodiments, the antenna 1110 is separate from the network node 1100 and connectable to the network node 1100 through an interface or port.

The antenna 1110, communication interface 1106, and/or the processing circuitry 1102 may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by the network node. Any information, data and/or signals may be received from a UE, another network node and/or any other network equipment. Similarly, the antenna 1110, the communication interface 1106, and/or the processing circuitry 1102 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and/or signals may be transmitted to a UE, another network node and/or any other network equipment.

The power source 1108 provides power to the various components of network node 1100 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 1108 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1100 with power for performing the functionality described herein. For example, the network node 1100 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 1108. As a further example, the power source 1108 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

Embodiments of the network node 1100 may include additional components beyond those shown in FIGURE 15 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, the network node 1100 may include user interface equipment to allow input of information into the network node 1100 and to allow output of information from the network node 1100. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1100. FIGURE 16 is a block diagram of a host 1200, which may be an embodiment of the host 916 of FIGURE 13, in accordance with various aspects described herein.

As used herein, the host 1200 may be or comprise various combinations hardware and/or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host 1200 may provide one or more services to one or more UEs.

The host 1200 includes processing circuitry 1202 that is operatively coupled via a bus 1204 to an input/output interface 1206, a network interface 1208, a power source 1210, and a memory 1212. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figures 10 and 11, such that the descriptions thereof are generally applicable to the corresponding components of host 1200.

The memory 1212 may include one or more computer programs including one or more host application programs 1214 and data 1216, which may include user data, e.g., data generated by a UE for the host 1200 or data generated by the host 1200 for a UE. Embodiments of the host 1200 may utilize only a subset or all of the components shown. The host application programs 1214 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAG, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs 1214 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host 1200 may select and/or indicate a different host for over-the-top services for a UE. The host application programs 1214 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

FIGURE 17 is a block diagram illustrating a virtualization environment 1300 in which functions implemented by some embodiments may be virtualized.

In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, 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 virtual environments 1300 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized.

Applications 1302 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 1300 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

Hardware 1304 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1306 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1308a and 1308b (one or more of which may be generally referred to as VMs 1308), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 1306 may present a virtual operating platform that appears like networking hardware to the VMs 1308.

The VMs 1308 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1306. Different embodiments of the instance of a virtual appliance 1302 may be implemented on one or more of VMs 1308, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

In the context of NFV, a VM 1308 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1308, and that part of hardware 1304 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1308 on top of the hardware 1304 and corresponds to the application 1302. Hardware 1304 may be implemented in a standalone network node with generic or specific components. Hardware 1304 may implement some functions via virtualization. Alternatively, hardware 1304 may be part of a larger cluster of hardware (e.g., such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1310, which, among others, oversees lifecycle management of applications 1302. In some embodiments, hardware 1304 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1312 which may alternatively be used for communication between hardware nodes and radio units.

FIGURE 18 shows a communication diagram of a host 1402 communicating via a network node 1404 with a UE 1406 over a partially wireless connection in accordance with some embodiments.

Example implementations, in accordance with various embodiments, of the UE (such as a UE 112a of FIGURE 13 and/or UE 1000 of FIGURE 14), network node (such as network node 110a of FIGURE 13 and/or network node 1100 of FIGURE 15), and host (such as host 916 of FIGURE 13 and/or host 1200 of FIGURE 16) discussed in the preceding paragraphs will now be described with reference to FIGURE 16.

Like host 1200, embodiments of host 1402 include hardware, such as a communication interface, processing circuitry, and memory. The host 1402 also includes software, which is stored in or accessible by the host 1402 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE 1406 connecting via an over-the-top (OTT) connection 1450 extending between the UE 1406 and host 1402. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 1450.

The network node 1404 includes hardware enabling it to communicate with the host 1402 and UE 1406. The connection 1460 may be direct or pass through a core network (like core network 906 of FIGURE 13) and/or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

The UE 1406 includes hardware and software, which is stored in or accessible by UE 1406 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE 1406 with the support of the host 1402. In the host 1402, an executing host application may communicate with the executing client application via the OTT connection 1450 terminating at the UE 1406 and host 1402. In providing the service to the 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 1450 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection 1450.

The OTT connection 1450 may extend via a connection 1460 between the host 1402 and the network node 1404 and via a wireless connection 1470 between the network node 1404 and the UE 1406 to provide the connection between the host 1402 and the UE 1406. The connection 1460 and wireless connection 1470, over which the OTT connection 1450 may be provided, have been drawn abstractly to illustrate the communication between the host 1402 and the UE 1406 via the network node 1404, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

As an example of transmitting data via the OTT connection 1450, in step 1408, the host 1402 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 1406. In other embodiments, the user data is associated with a UE 1406 that shares data with the host 1402 without explicit human interaction. In step 1410, the host 1402 initiates a transmission carrying the user data towards the UE 1406. The host 1402 may initiate the transmission responsive to a request transmitted by the UE 1406. The request may be caused by human interaction with the UE 1406 or by operation of the client application executing on the UE 1406. The transmission may pass via the network node 1404, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 1412, the network node 1404 transmits to the UE 1406 the user data that was carried in the transmission that the host 1402 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1414, the UE 1406 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 1406 associated with the host application executed by the host 1402.

In some examples, the UE 1406 executes a client application which provides user data to the host 1402. The user data may be provided in reaction or response to the data received from the host 1402. Accordingly, in step 1416, the UE 1406 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input/output interface of the UE 1406. Regardless of the specific manner in which the user data was provided, the UE 1406 initiates, in step 1418, transmission of the user data towards the host 1402 via the network node 1404. In step 1420, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 1404 receives user data from the UE 1406 and initiates transmission of the received user data towards the host 1402. In step 1422, the host 1402 receives the user data carried in the transmission initiated by the UE 1406.

One or more of the various embodiments improve the performance of OTT services provided to the UE 1406 using the OTT connection 1450, in which the wireless connection 1470 forms the last segment. More precisely, the teachings of these embodiments may improve one or more of, for example, data rate, latency, and/or power consumption and, thereby, provide benefits such as, for example, reduced user waiting time, relaxed restriction on file size, improved content resolution, better responsiveness, and/or extended battery lifetime.

In an example scenario, factory status information may be collected and analyzed by the host 1402. As another example, the host 1402 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 1402 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 1402 may store surveillance video uploaded by a UE. As another example, the host 1402 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host 1402 may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and/or transmitting data.

In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1450 between the host 1402 and UE 1406, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 1402 and/or UE 1406. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 1450 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1450 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 1404. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host 1402. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 1450 while monitoring propagation times, errors, etc.

Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and/or by end users and a wireless network generally.

Claims

1. A method (300) by a wireless device, (112A), the method comprising: receiving (302) a mobility command indicating that the wireless device is to move from a source cell to a target cell; receiving (304) one or more indications related to usage of at least one software (SW) version associated with the target cell; applying (306) the mobility command and performing at least one action according to the one or more indications related to the usage of the at least one SW version associated with the target cell.

2. The method of Claim 1, wherein the one or more indications and the mobility command are received in one message.

3. The method of Claim 1, wherein the one or more indications and the mobility command are received in different messages.

4. The method of Claim 3, wherein the one or more indications comprise a plurality of indications, and wherein each one of the plurality of indications is associated with a respective one of a plurality of target cells.

5. The method of any one of Claims 1 to 4, wherein the one or more indications related to the usage of the at least one SW version comprises at least one of: an addition of a SW version; a release of a SW version; a modification of a SW version; a selection of a SW version; an activation of a SW function; and a deactivation of a SW function.

6. The method of any one of Claims 1 to 5, wherein the one or more indications related to the usage of the at least one SW version comprises a selection of one of a plurality of SW versions to use for execution of the mobility command.

7. The method of any one of Claims 1 to 6, wherein performing the at least one action comprises at least one of: adding a SW version; releasing a SW version; modifying a SW version; selecting a SW version; activating a SW function; deactivating a SW function; and selecting one of a plurality of SW versions to use for execution of the mobility command.

8. The method of any one of Claims 1 to 6, wherein the mobility command is at least one of: a Handover command, and a Radio Resource Control Reconfiguration (RRCReconfiguration) message.

9. The method of any one of Claims 1 to 8, wherein the mobility command comprises at least one of: a configuration that is specific for the target cell; a random access configuration; and a physical cell identifier for the target cell.

10. The method of any one of Claims 1 to 9, wherein the mobility command is associated with a conditional handover or a conditional primary secondary cell change from the source cell to the target cell, and wherein the mobility command is applied and/or the actions are performed upon fulfillment of a condition associated with the conditional handover or the conditional primary secondary cell change.

11. The method of any one of Claims 1 to 10, further comprising: detecting an occurrence of an event triggering performance of the at least one action according to the one or more indications related to the usage of the at least one SW version; and wherein the at least one action is performed in response to detecting the occurrence of the event.

12. The method of Claim 11, wherein detecting the occurrence of the event comprises at least one of: detecting one or more out-of-sync events; detecting one or more beam failure indications (BFIs); determining that a value associated with a measurement is above a maximum threshold; determining that a value associated with a measurement is below a minimum threshold; determining that a battery level of the wireless device is below a threshold amount; determining that an amount of downlink traffic to the wireless device or uplink traffic from the wireless device is greater than a maximum threshold; determining that an amount of downlink traffic to the wireless device or uplink traffic from the wireless device is less than a minimum threshold; and detecting a traffic type, traffic Quality of Service, and/or traffic category at the wireless device.

13. The method of any one of Claims 1 to 12, wherein the wireless device is operating in a connected mode.

14. A method (400) by a target network node (HOB) associated with a target cell during a handover of a wireless device (112A) from a source network node (110A) associated with a source cell to the target network node associated with the target cell, the method comprising: receiving (402), from the source network node, a handover request message requesting handover of the wireless device to the target network node; transmitting (404), to the source network node, a handover request acknowledgement; and transmitting (406) to the source network node: one or more indications related to usage of at least one SW version associated with the target cell, and/or one or more software versions for use by the wireless device in the target cell.

15. The method of Claim 14, wherein the handover request message comprises one or more additional indications of at least one SW version stored at the wireless device.

16. The method of any one of Claims 14 to 15, wherein the handover request message comprises one or more additional indications of at least one SW version associated with the source cell.

17. The method of any one of Claims 14 to 16, wherein the one or more indications related to the usage of the at least one SW version comprises at least one of: an addition of a SW version; a release of a SW version; a modification of a SW version; a selection of a SW version; an activation of a SW function; and a deactivation of a SW function.

18. The method of any one of Claims 14 to 17, wherein the one or more indications related to the usage of the at least one S W version comprises a selection of one of a plurality of SW versions to use for execution of a mobility command by the wireless device.

19. The method of any one of Claims 14 to 18, wherein the handover comprises a conditional handover or a conditional primary secondary cell change from the source cell to the target cell.

20. The method of any one of Claims 14 to 19, wherein the wireless device is operating in a connected mode.

21. A method (500) by a source network node (110A) associated with a source cell during a handover of a wireless device (112A) to target network node (110B) associated with a target cell, the method comprising: transmitting (502), to the target network node, a handover request message requesting handover of the wireless device to the target network node; receiving (504), from the target network node, a handover request acknowledgement; and receiving (506) from the target network node: one or more indications related to usage of at least one SW version associated with the target cell, and/or one or more software versions for use by the wireless device in the target cell; and transmitting (508), to the wireless device, a mobility command and the one or more indications related to the usage of the at least one SW version associated with the target cell.

22. The method of Claim 21, wherein the handover request message comprises one or more additional indications of at least one SW version stored at the wireless device.

23. The method of any one of Claims 21 to 22, wherein the handover request message comprises one or more additional indications of at least one SW version associated with the source cell.

24. The method of any one of Claims 21 to 23, wherein the one or more indications and the mobility command are transmitted to the wireless device in one message.

25. The method of any one of Claims 21 to 23, wherein the one or more indications and the mobility command are transmitted to the wireless device in different messages.

26. The method of Claim 25, wherein the one or more indications comprise a plurality of indications, and wherein each one of the plurality of indications is associated with a respective one of a plurality of target cells.

27. The method of any one of Claims 21 to 26, wherein the one or more indications related to the usage of the at least one SW version comprises at least one of: an addition of a SW version; a release of a SW version; a modification of a SW version; a selection of a SW version; an activation of a SW function; and a deactivation of a SW function.

28. The method of any one of Claims 21 to 27, wherein the one or more indications related to the usage of the at least one S W version comprises a selection of one of a plurality of SW versions to use for execution of the mobility command.

29. The method of any one of Claims 21 to 28, wherein the mobility command is at least one of: a Handover command, and a Radio Resource Control Reconfiguration (RRCReconfiguration) message.

30. The method of any one of Claims 21 to 29, wherein the mobility command comprises at least one of: a configuration that is specific for the target cell; a random access configuration; and a physical cell identifier for the target cell.

31. The method of any one of Claims 21 to 30, wherein the mobility command is associated with a conditional handover or a conditional primary secondary cell change from the source cell to the target cell, and wherein the mobility command is applied and/or the actions are performed upon fulfillment of a condition associated with the conditional handover or the conditional primary secondary cell change.

32. A wireless device (112A) adapted to: receive a mobility command indicating that the wireless device is to move from a source cell to a target cell; receive one or more indications related to usage of at least one software (SW) version associated with the target cell; and apply the mobility command and performing at least one action according to the one or more indications related to the usage of the at least one SW version associated with the target cell.

33. The wireless device of Claim 32, wherein the one or more indications and the mobility command are received in one message.

34. The wireless device of Claim 32, wherein the one or more indications and the mobility command are received in different messages.

35. The wireless device of Claim 34, wherein the one or more indications comprise a plurality of indications, and wherein each one of the plurality of indications is associated with a respective one of a plurality of target cells.

36. The wireless device of any one of Claims 32 to 35, wherein the one or more indications related to the usage of the at least one SW version comprises at least one of: an addition of a SW version; a release of a SW version; a modification of a SW version; a selection of a SW version; an activation of a SW function; and a deactivation of a SW function.

37. The wireless device of any one of Claims 32 to 36, wherein the one or more indications related to the usage of the at least one SW version comprises a selection of one of a plurality of SW versions to use for execution of the mobility command.

38. The wireless device of any one of Claims 32 to 37, wherein performing the at least one action comprises at least one of: adding a SW version; releasing a SW version; modifying a SW version; selecting a SW version; activating a SW function; deactivating a SW function; and selecting one of a plurality of SW versions to use for execution of the mobility command.

39. The wireless device of any one of Claims 32 to 37, wherein the mobility command is at least one of: a Handover command, and a Radio Resource Control Reconfiguration (RRCReconfiguration) message.

40. The wireless device of any one of Claims 32 to 39, wherein the mobility command comprises at least one of: a configuration that is specific for the target cell; a random access configuration; and a physical cell identifier for the target cell.

41. The wireless device of any one of Claims 32 to 40, wherein the mobility command is associated with a conditional handover or a conditional primary secondary cell change from the source cell to the target cell, and wherein the mobility command is applied and/or the actions are performed upon fulfdlment of a condition associated with the conditional handover or the conditional primary secondary cell change.

42. The wireless device of any one of Claims 32 to 41, further adapted to: detect an occurrence of an event triggering performance of the at least one action according to the one or more indications related to the usage of the at least one SW version; and wherein the at least one action is performed in response to detecting the occurrence of the event.

43. The wireless device of Claim 42, wherein detecting the occurrence of the event comprises at least one of: detecting one or more out-of-sync events; detecting one or more beam failure indications (BFIs); determining that a value associated with a measurement is above a maximum threshold; determining that a value associated with a measurement is below a minimum threshold; determining that a battery level of the wireless device is below a threshold amount; determining that an amount of downlink traffic to the wireless device or uplink traffic from the wireless device is greater than a maximum threshold; determining that an amount of downlink traffic to the wireless device or uplink traffic from the wireless device is less than a minimum threshold; and detecting a traffic type, traffic Quality of Service, and/or traffic category at the wireless device.

44. The wireless device of any one of Claims 32 to 43, wherein the wireless device is operating in a connected mode.

45. A target network node (110B) associated with a target cell during a handover of a wireless device (112A) from a source network node (110A) associated with a source cell to the target network node, the target node being adapted to: receive, from the source network node, a handover request message requesting handover of the wireless device to the target network node; transmit, to the source network node, a handover request acknowledgement; and transmit to the source network node: one or more indications related to usage of at least one SW version associated with the target cell, and/or one or more software versions for use by the wireless device in the target cell.

46. The target network node of Claim 45, wherein the handover request message comprises one or more additional indications of at least one SW version stored at the wireless device.

47. The target network node of any one of Claims 45 to 46, wherein the handover request message comprises one or more additional indications of at least one SW version associated with the source cell.

48. The target network node of any one of Claims 45 to 47, wherein the one or more indications related to the usage of the at least one SW version comprises at least one of: an addition of a SW version; a release of a SW version; a modification of a SW version; a selection of a SW version; an activation of a SW function; and a deactivation of a SW function.

49. The target network node of any one of Claims 45 to 48, wherein the one or more indications related to the usage of the at least one SW version comprises a selection of one of a plurality of SW versions to use for execution of a mobility command by the wireless device.

50. The target network node of any one of Claims 45 to 49, wherein the handover comprises a conditional handover or a conditional primary secondary cell change from the source cell to the target cell.

51. The target network node of any one of Claims 45 to 50, wherein the wireless device is operating in a connected mode.

52. A source network node (110A) associated with a source cell during a handover of a wireless device (112A) to target network node (HOB) associated with a target cell, the source network node adapted to: transmit, to the target network node, a handover request message requesting handover of the wireless device to the target network node; receive, from the target network node, a handover request acknowledgement; and receive from the target network node: one or more indications related to usage of at least one SW version associated with the target cell, and/or one or more software versions for use by the wireless device in the target cell; and transmit, to the wireless device, a mobility command and the one or more indications related to the usage of the at least one SW version associated with the target cell.

53. The source network node of Claim 52, wherein the handover request message comprises one or more additional indications of at least one SW version stored at the wireless device.

54. The source network node of any one of Claims 52 to 53, wherein the handover request message comprises one or more additional indications of at least one SW version associated with the source cell.

55. The source network node of any one of Claims 52 to 54, wherein the one or more indications and the mobility command are transmitted to the wireless device in one message.

56. The source network node of any one of Claims 52 to 54, wherein the one or more indications and the mobility command are transmitted to the wireless device in different messages.

57. The source network node of Claim 56, wherein the one or more indications comprise a plurality of indications, and wherein each one of the plurality of indications is associated with a respective one of a plurality of target cells.

58. The source network node of any one of Claims 52 to 57, wherein the one or more indications related to the usage of the at least one SW version comprises at least one of: an addition of a SW version; a release of a SW version; a modification of a SW version; a selection of a SW version; an activation of a SW function; and a deactivation of a SW function.

59. The source network node of any one of Claims 52 to 58, wherein the one or more indications related to the usage of the at least one SW version comprises a selection of one of a plurality of SW versions to use for execution of the mobility command.

60. The source network node of any one of Claims 52 to 59, wherein the mobility command is at least one of: a Handover command, and a Radio Resource Control Reconfiguration (RRCReconfiguration) message.

61. The source network node of any one of Claims 52 to 60, wherein the mobility command comprises at least one of: a configuration that is specific for the target cell; a random access configuration; and a physical cell identifier for the target cell.

62. The source network node d of any one of Claims 52 to 61, wherein the mobility command is associated with a conditional handover or a conditional primary secondary cell change from the source cell to the target cell, and wherein the mobility command is applied and/or the actions are performed upon fulfillment of a condition associated with the conditional handover or the conditional primary secondary cell change.