WO2025214977A1

WO2025214977A1 - Optimization for beam hopping

Info

Publication number: WO2025214977A1
Application number: PCT/EP2025/059511
Authority: WO
Inventors: Chunhui Zhang; Johan Rune; Ignacio Javier PASCUAL PELAYO; Stefan ERIKSSON LÖWENMARK; Yuande TAN; Ioannis Xirouchakis; Zhang Zhang
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2024-04-08
Filing date: 2025-04-07
Publication date: 2025-10-16
Anticipated expiration: 2026-10-08
Also published as: TW202545216A

Abstract

The present disclosure provides a method (600) at a terminal device served by a satellite based mobile network, the satellite based mobile network comprising a network node which is configured to provide a coverage by switching among a plurality of beams, each associated with a respective one of a plurality of cells. The method (600) includes: receiving (S610), from a network node, a first indication whether resources for transmission of data between the terminal device and the network node is to be overlapped in time with the switching of a first one of the plurality of beams associated with a first one of the plurality of cells serving the terminal device; and performing (S620) the receiving and/or transmission of the data between the terminal device and the network node based on the first indication.

Description

OPTIMIZATION FOR BEAM HOPPING

Technical Field

The present disclosure relates to the field of telecommunications, and more particularly, to a terminal device, a network node, and methods therein for optimization for beam hopping.

Background

To benefit from the strong mobile ecosystem and economy of scale, the satellite network based on the terrestrial wireless access technologies including LTE and NR for satellite networks, is being specified in the 3^rd Generation Partnership Project (3GPP) standard.

In 3GPP Release 15, the first release of the 5G system (5GS) was specified. This is a new generation of radio access technology intended to serve use cases such as enhanced mobile broadband (eMBB), ultra-reliable and low latency communication (URLLC) and massive machine type communication (mMTC). 5G includes the New Radio (NR) access stratum interface and the 5G Core Network (5GC). The NR physical and higher layers are reusing parts of the LTE specification, and additional components are introduced when motivated by new use cases.

In Release 15, 3GPP also started the work to prepare NR for operation in a NonTerrestrial Network (NTN). The work was performed within the study item "NR to support Non-Terrestrial Networks" and resulted in TR 38.811. In Release 16 the work to prepare NR for operation in an NTN network continues with the study item "Solutions for NR to support Non-Terrestrial Network" . In parallel the interest to adapt LTE for operation in NTN is growing. As a consequence, 3GPP introduced support for NTN in both LTE and NR in Release 17. After the basic functionality was established, NTN enhancements continued in Release 18 for both LTEand NR.

A satellite radio access network usually includes the following components:

• A satellite that refers to a space-borne platform;

• An earth-based gateway that connects the satellite to a base station or a core network, depending on the choice of architecture;

• Feeder link that refers to the link between a gateway and a satellite; and

• Access link that refers to the link between a satellite and a UE. A satellite network or satellite based mobile network may also be called as nonterrestrial network (NTN). On the other hand, mobile network with base stations on the ground may also be called as terrestrial network (TN) or non-NTN network. A satellite within NTN may be called as NTN node, NTN satellite or simply a satellite.

Depending on the orbit altitude, a satellite may be categorized as low earth orbit (LEO), medium earth orbit (MEO), or geostationary earth orbit (GEO) satellite.

• LEO: typical heights ranging from 250 - 1,500 km, with orbital periods ranging from 90 - 120 minutes.

• MEO: typical heights ranging from 5,000 - 25,000 km, with orbital periods ranging from 3 - 15 hours.

• GEO: height at about 35,786 km, with an orbital period of 24 hours.

The significant orbit height means that satellite systems are characterized by a path loss that is significantly higher than what is expected in terrestrial networks. To overcome the path loss, it is often required that the access and feeder links are operated in line-of-sight conditions, and that the UE is equipped with an antenna offering high beam directivity.

In NTN, the beam hopping is introduced in Rel-19 NTN enhancement. In this feature, the satellite has a total number of beams to cover a certain geographic area but only a certain number of beams can be active simultaneously due to the limited total transmission power. When beam switching occurs using the same hardware, for example, the same antenna elements prepare to beamform the switching-to another beam, there is a beam switching delay associated with it. Such delay cannot be eliminated and therefore causing the potential additional system overhead.

To address or at least partially alleviate some of the above issues, some embodiments of the present disclosure are provided.

According to a first aspect of the present disclosure, a method at a terminal device is provided. The method comprises: receiving, from a network node which is configured to provide a coverage by switching among a plurality of beams, each associated with a respective one of a plurality of cells, a first indication whether resources for transmission of data between the terminal device and the network node is to be overlapped in time with the switching of a first one of the plurality of beams associated with a first one of the plurality of cells serving the terminal device; and performing the transmission of the data between the terminal device and the network node based on the first indication. Some other embodiments of the first aspect are described in the Detailed Description below.

According to a second aspect of the present disclosure, a terminal device is provided. The terminal device comprises: a processor; a memory, having instructions stored thereon, the instructions being executable by the processor whereby the terminal device is operative to: receive, from a network node which is configured to provide a coverage by switching among a plurality of beams, each associated with a respective one of a plurality of cells, a first indication whether it is allowable in a first one of the plurality of cells serving the terminal device for transmission of data in resources overlapped with the switching of a first one of the plurality of beams associated with the first cell; and perform the transmission of the data between the terminal device and the network node based on the first indication. In some embodiments, the instructions, when executed by the processor, cause the terminal device to further perform any of the methods of the first aspect.

According to a third aspect of the present disclosure, a method at a network node is provided. The method comprises: generating a first indication whether resources for transmission of data between the network node and a terminal device being served by a first one of the plurality of cells is to be overlapped in time with the switching of a first one of the plurality of beams associated with the first cell based on a timing of the switching of the first beam relative to the resources; and sending, to the terminal device, the first indication. Some other embodiments of the third aspect are described in the Detailed Description below.

According to a fourth aspect of the present disclosure, a network node is provided. The communication device comprises: a processor; a memory, having instructions stored thereon, the instructions being executable by the processor whereby the network node is operative to: generate a first indication whether resources for transmission of data between the network node and a terminal device being served by a first one of the plurality of cells is to be overlapped in time with the switching of a first one of the plurality of beams associated with the first cell based on a timing of the switching of the first beam relative to the resources; and send, to the terminal device, the first indication. In some embodiments, the instructions, when executed by the processor, cause the communication device to further perform any of the methods of the third aspect.

According to a fifth aspect of the present disclosure, a computer-readable storage medium is provided. The computer-readable storage medium has computer- readable instructions stored thereon. The computer-readable instructions, when executed by a processor of a terminal device, configure the terminal device to perform the method according to the first aspect.

According to a sixth aspect of the present disclosure, a computer program product is provided. The computer program product includes computer-readable instructions which, when executed by a processor of a terminal device, configure the terminal device to perform the method according to the first aspect.

According to a seventh aspect of the present disclosure, a computer-readable storage medium is provided. The computer-readable storage medium has computer- readable instructions stored thereon. The computer-readable instructions, when executed by a processor of a network node, configure the network node to perform the method according to the third aspect.

According to an eighth aspect of the present disclosure, a computer program product is provided. The computer program product includes computer-readable instructions which, when executed by a processor of a network node, configure the network node to perform the method according to the third aspect.

According to some embodiments of the present disclosure, the beam switching may be allowed to occur only during the non-active beam time (beam OFF time). Alternatively, the beam switching may be allowed to occur during the active beam time (beam ON time). When the beam switching delay is short, the beam switching occurrence may be allowed at the beginning of the beam ON period. When the beam switching delay is long, the beam switching occurrence may be allowed at the end of the beam ON period. The UE may be signaled whether it is allowed to drop the symbols impacted by beam switching delay at network, and/or the number of symbols and position of symbols is allowed to drop impacted by beam switching. Such signaling may depend on the duration of the beam switching delay.

According to some embodiment of the present disclosure, whether allowing the beam switching to occur during the active time or non-active time may be signaled to UE when the symbols could be corrupted by the beam switching. With some embodiments of the present disclosure, the system overhead caused by beam switching delay may be optimized or even minimized especially for a full load system. By applying the rules of placing the beam switching during the non-active beam time, the beam data is protected when system is not fully loaded. By applying the rules of placing the beam switching during the active beam time, the system capacity may be enhanced or even maximized depending on the beam switch length.

Brief Description of the Drawings

The foregoing and other features of the present disclosure will become more fully apparent from the following description and appended claims, taken in conjunction with the accompanying drawings. Understanding that these drawings depict only several embodiments in accordance with the disclosure and therefore are not to be considered limiting of its scope, the disclosure will be described with additional specificity and detail through use of the accompanying drawings.

