Method for SI accumulation in IOT NTN with explicit and implicit epoch time indication

Abstract

Methods, systems, and devices to facilitate accumulation of NTN SIBs are disclosed. For example, a method implemented by a user equipment (UE) for facilitating non-terrestrial system information block (NTN SIB) accumulation, the method comprising: determining whether NTN SIB accumulation should be implemented based on one or more system information (SI) configuration parameters; and performing the NTN SIB accumulation when the UE determines that the NTN SIB accumulation should be performed, or not performing the NTN SIB accumulation when the UE determines that the NTN SIB accumulation should not be performed.

Description

[0001] Cross-references to related information

[0002] This application claims the benefit of U.S. priority application No. 63 / 397,657, filed on August 12, 2022, entitled "METHOD FOR SI ACCUMULATION IN IOTNTN WITH EXPLICIT AND IMPLICIT EPOXYGEN TIME INDICATION." Technical Field

[0003] The present disclosure relates generally to non-terrestrial cellular communication technologies. Background Art

[0004] In 3GPP Release 8, the Evolved Packet System (EPS) was specified. EPS is based on the Long Term Evolution (LTE) radio network and the Evolved Packet Core (EPC). It was originally designed to provide voice and mobile broadband (MBB) services, but has evolved to extend its capabilities. Since 3GPP Release 13, Narrowband Internet of Things (NB-IoT) and LTE Machine Type Communication (LTE-M) have become part of the LTE specifications and provide connectivity for massive Machine Type Communication (mMTC) services.

[0005] In 3GPP Release 15, the first version of the 5G System (5GS) was specified. This is a new generation of radio access technology designed to serve use cases such as enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and mMTC. 5G includes the New Radio (NR) access layer interface and the 5G Core network (5GC). The NR physical layer and higher layers are reusing parts of the LTE specifications and adding required components. One such component is the introduction of a sophisticated framework for beamforming and beam management to extend the support of 3GPP technologies to frequency ranges beyond 6GHz.

[0006] Satellite Communications and Non-terrestrial Networks

[0007] Satellite communications are experiencing a resurgence. Several initiatives for satellite networks have been announced over the past few years. Target services vary, from backhaul and fixed wireless to transportation, to outdoor mobile, to IoT. Satellite networks can complement mobile networks on the ground by providing connectivity to underserved areas as well as multicast / broadcast services.

[0008] In order to benefit from a strong mobile ecosystem and economies of scale, there is a great deal of interest in adapting terrestrial radio access technologies, including LTE and NR, to satellite networks, which has been reflected in 3GPP standardization work. In 3GPP Release 15, 3GPP started work on preparing NR for operation in non-terrestrial networks (NTN). This work was implemented within the study project "Support for NR in non-terrestrial networks" and resulted in 3GPP TR 38.811[1]. In 3GPP Release 16, work on preparing NR for operation in NTN networks continued with the study project "Solutions for NR in support of non-terrestrial networks", which has been documented in 3GPP TR 38.821[2]. At the same time, interest in adapting NB-IoT and LTE-M for operation in NTN is also growing. 3GPP Release 17 contains both a work item on NR NTN[3] and a study item on NB-IoT and LTE-M support for NTN[4].

[0009] characteristic

[0010] Satellite radio access networks typically include the following components:

[0011] ●Refers to the satellite of the spaceborne platform.

[0012] ●Earth-based gateways connecting satellites to base stations or core networks, depending on the choice of architecture.

[0013] • Feeder link refers to the link between the gateway and the satellite.

[0014] • Access link or serving link referring to the link between the satellite and the UE.

[0015] Depending on the altitude of their orbit, satellites can be classified as low earth orbit (LEO), medium earth orbit (MEO) or geostationary earth orbit (GEO) satellites.

[0016] LEO: Typical altitudes range from 250-1500 km, and orbital periods range from 90-120 minutes.

[0017] ●MEO: Typical altitudes range from 5000-25000km, and orbital periods range from 3-15 hours.

[0018] ●GEO: Altitude is about 35786km, and the orbital period is 24 hours.

[0019] Depending on the functionality of the satellites in the system, two basic architectures can be distinguished for satellite communication networks:

[0020] Transparent Payload (also known as bent pipe architecture). The satellite forwards the received signal between the network equipment on the ground and the terminal, and only amplification and transfer from uplink frequency to downlink frequency are performed. When applied to general 3GPP architecture and terminology, transparent payload architecture means that the gNB is located on the ground and the satellite forwards the signal / data between the gNB and the UE.

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

[0022] In the work items for NR NTN in 3GPP Release 17, only the transparent payload architecture is considered.

[0023] Figure 1 An example architecture of a satellite network with bent pipe transponders (i.e., a transparent payload architecture) is shown. The gNB may be integrated in the gateway or may be connected to the gateway via a terrestrial connection (wired, optical fiber, wireless link).

[0024] Communication satellites usually generate several beams over a given area. The footprint of a beam is usually elliptical, which is conventionally regarded as a cell, but the 3GPP work does not exclude cells composed of the coverage areas of multiple beams. The coverage area of ​​a beam is also commonly referred to as a spot beam. The coverage area of ​​a beam can move on the surface of the earth as the satellite moves, or it can be fixed on the earth using a beam pointing mechanism used by the satellite to compensate for the movement of the satellite. The size of the spot beam depends on the system design, and its range may range from tens of kilometers to thousands of kilometers.

[0025] Consequences of long propagation delay / RTT and high satellite speeds

[0026] Propagation delay is an important aspect of satellite communications that differs from the delays expected in terrestrial mobile systems. For bent-pipe satellite networks, the round-trip delay can vary from tens of milliseconds in the case of LEO satellites to hundreds of milliseconds for GEO satellites, depending on the orbital altitude. For comparison, the round-trip delay in terrestrial cellular networks is typically less than 1 millisecond.

[0027] The distance between the UE and the satellite may vary greatly, depending on the position of the satellite and thus on the elevation angle ε seen by the UE. Assuming a circular orbit, the minimum distance is achieved when the satellite is directly above the UE (ε = 90°) and the maximum distance is achieved when the satellite is at the smallest possible elevation angle. Table 1 shows the distance between the satellite and the UE for different orbit altitudes and elevation angles, as well as the one-way propagation delay and the maximum propagation delay difference (the difference from the propagation delay when ε = 90°). Note that this table assumes a regenerative payload architecture. For the case of a transparent payload, the propagation delay between the gateway and the satellite also needs to be taken into account, unless the base station corrects for this.

[0028] Table 1: Propagation delays for different orbit altitudes and elevation angles.

[0029]

[0030] Due to the high speed of LEO and MEO satellites, propagation delays can also vary greatly, on the order of 10-100 μs per second depending on orbital altitude and satellite speed.

[0031] For non-terrestrial networks using 3GPP technologies (particularly 5G / NR), the long propagation delay means that the timing advance (TA) used by the UE for its uplink transmission is essential and must be much larger than in terrestrial networks so that the uplink and downlink are time-aligned at the gNB, as is the case in NR and LTE. One of the purposes of the random access (RA) procedure is to provide the UE with a valid TA (which the network may later adjust based on the reception timing of the uplink transmission from the UE). However, even the Random Access Preamble (i.e., the initial message from the UE in the Random Access procedure) has to be sent with a timing advance to allow a reasonable size of the RA preamble reception window in the gNB (and to ensure that the cyclic shift of the Zadoff-Chu sequence of the preamble is not so large that the Zadoff-Chu sequence (and thus the preamble) behaves like another Zadoff-Chu sequence (and thus another preamble) based on the same Zadoff-Chu root sequence, but this TA is not necessarily as accurate as the TA that the UE subsequently uses for other uplink transmissions. The TA that the UE uses for RA preamble transmission in the NTN is called the “pre-compensated TA”).

[0032] Various proposals were considered on how to determine the pre-compensated TA, all of which involved information originating from both the gNB and the UE. In short, the alternative proposals discussed included:

[0033] (1) Broadcast a "common TA" that is valid at a specific reference point (e.g., the center point in a cell). The UE will then calculate how its own pre-compensated TA deviates from the common TA based on the difference between its own position and the reference point and the positions of the satellites. Here, the UE uses GNSS measurements to obtain its own position, and the UE uses satellite orbit data (including satellite positions at a specific time) broadcast by the network to obtain satellite positions.

[0034] (2) Based on the respective positions of the UE and the satellite, the UE autonomously calculates the propagation delay between the UE and the satellite, and the network / gNB broadcasts the propagation delay on the feeder link, i.e., the propagation delay between the gNB and the satellite. Here, the UE uses GNSS measurements to obtain its own position, and the UE uses the satellite orbit data (including the satellite position at a specific time) broadcast by the network to obtain the satellite position. The pre-compensated TA is then twice the sum of the propagation delay on the feeder link and the propagation delay between the satellite and the UE.

[0035] (3) The gNB broadcasts a timestamp (in SIB9), which the UE compares with the reference timestamp obtained from the GNSS. Based on the difference between these two timestamps, the UE can calculate the propagation delay between the gNB and the UE, and pre-compensate the TA to be twice as long as this propagation delay.

[0036] In conjunction with the Random Access procedure, based on the time of reception of the Random Access Preamble, the gNB provides the UE with an accurate (i.e. fine-tuned) TA in the Random Access Response message (in a 4-step RA) or MsgB (in a 2-step RA). The gNB may subsequently adjust the UE's TA using a Timing Advance Command MAC CE (or Absolute Timing Advance Command MAC CE) based on the timing of reception of uplink transmissions from the UE. The goal of such network control of the UE's timing advance is typically to keep the timing error of the UE's uplink transmissions at the gNB's receiver within the cyclic prefix (which is required for correct decoding of the uplink transmissions). The timing advance control framework also includes a time alignment timer configured by the gNB for the UE. Each time the gNB adjusts the UE's TA, the time alignment timer is restarted, and if the time alignment timer expires, the UE is not allowed to transmit in the uplink without a prior Random Access procedure (the purpose of which is to provide the UE with a valid timing advance). For NTN, 3GPP also agreed that, in addition to the gNB’s control of the UE’s TA, the UE is allowed to autonomously update its TA based on an estimate of the change in UE-gNB RTT, using the UE’s location (e.g., obtained from Global Navigation Satellite System (GNSS) measurements) and knowledge of the feeder link delay information from the gNB and the ephemeris data of the serving satellite.

[0037] A second relevant aspect is that not only is the propagation delay between UE and satellite or between UE and gNB long in NTNs, but due to the large distances, even when the satellites / gNBs serve neighboring cells, the difference in propagation delays to two different satellites or two different gNBs can be large on time scales relevant for cellular communications, including signaling procedures. This has an impact on all procedures involving reception or transmission in two cells served by different satellites and / or different gNBs.

[0038] The third important aspect related to long propagation delay / RTT in non-terrestrial networks is the introduction of additional parameters to compensate for the long propagation delay / RTT. In terrestrial cellular networks, the UE-gNB RTT can vary from more or less zero to tens of microseconds in a cell. Besides the larger magnitude of the propagation delay / RTT, a major difference in non-terrestrial networks is that even at the location in the cell where the propagation delay / RTT is smallest, it will be large and will not be close to zero. In fact, the variation of the propagation delay / RTT within an NTN cell is small compared to the propagation delay / RTT. This facilitates the introduction of an offset, which is basically responsible for the RTT between the cell’s coverage area on the ground and the satellite, while other mechanisms, including signaling and control loops, are responsible for RTT-related aspects above this offset within the smaller RTT variation within the cell. For this purpose, 3GPP has agreed to introduce such a parameter, which is called K offset (or sometimes called K_offset).

[0039] K offset The parameter can potentially be used for various timing related mechanisms, but the application of primary interest is its use in uplink transmission scheduling on PUSCH. offset is used to indicate the additional delay between the UL grant and the PUSCH transmission resources allocated by the UL grant, so as to be added to the slot offset parameter K2 in the DCI containing the UL grant. Therefore, the offset between the UL grant and the slot in which the PUSCH transmission resources are allocated is K offset +K2. When used in this way in uplink scheduling, K offset It can be said to be used to ensure that the UE is never scheduled to transmit at a time point that occurs before the time point when the UE receives the UL grant because the UE must apply a larger TA. In 3GPP, it is also discussed to make the network's K offset The configuration takes into account the TA that the UE may have signaled that it has used.

[0040] A fourth important aspect closely related to timing is the Doppler frequency shift caused by satellite motion. In the frequency bands below 6 GHz, the access link may be affected by Doppler frequency shifts of the order of 10-100 kHz, and in higher frequency bands correspondingly higher Doppler frequency shifts. Furthermore, the Doppler frequency shift varies, with rates of up to a few hundred hertz per second in the S-band and a few thousand hertz per second in the Ka-band.

[0041] Ephemeris data

[0042] In TR 38.821 [2], it has been documented that ephemeris data should be provided to the UE, for example to assist in pointing a directional antenna (or antenna beam) towards a satellite and to calculate the correct timing advance (TA) and Doppler shift. However, the process of how to provide and update ephemeris data has not been studied in detail, but broadcasting ephemeris data in system information is an option.

[0043] A satellite orbit can be fully described by six parameters. The user can decide exactly which set of parameters to choose; many different representations are possible. For example, a common choice of parameters in astronomy is the set (α, ε, i, Ω, ω, t). Here, the semi-major axis α and the eccentricity ε describe the shape and size of the orbital ellipse; the inclination i, the right ascension Ω of the ascending node, and the argument ω of the periapsis determine its position in space, and the epoch t determines the reference time (e.g., the time it takes the satellite to move through the periapsis). This parameter set is like Figure 2 shown.

[0044] As an example of a different parameterization, TLE uses the mean motion n and the mean anomaly M instead of a and t. A completely different set of parameters are the position and velocity vectors (x, y, z, v x ,v y ,v z ). These are sometimes called orbital state vectors. They can be derived from orbital elements and vice versa because the information they contain is equivalent. All of these formulas (and many others) are possible choices for the ephemeris data format used in NTN. In order to achieve further progress, agreement on the data format should be reached.

[0045] It is important that the UE is able to determine the position of the satellite with an accuracy of at least a few meters. However, some studies have shown that this may be difficult to achieve when using the de facto standard of TLE. On the other hand, LEO satellites usually have GNSS receivers and can determine their position with some meter-level accuracy.

