Non-terrestrial network epoch time indication considering SFN cycle
By receiving and processing non-terrestrial network system information from network nodes in user equipment, determining system frame period count and support information indication, the problem of information transmission efficiency and accuracy of non-terrestrial network system is solved, and efficient and reliable system information transmission is achieved.
Patent Information
- Application Number
- JP2024547686
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-02-14
- Filing Date
- 2023-02-13
- Publication Date
- 2025-03-18
- Estimated Expiration
- Not applicable · inactive patent
AI Technical Summary
The prior art is difficult to efficiently transmit and receive system information in non-terrestrial networks, especially in 5G networks, where there are challenges in system information transmission efficiency and accuracy of non-terrestrial networks.
By setting a transceiver in the user equipment, receiving non-terrestrial network system information from the network node, and using processing circuits to determine the system frame period count and support information indication, thereby derive support information.
It realizes efficient transmission and reception of non-terrestrial network system information, improves the accuracy and reliability of system information, and is suitable for non-terrestrial network scenarios in 5G networks.
Smart Images

Figure 2025507376000001_ABST
Abstract
Description
[Technical field]
[0001] The present invention relates to transmitting system information relating to non-terrestrial networks, and more particularly to an apparatus and method for generating, signaling, receiving and / or utilizing system information relating to non-terrestrial networks. [Background technology]
[0002] Currently, the 3rd Generation Partnership Project (3GPP) is working on technical specifications for the next generation of cellular technology, also known as the fifth generation (5G).
[0003] One objective is to provide a single technical framework that addresses all usage scenarios, requirements and deployment scenarios, including at least enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC) and massive machine-type communications (mMTC) (see, for example, 3GPP TR 38.913 version 16.0.0 section 6, etc.). For example, eMBB deployment scenarios can include indoor hotspots, high-density urban, rural, urban macrocell and high-speed, URLLC deployment scenarios can include industrial control systems, mobile healthcare (remote monitoring, diagnosis and treatment), real-time control of vehicles, wide-area monitoring and control systems for smart grids, and mMTC deployment scenarios can include scenarios involving a large number of devices with non-time-critical data transfer, such as smart wearables and sensor networks. eMBB and URLLC services are similar in that both require very high bandwidth, but differ in that URLLC services may preferably require ultra-low latency.
[0004] A second objective is to achieve forward compatibility: backward compatibility with Long Term Evolution (LTE, LTE-A) cellular systems is not required, which facilitates completely new system designs and / or the introduction of new features.
[0005] One prominent feature of 5G is the introduction of non-terrestrial networks (NTNs), including satellites, in the communication path between user devices and the network. Summary of the Invention
[0006] One non-limiting illustrative embodiment facilitates efficient transmission and reception of system information regarding non-terrestrial networks.
[0007] In an embodiment, the techniques disclosed herein feature a user device having a transceiver that, during operation, receives system information relating to a non-terrestrial network from a network node; and processing circuitry that, during operation, (i) determines from the system information an indication of a system frame cycle count and an aiding information indication, (ii) determines an epoch time for deriving aiding information based on the indication of the system frame cycle count, and (iii) derives the aiding information based on the epoch time and the aiding information indication.
[0008] The general or specific embodiments may be realized as a system, a method, an integrated circuit, a computer program, a storage medium, or any combination thereof.
[0009] Further advantages and benefits of the disclosed embodiments will become apparent from the specification and drawings. The advantages and / or benefits may be obtained individually by various embodiments and features of the specification and drawings, not all of which need be provided in order to obtain one or more of such advantages and / or benefits. [Brief description of the drawings]
[0010] In the following, exemplary embodiments are explained in more detail with reference to the accompanying drawings. [Figure 1] 1 illustrates an example architecture of a 3GPP NR system. [Diagram 2] FIG. 1 is a schematic diagram showing functional separation between NG-RAN and 5GC. [Diagram 3]FIG. 1 is a sequence diagram for an RRC connection setup / reconfiguration procedure. [Figure 4] FIG. 1 is a schematic diagram showing usage scenarios of Enhanced mobile broadband (eMBB), Massive Machine Type Communications (mMTC) and Ultra Reliable and Low Latency Communications (URLLC). [Diagram 5] FIG. 1 is a block diagram illustrating an example 5G system architecture for a non-roaming scenario. [Figure 6] 1 illustrates an exemplary NG RAN architecture based on transparent satellites. [Figure 7] 1 illustrates an exemplary NG RAN architecture based on regenerative satellites. [Figure 8] 1 illustrates an example scenario in which multiple UEs are served by a satellite. [Figure 9] 1 shows an example NTN configuration with satellites moving at specific speeds. [Figure 10] 1 illustrates an exemplary variation of a common timing advance. [Figure 11] 1 illustrates an exemplary SFN cycle as supported by NR. [Figure 12] FIG. 2 is a schematic diagram illustrating time-dependent SFN values and epoch time values. [Figure 13] FIG. 13 is a schematic diagram illustrating time-dependent SFN and epoch time values for system information updates and repetitions. [Figure 14] FIG. 2 is a block diagram illustrating an example configuration of a user device and a network node. [Figure 15] FIG. 2 is a schematic diagram illustrating a first exemplary implementation in which the system frame number count is explicitly signaled in the system information; [Figure 16] FIG. 13 is a schematic diagram illustrating a second exemplary implementation in which the system frame number count is signaled by the hyperframe number. [Figure 17]FIG. 2 is a flow diagram illustrating a first exemplary implementation on the network side. [Figure 18] FIG. 2 is a flow diagram illustrating a first exemplary implementation on the user device side. [Figure 19] FIG. 11 is a flow diagram illustrating a second exemplary implementation on the network side. [Figure 20] FIG. 11 is a flow diagram illustrating a second exemplary implementation on the user device side. [Figure 21] FIG. 13 is a schematic diagram illustrating a third exemplary implementation in which a system frame number count is informed by a validity period. [Figure 22] FIG. 11 is a flow diagram illustrating a third exemplary implementation on the network side. [Figure 23] FIG. 11 is a flow diagram illustrating a third exemplary implementation on the user device side. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0011] 5G NR system architecture and protocol stack 3GPP is working on the next release of the fifth generation of cellular technology, simply called 5G, which includes the development of a new radio access technology (NR) that will operate at frequencies in the range up to 100 GHz. The first version of the 5G standard will be finalized at the end of 2017, enabling prototyping and commercial deployment of smartphones compliant with the 5G NR standard.
[0012] In particular, the overall system architecture assumes a Next Generation-Radio Access Network (NG-RAN) including gNBs, providing NG-Radio Access User Plane (SDAP / PDCP / RLC / MAC / PHY) and Control Plane (RRC) protocol termination for UEs. The gNBs are interconnected by an Xn interface. The gNBs are also connected by a Next Generation (NG) interface with the Next Generation Core (NGC), more specifically to the Access and Mobility Management Function (AMF) (e.g., a specific core entity that runs the AMF) by an NG-C interface, and to the User Plane Function (UPF) (e.g., a specific core entity that runs the UPF) by an NG-U interface. The NG-RAN architecture is shown in FIG. 1 (see, for example, 3GPP TS 38.300 v16.3.0 section 4).
[0013] The user plane protocol stack for NR (see, for example, 3GPP TS 38.300 section 4.4.1) comprises the Packet Data Convergence Protocol (PDCP, see TS 38.300 section 6.4), Radio Link Control (RLC, see TS 38.300 section 6.3), and Medium Access Control (MAC, see TS 38.300 section 6.2) sublayers, which are terminated at the gNB on the network side. In addition, a new Access Stratum (AS) sublayer (Service Data Adaptation Protocol, SDAP) has been introduced on top of PDCP (see, for example, 3GPP TS 38.300 sub-clause 6.5). A control plane protocol stack is also defined for NR (see, for example, TS 38.300 section 4.4.2). An overview of layer 2 functions is given in TS 38.300 sub-clause 6. RRC layer functions are listed in TS 38.300 sub-clause 7.
[0014] For example, the medium access control layer handles logical channel multiplexing and scheduling and scheduling related functions, including handling various numerologies.
[0015] The physical layer (PHY) is responsible for e.g. coding, PHY HARQ processing, modulation, multi-antenna processing and mapping of signals to appropriate physical time-frequency resources. It also handles mapping of transport channels to physical channels. The physical layer provides services to the MAC layer in the form of transport channels. A physical channel corresponds to a set of time-frequency resources used for transmission of a particular transport channel, and each transport channel is mapped to a corresponding physical channel. For example, the physical channels are PRACH (Physical Random Access Channel), PUSCH (Physical Uplink Shared Channel) and PUCCH (Physical Uplink Control Channel) for uplink, and PDSCH (Physical Downlink Shared Channel), PDCCH (Physical Downlink Control Channel) and PBCH (Physical Broadcast Channel) for downlink.
[0016] Use cases / deployment scenarios for NR can include enhanced Mobile Broadcast (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine Type Communication (mMTC), which have diverse requirements in terms of data rate and coverage. For example, eMBB is expected to support peak data rates (20 Gbps in downlink and 10 Gbps in uplink) and user-experienced data rates on the order of three times that offered by IMT-Advanced. On the other hand, the URLLC case requires ultra-low latency (0.5 ms for user plane latency on UL and DL respectively) and high reliability (1-10 ms latency within 1 ms). -5 Finally, mMTC is preferably designed for high connection density (1,000,000 devices / km in urban environments). 2), large coverage in harsh environments, and extremely long battery life (15 years) for low-cost devices.
[0017] Therefore, OFDM numerology (e.g., subcarrier spacing, OFDM symbol duration, cyclic prefix (CP) duration, number of symbols per scheduling interval) suitable for one use case may not work well for another use case. For example, low latency services may preferably require a shorter symbol duration (hence a larger subcarrier spacing) and / or fewer symbols per scheduling interval (a.k.a. TTI) than mMTC services. Furthermore, deployment scenarios with large channel delay spreads may preferably require a longer CP duration than scenarios with short delay spreads. Subcarrier spacing should be optimized accordingly to retain similar CP overhead. NR can support more than one subcarrier spacing value. Correspondingly, subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, ... are currently being considered. Symbol duration T u and the subcarrier spacing Δf is Δf=1 / T u Similar to LTE systems, the term "resource element" can be used to denote the smallest resource unit consisting of one subcarrier for the duration of one OFDM / SC-FDMA symbol.
[0018] In the new radio system 5G-NR for each numerology and carrier, a resource grid of subcarriers and OFDM symbols is defined for the uplink and downlink, respectively. Each element in the resource grid is called a resource element and is identified based on a frequency index in the frequency domain and a symbol position in the time domain (see, for example, 3GPP TS 38.211 v16.3.0 section 4). For example, downlink and uplink transmissions are organized into frames with a duration of 10 ms, each frame consisting of 10 subframes of 1 ms duration each. In a 5gNR implementation, the number of consecutive OFDM symbols per subframe depends on the subcarrier spacing configuration. For example, for a subcarrier spacing of 15 kHz, a subframe has 14 OFDM symbols (similar to an LTE-compliant implementation, assuming a normal cyclic prefix). On the other hand, for a subcarrier spacing of 30 kHz, a subframe has two slots, each of which contains 14 OFDM symbols.
[0019] 5G NR Functional Split Between NG-RAN and 5GC Figure 2 shows the functional division between NG-RAN and 5GC. The NG-RAN logical node is a gNB or a ng-eNB. The 5GC has logical nodes AMF, UPF and SMF.
[0020] In particular, the gNB and ng-eNB host the following main functions: - Functions for radio resource management such as radio bearer control, radio admission control, connection mobility control, dynamic allocation of resources to UEs in both uplink and downlink (scheduling) -IP header compression, encryption and data integrity protection - Selection of AMF at UE attachment when routing to the AMF cannot be determined from information provided by the UE -Routing of user plane data to UPF - Routing of control plane information to AMF -Connection setup and release - Scheduling and sending paging messages Scheduling and transmission of system broadcast information (initiated by AMF or OAM) - Measurement and measurement report configuration for mobility and scheduling -Transport level packet marking in the uplink -Session management -Network slicing support - QoS flow management and mapping to data radio bearers Support for UE in RRC_INACTIVE state -NAS message delivery function -Wireless access network sharing -Dual Connectivity -Tight interworking between NR and E-UTRA
[0021] The Access and Mobility Management Function (AMF) hosts the following main functions: -NAS (Non-Access Stratum) signaling termination -NAS signaling security -AS (Access Stratum) security control -Inter-Core Network (CN) Node Signaling for Mobility Between 3GPP Access Networks Idle mode UE reachability (including control and execution of paging retransmissions) -Registration area management - Support for intra-system and inter-system mobility -Access authentication -Access authentication including roaming privilege check -Mobility management controls (subscriptions and policies) -Network slicing support -SMF (Session Management Function) selection
[0022] Additionally, the User Plane Function (UPF) hosts the following main functions: -Anchor points for intra-RAT / inter-RAT mobility (when applicable) -External PDU session points for interconnection to data networks -Packet routing and forwarding - Packet inspection and user plane part for policy rule enforcement -Traffic usage report - An uplink classifier that supports routing of traffic flows to a data network - Branching points to support multi-homed PDU sessions - QoS processing for user plane, e.g. packet filtering, gating, UL / DL rate enforcement -Uplink traffic validation (SDF to QoS flow mapping) Downlink packet buffering and downlink data indication triggering
[0023] Finally, the SMF (Session Management Function) hosts the following main functions: -Session management - UE IP address allocation and management -UP function selection and control -Configuring traffic steering in the User Plane Function (UPF) to route traffic to the appropriate destination -Policy enforcement and QoS control section -Downlink data indication
[0024] RRC connection establishment and re-establishment procedures Figure 3 shows the interactions between the UE, gNB and AMF (5GC entities) for the UE's transition from RRC_IDLE to RRC_CONNECTED for the NAS part (see TS 38.300).
[0025] RRC is a higher layer signaling (protocol) used for configuration between the UE and the gNB. In particular, this transition involves the AMF preparing UE context data (including, for example, PDU session context, security keys, UE radio capabilities, and UE security capabilities) and sending it to the gNB with an INITIAL CONTEXT SETUP REQUEST. The gNB then activates AS security with the UE, which is performed by the gNB sending a SecurityModeCommand message to the UE and the UE responding to the gNB with a SecurityModeComplete message. The gNB then performs reconfiguration to configure the Signaling Radio Bearer (SRB) 2 and Data Radio Bearer (DRB) by sending an RRCReconfiguration message to the UE and in response, receiving an RRCReconfigurationComplete from the UE by the gNB. For signaling-only connections, the steps related to RRCReconfiguration are skipped since SRB2 and DRB are not configured. Finally, the gNB informs the AMF that the configuration procedure is completed with an INITIAL CONTEXT SETUP RESPONSE.
[0026] Therefore, in the present disclosure, a fifth generation core (5GC) entity (e.g., AMF, SMF, etc.) is provided, which includes a control circuit that establishes a Next Generation (NG) connection with a gNB during operation, and a transmitter that transmits an initial context setup message to the gNB via the NG connection during operation to perform a signaling radio bearer configuration between the gNB and a user equipment (UE). In particular, the gNB transmits Radio Resource Control (RRC) signaling including a resource allocation configuration information element to the UE via the signaling radio bearer. Then, the UE performs uplink transmission or downlink reception based on the resource allocation configuration.
[0027] IMT usage scenarios after 2020 Figure 4 shows some use cases for 5G NR. Three use cases are considered in 3GPP NR (3rd Generation Partnership Project New Radio) that are expected to support a wide range of services and applications by IMT-2020. Phase 1 specifications for enhanced mobile broadband (eMBB) have been finalized. In addition to further extending eMBB support, current and future research will include standardization of URLLC and massive machine-based communications. Figure 4 shows some of the expected usage scenarios for IMT beyond 2020 (see, for example, Figure 2 in ITU-R M.20183).
[0028] URLLC use cases have stringent requirements for capabilities such as throughput, latency and availability and have been envisioned as one of the enablers for future vertical applications such as wireless control of industrial manufacturing or manufacturing processes, remote medical surgery, delivery automation in smart grids, transportation safety, etc. URLLC ultra-reliability is supported by identifying technologies that meet the requirements set by TR 38.913 version 16.0.0. For NR URLLC in Release 15, the key requirements include a target user plane delay of 0.5 ms for UL (uplink) and 0.5 ms for DL (downlink). The general URLLC requirement for a single transmission of a packet is a Block Error Rate (BLER) of 1E-5 for a packet size of 32 bytes with a user plane delay of 1 ms.
[0029] From the physical layer perspective, reliability can be improved in many possible ways. Current scope for improving reliability includes defining separate CQI tables for URLLC, more compact DCI formats, PDCCH repetition, etc. However, as NR becomes more stable and developed (due to the main requirement of NR URLLC), the scope for achieving ultra-reliability can be expanded. Specific use cases for NR URLLC in Rel.15 include augmented reality / virtual reality (AR / VR), e-health, e-safety and mission-critical applications.
[0030] Furthermore, technology extensions aimed at NR URLLC aim at improving latency and reliability. Technology extensions for latency improvement include configurable numerology, non-slot-based scheduling with flexible mapping, grant-free (configured grant) uplink, slot-level repetition for data channels, and downlink preemption. Preemption means stopping a transmission for which resources have already been allocated, and using the already allocated resources for another transmission that has been requested later but has lower latency / higher priority requirements. Thus, an already granted transmission is preempted by a later transmission. Preemption is applicable independently of the specific service type. For example, a transmission for service type A (URLLC) can be preempted by a transmission for service type B (eMBB, etc.). Technology extensions for reliability improvement include dedicated CQI / MCS tables for a target BLER of 1E-5.
[0031] Massive Machine Type Communication (mMTC) use cases are typically characterized by a very large number of connected devices transmitting a relatively small amount of non-delay sensitive data. The devices are required to be low cost and have a very long battery life. From an NR perspective, utilizing very narrow bandwidth portions is one possible solution that has power saving from the UE perspective and allows for a long battery life.
[0032] As mentioned above, it is expected that the reliability range in NR will be wider. One main requirement for all cases, especially for URLLC and mMTC, is high or ultra-reliability. Several mechanisms can be considered to improve reliability from a radio perspective and from a network perspective. In general, there are several important potential areas that can help improve reliability. Among these areas are compact control channel information, data / control channel repetition, and diversity with respect to frequency, time and / or spatial domains. These areas are generally applicable to reliability, regardless of the specific communication scenario.
[0033] Further use cases with more stringent requirements have been identified for NR URLLC, such as factory automation, transportation, and power distribution, including power distribution. The more stringent requirements include higher reliability (10 6 level), higher availability, packet sizes up to 256 bytes, time synchronization on the order of a few μs, where the numbers here could be one or a few μs depending on the frequency range and short latencies on the order of 0.5-1 ms depending on the use case, especially the target user plane delay of 0.5 ms.
[0034] Furthermore, for NR URLLC, several technology enhancements have been identified from the physical layer point of view. Among these are PDCCH (Physical Downlink Control Channel) extensions related to compact DCI, PDCCH repetition, and increased PDCCH monitoring. Furthermore, UCI (Uplink Control Information) extensions related to enhanced HARQ (Hybrid Automatic Repeat Request) and CSI feedback extensions. Also, PUSCH extensions related to minislot level hopping and retransmission / repetition extensions have been identified. The term "minislot" refers to a TTI (Transmission Time Interval) that contains fewer symbols than a slot (a slot containing 14 symbols).
[0035] QoS Control The 5G Quality of Service (QoS) model is based on QoS flows and supports both QoS flows that require a guaranteed flow bit rate (GBR QoS flows) and QoS flows that do not require a guaranteed flow bit rate (non-GBR QoS flows). At the NAS level, QoS flows are therefore the finest granularity of QoS differentiation in a PDU session. QoS flows are identified within a PDU session by a QoS Flow Identifier (QFI) that is carried in the encapsulation header over the NG-U interface.
[0036] For each UE, the 5GC establishes one or more PDU sessions. For each UE, the NG-RAN establishes at least one Data Radio Bearer (DRB) with the PDU session, and additional DRBs for the QoS flows of the PDU session may be configured subsequently (when to do so is up to the NG-RAN), e.g. as shown above with reference to Figure 3. The NG-RAN maps packets belonging to different PDU sessions to different DRBs. NAS level packet filters in the UE and 5GC associate UL and DL packets with QoS flows, while AS level mapping rules in the UE and NG-RAN associate UL and DL QoS flows with DRBs.
[0037] FIG. 5 illustrates the 5G NR non-roaming reference architecture (see TS 23.501 v16.6.0, section 4.2.3). Application Functions (AFs), e.g., external application servers hosting 5G services as exemplarily described in FIG. 4, interact with the 3GPP core network to provide services, e.g., support application influence on traffic routing, interact with a policy framework (see Policy Control Function (PCF)) for policy control or access to a Network Exposure Function (NEF), etc. Based on the operator's deployment, application functions that are considered trusted by the operator may be allowed to interact directly with the relevant network functions. Application functions that are not allowed by the operator to directly access network functions interact with the relevant network functions using an external exposure framework via the NEF.
[0038] 5 shows further functional parts of the 5G architecture, namely, a Network Slice Selection Function (NSSF), a Network Repository Function (NRF), a Unified Data Management Function (UDM), an Authentication Server Function (AUSF), an Access Mobility Management Function (AMF), a Session Management Function (SMF), and a Data Network (DN), such as operator services, Internet access, or third-party services. All or part of the core network functions and application services may be deployed and executed on a cloud computing environment.
[0039] Thus, the present disclosure provides an application server (e.g., an AF in a 5G architecture) comprising a transmitter that, during operation, sends a request including QoS requirements for at least one of URLLC, eMBB and mMTC services to at least one of 5GC functions (e.g., NEF, AMF, SMF, PCF, UPF, etc.) to establish a PDU session including a radio bearer between a gNB and a UE in accordance with the QoS requirements, and a control circuit that, during operation, performs a service using the established PDU session.
[0040] System information transmission System information is downlink broadcast information periodically transmitted by a base station (gNB in 5G, usually a network node). It contains information for the UE to establish a connection with the base station. In 5G, the UE reads system information when it is powered on, for cell camping, and for cell selection and reselection when in RRC_IDLE mode. System information provides all the necessary details to access the network, such as system frame number, system bandwidth, PLMN, cell selection and reselection thresholds, etc.
[0041] The system information is organized into a Master Information Block (MIB) and a System Information Block (SIB). The SIB contains various information. For this disclosure, information regarding NTN transmission may be relevant, as described below. The MIB information is broadcast over the BCH and PBCH channels, and the SIB is transmitted over the DL-SCH and PDSCH channels.
[0042] In general, system information may be transmitted periodically (so that newly connecting terminals can retrieve it) or on-demand. The periodic schedule of system information transmission is configurable by RRC. In particular, SIB1 (referenced by MIB) carries scheduling information specifying, for example, the system information window (repetition period of the system information transmission pattern), some transmission parameters (e.g. physical layer parameters) for receiving the system information, and the mapping of SIBs within the system information window (transmission pattern).
[0043] Non-Terrestrial Network (NTN) Thanks to its wide service coverage capability and reduced vulnerability to space / aircraft physical attacks and natural disasters, NTNs can facilitate the deployment of NR services in unserviceable areas not covered or serviced by terrestrial NR networks (e.g., isolated or remote areas, operational aircraft and ships). Furthermore, NTNs can enhance NR service reliability by providing service continuity to crews on moving platforms or guaranteeing service availability anywhere, especially for critical communications.
[0044] These advantages relate to either non-terrestrial networks operating alone or to integrated terrestrial and non-terrestrial networks which may impact coverage, user bandwidth, system capacity, service reliability or availability.
[0045] A non-terrestrial network refers to a network or a segment of a network that uses RF resources on board a satellite, for example. An NTN is typically characterized by the following system elements: a 3GPP UE or a terminal specific to a satellite system if the satellite does not directly serve the 3GPP UE, a service link, which refers to the radio link between the user equipment and the space / air platform, an air platform carrying the payload, a gateway connecting the space / air platform to the core network, and a feeder link, which refers to the radio link between the gateway and the space / air platform.
[0046] NR-based operation in non-terrestrial networks (NTNs) has been considered and described in 3GPP (see, e.g., 3GPP TR 38.811, Study on New Radio (NR) to support non-terrestrial networks, version 15.4.0, and 3GPP TR 38.821, Solutions for NR to support non-terrestrial networks, version 16.0.0).
[0047] Non-terrestrial network (NTN) refers to a network or segment of a network that uses RF resources aboard airborne or space-based entities for transmission, such as: Spacecraft: Satellites (including LEO (Low Earth Orbiting), MEO (Medium Earth Orbiting), GEO (Geostationary Earth Orbiting), and HEO (Highly Elliptical Orbiting) satellites) Aircraft: High Altitude Platforms (HAPs) encompassing unmanned aircraft systems (UAS) that are lighter than Air UAS (LTAs) and heavier than Air UAS (HTAs), all of which typically operate at quasi-geostationary altitudes between 8 and 50 km.
[0048] Exemplarily, the UAS or satellite platform is connected to the 5G network via one or more gateways linked to a data network. The NTN may comprise the following system elements: a 3GPP UE or an NTN-enabled terminal, which may refer to a terminal specific to a satellite system when the satellite does not directly serve the 3GPP UE, a service link, which refers to a radio link between the user equipment and the space / air platform, an air platform carrying a payload, a gateway connecting the space / air platform to the core network, and a feeder link, which refers to a radio link between the gateway center space / air platform. The platform may implement either transparent or regenerative payload transmission with the following exemplary characteristics: In a transparent payload, the platform acts as a repeater by filtering, transforming and amplifying the wave signal, while the payload remains unchanged. With regenerative payloads, the platform has some or all of the base station functionality: it can perform demodulation / modulation, switching / routing, encoding / decoding, in addition to radio frequency filtering, conversion and amplification. · Inter-Satellite Links (ISLs) may optionally be used to form constellations of satellites. An ISL (Inter-Satellite Link) is a transport link between satellites.
[0049] Figure 6 shows a scenario of a non-terrestrial network in which transmission between terminals (UEs) is performed via a remote radio unit including a satellite and an NTN gateway. The gNB is located in the gateway as a scheduling device. The satellite payload implements frequency conversion radio frequency amplifiers for both uplink and downlink directions. Thus, the satellite repeats the NR radio interface from the feeder link (between the NTN gateway and the satellite) to the service link (between the satellite and the UE) and vice versa. The satellite radio interface (SRI) on the feeder link is NR-Uu. In other words, the satellite does not terminate NR-Uu. The satellite in this configuration is called a transparent satellite.
[0050] Figure 7 shows a scenario of a non-terrestrial network where the transmission between terminals (UEs) is via a satellite including a gNB as a scheduling device. The satellite in this configuration is called a regenerative satellite. According to one exemplary embodiment (see TR 38.321 section 5.2), the NG-RAN logical architecture as described in TS 38.401 is used as a baseline for the NTN scenario. The satellite payload performs the regeneration of the signal received from the Earth. The NR-Uu radio interface is on the service link between the UE and the satellite. The satellite radio interface (SRI) is on the feeder link between the NTN gateway and the satellite. The SRI (Satellite Radio Interface) is the transport link between the NTN GW and the satellite.
[0051] Figure 8 illustrates an example scenario in which three UEs (UE1, UE2, UE3) are served by a satellite S1, which communicates with a gNB and an NTN gateway via a feeder link and with another nearby satellite S2 via an inter-satellite link (ISL).
[0052] There are different types of satellites that provide communications: low Earth orbit (LEO) or geosynchronous equatorial orbit (GEO), also called geostationary satellites. Geostationary satellites move at the same angular velocity as the Earth and appear to orbit along a path parallel to the Earth's rotation, thereby providing coverage to a specific area. From the ground, GEO satellites appear to be stationary. LEO satellites orbit at altitudes between 160 and 2000 kilometers (99 and 1200 miles). A constellation of LEO satellites can provide continuous global coverage as the satellites move. Unlike GEO satellites, LEO satellites also travel at much faster speeds due to their closer proximity to the Earth.
[0053] GEO satellites have many uses, including weather forecasting, satellite radio, and television. However, because GEO satellites orbit at such high altitudes, there is a long communication lag time (delay) when signals are sent to and from these satellites. For this reason, many important communications are handled through the LEO satellite network, which allows for faster connectivity without wires or cables.
[0054] However, in general, in NTNs, there may be various different types of platforms, including not only satellites but also Unmanned Aerial System (UAS) platforms, examples of which are listed in Table 1 (see corresponding Table 4.1-1 in 3GPP TR 38.821, section 4.1, Non-Terrestrial Networks overview). [Table 1]
[0055] For LEO, MEO and HEO satellites that do not keep their positions fixed relative to a given point, the satellite beams corresponding to cells, PCI (Physical Cell ID) or SSB (Synchronization Signal Block) beams of the NR radio system may move around the Earth.
[0056] NTN scenarios that provide cells that move continuously on the Earth (e.g., LEO, MEO, or HEO based NTNs) are referred to as Earth moving cell scenarios. The continuous cell movement on the Earth is due to the motion of the satellite beams being fixed relative to the NTN platform. Thus, the footprint of the cell, which may correspond to one or more satellite beams, slides on the Earth surface along with the movement of the NTN platform (e.g., LEO satellites).
[0057] Information about the orbital trajectory of the satellites is contained in ephemeris data (or "satellite ephemeris data"). There are different possible representations of ephemeris data, one possibility is to use orbital parameters such as semi-major axis, eccentricity, inclination, right ascending of the ascending node, argument of periapsis, mean anomaly at a reference time, and epoch. The first five parameters can determine the orbital plane (orbital plane parameters), and the other two parameters are used to determine the exact satellite position at a certain time (satellite level parameters). The orbital plane parameters and satellite level parameters are exemplified in 3GPP TR 38.821 V16.0.0 Section 7.3.6.1 Representation of Complete Ephemeris Data. Another possible option is to provide the satellite position (x,y,z), the velocity vector (vx,vy,vz) and the coordinates of the reference time. [Table 2]
[0058] In an NTN system, several satellites may share a common orbital plane. In such a case, several ephemeris data may be provided for an orbital plane rather than for a single satellite to reduce the amount of data. The ephemeris data for each orbital plane may be stored in the UE or in the UE's Subscriber Identity Module (SIM). However, for networks with many satellites, the size of the ephemeris data may become significant. Therefore, rather than storing the ephemeris data, the ephemeris data may be at least partially (or completely) transmitted from the gNB.
[0059] For example, satellite level orbital parameters for all satellites that can serve the UE may be stored in the UE or SIM, and the ephemeris data of each satellite is linked to a satellite ID or index. The satellite ID or index of the serving satellite is then broadcast in the system information, so that the UE can find the corresponding ephemeris data in the UE's SIM or storage. Alternatively, the satellite level orbital parameters of the serving satellite may be broadcast in the system information, and the UE derives the position coordinates of the serving satellite. The ephemeris data of neighboring satellites may also be provided to the UE via system information or dedicated RRC signaling. If the baseline orbital plane parameters are provided in the UE or SIM, it is sufficient to broadcast the average anomaly of the reference time instant, and the epoch needs to be broadcast to the UE, so that the overhead can be reduced.
[0060] Timing advance and epoch time in NTN In 3GPP, a Release 17 work item for support of non-terrestrial networks (NTN) is still in progress (see, for example, 3GPP RP-201256, “WID: Solutions for NR to support non-terrestrial networks (NTN)”). NTN scenarios are characterized by long propagation delays, which the UE should take into account in the timing advance when transmitting on the uplink. Timing Advance (TA) is a delay used to control the uplink transmission timing of an individual UE. It helps to ensure that the uplink transmissions from all UEs are synchronized when received by the base station (network node). Already in terrestrial systems, the timing advance to be applied at the UE is transmitted from the network node to the specific UE.
[0061] The NTN transmission chain is divided into two segments: between the gateway and the satellite (the feeder link) and between the satellite and the UE (the service link). The delay on the feeder link is called the "common delay" because it is the same for any UE (e.g., see UE1, UE2, and UE3 in FIG. 8) served by the same NTN entity (e.g., satellite S1). The delay on the feeder link can vary for different UEs due to their possibly different locations, so it is called the "UE-specific delay".
[0062] In order to avoid revealing the physical location of the network node (gNB) to the UE, 3GPP RAN1 decided to signal the feeder link delay as a common timing advance, especially in architectures such as those shown in Figure 6 (see 3GPP TR 38.821, v.1.1.0).
[0063] Autonomous acquisition of the service link TA in the UE is possible using the UE-known position and satellite ephemeris. The UE's own position is usually available to the UE, especially if the UE can be assumed to have access to a positioning system, e.g., a Global Navigation Satellite System (GNSS) such as the Global Positioning System (GPS). Ephemeris data can be made available to the UE as mentioned in some specific examples above (stored in the SIM and / or acquired from system information signaling, etc.).
[0064] In general, however, the present disclosure is not limited to a fully autonomous determination of the service link TA component. Rather, the acquisition of the service link TA component may also be assisted by signaling of UE-specific information to a particular UE. A common TA, which refers to a common component of the propagation delay shared by all UEs within the coverage of the same satellite beam / cell, may be broadcast by the network for each satellite beam / cell. The calculation of this common TA is performed by the network assuming at least a single reference point for each satellite beam / cell.
[0065] In other words, in the exemplary scenario, the UE is assumed to be GNSS-enabled and therefore autonomously calculates the UE-specific delays. The UE calculates the feeder link delays based on a polynomial for the common TA. The sum of these delays provides the UE with the applicable timing advance value for the UL transmission.
[0066] However, it has been found that the feeder link delay can be time-varying, especially for fast moving LEO satellites. Thus, a single value representing the common TA may result in large approximation errors or require very frequent SIB updates. To reflect the time dispersion, the common TA can be expressed (approximated), for example, as a polynomial.
[0067] For 5G-NTN, the method of signaling the TA is being discussed in RAN1 (3GPP Radio Access Network Working Group 1). For example, a common TA may be approximated by a polynomial over an interval (herein called the validity interval), and the coefficients of the polynomial may be transmitted from a network node to one or more UEs. The coefficients may be transmitted by broadcast since they are common to UEs served by the same entity (e.g., satellite). The UE then calculates the feeder link delay based on the polynomial defined by the received coefficients for the common TA.
[0068] 3GPP TS 38.211 version h.0.0 (Release 17) in the tile "Physical channels and modulation" shows how the timing advance is derived in Section 4.3.1. Furthermore, according to one of the agreements captured in R1-2111127 "FL Summary on enhancements on UL time and frequency synchronizatio for NR NTN" from the RAN1#107-e meeting, the UE shall use the signaled higher layer common TA parameters to determine the timing advance of the N TA,common The one-way propagation time (Delay common ) can be determined as follows:
number
number
[0069] As a specific scenario, in Rel.17 NTN, the UE transmission timing is adjusted based on the propagation delay. This is shown in Figure 9. A satellite 910 moves (indicated by the moving arrow 920) at a speed of, for example, 7.6 km / s. It serves multiple (here three) cells 990.
[0070] The delay of the service link 940 (between the UE 950 and the satellite 910) is calculated using the satellite ephemeris (i.e., information about the satellite position) and the UE GNSS position information. The satellite ephemeris is broadcast via the system information, specifically via a system information block (SIB) carrying the NTN information, sometimes referred to as the NTN-SIB. The system information is broadcast by the satellite 910. This disclosure is not limited to any particular network configuration. In some communication systems that can still benefit from this disclosure, the satellites may be controlled by the gNB 960 to broadcast the system information.
[0071] The delay of the feeder link 930 (between the satellite 910 and the gNB 960) may be compensated by the network (e.g., by the gNB) or may be compensated by the UE 950 based on common TA parameters broadcasted via the NTN-SIB. The common TA parameters include information about the feeder link delay and its variations due to, for example, movement of LEO satellites (or other types of satellites).
[0072] FIG. 10 shows an example common timing advance value N for two satellite altitudes (600 km, 1200 km). TA,common(t) is shown for a constellation with a gateway (gNB, network node), satellites and a single UE in an initial position. At time t=0, the satellites are directly above the gateway. The satellites are visible to the UE under an elevation angle of 10 degrees at t=0. The common timing advance value N TA,common (t) may be determined based on signaled common TA parameters, including the feeder link delay and the variation rate of the delay (first and second derivatives).
[0073] The common timing advance parameter and further NTN related parameters are conveyed by the system information, for example in a specific NTN-SIB. The parameters carried therein may include one or more (or all) of the following: -Ephemeris -Common TA parameters - UL synchronization information validity duration -t-Service (timing information about when the serving cell stops serving the area) - Cell reference position - Epoch time -K_mac - Cell-specific Koffset -Network enable / disable TA report instructions -Polarization indication
[0074] As mentioned above, the ephemeris can include satellite orbit parameters such as anomalies (e.g., mean anomaly M in radians at epoch time), eccentricity, inclination, longitude (of the ascending node), periapsis and semi-major axis, etc. The ephemeris can include the coordinates of a satellite position state vector and the coordinates of a satellite velocity state vector.
[0075] Common TA parameters include, for example, TACommon, TACommonDrift, TACommonDriftVariant, and TACommonDriftVariation parameters. In particular, TACommon is a network-controlled common timing advance value and may include any timing offset deemed necessary by the network. A value of zero TACommon is supported. The granularity of TACommon is 4.07x10^(-3) μs. TACommonDrift indicates the drift rate of the common TA. The granularity of TACommonDrift is 0.2x10^(-3) μs / s, and TACommonDriftVariant indicates the drift rate variation of the common TA. The granularity of TACommonDriftVariant is 0.2x10^(-4) μs / s^2. Values are given in units of the corresponding granularity.
[0076] t-Service indicates time information regarding when a cell provided via the NTN quasi-earth fixed system is going to stop serving the area it currently covers. Cell reference position is the reference position of a cell provided via the NTN quasi-earth fixed system.
[0077] The epoch time indicates the epoch time of the assistance information (i.e., the serving satellite ephemeris and common TA parameters). When provided explicitly via SIB or via dedicated signaling, the epoch time is the start time of the DL subframe and is indicated by the SFN and the subframe number signaled with the assistance information. The reference point for the epoch time of the serving satellite ephemeris and common TA parameters is the uplink time synchronization reference point.
[0078] K_mac is a scheduling offset provided by the network when downlink and uplink frame timing are not aligned at the gNB. It may be required for UE behavior and assumptions regarding downlink configuration signaled by MAC-CE command in PDSCH. When the UE is not provided with a K_mac value by the network, the UE assumes K_mac=0. For the reference subcarrier spacing value in units of K_mac for FR1 (frequency range 1 between 410 MHz and 7125 MHz), a value of 15 kHz is used. The unit of K_mac is the number of slots for a given subcarrier spacing.
[0079] CellSpecific_K_offset is the scheduling offset used for the timing relationships that need to be modified for NTN. The units of K_offset are the number of slots for a given subcarrier spacing of 15 kHz.
[0080] ntnPolarizationDL may optionally be included in the NTN-SIB (which may also be referred to as SIB NTN, SIB-NTN, etc.). If present, this parameter indicates the polarization information for downlink transmission on the service link, including right-hand, left-hand circular polarization (RHCP, LHCP) and linear polarization. Correspondingly, ntnPolarizationUL, if present, indicates the polarization information of the uplink service link. If not present and ntnPolarizationDL is present, the UE assumes the same polarization for UL and DL.
[0081] As mentioned above, the epoch time is the reference time for the ephemeris and the common TA parameters (assistance information). In other words, the ephemeris and the common TA parameters are generated based on the epoch time. The UE 950 calculates the position of the satellite 910 and the delay of the feeder link 930 based on the time reported as the epoch time and the satellite position determined based on the ephemeris. In NTN, the epoch time is usually determined in terms of the SFN (system frame number) and the subframe number when signaled in the NTN-SIB. In other contexts, such as the Unix operating system, the epoch time is the number of seconds elapsed since 00:00:00 UTC on January 1, 1970 (also called the Unix epoch). It is a continuous time without wraparound.
[0082] Epoch time t epoch appears to be an approximation of the one-way propagation delay.
number
[0083] Note that the epoch time does not need to be explicitly signaled in the NTN-SIB, but may be implicitly determined, for example, according to the system information window.
[0084] For normal system information content (SIBs used for terrestrial networks), there is a validity period (duration) of assistance information including ephemeris and common TA parameters, during which the estimates (i.e. satellite positions and feeder link delays) have sufficient accuracy. The validity period is indicated for example as validity duration (VD) in the NTN-SIB. It indicates the validity duration for the entire content of the NTN-SIB. The validity may be longer than the SFN cycle 1110. For example, for LEO, the maximum validity duration is currently assumed to be 240s (or even infinite for GEO).
[0085] Since the epoch time is indicated by the SFN and subframe number, and the SFN cycles every 1024 frames (i.e., every 10.24 s), ambiguity arises when the aiding information is repeated at different SFN cycles. This is illustrated in FIG. 12, which shows a solid line representing the value of SFN over time. As can be seen, with each SFN cycle (1024 SFNs), the SFN value falls back to zero. The dashed line shows the value of epoch time over time (relative to a starting point, shown here as 0). As can be seen, the epoch time expands and does not wrap up.
[0086] To avoid ambiguity, the validity duration may be longer and still be sufficient, but the network needs to update the NTN-SIB contents (i.e., ephemeris, common TA parameters and epoch time) at least every SFN cycle (every 10.24 seconds), which leads to unnecessary network complexity and lower efficiency, and unnecessary UE complexity resulting in higher power consumption.
[0087] A more detailed description of the time domain relationship between NTN-SIB transmissions and SFN cycles is shown in FIG. 13. In particular, three SFN cycles are shown. The NTN-SIB is updated after each duration of the SFN cycle (1330) (which may be less). Here, "updating" refers to updating the content of the NTN-SIB. For example, the fact that the content of the NTN-SIB has been updated may be indicated in the scheduling information that schedules the SIB, and such an indication is taken into account by the UE when determining which SIB to read and when, similar to the current NR mechanism provided by SIB1. However, in general, such a mechanism is not necessary for the NTN-SIB. In particular, the UE may recognize the need to read the NTN-SIB based on the validity duration indicated in the NTN-SIB or set in SIB1. Furthermore, the NTN-SIB is also transmitted during the SFN cycle (1320) (indicated by the vertical arrows at the bottom of the figure). These transmissions 1310 repeat the most recently updated NTN-SIB. The dashed oval 1310 indicates an NTN-SIB with the same content. The same SIB content can only be repeated for a period less than the SFN cycle length (10.24 s). Otherwise, epoch time ambiguity occurs. The content of the updated NTN-SIB starts at update 1330 and is associated with a valid duration with a value signaled in the updated NTN-SIB.
[0088] Working Example According to an embodiment, to avoid such an increase in complexity on the network side as well as on the UE side, the network signals information for identifying the SFN cycle of the epoch time in the NTN-SIB, which makes it possible to distinguish SFNs that have the same value but belong to different SFN cycles.
[0089] In the following, UEs, base stations and procedures for meeting these needs are described for a new radio access technology envisaged for a 5G mobile communication system, but which may also be used in an LTE mobile communication system or other communication systems. Different implementations and variations are described as well. The following disclosure is facilitated by, and may be based, for example, at least in part on, the discussion and insights presented above.
[0090] In general, it should be noted that many assumptions have been made herein so that the principles underlying the present disclosure can be explained in a clear, concise and understandable manner. However, these assumptions should be understood as merely examples made herein for illustration purposes that should not limit the scope of the present disclosure. Those skilled in the art will recognize that the principles of the following disclosure and those described in the claims can be applied to different scenarios and methods not explicitly described herein.
[0091] Furthermore, some of the terms such as procedures, entities and layers used below are closely related to the terms used in the LTE / LTE-A system or current 3GPP 5G standardization, even though the specific terms used in relation to new radio access technologies for the upcoming 3GPP 5G communication system have not yet been fully determined or may eventually be changed. Thus, the terms may be changed in the future without affecting the functionality of the embodiment. Therefore, those skilled in the art will recognize that the present embodiment and its scope of protection should not be limited to the specific terms used illustratively herein due to the lack of newer or finally agreed upon terms, but should be more broadly understood with respect to the functions and concepts underlying the functions and principles of the present disclosure.
[0092] For example, a mobile station, a mobile node, a user terminal, a user device or a user equipment is a physical entity (physical node) in a communication network. A node may have several functional entities. A functional entity refers to a software or hardware module that implements and / or provides a given set of functions to other functional entities of the same or other nodes or the network. A node may have one or more interfaces that connect the node to a communication facility or medium over which the node can communicate. Similarly, a network entity may have logical interfaces that attach a functional entity to a communication facility or medium over which it can communicate with other functional entities or correspondent nodes.
[0093] Here, the term "base station" or "radio base station" refers to a physical entity in a communication network. Similar to a mobile station, a base station may have several functional entities. A functional entity refers to a software or hardware module that implements and / or provides a given set of functions to other functional entities of the same or other nodes or networks. A physical entity performs several control tasks for communication devices, including one or more of scheduling and configuration. It should be noted that base station functions and communication device functions may also be integrated in a single device. For example, a mobile terminal may also implement the functions of a base station for other terminals. The term used in LTE is eNB (or eNodeB), while the term currently used in 5G NR is gNB.
[0094] The term non-terrestrial network, NTN, entity, as introduced in the above section on NTNs, can be broadly understood as an entity of a non-terrestrial network, such as a spacecraft or an aircraft. In the following, a satellite is considered only as a specific example of such an NTN entity, but it is clear that other specific examples of NTN entities are also covered.
[0095] For the following examples, it is exemplarily assumed that data transmission takes place between the UE and the network node via an NTN entity (e.g., a satellite). The term "network node" refers to a base station (e.g., a gNB) as shown in FIG. 6 or other entity with an interface to the core network (CN), such as the NTN gateway as shown in FIG. 7. The above-introduced scenarios of FIG. 8 and FIG. 9 may be exemplarily referred to below. For simplicity of explanation, it is exemplarily assumed that the gateway and the gNB (forming a network node) are collocated, thus avoiding possible physical and logical separation of the gateway and the gNB (base station) in the following description. Thus, in the following, the examples are described as taking place between the UE, the NTN entity and the gNB, without mentioning that the gateway is located between the NTN entity and the gNB or is integrated in the gNB.
[0096] FIG. 14 shows a schematic simplified exemplary block diagram of a user equipment 110 (also called a communication device) and a scheduling device 160 (here assumed to be exemplarily located in a base station, e.g. an eLTE eNB (or also called ng-eNB) or a gNB in 5G NR). The UE 110 and the eNB / gNB 160 communicate with each other via (wireless) physical channels using respective transceivers. The communication is indicated by the arrow 150. Furthermore, the NTN entity may have the same or similar configuration as the scheduling device, e.g. including transceivers and processing circuits. Thus, the terminal 110 and the gNB 160 are part of the communication system 100.
[0097] Both devices 110 and 160 may comprise a transceiver 120, 170 and a processing circuit 130, 180. The transceiver 120, 170 may also comprise and / or function as a receiver and a transmitter. The processing circuit 130, 180 may be one or more hardware such as one or more processors or any LSI. Between the transceiver and the processing circuit there are input / output points (or nodes) through which the processing circuit can control the transceiver during operation, i.e. control the receiver and / or transmitter and exchange receive / transmit data. The transceiver may include an RF (radio frequency) front including one or more antennas, amplifiers, RF modulators / demodulators, etc. as a transmitter and receiver. The processing circuit may realize control tasks such as controlling the transceiver to transmit user data and control data provided by the processing circuit and / or receiving user data and control data that are further processed by the processing circuit. The processing circuit may also be responsible for performing other processes such as decisions, determinations, calculations, measurements, etc. The transmitter may be responsible for performing the process of transmission and other processes related thereto. The receiver may be responsible for carrying out the process of reception and other processes related thereto, such as monitoring the channel.
[0098] Different implementations of the improved transmission procedure are described below. In this connection, improved entities such as an improved UE, an improved NTN entity and an improved base station participating in the improved transmission procedure are presented. Corresponding methods for the operation of the UE NTN entity and the BS are also provided.
[0099] According to an embodiment, a user device (such as a terminal 950) is provided. The user device includes a transceiver (such as the transceiver 120 shown in FIG. 14) and a circuit (such as the processing circuit 130 in FIG. 14). In operation, the transceiver receives system information related to a non-terrestrial network from a network node. The transceiver may perform reception controlled by the circuit. In other words, the circuit may control (instruct) the transceiver, including instructing the receiver to receive the system information. The network node here is, for example, an NTN device (such as a satellite or an aircraft). However, it is conceivable that other network devices such as a gNB may provide (transmit) the system information.
[0100] During operation, the circuit determines an indication of a system frame cycle count and an aiding information indication from the system information. Then, it determines an epoch time for deriving the aiding information based on the indication of the system frame cycle count. Finally, it derives the aiding information based on the epoch time and the aiding information indication.
[0101] Corresponding to the user device, a network node (e.g., NTN node 910 such as a satellite or gNB 960) is provided. It corresponds to the NTN entity 160 of FIG. 14 and may include a transceiver such as transceiver 170 of FIG. 14 and a circuit such as processing circuit 180 of FIG. 14. In operation, the circuit generates system information regarding the non-terrestrial network. In particular, the system information includes an indication of a count of system frame cycles and an aiding information indication. The aiding information indicated by the aiding information indication is derivable based on the epoch time and the aiding information indication, and the epoch time is determined based on the indication of the count of system frame cycles.
[0102] For example, the circuitry determines the assistance information (e.g., based on its own location and based on information received from the gNB), and it generates the assistance information (such as common TA information and / or ephemeris). To enable the UE to derive the assistance information, the circuitry generates an assistance information indication that references an epoch time related to a reference epoch time associated with the assistance information indication (e.g., an association may be given in that the reference time for determining the epoch time is the reference epoch time of the updated NTN-SIB transmission / reception that carries the assistance information indication).
[0103] Additionally, the transceiver of the network device transmits system information during operation.
[0104] In some implementations, the count of the system frame cycles increases periodically within a predefined range. In other words, the count of the system frame cycles (SFN cycles) can take a value from a predefined range. Such predefined ranges can be, for example, 0 to 3, 0 to 7, or 0 to 15, etc. It is not mandatory that the range includes a number of values that are a power of 2, but such ranges can increase the efficiency of binary signaling in some scenarios. It can be effective if the range of the count of the SFN cycles is determined such that the maximum value of the range multiplied with the length of the SFN cycle is equal to or greater than the maximum valid duration of the system information (NTN-SIB). This allows to always avoid the above-mentioned ambiguity. For example, as shown in FIG. 13, if the duration of the SFN cycle is 10.24 s and the maximum valid duration is 240 s, it can be effective to provide a maximum count of the SFN cycles of at least 24 (corresponding to a 5-bit counter, or equivalently a range of 0 to 23 or equivalently 1 to 24). The SFN cycles may then be counted circularly from some predetermined time (such as the time of sending / receiving an updated NTN-SIB), starting from a minimum range value (such as 0 for the range 0-23 or 1 for the range 1-24) consecutively, for example, by 0, 1, 2, 3,..., 22, 23, 0, 1, etc.
[0105] In other words, effectively the maximum count of system frame cycles is equal to or greater than the validity period of the system information (counted in terms of the number of system frame cycles).
[0106] For example, the count of system frame cycles starts when the system information (carrying assistance information, NTN-SIB) is updated and increments with any system frame cycle following the system frame cycle in which the system information was updated.
[0107] The term "system information" referred to in the embodiments herein specifically refers to system information that carries NTN-related information and is therefore also referred to as NTN-SIB. Note that, as mentioned above, the system information may include at least one of the following: -Ephemeris -Timing advance parameters -Uplink Sync Expiry - Cell reference position Scheduling offset between uplink and downlink -Uplink and / or downlink polarization indication
[0108] These NTN-SIB contents are merely examples. They are readily available for current NR systems. However, the present disclosure is not limited thereto. In addition, there may be additional parameters transmitted in the NTN-SIB.
[0109] In an exemplary embodiment, the assistance information indication includes at least one timing advance parameter. As mentioned above, the parameters may for example be coefficients of first and second derivatives or polynomial terms (depending on the approximation applied) that allow to reset an approximation of the common TA variation. That is, the timing advance parameters are derived in the network node by approximating the common TA. The common TA is obtained by the UE by resetting the approximation based on the parameters indicated in the NTN-SIB.
[0110] The validity interval may be determined by a network node and signaled to the UE together with the NTN-SIB. However, for some communication systems, it is conceivable to provide a predetermined fixed validity interval without the possibility of configuring it by signaling, e.g., by SIB1 or scheduling information in the standard. The present disclosure is not limited to a particular method of obtaining the validity interval in the network node and / or the user device.
[0111] In general, the timing advance between the network and the UE may be defined by compensation components such as feeder link delay, service link delay, and network controlled delay. The above approximations apply with respect to the feeder link portion (i.e., between the network and the satellite). This disclosure is not limited to any particular technique for determining and / or reporting the service link delay or the network controlled delay.
[0112] The reference time (epoch time) for acquiring the correct ephemeris and / or common TA may be determined by the network node and the user device in the same way for some system timing parameters, so that no additional (explicit) signaling is required. However, in some implementations, it may be beneficial to explicitly signal the reference time from the network node to the user device. A validity interval may be determined (specified) for the reference time. The reference time in some embodiments may start the validity interval. However, the present disclosure is not limited to such a relationship between the reference time and the validity interval. In general, any other pre-configured relative position of the reference time and the validity interval may be supported.
[0113] It should be noted that the functionality of the above network nodes may be incorporated in an integrated circuit corresponding to the functionality of the processing circuit 180 described above. Such processing circuitry controls the transceiver to perform transmission and / or reception. Since the common TA is common to one or more devices served by the same NTN entity (e.g., satellite), it may be transmitted by broadcast, e.g., system information broadcast by the network node or NTN entity. In the specific example of FIG. 6, for example, the gNB may transmit the NTN-SIB (via the NTN entity) with further information in a system information block (SIB) defined in the RRC protocol.
[0114] In the network node and / or in the user device, the processing circuitry 130 and / or 180 may be configured to determine the reference time based on the timing of the transmission of system information (e.g., uplink and / or downlink transmission timing), which may be known from a previously received configuration that includes the SIB transmission window.
[0115] For example, in general the reference time (epoch time) may be determined in a variety of different ways, for example based on at least one of the following reference points: The start point of the system information window in which system information (e.g. NTN-SIB) is transmitted. The UE (as a receiving entity) can derive the start point from the NTN-SIB reception timing, i.e. from the timing when the UE receives SIB_NTN in the downlink. - The starting point of the system frame number (SFN) of the frame in which the system information is transmitted. The system frame number can be reported in the MIB or SIB1. - The start point of the frame in which the system information (NTN-SIB) is transmitted - System information timing and a given offset to the reference time
[0116] For example, a reference point can be directly one of the following: -Start point of the System Information (SI) window where NTN-SIB is sent - The start point of the SFN from which the NTN-SIB is sent -Start point of the frame in which the NTN-SIB is sent - NTN-SIB timing minus delta_t (δt). Delta_t (δt) in NTN-SIB in this example is a fixed offset starting from (relative to) the reference time.
[0117] The term "system frame" means a frame defined (e.g., by a standard) for data transmission in a communication system. The NTN-SIB is transmitted at a position (e.g., given by a subframe, slot, and / or symbol) within the system frame that is given by an offset δt from the start of the system frame.
[0118] In the user device, the processing circuitry, in operation, controls the transceiver to apply the determined timing advance when transmitting signals, e.g., signals carrying payload, control data and / or reference signals.
[0119] Alternatively or in addition to timing advance information, the assistance information may include satellite ephemeris as described above. The present disclosure is not limited to these types of assistance data but may be useful for any information indicated in the system information that needs to be reconstructed with reference to an epoch time or another time reference that may take values beyond the validity period of the system information.
[0120] A first exemplary embodiment is shown in Figure 15. In this embodiment, the network indicates the SFN cycle counter in the NTN-SIB along with the ephemeris and common TA parameters, and possibly but not necessarily, the epoch time.
[0121] In particular, for example, the processing circuitry determines, during operation, an epoch time indication from the system information. The processing circuitry then determines the epoch time further based on the epoch time indication, which references a system frame number, the system frame number being unique within one system frame cycle. The system frame number is not necessarily unique outside of the one system frame cycle.
[0122] Thus, the NTN-SIB content may include at least ephemeris (e.g., orbital parameters, 144 bits), common TA parameters (e.g., 60 bits), epoch time (e.g., represented by SFN and subframe number, 14 bits), and SFN cycle counter (e.g., 5 bits).
[0123] In this example, the epoch time indication includes the start time of a downlink subframe indicated by the SFN and subframe number signaled together with the assistance information (by the NTN-SIB carrying the assistance information).
[0124] In an NTN-SIB 1530 transmitted in the same SFN cycle as the SFN indicated by the epoch time, an SFN cycle counter = 0 is signaled. In an NTN-SIB transmitted in the nth SFN cycle thereafter compared to the SFN indicated by the epoch time (cycle), an SFN cycle counter = n (or n-1 if the count starts from 0) is signaled. The term "signaled" here refers to the transmission of the SFN cycle count in the NTN-SIB. All NTN-SIBs transmitted (repeated) in the same SFN cycle have the same SFN cycle count.
[0125] One of the advantages of this exemplary embodiment is that the ephemeris and common TA parameters do not need to be updated every SFN cycle. The same content (of the NTN-SIB) can be repeated throughout the validity period, as seen in Figure 15. In particular, the dashed oval 1550 indicates the repetition of the updated (1530) NTN_SIB. The repetitive transmission is indicated by the downward vertical arrow.
[0126] In the above example, the epoch time indication was transmitted in the system information (NTN-SIB). However, the present exemplary embodiment and the present disclosure generally do not require an explicit epoch time indication. Rather, for example, in a user device, a processing circuit determines, during operation, the epoch time of the assistance information by reference to the end of the window in which the system information is transmitted.
[0127] In other words, in this example, the network still indicates the SFN cycle count in the NTN-SIB together with the ephemeris and common TA parameters without an explicit provision of the epoch time. When not explicitly provided via the NTN-SIB, the aiding information (e.g., serving satellite ephemeris and common TA parameters) is implicitly known as the end of the SI window in which the SI message is transmitted. As in the previous example, in the NTN-SIB transmitted in the same SFN cycle (as epoch time) as the specified SFN, the SFN cycle counter = 0 is reported. In the NTN-SIB transmitted in the Nth SFN cycle following the specified SFN (as epoch time), the SFN cycle counter = N is reported.
[0128] As in the previous example, the NTN-SIB content may therefore include at least the ephemeris (e.g., orbital parameters, 144 bits), common TA parameters (e.g., 60 bits), and an SFN cycle counter (e.g., 5 bits). However, the NTN-SIB no longer needs to include the epoch time (e.g., represented by the SFN and subframe number, 14 bits).
[0129] FIG. 17 shows an exemplary flow diagram illustrating a method performed on the network side in the first exemplary embodiment. The network side here may be represented by an NTN device such as a satellite (or by a gateway or by a combination of a satellite and a gateway). The network knows the epoch time, and in most cases, the network also knows the absolute epoch time, but in any case, the epoch time is relative with respect to the network timing such as SFN and subframe (or possibly HFN or other time domain unit). Step 1710 shows generating an ephemeris based on the epoch time. As mentioned above, this step is not required. The ephemeris may be fully or partially stored in the user device (e.g., in the SIM). However, if there is a lot of ephemeris data, or if the ephemeris data may change more frequently, it may be more efficient to inform the user device (UE) of it. In step 1720, timing advance information is determined and a timing advance indication (including one or more parameters) is generated with reference to the epoch time (relative to a predefined reference epoch time). For example, a common timing advance on a feeder link is determined by the NTN device based on a signal received from a gNB, and the timing advance variation with respect to time is approximated by utilizing one or more parameters, which are included in the NTN-SIB as a timing advance indication.
[0130] In step 1730, the SFN cycle counter is set to 0 (typically set to the minimum value out of the range for the SFN cycle count), and in step 1740, the determined (i.e., updated) ephemeris and / or timing advance indication (parameters) are transmitted in the NTN-SIB.
[0131] In step 1750, it is determined whether the current NTN-SIB content is within the validity period. If not, the NTN-SIB is updated, corresponding to repeating steps 1710 to 1750 shown in the flow diagram and described above. If the current NTN-SIB is still within the validity period, step 1760 follows, where it is determined whether the current NTN-SIB is transmitted within the SFN cycle with the current SFN cycle count. If so, in step 1740, transmission of the NTN-SIB is performed. If not, the SFN cycle count is incremented in step 1760 (in general, it is updated, since it is considered that the counts are performed in a decreasing order), and the method proceeds to step 1740, where the SIB-NTN is transmitted (although it is not updated, contrary to the method described with reference to FIG. 13).
[0132] 18 illustrates a corresponding method performed in a user device according to a first exemplary embodiment. In particular, in step 1810, the user device receives an NTN-SIB including an ephemeris and a common TA. In step 1820, the user device (e.g., its circuitry described above) determines an epoch time based on an epoch time indication that is explicitly signaled or derived from the SIB window timing by utilizing the SFN cycle count.
[0133] In step 1830, the user device calculates the satellite position (or the position of the NTN device in general) based on the ephemeris. In step 1840, the user device calculates the common TA based on the common TA parameters received in step 1810. The epoch time determined in step 1820 may be used to determine the ephemeris and the common TA.
[0134] 16 illustrates a second exemplary embodiment in which an indication of the count of system frame cycles corresponds to a hyperframe number, which indicates a count of hyperframes, which include a given number of system frames.
[0135] The hyperframe count is provided by the communication system and does not necessarily start or relate to the epoch time update.
[0136] As can be seen from FIG. 16, the network notifies HFN (Hyper Frame Number), SFN, and subframe number as epoch time. For example, LTE supports signaling of HFN, and the range of HFN is 0 to 1023 in LTE. Such HFN may be provided in the exemplary embodiment. In LTE, an interval of 10 ms defines a system frame. The system frame can have numbers from 0 to 1023, and these numbers are called SFN (System Frame Number). When the SFN number reaches its maximum value (i.e., 1023), it rolls back to 0. The UE and eNB maintain synchronization on the subframe number and SFN throughout the communication period. LTE introduces HFN (Hyper Frame Number) or hyper HFN to support a longer synchronization period, especially for machine-type communication and IoT. HFN is the next level timer of SFN. HFN ranges from 0 to 1023, and when SFN reaches 1023 and is reset to 0, its value is incremented by 1. However, this disclosure is not limited to LTE hyperframes. The range of HFN values may be different.
[0137] One advantage of this embodiment is that the ephemeris and common TA parameters do not need to be updated every SFN cycle. The same content can be repeated during the validity duration as in the first exemplary embodiment. In addition, the HFN can also be useful for other applications, such as synchronization in LTE.
[0138] FIG. 19 shows a flow diagram of an exemplary method performed on the network side in the second exemplary embodiment. In particular, similar to the first exemplary embodiment (see FIG. 17), step 1910 shows generating ephemeris based on epoch time. As mentioned above, this step is not required. The ephemeris may be fully or partially stored in the user device (e.g., in the SIM). In step 1920, timing advance information is determined and a timing advance indication is generated with reference to the epoch time. In step 1930, the current HFN count is embedded (the NTN-SIB may reference it). The network may transmit the HFN, for example, in every SIB1, and the UEs may synchronize their SFNs based on this. However, there are other possibilities to carry the HFN.
[0139] In step 1940, it is determined whether the current NTN-SIB content is within the validity period. If not, the NTN-SIB is updated corresponding to repeating steps 1910-1930 as shown in the flow diagram and described above. If the current NTN-SIB is still within the validity period, step 1750 follows and the SIB-NTN is transmitted (although not updated) including the ephemeris and / or common TA data and the embedded HFN.
[0140] FIG. 20 shows a flow diagram of an exemplary method performed at the UE side in the second exemplary embodiment. In particular, in step 2010, the user device receives the NTN-SIB including the ephemeris and the common TA. In step 2020, the user device (e.g., its circuitry described above) determines the epoch time by utilizing the HFN and based on the epoch time indication that is explicitly signaled or derived from the NTN-SIB window timing. In step 2030, the user device calculates the position of the NTN device based on the ephemeris. In step 2040, the user device calculates the common TA based on the common TA parameters received in step 2010. The epoch time determined in step 2020 may be utilized to determine the ephemeris and the common TA.
[0141] 21 illustrates a third exemplary embodiment in which SFN cycles may be distinguished by conventions for setting and modifying the validity duration. In particular, the processing circuitry of the user device determines a count of system frame cycles based on a validity indication and a predefined validity duration. The validity indication indicates a time period during which the system information is valid for use by the user device. Furthermore, the validity indication is reset to the predefined validity duration in the system frame cycle in which the system information is updated and decremented in any other system frame cycle.
[0142] According to an advantageous embodiment, the predetermined valid duration is set by the network. In other words, the user device can receive the predetermined valid duration via the transceiver. The network can set the valid duration based on an estimate of how often the SIB data needs to be updated to ensure sufficient transmission / reception quality for a particular scenario (e.g., this can be different for GEO or LEO satellites or airborne devices). However, the present disclosure is not limited to the predetermined valid duration being signaled. Rather, the predetermined valid duration can be set directly by a predetermined rule or by a standard.
[0143] As can be seen from Fig. 21, it is not envisaged that the epoch time has a tight coupling with the ephemeris content and common TA parameters. The epoch time 2130 of the NTN-SIB is used as the start time of the validity duration. The advertised validity duration is decreased every SFN cycle. For example, in SFN cycle 1, the validity duration (VD) is set to the total VD (TVD), here with an exemplary value of 420s. In SFN cycle 2, the remaining VD (RVD) is decreased by 10s, corresponding approximately to the SFN cycle size. In SFN cycle 3, the RVD is further decreased by 10s to a value of 220s. As can be seen from reference numeral 2170, the TVD remains the same (corresponding to a predefined validity duration). The RVD is decremented by a predefined step every SFN cycle. The predefined step effectively corresponds to the SFN cycle duration.
[0144] It should be noted that the correspondence need not be perfect. Furthermore, the remaining effective duration shown here is, as an example, decreased every SFN cycle. In general, the remaining effective duration is signaled in every NTN-SIB transmission and may be decreased according to the NTN-SIB transmission timing. This may result in a smaller effective duration of 5s and 10s, etc., or indeed every SFN cycle, and a larger effective duration up to 240s (i.e., decreasing not every SFN cycle, but every predetermined number of SFN cycles, for example. When referring to "predetermined," what is meant is, for example, pre-set by a betwork, given by a standard, or given by a rule specified in a standard, etc., to ensure synchronization between the network and the user device.
[0145] As with the first and second exemplary embodiments, the ephemeris and common TA parameters do not need to be updated every SFN cycle. The UE can know the correct expiration time of the SIB content. This is indicated by the dashed ellipse 2150 surrounding the NTN-SIB transmission, which may be a repetition of the NTN-SIB updated at time 2130. The expiration time 2190 is the time when the validity duration reaches or falls below 0s.
[0146] Figure 22 shows an exemplary method performed on the network side. In particular, similar to the first and second exemplary embodiments (see Figures 17 and 19), step 2210 shows generating an ephemeris based on the epoch time. As mentioned above, this step is not required. The ephemeris may be fully or partially stored in the user device (e.g., in the SIM). In step 2220, timing advance information is determined and a timing advance indication is generated with reference to the epoch time.
[0147] In step 2230, the network side selects a total validity duration (TVD, i.e., the predefined validity duration as described above). In step 2240, the remaining validity duration (RVD) is set and embedded in the NTN-SIB, where RDV is set equal to TVD following the ephemeris and common TA updates in steps 2210 and 2220.
[0148] In step 2250, these parameters (ephemeris, common TA indication and RVD determined in steps 2210, 2220 and 2240, respectively) are transmitted in the NTN-SIB. Furthermore, in step 2260, it is determined whether the current NTN-SIB content is within the current validity period. If not, the NTN-SIB is updated corresponding to repeating steps 2210-2250 shown in the flow diagram and described above. If the current NTN-SIB is still within the validity period, step 2270 follows, where it is determined whether the NTN-SIB should be repeated. If yes, the RVD is decremented by a predefined tick (2280). The method then loops back to step 2250 and the NTN-SIB is transmitted (repeated without updating its content). If no in step 2270, the method loops back to step 2210, whereupon the content of the NTN-SIB is updated.
[0149] FIG. 23 shows a flow diagram of an exemplary method performed at the UE side in the third exemplary embodiment. In particular, in step 2310, the user device receives the NTN-SIB including the ephemeris and the common TA. In step 2220, the user device (e.g., its circuitry described above) determines the epoch time by utilizing the total valid duration (predetermined duration) and the remaining valid duration (current duration). In step 2230, the user device calculates the position of the NTN device based on the ephemeris. In step 2240, the user device calculates the common TA based on the common TA parameters received in step 2210. The epoch time determined in step 2220 can be used to determine the ephemeris and the common TA.
[0150] It should be noted that the present disclosure is not limited to the exemplary first, second and third embodiments. Rather, further variations and modifications are possible. For example, in an exemplary modification of any of the above-mentioned embodiments, the transceiver of the user device receives system information during operation via dedicated signaling related to measurements or handover. Correspondingly, the network transmits system information via dedicated signaling related to measurements or handover. The dedicated signaling may be RRC signaling, for example, an RRC RECONFIGURATION message.
[0151] Additionally or alternatively, the SFN counter and / or HFN may be added to the NTN-SIB for specific scenarios only, optionally only for GEO satellites that are NTN devices. Correspondingly, the network transmits and the user device receives the SFN count, HFN or RVD / TVD depending on the type of NTN entity (network node).
[0152] The present disclosure can be realized by software, hardware, or software in cooperation with hardware. In addition, each functional block used in the description of each embodiment described above can be partially or completely realized by an LSI (Large Scale Integration) such as an integrated circuit (IC), and each process described in each embodiment can be partially or completely controlled by the same LSI or a combination of LSIs. The LSI may be formed as a chip individually, or one chip may be formed to include some or all of the functional blocks. The LSI may include data input / output coupled thereto. The LSI here may be referred to as an IC, a system LSI, a super LSI, or an ultra LSI depending on the degree of integration. However, the technology for realizing the integrated circuit is not limited to an LSI, and may be realized using a dedicated circuit, a general-purpose processor, or a dedicated processor. In addition, a field programmable gate array (FPGA) that can be programmed after the LSI is manufactured, or a reconfigurable processor that allows the connection and setting of the circuit cells arranged in the LSI to be reconfigured, may be used. The present disclosure can be realized as digital processing or analog processing. When future integrated circuit technologies replace LSI as a result of advances in semiconductor technology or other derived technologies, the functional blocks may be integrated using future integrated circuit technologies. Biotechnology is also applicable.
[0153] The present disclosure may be implemented by any type of apparatus, device or system having communication capabilities, which may be referred to as a communications apparatus.
[0154] A communication device may include a transceiver and processing / control circuitry. The transceiver may include and / or function as a receiver and a transmitter. The transceiver may include a radio frequency (RF) module including an amplifier, an RF modulator / demodulator, etc., and one or more antennas as a transmitter and a receiver.
[0155] Some non-limiting examples of such communication devices include telephones (e.g., cellular (mobile) phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, netbooks), cameras (e.g., digital still / video cameras), digital players (digital audio / video players), wearable devices (e.g., wearable cameras, smart watches, tracking devices), game consoles, digital book readers, telehealth / telemedicine (telehealth and medical) devices, and vehicles providing communication capabilities (e.g., automobiles, aircraft, watercraft), and various combinations thereof.
[0156] The communication equipment is not limited to being portable or mobile, but may include any type of apparatus, device or system that is non-portable or fixed, such as smart home devices (e.g., appliances, lights, smart meters, control panels), vending machines, and any other "thing" in an "Internet of Things (IoT)" network.
[0157] Communications may include, for example, exchanging data via cellular systems, wireless LAN systems, satellite systems, and the like, as well as various combinations thereof.
[0158] A communications apparatus may include devices such as controllers or sensors coupled to a communications device to perform the communications functions described in this disclosure. For example, a communications apparatus may include controllers or sensors that generate control or data signals used by the communications device to perform the communications functions of the communications apparatus.
[0159] The communications equipment may also include infrastructure facilities such as base stations, access points, and any other equipment, devices, or systems that communicate with or control equipment such as those in the above non-limiting examples.
[0160] Overview of the Example Corresponding to the above-mentioned network nodes, user devices and related further examples and embodiments, the present disclosure provides corresponding methods performed by the network nodes and user devices or by processing circuitry thereof.
[0161] Further exemplary examples and embodiments of the method are provided by steps that are operatively performed by the above-mentioned processing circuitry of the network node and / or user device.
[0162] A user device is provided having a transceiver that, during operation, receives system information relating to a non-terrestrial network from a network node; and processing circuitry that, during operation, (i) determines an indication of a system frame cycle count and an aiding information indication from the system information, (ii) determines an epoch time for deriving the aiding information based on the indication of the system frame cycle count, and (iii) derives the aiding information based on the epoch time and the aiding information indication.
[0163] For example, during operation, the processing circuitry determines an epoch time indication from the system information and determines the epoch time further based on the epoch time indication that references a system frame number, the system frame number being unique within one system frame cycle.
[0164] As another example, during operation the processing circuitry determines the epoch time of the assistance information with reference to the end of a window during which system information is transmitted.
[0165] For example, the maximum count of the system frame cycle is equal to or greater than the validity period of the system information.
[0166] In an exemplary embodiment, the system frame cycle count starts when the system information is updated and increments with each system frame cycle following the system frame cycle in which the system information was updated.
[0167] For example, an indication of the system frame cycle count corresponds to a hyperframe number, which indicates a count of the hyperframes that include a given number of system frames.
[0168] For example, the count of system frame cycles may be determined based on a validity indication and a predetermined validity duration, where the validity indication indicates the time period during which the system information is valid for use by a user device, and the validity information is reset to the predetermined validity duration in the system frame cycle during which the system information is updated and decremented in any other system frame cycle.
[0169] In some embodiments, the predetermined valid duration is set by a predetermined rule or standard, or is received by the transceiver (eg, in SIB1 or other information).
[0170] In any of the above embodiments, the system frame cycle count increases cyclically within a predetermined range.
[0171] The system information includes at least one of an ephemeris, a timing advance parameter, a validity duration of uplink synchronization information, a cell reference position, a scheduling offset between the uplink and downlink, and an uplink and / or downlink polarization indication.
[0172] For example, the aiding information indication may include at least one timing advance parameter, and the processing circuitry, during operation, may control the transceiver to apply the determined timing advance when transmitting signals. Alternatively or additionally, the aiding information may include satellite ephemeris.
[0173] In some embodiments, the transceiver receives system information during operation via dedicated signaling related to measurements or handovers.
[0174] A network node is provided having a processing circuit that generates, during operation, system information relating to a non-terrestrial network, the system information including an indication of a system frame cycle count and an aiding information indication, the aiding information signaled by the aiding information indication being derivable based on an epoch time and the aiding information indication, the epoch time being determined based on the indication of the system frame cycle count, and a transceiver that, during operation, transmits the system information.
[0175] A method is provided, the method comprising: receiving system information relating to a non-terrestrial network from a network node, determining an indication of a count of system frame cycles and an aiding information indication from the system information, determining an epoch time for deriving the aiding information based on the indication of the count of system frame cycles, and deriving the aiding information based on the epoch time and the aiding information indication, the method may be performed by a user device.
[0176] A method is provided for a network node comprising: generating system information for a non-terrestrial network, the system information including an indication of a count of a system frame cycle and an aiding information indication, the aiding information signaled by the aiding information indication being derivable based on an epoch time and the aiding information indication, the epoch time being determined based on the indication of the count of the system frame cycle; and transmitting the system information.
[0177] It should be noted that the method may also be performed by a processing circuit or integrated circuit of a user device, in which case, instead of the transmitting and receiving steps, the method comprises providing data for (over-the-air) transmission to a transceiver (or simply an output) and obtaining data (e.g. coefficients) from the transceiver (or simply an input).
[0178] In the present disclosure, an integrated circuit (IC) is provided that, in operation, performs the following: determining an indication of a count of system frame cycles and an aiding information indication from system information; determining an epoch time for deriving the aiding information based on the indication of the count of system frame cycles; and deriving the aiding information based on the epoch time and the aiding information indication. The IC further has an input to which the system information is provided from a receiver. Such input can be connected or may be connected to a transceiver that, in a practical embodiment, subsequently performs the receiving.
[0179] In the present disclosure, an integrated circuit (IC) is provided that, during operation, generates system information for a non-terrestrial network, the system information including an indication of a count of a system frame cycle and an aiding information indication, the aiding information signaled by the aiding information indication being derivable based on an epoch time and the aiding information indication, the epoch time being determined based on the indication of the count of the system frame cycle, and may further have an output at which the generated system information is provided for transmission, such as by a transceiver.
[0180] The present disclosure further provides program code that, when executed on one or more processors, causes the one or more processors to perform any of the methods described above. The program code may be stored on a non-transitory medium.
[0181] The present disclosure provides a communication system including a network node as described above and one or more user devices as described above, which may further include one or more NTN entities.
Claims
1. a transceiver that, during operation, receives system information relating to a non-terrestrial network from a network node; During operation, determining a system frame cycle count indication and an aiding information indication from the system information; determining an epoch time for deriving aiding information based on the indication of the system frame cycle count; a processing circuit for deriving the aiding information based on the epoch time and the aiding information indication; A user device having:
2. The processing circuitry, during operation, determining an epoch time indication from the system information; determining the epoch time further based on the epoch time indication referencing a system frame number; The user device of claim 1 , wherein the system frame number is unique within one system frame cycle.
3. The user device of claim 1 , wherein the processing circuitry, during operation, determines the epoch time of the assistance information with reference to an end of a window during which the system information is transmitted.
4. The user device of claim 1 , wherein a maximum count of system frame cycles is equal to or greater than a validity period of the system information.
5. 2. The user device of claim 1, wherein the count of system frame cycles starts when the system information is updated and increments with each system frame cycle following the system frame cycle in which the system information was updated.
6. the indication of the system frame cycle count corresponds to a hyperframe number; The user device of claim 1 , wherein the hyperframe number indicates a count of a hyperframe that includes a given number of system frames.
7. said system frame cycle count being determined based on a validity indication and a predetermined validity duration; the validity indication indicates a period of time during which the system information is valid for use by the user device; the validity information is reset to the predetermined validity duration in a system frame cycle in which the system information is updated and decremented in any other system frame cycle; The user device of claim 1 , wherein the predetermined valid duration is set by a predetermined rule or standard or is received by the transceiver.
8. The user device of claim 1 , wherein the system frame cycle count increases cyclically within a predetermined range.
9. The system information includes: - Ephemeris - Timing advance parameters - validity duration of uplink synchronization information - Cell reference position - a scheduling offset between the uplink and the downlink, and - Uplink and / or downlink polarization indication The user device of claim 1 , comprising at least one of:
10. the aiding information indication includes at least one timing advance parameter; The user device of claim 1 , wherein the processing circuitry, in operation, controls the transceiver to apply the determined timing advance when transmitting signals.
11. The user device of claim 1 , wherein the aiding information includes satellite ephemeris.
12. The user device of claim 1 , wherein the transceiver, during operation, receives the system information via dedicated signaling related to measurements or handovers.
13. a processing circuit configured to generate, during operation, system information for a non-terrestrial network, the system information including an indication of a count of a system frame cycle and an aiding information indication, aiding information signaled by the aiding information indication being derivable based on an epoch time and the aiding information indication, the epoch time being determined based on the indication of the count of the system frame cycle; a transceiver for transmitting said system information during operation; A network node having a
14. 1. A method for a user device, comprising: receiving system information relating to a non-terrestrial network from a network node; determining a system frame cycle count indication and an aiding information indication from the system information; determining an epoch time for deriving aiding information based on an indication of the system frame cycle count; deriving the aiding information based on the epoch time and the aiding information indication; The method comprising:
15. A method for a network node, comprising: generating system information for a non-terrestrial network, the system information including an indication of a count of a system frame cycle and an aiding information indication, the aiding information signaled by the aiding information indication being derivable based on an epoch time and the aiding information indication, the epoch time being determined based on the indication of the count of the system frame cycle; transmitting the system information; The method comprising:
16. Program code which, when executed on one or more processors, causes said one or more processors to perform any of the methods of claim 14 or 15.
17. During operation, determining an indication of a system frame cycle count and an indication of aiding information from the system information; determining an epoch time for deriving aiding information based on an indication of the system frame cycle count; deriving the aiding information based on the epoch time and the aiding information indication; An integrated circuit (IC) that performs the steps of:
18. During operation, generating system information for a non-terrestrial network, the system information including an indication of a count of a system frame cycle and an aiding information indication, aiding information signaled by the aiding information indication being derivable based on an epoch time and the aiding information indication, the epoch time being determined based on the indication of the count of the system frame cycle; An integrated circuit (IC) that performs the steps of:
19. A communication system comprising a network node according to claim 13 and one or more user devices according to any one of claims 1 to 12.