Fig. 1 is a diagram illustrating an exemplary telecommunication system 10 in which system overhead optimization for beam hopping is applicable according to an embodiment of the present disclosure.

Fig. 2 is a diagram illustrating exemplary diurnal Doppler shift of a forward service link observed for a GEO satellite operating from an inclined orbit.

Fig. 3 is a diagram illustrating exemplary orbital elements.

Fig. 4 is a diagram illustrating an exemplary coverage by a satellite.

Fig. 5 is a diagram illustrating exemplary beam hopping.

Fig. 6 is a diagram illustrating a method at a terminal device according to an embodiment of the present disclosure.

Fig. 7 is a diagram illustrating an exemplary beam switch ON/OFF indication per beam according to an embodiment of the present disclosure.

Fig. 8 is a diagram illustrating an exemplary association between beam switch ON/OFF time and satellite local time according to an embodiment of the present disclosure.

Fig. 9 is a diagram illustrating exemplary beam switching ON/OFF time in relation to beam/cell frame time according to an embodiment of the present disclosure.

Fig. 10 is a diagram illustrating exemplary multiplexing in spatial domain of two beams with a guard period containing beam switching delay and symbol boundary alignment between the two beams according to an embodiment of the present disclosure.

Fig. 11 is a diagram illustrating exemplary multiplexing in spatial domain of two beams with a guard period containing beam switching delay and without symbol boundary alignment between the two beams according to an embodiment of the present disclosure.

Fig. 12 is a diagram illustrating exemplary beam switching delay occurrence within beam active/ON time according to an embodiment of the present disclosure.

Fig. 13 is a diagram illustrating a method at a network node according to an embodiment of the present disclosure.

Fig. 14 is a block diagram illustrating a terminal device according to an embodiment of the present disclosure.

Fig. 15 is a block diagram illustrating a network node according to an embodiment of the present disclosure.

Fig. 16 shows an exemplary communication system in accordance with some embodiments.

Fig. 17 shows an exemplary UE in accordance with some embodiments.

Fig. 18 shows an exemplary network node in accordance with some embodiments.

Fig. 19 is a block diagram illustrating an exemplary virtualization environment in which functions implemented by some embodiments may be virtualized.

Fig. 20 is a diagram illustrating an exemplary case where beam switching occurs during a beam OFF period and no data is transmitted during this beam switching.

Fig. 21 is a diagram illustrating an exemplary case where beam switching delay is not impacted for data transmission.

Detailed Description

The term "terminal device" or "UE" refers to any end device that can access a wireless communication network and receive services therefrom. By way of example and not limitation, the terminal device refers to a mobile terminal, user equipment (UE), or other suitable devices. The UE may be, for example, a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT). The terminal device may include, but not limited to, portable computers, desktop computers, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, tablets, personal digital assistants (PDAs), wearable terminal devices, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE), laptopmounted equipment (LME), USB dongles, smart devices, wireless customer-premises equipment (CPE) and the like. In the following description, the terms "terminal device", "terminal", "user equipment" and "UE" may be used interchangeably. As one example, a terminal device may represent a UE configured for communication in accordance with one or more communication standards promulgated by the 3rd Generation Partnership Project (3GPP), such as 3GPP's Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and/or the 5th Generation (5G) standards. As used herein, a "user equipment" or "UE" may not necessarily have a "user" in the sense of a human user who owns and/or operates the relevant device. In some embodiments, a terminal device may be configured to transmit and/or receive information without direct human interaction. For instance, a terminal device may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the wireless communication network. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but that may not initially be associated with a specific human user.

Further, the term "network node" used herein may refer to a network function, a network element, a RAN node, an OAM node, a testing network function, a transmission reception point (TRP), a base station, a base transceiver station, an access point, a hot spot, a NodeB, an Evolved NodeB (eNB), a gNB, a network element, or any other equivalents. Furthermore, please note that the term "indication" used herein may refer to a parameter, a coefficient, an attribute, a property, a setting, a configuration, a profile, an identifier, a field, one or more bits/octets, an information element, or any data by which information of interest may be indicated directly or indirectly.

References in the specification to "one embodiment," "an embodiment," "an example embodiment," and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that although the terms "first" and "second" etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed terms.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises", "comprising", "has", "having", "includes" and/or "including", when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

Two basic architectures can be distinguished for satellite communication networks, depending on the functionality of the satellite in the system:

• Transparent payload (also referred to as bent pipe architecture). The satellite forwards the received signal between the terminal and the network equipment on the ground with only amplification and a shift from uplink frequency to downlink frequency. When applied to general 3GPP architecture and terminology, the transparent payload architecture means that the gNB is located on the ground and the satellite forwards signals/data between the gNB and the UE.

• Regenerative payload. The satellite includes on-board processing to demodulate and decode the received signal and regenerate the signal before sending it back to the earth. When applied to general 3GPP architecture and terminology, the regenerative payload architecture means that the gNB is located in the satellite.

The system 10 as shown in Fig. 1 has an example architecture of a satellite network with bent pipe transponders (i.e., the transparent payload architecture, which is considered in the work item for NR NTN and loT NTN in 3GPP Release 17 and Release 18).

As shown in Fig. 1, a satellite 105 may have a spotbeam 110 to provide services, e.g., access to network, for a terminal device 115, e.g., UE. The terminal device 115 is connectable to the satellite 105 through an access link 120. The satellite 105 is connectable to a base station (BS), e.g., gNB, 125, via a gateway (GW) 130 through a feeder link 135. The based station 125 may be integrated in the gateway 130, or connected to the gateway 130 through a terrestrial connection, e.g., wires, optical fibers, wireless links, or the like. The satellite 105 may be configured to forward signals/data between the terminal device 115 and the base station 125.

Though the system 10 is shown in Fig. 1 as being of the transparent payload architecture, the present disclosure is not limited thereto. The inventive concept disclosed herein is also applicable to different topologies, such as a satellite communication network of the regenerative payload architecture. Hereinafter, we describe embodiments generally on NTN in the context of Internet of Things (loT), but the inventive concept is applicable to NR and any wireless network dominated by line- of-sight conditions.

There are some NTN specific challenges.

Propagation Delay

Propagation delay is an important aspect of satellite communications that is different from the delay expected in a terrestrial mobile system. For a bent pipe satellite network, the round-trip delay may, depending on the orbit height, range from tens of ms in the case of LEO satellites to several hundreds of ms for GEO satellites. As a comparison, the round-trip delays in terrestrial cellular networks are typically below 1 ms.

The distance between the terminal device and the satellite can vary significantly, depending on the position of the satellite and thus the elevation angle E seen by the terminal device. Assuming circular orbits, the minimum distance is realized when the satellite is directly above the terminal device (E = 90°), and the maximum distance when the satellite is at the smallest possible elevation angle. Table 1 shows the distances between satellite and terminal device for different orbital heights and elevation angles together with the one-way propagation delay and the maximum propagation delay difference (the difference from the propagation delay at E = 90°). Note that this table assumes regenerative payload architecture. For the transparent payload case, the propagation delay between gateway and satellite needs to be considered as well, unless the base station corrects for that. Table 1 Propagation delay for different orbital heights and elevation angles The propagation delay may also be highly variable due to the high velocity of the LEO and MEO satellites and change in the order of 10 - 100 ps every second, depending on the orbit altitude and satellite velocity.

Doppler shift

In a LEO NTN, the satellites are moving with a very high velocity. This leads to a Doppler shift of the carrier frequency on the service link of up to 24 ppm for a LEO satellite at 600 km altitude. The Doppler shift is also time variant due to the satellite motion over the sky. The Doppler shift may vary with up to 0.27 ppm/s for a LEO 600 km satellite. The Doppler shift will impact, i.e., increase or decrease, the frequency received on the service link compared to the transmitted frequency. For GEO NTN the satellites may move in an orbit inclined relative to the plane of the equator. The inclination introduces a periodic movement of the satellite relative to the earth which introduces a predictable, and daily periodically repeating Doppler shift of the carrier frequency as exemplified in Fig. 2.

Ephemeris data

In TR 38.821, it has been captured that ephemeris data should be provided to the UE, for example to assist with pointing a directional antenna (or an antenna beam) towards the satellite. A UE knowing its own position, e.g., thanks to GNSS support, may also use the ephemeris data to calculate correct Timing Advance (TA) and Doppler shift. The contents of the ephemeris data and the procedures on how to provide and update such data have not yet been studied in detail.