[0046] Another aspect discussed during the study project and documented in 3GPP TR 38.821 [2] is the validity period of the ephemeris data. Due to atmospheric drag, maneuvers of the satellite, imperfections in the orbital model used, etc., the prediction of the satellite position generally degrades as the age of the ephemeris data used increases. Therefore, for example, publicly available TLE data are updated quite frequently. The frequency of updates depends on the satellite and its orbit and can range from once a week to several times a day for satellites in very low orbits (which are affected by strong atmospheric drag and require frequent correction maneuvers).

[0047] Therefore, while it seems possible to provide satellite positions with the required accuracy, care needs to be taken to meet these requirements, for example, when choosing the ephemeris data format or the orbit model used for orbit propagation.

[0048] Some achievements of NTN's 3GPP research projects

[0049] Since the results of the study items in 3GPP [1][2] lay the foundation for the specification work of non-terrestrial networks in 3GPP, it is relevant to the background information of the present invention. The following includes some relevant information from the study items and the resulting technical reports [1][2]:

[0050] The second study project TR (3GPP TR 38.821[2]) describes the scenarios for NTN operation as follows:

[0051] Non-terrestrial networks are typically characterized by the following elements[3]:

[0052] -One or more satellite gateways that connect non-terrestrial networks to the public data network

[0053] -GEO satellites are fed by one or more satellite gateways, which are deployed across the satellite's target coverage (e.g., regional coverage or even continental coverage). We assume that a UE in a cell is served by only one satellite gateway

[0054] -Non-GEO satellites are continuously served by one satellite gateway at a time. The system ensures service and feeder link continuity between continuously serving satellite gateways with sufficient time periods for mobility anchoring and handover

[0055] Four scenarios are considered as shown in Table 4.2-1, see Table 4.2-2 for details [3].

[0056] Table 4.2-1: Reference scenarios[3]

[0057] Transparent Satellite Regenerative satellite GEO-based non-terrestrial access network Scenario A Scenario B LEO-based non-terrestrial access network Scenario C Scenario D

[0058] Table 4.2-2: Reference scenario parameters [3]

[0059]

[0060]

[0061] Note 1: Each satellite has the capability to steer a beam towards a fixed point on Earth using beamforming techniques. This applies for a period of time corresponding to the satellite's visibility time.

[0062] Note 2: The maximum delay variation within a beam (Earth-fixed UE) is calculated based on the minimum elevation angle for both the gateway and the UE.

[0063] Note 3: The maximum differential delay within a beam is calculated based on the maximum beam footprint diameter at the nadir.

[0064] For scenario D, which is LEO with regenerative payload, both earth-fixed beams and earth-moving beams are listed. Therefore, we have additional scenarios when we consider fixed / non-fixed beams. The full list of the 5 scenarios in 3GPP TR 38.821 [2] is as follows:

[0065] ●Scenario A-GEO, transparent satellite, earth fixed beam;

[0066] ●Scenario B-GEO, regenerative satellite, earth fixed beam;

[0067] ●Scenario C-LEO, transparent satellite, earth mobile beam;

[0068] ●Scenario D1-LEO, regenerative satellite, earth fixed beam;

[0069] ●Scenario D2-LEO, regenerative satellite, earth moving beam.

[0070] IoT NTN SI Window

[0071] Figure 3 The NB-IoT system information block (SIB) Type-x (SIBxNB) transmission and the related parameter ranges for the repetition mode within the system information (SI) window, the duration of the SI window, and the period of the SI window are shown. The same repetition mode is used for all SI messages. Assuming a maximum SI window length of 160 frames (i.e. 1600ms) and a repetition mode of repeating the SIB in every other frame, the network can configure up to 80 repetitions within the SI window.

[0072] Similarly, for LTE-M, the possible SI window period is {8, 16, 32, 64, 128, 256, 512} frames, and the possible S1 window length is {1, 2, 5, 10, 15, 20, 40, 60, 80, 120, 160, 200} ms. Similar to NB-IoT, the SI message in LTE-M can be repeated within its corresponding SI window to support operation within extended coverage. In the entire SI window, the possible repetition pattern is {every frame, every second frame, every fourth frame, and every eighth frame}. All SI messages have the same repetition pattern.

[0073] Rel-17 NR NTN RAN1 Protocol

[0074] We share some key 3GPP RAN1 protocols from Rel-17 NR NTN WI. Rel-17 IoT NTN WI inherits the same protocols in principle. These are related to satellite ephemeris / common TA broadcast and acquisition, for example, to maintain uplink synchronization.

[0075] protocol

[0076] The common TA epoch time is implicitly referred to as the reference time defined by the start time of the DL slot and / or frame.

[0077] FFS: Is the start time given by a predefined rule or indicated by the network?

[0078] Note: "Implicitly referred to" means that no UTC is provided to define a common TA epoch time.

[0079] protocol

[0080] If new or additional assistance information (ie serving satellite ephemeris data or common TA parameters) is not available within the associated validity duration, the UE assumes that it has lost uplink synchronization.

[0081] protocol

[0082] The serving satellite ephemeris and common TA-related parameters are signaled in the same SIB message and have the same epoch time.

[0083] protocol

[0084] A single validity duration for both serving satellite ephemeris and common TA-related parameters is broadcasted on the SIB.

[0085] protocol

[0086] Confirm the working assumptions made in RAN1#106-bis-e regarding the allocation of serving satellite ephemeris bits for LEO / MEO / GEO based non-terrestrial access networks:

[0087] ●Support service satellite ephemeris format bit allocation for non-terrestrial access networks based on LEO / MEO / GEO:

[0088] ○ Position and velocity state vector ephemeris format is a 17 byte payload.

[0089] ■ The field size for position (m) is 78 bits

[0090] ●Location range driven by GEO: + / -42 200km

[0091] ●For position, the quantization step is 1.3m

[0092] ■ The field size for speed (m / s) is 54 bits

[0093] ●Speed ​​range driven by LEO@600km: + / -8000m / s

[0094] ●For speed, the quantization step is 0.06m / s

[0095] ○ Orbital parameter ephemeris format 18 bytes payload

[0096] ■The semi-major axis α(m) is 33 bits

[0097] ●Range: [6500, 43000]km

[0098] ■Eccentricity e is 19 bits

[0099] ●Range: ≤0.015

[0100] ■The argument of periapsis ω (radians) is 24 bits

[0101] ●Range: [0, 2π]

[0102] ■The longitude of the ascending node (Ω radians) is 21 bits

[0103] ●Range: [0, 2π]

[0104] ■The inclination angle i (radians) is 20 bits

[0105] ●Range: [-π / 2, +π / 2]

[0106] ■The mean anomaly M (radians) at epoch time to is 24 bits

[0107] ●Range: [0, 2π]

[0108] protocol

[0109] When explicitly provided through the SIB, the epoch time of the assistance information (ie, serving satellite ephemeris and common TA parameters) is the start time of the DL subframe, indicated by the subframe number and SFN signaled together with the assistance information.

[0110] Otherwise, when indicated in a SIB (except SIB1), the epoch time of the assistance information (ie, serving satellite ephemeris and common TA parameters) is implicitly referred to as the end of the SI window (during which SI messages are sent).

[0111] When provided by dedicated signaling, the epoch time of the assistance information (ie, serving satellite ephemeris and common TA parameters) is the start time of the DL subframe, indicated by the SFN and subframe number.

[0112] protocol

[0113] Modify the second item about epoch time in RAN1#107-e protocol as follows:

[0114] Otherwise, when in SIB When the epoch time is not explicitly indicated in the IEEE 802.11 protocol, the epoch time of the assistance information (i.e., serving satellite ephemeris and common TA parameters) is implicitly referred to as the end of the SI window (during which NTN-specific SIBSI messages are sent).

[0115] protocol

[0116] An additional NTN validity duration value of 900 seconds is added for GEO. X = 4 bits.

[0117] agreement

[0118] The bit allocation for the orbital parameter ephemeris format is modified as follows:

[0119] ●Indicates track parameters in the 21-byte payload:

[0120] ■The semi-major axis α(m) is 33 bits

[0121] ●Range: from 6500km to 43000km

[0122] ●The quantization step size is 4.249×10 -3 m

[0123] ■Eccentricity e is 20 bits

[0124] ●Range: ≤0.015

[0125] ●The quantization step size is 1.431×10 -8

[0126] ■The argument of periapsis ω (radians) is 28 bits

[0127] ●Range: from 0 to 2π

[0128] ●The quantization step size is 2.341×10 -8 radian

[0129] ■The longitude of the ascending node (Ω radians) is 28 bits

[0130] ●Range: from 0 to 2π

[0131] ●The quantization step size is 2.341×10 -8 radian

[0132] ■The inclination angle i (radians) is 27 bits

[0133] ●Range: from -π / 2 to +π / 2

[0134] ●The quantization step size is 2.341×10 -8 radian

[0135] ■The mean anomaly M (radians) at epoch time to is 28 bits

[0136] ●Range: from 0 to 2π

[0137] ●The quantization step size is 2.341×10 -8 radian

[0138] in conclusion

[0139] It is confirmed that the agreed position and velocity state vector ephemeris format used for LEO / MEO / GEO can also be used for HAPS / ATG.

[0140] NTN SIB protocol in Rel-17 IoT NTN WI

[0141] IoT NTN introduces two NTN-specific SIBs.

[0142] The first SIB contains information elements required for synchronization with the cell, such as ephemeris information, common TA parameters, uplink synchronization validity timer duration, epoch time for assistance information. Some of the protocols of NTN SIB include.

[0143] RAN2#116-e:

[0144] • Serving cell ephemeris information (used for L1 pre-compensation) is signaled in a new SIB (which is NTN specific).

[0145] ● The update of the serving cell ephemeris information will not affect the system information value tag, nor will it trigger the system information modification process. How to trigger the re-reading of this information is FFS. FFS: Whether the UE should re-acquire the new SIB when the SI update is triggered.

[0146] • Broadcasting timing information about when the serving cell will stop serving the area in the same SIB as the ephemeris information.

[0147] RAN2#116bis-e:

[0148] • TA common parameters, UL synchronization validity duration and ephemeris epoch time are signaled in the NTN specific SIB (SIBXX).

[0149] • K_offset and K_mac parameters are signaled in the NTN-specific SIB (SIBXX).

[0150] ● The UE acquires the NTN-specific SIB before accessing the cell.

[0151] RAN2#117-e:

[0152] ● SIBXX is a necessary SIB, ie if the UE cannot obtain the SIB when being scheduled, it should consider the cell to be barred.

[0153] • The UE shall acquire the NTN-specific SIB before accessing a cell regardless of the state of the UL synchronization validity timer.

[0154] ● FFS: Will we have a protection timer to handle the case where the UE "takes forever" to reacquire the SIB. On expiration of the timer, the UE triggers the RLF process. (Note that it is expected that the timer will not expire in normal cases and the UE can revert to a previous decision).

[0155] • For simplicity, the entire SIBXX structure is included in the RRC reconfiguration message for handover.

[0156] ● Introduce a guard timer TXXXX for acquiring SIBXX in connected mode. On expiration of TXXX, UE triggers RLF (if it can be shown in Q2 that UE will relax RLM when UE tunes away, then skipping this timer can be discussed)

[0157] ●In addition to the 2-bit LSB EARFCN in the NB-IoT MIB (eMTC-Omni-directional FFS), a presence indicator is introduced

[0158] • When the timer expires (or the UE tunes away), the UE stops all UL transmissions, flushes all HARQ buffers and maintains all UL resources.

[0159] ●Maintain the UL synchronization validity timer in RRC.

[0160] ● Modified Proposal 4: SIBXX acquisition is documented in 5.2.2. The UE action when ul-SyncValidityTimer expires is described in a new section in 5.3.3, which will refer to 5.2.2 for SIBXX (re)acquisition

[0161] ●SIBXX is included outside of mobileControlInfo, similar to other private SIBs.

[0162] In the latest CR[8], the following provisions have been made:

[0163] 2.1.4.1SystemInformationBlockType31

[0164] IE SystemInformationBlockType31 contains satellite assistance information for the serving cell.

[0165] SystemInformationBlockType31 Information Elements

[0166]

[0167]

[0168] A second SIB has been introduced to broadcast the information needed to handle non-continuous coverage scenarios in IoT NTNs, for example, it includes an information element containing the satellite ephemeris of neighboring and upcoming satellites so that the UE knows when to wake up to receive coverage. This is useful in scenarios such as low-density or sparse LEO constellations, where the number of satellites in the constellation is not enough to cover the entire Earth at a given time.

[0169] Some related agreements:

[0170] • RAN2 will use new SIB to share ephemeris information for non-contiguous coverage with UE. Sharing information using dedicated RRC signaling is FFS.

[0171] For non-contiguous coverage, a new SIB can be used to share ephemeris information for up to a maximum number of X satellites, where X is limited by the capacity of the SIB versus the amount of information (X=4 is a baseline). This maximum number is increased by using dedicated RRC signaling and by any further ephemeris optimizations are FFS.

[0172] Epoch time indication

[0173] In the case of explicit epoch time indication, the epoch time is included in the NTN SIB. Therefore, as long as the epoch time remains unchanged (in addition to the common TA parameters, the ephemeris and validity timer also remain unchanged), the content of the NTN SIB remains unchanged. In one example, the epoch time can indicate up to 5.12 seconds in the past or future (can indicate epoch times in both the past and the future), or up to 10.24 seconds in the future or past (can indicate only epoch times in the past or only epoch times in the future). Since the NTN SIB is a necessary SIB, it is expected to be sent with a shorter SI period, for example, at least once per second. This means that there are a large number of SI windows within the validity timer duration for both LEO and GEO (as shown in Tables 2 and 3). However, due to the explicit epoch time indication, there is an additional restriction of 5.12 seconds (or 10.24 seconds) on the SI accumulation duration.

[0174] For explicit epoch time indication, the epoch time indication range essentially limits the SIB accumulation to a shorter SI period of at most 64 frames without introducing additional signaling. Summary of the invention

[0175] The present disclosure includes the following general embodiments, and encompasses combinations of the following features.

[0176] General Group Embodiment

[0177] G1. A method implemented by a user equipment or a network node for facilitating NTN SIB accumulation in an NTN to allow operation under coverage-limited conditions and to avoid decoding errors when the NTN SIB content changes frequently for one or both of implicit and explicit epoch time indications, the method comprising:

[0178] Any one of the above steps, features or functions of the user equipment or network node, alone or in combination with the other steps, features or functions mentioned above.

[0179] G2. The method according to the aforementioned embodiment further includes: one or more of the above-mentioned additional user equipment steps, features or functions.

[0180] G3. The method according to any one of the preceding embodiments, further comprising:

[0181] Provide user data; and

[0182] The user data is forwarded to a host computer via transmission to the network node.

[0183] G4. A user equipment of a network node having hardware, wherein the hardware is configured to facilitate NTN SIB accumulation in an NTN by implementing any of the above user equipment or network node steps, features or functions alone or in combination with the above other steps, features or functions to allow operation under coverage-limited conditions and to avoid decoding errors when the NTNSIB content changes frequently for both implicit and explicit epoch time indications.

[0184] Group A Embodiment

[0185] A1. A method implemented by a user equipment (UE) for facilitating NTN SIB accumulation, the method comprising:

[0186] determining whether NTN SIB accumulation should be performed based on one or more SI configuration parameters; and

[0187] When the UE determines that NTN SIB accumulation should be implemented, implement NTN SIB accumulation; or

[0188] When the UE determines that NTN SIB accumulation should not be performed, NTN SIB accumulation is not performed.

[0189] A2. The method according to embodiment A1 further comprises the following steps:

[0190] Determining whether the network has not explicitly indicated whether NTN SIB accumulation should be performed;

[0191] Thereafter, based on one or more SI configuration parameters, it is determined whether NTN SIB accumulation should be implemented.

[0192] A3. A method according to any of the preceding embodiments, wherein the one or more SI configuration parameters include an SI period value.

[0193] A4. A method according to any of the preceding embodiments, wherein the one or more SI configuration parameters include an epoch timer indication range and / or the number of SI windows.

[0194] A5. The method of embodiment A1 or A2, wherein the UE determines whether the network is using explicit or implicit epoch time indication based on one of the following:

[0195] Instructions in SI, except NTN SIB;

[0196] Assumptions about explicit epoch times in the absence of indications of implicit epoch times;

[0197] In the absence of an indication of an explicit epoch time, an assumption of an implicit epoch time; or

[0198] Inference based on parameters signaled in SI.

[0199] A6. The method of embodiment A1 or A2, wherein the one or more parameters include a validity timer update.

[0200] A7. The method of embodiment A1 or A2, wherein determining based on the one or more parameters comprises determining whether NTN SIB accumulation should be performed based on the lack or one or more parameters.

[0201] A8. The method according to any one of the preceding embodiments, further comprising:

[0202] Provide user data; and

[0203] The user data is forwarded to the host via transmission to a network node.

[0204] A9. A method implemented by a user equipment (UE) for facilitating NTN SIB accumulation, the method comprising:

[0205] In the absence of an indication from the network to perform NTN SIB accumulation, determining that NTN SIB accumulation should be performed; and

[0206] When the UE determines that NTN SIB accumulation should be performed, NTN SIB accumulation is performed.

[0207] A10. The method according to embodiment A9 further includes: decoding the NTN SIB.

[0208] A11. The method of embodiment A10, wherein decoding the NTN SIB comprises:

[0209] attempting to decode the NTN SIB;

[0210] If the attempt to decode the NTN is successful, the NTN SIB is stored, and an additional NTN SIB is received and stored in the next SI transmission.

[0211] The first NTN SIB is stored, and the second NTN SIB in the next SI transmission is received and stored.

[0212] A12. The method according to embodiment A11 further comprising:

[0213] attempting to decode the additional NTN SIB without merging the NTN SIB with the additional NTN SIB; or

[0214] An attempt is made to decode the additional NTN SIB by combining the first stored NTN SIB with the second NTN SIB.

[0215] Group B Example

[0216] B1. A user equipment for facilitating NTN SIB accumulation in an NTN to allow operation under coverage-limited conditions and to avoid decoding errors when NTN SIB content changes frequently for one or both of implicit and explicit epoch time indications, the user equipment comprising:

[0217] A processing circuit configured to implement any of the steps according to any one of Group A or the General Group of Embodiments; and

[0218] A power supply circuit is configured to supply power to the processing circuit.

[0219] B2. A user equipment (UE) for facilitating NTN SIB accumulation in an NTN to allow operation under coverage-limited conditions and to avoid decoding errors when NTN SIB content changes frequently for one or both of implicit and explicit epoch time indications, the UE comprising:

[0220] an antenna configured to transmit and receive wireless signals;

[0221] a radio front end circuit connected to the antenna and to the processing circuit and configured to condition signals transmitted between the antenna and the processing circuit;

[0222] The processing circuit is configured to implement any of the steps according to any one of Group A or the General Group of Embodiments;

[0223] an input interface connected to the processing circuitry and configured to allow information to be input into the UE for processing by the processing circuitry;

[0224] an output interface connected to the processing circuit and configured to output information that has been processed by the processing circuit from the UE; and

[0225] A battery is connected to the processing circuit and configured to supply power to the UE.

[0226] B3. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising:

[0227] processing circuitry configured to provide user data; and

[0228] A network interface, which is configured to initiate transmission of the user data to a network node in a cellular network for transmission to a user equipment (UE), the network node having a communication interface and a processing circuit, the processing circuit of the network node being configured to implement any operation according to any one of the embodiments in Group B to send the user data from the host to the UE.

[0229] B4. A host according to the preceding embodiment, wherein:

[0230] The processing circuitry of the host is configured to execute a host application that provides the user data; and

[0231] The UE includes processing circuitry configured to execute a client application associated with the host application to receive a transmission of user data from the host.

[0232] B5. A method implemented in a host, the host being configured to operate in a communication system, the communication system further comprising a network node and a user equipment (UE), the method comprising:

[0233] providing user data for the UE; and

[0234] Initiate a transmission carrying the user data to the UE via a cellular network including the network node, wherein the network node implements any operation according to any one of Group B embodiments to send the user data from the host to the UE.

[0235] B6. The method according to the aforementioned embodiment further includes: at the network node, sending the user data provided by the host for the UE.

[0236] B7. A method according to any one of the above two embodiments, wherein the user data is provided at the host by executing a host application that interacts with a client application executed on the UE, and the client application is associated with the host application.

[0237] B8. A communication system configured to provide an over-the-top (OTT) service, the communication system comprising:

[0238] A host computer, which includes:

[0239] a processing circuit configured to provide user data to a user equipment (UE), the user data being associated with the over-the-top service; and

[0240] A network interface configured to initiate transmission of the user data to a cellular network node for transmission to the UE, the network node having a communication interface and a processing circuit, the processing circuit of the network node being configured to implement any operation according to any one of the embodiments in Group B to send the user data from the host to the UE.

[0241] B9. The communication system according to the preceding embodiment further includes:

[0242] The network node; and / or

[0243] The UE.

[0244] B10. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising:

[0245] processing circuitry configured to initiate reception of user data; and

[0246] A network interface, which is configured to receive the user data from a network node in a cellular network, the network node having a communication interface and a processing circuit, the processing circuit of the network node being configured to implement any operation according to any one of the embodiments in Group B to receive the user data from the user equipment (UE) for the host.

[0247] B11. A host according to the above two embodiments, wherein:

[0248] The processing circuit of the host is configured to execute a host application that receives the user data; and

[0249] The host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.

[0250] B12. A host according to any one of the two preceding embodiments, wherein initiating reception of the user data comprises: requesting the user data.

[0251] B13. The method according to the aforementioned embodiment further includes: at the network node, sending the received user data to the host.

[0252] B14. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising:

[0253] processing circuitry configured to provide user data; and

[0254] A network interface configured to initiate transmission of the user data to a cellular network for transmission to a user equipment (UE), wherein the UE includes a communication interface and a processing circuit, and the communication interface and processing circuit of the UE are configured to implement any operation according to any one of Group A or General Group embodiments to receive the user data from the host.

[0255] B16. The host according to the preceding embodiment, wherein the cellular network further comprises a network node, wherein the network node is configured to communicate with the UE to send the user data from the host to the UE.

[0256] B17. A host according to the above two embodiments, wherein:

[0257] The processing circuit of the host is configured to execute a host application to provide the user data; and

[0258] The host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.

[0259] B18. A method implemented by a host operating in a communication system, the communication system also including a network node and a user equipment (UE), the method comprising:

[0260] providing user data for the UE; and

[0261] Initiate a transmission carrying the user data to the UE via a cellular network including the network node, wherein the UE implements any operation described in any of Group A or General Group embodiments to receive the user data from the host.

[0262] B19. The method according to the above embodiment further includes:

[0263] At the host, a host application associated with the client application executing on the UE is executed to receive the user data from the host application.

[0264] B20. The method according to the above embodiment further includes:

[0265] sending, at the host, input data to a client application executing on the UE, the input data being provided by executing the host application,

[0266] The user data is provided by the client application in response to input data from the host application.

[0267] B21. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising:

[0268] processing circuitry configured to provide user data; and

[0269] A network interface configured to initiate transmission of the user data to a cellular network for transmission to a user equipment (UE), wherein the UE includes a communication interface and a processing circuit, and the communication interface and processing circuit of the UE are configured to implement any steps described in any one of Group A or General Group embodiments to send the user data to the host.

[0270] B22. The host according to the preceding embodiment, wherein the cellular network further comprises a network node, wherein the network node is configured to communicate with the UE to send the user data from the UE to the host.

[0271] B23. A host according to the above two embodiments, wherein:

[0272] The processing circuit of the host is configured to execute a host application to provide the user data; and

[0273] The host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.

[0274] B24. A method implemented by a host configured to operate in a communication system, the communication system also including a network node and a user equipment (UE), the method comprising:

[0275] At the host, user data sent by the UE to the host via the network node is received, wherein the UE implements any steps described in any one of Group A or General Group embodiments to send the user data to the host.

[0276] B25. The method according to the above embodiment further includes:

[0277] At the host, a host application associated with the client application executing on the UE is executed to receive the user data from the UE.

[0278] B26. The method according to the above two embodiments further includes:

[0279] sending, at the host, input data to the client application executing on the UE, the input data being provided by executing the host application,

[0280] The user data is provided by the client application in response to input data from the host application. BRIEF DESCRIPTION OF THE DRAWINGS

[0281] For a more complete understanding of the present disclosure, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:

[0282] Figure 1 An example architecture of a satellite network with bent pipe transponders (ie, a transparent payload architecture) is shown.

[0283] Figure 2 A satellite orbit fully described using 6 parameters is shown.

[0284] Figure 3 NB-IoT SIB Type-x (SIBxNB) transmission and related parameter ranges for the repetition pattern within the SI window, the duration of the SI window and the period of the SI window are shown.

[0285] Figure 4 An example of a communication system 400 is shown in accordance with some embodiments.

[0286] Figure 5 UE 500 according to some embodiments is shown. UE 500 may be Figure 1 An embodiment of a device for communicating with a satellite is shown in .

[0287] Figure 6 A network node 600 according to some embodiments is shown.

[0288] Figure 7 is a block diagram of a host 700 according to various aspects described herein, and the host 700 may be Figure 4 An embodiment of host 416.

[0289] Figure 8 is a block diagram illustrating a virtualization environment 800 in which functionality implemented by some embodiments may be virtualized.

[0290] Fig. 9 A communication diagram is shown in which a host 902 communicates with a UE 906 via a network node 904 over a partially wireless connection according to some embodiments.

[0291] Fig.10 is a flow chart of method 1000 according to some embodiments.

[0292] Fig.11 is a flow chart of method 1100 according to some embodiments. DETAILED DESCRIPTION

[0293] There are some challenges. One unresolved issue with IoT NTN is how to handle NTN SIB accumulation across SI windows. Both LTE-M and NB-IoT allow SIB repetition within an SI window. In addition, if necessary, the UE can also accumulate SIBs across multiple SI windows (except for frequently changing SIBs, such as SIB16 specified in the 3GPP specification).

[0294] If the content of the NTN SIB remains constant across multiple SI windows, it is beneficial to allow SIB accumulation over those windows to overcome poor coverage. However, if one or more NTN SIBs in the accumulated SI windows are different, decoding errors may result and accumulation should be avoided.

[0295] The content of the NTN SIB is partly dynamic (e.g. ephemeris data and common TA parameters), so this is problematic when SIB accumulation is needed, e.g. in order to get a good enough reception at the cell edge.

[0296] Therefore, a solution is needed to facilitate the accumulation of NTN SIBs when needed. In the Appendix, a more general solution to this problem is proposed. However, the present disclosure provides a detailed solution for explicit and implicit epoch time indication.

[0297] Certain aspects of the present disclosure and embodiments thereof may provide solutions to these or other challenges. We describe methods and signaling that facilitate NTN SIB accumulation in NTN to allow operation under coverage-restricted conditions and to avoid decoding errors when the NTN SIB contents change frequently for both implicit and explicit epoch time indications. Signaling and methods are used to determine whether NTN-specific SIB accumulation across SI windows should be implemented in IoT NTN cells based on other SI configuration parameters. Signals and methods are used to indicate whether implicit or explicit epoch time is used in the NTN cell. Methods are used to implement blind decoding of the NTN SIB when the UE receives only partial information about the NTN SIB accumulation from the network or no information about the NTN SIB accumulation. Signaling and methods are used to implement decoding of the NTN SIB when the validity timer varies from SIB to SIB, even if the other contents of the SIB remain unchanged.

[0298] Certain embodiments may provide one or more of the following technical advantages: The proposed solution provides a method for facilitating accumulation of NTN-specific SIBs across multiple SI windows for NTN UEs in poor coverage areas while avoiding decoding errors due to NTN-specific SIB accumulation.

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

[0300] Note 1: SIB accumulation refers to the accumulation of NTN-specific SIBs (which contain satellite ephemeris and / or other assistance information for NTN; also referred to as NTN SIBs) across one or more SI windows.

[0301] Note 2: One or more of the concepts described herein for IoT NTN may also be applied to NR NTN and / or other scenarios where it is desirable to accumulate SIBs for frequently changing SIBs.

[0302] Note 3: “Updating NTN SIB” means updating the contents of NTN SIB.

[0303] Note 4: The present invention is about NTN SIB accumulation and does not change the defined UE behavior regarding accumulation of other legacy SIBs. That is, the UE can also accumulate other SIBs as in the terrestrial network.

[0304] Note 5: In IoT NTN there are technically 2 different NTN SIBs (SystemInformationBlockType31 and SystemInformationBlockType32) to which the present invention may be relevant since both may update their ephemeris between SI windows.

[0305] Note 6: The invention described herein may be used in conjunction with one or more of the methods described in the Appendix.

[0306] SIB accumulation based on SI configuration