A satellite orbit can be fully described using six (6) parameters. Exactly which set of parameters is used can be decided by the user; many different representations are possible. For example, a choice of parameters used often in astronomy is the set (a, E, i, Q, co, t). Here, the semi-major axis a and the eccentricity E describe the shape and size of the orbit ellipse; the inclination i, the right ascension of the ascending node Q, and the argument of periapsis co determine its position in space, and the epoch t determines a reference time (e.g. the time when the satellites moves through periapsis). The set of these parameters is illustrated in Fig. 3.

A two-line element set (TLE) is a data format encoding a list of orbital elements of an Earth-orbiting object for a given point in time, the epoch. As an example of a different parametrization, TLEs use mean motion n and mean anomaly M instead of a and t. A completely different set of parameters is the position and velocity vector (x, y, z, v_x, v_y, v_z) of a satellite. These are sometimes called orbital state vectors. They can be derived from the orbital elements and vice versa since the information they contain is equivalent. All these formulations (and many others) are possible choices for the format of ephemeris data to be used in NTN.

It is important that a terminal device can determine the position of a satellite with accuracy of at least a few meters. However, several studies have shown that this might be hard to achieve when using the de-facto standard of TLEs. On the other hand, LEO satellites often have GNSS receivers and can determine their position with some meter level accuracy.

Another aspect discussed during the study item and captured in TR 38.821 is the validity time of ephemeris data. Predictions of satellite positions in general degrade with increasing age of the ephemeris data used, due to atmospheric drag, maneuvering of the satellite, imperfections in the orbital models used, etc. Therefore, the publicly available TLE data are updated quite frequently, for example. The update frequency depends on the satellite and its orbit and ranges from weekly to multiple times a day for satellites on very low orbits which are exposed to strong atmospheric drag and need to perform correctional maneuvers often. So, while it seems possible to provide the satellite position with the required accuracy, care needs to be taken to meet these requirements, e.g., when choosing the ephemeris data format, or the orbital model to be used for the orbital propagation.

Ephemeris data consists of at least 5 parameters describing the shape and position in space of the satellite orbit. It also comes with a timestamp, which is the time when the other parameters describing the orbit ellipse were obtained. The position of the satellite at any given time in the nearer future can be predicted from this data using orbital mechanics. The accuracy of this prediction will however degrade as one projects further and further into the future. The validity time of a certain set of parameters depends on many factors like the type and altitude of the orbit, but also the desired accuracy, and ranges from the scale of a few days to a few years.

Fig. 4 is a diagram illustrating an exemplary coverage by a satellite. For convenience of descriptions, a telecommunication system 40 is shown in Fig. 4 to have a like configuration as the system 10 show in Fig. 1. The system 40 may include, among others, a satellite 405, a terminal device 415, an access link 420, a base station 425, a gateway 430, and a feeder link 435. For details of those components, reference may be made to the descriptions taken in conjunction with Fig. 1.

The satellite 405 may generate several beams over a given area. The footprint of each of those beams is usually in an elliptic shape, which may be considered as a cell. Throughout the present disclosure, we are hereafter using the terms beam and cell interchangeably, unless explicitly noted otherwise. The footprint of a beam is also often referred to as a spotbeam, e.g., Spotbeam 1, Spotbeam 2, Spotbeam 3, or Spotbeam 4 as shown in the figure. The spotbeam may move over the earth surface with the satellite movement, or may be earth fixed with some beam pointing mechanism used by the satellite to compensate for its motion. The spotbeam may have a size depending on the system design, which may range from tens of kilometers to a few thousands of kilometers.

The NTN beam may be, in comparison to beams observed in a terrestrial network, very wide and thus cover an area outside of the area defined by the served cell. Beams covering adjacent cells will overlap and may cause significant levels of intercell interference. To overcome the large levels of interference, a typical approach for the NTN is to configure different cells with different carrier frequencies and polarization modes.

In practice, the satellite 405 may provide a coverage over a certain region on the earth up to certain elevation angle, e.g., 30 degrees, and the number of beam footprints required to cover this region is a function of the beam size. The number of the spotbeams, four (4), shown in Fig. 4 is just illustrative, and there might be more or less spotbeams.

On the other hand, the number of beams that can be illuminated at the satellite payload is subject to such factors as its hardware complexity, the number of RF chains available as well as the total power budget available for sharing across beams. Generally, the actual number of beams illuminated is lower than the total number of beam footprints required to cover the region of interest under one satellite. One potential solution to this issue is to utilize beam time-division multiplexing (also known as beam hopping or switching), where multiple beams across the satellite footprint are time multiplexed to provide a coverage in the corresponding cells on the earth.

Fig. 5 is a diagram illustrating exemplary beam hopping. As shown in Fig. 5, there may be three (3) beam hopping patterns A, B, and C. Please be noted that the paterns can be more or less than three (3). The paterns can be activated in a time multiplexed manner. That is, a first patern may be activated for a first period, and then a second patern may activated for a second period following the first period, and so on, to provide the coverage. Generally, each of the paterns can be activated once for the same time duration per cycle, to provide equal opportunities for terminal devices in different cells of the coverage.

For example, firstly the beam hopping patern A may be activated or turned ON for the first 1/3 of the cycle (while the beam hopping paterns B and C may be deactivated or turned OFF), secondly the beam hopping patern B may be activated or turned ON for the second 1/3 of the cycle (while the beam hopping paterns A and C may be deactivated or turned OFF), and thirdly the beam hopping patern C may be activated or turned ON for the third 1/3 of the cycle (while the beam hopping paterns A and B may be deactivated or turned OFF). Then, the cycle may start over.

It is worth to mention that there may be a delay involved in turning on a specific beam patern while turning off the remaining beam paterns, which is subject to the antenna hardware implementation at the satellite payload.

The beam hopping or switching feature is introduced in Rel-19 NTN enhancement. In this feature, the satellite has a total number of beams to cover a certain geographic area but only a certain number of beams can be active simultaneously due to the limited total transmission power. Therefore, a given satellite needs to activate the different beams in different time and all the beams will operate in TDM (Time division multiplexing) mode. That is, the number of simultaneously ON beams is low compared to the total number of beam footprint. In Table 2 there is an example for the LEO600 system, where the active beam number is 106 whereas the total beam number is 1058.

Table 2 ( { [ | | | | | | | | j

As part of the network energy saving feature, the discontinuous transmission (DTX) pattern is specified with a slot granularity with the related agreement as below.

Agreements

1. A periodic cell DTX/DRX configuration is explicitly signalled to the UEs.

2. A periodic cell DTX/DRX pattern is configured by UE specific Radio Resource Control (RRC) signalling.

3. The Cell DTX/DRX configuration contains at least: periodicity, start slot/offset, on duration.

4. As a baseline Cell DTX/DRX is activated/deactivated implicitly by RRC signalling, i.e. activated immediately once configured by RRC and deactivated once the RRC configuration is released.

For a full load cell/beam, the duty cycle of each beam may be fixed so the terminal device in each cell/beam has an equal opportunity to be served. When beam switching occurs using the same hardware, for example, the same antenna elements prepare to beamform the switching-to another beam, there is a beam switching delay associated with it. Such delay cannot be eliminated and therefore causing the potential additional system overhead.

Fig. 6 is a diagram illustrating a method at a terminal device according to an embodiment of the present disclosure, by which the system overhead can be optimized for beam hopping. As shown in Fig. 6, the method 600 may comprise steps S610 and S620. However, the present disclosure is not limited thereto. In some other embodiments, the method 600 may comprise more steps, less steps, different steps, or any combination thereof. Further the steps of the method 600 may be performed in a different order than that described herein. Further, in some embodiments, a step in the method 600 may be split into multiple sub-steps and performed by different entities, and/or multiple steps in the method 600 may be combined into a single step.

The method 600 may begin with step S610 wherein the terminal device may receive, from a network node, which is configured to provide a coverage by switching among a plurality of beams, each associated with a respective one of a plurality of cells, a first indication whether resources for transmission of data between the terminal device and the network node is to be overlapped in time with the switching of a first one of the plurality of beams associated with a first one of the plurality of cells serving the terminal device.

At step S620, the terminal device may performing the receiving and /or transmission of the data between the terminal device and the network node based on the first indication.

In some embodiments, the terminal device may be a UE, and the network node may be a NTN network node or a satellite. The network node may provide the coverage by switching from one pattern to another pattern (see, e.g., patterns A, B, and C as shown in Fig. 5). The terminal device may be served by a cell, for example, one where the terminal device residents in, or one with an associated beam which provides best radio conditions for the terminal device.

Note, a beam in NTN typically corresponds to a cell, but cells covered by multiple beams are not precluded. Hence, generally, activating or deactivating a beam (i.e. turning a beam ON or OFF) is equivalent to activating or deactivating a cell (i.e. turning a cell ON or OFF).

The first beam associated with the first cell serving the terminal device may be switched, either from ACTIVE to INACTIVE (while switching some other beam(s) from INACTIVE to ACTIVE) or from INACTIVE to ACTIVE (while switching some other beam(s) from ACTIVE to INACTIVE) from time to time. The switching may have an associated switching delay. For example, when the network node switches a beam ACTIVE from INACTIVE status, there may be a delay caused by the hardware preparedness to initiate a new beam. For example, for an analog beam switching system, phase coefficients may need to be set in different antenna element branch so that a new beam direction can be created.

The mechanism of the beam switching time control between satellite and gNB may be implemented as follows.

As the gNB will send control/data signals in each beam when the beam is turned ON, the gNB may control the beam switching ON/OFF time in a synchronized manner in the satellite. Such control may be known by the satellite before the beam data (control/data signals for this beam) arrives at the satellite (so the satellite can prepare the beam switch ON/OFF). One example of such control scheme is that the satellite synchronizes with the gNB and/or gateway as illustrated in Fig. 7.

As shown in Fig. 7, a beam switching control word (ON/OFF) in terms of, e.g., frame number, subframe number, slot number and/or symbol number within one system frame may be signaled from the gNB to the satellite. The satellite may have local time which synchronizes with the gNB/GW (Gateway) and has finer granularity than the beam switching control word granularity indicated with, e.g., system frame number, subframe number, slot number and/or symbol number so that the beam switching inaccuracy caused by satellite local time granularity can be minimal. In a case where there is no need to indicate finer granularity in the beam switching control word, the beam switching control word containing ON/OFF switch time can be indicated with one among those listed below:

• system frame;

• subframe;

• slot;

• symbol;

• absolute time reference (e.g., UTC).

For example, when the granularity of the beam switching ON/OFF time is slot, only system frame number, subframe number and slot number may be contained in the beam switching control word. Because of the satellite and the gNB/GW is synchronized, the satellite may associate the beam switching ON/OFF time with the satellite local time. As shown in Fig. 8, Beam #1 switch-ON time is indicated with system frame number (SFN) N, subframe number M and/or slot number K and the satellite associates the satellite local time T1 to the beam switch-ON time and turns on Beam #1 at satellite local time Tl.

Considering the switching delay, the beam switch-ON time of Tl for Beam #1 implies that the operation of switching Beam #1 from INACTIVE to ACTIVE, e.g., the operation of setting phase coefficients in different antenna element branches to create Beam #1, have already been completed by the time Tl so that Beam #1 is ready for data transmission. That is, the switching delay occurs before the beam switch-ON time of Tl. This is clear for Beam #2 in Fig. 8, where there is a gap between the beam switch-OFF time of Beam #1 and the beam switch-ON time of Beam #2, and the switching delay by, e.g., changing settings of the antenna elements for different beamforming (from Beam #1 to Beam #2), is contained in the gap.

In some embodiments, the beam switch ON/OFF time may be not indicated in terms of 3GPP radio interface structural entities (such as frames, slots and symbols), but rather in terms of structural entities of a protocol transporting the 3GPP data between the network equipment, e.g., gNB or GW, and the satellite, e.g. a frame number, a packet number, or an indication referring to a time in a synchronous low layer protocol in the protocol framework for transporting data between the network equipment, e.g., gNB or GW, and the satellite. Note that these beam switch ON/OFF time indications can still be aligned with frames/slots/ symbols of the 3GPP radio interface, as the 3GPP radio interface frames, slots and symbols are contained in the entities (e.g. frames or packets) of the protocol transporting them between the network equipment, e.g., gNB or GW, and the satellite.

In some embodiments, a beam switch may be indicated in the header (or other control information part) of a frame or packet in a protocol (e.g. the Internet Protocol, IP) transporting data between the network equipment, e.g., gNB or GW, and the satellite. This indication could e.g. indicate which beam the 3GPP data content of the packet or frame and/or in subsequent frames should be sent in. Based on this indication, the satellite may activate the indicated beam for transmission of the data content. As an option, or variation of the embodiment, to allow time for the satellite to activate the indicated beam (if there is a delay associated with the beam activation), the data to be forwarded to the terminal device in the cell may be buffered for a certain time in the satellite. To maintain synchronicity with this option/variation, the satellite may always buffer all data to be forwarded for this specific time, regardless of whether beam activation is required.

In some embodiments, the beam switch ON/OFF time may be indicated relative to the time when the beam switch ON/OFF indication is received by the satellite. In one alternative, the time gap between the time when the indication is received and the time when the beam switch is initiated/completed may be hardcoded in the specification (i.e., the time gap need not to be explicitly informed). In another alternative, the time gap may be explicitly informed to the satellite (either together with or independent of the beam switch ON/OFF time indication). Moreover, the beam switch pattern (i.e., the index of the next beam to be switched on) may also be informed to the satellite, which may be sent either together with or independent of the beam switch ON/OFF time indication. Besides, the gNB may send DL packets to the satellite in a way that the satellite will not receive the packets before switching to the beam which is intended to be used for forwarding the packets to the terminal device.

With the beam switch ON/OFF indication, the network node may perform the beam switching accordingly by taking the switching delay into account. Such beam switching delay occurrence should be carefully designed in relation to cell timing, e.g., timing of ON/OFF periods of data transmission. More specifically, the present disclosure provides some time relation between the occurrence of beam switching time and cell time, e.g., ON/OFF periods of data transmission, associated with each beam, to optimize the system overhead. The network node may signal an indication of the relation, e.g., whether the beam switching occurrence in a beam will be overlapped in time with the resources for data transmission in a cell associated with that beam, to the terminal device, so that the terminal device can properly perform the data transmission with the network node. The network node can know the resources for data transmission, for example by DL scheduling allocation or UL grant from the base station and also the beam switch ON/OFF indication, and thus know the time relation between the beam switching occurrence and the cell timing.

In some embodiments, the beam switching may be configured to occur during the beam OFF time (or, an OFF period of data transmission), to protect beam data integrity. In this way, there is no system overhead impact as there is no signal/data during the beam OFF time. In addition, the cell time between different beams/cells may not be aligned at the boundary of the system frame/subframe/slot boundary of each beam/cell in order to keep the beam switching time as minimal as possible. For example, as shown in Fig. 9, the beam/cell #1 cell time indicated by frame #1 and the beam/cell #2 time indicated by frame #2 is offset with a number (one or more) of frames plus a beam switching delay.

In some embodiments, the configuration or capability of the satellite payload or the NTN payload to execute the beam switch during the OFF time for a specific beam or set of beams is either indicated in terms of 3GPP radio interface structural entities, or other non-3GPP structural entities of a protocol transporting the 3GPP data between a 3GPP network node and the NTN payload or between the NTN ground station and the NTN payload. Similarly, this configuration or capability can be indicated in the header (or other control information part) of a frame or packet in a protocol (e.g., the Internet Protocol, IP) transporting data between the 3GPP network node and the NTN payload or between the NTN ground station and the NTN payload.

In some embodiments, the beam switching delay may be contained in a guard time duration so that the guard period is the integer number of symbol duration which is the minimum of symbol time configured among all the beams/cells in the satellite. The different beams' respective ON periods are separated by this guard period. By doing so, cell time in different beams can be synchronized and the signal/data of different beams can be multiplexed in spatial and/or time domain. This may be needed when beam #1 and beam #2 have the same frequency and are multiplexed also in time domain and this will avoid the inter-symbol interference between the two beams. When the symbol boundary between two beams is aligned, the two beams, or generally, more than two beams with coinciding (or overlapping) ON periods, can share a wider beam and maximize the utilization of a beam transmission time. As shown in Fig. 10, when beam#l and Beam #2 are transmitted in a wider beam, the beam data in both beams can be transmitted within the wide beam ON duration. When the symbol boundary between two beams is not aligned, as shown in Fig. 11, additional time shift between the different beam ON time may be needed to protect the beam data with shorter beam ON time. For example, as shown in Fig. 11, when beam #1 and beam #2 are transmitted with a wide beam, the beam #2 ON time may be shorter than the beam #1 ON time.

In some other embodiments, the beam switching may be configured to occur during the beam ON time (or, an ON period of data transmission). As shown in Fig. 12, the beam switching may be performed in the ON period of Beam #1 (e.g., at end of the ON period) so that Beam #2 can be turned on (immediately) following the ON period of Beam #1, and also in the ON period of Beam #2 (e.g., at end of the ON period) so that Beam #1 can be turned on again (immediately) following the ON period of Beam #2.

Here, in the switching gap, the beam, or the corresponding setting of the antenna elements, is being under change. That is, the beam is actually in a transitional state from ACTIVE to INACTIVE, not a totally ON state. In the figure, the ON period is illustrated to cover this gap to mean that the data transmission, intended to be performed over this beam (that is, the data transmission has allocated resources in the switching gap), continues, though the beam is not as desirable as a totally ON one.

In this case, a part of the beam data may not be protected, i.e. may be lost, because of the beam switching during the active/ON period/time. The beam switching delay may be allowed either at end of one beam ON period or at the beginning of one beam ON period. The placement of the beam switching occurrence may depend on the beam switching delay length, which is to be described in detail hereinafter.

In one embodiment, the beam switching occurrence may be placed at the beginning of the beam ON period when the beam switching delay is relatively small. For example, the beam switch occurrence at the first symbol of first frame of beam ON period/time may be allowed because the cyclic prefix can be used to protect the data integrity. For example, the beam switching delay is 2 microseconds, and for a cyclic prefix of 4.69 microseconds for a subcarrier spacing (SCS) of 15kHz. If the beam switching delay is longer than the cyclic prefix, data may be corrupted and potentially lost.

In another embodiment, the beam switching occurrence may be placed at the end of the beam ON period. When the beam switching delay is relatively large compared to the symbol time, the symbols overlapping with the beam switch time may be corrupted and potentially lost.

In some embodiments, the network node may signal, to the terminal device, an indication to indicate the part of the data which is likely to be impacted by the overlapping of the beam switching occurrence and the transmission resources. The part of the data may be indicated in units of symbols. For example, the number of symbols likely to be corrupted by the beam switching, or indication(s) of the likely corrupted symbols, may be signaled to the terminal device. Another option is that the part of the data, i.e. the likely corrupted/lost/impacted symbols, may be indicated in the system information.

In some embodiments, the indication of the part of the data, e.g., symbols that are fully or partially lost or corrupted, may be indicated for a next beam switching, e.g., a next ACTIVE-to-INACTIVE beam switching, a next INACTIVE-to-ACTIVE beam switching, or both of them. As an option, the indication may cover multiple occurrences of following beam switching, e.g., multiple ACTIVE-to-INACTIVE beam switching occurrences and/or multiple INACTIVE-to-ACTIVE beam switching occurrences into the future.

In some embodiments, the part of the data may be signaled together with an indication of time of its associated switching, e.g., a beam switching schedule or an indication of the time of the next beam ACTIVE-to-INACTIVE transition (i.e. beam inactivation) and/or an indication of the time of the next beam INACTIVE-to-ACTIVE transition (i.e. beam activation).

Such indication(s) of the part (e.g., symbols) of the data may be signaled in a semi-permanent manner in, e.g., the system information. For example, the indication may indicate that symbol N, or symbols N through N+X, in slot 7(and symbol P, or symbols /’through P Y, in slot M+ , in case the impact symbols span across a slot boundary) of every beam switching frame will be impacted, e.g. fully or partially missing and/or corrupted and may (as one option) be ignored/dropped by the terminal device (wherein N, X, M, /’and a integers >0). Such semi-permanent indication(s) may optionally be signaled separately (albeit in the same SIB and SI message) for beam ACTIVE-to-INACTIVE transitions and beam INACTIVE-to-ACTIVE transitions respectively.

In some embodiments, the presence of the impacted part of the data, e.g., the impacted (e.g. fully or partially missing or corrupted) symbols may be signaled in the DCI containing the transmission resource allocation, i.e. the DL scheduling allocation or the UL grant, allocating the transmission resources that overlap with the beam switching gap or beam activation delay. The indication would indicate which symbol(s) of the allocated transmission resource that is/are likely to be impacted.

In some embodiments, a rule may be introduced, e.g., in the specification of in the terminal device by implementation, to allow, or instruct, the terminal device to drop the indicated part of the data, e.g., symbols that are likely to be corrupted/lost due to beam switching. In an alternative, the activation of the rule is configurable by the network node via an explicit or implicit indication provided through broadcast or dedicated signaling. In another alternative, the activation of the rule may be up to the terminal device implementation, where the terminal device determines on its own the detection of the corrupted/lost/impacted symbols.

In some embodiments, the base station, e.g., gNB, may configure different modulation and coding schemes (MCSs) for different parts of the data, to provide more redundancy. For example, the base station may configure a first MCS for the indicated part of the data, while a second MCS, which may be less robust than the first MCS, for another part of the data. The indicated part of the data would be more robust to the impact of the beam switching due to the more robust MCS. Such configuration may be signaled to the terminal device so that the terminal device can perform data transmission with the base station (via the satellite).

For example, the gNB can (attempt to) fully or partially compensate for the potential loss of impacted symbols by using a more robust MCS than otherwise motivated by the radio channel conditions, i.e. an MCS which provides more redundancy, when allocating transmission resources that overlap with a beam switching gap.

In some embodiments, the base station, e.g., gNB, may configure different sets of parameters for different parts of the data, to provide more redundancy. For example, the base station may configure a first set of parameters for the indicated part of the data, while a second set of parameters, different from the first set, for another part of the data. Such configuration may be signaled to the terminal device so that the terminal device can perform data transmission with the base station (via the satellite).

For example, for configured grant, the gNB may configure two sets of modulation order, target code rate and TB size (i.e., mcsAndTBS in ConfiguredGrantConfig , one is used for transmission in resources overlapped with a beam switching gap while the other is used for transmission in resources not overlapped with a beam switching gap.

In some embodiments, the terminal device may skip a transmission occasion overlapped with a beam switching gap if a condition is satisfied. Such a condition may be implemented in the terminal device, or configurable by the network node. For example, the gNB may configure the condition and the network node may signal the condition to the terminal device. For example, when a percentage of the resources in a transmission occasion overlapped with a beam switching gap is greater than a threshold, the transmission occasion may be skipped. The terminal device can know whether a resource in a transmission occasion of the configured grant has overlap with a beam switching gap from, e.g., the system information indicating which symbols are impacted by the beam switching.

In some embodiments, whether there is an overlapping between the beam switching and the data transmission, e.g., whether some part of beam data is allowed to be corrupted by the beam switching (presence of overlapping implies possible corruption), may be indicated to the terminal device via broadcast signaling (e.g., system information) or dedicated MAC or RRC message. For example, for a full load system, if the corrupted beam data is allowed in one cell, then the capability among all beams may be maximized.

In some embodiments, the terminal device may be signaled in broadcast (e.g., SIB) or dedicated signaling (e.g., RRC message) with information on all beams that are served by an NTN payload and an indication of the beam switching pattern of the serving beam and its neighbors. In this way, the terminal device can be aware of which of the beams provided by the NTN payload may suffer from data loss/corru ption due to the switching mechanism, e.g., the overlapping of the switching with the data transmission. Upon identifying that the serving cell experiences beam data loss/corruption, the UE can adopt one of the mitigating mechanisms as described above.

In some embodiments, when a part of beam data will be corrupted by the beam switching according to one or more of the indications or rules as described above, whether that part of beam data will be corrupted further depends on the type or priority of data that is being transmitted. As an example, the terminal device can expect that indicated beam data is not corrupted during a System Synchronization Block (SSB) transmission while dedicated Physical Downlink Shared Channel (PDSCH) may be corrupted.

Fig. 13 is a diagram illustrating a method at a network node according to an embodiment of the present disclosure, by which the system overhead can be optimized for beam hopping.

As shown in Fig. 13, the method 1300 may comprise steps S1310 and S1320. However, the present disclosure is not limited thereto. In some other embodiments, the method 1300 may comprise more steps, less steps, different steps, or any combination thereof. Further the steps of the method 1300 may be performed in a different order than that described herein. Further, in some embodiments, a step in the method 1300 may be split into multiple sub-steps and performed by different entities, and/or multiple steps in the method 1300 may be combined into a single step.

The method 1300 may begin with step S1310 wherein the network node may generate a first indication whether resources for transmission of data between the network node and a terminal device being served by a first one of the plurality of cells is to be overlapped in time with the switching of a first one of the plurality of beams associated with the first cell based on a timing of the switching of the first beam relative to the resources.

At step S1320, the network node may send the indication to the terminal device. As a result, the terminal device can perform any of the above described operations with the knowledge of the indication.

Various ways to generate the indication and to signal the indication to the terminal device have been described above in detail.

The terminal device 1400 may include a transceiver 1410, a processor 1420 and a memory 1430.

The memory 1430 may contain instructions executable by the processor 1420 whereby the terminal device 1400 is operative to perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 6. Particularly, the memory 1430 may contain instructions executable by the processor 1420 whereby the terminal device 1400 is operative to receive, from a network node which is configured to provide a coverage by switching among a plurality of beams, each associated with a respective one of a plurality of cells, a first indication whether it is allowable in a first one of the plurality of cells serving the terminal device for transmission of data in resources overlapped with the switching of a first one of the plurality of beams associated with the first cell, and to perform the transmission of the data between the terminal device and the network node based on the first indication.

Fig. 15 is a block diagram illustrating a network node according to an embodiment of the present disclosure. The network node 1500 may include a transceiver 1510, a processor 1520 and a memory 1530.

The memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 13. Particularly, the memory 1530 may contain instructions executable by the processor 1520 whereby the network node 1500 is operative to generate a first indication whether resources for transmission of data between the network node and a terminal device being served by a first one of the plurality of cells is to be overlapped in time with the switching of a first one of the plurality of beams associated with the first cell based on a timing of the switching of the first beam relative to the resources, and to send, to the terminal device, the first indication.

The present disclosure also provides at least one computer program product in the form of a non-volatile or volatile memory, e.g., a non-transitory computer readable storage medium, an Electrically Erasable Programmable Read-Only Memory (EEPROM), a flash memory and a hard drive. The computer program product includes a computer program. The computer program includes: code/computer readable instructions, which when executed by the processor 1420 causes the terminal device 1400 to perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 6; or code/computer readable instructions, which when executed by the processor 1520 causes the network node 1500 to perform the actions, e.g., of the procedure described earlier in conjunction with Fig. 13.

The computer program product may be configured as a computer program code structured in computer program modules. The computer program modules could essentially perform the actions of the flow illustrated in Fig. 6 or 13.

The processor may be a single CPU (Central Processing Unit), but could also comprise two or more processing units. For example, the processor may include general purpose microprocessors; instruction set processors and/or related chips sets and/or special purpose microprocessors such as Application Specific Integrated Circuits (ASICs). The processor may also comprise board memory for caching purposes. The computer program may be carried in a computer program product connected to the processor. The computer program product may comprise a non-transitory computer readable storage medium on which the computer program is stored. For example, the computer J program product may be a flash memory, a Random Access Memory (RAM), a Read- Only Memory (ROM), or an EEPROM, and the computer program modules described above could in alternative embodiments be distributed on different computer program products in the form of memories.

Fig. 16 shows an example of a communication system 1600 in accordance with some embodiments.

In the example, the communication system 1600 includes a telecommunication network 1602 that includes an access network 1604, such as a radio access network (RAN), and a core network 1606, which includes one or more core network nodes 1608. The access network 1604 includes one or more access network nodes, such as network nodes 1610A and 1610B (one or more of which may be generally referred to as network nodes 1610), or any other similar 3^rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 1602 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 1602 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 1602, including one or more network nodes 1610 and/or core network nodes 1608.

Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective "open" designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an 0- Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the 0-RAN Alliance or comparable technologies. The network nodes 1610 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 1612A, 1612B, 1612C, and 1612D (one or more of which may be generally referred to as UEs 1612) to the core network 1606 over one or more wireless connections.

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 1600 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 1600 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.

The UEs 1612 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 1610 and other communication devices. Similarly, the network nodes 1610 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 1612 and/or with other network nodes or equipment in the telecommunication network 1602 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 1602.

In the depicted example, the core network 1606 connects the network nodes 1610 to one or more host computing systems, such as host 1616. 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 1606 includes one more core network nodes (e.g., core network node 1608) 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 1608. 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 1616 may be under the ownership or control of a service provider other than an operator or provider of the access network 1604 and/or the telecommunication network 1602. The host 1616 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 1600 of Fig. 16 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 1602 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 1602 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1602. For example, the telecommunications network 1602 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)/Massive loT services to yet further UEs.

In some examples, the UEs 1612 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 1604 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1604. 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 1614 communicates with the access network 1604 to facilitate indirect communication between one or more UEs (e.g., UE 1612C and/or 1612D) and network nodes (e.g., network node 1610B). In some examples, the hub 1614 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1614 may be a broadband router enabling access to the core network 1606 for the UEs. As another example, the hub 1614 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 1610, or by executable code, script, process, or other instructions in the hub 1614. As another example, the hub 1614 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 1614 may be a content source. For example, for a UE that is a Virtual Reality (VR) device, display, loudspeaker, or other media delivery device, the hub 1614 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1614 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub 1614 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices. The hub 1614 may have a constant/persistent or intermittent connection to the network node 1610B. The hub 1614 may also allow for a different communication scheme and/or schedule between the hub 1614 and UEs (e.g., UE 1612C and/or 1612D), and between the hub 1614 and the core network 1606. In other examples, the hub 1614 is connected to the core network 1606 and/or one or more UEs via a wired connection. Moreover, the hub 1614 may be configured to connect to a Machine-to- Machine (M2M) service provider over the access network 1604 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1610 while still connected via the hub 1614 via a wired or wireless connection. In some embodiments, the hub 1614 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 1610B. In other embodiments, the hub 1614 may be a nondedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1610B, but which is additionally capable of operating as a communication start and/or end point for certain data channels.

Fig. 17 shows a UE 1700 in accordance with some embodiments. The UE 1700 presents additional details of some embodiments of the UE 1612 of Fig. 16. 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/playback device, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop- embedded equipment (LEE), laptop-mounted equipment (LME), an Augmented Reality (AR) or Virtual Reality (VR) device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded/integrated wireless device, etc. Other examples include any UE identified by the 3^rd 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 1700 includes processing circuitry 1702 that is operatively coupled via a bus 1704 to an input/output interface 1706, a power source 1708, a memory 1710, a communication interface 1712, and/or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Fig. 17. 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 1702 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 1710. The processing circuitry 1702 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 1702 may include multiple central processing units (CPUs).

In the example, the input/output interface 1706 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 1700. 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 1708 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 1708 may further include power circuitry for delivering power from the power source 1708 itself, and/or an external power source, to the various parts of the UE 1700 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 1708. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 1708 to make the power suitable for the respective components of the UE 1700 to which power is supplied.

The memory 1710 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 1710 includes one or more application programs 1714, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1716. The memory 1710 may store, for use by the UE 1700, any of a variety of various operating systems or combinations of operating systems.

The memory 1710 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 1710 may allow the UE 1700 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 1710, which may be or comprise a device-readable storage medium.

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

In the illustrated embodiment, communication functions of the communication interface 1712 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, locationbased 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 1712, 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.

A UE, when in the form of an Internet of Things (loT) device, 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. Nonlimiting 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 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 UE 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 1700 shown in Fig. 17.

As yet another specific example, in an loT scenario, a UE 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.

Fig. 18 shows a network node 1800 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)), O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, 0- CU).

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, distributed units (e.g., in an O-RAN access node) 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 1800 includes a processing circuitry 1802, a memory 1804, a communication interface 1806, and a power source 1808. The network node 1800 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 1800 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 1800 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1804 for different RATs) and some components may be reused (e.g., a same antenna 1810 may be shared by different RATs). The network node 1800 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1800, 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 1800.