[0307] In the appendix, the following examples are documented:

[0308] Example 4: If the SI period exceeds the NTN SIB broadcast period, and / or the number of repetitions configured for the SIB exceeds a certain value, SIB accumulation is prohibited. The UE can determine these periods and repetition patterns from system information and then determine whether to allow accumulation of NTN SIBs.

[0309] In this document we include additional detailed embodiments regarding NTN SIB accumulation and SI configuration parameters.

[0310] In one embodiment, one or more SI configuration parameters are used by the UE to determine whether NTN SIB accumulation is allowed. In a sub-embodiment, the SI period is used by the UE to determine whether NTN SIB accumulation is allowed.

[0311] This may be defined in a standard specification, for example, NTN SIB accumulation may be fixed and specified in the specification as being possible for certain SI configuration parameter values, and / or this may be implemented by the UE. Alternatively or additionally, the network may indicate whether the UE may use the SI configuration parameters to determine whether it may accumulate NTN SIBs. In another embodiment, the UE determines whether accumulating NTN SIBs is feasible by using the SI configuration parameters and other parameters such as the remaining service time (T_service) before the NTN cell changes, the satellite orbit or constellation type, the satellite beam type (Earth-fixed or mobile), the previous ephemeris validity timer value stored in the UE and / or whether NTN SIB accumulation has been successfully used in previous attempts, whether it is a NB-IoT or eMTC UE, the epoch time indication range (and / or whether it is indicated in the past or in the future), etc.

[0312] In one embodiment, one or more SI configuration parameters are used by the UE to determine whether NTN SIB accumulation should be implemented. For example, if the network does not explicitly indicate information that allows or prohibits NTN SIB accumulation in a cell, but leaves it to the UE to decide, the UE can use the SI configuration parameter value to decide whether NTN SIB should be accumulated across SI windows. In a sub-embodiment, the UE uses the SI period to determine whether NTN SIB accumulation should be implemented.

[0313] In the following sections, we give several examples of the above embodiments for explicit epoch times.

[0314] Explicit epoch time

[0315] Let us consider the case where the epoch time is explicitly signaled in the NTN SIB. Even if the ephemeris, common TA parameters, validity timer duration and epoch time remain unchanged, it is the epoch time indication range that will determine how long the NTN SIB can be sent unchanged before it needs to be updated. For example, if the epoch time indication range is 5.12 seconds (or 10.24 seconds), the period of time that the NTN SIB content can remain unchanged will be at most 5.12 seconds (or 10.24 seconds). After this time, the content may need to be updated to correspond to the new epoch time (unless additional signaling is introduced in the SI to assist the decoding process).

[0316] Depending on the NTN scenario, how frequently the network sends and updates the NTN SIB depends on the network. Based on the parameter values ​​for SI configuration and validity timer, we analyzed potential scenarios where NTN SIB accumulation may be feasible. In the table for eMTC and the table for NB-IoT, we observed that there are many combinations of SI periodicity and UL synchronization validity timer duration for which the ephemeris is expected to remain unchanged. Smaller validity timer values ​​are mainly applicable to LEO scenarios, while larger validity timer values ​​are applicable to GEO scenarios. Since the SI period supported by eMTC is much smaller than that of NB-IoT, the frequency of sending NTN SIBs in eMTC can be higher than that in NB-IoT. This means that in eMTC, a larger number of SI windows can exist in a specific time period than in NB-IoT. Nevertheless, for both eMTC and NB-IoT, NTN-SIBs can be accumulated over multiple SI windows. In addition, the smaller the SI period, the greater the number of SI windows in a specific time period. Therefore, if the network updates the NTN SIB in roughly the same order as the validity timer, the number of SI windows that can be accumulated for NTN SIB decoding can be reflected in these tables. However, if we take into account the additional restrictions due to the epoch time indication range, then the number of possible NTN SIBs that can be accumulated is roughly given by the first row (regardless of the validity timer), assuming an indication range of 5.12 seconds; or the first row and the second row, assuming an indication range of 10.24 seconds (and a validity timer of 5 seconds), or the second row, assuming an indication range of 10.24 seconds (and a validity timer of 10 seconds or more).

[0317] Table 2 The number of eMTC NTN SIBs that can be accumulated before the validity timer expires.

[0318]

[0319] Table 3 The number of NB-IoT NTN SIBs that can be accumulated before the validity timer expires.

[0320]

[0321] Example:

[0322] With explicit epoch time, the SI period value can be used to determine whether the UE should accumulate NTN SIBs. Based on the results in the table above, in one example, if it exceeds 64 radio frames, the IoT NTN UE can assume that NTN SIB accumulation is not allowed. In this case, no additional signaling is required, because the SI period is signaled by the network anyway, which is all the UE needs to decide whether to accumulate NTN SIBs.

[0323] In another example, NTN SIB accumulation in eMTC NTN is allowed for the following SI periods: {8, 16, 32, 64} frames.

[0324] In another example, NTN SIB accumulation in eMTC NTN is allowed for the following SI periods: {8, 16, 32} frames.

[0325] In one embodiment, NTN SIB accumulation in NB-IoT NTN is allowed for the following SI periods: {64} frames.

[0326] In the above examples, the mentioned SI period may be specified in the specification and / or optionally indicated by the network in system information (except for the NTN SIB).

[0327] In another example, NTN SIB accumulation is implemented by the UE. In this case, the UE can decide whether to attempt NTN SIB accumulation based on the epoch timer indication range and the number of SI windows.

[0328] Difference between explicit and implicit epoch time

[0329] How does the UE know if the network is using explicit or implicit epoch time indication?

[0330] In one embodiment, if the network uses implicit or explicit epoch time indication, for example using a 1-bit field in SIB1, the network indicates it in the SI (except for the NTN SIB).

[0331] In another embodiment, if different parameters are signaled in the SI for NTN SIB accumulation of explicit epoch time and implicit epoch time, the UE can infer whether the network uses implicit epoch time or explicit epoch time based on the signaled parameters.

[0332] If no additional signaling is introduced for explicit epoch time, but additional signaling is introduced for explicit epoch time: If the relevant parameters for implicit epoch time are included in the SI, the UE shall assume that implicit epoch time is supported. Otherwise, it shall assume that explicit epoch time is supported.

[0333] If no additional signaling is introduced for implicit epoch time, but additional signaling is introduced for explicit epoch time: If the relevant parameters for explicit epoch time are included in the SI, the UE shall assume that explicit epoch time is supported. Otherwise, it shall assume that implicit epoch time is supported.

[0334] NTN SIB accumulation independent of validity timer update

[0335] If some contents of the NTN SIB remain unchanged, i.e., ephemeris, common TA parameters, and epoch time (if epoch time is sent), but the validity timer is updated, the UE can still accumulate the NTN SIB and attempt to decode the NTN SIB if the validity timer is updated in a predictable manner. For example, if the SI period is 5.12 seconds, and the UE determines that it can accumulate NTN SIBs, and it attempts to decode using 2 NTN SIBs, it can assume that the validity timer in the second SIB is ~5 seconds less than the first NTN SIB. Since it knows the validity timer bits that are different in the two NTN SIBs, it can incorporate this information when merging the two SIBs.

[0336] In another embodiment, the network may indicate in the SI whether the validity timer indicated in the NTN SIB may be assumed to be constant for the NTN SIB accumulation.

[0337] In another embodiment, if the network indicates any information related to facilitating NTN SIB accumulation, it is assumed that the validity timer value will remain unchanged if the other contents of the NTN SIB remain unchanged.

[0338] In another embodiment, if the network indicates any information related to facilitating NTN SIB accumulation, it is assumed that the validity timer value will vary for each SIB according to the validity timer granularity and SI periodicity, even if the other contents of the NTN SIB remain unchanged.

[0339] In another embodiment, if the network uses explicit epoch time indication, it is assumed that the validity timer value will remain unchanged if the other contents of the NTN SIB remain unchanged.

[0340] In another embodiment, if the network uses implicit epoch time indication, it is assumed that the validity timer value will remain unchanged if the other contents of the NTN SIB remain unchanged.

[0341] In another embodiment, if the network uses explicit epoch time indication, it is assumed that the validity timer value will vary for each SIB according to the validity timer granularity and SI periodicity, even if the other contents of the NTN SIB remain unchanged.

[0342] In another embodiment, if the network uses implicit epoch time indication, it is assumed that the validity timer value will vary for each SIB according to the validity timer granularity and SI periodicity, even if the other contents of the NTN SIB remain unchanged.

[0343] In another embodiment, the satellite orbit (eg, LEO, MEO, or GEO) determines whether the validity timer indicated in the NTN SIB can be assumed to be constant for NTN SIB accumulation, where this rule can be defined in the specification.

[0344] Blind NTN SIB decoding in accumulation case

[0345] In the appendix, it is recorded that "In one embodiment, once the UE has determined that NTN SIB accumulation is not prohibited, it is implemented by the UE to determine the number of SI windows across which NTN SIBs can be accumulated. For example, the UE may opportunistically attempt to decode the NTN SIB by accumulating across SI windows on a trial-and-error basis. It may also use an orbit prediction algorithm or other side information, such as an uplink synchronization validity timer value or previously acquired satellite ephemeris / common TA parameters, to estimate how frequently the network updates satellite ephemeris or common TA, etc. It may then attempt to accumulate the NTN SIB in SI windows that fall within its estimated duration (during which the NTN SIB content is expected to remain unchanged)."

[0346] In the present invention, we provide some additional embodiments for NTN SIB accumulation, regardless of whether the UE has any a priori information about NTN SIB decoding.

[0347] In one embodiment, even if the network does not indicate any information to assist the UE in deciding whether to accumulate NTN SIBs and / or when to start / stop accumulating NTN SIBs, the UE may blindly try to accumulate NTN SIBs for decoding purposes.

[0348] Example: Let us assume that the NTN SIB remains unchanged in N consecutive SI windows, but the UE does not know the parameter "N" and / or the start or end time of the set of N SI windows (i.e., it does not know the starting SI window of the set of SI windows (which contains the SI message for the NTN SIB) and / or the last SI window of the set of SI windows). In this case, the UE can test multiple hypotheses when decoding the NTN SIB. For example,

[0349] It may try to decode the NTN SIB first.

[0350] If unsuccessful, it may store the first NTN SIB and receive and store the second NTN SIB in the next SI transmission. It may attempt to decode the second NTN SIB itself and / or attempt to decode the NTN SIB by combining the first stored NTN SIB and the second NTN SIB.

[0351] If still unsuccessful, it may continue to receive, store and attempt to merge multiple NTN SIBs until it successfully decodes an NTN SIB, or after a certain number of unsuccessful decoding or merging attempts, and / or until it has stored a certain number of NTN SIBs based on its memory constraints, and / or based on its knowledge of the SI period or other relevant parameters.

[0352] The UE may use additional information about coverage to assist the decoding process. For example, if the UE can estimate the number "X" of NTN SIBs it may need to accumulate based on previous successful acquisition of the NTN SIB or successful acquisition of SIBs other than the NTN SIB, and / or other information related to coverage (such as RSRP / RSRQ levels) and / or SI configuration parameters. The UE may start the decoding process with its assessment of "X" and only merge a maximum of X SI windows or at least X SI windows. If its decoding attempt fails, it may increment the number X until the decoding is successful.

[0353] In another example, if the UE has received and stored K NTN SIBs, it may try to merge the first k (k=1, ..., K) of these NTN SIBs starting from the first NTN SIB. Alternatively, it may merge k NTN SIBs (k=1, ..., K) starting from the mth NTN SIB (where m=1, ..., K) of the set of K NTN SIBs.

[0354] In another example, the UE adopts a "sliding window" approach when receiving and combining NTN SIBs for decoding, that is, if the UE has made a certain number of failed decoding attempts using older SIBs, the set of "K" NTN SIBs is updated by removing older SIBs and adding newer SIBs. For example, if X=3, the UE can accumulate up to K=3 NTN SIBs for decoding. The UE can try to decode the first, second, and third NTN SIBs separately, but if the UE's assessment of X=3 is correct, they will fail. The UE can then try to combine the first and second NTN SIBs or the second and third NTN SIBs, but these attempts will also fail. Finally, it can try to combine all three SIBs. If this attempt is unsuccessful, the UE can clear the first NTN SIB and obtain another NTN SIB (which will be the third NTN SIB) and try to decode with this set of three NTN SIBs. If it is still unsuccessful, the UE can remove the first NTN SIB again and add the new NTN SIB. If it is still unsuccessful, the UE can increment X by 1 and restart the whole process.

[0355] In another embodiment, the UE may flush older NTN SIBs that it has stored for accumulation, eg, freeing up memory to store additional NTN SIBs.

[0356] In another embodiment, the UE may test additional assumptions depending on whether it assumes that the validity timer sent in the NTN SIB remains unchanged (if other SIB contents remain unchanged).

[0357] In another embodiment, the SIB accumulation described in this document targets a specific NTN SIB, which is the NTN SIB required for uplink synchronization (SystemInformationBlockType31) or the NTN SIB for non-contiguous coverage (SystemInformationBlockType32). This can be specified and / or additionally indicated to the UE. Optionally, the SIB accumulation information applies to both NTN SIBs.

[0358] Figure 4 An example of a communication system 400 is shown in accordance with some embodiments.

[0359] In this example, the communication system 400 includes a telecommunications network 402, which includes an access network 404 (such as a radio access network (RAN)) and a core network 406 (which includes one or more core network nodes 408). The access network 404 includes one or more access network nodes, such as network nodes 410a and 410b (one or more of which may be generally referred to as network nodes 410), or any other similar third generation partnership project (3GPP) access node or non-3GPP access point. In addition, as will be appreciated by those skilled in the art, the network node is not necessarily limited to an implementation in which the radio portion and the baseband portion are provided and integrated by a single vendor. Therefore, it is understood that the network node may include a decomposed implementation or part thereof. For example, in some embodiments, the telecommunications network 402 includes one or more open RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunications network 402 that supports ORAN specifications (e.g., specifications published by the O-RAN Alliance or any similar organization) and can operate alone or in conjunction with other nodes to implement one or more functions of any node in the telecommunications network 402, including one or more network nodes 410 and / or core network nodes 408.