The processing circuitry 1802 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 1800 components, such as the memory 1804, to provide network node 1800 functionality.

In some embodiments, the processing circuitry 1802 includes a system on a chip (SOC). In some embodiments, the processing circuitry 1802 includes one or more of radio frequency (RF) transceiver circuitry 1812 and baseband processing circuitry 1814. In some embodiments, the radio frequency (RF) transceiver circuitry 1812 and the baseband processing circuitry 1814 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 1812 and baseband processing circuitry 1814 may be on the same chip or set of chips, boards, or units.

The memory 1804 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 1802. The memory 1804 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 1802 and utilized by the network node 1800. The memory 1804 may be used to store any calculations made by the processing circuitry 1802 and/or any data received via the communication interface 1806. In some embodiments, the processing circuitry 1802 and memory 1804 is integrated.

The communication interface 1806 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 1806 comprises port(s)/terminal(s) 1816 to send and receive data, for example to and from a network over a wired connection. The communication interface 1806 also includes radio front-end circuitry 1818 that may be coupled to, or in certain embodiments a part of, the antenna 1810. Radio front-end circuitry 1818 comprises filters 1820 and amplifiers 1822. The radio front-end circuitry 1818 may be connected to an antenna 1810 and processing circuitry 1802. The radio front-end circuitry may be configured to condition signals communicated between antenna 1810 and processing circuitry 1802. The radio front-end circuitry 1818 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 1818 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1820 and/or amplifiers 1822. The radio signal may then be transmitted via the antenna 1810. Similarly, when receiving data, the antenna 1810 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1818. The digital data may be passed to the processing circuitry 1802. In other embodiments, the communication interface may comprise different components and/or different combinations of components.

In certain alternative embodiments, the network node 1800 does not include separate radio front-end circuitry 1818, instead, the processing circuitry 1802 includes radio front-end circuitry and is connected to the antenna 1810. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1812 is part of the communication interface 1806. In still other embodiments, the communication interface 1806 includes one or more ports or terminals 1816, the radio front-end circuitry 1818, and the RF transceiver circuitry 1812, as part of a radio unit (not shown), and the communication interface 1806 communicates with the baseband processing circuitry 1814, which is part of a digital unit (not shown).

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

The antenna 1810, communication interface 1806, and/or the processing circuitry 1802 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 1810, the communication interface 1806, and/or the processing circuitry 1802 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 1808 provides power to the various components of network node 1800 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 1808 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1800 with power for performing the functionality described herein. For example, the network node 1800 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 1808. As a further example, the power source 1808 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 1800 may include additional components beyond those shown in Fig. 18 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 1800 may include user interface equipment to allow input of information into the network node 1800 and to allow output of information from the network node 1800. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1800. In some embodiments providing a core network node, such as core network node 108 of Fig. 16, some components, such as the radio front-end circuitry 1818 and the RF transceiver circuitry 1812 may be omitted.

Fig. 19 is a block diagram illustrating a virtualization environment 1900 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 1900 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. In some embodiments, the virtualization environment 1900 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host.

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