[0360] Examples of ORAN network nodes 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" indicates support for ORAN specifications). The network node may support the specifications by, for example, supporting interfaces defined by the ORAN specifications, such as A1, F1, W1, E1, E2, X2, Xn interfaces, an open fronthaul user plane interface, or an open fronthaul management plane interface. In addition, the ORAN network node may be a logical node in a physical node. In addition, the ORAN network node may be implemented in a virtualized environment (described further below) in which one or more network functions are virtualized. For example, the virtualized environment may include an O-Cloud computing platform orchestrated by a service management and orchestration framework through an O-2 interface defined by the O-RAN Alliance or similar technology. The network node 410 facilitates direct or indirect connection of user equipment (UE), such as connecting wireless devices 412a, 412b, 412c, and 412d (one or more of which may be generally referred to as UE 412) to the core network 406 via one or more wireless connections.

[0361] Example wireless communications over wireless connections include sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transferring information without the use of wires, cables, or other material conductors. In addition, in various embodiments, the communication system 400 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 a wired or wireless connection. The communication system 400 may include and / or interface to any type of communication, telecommunication, data, cellular, radio network, and / or other similar types of systems.

[0362] UE 412 may be any of a variety of communication devices, including wireless devices that are arranged, configured and / or operable to communicate wirelessly with network node 410 and other communication devices. Similarly, network node 410 is arranged, capable, configured and / or operable to communicate directly or indirectly with UE 412 and / or with other network nodes or devices in telecommunication network 402 to enable and / or provide network access, such as wireless network access, and / or perform other functions, such as management in telecommunication network 402.

[0363] In the depicted example, the core network 406 connects the network node 410 to one or more hosts, such as the host 416. These connections may be direct or may be indirect via one or more intermediate networks or devices. In other examples, the network node may be directly coupled to the host. The core network 406 includes one or more core network nodes (e.g., core network node 408) constructed with hardware and software components. The features of these components may be substantially similar to those described with respect to the UE, network node, and / or host, so that the description thereof is generally applicable to the corresponding components of the core network node 408. The example core network node includes a mobile switching center (MSC), a mobility management entity (MME), a home subscriber server (HSS), an access and mobility management function (AMF), a session management function (SMF), an authentication server function (AUSF), a subscription identifier de-hiding function (SIDF), a unified data management (UDM), a security edge protection agent (SEPP), a network open function (NEF), and / or a user plane function (UPF) One or more functions.

[0364] The host 416 may be owned or controlled by a service provider other than the operator or provider of the telecommunications network 402 and / or the access network 404, and may be operated by or on behalf of the service provider. The host 416 may host various applications to provide one or more services. Examples of such applications include real-time and pre-recorded audio / video content, data collection services such as retrieving and compiling data of various environmental conditions detected by multiple UEs, analytical functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarm and monitoring centers, or any other such functions implemented by a server.

[0365] Overall, Figure 4 The communication system 400 enables connections between UEs, network nodes, and hosts. In this sense, the communication system can be configured to operate according to predefined rules or procedures, such as specific standards, including but 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 standards (e.g., 6G); Wireless Local Area Network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and / or any other suitable wireless communication standards, such as 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.

[0366] In some examples, the telecommunication network 402 is a cellular network that implements 3GPP standardized features. Therefore, the telecommunication network 402 can support network slicing to provide different logical networks to different devices connected to the telecommunication network 402. For example, the telecommunication network 402 can provide ultra-reliable low-latency communication (URLLC) services to some UEs, enhanced mobile broadband (eMBB) services to other UEs, and / or massive machine type communication (mMTC) / massive IoT services to other UEs.

[0367] In some examples, UE 412 is configured to send and / or receive information without direct human interaction. For example, the UE may be designed to send information to access network 404 according to a predetermined schedule when triggered by an internal or external event, or in response to a request from access network 404. In addition, the UE may be configured to operate in a single RAT or multi-RAT or multi-standard mode. For example, the UE may operate using any one or a combination of WiFi, NR (New Radio) and LTE, i.e., configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC).

[0368] In this example, the hub 414 communicates with the access network 404 to facilitate indirect communication between one or more UEs (e.g., UE 412c and / or 412d) and a network node (e.g., network node 410b). In some examples, the hub 414 can be a controller, a router, a content source and analysis, or any other communication device described herein with respect to the UE. For example, the hub 414 can be a broadband router that enables the UE to access the core network 406. As another example, the hub 414 can be a controller that sends commands or instructions to one or more actuators in the UE. The command or instruction can be received from the UE, the network node 410, or received by an executable code, a script, a process, or other instructions in the hub 414. As another example, the hub 414 can be a data collector that acts as a temporary storage for UE data, and in some embodiments, analysis or other processing of the data can be implemented. As another example, the hub 414 can be a content source. For example, for a UE that is a VR headset, display, speaker, or other media delivery device, the hub 414 can retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, and then the hub 414 provides it to the UE directly, provides it to the UE after implementing local processing, and / or provides it to the UE after adding additional local content. In another example, the hub 414 acts as a proxy server or orchestrator for the UE, especially when one or more UEs are low-energy IoT devices.

[0369] Hub 414 can have constant / persistent or intermittent connection to network node 410b. Hub 414 can also allow different communication schemes and / or scheduling between hub 414 and UE (e.g., UE 412c and / or 412d) and between hub 414 and core network 406. In other examples, hub 414 is connected to core network 406 and / or one or more UE via wired connection. In addition, hub 414 can be configured to be connected to M2M service provider and / or connected to another UE via direct connection through access network 404. In some scenarios, UE can establish wireless connection with network node 410, while still connected via hub 414 through wired or wireless connection. In some embodiments, hub 414 can be a dedicated hub, that is, its main function is to route communication from network node 410b to UE or from UE to the hub of network node 410b. In other embodiments, the hub 414 may be a non-dedicated hub, ie, a device operable to route communications between the UE and the network node 410b, but which is also operable as a communications origin and / or destination for a particular data channel.

[0370] Figure 5 FIG. 5 shows a UE 500 according to some embodiments. The UE 500 may be a UE that is connected to a wireless network via an access link. Figure 1 . As used herein, UE refers to a device capable of, configured, arranged and / or operable to wirelessly communicate with a network node and / or other UE. Examples of UE include, but are not limited to, smart phones, mobile phones, cellular phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, notebook computers, notebook embedded devices (LEEs), notebook computer mounted devices (LMEs), smart devices, wireless customer premises equipment (CPEs), vehicles, wireless devices mounted on vehicles or embedded / integrated into vehicles, etc. Other examples include any UE identified by the Third Generation Partnership Project (3GPP), including narrowband Internet of Things (NB-IoT) UEs, machine type communications (MTC) UEs, and / or enhanced MTC (eMTC) UEs.

[0371] A UE may support device-to-device (D2D) communications, such as by implementing 3GPP standards for sidelink communications, dedicated short-range communications (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 owning and / or operating an associated device. Rather, a UE may represent a device that is intended to be sold to or operated by a human user, but may not be associated with a specific human user (e.g., a smart sprinkler controller), or may not initially be associated with one. Alternatively, a UE may represent a device that is not intended to be sold to or operated by an end user, but may be associated with or operated for the benefit of a user (e.g., a smart meter).

[0372] UE 500 includes processing circuit IQ 202, which is operatively coupled to input / output interface 506, power supply 508, memory 510, communication interface 512 and / or any other components, or any combination thereof, via bus 504. Some UEs may utilize Figure 5 All or a subset of the components shown in . The level of integration between components may vary from UE to UE. In addition, some UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0373] The processing circuit 502 is configured to process instructions and data, and may be configured to implement any sequential state machine operable to execute instructions stored in the memory 510 as a machine-readable computer program. The processing circuit 502 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 and appropriate firmware; one or more stored computer programs, general-purpose processors, such as microprocessors or digital signal processors (DSPs), and appropriate software; or any combination of the above. For example, the processing circuit 502 may include multiple central processing units (CPUs).

[0374] In this example, the input / output interface 506 can be configured to provide one or more interfaces to an input device, an output device, or one or more input and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, transmitters, smart cards, another output device, or any combination thereof. An input device can allow a user to capture information into the UE 500. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, web cameras, etc.), microphones, sensors, mice, trackballs, direction pads, trackpads, rollers, smart cards, etc. A presence-sensitive display can include a capacitive or resistive touch sensor to sense input from a user. The sensor can be, for example, 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 can use an interface port of the same type as an input device. For example, a universal serial bus (USB) port can be used to provide input devices and output devices.

[0375] In some embodiments, the power supply 508 is configured as a battery or a battery pack. Other types of power supplies may be used, such as an external power supply (e.g., a power outlet), a photovoltaic device, or a battery. The power supply 508 may also include a power supply circuit for delivering power from the power supply 508 itself and / or an external power supply to various components of the UE 500 through an input circuit or an interface such as a power cable. For example, the delivered power may be used to charge the power supply 508. The power supply circuit may perform any formatting, conversion, or other modification on the power from the power supply 508 so that the power is suitable for the corresponding components of the UE 500 to which the power is supplied.

[0376] The memory 510 may be or be configured to include a memory such as a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic disk, an optical disk, a hard disk, a removable cartridge, a flash drive, etc. In one example, the memory 510 includes one or more application programs 514, such as an operating system, a web browser application, a widget, a gadget engine, or other application, and corresponding data 516. The memory 510 may store any of a variety of different operating systems or a combination of operating systems for use by the UE 500.

[0377] The memory 510 may be configured to include multiple physical drive units, such as a redundant array of independent disks (RAID), a flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile disk (HD-DVD) optical drive, an internal hard drive, a Blu-ray optical drive, a holographic digital data storage (HDDS) optical drive, an external mini dual in-line memory module (DIMM), a synchronous dynamic random access memory (SDRAM), an external micro DIMM SDRAM, a smart card memory, such as a tamper-proof module in the form of a universal integrated circuit card (UICC), including one or more subscriber identity modules (SIMs), such as USIM and / or ISIM, other memories, or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card". The memory 510 may allow the UE 500 to access instructions, applications, etc. stored on a transient or non-transient storage medium to offload data or upload data. An article of manufacture (eg, an article of manufacture utilizing a communication system) may be tangibly embodied as or in memory 510 , which may be or include a device-readable storage medium.

[0378] The processing circuit 502 may be configured to communicate with an access network or other network using a communication interface 512. The communication interface 512 may include one or more communication subsystems and may include an antenna 522 or be communicatively coupled to the antenna 522. The communication interface 512 may include one or more transceivers for communication, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or network node in the access network). Each transceiver may include a transmitter 518 and / or a receiver 520 suitable for providing network communications (e.g., optical, electrical, frequency allocation, etc.). In addition, the transmitter 518 and the receiver 520 may be coupled to one or more antennas (e.g., antenna 522) and may share circuit components, software, or firmware, or may alternatively be implemented separately.

[0379] In the illustrated embodiment, the communication functionality of the communication interface 512 may include cellular communication, WiFi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication (such as Bluetooth), near field communication, location-based communication (such as using a global positioning system (GPS) to determine location), another similar communication functionality, or any combination thereof. Communication may be implemented according to one or more communication protocols and / or standards, such as IEEE 802.11, code division multiple access (CDMA), wideband code division multiple access (WCDMA), GSM, LTE, new radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / Internet protocol (TCP / IP), synchronous optical network (SONET), asynchronous transfer mode (ATM), QUIC, hypertext transfer protocol (HTTP), etc.

[0380] Regardless of the type of sensor, the UE can provide an output of the data captured by its sensor via a wireless connection to a network node through its communication interface 512. The data captured by the UE's sensor can be transmitted to the network node via another UE through a wireless connection. The output can be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to balance the load of reports from several sensors), in response to a trigger event (e.g., when humidity is detected, an alarm 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).

[0381] As another example, the UE includes an actuator, motor, or switch associated with a communication interface that is configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input, the state of the actuator, motor, or switch can change. For example, the UE can include a motor that adjusts a control surface or rotor of a drone in flight based on the received input, or adjusts a robotic arm that performs a medical procedure based on the received input.

[0382] When the UE is in the form of an Internet of Things (IoT) device, it can be a device for one or more application areas, including but not limited to urban wearable technology, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices are the following devices or devices embedded in the following devices: connected refrigerators or freezers, TVs, connected lighting devices, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / humidity sensors, electric door locks, connected doorbells, air conditioning systems such as heat pumps, self-driving cars, surveillance systems, weather monitoring devices, parking monitoring devices, electric vehicle charging stations, smart watches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearable devices for tactile enhancement or sensory enhancement, sprinklers, animal or item tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any type of medical equipment, such as heart rate monitors or remotely controlled surgical robots. In addition to including, for example, in combination with Figure 5 In addition to the other components described for the UE 500 shown in FIG. 5 , circuits and / or software may also be included depending on the intended application of the IoT device.

[0383] As another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurement and sends the results of such monitoring and / or measurement to another UE and / or a network node. In this case, the UE may be an M2M device, which may be referred to as an MTC device in the 3GPP context. As a specific example, a UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, bus, truck, ship, and airplane, or other device capable of monitoring and / or reporting its operating status or other functions related to its operation.

[0384] In practice, any number of UEs may be used together for a single use case. For example, a first UE may be a drone or integrated in a drone and provide the drone's speed information (obtained via a speed sensor) to a second UE that is a remote controller for operating the drone. When the user implements 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 speed of the drone. The first and / or second UE may also include one or more of the above functions. For example, a UE may include a sensor and an actuator and handle communication of data for both the speed sensor and the actuator.

[0385] Figure 6 A network node 600 according to some embodiments is shown. The network node 600 may be included in Figure 1In the embodiment of the satellite shown. As used herein, a network node refers to a device that is capable of, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or devices in a telecommunications 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 Node Bs (gNBs)), O-RAN nodes, or components of O-RAN nodes (e.g., O-RUs, O-DUs, O-CUs).

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

[0387] Other examples of network nodes include a multi-transmission point (multi-TRP) 5G access node, a multi-standard radio (MSR) device (such as an MSR BS), a network controller (such as a radio network controller (RNC) or a base station controller (BSC)), a base transceiver station (BTS), a transmission point, a transmission node, a multi-cell / multicast coordination entity (MCE), an operation and maintenance (O&M) node, an operation support system (OSS) node, a self-organizing network (SON) node, a positioning node (e.g., an evolved serving mobile positioning center (E-SMLC)), and / or a minimization of drive tests (MDT).