Hardware 1904 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 1906 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1908a and 1908b (one or more of which may be generally referred to as VMs 1908), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 1906 may present a virtual operating platform that appears like networking hardware to the VMs 1908.

The VMs 1908 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1906. Different embodiments of the instance of a virtual appliance 1902 may be implemented on one or more of VMs 1908, 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 1908 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, nonvirtualized machine. Each of the VMs 1908, and that part of hardware 1904 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 1908 on top of the hardware 1904 and corresponds to the application 1902.

Hardware 1904 may be implemented in a standalone network node with generic or specific components. Hardware 1904 may implement some functions via virtualization. Alternatively, hardware 1904 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 1910, which, among others, oversees lifecycle management of applications 1902. In some embodiments, hardware 1904 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 1912 which may alternatively be used for communication between hardware nodes and radio units.

Although the computing devices described herein (e.g., UEs, network nodes) 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.

In the disclosure, we present our general overview on the SAN RF impact.

In WID[1], the objectives relating to the RF are quoted below:

1. Study and specify if beneficial downlink coverage enhancements targeting support for additional reference satellite payload parameters covering both GSO and NGSO constellations operating in FR1-NTN or FR2-NTN [RANI, RAN 2, RAN4]

• Define additional reference satellite payload parameters assuming power sharing among satellite beams or different satellite beam patterns/size (i.e. wide or narrow) across the satellite footprint, such that satellite beams may not all be simultaneously active or may be active below the nominal EIRP density per satellite beam (see section 6.1.1 in TR 38.821) due to limited power and limited feeder link bandwidth.

• Define the corresponding power sharing assumptions and necessary link level and system level evaluation methodology and relevant KPIs for evaluations of the coverage, to allow for identification of physical channels/signals and system-level aspects that need enhancements and the corresponding needed improvements.

• Study and if needed specify solutions, including link level enhancements for FR1-NTN (e.g. for PDCCH, PDSCH) and/or system level enhancements for FR1-NTN and/or FR2-NTN, allowing dynamic and flexible power sharing between satellite beams or different satellite beam patterns/size (i.e. wide or narrow) across the satellite footprint.

• Notes for this objective: o SSB channel enhancement is not considered o Antenna gain of UE shall be assumed to be -5.5dBi in case of smartphone in FR1-NTN, the UE is assumed to be a full duplex UE, and at least 2Rx are considered at the UE o NGSO to be considered in priority: LEO Set-1 @ 600 km o Rel-18 network energy saving techniques should be considered as baseline in the system level study

For DL coverage enhancement objective, as the network energy saving should be considered as baseline for system study, we think it should be also good to study any RF impact for NTN based on network energy saving feature in Rel-18. In WF[2], it is agreed that

Issue 2-1: RF requirements for Cell DTX

• Agreement: o No need to define RF requirements for cell DTX.

■ Transient period may be needed on the CC when cell DTX is conducted on that CC

• It is not expected to capture it in the TS Issue 3-1: RF requirements for spatial domain techniques

• Agreement: o No need to define RF requirements for spatial domain techniques ■ Transient period may be needed on the CC when spatial domain techniques are conducted on that CC.

• It is not expected to capture it in the TS

Issue 3-2: RF requirements for power domain techniques

• Agreement:

No need to define RF requirements for power domain techniques

Some explanation on the NES feature about RF impact on Cell DTX, spatial and power domain. For Cell DTX RF impact, it is mainly because there is transient time is needed when the beam is switching ON, one RF requirement relating to it is the TDD timing mask. Similar to the TDD ON/OFF power transient requirement, when the beam is turned ON/OFF, there is also a transient period. In NTN objective, this is relating to the beam switching between one beam to another, the PA may not be switched ON/OFF, but the new phase coefficients may needs to be set in hardware if analogy beamforming is used. We think so long this transient period occurs during the beam OFF status, the beam data will not be impacted, this is illustrated in Fig. 20.

Proposal -1: No RF impact due to the Cell TX (e.g The NES Cell DTX

RF conclusion due to Cell DTX can be reused ) assuming the transient time occurs during the beam OFF status.

In latest RANI agreement, there is a beam delay assumption as below[3]

Agreement

For NR NTN Rel-19 DL coverage evaluation, a value of beam steering latency equal to 0 at least if phase array antenna is assumed.

Values different from 0 can be optionally reported

If the digital beam forming is used in beamforming, the beam switching delay may be zero. But for analogy beamforming, there may be additional delay caused by setting the phase coefficient for different antenna elements. So the beam switching delay is not zero for analog beamforming. From our understanding, the beam switching delay will incur the system overhead as there is no data will be transmitted during the beam switching period as illustrated in Fig. 20. It should be fine to the light/medium load system but for a full load system, the time used for beam switching will reduce the system capability. As illustrated in Fig. 21 if the beam data could be transmitted during the beam switching delay, the PHY layer should handle this with it so system capability will not impact as seriously as the case illustrated in Fig. 20. As System capability is a RANI topic, RAN4 could provide any beam switching delay number to RANI if RAN4 think other value than 0 should be considered in RANI evaluation.

Observation 1 The beam switching delay incurs the system overhead for a full load system.

Observation 2 No data transmission during the beam switching time incurs the system overhead for full load system

Proposal -2: RAN 4 can send LS to RANI to notify if beam switching delay has other value than 0.

For NES power and spatial domain feature, there is no such discussion in RANI for NTN till now. As the beam switching in NTN is relating to the switch ON/OFF beam rather tuning the power of power of the beam, therefore, there is no need to consider it in RAN4 for now.

Proposal -3: No need to consider the spatial and power domain in

Rel-18 NES impact on NTN RF for now.

In this contribution, we present our general overview with below proposals and observations:

0 Observation 1 The beam switching delay incurs the system overhead for a full load system.

0 Observation 2 No data transmission during the beam switching time incurs the system overhead for full load system

0 Proposal -1: No RF impact due to the Cell TX (e.g The NES Cell DTX RF conclusion due to Cell DTX can be reused ) assuming the transient time occurs during the beam OFF status.

0 Proposal -2: RAN4 can send LS to RANI to notify if beam switching delay has other value than 0.

0 No need to consider the spatial and power domain in Rel-18 NES impact on NTN RF for now.

References

[1] RP-234078, New WID: Non-Terrestrial Networks (NTN) for NR Phase 3 , Huawei

[2] R4-2314935, WF on NES RF requirements, Huawei

[3] RP-240091, Status report for New WID: Non-Terrestrial Networks (NTN) for NR Phase 3; rapporteur: Thales, CATT The present disclosure is described above with reference to the embodiments thereof. However, those embodiments are provided just for illustrative purpose, rather than limiting the present disclosure. The scope of the disclosure is defined by the attached claims as well as equivalents thereof. Those skilled in the art can make various alternations and modifications without departing from the scope of the disclosure, which all fall into the scope of the disclosure.

Claims

1. A method (600) at a terminal device served by a satellite based mobile network, the satellite based mobile network comprising a network node which is configured to provide a coverage by switching among a plurality of beams, each associated with a respective one of a plurality of cells, the method comprising: receiving (S610), from the network node, a first indication whether resources for transmission of data between the terminal device and the network node is to be overlapped in time with the switching of a first one of the plurality of beams associated with a first one of the plurality of cells serving the terminal device; and performing (S620) the receiving and/or transmission of the data between the terminal device and the network node based on the first indication.

2. The method (600) according to claim 1, wherein the switching comprises: switching the first beam from ACTIVE to INACTIVE while switching a second one of the plurality of beams from INACTIVE to ACTIVE; or switching from the first beam from INACTIVE to ACTIVE while switching a third one of the plurality of beams from ACTIVE to INACTIVE.

3. The method (600) according to any one of claims 1 or 2, further comprising: receiving, from the network node, a second indication to indicate a part of the data which is likely to be impacted by the overlapping of the transmission resources with the switching.

4. The method (600) according to claim 3, wherein the part of the data is indicated in units of symbol.

5. The method (600) according to claim 3 or 4, wherein the second indication is for a next switching of the first beam, or for multiple occurrences of following switching of the first beam.

6. The method (600) according to any one of claims 3 to 5, wherein the part of the data is indicated together with an indication of time of its associated switching.

7. The method (600) according to claim 3 or 4, wherein the part of the data is indicated in a semi-permanent manner for data transmissions overlapped in resources with the switching.

8. The method (600) according to claim 7, wherein the second indication is signaled in system information.

9. The method (600) according to claim 8, wherein the second indication is separate from the first indication.

10. The method (600) according to claim 3 or 4, wherein the second indication is signaled in Downlink Control Information, DCI, containing transmission resource allocation allocating the transmission resources overlapped with the switching, and indicates which part of the allocated transmission resources is likely to be impacted.

11. The method (600) according to any one of claims 3 to 10, wherein the transmission of the data comprises receiving the data from the network node, and the performing (S620) of the receiving and/or transmission comprises: dropping the indicated part of the data.

12. The method (600) according to claim 11, wherein whether or not to perform the dropping is configurable by the network node explicitly or implicitly, or up to the terminal device.

13. The method (600) according to any one of claims 3 to 10, wherein the performing (S620) of the receiving and /or transmission comprises: receiving a configuration where a first Modulation and Coding Scheme, MCS, is used for the indicated part of the data while a second MCS, less robust than the first MCS, for another part of the data.

14. The method (600) according to any one of claims 1 to 10, wherein the performing (S620) of the receiving and /or transmission comprises: receiving a configuration where a first set of parameters is used for the transmission in resources to be overlapped with the switching while a second set of parameters, different from the first set, for the transmission in resources not to be overlapped with the switching.

15. The method (600) according to claim 14, wherein the set of parameters comprises a modulation order, a target code rate, and a Transport Block, TB, size.

16. The method (600) according to any one of claims 1 to 15, wherein the performing (S620) of the receiving and /or transmission comprises: skipping a transmission occasion having resources overlapped with the switching if a condition is satisfied.

17. The method (600) according to claim 16, wherein the condition is that a percentage of the resources in the transmission occasion overlapped with the switching is greater than a threshold.

18. The method (600) according to any one of claims 1 to 17, wherein the first indication is signaled by broadcast signaling, or a dedicated Media Access Control, MAC, or Radio Resource Control, RRC, message.

19. The method (600) according to any one of claims 1 to 17, wherein the receiving (S610) of the first indication comprises: receiving, from the network node, information on the plurality of beams and switching patterns of the first beam and also those of the plurality of beams associated with neighboring cells of the first cell; and identifying the first indication based on the information.

20. A terminal device (1400), comprising: a processor (1420); and a memory (1430), having instructions stored thereon, the instructions being executable by the processor (1420) whereby the terminal device (1400) is operative, when served by a satellite based mobile network comprising a network node which is configured to provide a coverage by switching among a plurality of beams, each associated with a respective one of a plurality of cells, to: receive, from the network node, a first indication whether it is allowable in a first one of the plurality of cells serving the terminal device for transmission of data in resources overlapped with the switching of a first one of the plurality of beams associated with the first cell; and perform the transmission of the data between the terminal device and the network node based on the first indication.

21. The terminal device (1400) according to claim 20, wherein the instructions are executable by the processor (1420) whereby the terminal device (1400) is operative to perform the method according to any one of claims 2 to 19.

22. A method (1300) at a network node in a satellite based mobile network, wherein the network node is configured to provide a coverage by switching among a plurality of beams, each associated with a respective one of a plurality of cells, the method comprising: generating (S1310) a first indication whether resources for transmission of data between the network node and a terminal device being served by a first one of the plurality of cells is to be overlapped in time with the switching of a first one of the plurality of beams associated with the first cell based on a timing of the switching of the first beam relative to the resources; and sending (S1320), to the terminal device, the first indication.

23. The method (1300) according to claim 22, wherein the switching comprises: switching the first beam from ACTIVE to INACTIVE while switching a second one of the plurality of beams from INACTIVE to ACTIVE; or switching from the first beam from INACTIVE to ACTIVE while switching a third one of the plurality of beams from ACTIVE to INACTIVE.

24. The method (1300) according to claim 22 or 23, further comprising: performing the switching of the first beam in an OFF period of the data transmission, wherein the first indication indicates the resources is not to be overlapped with the switching; or performing the switching of the first beam in an ON period of the data transmission, wherein the first indication indicates the resources is to be overlapped with the switching.

25. The method (1300) according to claim 24, wherein the switching is overlapped with either the beginning or the end of the ON period of the data transmission.

26. The method (1300) according to claim 24, further comprising: determining the switching to be overlapped with the beginning of the ON period of the data transmission when the switching has a relatively small delay; or determining the switching to be overlapped with the end of the ON period of the data transmission when the switching has a relatively large delay.

27. The method (1300) according to claim 24, wherein the switching is performed in a guard period, wherein the guard period is an integer times a minimum symbol time configured among the plurality of cells.

28. The method (1300) according to any one of claims 22 to 27, further comprising: sending, to the terminal device, a second indication to indicate a part of the data which is likely to be impacted by the overlapping of the transmission resources with the switching.

29. The method (1300) according to claim 28, wherein the part of the data is indicated in units of symbol and/or wherein the part of the data is indicated in a semipermanent manner for data transmissions overlapped in resources with the switching.

30. The method (1300) according to claim 28 or 29, wherein the second indication is for a next switching of the first beam, or for multiple occurrences of following switching of the first beam.

31. The method (1300) according to any one of claims 28 to 30, wherein the part of the data is indicated together with an indication of time of its associated switching.

32. The method (1300) according to claim 28 or 29, wherein the second indication is signaled in Downlink Control Information, DCI, containing transmission resource allocation allocating the transmission resources overlapped with the switching, and indicates which part of the allocated transmission resources is likely to be impacted.

33. The method (1300) according to any one of claims 28 to 32, further comprising: configuring a rule for the terminal device to drop the indicated part of the data.

34. The method (1300) according to any one of claims 28 to 32, further comprising: configuring a first Modulation and Coding Scheme, MCS, for the indicated part of the data while a second MCS, less robust than the first MCS, for another part of the data.

35. The method (1300) according to any one of claims 22 to 34, further comprising: configuring a first set of parameters for the transmission in resources to be overlapped with the switching while a second set of parameters, different from the first set, for the transmission in resources not to be overlapped with the switching.

36. The method (1300) according to any one of claims 22 to 35, further comprising: configuring a condition for the terminal device to skip a transmission occasion having resources overlapped with the switching and/or wherein the condition is that a percentage of the resources in the transmission occasion overlapped with the switching is greater than a threshold.

37. The method (1300) according to any one of claims 22 to 36, wherein the sending (S1320) of the first indication comprises: sending, to the terminal device, information on the plurality of beams and switching patterns of the first beam and also those of the plurality of beams associated with neighboring cells of the first cell, wherein the first indication is identified based on the information.

38. A network node (1500), comprising: a processor (1520); and a memory (1510), having instructions stored thereon, the instructions being executable by the processor (1520) whereby the network node (1500) is operative to: generate a first indication whether resources for transmission of data between the network node and a terminal device being served by a first one of the plurality of cells is to be overlapped in time with the switching of a first one of the plurality of beams associated with the first cell based on a timing of the switching of the first beam relative to the resources; and send, to the terminal device, the first indication.

39. The network node (1500) according to claim 38, wherein the instructions are executable by the processor (1520) whereby the network node (1500) is operative to perform the method according to any one of claims 23 to 37.

40. A computer program product comprising computer-readable instructions or computer-readable storage medium having computer-readable instructions stored thereon, the computer-readable instructions, when executed by a processor of a terminal device, configure the terminal device to perform the method according to any one of claims 1 to 19 and when executed by a processor of a network node, configure the network node to perform the method according to any one of claims 22 to 37.