[0388] The network node 600 includes a processing circuit 602, a memory 604, a communication interface 606, and a power supply 608. The network node 600 may include multiple physically separated components (e.g., a node B component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have its own corresponding component. In a specific scenario where the network node 600 includes multiple individual components (e.g., a BTS and a BSC component), one or more individual components may be shared between several network nodes. For example, a single RNC may control multiple node Bs. In such a scenario, in some instances, each unique node B and RNC pair may be considered as a single individual network node. In some embodiments, the network node 600 may be configured to support multiple radio access technologies (RATs). In such an embodiment, some components may be repeated (e.g., separate memories 604 for different RATs), and some components may be reused (e.g., the same antenna 610 may be shared by different RATs). The network node 600 may also include multiple sets of the various components shown for different wireless technologies, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth wireless technologies, integrated into the network node 600. These wireless technologies may be integrated into the same or different chip or set of chips and other components within the network node 600.

[0389] The processing circuit 602 may include a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, a combination of one or more of resources, or a combination of hardware, software and / or encoded logic that is operable to provide network node 600 functionality alone or in combination with other network node 600 components (such as memory 604).

[0390] In some embodiments, processing circuitry 602 includes a system on a chip (SOC). In some embodiments, processing circuitry 602 includes one or more of radio frequency (RF) transceiver circuitry 612 and baseband processing circuitry 614. In some embodiments, radio frequency (RF) transceiver circuitry 612 and baseband processing circuitry 614 may be on separate chips (or a set of chips), boards, or units (e.g., a radio unit and a digital unit). In alternative embodiments, part or all of RF transceiver circuitry 612 and baseband processing circuitry 614 may be on the same chip or a set of chips, boards, or units.

[0391] The memory 604 may include any form of volatile or non-volatile computer-readable memory, including but not limited to persistent memory, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, compact disk (CD) or digital video disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable storage device that stores information, data and / or instructions that can be used by the processing circuit 602. The memory 604 may store any suitable instructions, data or information, including computer programs, software, applications (including one or more of logic, rules, codes, tables and / or other instructions that can be executed by the processing circuit 602 and utilized by the network node 600). The memory 604 may be used to store any calculations performed by the processing circuit 602 and / or any data received via the communication interface 606. In some embodiments, the processing circuit 602 and the memory 604 are integrated.

[0392] The communication interface 606 is used for wired or wireless communication of signaling and / or data between network nodes, access networks and / or UEs. As shown, the communication interface 606 includes a port / terminal 616, which is used to send data to the network and receive data from the network, for example, via a wired connection. The communication interface 606 also includes a radio front-end circuit 618, which can be coupled to the antenna 610, or is a part of the antenna 610 in some embodiments. The radio front-end circuit 618 includes a filter 620 and an amplifier 622. The radio front-end circuit 618 can be connected to the antenna 610 and the processing circuit 602. The radio front-end circuit can be configured to adjust the signal transmitted between the antenna 610 and the processing circuit 602. The radio front-end circuit 618 can receive digital data to be sent to other network nodes or UEs via a wireless connection. The radio front-end circuit 618 can use a combination of a filter 620 and / or an amplifier 622 to convert the digital data into a radio signal with appropriate channel and bandwidth parameters. Then, the radio signal can be sent via the antenna 610. Similarly, when receiving data, antenna 610 may collect radio signals, which may then be converted to digital data by radio front end circuitry 618. The digital data may be passed to processing circuitry 602. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0393] In certain alternative embodiments, the network node 600 does not include a separate radio front end circuit 618, but rather the processing circuit 602 includes the radio front end circuit and is connected to the antenna 610. Similarly, in some embodiments, all or some of the RF transceiver circuit 612 is part of the communication interface 606. In other embodiments, the communication interface 606 includes one or more ports or terminals 616, the radio front end circuit 618, and the RF transceiver circuit 612 as part of a radio unit (not shown), and the communication interface 606 communicates with the baseband processing circuit 614 as part of a digital unit (not shown).

[0394] Antenna 610 may include one or more antennas or antenna arrays configured to send and / or receive wireless signals. Antenna 610 may be coupled to radio front end circuit 618 and may be any type of antenna capable of wirelessly sending and receiving data and / or signals. In some embodiments, antenna 610 is separate from network node 600 and may be connected to network node 600 via an interface or port.

[0395] Antenna 610, communication interface 606 and / or processing circuit 602 can be configured to implement any receiving operation and / or certain acquisition operation implemented by the network node as described herein. Any information, data and / or signal can be received from UE, another network node and / or any other network device. Similarly, antenna 610, communication interface 606 and / or processing circuit 602 can be configured to implement any sending operation implemented by the network node as described herein. Any information, data and / or signal can be sent to UE, another network node and / or any other network device.

[0396] The power supply 608 provides power to the various components of the network node 600 in a form suitable for the respective components (e.g., at the voltage and current levels required by each respective component). The power supply 608 may also include or be coupled to a power management circuit to provide power to the components of the network node 600 for implementing the functions described herein. For example, the network node 600 may be connected to an external power source (e.g., a power grid, a power outlet) via an input circuit or interface such as a cable, whereby the external power source supplies power to the power circuit of the power supply 608. As another example, the power supply 608 may include a power source in the form of a battery or battery pack connected to or integrated in the power circuit. If the external power source fails, the battery may provide backup power.

[0397] An embodiment of the network node 600 may include Figure 6Additional components other than those shown in the figure may be used to provide certain aspects of the functionality of the network node, including any functionality described herein and / or any functionality required to support the subject matter described herein. For example, the network node 600 may include a user interface device to allow information to be input into the network node 600 and to allow information to be output from the network node 600. This may allow a user to perform diagnostic, maintenance, repair, and other management functions for the network node 600.

[0398] Figure 7 is a block diagram of a host 700 according to various aspects described herein, and the host 700 may be Figure 4 4. As used herein, host 700 may be or include various combinations of hardware and / or software, including standalone servers, blade servers, cloud-enabled servers, distributed servers, virtual machines, containers, or processing resources in a server farm. Host 700 may provide one or more services to one or more UEs.

[0399] Host 700 includes processing circuitry 702, which is operably coupled to input / output interface 706, network interface 708, power supply 710, and memory 712 via bus 704. Other components may be included in other embodiments. The features of these components may be similar to those described with respect to previous figures (such as Figure 5 and Figure 6 ) are substantially similar in features to those described for the devices of the host 700, so that the description thereof is generally applicable to the corresponding components of the host 700.

[0400] The memory 712 may include one or more computer programs (including one or more host applications 714 and data 716), and the data 716 may include user data, such as data generated by the UE for the host 700 or data generated by the host 700 for the UE. An embodiment of the host 700 may utilize only a subset of the components shown or utilize all of the components shown. The host application 714 may be implemented in a container-based architecture and may provide support for video codecs (e.g., generic video coding (VVC), high efficiency video coding (HEVC), advanced video coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, advanced audio coding (AAC), MPEG, G.711), including transcoding for multiple different categories, types or implementations of UE (e.g., mobile phones, desktop computers, wearable display systems, head-up display systems). The host application 714 may also provide user authentication and authorization checks, and may periodically report health status, routing, and content availability to a central node (such as a device in a core network or at the edge). Thus, the host 700 may select and / or instruct different hosts for over-the-top services for the UE. The host application 714 may support various protocols, such as HTTP Live Streaming (HLS) protocol, Real Time Messaging Protocol (RTMP), Real Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), and the like.

[0401] Figure 8 800 in which the functions implemented by some embodiments may be virtualized. In the present context, virtualization means creating a virtual version of a device or apparatus, which may include virtualized hardware platforms, storage devices, and network resources. As used herein, virtualization may be applied to any device or component thereof described herein, and relates to an implementation in which at least a portion of the functions are 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), which are implemented in one or more virtual environments 800 hosted by one or more hardware nodes (such as hardware computing devices operating as network nodes, UEs, core network nodes, or hosts). In addition, in embodiments where a virtual node does not require a radio connection (e.g., a core network node or host), the node may be fully virtualized. In some embodiments, the virtualization environment 800 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a service management and orchestration framework via an O-2 interface.

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

[0403] The hardware 804 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices as described herein, such as network interfaces, input / output interfaces, etc. The software may be executed by the processing circuitry to instantiate one or more virtualization layers 806 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 808a and 808b (one or more of which may be generally referred to as VMs 808), and / or implement any functionality, features, and / or benefits associated with some embodiments described herein. The virtualization layer 806 may present a virtual operating platform that appears to be network hardware to the VMs 808.

[0404] The VM 808 includes virtual processing, virtual memory, virtual networks or interfaces, and virtual storage, and may be run by a corresponding virtualization layer 806. Different embodiments of instances of virtual devices 802 may be implemented on one or more VMs 808, and may be implemented in different ways. Virtualization of hardware is referred to as network function virtualization (NFV) in some contexts. NFV may be used to integrate many network device types onto industry-standard high-volume server hardware, physical switches, and physical storage, which may be located in data centers and customer premises equipment.

[0405] In the context of NFV, VM 808 can be a software implementation of a physical machine that runs programs as if they were executed on a physical, non-virtualized machine. Each VM 808 and a portion of the hardware 804 on which the VM executes, whether hardware dedicated to the VM and / or hardware shared by the VM with other VMs, form a separate virtual network element. Still in the context of NFV, a virtual network function is responsible for handling a specific network function running in one or more VMs 808 on the hardware 804 and corresponds to an application 802.

[0406] The hardware 804 may be implemented in a standalone network node with general or specific components. The hardware 804 may implement some functions through virtualization. Alternatively, the hardware 804 may be part of a larger hardware cluster (e.g., as in a data center or CPE) where many hardware nodes work together and are managed through management and orchestration 810, where management and orchestration 810 oversees the lifecycle management of the application 802. In some embodiments, the hardware 804 is coupled to one or more radio units, each of which includes one or more transmitters that can be coupled to one or more antennas and one or more receivers. The radio units can communicate directly with other hardware nodes through one or more appropriate network interfaces, and can be used in conjunction with virtual components to provide radio capabilities for virtual nodes, such as radio access nodes or base stations. In some embodiments, a control system 812 may be used to provide some signaling, and the control system 812 may optionally be used for communication between hardware nodes and radio units.

[0407] Fig. 9 A communication diagram is shown in which a host 902 communicates with a UE 906 via a network node 904 over a partially wireless connection according to some embodiments. Fig. 9 To describe the UE discussed in the preceding paragraphs (such as Figure 4 UE 412a and / or Figure 5 UE 500), network nodes (such as Figure 4 The network node 410a and / or Figure 6 network nodes 600) and hosts (such as Figure 4 Host 416 and / or Figure 7 An example implementation of host 700).

[0408] Similar to the host 700, an embodiment of the host 902 includes hardware, such as a communication interface, a processing circuit, and a memory. The host 902 also includes software, which is stored in the host 902 or accessible by the host 902 and can be executed by the processing circuit. The software includes a host application, which is operable to provide services to a remote user (e.g., a UE 906 connected via an over-the-top (OTT) connection 950 extending between the UE 906 and the host 902). When providing services to the remote user, the host application can provide user data sent using the OTT connection 950.

[0409] The network node 904 includes hardware that enables it to communicate with the host 902 and the UE 906. The connection 960 can be direct or through a core network (such as Figure 4The core network 406 of the present invention) and / or one or more other intermediate networks, such as one or more public, private or managed networks. For example, the intermediate network can be a backbone network or the Internet.

[0410] UE 906 includes hardware and software, which is stored in UE 906 or accessible by UE 906, and can be executed by the processing circuit of UE. The software includes a client application, such as a web browser or an operator-specific "app", which is operable to provide services to human or non-human users through UE 906 with the support of host 902. In the host 902, the executed host application can communicate with the executed client application via the OTT connection 950 terminated at UE 906 and host 902. When providing services to the user, the client application of the UE can receive request data from the host application of the host and provide user data in response to the request data. The OTT connection 950 can transmit both request data and user data. The client application of the UE can interact with the user to generate user data that it provides to the host application through the OTT connection 950.

[0411] The OTT connection 950 may extend via a connection 960 between the host 902 and the network node 904 and via a wireless connection 970 between the network node 904 and the UE 906 to provide a connection between the host 902 and the UE 906. The connection 960 and the wireless connection 970 over which the OTT connection 950 may be provided are drawn abstractly to illustrate communication between the host 902 and the UE 906 via the network node 904 without explicit reference to any intermediate devices and the precise routing of messages via these devices.

[0412] As an example of sending data via the OTT connection 950, in step 908, the host 902 provides user data, which can be implemented by executing a host application. In some embodiments, the user data is associated with a specific human user interacting with the UE 906. In other embodiments, the user data is associated with the UE 906, and the UE 906 shares the data with the host 902 without explicit human-computer interaction. In step 910, the host 902 initiates a transmission carrying the user data to the UE 906. The host 902 may initiate the transmission in response to a request sent by the UE 906. The request may be caused by human-computer interaction with the UE 906, or by the operation of a client application executed on the UE 906. According to the teachings of the embodiments described throughout the present disclosure, the transmission may be transmitted via the network node 904. Therefore, in step 912, according to the teachings of the embodiments described throughout the present disclosure, the network node 904 sends the user data carried in the transmission initiated by the host 902 to the UE 906. In step 914 , the UE 906 receives the user data carried in the transmission, which may be implemented by a client application executing on the UE 906 that is associated with a host application executed by the host 902 .

[0413] In some examples, the UE 906 executes a client application that provides user data to the host 902. The user data may be provided as a reaction or response to data received from the host 902. Therefore, in step 916, the UE 906 may provide the user data, which may be implemented by executing the client application. When providing the user data, the client application may also take into account user input received from the user via the input / output interface of the UE 906. Regardless of the specific manner in which the user data is provided, in step 918, the UE 906 initiates the transmission of the user data to the host 902 via the network node 904. In step 920, in accordance with the teachings of the embodiments described throughout the present disclosure, the network node 904 receives the user data from the UE 906 and initiates the transmission of the received user data to the host 902. In step 922, the host 902 receives the user data carried in the transmission initiated by the UE 906.

[0414] One or more of the various embodiments improve the performance of OTT services provided to UE 906 using OTT connection 950, where wireless connection 970 forms the last leg. More specifically, the teachings of these embodiments can improve OTT connections in terms of data rate, latency, power consumption, thereby providing benefits such as reduced user waiting time, relaxed file size restrictions, improved content resolution, better responsiveness, and extended battery life.

[0415] In an example scenario, plant status information may be collected and analyzed by the host 902. As another example, the host 902 may process audio and video data that may have been retrieved from the UE for use in creating a map. As another example, the host 902 may collect and analyze real-time data to help control vehicle congestion (e.g., control traffic lights). As another example, the host 902 may store surveillance videos uploaded by the UE. As another example, the host 902 may store or control access to media content, such as video, audio, VR, or AR, which may broadcast, multicast, or unicast the media content to the UE. As other examples, the host 902 may be used for energy pricing, remote control of non-time-critical power loads to balance power generation demand, location services, presentation services (such as compiling charts based on data collected from remote devices, etc.), or any other function for collecting, retrieving, storing, analyzing, and / or sending data.

[0416] In some examples, a measurement process may be provided for monitoring data rates, delays, and other factors improved by one or more embodiments. There may also be an optional network function for reconfiguring the OTT connection 950 between the host 902 and the UE 906 in response to changes in the measurement results. The measurement process and / or network function for reconfiguring the OTT connection may be implemented in software and hardware of the host 902 and / or the UE 906. In some embodiments, sensors (not shown) may be deployed in or associated with other devices through which the OTT connection 950 passes; the sensors may participate in the measurement process by providing the values ​​of the monitored quantities of the above examples or by providing the values ​​of other physical quantities from which the software can calculate or estimate the monitored quantities. The reconfiguration of the OTT connection 950 may include message formatting, retransmission settings, preferred routing, etc.; the reconfiguration does not require direct changes to the operation of the network node 904. These processes and functions may be known and practiced in the art. In some embodiments, the measurement may involve proprietary UE signaling, which facilitates the host 902 to measure throughput, propagation time, delay, etc. The measurements may be implemented in software that causes messages (particularly empty or 'dummy' messages) to be sent using the OTT connection 950 while monitoring propagation times, errors and the like.

[0417] Although the computing devices (e.g., UE, network node, host) described herein may include a combination of the hardware components shown, other embodiments may include computing devices with different combinations of components. It should be understood that these computing devices may include any suitable combination of hardware and / or software required to implement the tasks, features, functions and methods disclosed herein. The determination, calculation, acquisition or similar operations described herein may be implemented by a processing circuit, which may process information by, for example, converting the acquired information into other information, comparing the acquired information or the converted information with the information stored in the network node, and / or implementing one or more operations based on the acquired information or the converted information, and making a determination as a result of the processing. In addition, although the components are described as a single box located within a larger box, or a single box nested within multiple boxes, in practice, a computing device may include multiple different physical components constituting a single illustrated component, and functions may be divided between separate components. For example, a communication interface may be configured to include any component described herein, and / or the functions of the components may be divided between a processing circuit and a communication interface. In another example, the non-computationally intensive functions of any such component may be implemented in software or firmware, and the computationally intensive functions may be implemented in hardware.

[0418] In some embodiments, some or all of the functions described herein may be provided by a processing circuit that executes instructions stored in a memory, which in some embodiments may be a computer program product in the form of a non-transient computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by a processing circuit without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hardwired manner. In any of these specific embodiments, the processing circuit may be configured to implement the described functions, regardless of whether instructions stored on a non-transient computer-readable storage medium are executed. The benefits provided by such functionality are not limited to separate processing circuits or other components of a computing device, but are generally enjoyed by the entire computing device and / or by end users and wireless networks.

[0419] Fig.10is a flow chart of a method 1000 for facilitating non-terrestrial network (NTN) system information block (SIB) accumulation. The method 1000 may be implemented by a user equipment, such as UE 500, to facilitate non-terrestrial network (NTN) system information block (SIB) accumulation. The method 1000 may include an operation 1002 of determining whether NTN SIB accumulation should be implemented based on one or more system information (SI) configuration parameters. The method 1000 may also include an operation 1004 of implementing NTN SIB accumulation when the UE determines that NTN SIB accumulation should be implemented, or an operation 1006 of not implementing NTN SIB accumulation when the UE determines that NTN SIB accumulation should not be implemented.

[0420] In some embodiments of method 1000, additional operations may include determining that the network does not explicitly indicate whether NTN SIB accumulation should be implemented, and then determining whether NTN SIB accumulation should be implemented based on one or more SI configuration parameters. The one or more SI configuration parameters may include an SI period value. The one or more SI configuration parameters may include an epoch timer indication range and / or the number of SI windows.

[0421] The UE 500 may determine whether the network uses explicit or implicit epoch time indication based on one of: an indication in the SI, excluding the NTN SIB; an assumption of explicit epoch time in the absence of an indication of implicit epoch time; an assumption of implicit epoch time in the absence of an indication of explicit epoch time; or an inference based on parameters signaled in the SI. The one or more parameters may include validity timer updates.

[0422] Determining based on the one or more parameters may include determining whether NTN SIB accumulation should be performed based on the lack or the one or more parameters.

[0423] Method 1000 may also include operations of providing user data and forwarding the user data to a host via transmission to a network node.

[0424] Fig.11 1 is a flow chart of a method 1100 that may be implemented by a user equipment (UE) to facilitate NTN SIB accumulation. The method 1100 may include an operation 1102 of determining that NTN SIB accumulation should be implemented in the absence of an indication from the network to implement NTN SIB accumulation, and an operation 1104 of implementing NTN SIB accumulation when the UE determines that NTN SIB accumulation should be implemented.

[0425] Embodiments of method 1100 may further include decoding the NTN SIB. Decoding the NTN SIB may include: attempting to decode the NTN SIB; if the attempt to decode the NTN is successful, storing the NTN SIB and receiving and storing an additional NTN SIB in a next SI transmission, and storing a first NTN SIB and receiving and storing a second NTN SIB in the next SI transmission.

[0426] The method 1100 may also include attempting to decode the additional NTN SIB without merging the NTN SIB and the additional NTN SIB, or attempting to decode the additional NTN SIB by merging the first stored NTN SIB and the second NTN SIB.

[0427] Certain aspects of the present disclosure and embodiments thereof may provide solutions to these and other challenges. For example, methods and systems are provided for facilitating NTN SIB inhibition or accumulation in NTN to allow operation under coverage-limited conditions and to avoid decoding errors when NTN SIB content changes frequently.

[0428] For example, according to certain embodiments, systems, methods, and signaling are provided to determine whether NTN-specific SIB accumulation across SI windows in an IoT NTN cell should be allowed.

[0429] As another example, according to certain embodiments, systems, methods, and signaling are provided to support NTN-specific SIB accumulation across SI windows for UEs in an IoT NTN cell.

[0430] As yet another example, in accordance with certain embodiments, systems, methods, and signaling are provided for determining epoch time when NTN-specific SIB accumulation across SI windows is supported.

[0431] Certain embodiments may provide one or more of the following technical advantages. For example, certain embodiments may provide the following technical advantages: facilitating the accumulation of NTN-specific SIBs across multiple SI windows for NTN UEs in poor coverage areas while avoiding decoding errors due to the accumulation of NTN-specific SIBs.

[0432] Other advantages may be apparent to those skilled in the art. Some embodiments may have none, some, or all of the listed advantages.

[0433] As used herein, SIB accumulation refers to accumulation of NTN-specific SIBs (which contain satellite ephemeris and / or other assistance information for NTN; also referred to as NTN SIBs) across one or more SI windows.

[0434] One or more of the concepts described herein for IoT NTN may also be applied to NR NTN and / or other scenarios where SIB accumulation is desired for frequently changing SIBs.

[0435] As used herein, "updating the NTN SIB" means updating the content of the NTN SIB.

[0436] It may be noted that the present disclosure is about NTN SIB accumulation and does not change the defined UE behavior in terms of accumulating other legacy SIBs. That is, the UE may also accumulate other SIBs as in the terrestrial network.

[0437] It may also be noted that technically there are two different NTN SIBs (SystemInformationBlockType31 and SystemInformationBlockType32). The techniques and embodiments disclosed herein may be relevant to both types of NTN SIBs, as both may update their ephemeris between SI windows.

[0438] Disable SIB accumulation based on NTN scenario

[0439] According to certain embodiments, SIB accumulation for the NTN SIB is enabled or disabled depending on how frequently the NTN SIB is updated.

[0440] Example 1:

[0441] According to certain embodiments, the NTN SIB may need to be updated very frequently for LEO compared to GEO. Therefore, if a UE in a LEO NTN accumulates SIBs across multiple SI windows (where the SIB contents are different), SIB accumulation may need to be disabled to avoid decoding errors. However, no such inhibition is required for GEO, and the default UE behavior is to accumulate SIBs when needed.

[0442] In a particular embodiment, it is specified in the standard specification that NTN SIB accumulation for IoT NTN is prohibited for LEO and / or MEO and / or GEO.

[0443] In another specific embodiment, the prohibition of NTN SIB accumulation is described indirectly according to the validity timer configured by the network for uplink synchronization. This can be fixed in the specification, or the network can indicate to the UE whether it needs to determine NTN SIB prohibition based on the NTN validity timer configuration.

[0444] For example, for some specified validity timer value, or if the validity timer value exceeds a certain threshold, SIB accumulation is not prohibited. Otherwise, SIB accumulation is either prohibited or allowed only for a duration less than the validity timer value.

[0445] In another specific embodiment, the prohibition is only applicable to the case where the UE has already obtained the validity timer configuration value, that is, when the UE obtains the NTN SIB for the first time and / or has not yet obtained the validity timer value, SIB accumulation is not prohibited.

[0446] In another specific embodiment, if the UE has not yet acquired the validity timer configuration value, or if it is acquiring the NTN SIB for the first time, SIB accumulation is disabled.

[0447] In another specific embodiment, the network configures whether to prohibit NTN SIB accumulation in the NTN cell and use SI for broadcasting.

[0448] Example 2:

[0449] According to certain embodiments, depending on how frequently the NTN SIB is updated and / or the SI window configuration (eg, SI window length, SI periodicity, SI repetition pattern), it may be desirable to allow NTN SIB accumulation in a particular cell.

[0450] In another embodiment, specific rules are defined in the specification, which together with broadcast information and / or UE measurements allow the UE to determine whether to prohibit NTN SIB accumulation.

[0451] For example, in certain embodiments, SIB accumulation is disabled for a UE based on UE category and / or coverage enhancement classification and / or NTN scenario type (LEO / MEO / GEO).

[0452] Example 3:

[0453] According to certain embodiments, when the configured repetitions within the SI window exceed a predefined threshold, SIB accumulation is disabled for NTN UEs in good coverage (when the RSRP threshold exceeds a predefined level). Otherwise, SIB accumulation is not disabled.

[0454] Example 4:

[0455] According to certain embodiments, if the SI period exceeds the NTN SIB broadcast period, and / or the number of repetitions configured for the SIB exceeds a certain value, SIB accumulation is prohibited. The UE can determine these periods and repetition patterns based on system information and then determine whether to allow accumulation of NTN SIB.

[0456] In another embodiment, the disabled SIB accumulation forces the epoch time to not be optional (i.e., if SIB accumulation is allowed for that SIB, the epoch time will be mandatory in its SIB). This is because if the epoch time is not signaled, the epoch time is based on the start time of the downlink subframe corresponding to the end of the system information window. Therefore, if SIB accumulation occurs, confusion may arise as to where the epoch time should or should not start.

[0457] In another embodiment, the ambiguity of the above-mentioned epoch time caused by the repetition of related SIBs (e.g., systemInformationBlockType31) with the same content is alleviated by specifying rules for when to define the epoch time in conjunction with SIB repetition (when the epoch time is not explicitly indicated but defined by default rules). To this end, it is configured in the SI (e.g., in SIB1), the SIB is sent in a group of N identical SIBs (i.e., accumulation is allowed) or a group of N SI windows with the same SIB transmission (see another section

[0383] ), and the default epoch time is further configured or specified in relation to a specific one of these SIB transmissions or SI windows.

[0458] For example, the default epoch time may be the start time of a downlink subframe corresponding to the end of the first SI window with the same SIB transmission.

[0459] As another example, the default epoch time may be the start time of a downlink subframe corresponding to the end of the last SI window with the same SIB transmission.

[0460] As another example, the default epoch time may be the start of a downlink subframe corresponding to the start of a particular SI window among a set of SI windows having the same SIB transmission.

[0461] In other examples, the default epoch time is defined as the start of transmission or the end of transmission of a particular one of consecutive transmissions of SI messages containing an associated SIB with unchanged content.

[0462] Support SIB accumulation in NTN scenarios

[0463] The following method relates to the case where NTN SIB accumulation is supported in an NTN cell.

[0464] In a particular embodiment, once the UE has determined that NTN SIB accumulation is not prohibited, it is up to the UE implementation to determine the number of SI windows across which NTN SIBs may be accumulated. For example, the UE may opportunistically attempt to decode the NTN SIB by accumulating across SI windows on a trial-and-error basis. It may also use orbit prediction algorithms or other side information, such as the uplink synchronization validity timer value or previously acquired satellite ephemeris / common TA parameters, to estimate how frequently the network will update the satellite ephemeris / common TA, etc. It may then attempt to accumulate the NTN SIB in SI windows that fall within its estimated duration during which the NTN SIB contents are expected to remain unchanged.

[0465] In certain embodiments, once the UE has determined that NTN SIB accumulation is not prohibited, the number of SI windows across which NTN SIBs may be accumulated is specified in the standard specification.

[0466] In another specific embodiment, the network indicates the number of SI windows to the UE, wherein the UE may accumulate across said number of SI windows.

[0467] In a particular embodiment, a set of NTN-specific SI window lengths is specified. It includes existing SI window lengths, such as {160, 320, 480, 960, 1280, 1600} ms for NB-IoT, and adds additional lengths, such as 3200ms and 6400ms. Similarly, as another example, the existing SI window lengths {1, 2, 5, 10, 15, 20, 40, 60, 80, 120, 160, 200} ms for LTE-M can also be extended to include additional lengths such as 240ms, 280ms, 320ms and 360ms. In the case of longer SI windows, the network can configure a larger number of repetitions of NTN SIBs within the SI window. It can eliminate the need to accumulate NTN SIBs across multiple SI windows, or reduce the number of SI windows that the UE needs to accumulate across in order to correctly decode the NTN SIB.

[0468] In a specific embodiment, the new SI window length applies to all SI windows in the NTN. Optionally, it applies only to SI windows containing NTN SIBs, and information about which SI window contains SI messages with NTN SIBs may be specified or indicated to the UE in the SI.

[0469] In certain embodiments, existing values ​​in a set for configuring the SI window length are fully or partially reinterpreted as different values ​​for use in IoT NTN scenarios.

[0470] In particular embodiments, the values ​​in the set used to configure the SI window length may differ depending on the satellite orbit altitude (eg, the set of values ​​differs for LEO and GEO satellite orbits).

[0471] In certain embodiments, existing values ​​in the set for configuring "si-Periodicity" are either fully reused or new values ​​are added (eg, longer values ​​are appended) for use in IoT NTN scenarios.

[0472] In certain embodiments, existing values ​​in the set for configuring "si-Periodicity" are fully or partially reinterpreted as different values ​​for use in IoT NTN scenarios.

[0473] In certain embodiments, the values ​​in the set used to configure "si-Periodicity" may differ depending on the satellite orbit altitude (eg, the set of values ​​may differ for LEO and GEO satellite orbits).

[0474] In certain embodiments, existing values ​​in the set for configuring "si-RadioFrameOffset" are either fully reused or new values ​​are added (e.g., longer values ​​are appended) for use in IoT NTN scenarios.

[0475] In certain embodiments, existing values ​​in the set for configuring "si-RadioFrameOffset" are fully or partially reinterpreted as different values ​​for use in IoT NTN scenarios.

[0476] In certain embodiments, the values ​​in the set used to configure "si-RadioFrameOffset" may differ depending on the satellite orbit altitude (eg, the set of values ​​differs for LEO and GEO satellite orbits).

[0477] In certain embodiments, existing values ​​in the set used to configure "si-RepetitionPattern" are either fully reused or new values ​​are added (eg, longer values ​​are appended) for use in IoT NTN scenarios.

[0478] In certain embodiments, existing values ​​in the set used to configure "si-RepetitionPattern" are fully or partially reinterpreted as different values ​​for use in IoT NTN scenarios.

[0479] In particular embodiments, the values ​​in the set used to configure "si-RepetitionPattern" may differ depending on the satellite orbit altitude (eg, the set of values ​​differs for LEO and GEO satellite orbits).

[0480] Similarly, in some embodiments, if SIB accumulation is supported in NTN scenarios, the epoch time becomes mandatory.

[0481] Details of network indication and / or assistance information accumulated for the NTN SIB

[0482] According to certain embodiments, the network uses one or more of the following methods to indicate one or more of the above information to the UE in the NTN cell.

[0483] In a specific embodiment, the network may indicate 1-bit information about SIB accumulation prohibition using the following:

[0484] MIB

[0485] SIBs other than the NTN SIB, such as in SIB1, such as in the SI scheduling information.

[0486] In addition to the existing SI-RNTI, a different SI-RNTI is defined and specified to indicate that NTN SIB accumulation is allowed. This enables selectively allowing accumulation per SI message (so SIB is selective) and can also dynamically change between SI message transmissions and SI windows.

[0487] In another specific embodiment, SIB accumulation targets a specific NTN SIB, which is the NTN SIB required for uplink synchronization (SystemInformationBlockType31) or the NTN SIB for non-contiguous coverage (SystemInformationBlockType32). This can be specified and / or additionally indicated to the UE. Optionally, SIB accumulation information applies to both NTN SIBs.

[0488] Further embodiments regarding configuration of SIB accumulation in IoT NTN

[0489] As mentioned earlier, the number of repeated SIB transmissions can be configured and signaled in another SIB (of a specific SIB, for example, an NTNSIB such as systemInformationBlockType31 or systemInformationBlockType 32), preferably a SIB where the content is static or semi-static, so that the UE can apply SIB accumulation to this SIB without restriction.

[0490] The indication will first include an indication of the number N of consecutive SIB transmissions without updating the content (i.e. the number of identical repeated SIB transmissions). Thus, the transmissions of the relevant SIBs will be sent in a repeated set of N identical transmissions (i.e. the content does not change). Thus, there will be a set of N unchanged SIB transmissions followed by another set of N identical SIB transmissions, where an update of the SIB content may only occur between the two sets.

[0491] In order to allow the UE to identify a priori the start of a set of N identical SIB transmissions, a reference is needed. This reference can be specified and a natural definition could be: the first transmission of a set of identical SIB transmissions occurs in the first SI window (containing an SI message with associated SIBs) starting at or after SFN=0. N identical transmissions will be followed by a potential updated transmission, marking the first transmission of another set of N identical SIB transmissions.

[0492] The disadvantage of using SFN=0 as a reference is that this is somewhat limiting, as it forces the SIB to be updated (or at least the UE must assume that there is an update) every SFN period wrap-around (which occurs after 1024 SFNs). This will exclude repetitions across SI windows when the SI window period is 4096 frames, 2048 frames, or 1024 frames, and will only allow accumulation of two SI window transmissions when the SI window period is 512 frames. If Hyper-SFN is considered for IoT-NTN, this can be easily solved by taking the start of H-SFN=0 as the reference instead of SFN=0 as the reference. Otherwise, by combining SFN=0 with UTC as the reference, an unambiguous reference that does not limit the possibility of repetition and accumulation can be achieved, for example, the occurrence of SFN=0 that is closest to UTC=xxxxx. This can still be specified, as UTC "xxxxx" can also be specified, as long as "xxxxx" is a time that occurred in the past, such as the beginning of UTC timing.

[0493] The configuration parameter N is described above as indicating the number of consecutive identical transmissions of the relevant SIB. In an alternative embodiment, the configuration parameter N instead indicates the number of SI windows (in which SI messages containing the relevant SIB are sent) in which the relevant SIB will remain unchanged. This means that the number of repetitions within an SI window is multiplied by the number of SI windows indicated by N to obtain the number of consecutive transmissions of the relevant SIB with unchanged content. For example, if the relevant SIB is sent twice within each SI window (in which SI messages containing the relevant SIB are sent), and the SIB remains unchanged for N=2 such SI windows, the number of identical SIB transmissions is 2x2=4.

[0494] In a particular embodiment, N is not indicated in the SI, but is specified in the standard specification. In this case, different N values ​​may be specified for different network deployment scenarios (e.g., for LEO, MEO, GEO, and HAPS / HIBS deployments).

[0495] In another specific embodiment, N is configured in the USIM, for example, when the USIM is provisioned (eg, on a SIM card), or configured in the USIM using Over-The-Air (OTA) configuration.

[0496] In a particular embodiment, a reference to the start of a set of N identical SIB transmissions or a set of N SI windows (in which SI messages containing related SIBs are sent) (the related SIBs will remain unchanged) is configured in the system information, for example in SIB1.

[0497] In another specific embodiment, the network does not necessarily need to send a different SIB after "N" identical transmissions. In practice, it may send the same SIB in the next "N" transmissions, but as far as UE behavior is concerned, the UE will assume that the SIB content may be different after "N" transmissions, and it should avoid accumulating SIBs beyond the indicated "N" transmissions.

[0498] References

[0499] 1. TR 38.811, Studies on New Radio (NR) supporting non-terrestrial networks

[0500] 2. TR 38.821, Solutions for NR supporting non-terrestrial networks, 3GPP, 16.1.0, June 2021.

[0501] 3. RP-193234, Solutions for NR supporting non-terrestrial networks (NTN), 3GPP RAN#86

[0502] 4. RP-193235, Study on NB-Io / eMTC support for non-terrestrial networks, 3GPP RAN#86

[0503] 5. RP-202689, Study on NB-IoT / eMTC Support for Non-Terrestrial Networks, RAN #90, December 2020.

[0504] 6. RP-211601, NB-IoT / eMTC Support for Non-Terrestrial Networks (NTN), RAN#92-e, June 2021.

[0505] 7.TR 36.763, Study on Narrowband Internet of Things (NB-IoT) / Enhanced Machine Type Communications (eMTC) support for Non-Terrestrial Networks (NTN), 3GPP, 17.0.0, June 2021.

[0506] 8.R2-2203810, Support of non-terrestrial networks in NB-IoT and eMTC, 3GPP RAN2#117-e.

Claims

1. A method implemented by a user equipment UE for facilitating non-terrestrial network NTN system information block SIB accumulation, the method comprising: determining whether NTN SIB accumulation should be performed based on one or more system information SI configuration parameters; as well as When the UE determines that NTN SIB accumulation should be implemented, implementing NTN SIB accumulation; or When the UE determines that NTN SIB accumulation should not be performed, NTN SIB accumulation is not performed.

2. The method according to claim 1, further comprising the steps of: determining whether the network has not explicitly indicated that NTN SIB accumulation should be performed; Thereafter, based on one or more SI configuration parameters, it is determined whether NTN SIB accumulation should be implemented.

3. The method according to any one of claims 1 to 2, wherein: The one or more SI configuration parameters include an SI period value.

4. The method according to any one of claims 1 to 3, wherein: The one or more SI configuration parameters include an epoch timer indication range and / or a number of SI windows.

5. The method according to any one of claims 1 to 2, wherein: The UE determines whether the network is using explicit or implicit epoch time indication based on one of: Instructions in SI, except for the NTN SIB; Assumptions about explicit epoch times in the absence of indications of implicit epoch times; In the absence of an indication of an explicit epoch time, assumptions about implicit epoch time; or Inference based on parameters signaled in the SI.

6. The method according to any one of claims 1 to 2, wherein: The one or more parameters include a validity timer update.

7. The method according to any one of claims 1 to 2, wherein: Determining based on the one or more parameters includes determining whether NTN SIB accumulation should be performed based on the lack or the one or more parameters.

8. The method according to any one of claims 1 to 7, further comprising: Provide user data; as well as The user data is forwarded to the host via transmission to a network node.

9. A method implemented by a user equipment UE for facilitating NTN SIB accumulation, the method comprising: In the absence of an indication from the network to perform NTN SIB accumulation, determining whether NTN SIB accumulation should be performed; as well as When the UE determines that NTN SIB accumulation should be performed, NTN SIB accumulation is performed.

10. The method according to claim 9, further comprising: Decode the NTN SIB.

11. The method according to claim 10, wherein: Decoding the NTN SIB includes: attempting to decode the NTN SIB; If the attempt to decode the NTN is successful, the NTN SIB is stored, and an additional NTN SIB is received and stored in the next SI transmission. The first NTN SIB is stored, and the second NTN SIB in the next SI transmission is received and stored.

12. The method according to claim 11, further comprising: attempting to decrypt the additional NTN SIB without merging the NTN SIB with the additional NTN SIB; or An attempt is made to decode the additional NTN SIB by combining the first stored NTN SIB and the second NTN SIB.

13. A user equipment for facilitating NTN SIB accumulation in an NTN to allow operation under coverage-limited conditions and to avoid decoding errors when the NTN SIB content changes frequently for one or both of implicit and explicit epoch time indications, comprising: Processing circuitry configured to implement any of the steps of any one of claims 1-12; as well as A power supply circuit is configured to supply power to the processing circuit.

14. A user equipment (UE) for facilitating NTN SIB accumulation in an NTN to allow operation under coverage-limited conditions and to avoid decoding errors when the NTN SIB content changes frequently for one or both of implicit and explicit epoch time indications, the UE comprising: an antenna configured to transmit and receive wireless signals; a radio front end circuit connected to the antenna and to the processing circuit and configured to condition signals transmitted between the antenna and the processing circuit; The processing circuit is configured to implement any of the steps according to any one of claims 1-12; an input interface connected to the processing circuitry and configured to allow information to be input to the UE for processing by the processing circuitry; an output interface connected to the processing circuit and configured to output information that has been processed by the processing circuit from the UE; as well as A battery is connected to the processing circuit and configured to supply power to the UE.

15. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; as well as A network interface configured to initiate transmission of the user data to a cellular network for transmission to a user equipment UE, wherein the UE comprises a communication interface and a processing circuit, the communication interface and processing circuit of the UE being configured to implement any operation according to any one of claims 1-12 to receive the user data from the host.

16. The host according to claim 15, wherein: The cellular network also includes a network node configured to communicate with the UE to send the user data from the host to the UE.

17. A host according to any one of claims 15-16, wherein: The processing circuitry of the host is configured to execute a host application to provide the user data; and The host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.

18. A method implemented by a host operating in a communication system, the communication system further comprising a network node and a user equipment UE, the method comprising: Providing user data for the UE; as well as Initiating a transmission carrying the user data to the UE via a cellular network including the network node, wherein the UE implements any of the operations of any of claims 1-12 to receive the user data from the host.

19. The method according to claim 18, further comprising: At the host, a host application associated with the client application executing on the UE is executed to receive the user data from the host application.

20. The method according to any one of claims 18-19, further comprising: sending, at the host, input data to the client application executing on the UE, the input data being provided by executing the host application, Wherein, the user data is provided by the client application in response to the input data from the host application.

21. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; as well as A network interface configured to initiate transmission of the user data to a cellular network for transmission to a user equipment UE, wherein the UE comprises a communication interface and a processing circuit, the communication interface and processing circuit of the UE being configured to implement any of the steps according to any one of claims 1-12 to send the user data to the host.

22. The host according to claim 21, wherein: The cellular network also includes a network node configured to communicate with the UE to send the user data from the UE to the host.

23. A host according to any one of claims 21-22, wherein: The processing circuitry of the host is configured to execute a host application to provide the user data; and The host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.

24. A method implemented by a host configured to operate in a communication system, the communication system further comprising a network node and a user equipment UE, the method comprising: At the host, user data sent by the UE to the host via the network node is received, wherein the UE implements any steps according to any one of claims 1-12 to send the user data to the host.

25. The method according to claim 24, further comprising: At the host, a host application associated with the client application executing on the UE is executed to receive the user data from the UE.

26. The method according to any one of claims 24-25, further comprising: sending, at the host, input data to the client application executing on the UE, the input data being provided by executing the host application, Wherein, the user data is provided by the client application in response to the input data from the host application.

27. A method of a user equipment or network node for facilitating NTN SIB accumulation in an NTN to allow operation under coverage-limited conditions and to avoid decoding errors when the NTN SIB content changes frequently for one or both of implicit and explicit epoch time indications, the method comprising: Any one of the steps, features or functions of the user equipment or network node described in this document, alone or in combination with other steps, features or functions described in this document.

28. The method according to claim 27, further comprising: One or more additional user equipment steps, features, or functions described herein.

29. The method according to any one of claims 27-28, further comprising: Provide user data; as well as The user data is forwarded to a host computer via transmission to the network node.

30. A user equipment of a network node having hardware, the hardware being configured to: facilitate NTN SIB accumulation in an NTN by implementing any one of the user equipment or network node steps, features or functions described herein alone or in combination with other steps, features or functions described herein to allow operation under coverage-limited conditions and to avoid decoding errors when the NTNSIB content changes frequently for both implicit and explicit epoch time indications.

Images