System and method for enhanced communication

Abstract

A communication system including at least non terrestrial access nodes, and terminals, and method of operation are described that are resilient to an access node being present but unavailable for communication. A schedule tasker is configured to receive a network schedule for the access nodes that comprises scheduling information of the availability of the access node for communications. The schedule tasker is configured to generate and distribute network information to system entities including terminals, access nodes, and gateway nodes. The network information for the terminals may include scheduling information or a sleep command which can be used by a terminal to control the state of the user node, such as a sleep state, such that the user node is allowed to communicate when one or more access nodes are available for communication and is prevented from communicating when no access nodes are available for communication (even if present).

Description

SYSTEM AND METHOD FOR ENHANCED COMMUNICATIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The following application claims priority to Australian Provisional Patent Application No.2025900812 filed on 14 / 03 / 2025 and Australian Provisional Patent Application No. 2025902133 filed on 30 / 05 / 2025. The content of each of these applications is hereby incorporated by reference in their entirety.

[0002] The following applications are referred to in the present application and their contents are hereby incorporated by reference in their entirety:PCT / AU2013 / 000895 titled CHANNEL ALLOCATION IN A COMMUNICATION SYSTEM and filed on 14 / 08 / 2013 claiming priority from Australian Provisional Patent Application No.2012903489 filed on 14 / 08 / 2012;PCT / AU2013 / 001078 titled COMMUNICATION SYSTEM AND METHOD and filed on 20 / 09 / 2013 claiming priority from Australian Provisional Patent Application No. 2012904130 filed on 21 / 09 / 2012;PCT / AU2013 / 001079 titled MULTI-ACCESS COMMUNICATION SYSTEM and filed on 20 / 09 / 2013 claiming priority from Australian Provisional Patent Application No. 2012904145 filed on 21 / 09 / 2012;PCT / AU2014 / 000826 titled A MULTIUSER COMMUNICATIONS SYSTEM and filed on 21 / 08 / 2014 claiming priority from Australian Provisional Patent Application No. 2013903163 filed on 21 / 08 / 2013;PCT / AU2015 / 000743 titled MULTICARRIER COMMUNICATIONS SYSTEM and filed on 9 / 12 / 2015 claiming priority from Australian Provisional Patent Application No. 2014904976 filed on 9 / 12 / 2014;PCT / AU2017 / 000058 titled TERMINAL SCHEDULING METHOD IN SATELLITE COMMUNICATION SYSTEM and filed on 24 / 02 / 2017 claiming priority from Australian Provisional Patent Application No. 2016900685 filed on 25 / 02 / 2016;PCT / AU2017 / 000108 titled POSITION ESTIMATION IN A LOW EARTH ORBIT SATELLITE COMMUNICATIONS SYSTEM and filed on 16 / 05 / 2017 claiming priority from Australian Provisional Patent Application No. 2016901913 filed on 20 / 05 / 2016;PCT / AU2017 / 000286 titled SYSTEM AND METHOD FOR GENERATING EXTENDED SATELLITE EPHEMERIS DATA and filed on 21 / 12 / 2017 claiming priority from Australian Provisional Patent Application No. 2016905314 filed on 22 / 12 / 2016;PCT / AU2018 / 000150 titled TERMINAL IDENTITY PROTECTION METHOD IN A COMMUNICATION SYSTEM and filed on 28 / 08 / 2018 claiming priority from Australian Provisional Patent Application No. 2017903469 filed on 28 / 08 / 2017;PCT / AU2018 / 000151 titled SYSTEM AND METHOD FOR PREDICTION OF COMMUNICATIONS LINK QUALITY and filed on 28 / 08 / 2018 claiming priority from Australian Provisional Patent Application No. 2017903470 filed on 28 / 08 / 2017;PCT / AU2021 / 000027 titled SYSTEM AND METHOD FOR ADAPTIVE COMMUNICATIONS and filed on 29 March 2021 claiming priority from Australian Provisional Patent Application No. 2020901049 filed on 3 / 04 / 2020;PCT / AU2023 / 050178 titled COARSE GEOLOCATION OF REMOTE TERMINALS and filed on 14 March 2023 claiming priority from Australian Provisional Patent Application No. 2022900611 filed on 14 / 03 / 2022; andPCT / AU2024 / 051366 titled SATELLITE AND METHOD OF OPERATION and filed on 18 December 2024 claiming priority from Australian Provisional Patent Application No. 2023904225 filed on 22 / 12 / 2023.TECHNICAL FIELD

[0003] The present disclosure relates to wireless communication systems. In a particular form the present disclosure relates to the enhancement of a communication system to support flexible availability of the network.BACKGROUND ART

[0004] There is an increasing demand for internet of things (loT) connectivity for small, low cost sensors and devices, and for direct-to-device non-terrestrial communications to mobile handsets. In many cases devices are energy constrained due to a need to operate from a battery. Remote loT applications are heavily constrained by a need to operate for long periods of time without battery replacement. Example applications include telemetry for devices such as pumps, tank level meters, utilities metering, and sensors such as soil moisture probes. Many of these applications are located in areas that do not have terrestrial communications networks such as cellular, and the cost of deploying a dedicated local wireless solution is prohibitive. For such applications anon-terrestrial, e.g. satellite -based, solution is attractive. A further design constraint is cost. In order to provide connectivity to large numbers of low cost sensors and devices, it is desirable that the communications module be as cheap as possible.

[0005] One approach to reducing the cost for user terminals for loT sensors and devices, is to utilise user node modules based on communication standards such as 3 GPP which include support for non terrestrial access nodes, such as satellite access nodes and High Altitude Platforms (HAPS). The widespread applicability and use of 3GPP enables the low cost mass production of 3GPP compliant user node modules. However, whilst the 3GPP standard includes support for non-terrestrial access nodes, the standard is not well matched to the power constraints of some loT applications. Specifically, mostcommunication standards, including 3GPP, assume that when a non-terrestrial access nodes (or in fact any access node) is visible to a terminal, then it is available for communication with a terminal. In this case visibility means the terminal is within the field of view, e.g. within a spot beam, of a satellite or a non-terrestrial access node. Visibility can be determined by the terminal using a knowledge of the terminal’s location, current time and ephemeris data of the access nodes. That is the physical presence of an access node is assumed to be a sufficient condition for a terminal to establish a connection (or transmit data) to an access node. For completeness, this assumption also extends to terrestrial access nodes.

[0006] This simplifies the design of the communication system as access nodes, or other system entities can be configured to transmit ephemeris data to terminals so terminals can determine when access nodes are visible (physically present). A terminal can wake to listen for transmissions, or when ready to transmit, the terminal can attempt to establish a connection, or simply transmit data if no handshaking / connection is required. In the event a connection can’t be established, the terminal can perform a search for the access node. Similarly, if the ephemeris data is invalid (e.g., out of date), the terminal can perform a cold start search to locate an access node. However, such searches, and in particular cold start searches, can consume large amounts of power and so are extremely undesirable in loT systems where power conservation of the terminal is of prime importance.

[0007] However, in some cases, whilst an access node may be visible to a terminal, it may not necessarily be in a state to establish a connection or to receive transmissions from the terminal (i.e., it is physically present, but unavailable for communications). For example, a satellite access node may not have a sufficient power budget to operate the access node over all regions, and thus may not accept connections or receive transmissions in some regions, or the access nodes may be experiencing a planned service outage, or the network operator may wish to save network operating costs, by placing an access point in a sleep or low power mode in which communications capabilities are disabled for a period to reduce network operating costs.

[0008] If a terminal expects an access node to be available due to being visible (i.e., physical present or overhead) and the access node is not available for communication, then the terminal can waste significant energy transmitting or attempting to connect to the access node, particularly if a lack of connection triggers repeated searching or a cold start search in the belief information is out of date . Thus, the assumption that visibility of an access node is a sufficient condition for communication is thus a significant problem for energy constrained loT systems where conservation of battery life of a terminal is a primary design requirement or constraint. This limits the ability to use cheap mass produced standards compliant user nodes in terminals.

[0009] There is thus a need to provide methods and communication systems configured to be resilient to access node being present but unavailable for communications, or to at least provide a useful alternative to existing methods and systems.SUMMARY

[0010] The typical assumption in many communication systems, including those based on the 3GPP based communication standards, is that physical presence of an access node equates to availability.Embodiments of communication systems and methods of operation are described that are configured to be resilient to an access node being present but unavailable for communications. The communication system at least comprises non-terrestrial access nodes, and may also comprise terrestrial access nodes (collectively referred to as access nodes). Embodiments use a schedule tasker that is configured to receive a network schedule for the access nodes that comprises scheduling information of the availability of at least one or more of the non-terrestrial access nodes for communications. That is the scheduling information could be provided for a subset of the non-terrestrial access nodes (including one nonterrestrial access node), or all non-terrestrial access nodes in the system. The schedule tasker is configured to generate and distribute network information to system entities including terminals, access nodes, and gateway nodes. The network information includes tasking information to control or configure operation of the respective access node or gateway node according to the schedule. The network information for the terminals may include scheduling information or a sleep command which can be used by a terminal to control the state of the user node such that is allowed (or permitted) to communicate when one or more access nodes are available for communication. The scheduling information could relate to at least one or more of the non-terrestrial access nodes, or all of the non-terrestrial access nodes, as well as some or all of the terrestrial access nodes, i.e., all access nodes in the system. In the case of scheduling information the terminal can use the scheduling information to control the user node so that it is allowed (permitted) to communicate when one or more access nodes are available for communication and is prevented from communicating when no access nodes are available for communication (even if present). This may be performed by sending a sleep command to the user node so that the user node remains asleep when no access nodes are available for communication and woken when an access node is available. The network information could also be sent to the terminal as a sleep command for the user node to control a waking or sleeping state such that the user node is allowed to communicate when one or more access nodes are available for communication. Effectively the user node can be put to sleep, or otherwise prevented from attempting to communicate when there are no access nodes available for communication, even though they may be physically overhead or in communication range. Other mechanisms could be used to control whether the user node is allowed to communicate, for example an allowance state could be stored in a memory which the user node could check (i.e. lookup), or an error code could be provided to the user node indicating the communication components of the terminal are unavailable or offline. During allowed(or permited) time periods the user node can separately determine whether to actually communicate (i.e. send a transmission). In some embodiments the user node may also be allowed to atempt to discover an access node for establishing a connection regardless of the network information.

[0011] According to a first aspect, there is provided a terminal apparatus for use in a communication system comprising one or more access nodes, the one or more access node comprising one or more nonterrestrial access nodes, one or more gateway nodes, and a schedule tasker, the terminal apparatus comprising:a terminal application that generates messages;one or more antennas;a user node configured to communicate with the one or more access nodes of the communication system using the one or more antennas; andan enhancement layer configured to:receive and process network information, wherein the network information comprises either scheduling information of an availability for communication of at least one or more of the one or more non-terrestrial access nodes in the communication system, or a sleep command; and control a state of the user node based on the network information such that the user node is allowed to communicate when one or more access nodes are available for communication.

[0012] The communication system at least comprises non-terrestrial access nodes. In embodiments where the communication system only comprises non-terrestrial access nodes, then the scheduling information may be provided for a subset of the non-terrestrial access nodes (including one non-terrestrial access node), or it may be provided for all the non-terrestrial access nodes in the system. In embodiments where the communication system comprises both non-terrestrial access nodes and terrestrial access nodes, the scheduling information could be provided just for some or all of the non-terrestrial access nodes (as above), or for some (i.e. one or more) non-terrestrial access nodes and some (i.e. one or more) or all terrestrial access nodes as terrestrial access nodes may also have periods of communication unavailability. The use of “at least one or more of the one or more non-terrestrial access nodes” thus covers several scenarios (i.e., covers only one or more non-terrestrial access nodes, or combination of non-terrestrial and terrestrial access nodes, or each of the access nodes in the communication system).

[0013] In one form, controlling a state of the user node comprises preventing the user node transmiting when no access nodes are available for communication. This may comprises controlling a sleep state of the user node, sending commands or error codes to the user node so that it does not atempt to send a transmission, or controlling a state (or status) variable which is used by the user node to determine whether to send a transmission.

[0014] In one form, the network information is scheduling information, and controlling a state of the user node comprises controlling a sleep state such that the user node is allowed to wake up when one or more access nodes are available for communication based on the scheduling information and putting the user node to sleep when no access nodes are available for communication. In a further form, the scheduling information may comprise one or more time windows of availability for the respective access node, each time window having a start time and a duration. In a further form, the scheduling information may comprise an ordered list of gaps starting from a reference time. In another further form, the communication system may be divided into a plurality of service zones, where each service zone is a geographical region, and network information is generated for each service zone, and each service zone is assigned one or more schedules, and a terminal uses the union of the one or more schedules to determine when no access nodes are available. In another further form, the scheduling information of the availability of the one or more access node may further comprise the one or more operating frequencies of the respective access nodes. The scheduling information could also be provided for access nodes in multiple networks, for example, each identified by an independent Public Land Mobile Network (PLMN) number or similar network identifier.

[0015] In one form, the network information may be a sleep command and controlling a state of the user node comprises controlling a sleep state of the user node by waking up the user node when one or more access nodes are available for communication and putting the user node to sleep when no access nodes are available for communication.

[0016] In a further form, the enhancement layer may be further configured to queue one or more messages received from the terminal application for transmission by the user node at least until one or more access nodes are available for communication. In a further form, the network information may further comprise an immutable set of access windows for the one or more access nodes which do not change, and the terminal apparatus stores the immutable set of access windows. In a further form, the enhancement layer may be further configured to allow a user node to wake up to attempt to discover an access node for establishing a connection regardless of the network information. In one form, after receiving the network information, the network information is stored and existing network information may be updated or replaced based on the received network information. In a further form each terminal may calculate or store a terminal network information version identifier (TNIVI) that represents a version of the network information being used by the terminal apparatus, and the terminal apparatus uses the TNIVI to determine whether to update received network information. In a further form the user node may be a 3 GPP compliant user node.

[0017] According to a second aspect, there is provided a communication system comprising:one or more access nodes, the one or more access node comprising one or more non-terrestrial access nodes;one or more gateway nodes;a service platform;a plurality of terminal apparatus according to the first aspect, including any of the forms and further form in any combination; anda schedule tasker,wherein,each user node in a terminal apparatus is configured to connect with the one or more access nodes, and the one or more gateways connect the one or more non-terrestrial access nodes to the service platform, such that data may be exchanged unidirectionally in either direction between the terminal application and the service platform, or bi-directionally between the terminal application and the service platform, andthe schedule tasker is configured to receive a network schedule for the one or more access nodes comprising scheduling information of the availability of at least one or more of the one or more nonterrestrial access nodes, and the schedule tasker is configured to generate and distribute network information for the plurality of terminal apparatus, the one or more access nodes, and the one or more gateway nodes, and the network information for the one or more access nodes and one or more gateway nodes comprises tasking information to control and / or configure operation of the respective access node or gateway node according to the schedule and the network information for a terminal apparatus comprises either a sleep command or scheduling information of the availability for communication of at least one or more of the one or more non-terrestrial access nodes, and each terminal is configured to process received network information to control a state of the user node based on the network information such that a user node of the respective terminal is allowed to communicate when one or more access nodes are available for communication.

[0018] The communication system may implement any of the forms discussed above in relation to the terminal apparatus of the first aspect. In one form, the network information maybe unicast to a terminal apparatus by an access node, and may be sent to a respective terminal apparatus in response to receiving a transmission or message from the terminal apparatus (i.e. piggybacking on a received transmission; other data for the terminal apparatus may also be sent). In some forms the network information is multi -cast or broadcast to the terminals.

[0019] In one form, the communication system may further comprise a network enhancement module which stores the network information, and on receipt of network information from the schedule tasker, updates the stored network information, and performs configuration and tasking of the respective nonterminal entity based on the network information, wherein the non-terminal system entities comprise the one or more access nodes, one or more gateway nodes, the core network, the service platform, and the central user application, or anything that is not a terminal apparatus. In one form the schedule tasker isimplemented in the service platform. In one form, the communication system is divided into a plurality of service zones, where each service zone is a geographical region, and network information is generated for each service zone, and the scheduling information sent to a terminal apparatus comprises scheduling information for the service zone. In a further form, each service zone is assigned one or more schedules, and a terminal apparatus uses the union of the one or more schedules to determine when no access nodes are available

[0020] In one form, each terminal apparatus calculates or stores a terminal network information version identifier (TNIVI) that represents a version of the network information being used by the terminal apparatus, and the network tasker or terminal apparatus uses the TNIVI to determine whether to update network information. In one form, the network schedule comprises an immutable set of access windows which do not change, and the immutable set of access windows are stored on the terminal apparatus. They may be uploaded to the terminal apparatus prior to deployment, or may be downloaded via a downlink after deployment.

[0021] In one form the communication system may further comprise a network scheduler configured to generate a network schedule which is sent to the schedule tasker. The network schedule may generate the network schedule using one or more of the following:input from third parties;time varying physical availability of network components, for example such that network components are only scheduled for use in a service zone when they are physically available to that zone;end user requirements on latency, e.g. to target a latency requirement for example by using an optimisation method so that a revisit to a service zone occurs frequently enough to satisfy customer devices in that zone;required capacity in each service zone, e.g. ensuring that the network is able to support the required number of devices, and the network load presented by those devices within the service zone; capabilities of network system entities, e.g. satellite power and link budgets;network load balancing objectives, e.g. ensuring that zones are not underutilised or overloaded; radio frequency spectrum availability, e.g. allocating specific radio channels to different service zones;the interference environment, e.g. scheduling availability to be orthogonal to interference in time and / or frequency;cost of network operations, e.g. scheduling activity during periods of reduced operating costs; the availability of network components operated by third parties and leased to the communication system, e.g. ground station and satellite operators;the availability of spectrum resources from regulatory authorities, e.g. regulatory authorisations; andthe availability of channel resources from other operators sharing the resource.

[0022] In one form, the one or more access nodes further comprise one or more terrestrial access nodes which are configured to either connect directly to the core network or connect to the core network via one or more gateways, and the network information comprises scheduling information of the availability of each of the access nodes (i.e., both terrestrial and non -terrestrial). In one form the service platform is configured to execute a plurality of central user applications for a plurality of users, and each terminal application in a terminal is a remote user application associated with one or more central user applications in the service platform and the communication system is configured such that data may be exchanged unidirectionally in either direction between the remote user application and the associated one or more central user applications, or bi-directionally between the remote user application and the associated one or more central user applications. The central user application may also be an API interface (or similar) to allow users to provide data to the terminal (and need not be specifically linked with a remote user application). These, and other features of the communication system are described below and in the claims.

[0023] According to a third aspect, there is provided a schedule tasker apparatus for use in the communication system of the second aspect including any of the forms and further form in any combination, comprising:at least one memory, andat least one processor, wherein the at least one memory comprises instructions to configure the at least one processor to:receive a network schedule for the one or more access nodes in the communication system comprising scheduling information of the availability for communication of at least one or more of the one or more non-terrestrial access nodes; andgenerate and distribute network information for the plurality of terminal apparatus, the one or more access nodes, and the one or more gateway nodes, and the network information for the one or more access nodes and one or more gateway nodes comprises tasking information to control operation of the respective access node or gateway node according to the schedule and the network information for a terminal apparatus comprises either a sleep command or scheduling information of the availability for communication of at least one or more of the one or more non-terrestrial access nodes, and each terminal apparatus is configured to process received network information to control a state of the user node based on the network information such that the user node is allowed to communicate when one or more access nodes are available for communication.

[0024] According to a fourth aspect, there is provided a method of maintaining scheduling transmission in the communication system of the second aspect including any of the forms and further form in any combination, comprising:receiving by a schedule tasker, a network schedule;determining network information for one or more terminal apparatus wherein the network information comprises scheduling information of the availability for communication of at least one or more of the one or more non-terrestrial access nodes in the communication system;distributing the network information to the one or more terminal apparatus using the communication network; andreceiving, by a terminal apparatus, network information wherein the network information comprises either scheduling information of the availability for communication of at least one or more of the one or more non-terrestrial access nodes in the communication system, or a sleep command, and controlling a state of the user node based on the network information such that the user node is allowed to communicate when one or more access nodes are available for communication.. The network information may be stored and existing network information may be updated or replaced.

[0025] The method may further include steps based on any of the actions of the terminal or communication system discussed above or herein (in any combination). In one form, the network schedule for the one or more access nodes comprising scheduling information of the availability of at least the one or more non-terrestrial access nodes and the method further comprises, generating and distributing network information for the one or more access nodes and the one or more gateway nodes, and the network information for the one or more access nodes and the one or more gateway nodes comprises tasking information to control and / or configure operation of the respective access node or gateway node according to the schedule. In one form the method may further comprise generating, by a terminal apparatus, a terminal network information version identifier (TNIVI) that represents a version of the network information being used by the respective terminal apparatus, and the network tasker or terminal apparatus uses the TNIVI to determine whether to update network information. In one form, distributing the network information to the one or more terminals comprises multi-casting or broadcasting the network information by one or more access nodes using any combination of extension fields of system information blocks (SIBs), extension fields of master information blocks (MIBs), a warning message segment field of a public warning system (PWS) SIB for emergency notification, and a 3GPP single-cell point-to-multipoint (SC-PTM) broadcast channel.BRIEF DESCRIPTION OF DRAWINGS

[0026] Embodiments of the present disclosure will be discussed with reference to the accompanying drawings wherein:

[0027] Figure 1 is a schematic diagram of a satellite communications system according to an embodiment;

[0028] Figure 2 is a schematic diagram of a satellite pass over a device according to an embodiment;

[0029] Figure 3A is a schematic diagram of a regular schedule of access node availability according to an embodiment;

[0030] Figure 3B is a schematic diagram of an irregular schedule of access node availability according to an embodiment;

[0031] Figure 3C is schematic diagram of the structure of a schedule of access node availability according to an embodiment;

[0032] Figure 3D illustrates several examples of service zones according to an embodiment;

[0033] Figure 3E is a schematic diagram of a set of service zones based on a base pattern according to an embodiment;

[0034] Figure 4 is a schematic diagram of the scheduling system according to an embodiment;

[0035] Figure 5 illustrates a cold start procedure 500 according to an embodiment;

[0036] Figure 6A is a schematic diagram of an initial schedule with immutable access windows according to an embodiment;

[0037] Figure 6B is a schematic diagram of an updated schedule with immutable access windows according to an embodiment;

[0038] Figure 7 is a schematic diagram of the scheduling system in which the network information is used to directly control a sleep state of a user node of a device according to an embodiment; and

[0039] Figure 8 is a flowchart of a scheduling method according to an embodiment.

[0040] In the following description, like reference characters designate like or corresponding parts throughout the figures.DETAILED DESCRIPTION

[0041] Referring now to Figure 1, there is shown a schematic block diagram of a satellite communications system 1 according to an embodiment. In this example embodiment, the communication system 1 comprises a plurality of terminal apparatus 12 (which for simplicity we will simply refer to asterminals in the following discussion), one or more access nodes 22, one or more gateway nodes 32, a core network 40 and a service platform 50. The terminals 12 communicate with each of the access nodes 22 over a radio access interface 24. The system includes at least one non-terrestrial access node 22, and may optionally include terrestrial access nodes 22". In some embodiments the communication may thus comprises a single non-terrestrial access node 22, such as access node on board a non-terrestrial access station 20 such as a GEO, MEO, or LEO satellite or a high altitude platform station (HAPS). In some embodiments the communication system comprises multiple access nodes including one or more nonterrestrial access nodes 22, and optionally one or more terrestrial access nodes 22" located in a terrestrial access station 20". The access node may be a distributed access node 22' in which functionality is distributed over multiple system entities, e.g. non -terrestrial access station 20 which captures samples and forwards to the ground station 30 for decoding and message recovery. The non-terrestrial access nodes 22 communicate with one or more gateway nodes 32, located in one or more ground stations 30, which in this example is over a gateway radio interface 26, although another communication interface could be used such as an optical fibre connection in the case of a drone, airborne access node, or HAPS . The gateway nodes 32 and any terrestrial access nodes 22" present, are connected to the core network 40 over one or more wired or wireless links, and the core network 40 is further connected to a service platform 50. As shown in Figure 1, data may originate in devices 10 or terminals 12 (solid arrows) or terminate in (received by) devices 10 or terminals 12 (dashed arrow) and the communication system is configured to allow the transfer of data between the terminals 12 (and thus devices 10) and the service platform 50. The transfer of data may be uni-directional, in either direction, and / or bi-directional transfer of data to / from the terminals 12 from / to the service platform 50. That is communication system may simultaneously support uni-directional and bi-directional data flows, with some terminals 12 being configured as unidirectional devices (in either direction) and others as bi-directional terminals. It is also to be understood that Figure 1 shows an example architecture to assist with understanding the communication system, and other communication system architectures could be used. For example, the access nodes 22 and / or core network 40 could be functionally distributed across the communication system 1 and / or be integrated with the service platform 50, e.g., there is no separate or distinct access node or “core”. The access node or core network could also be a part of, or hosted with, the service platform 50 in a cloud computing environment. For example the access node 22 could be implemented in part (or whole) in the cloud, for example processing digital spectrum data received over the internet (or similar) before interfacing to the core network.

[0042] The terminals 12 are each located in devices 10 which includes one or more sensors, actuators, or trackers 11 and the terminals 12 are configured to provide loT connectivity to the device 10. The terminals 12 may be integrated with the devices 10, or may be connected to a device, for example over a local wired link or wireless link. The devices 10 may be mounted to, and may interface with, remote assets, which may be fixed or moving (i.e. the device is mobile device), including livestock, personnel,vehicles, industrial machinery, shipping containers, and environmental sensors. Devices may be permanently fixed in a location, or may be fixed for long periods (months or years) before being redeployed to another location. The devices 10 may be geographically distributed across large areas including across countries, oceans, and around the world. Embodiments of the communication system 1 can thus be used for monitoring and / or controlling large numbers of remotely located assets and sensors operated by a large number of users over large geographical areas.

[0043] The devices 10 may also include a controller 13 such as microprocessor, microcontroller, system on a chip or other computing device for controlling operation of the device, along with one or more antennas 15 and a battery 19 for supplying power to the device 10 and the terminal 12. The controller 13 may include a power control module for monitoring the state of charge of the battery 19 and controlling the power state of the device 10, including providing low power and / or sleep states. Each terminal 12 comprises a terminal application 14, which in this case is a remote user application, and a user node 16 that provides network connectivity to the access nodes 22 over a radio access interface 24. The downlink of the radio access interface 24 represents communications to a terminal 12 from an access node 22 (dashed black arrow) and the uplink represents communications from the terminal 12 to the access node 22 (solid black arrow). The terminal application can be any application that generates messages for transmission by the terminal, and may be a remote user application linked to a central user application, or it may be an application executing on the terminal that generates messages, for example based on sensor data or to provide status information on the terminal or the device 10. For the sake of convenience in the following discussion we will refer to the terminal application 14 as a remote user application 14, but it is to be understood that the terminal application could be a more general application that generates, obtains or collates data to be sent in a message. A central user application may provide an API interface to allow users to provide data to be sent to the terminal application 14 in the terminal apparatus 12.

[0044] The communication system is configured such that data may be exchanged unidirectionally in either direction between the remote user application 14 and the service platform 50, or bi-directionally between the remote user application 14 and the service platform 50. The data may be exchanged in the form of messages, and the system may support a range of message types including data messages and diagnostic messages, with each message including predefined fields. For example, a data message could comprise a header field, a terminal identifier field, and a payload (data) field. Each terminal may have a terminal identifier which can be included in, or determined from a message, for example using encryption techniques (see for example PCT / AU2018 / 000150). The remote user application 14 may generate messages from data for transmission to the service platform 50, for example data messages containing sensor data or location data, as well as diagnostic messages for the core network 40 or service platform 50. The service platform may include or provide a connection to a plurality of central application programs 54 and the data messages, or data from a message, maybe provided to one or more centralapplication programs. In some embodiments each user application 14 in a terminal 12 is associated with one or more central user applications 54, each of which may be associated with a user. The remote user application also processes received messages from the service platform 50 or associated central application program(s) 54, for example to control or configure the sensor 11 or user device 10, as well as system control or configuration messages received from the core network 40, service platform 50 or other system entity. The service platform 50 and / or the plurality of central user applications 54 allows each user to monitor or control their set of remotely located devices 10. The communication system 1 may be configured to allow uni-directional data to be sent from / to the respective user application 14 to / from the respective central user application(s) 54 or to allow the bi-directional exchange of data between the respective user application 14 and the respective central user application(s) 54. Device originated data is shown in Figure 1 with solid black arrow and device terminated data is shown with dashed black arrows.

[0045] One or more radio access interfaces 24 may be provided to enable terminals 12 to communicate with the access nodes 22 using one or more frequency bands, or standards. The set of all radio access interfaces used by the system is referred to as the Radio Access Network (RAN). Terminals and access nodes may each implement one, multiple or all the radio access interfaces in the RAN. The choice of which radio access interfaces to implement may be based on factors such as cost, location, and function. For example, a terminal may implement a limited set of radio access interfaces 24 to keep costs low and to be compliant with specific standards or spectrum allocations within a geographical region or jurisdiction. In contrast, a satellite access node which is servicing multiple geographical regions or jurisdictions may support a larger number of radio access interfaces 24 to maximise the ability of a terminal to communicate with the access node across multiple geographical regions or jurisdictions.

[0046] The user node 16 in the terminal 12 may be a communications module or modem which communicates with access nodes 22 over a radio access interface 24 using one or more device antennas 15. The user node 16 may support multiple radio access interfaces 24 and may be a standards compliant communications module such as a 3 GPP compliant communications module. The antennas 15 may be monopoles, dipoles, chip antennas, patch antennas, antenna arrays, inverted-F antennas, or any other antenna known to those skilled in the art. The device 10 may include different antennas for interfacing with different radio access interfaces 24. For example, it may include an antenna with a gain pattern suited to communication with a terrestrial access node 22" station, such as a monopole, chip, or inverted-F antenna, and an antenna suitable for communication with anon-terrestrial access node 22 (e.g. satellite), such as a circularly polarised patch antenna.

[0047] The access nodes 22 may be implemented as non-terrestrial access nodes 22, and in some embodiments, as terrestrial access nodes 22" (noting the communication system includes at least one nonterrestrial access node). Further the access nodes 22 may be implemented in a single access station (nonterrestrial station 20 or terrestrial station 20"), or the access node functionality may be distributed acrossmultiple system entities. We will define a non-terrestrial access node 22 as an access node in which at least the transmitter and receiver for the radio access interface 24 are located on a non-terrestrial platform 20, such as onboard a LEO, MEO or GEO satellite or a HAPS. Similarly, we will define a terrestrial access node 22" as an access node in which at least the transmitter and receiver for the radio access interface 24 are located on a terrestrial platform 20". The non-terrestrial access node 22 may be a distributed access node in which the non-terrestrial access station 20 is configured as bent pipe type system. In these embodiments the non -terrestrial access station 20 comprises a receiver which supports one or more radio access interfaces 24 to receive transmissions from terminals 18. These signals are either relayed to a ground station 30 over the gateway interface 26 (i.e. traditional bent pipe), or the nonterrestrial access station 20 (or components of the access node 22) may be configured to capture spectrum samples received over the radio access interface 24, and these spectrum samples are transmitted to the ground station 30 over the gateway interface 26. These received signals or spectrum samples may be processed by distributed access node components 22' in the ground station 30, or in other system entities such as the core network 40 and / or service platform 50, or by a cloud server. For example, received digital spectrum data could be provided to a cloud server over the internet for processing, and the recovered data then provided to the core network. In some embodiments some components of the network stack of the access node may be implemented in the access node 22 onboard a satellite station or HAPS 20, and other components of the network stack of the access node may be implemented in an access node 22' in the ground station 30. The communication system may comprise both access nodes implemented in single access stations as well as distributed access nodes distributed across multiple access stations and / or ground stations.

[0048] The gateway interface 26 delivers feeder link connectivity for data transport between a nonterrestrial access node 22 and a gateway node 34. The system 1 may comprise a plurality of geographically distributed gateway nodes 34 (in ground stations 30), each implementing the necessary protocols to support a plurality of access nodes to interface with the network. One or more core networks 40 support the access nodes 22 across the communication system. The core network 40 comprises one or more computing devices 42 which are configured to manage the communication system, for example provide authentication services to ensure only recognised terminals can access the communication system, and to manage system load and latency. However, it is to be understood that the communication system architecture may take other forms, and functionality may be distributed across the system differently to that shown in Figure 1. For example, the core network 40 may take different forms or be distributed across, or integrated with other system entities such as the ground station, access station, or service platform. It is to be understood that the functionality and methods described herein may be applied in these cases.

[0049] The radio access interfaces 24 and gateway interfaces 26 may be configured to use a wide range of frequences including those in the VLF, LF, MF, HF, VHF, UHF, L-band, S-band, C-band, X-band, Ku-Band, K-Band, Ka-Band, V-Band and W-band. Typically, the gateway interface 26 will be a radio interface although in some cases an optical (e.g. laser based) interface or a mixture of radio and optical interfaces could be used including the use of links between non -terrestrial stations, such as intersatellite links.

[0050] A service platform 50 provides transport of data to and from the plurality of central user applications 54 or directly to users, e.g. by forwarding to a user specified IP address or by providing a data repository the user can access and implements additional functions such as device management and billing. The service platform 50 allows users to remotely control or configure the devices 10, for example by receiving and forwarding control commands from an approved IP address or port, or by providing the central user application 54 to allow the user to send commands to the devices to control or configure them (device terminating data in Figure 1). The central user applications 54 may process data received from the user devices 10 and / or preparing and delivering data to the communication system for delivery to devices 10, or otherwise allow the user to interact with and monitor their devices or received data. The central user application 54 may also allow a user to view the status of all of their devices, including both individually, or in groups (for example by region or type). The service platform 50 may also act as a storage repository for data received from the user’s devices and provide analytics functionality. There may be a single central user application 54 that provides functionality for multiple users where each user can login and view their devices, and the platform provides a set of common commands / interfaces to all users, or there may be multiple central user applications 54 which maybe customer specific or support multiple customers with each central user application providing different functionality. The service platform 50 may comprise one or more computing apparatus 52 and may be a cloud based computing system. The service platform 50 may also implement functions required to manage and control network infrastructure such as terrestrial base stations, satellite ground stations, satellites, and HAPS. It may also send data, such as control data, to devices 10 or terminals 12; and receive data, such as diagnostics data, from devices 10 or terminals 12. The central user applications 54 may interface with the communication system via the service platform 50 (as shown in figure 1) or directly via the core network 40 (omitted from the figure for simplicity). In some embodiments the core network 40 may be included in the service platform 50. The service platform may also host or provide / execute the functionality of the schedule tasker 64 discussed below. In summary the communication system is configured to allow uni -directional (in either direction) or bi-directional transfer of data from / to the devices 10 (or terminals 12) to / from the service platform 50. The implementation of the network may be varied based on specific requirements.

[0051] For simplicity, Figure 1 only shows the case of a device 10 communicating via a non -terrestrial access station 20 that is connected to the core network 40 via a ground station 30. Those skilled in art willrecognise that the communication system 1 may comprise a mixture of non-terrestrial network (NTN) components and terrestrial network (TN) components. For example, the network may have non-terrestrial Access Nodes 22 and terrestrial access nodes 22”, and a device may have the ability to communicate with both. The device 10 may have multiple antennas 15 and may switch antennas when communicating with non-terrestrial access nodes 22 and terrestrial access nodes 22", and select the most appropriate antenna for the type of access node the device is communicating with. A terminal 10 may communicate with multiple access nodes, using a range of radio access interfaces 24 to connect to a common core network 40. A device 10 may also communicate with multiple communication networks, e.g. roaming between them with roaming supported via a core-to-core communication interface.

[0052] The communication system 1 may implement communication systems, methods, components and apparatus such as those described in PCT / AU2013 / 000895, PCT / AU2013 / 001078, PCT / AU2013 / 001079, PCT / AU2014 / 000826, PCT / AU2015 / 000743, PCT / AU2017 / 000058, PCT / AU2017 / 000108, PCT / AU2017 / 000286, PCT / AU2018 / 000151, PCT / AU2021 / 000027, PCT / AU2023 / 050178 and PCT / AU2024 / 051366. The communication system may be a proprietary communication system or a communications systems developed collaboratively e.g. via a standards framework or industry led group including 3GPP, IEEE, ITU, ETSI, GSMA, LoRaWAN, Mioty, Sigfox, and may be a combination of these systems (including proprietary components). In some embodiments the communications system is based on a 3GPP standardised communications system including non-terrestrial network entities, implemented using transparent (bent pipe) or regenerative architectures, and the radio access interface 24 is implemented using 3GPP compatible spectrum, and the user nodes 16 are 3GPP compliant user nodes.

[0053] The communications system 1 may comprise access nodes 22 that deliver discontinuous coverage to a geographical area. For example, a satellite 20 in a low Earth orbit (LEO) may be physically present as it passes over a geographic region for a short number of minutes. A terminal 12 may be aware of the presence of the access node 22 by maintaining a model of its dynamic behaviour, e.g. in the case of a LEO satellite the terminal 12 may use satellite ephemeris data to predict availability of a satellite -based access node 22. However, whilst the terminal may be able to determine that the terminal is within the field of view of the satellite (or non-terrestrial) access node, i.e., the access node is physically present over, or visible to the terminal, the satellite (or non-terrestrial) access node may not be available for communication. The unavailability of a non-terrestrial access node for communications could arise for multiple reasons such as:• the non-terrestrial access node having an insufficient power budget to operate the access node over all regions;• the non-terrestrial access node having insufficient computation or storage resources to operate over all regions;• to avoid interference, either by the non-terrestrial access node or due to the presence of an interfering source in the current geographic region;• the access node could be experiencing a planned or unplanned service outage;• the access nodes may be multiplexing its resources across multiple services; or • the network operator could temporarily disable communications for a period of time to save operating costs.

[0054] In some embodiments the access node could be a LEO, MEO, or GEO satellite with multiple beams, each covering a different geographic region which may not always be available thus providing discontinuous or intermittent coverage in each geographic region. However it will be realised that terrestrial access nodes may also have periods of unavailability, for example due to a planned or unplanned service outage, or when multiplexing its resources across multiple services. Thus in some embodiments one or more terrestrial access nodes may be present but unavailable.

[0055] In most standards based communication systems, such as in 3GPP based systems, the physical presence of a non-terrestrial access node is considered sufficient to enable communications, and the issue of unavailability of non-terrestrial access is not considered. However as noted above physical presence of an access node is therefore a necessary, but not a sufficient, condition for network access. If a device expects an access node to be available and it is not, then the device can waste significant energy attempting to communicate with the network. This is a particular problem for energy constrained loT systems where conservation of power (or battery life) is of prime importance, and limits use of standard compliant user nodes 16, such as 3GPP compliant user nodes 16 in terminals.

[0056] Figure 2 is a schematic diagram of satellite pass 210 of a satellite 20 comprising an access node 22 over a device 10 comprising a terminal 12 according to an embodiment. In this embodiment the satellite access node 22 is available for communication service to the terminal 12 during two windows of time 202 and 204. In first window 201, the device attempts to receive transmissions from the satellite, but this is a waste of energy as the access node 22 in the satellite 20 is unavailable. In windows 202 and 204 the access node 22 in the satellite 20 is available and thus communication is possible. However, in windows 203 and 205, the satellite access node is again unavailable, any packets transmitted by the device 10 on the uplink will not be received and will be lost (and thus the device again wastes energy). That is any attempt to communicate with or transmit packets to the satellite outside of windows 202 and 204 will be a waste of energy (or power) as the access node is unavailable. This break in communication and wasted energy occurs despite the satellite being physically within communications range of the device (i.e. visible to the device) during windows 201, 203 and 205.

[0057] Accordingly, embodiments enable the terminal 12 to be aware of the availability of at least the non-terrestrial access nodes 22, and potentially all access nodes including terrestrial access nodes 22" (i.e. the plurality of radio access networks) via a shared understanding of access node operation rather than an assumption that physical presence equates to availability (as is the typical assumption in 3GPP based communication standards). This is achieved in an energy efficient manner to meet loT connectivity requirements. As shown in Figure 1, an enhancement layer 18 is added to the terminal 12 and interfaces with the remote user application 14 and the user node 16. The enhancement layer is configured to store and process scheduling information of the availability of the non-terrestrial access nodes for communication, and this network information (on availability of access nodes for communication) is used to control the sleep state of the user node 16. The sleep state is a state in which the user node does not attempt to transmit or receive, e.g. a low energy state that preserves the battery. Further whilst the user node 16 is in the sleep state, the enhancement layer can queue (i.e. hold) any messages received from the remote user application 14 for later transmission by the user node 12 when an access node 22 is available. The messages may include data messages containing data from the sensor 11 or location data. The enhancement layer 18 or user node 16 may also generate system messages, such as system diagnostics (also referred to as diagnostic messages). In some embodiments the enhancement layer acts to queue these messages until an access node becomes available. In some embodiments the enhancement layer may place the device 10 in a “sleep” or other low energy mode which may comprise shutting down or reducing the sampling rate (frequency) of any sensors 11 or monitoring functions to preserve energy (battery 19) of the user device. The enhancement layer 18 ensures the user node 16 or device 10 is only active when required (e.g. to collect and process sensor data, activate actuators, or communicate with the network) and it can enter a low energy “sleep” mode to preserve energy at other times. Other mechanisms could be used to control whether the user node is allowed to communicate. For example, an allowance state (communication allowed, or communication not allowed) could be stored in a memory and whose values is controlled by the enhancement layer based on the networking information. When the user node 16 has data to transmit, the user node 16 could check the allowance status and only attempt to transmit the data if communication is currently allowed. In other embodiments an error code could be provided to the user node indicating the communication components of the terminal are unavailable or offline so that the user node does not attempt to transmit data when access nodes are unavailable for communication. The error code could be provided by the enhancement layer or the enhancement layer could interface with or control the communication components to create an error code that would prevents transmission by the user node.

[0058] The enhancement layer 18 thus augments (or enhances) the communication system 1 and enables the devices 10 and system 1 to operate through periods when the radio access network is not available to devices 10, i.e. periods of discontinuous coverage. In some embodiments the enhancement layer 18 can be added to a standards-compliant user node or integrated into the user node as an additional commandset while maintaining user node stack standards -compliance. That is the enhancement layer 18 does not affect the underlying operation of the user node 16. Additionally, and as shown in Figure 1, network enhancement modules 60 may also be added to other system components including the non-terrestrial access station 20, non-terrestrial access nodes 22, terrestrial access stations 20", terrestrial access nodes 22", the ground station 30, distributed access nodes 22', gateway nodes 34, the core network 40, the service platform 50. Network enhancements modules 60 may also be incorporated via one or more central user applications, e.g. via applications managed by the network operator, or application components provided by the network operator for integration into a central user application managed by the user. Like the enhancement layer 18 the network enhancements 60 do not affect the underlying operation of the user node 16, and can be added to a standards compliant communication system to enhance the communication system to enable energy-efficient reliable communications at scale.

[0059] A network schedule 62 for access node 22 availability may be generated. In some embodiments network schedule 62 is controlled by the network operator and may be stored in the service platform 50 or core network 40. The schedule 62 may also be influenced by a third party, e.g. a supplier, other user of a shared channel resource, or a regulator. Availability of an access node may be periodic, e.g. the access node being available for five minutes of every hour; or it may be sporadic, e.g. the first three minutes of each satellite pass. Availability of an access node may also be driven by end user requirements, e.g. heavier use at different times throughout the day, different seasonal network loads, and so on. Further the schedule 62 may change over time. Embodiments of the communication system are configured to distribute scheduling information of the availability of access nodes 22 to the devices, and to allow regular updates of this information. In some embodiments this may be scheduling information of one or more, or all of the non-terrestrial access nodes 22. Scheduling information of some or all of the terrestrial access nodes 22" may also be provided or distributed. The scheduling information may be in relation to the availability of a part of the radio access network, such as a particular geographic region, or it may be provided for the entire radio access network. The devices may be configured to store the information, update stored information, and / or to directly act based on received information. The scheduling information of the availability of the one or more non-terrestrial access node will be referred to as network information. Different network information may be provided to different components. As will be discussed further below, a schedule tasker 64 uses the schedule 62 to generate network information 62' for use by the enhancement layer 18 in a terminal 12, and by the network enhancement modules 60. The schedule tasker 64 may be located in the service platform 50 (e.g., as shown in Figure 1), the core network 40, another computing apparatus, or distributed across the system.

[0060] In some embodiments radio access is defined for geographical regions, called service zones. When a device 10 is located within a service zone it will receive a level of network service defined for that service zone and distributed to devices via network information 62'. A device may determineapplicable service zones at its location, e.g. obtaining a location from a GNSS such as GPS, pre-loaded coordinates, or via another means such as discussed in PCT / AU2017 / 000108 or PCT / AU2023 / 050178. Service zones are defined as a bounded region in 3D space, or by a region on the surface of the Earth. Service zone boundaries may be represented by a series of polygons, circles, ellipses, lattices, any other shape, or a combination of these. In some embodiments service zones may be mapped onto physical properties of the radio network, such as cells, satellite antenna footprints or spot beam maps. In other embodiments service zones may be used to partition physical attributes of the network (such as antenna footprints) into regions that can be assigned individual attributes such as schedules. This has the advantage of providing a high resolution control of service level, thus allowing load to be distributed across a coverage area, e.g.:• increasing the number of access windows and / or increasing access window duration in a service zone in order to increase capacity and / or reliability;• increasing the number of access windows in a service zone in order to increase network revisit to the zone and decrease latency;• directing network service levels according to customer requirements, and adapting service as demand scales.

[0061] In some embodiments the device enhancement layer 18 receives, interprets and actions commands. These commands can be issued by the network at service zone resolution, effectively multicasting to all devices or a subset of devices in the service zone. In one embodiment commands are issued to a subset of devices in the service zone that meet some additional criteria. For example, the network may issue a command to devices in a specific service zone that causes them to reconfigure user node parameters. In one embodiment this is used to adjust quality of service parameters for the node. In another embodiment the network instructs the user node on maximum transmit packet and / or message length. Messaging may be based on packet-based messaging techniques in which messages are broken into multiple packets and transported via a packet-based network.

[0062] The schedule 62 may be a regular schedule 300 that repeats over some period of time, e.g. every hour, every day, or every week. Alternatively, the schedule may not repeat and instead be an irregular schedule 310 defined for an upcoming period of time, e.g. a day, week or month. An updated (or replacement) schedule can be distributed to devices 10 prior to the end of this period of time, or sooner, such as before the next time period that the access node will be available. In some embodiments a schedule has a period of applicability marked by start date and time, and an (optional) end date and time. The schedule end date and time may be omitted, indicating that the schedule is to persist until it is updated or cancelled (replaced with an empty schedule). A schedule may be updated by appending new access windows, adjusting existing access windows, removing existing access windows, or replacing theschedule in its entirety with a new schedule. This mechanism can also be used to inform of an ongoing or future outage.

[0063] In some embodiments the schedule 62 represents access node availability as windows of time, each having a start time and a duration. Access windows may be scheduled flexibly. For example, they may appear regularly or irregularly across the schedule, as shown in Figures 3 A and 3B. Figure 3 A is a schematic diagram of a regular schedule 300 of access node 22 availability according to an embodiment. Each access window 203 has a window start time 304 and a window end time 306. The access nodes are available for communication 308 during the access window, and unavailable for communication 309 outside of the time windows 302. In this embodiment access windows 302, 302a, and 302b are each identical duration and equally spaced apart such that time periods of unavailability 309, 309a and 309b are each of identical durations. Figure 3B is a schematic diagram of an irregular schedule of access node availability according to an embodiment. This this embodiment the access windows 302, 302c, 302d, 302e, and 302f are of varying durations, and thus the time periods of unavailability 309, 309c, 309d, 309e, and 309f are also of varying durations (although some access windows may be of the same duration).

[0064] Figure 3C is schematic diagram of the structure of a schedule of access node availability according to an embodiment. In this embodiment the schedule 62 is described by a list of access window gaps (gO, gl, g2 ...) starting from a fixed reference time 301 such as midnight UTC. Associated with each access window gap is a duration describing the length of the access window. Each service zone can be uniquely identified by its service zone identifier. Service zone b becomes active at start times given byT'b.iEquation 1where gb,k is the kthgap in seconds and nb is the number of access windows 302 per day for service zone b. The activation times for service zone b are then described byEquation 2where db.i is the duration of the access window 302 for service zone b and access window i.

[0065] Defining a schedule using access window gaps rather than a purely periodic schedule enables a flexible schedule while being more space efficient. The list of access window gaps can be compressed by collating identical repeated gaps / durations with an associated count.

[0066] In some embodiments, the following information is used to describe the schedule of an individual service zone:• Service zone identifier;• Schedule start date and time for identifying current vs future schedules;• Optional schedule end date and time; and• List of access window sets.

[0067] The list of access window sets may comprise:• access window gap count, i.e. number of gaps repeated in a row;• access window gap, i.e. time gap between access windows;• access window duration; and• access window quality of service (QoS) information.

[0068] In another embodiment this is a list of access window descriptions, where each access window is treated as a regular periodic window, with the following characteristics:• a time offset from a reference time such as 0:00Z;• a period of regular access window repetition;• an access window duration; and• access window quality of service (QoS) information.

[0069] In another embodiment this is a list of explicit access window start times and durations. In another embodiment this is some combination of the above.

[0070] In another embodiment a list of service zones may be provided with the schedule information, such that the schedule information applies to all service zones in the list.

[0071] In some embodiments, the access window operating frequency, list of frequencies, or frequency band is also delivered via network information. The specified frequencies may apply to a single service zone, set of service zones, or all service zones. In one embodiment, the frequencies may be delivered pertaining to a single access node, set of access nodes, or the full radio access network. For example, network information may specify that an access node will persistently use certain frequencies. In another embodiment the frequencies may be specified to apply according to a schedule, in a similar way to the access window specification embodiments described above. In another embodiment the frequencies may be included in the access window specification embodiments described above. Specifying frequencies separately from the access window schedule allows frequency parameters and access window schedule parameters to be updated independently. This may reduce the amount of network information data to be carried on the network, in the case of different update cadence requirements. The scheduling informationcould also be provided for access nodes in multiple networks, for example, each identified by an independent Public Land Mobile Network (PLMN) number or similar network identifier. That is the system could be extended to use with multiple communication networks, or where terminals implement protocols to communicate with multiple communication networks. Additional network parameters may also be delivered via the same mechanism, such as:• valid transmit power ranges;• supported modulation and coding schemes;• quality of service parameters (e.g. maximum throughput, such as a cap on messages and / or packets per window per device that may be used for network load balancing); • minimum and maximum packet lengths;• revisit class identifiers (as described below);• Cold start entry / exit criteria;• Connection retry parameters;• Diagnostic transmission rates; and / or• GNSS fix frequency;

[0072] In some embodiment each service zone is assigned one or more schedules 62. Radio access network availability within a service zone is the union of all schedules pertaining to the service zone. A service zone may be served by multiple frequencies from the same access node, or via multiple access nodes. In each case separate access windows can be defined for each frequency and access node. Where applicable access windows are scheduled with regard to underlying physical constraints of an access node. For example, for a satellite access node in LEO, access windows for a service zone are defined to fall within times that the satellite is passing over the service zone.

[0073] A device may build a calendar of access to the RAN based on the union of AN access window schedules at its current location.

[0074] In another embodiment network access schedules are consolidated by one or more network enhancements prior to being distributed via network information. For example, if a service zone is serviced by multiple access nodes operating at the same frequencies, then a consolidated schedule of radio access network availability, formed by the union of availability for these multiple access nodes, may be distributed via network information.

[0075] A service zone may be served by multiple frequencies from the same access node, or via multiple access nodes. In each case separate access windows can be defined for each frequency and access node. A device may purposely communicate with different access nodes in order to provide diversity.

[0076] Where applicable access windows are scheduled with regard to underlying physical constraints of an access node. For example, for a satellite access node in LEO, access windows for a service zone are defined to fall within times that the satellite is passing over the service zone.

[0077] Service zones are used to specify levels of service, such as access window duration and revisit, channel bandwidth, and so on, pertaining to geographical regions as described above. Figure 3D illustrates several examples of services zones. A first service zone 351 shows a polygon service zone, e.g. specifying the boundary of a country.

[0078] A second service zone 352 shows how service zones may be mapped onto geographically-defined “cells”, e.g. fixed cells defined on the surface of Earth that equate to spot beams. Such spot beams may be served via phased arrays from one or more geostationary (GEO) satellites or LEO satellites (adjusting beam generation to compensate for satellite motion).

[0079] A third service zone 353 shows how a cell (or beam) may be broken into smaller regions using service zones. This has an advantage of being able to offer different service levels from the same physical access node. In this case there are three regions, A, B, and C (remainder of the cell), and different service parameters can be applied in each.

[0080] A fourth service zone 354 shows how a service zone may be located in a region that is served by multiple overlapping cells, and the device may employ diversity as described above,

[0081] A fifth service zone 355 illustrates a specific type of service zone that is used to mark a service zone for the exclusion of uplink service from a region. The device enhancement layer interprets this type of service zone in a way that overrides any service zones that it overlaps. This may be used to implement regulatory constraints, e.g. non-transmit zones around radio astronomy sites.

[0082] In some embodiments an access node may define different schedules in each service zone, where each schedule is derived from a base pattern of access windows delivered by the access node. Figure 3E is a schematic diagram of a set of service zones based on a base pattern according to an embodiment and shows how an access node may operate with a base pattern of access windows. Three different service zones within the physical range of the access node are defined such that each service zone operates according to a subset of the access windows from the base service pattern. In this example the base pattern and schedules are regular however that is not a requirement. Devices in Service Zone 1 can access the network on 5 minute intervals. Devices in Service Zone 2 can access the network on 10 minute intervals, and devices in Service Zone 3 can access the network on 20 minute intervals. Hence the typical service revisit experienced by a device is 5, 10, or 15 minutes if it is located in Service Zone 1, 2, or 3 respectively.

[0083] In another embodiment delivery of a typical service revisit profde is achieved through devices statistically targeting revisit according to revisit classes. For example, a typical service revisit profde of 5, 10, or 15 minutes delivered to devices located in Service Zone 1, 2, or 3 respectively, may be achieved by giving each service zone a revisit class, and this is provided as part of the network information e.g.Service Zone 1 has revisit class 5 minutes, Service Zone 2 has revisit class 10 minutes, and Service Zone 3 has revisit class 20 minutes. In order to balance access node activity, devices in each service zone may apply the revisit class as follows:• The enhancement layer makes use of any access window available in the base pattern and schedules access to statistically target revisit according to its class. For example, a device in Service Zone 3 may target some statistical revisit performance, e.g. average, median, nth percentile, or maximum revisit of 20 minutes.• In one embodiment, the device randomly selects an offset into the base pattern and then schedules on regular intervals according to the revisit target. For example, a device in Service Zone 3 may select an offset in the range 0 to 3, and then schedule access at every 4th access window plus the offset value.• In another embodiment the device randomly schedules its next access according to its target average (or median) revisit.• In another embodiment the device randomly schedules access according to a distribution that delivers some statistical performance associated with its revisit class. For example, the distribution may be chosen such that 90% of time the device selects an access window that is no further into the future than the revisit target.

[0084] In some embodiment terminals will access the network at a randomly chosen time offset into the access window. This may avoid or mitigate overloading an access window if a large number of terminals attempt to access the network simultaneously, e.g. at the start of the access window. In some embodiments the terminals will access the network with an access window time offset determined by:• The network (e.g. via network information);• The terminal throughput (i.e. number of messages or packets per access window);• The service zone; or• A combination of above.

[0085] In some embodiment discontinuous coverage is supported by loading scheduling information (network information) onto devices so that they share a common understanding of radio access network availability with the network. Network information may be loaded onto devices at:• Manufacture time: e.g. during firmware load as part of the production process; and / or • Deployment preparation time: as devices are being prepared for dispatch; and / or• Device installation time: e.g. via a cabled or wireless (e.g. Bluetooth or NFC) connection to the device; or• Runtime, e.g. loading from any SIM, such as a USIM or eUICC card’s proprietary fdes.

[0086] In some embodiments the enhancement layer is implemented as an application on a SIM, such as a UICC, eUICC, or eSIM. The SIM application, or “SIM applet”, may be developed, deployed and maintained by the network operator. The SIM applet includes program code to execute the enhancement layer and associated storage, e.g. for storage of enhancement layer parameters and network information. In the case of an eUICC the network operator may deploy, manage and update the SIM applet over the air via remote SIM provisioning and management tools. The SIM applet can be maintained separately to the communications module or modem firmware. The SIM may be integrated with a compatible communications module, thereby providing the enhancement layer to the module without requiring modification to the communications module itself.

[0087] In other embodiments, enhancement layer functionality and storage may be distributed across one or more SIM applets and / or across other computational elements of the user node. This allows some functionality or storage to be offloaded onto the user node if advantageous. It also allows different architectural features of the user node and SIM to be exploited, e.g. implementing some functionality on the SIM to utilise its security-hardened environment.

[0088] In some embodiments discontinuous coverage is supported by distributing network information to devices across the network, and operating the network so that radio access network availability is consistent with the scheduling as defined within the distributed network information. This allows the network configuration to be updated over the air. Figure 4 is a schematic diagram of the scheduling system according to an embodiment and can be used to develop a method for distributing network information and operating the network according to the same schedule .

[0089] The schedule tasker 410 may be a part of the service platform 50 or the core network 40, or it may be a separate application for example running on another computing device.

[0090] In some embodiments a schedule tasker 410 is configured to receive a network schedule 402 for the one or more access nodes comprising scheduling information of the availability of the non -terrestrial access nodes 22. The schedule tasker 410 is configured to generate and distribute network information 411 for the terminals 12 (in devices 10), access nodes 22, and gateway nodes 34. In some embodiments network information may also be provided to the non-terrestrial access station 20, the terrestrial access station 20", the ground station 30, the core network 40, the service platform 50 and the central user applications 54. Different network information may be provided to different system entities, and the schedule tasker is configured to determine what network information to send to what entities. Thenetwork information for the access nodes 22 and gateway nodes 34 may comprise tasking information to control or configure operation of the respective access node 22 and gateway node 34, and / or of the respective non-terrestrial access station 20, terrestrial access station 20", and ground station 30 in which they are based. The network information for a terminal 418 comprises either a sleep command or scheduling information of the availability of the one or more non-terrestrial access nodes. Each terminal 12 in device 10 is configured to process received network information 418, for example by enhancement layer 420 which may include a scheduler. If the network information 411 is a sleep command the user node processes the sleep command so that at least the user node wakes up when one or more nonterrestrial access nodes are available. This may comprise putting the user node 16 into a sleep state for a sleep time window. If the network information 411 is scheduling information, then the terminal 12 stores the network information 418 and processes the network information such that the user node is allowed (i.e. permitted) to wake up to communicate when one or more access nodes are available for communication based on the scheduling information. This may comprise controlling a sleep state (or equivalently an activity state, operational state or power state) of the user node 16 to prevent the user node transmitting when no access nodes are available for communication, or to otherwise maintain the user node in the sleep state. In embodiments in which the network information 118 for a terminal is a sleep command, the enhancement layer in a terminal may be omitted simplifying the design of the terminal device. That is the network can directly control the power states of the user nodes 16 without the need for the terminal to store network information on the availability schedule. The enhancement layer 420 may also allow the user node to attempt to discover an access node for establishing a connection, regardless of the network information. This may occur if the terminal has been unavailable to communicate with any access nodes after repeated attempts, and the network information is out of date or is no longer considered valid or reliable. This functionality may be tightly controlled to prevent excessive use of power.

[0091] The network scheduler 402 defines the radio access availability schedule 404. This may be done with regard to:• time varying physical availability of network components such as mobile access nodes, e.g. onboard non-terrestrial network stations 20, ensuring that network components are only scheduled for use in a service zone when they are physically available to that zone;• end user requirements on latency, e.g. ensuring that revisit to a service zone occurs frequently enough to satisfy customer devices in that zone;• required capacity in each service zone, e.g. ensuring that the network is able to support the required number of devices, and the network load presented by those devices within the service zone;• capabilities of network system entities, e.g. satellite power and link budgets;• network load balancing objectives, e.g. ensuring that zones are not underutilised or overloaded;• radio frequency spectrum availability, e.g. allocating specific radio channels to different service zones;• the interference environment, e.g. scheduling availability to be orthogonal to interference in time and / or frequency; and / or• cost of network operations, e.g. scheduling activity during periods of reduced operating costs.

[0092] Additionally, the network scheduler 402 may define the radio access availability schedule 404 taking into account input from third parties regarding:• The availability of network components, e.g. ground station and satellite operators; • The availability of spectrum resources, e.g. regulatory authorisations; and / or • Availability of channel resources, e.g. other operators sharing the resource.

[0093] As outlined above, the network schedule 404 is delivered to a schedule tasker 410 which it uses to generate network information for distribution to the various system entities. As outlined above, different network information may be generated for different entities. The schedule tasker 410:• Prepares configuration information for network entities such as access nodes so that they can be operated according to the schedule. Configuration information may include radio frequency and waveform parameter settings.• Distributes configuration information and access window schedule information to network entities.• Tasks (i.e. operates) network infrastructure, such as ground stations, base stations, satellite stations, and HAPS, such that service zones are configured and activated according to the schedule.• Distributes network information for terminals (and devices) over the air via the network to enable control of the sleep (or power) state of the user node 16 according to the schedule.

[0094] The enhancement layer 18 in a device 10 utilizes network information, received over the air, to apply the updated schedule, for example to control the sleep state of the user node 16.

[0095] In some embodiments the network information 411 may be pre-loaded onto devices, e.g. at manufacture time, as described above. Network information for terminals 416 can be distributed to the manufacturer via some public interface or private / authenticated interface, e.g. via HTTP 414.

[0096] In some embodiment network enhancements are integrated into the service platform, and / or any other network entities as required to control the RAN.

[0097] In some embodiments the RAN cells are 3GPP standard network cells, with access nodes provided by a NodeB, evolved NodeB (eNodeB or eNB), or next generation NodeB (gNodeB or gNB) or some combination of these.

[0098] In some embodiments the access node also receives any required information on station dynamics, e.g. satellite ephemeris information for a satellite station. This may be delivered via the schedule tasker (as shown) or directly to the access node.

[0099] The access node configuration and / or scheduling information is passed to the access node via a push from the schedule tasker (event driven by change in schedule, configuration or on a per access window basis) or via a pull (e.g. polling) by the access node. In some embodiments the information is sent in its entirety for each access window. Configuration and / or scheduling information may be distributed as an atomic action, ensuring that the schedule tasker and access node remain synchronized. In another embodiment, the configuration and / or scheduling information for multiple access windows is sent every time there is a change. In another embodiment, the information is sent in increments.

[0100] In another embodiment the access node stores multiple versions of schedules and / or configurations, each having unique identifiers. The schedule tasker may instruct the access node to apply a stored configuration or schedule without the need to transfer the data unless there is an update to the configuration or schedule information.

[0101] The system architecture, capacity available for transport of the configuration and / or scheduling information, and the required latency to issue the information, may guide the approach taken. Compared to delivery of the entire configuration and schedule information set, delivery of incremental change information will require less data to be transferred, and a configuration version identifier will require less again. This may be advantageous if the gateway interface is not persistent, and / or it has limited capacity, as may be the case in a LEO satellite system with satellite -based access nodes.

[0102] In some embodiments the distribution of network information occurs via a 3GPP channel (radio access interface). In one embodiment the network information is broadcast to devices using:• Extension fields of 3GPP system information blocks (SIBs) or Master Information Block (MIB) encoded as an ASN.l; or• The warning message segment field of a public warning system (PWS) SIB for emergency notification; or• The 3GPP single-cell point-to-multipoint (SC-PTM) broadcast channel; or• a combination of the above.

[0103] The information is processed via a notification from the user node to the enhancement layer .

[0104] In another embodiment network information is distributed via 3GPP unicast messages. These messages could piggyback on uplink message exchanges as described below, e.g. user application uplink messages, or diagnostic messages. In this approach, messages are generated by an enhancement function, e.g. operating at an enhanced service platform or core network. Unicast network information updates may be issued autonomously by the network or in response to a request from a device. In one embodiment the core network and device are configured with a dedicated packet data network (PDN) that is used to deliver network information. The access point name (APN) of this PDN may be different to the APN used for user application data messages.

[0105] In another embodiment a secondary alternate standard or proprietary radio access interface is used to distribute network information to devices (via broadcast or unicast).

[0106] In one embodiment the schedule tasker 410 maintains a cache of information relating to one or more terminals. In a preferred embodiment this includes one or more of:• Terminal identifier, e.g. such as an international mobile subscriber identity (IMSI) in a 3GPP standardised baseline communications system• One or more terminal network information version identifiers (TNIVI) as described below• Date and time that the terminal was last active on the network• Service zone where the terminal was last active on the network• Date and time that network information was last scheduled for delivery to the terminal

[0107] In some embodiments, the schedule tasker creates network information message content:• Per terminal in the case of unicast network information delivery, which may be based on location e.g. the last active service zone• Relevant to the service zones served by the access node in the case of broadcast network information delivery

[0108] In some embodiments message content includes network information for one or more of the following:• The relevant service zone• Service zones neighbouring or nearby to the relevant service zone• Service zones relating to a broad set of service zones, e.g. in the case of informing about immutable access windows

[0109] Messages are passed to the core or directly to access nodes for network delivery to the terminals.

[0110] In some embodiment the schedule tasker generates messages when a new device joins the network, e.g. one or more messages are created based on the relevant service zone and passed to the core. In another embodiment the schedule tasker periodically generates network information messages. In one embodiment the schedule tasker determines if the terminal should be issued with updated network information, and these messages are scheduled for delivery based on the TNIVI (which may be reported by the terminal via diagnostics) and the date and time that network information was last scheduled for delivery to the terminal.

[0111] In some embodiments the service tasker determines the service zones and schedules to be included in per-terminal network information messages by considering:• Knowledge of terminal dynamics - e.g. if the terminal is known to be stationary (e.g. a fixed sensor) then the service tasker may deliver only the last active service zone without (or only a limited set) of neighbouring or nearby service zones.• Historic motion behaviour - e.g. if the terminal is observed to move within certain service zones, then the network information forthose service zones may be updated.• Device capabilities - e.g. supported frequency bands in the case that different access windows support different frequency bands• Service plans - e.g. providing some service zones, or services available within a service zone, only for some customers

[0112] It is possible that the network information onboard a device is invalid, e.g. if the network configuration has changed during a time when the device was offline and not receiving updates or during the time between device manufacture and deployment. In this case the device will not be able to attach to the network, and it will enter a cold start mode.

[0113] Figure 5 illustrates a cold start procedure 500 according to an embodiment. The device determines whether the onboard information is valid, e.g. by detecting missing information, time -based expiry of existing information, or failed connection attempts.

[0114] In some embodiments the network schedule includes attributes (or information) that allow a device to efficiently (re)discover the network in cold start mode. Such attributes include known physical layer parameters, e.g. operating frequencies or available access times, or patterns of behaviour, e.g. cycling through different frequencies or access time schedules according to some pattern known to devices. In some embodiments these network schedule attributes are “immutable”, meaning that they do not change, or they are only changed rarely and under tight control. In an embodiment the immutable access times may be changed and a new, or additional, immutable schedule may be communicated todevices via network information (loaded directly onto the device or received over the air). In another embodiment, an updated immutable schedule may be communicated to devices, then coexist with the initial immutable schedule, until devices have learned the updated immutable schedule, at which point the initial immutable schedule may be retired. In these latter embodiments “immutable” may alternatively be considered a set of “long term” or rarely changed time windows.

[0115] In some embodiments the network schedule includes an immutable set of access windows 342 that are known at device manufacture time and do not change during network updates. Figure 6 A is a schematic diagram of an initial schedule 340 with immutable access windows and Figure 6B is a schematic diagram of an updated schedule 350 with immutable access windows according to an embodiment. As can be seen in Figures 6A and 6B, the immutable set of access windows 342a 342b occur at the same time every day whereas the access windows 302302a and 302b are changed to 302g, 302h and 302i after the schedule update 350. The device then searches for the network only during these times, thus avoiding wasting energy when the network is unavailable. In some embodiments of a 3GPP standardised baseline communications system, the search is conducted by attempting to obtain network information via broadcast or unicast as described above. The operating frequency may be known, limited to a finite set of possibilities, or be any frequency within the operating bands. In some embodiments, the device searches using knowledge of the likely operating frequency (or finite set), e.g. loaded at manufacture time. The device may use any available knowledge of the likelihood of the network selecting a frequency within the set of assigned downlink frequencies to influence its selection of search frequency. In another embodiment the device begins with a small search space, potentially chosen based on probability of network downlink frequency selection, then broadens the frequency search set if it cannot connect to the network, potentially expanding the search out to the full operating bands. The immutable set of access windows may be delivered via the same radio access network as that used for network traffic, or via an alternative radio access network. Once the updated schedule information is obtained, the device will reconfigure to reconnect at the correct time windows.

[0116] In another embodiment for the purposes of delivering cold start information, a downlink operating frequency, or set of operating frequencies may be known but the access window times may vary. In this case the device will search across time to find the network at the operating frequency. In the case of a set of frequencies the search process may cycle through the set. The device may use any available knowledge of the likelihood of the network selecting a frequency within the set of assigned downlink frequencies to influence its selection of search frequency. For example, if the revisit pattern and access window duration is known for a service zone then a device can use this information to inform its search; e.g. if it is known that the a service zone will be revisited every 60 minutes for a 5 minute access window duration, then the device could search for a brief period (e.g. 30 seconds) every 5 minutes, and expect to discover the network within approximately 12 attempts (depending upon channel conditions andassociated packet loss). If after some number of attempts the device search is unsuccessful, then the device could widen its search parameters to frequencies outside its original set of known frequencies.

[0117] It is possible that multiple embodiments for delivering cold start information may be implemented. For example, a device may implement the embodiment of immutable access windows to receive network information as a first priority, then if this were to be unsuccessful, it may be reasonable for the device to change to a different embodiment such as searching a set of known frequencies over varying access windows.

[0118] In some embodiments terminal network information version identifiers (TNIVI) are used to represent the version of network information being used by terminals. Network enhancements in the service platform (and / or other network entities) may maintain a record of terminals and their associated TNIVI or query the terminals for their TNIVI. A terminal may uplink its TNIVI information explicitly, e.g. in response to a request from the network or via a diagnostics message, or implicitly, e.g. by indicating that it has received a version of network information that is currently being distributed. In an embodiment the network transmits network information version identifiers (NIVI) that identify the current version of network information available for a service zone, thus allowing a terminal to determine it has current network information. A hash, version number, or other identifier may be used to represent NIVI and TNIVI. These identifiers could represent a service zone or a combination of service zones. The hash may be calculated using NIVI or using the network information that is stored. In some embodiments the terminal generates a NIVI by calculating a storage hash for its network information. The network information may be distributed in pieces, e.g. separate pieces for different types of information or associated with different service zones. For the case of a large number of pieces, each with a potentially different version, the set of possible TNIVIs can grow very large and a hash becomes inefficient or infeasible to lookup the corresponding network information. In an embodiment, the hash TNIVI is constructed from a hierarchy of version information using a tree structure such that the hash of each tree node is concatenated to form the final TNIVI. This allows efficient recovery of the network information from the hash, similar to a tree-based message authentication and identification method, such as that discussed in PCT / AU2018 / 000150. NIVI and TNIVI allow a terminal to determine if it has the latest network information being delivered by the network, while also allowing the network to determine the state of network information at each terminal. Other version control methods may be used to determine the current version of the network information a terminal and to decide whether to send and / or update the network information in a terminal.

[0119] This allows rollout of new network information to be monitored, e.g. to ensure a significant portion of the device population has received it prior to switching over to the updated network schedule. In an embodiment, after switching the network to operate according to a new schedule, devices that did not receive the new network information will attempt to receive it from any overlapping access windowsbetween the initial and updated schedules. In some embodiments, devices that are unable to connect via the new schedule will revert to cold start to obtain the updated schedule information and rejoin the network as described above.

[0120] A change to a network schedule may be aborted, e.g. if it is determined that an insufficient proportion of devices have received the updated network information. In the preferred embodiment, a device will store the previous and updated network information and will attempt to switch to the new network information (updated schedule) at its scheduled start date and time, and if the network cannot be reached, the device will attempt to reconnect using the previous network information (initial schedule). If the device can still successfully connect with the network via the initial schedule, and consistently fails to connect via the updated schedule, then it will conclude that the network change was aborted. In another embodiment the network may issue an explicit message to announce that the network change was aborted.

[0121] In another embodiment, the network is configured and operated, and device behaviour is controlled to manage communication in the presence of discontinuous coverage by using network enhancements, without requiring an enhancement layer at the device. The network scheduler and schedule tasker interact with network entities as described above, however, scheduling information (via network information) is distributed to the terminals and used to control terminal behaviour via methods that exist within the communications system, in contrast to implementation using the terminal enhancement layer.

[0122] Figure 7 is a schematic diagram of the scheduling system in which the network information is used to directly control a sleep state of a user node 16 of a device 10 according to an embodiment. This is based on Figure 4 and like numbers in this embodiment refer to like components, In this embodiment:• The network notifies devices about a future (e.g. the next) upcoming access window.This could be via unicast or broadcast messaging. A standard 3GPP network may notify devices about a future access window using satellite assistance information for prediction of discontinuous coverage via system information block type 32 (SIB32).• The network configures device behaviour such that the device 10 will sleep and later wake up during an access window. As shown in Figure 7, network information for control of device behaviour 433 may be sent by the schedule tasker 410 to the core network 40 and access node 424, which may be implemented on an access station and / or ground station, or in the cloud, etc. The access node includes an access node scheduler. The access node sends network information for control of device behaviour 434 to a device 10. This may be in the form of commands or parameters that are processed (and understood / actioned) by the user node 16 to place the user node in a sleep state until a specified time, or for a time period or a time window. These commands and parametersmay collectively be referred as a sleep command. In a standard 3GPP network this may be achieved by setting the extended discontinuous reception (eDRX) cycle, or the end of power save mode (PSM), so that the device is reachable for device terminated data during a future access window. Access node configuration information 422 may also be sent to the access node along with the access window schedule 428.• If the device 10 has data to be transmitted, then it will wake the user node 16 to send device originated data during an access window.• If the device cannot find the network, then it will initiate a search. In a standard 3GPP network the device will enter a cell search. In some embodiments the device SIM (such as a USIM or eUICC) is configured with a list of frequencies to use during cell search. This list may be updated over the air.

[0123] In another embodiment the enhanced system uses a combination of techniques described in this embodiment, and those described in the above embodiments that utilise the device enhancement layer.

[0124] Figure 8 is a flow chart 800 of a method of distributing scheduling information according to an embodiment based on Figure 4 and as discussed above. At step 810 Schedule tasker 410 receives network schedule. At step 820 the Schedule tasker 410 determines network information for one or more terminals wherein the network information comprises scheduling information of the availability for communication of at least one or more of the one or more non-terrestrial access nodes in the communication system. At step 830 the network information is distributed to one or more terminals. At step 840 the terminal receives the network information (comprising either scheduling information of the availability for communication of at least one or more of the one or more non-terrestrial access nodes in the communication system for communication, or a sleep command), and controls a state of the user node based on the network information such that the user node is allowed to communicate when one or more access nodes are available for communication. The terminal apparatus may also update or replaced stored network information.

[0125] Additionally at step 860 the schedule tasker 410 determine tasking of one or more access nodes, gateway nodes or the core network using the network schedule, for example to control and / or configure the system entities, and at step 870 distribute network information to the one or more access nodes, gateway nodes or the core network to task the respective system entity according to the network schedule

[0126] The terminal enhancement layer 18 may be implemented using software, firmware, or hardware (e.g. application specific integrated circuit, or integrated into a system on a chip). In some embodiments the enhancement layer is implemented onboard the user node 16, e.g. onboard a system on a chip, communications module, or modem device, or a microcontroller integrated into any of these. In another embodiment the enhancement layer is implemented onboard a microcontroller that is external to the usernode 16. In some embodiments the enhancement layer and remote user application may share the same microcontroller (which may also be embedded into the user node 16).

[0127] In some embodiments the enhancement layer 18 augments a command interface into the user node, such as an AT command interface into a modem, adding features to provide access to the enhanced functionality. In another embodiment the user node interface is an application programming interface (API), and the enhancement layer augments the API with enhanced functionality. The command interface or API interface may also provide a passthrough mode that provides access to the baseline user node functions.

[0128] In some embodiments the terminal enhancement layer 18 includes a message handler that manages the uplink message queues and provides downlink message notifications to the remote user application.

[0129] In some embodiments the message handler queues uplink data for delivery to the network during a future access window. In an embodiment the message handler implements two transmit message queues, one each for:• Remote user application messages;• System messages, such as diagnostic messages; and• Various QoS policies can be applied to the queues.

[0130] In one embodiment the core network and terminal are configured with a dedicated packet data network (PDN) that is used to deliver system messages. The access point name (APN) of this PDN may be different to the APN used for user application data messages. In one embodiment the same APN is used for system messages and network information. In this case, when piggybacking is used for downlink data (as described below) network information downlink messages and user application downlink messages may be piggybacked on either system message uplink exchanges or user application uplink data exchanges. Piggyback refers to utilising a communication exchange between a terminal and an access node as a trigger for the transmission of network information. The communication exchange includes both the establishment of a connection (e.g. handshaking and the like), as well a transmission of a message, as each case indicates that the user node in the terminal is currently awake, and thus is available to receive network information,

[0131] In some embodiments the enhancement layer processes messages in one or more transmit queues by performing one or more of the following:combining data content for multiple messages to form a data stream;encode the data stream in a more compact form and / or encrypting the data stream; fragmenting the data stream into blocks to be sent as packets; andqueuing the blocks as packets for transmission.

[0132] In some embodiments the block size may be selected to improve transfer efficiency, e.g. data content for multiple small packets (e.g. 5, 10, 20 Bytes each) may be sent within a longer packet (e.g. 100, 200, 300 Bytes) to reduce the impact of protocol overhead; and / or account for channel conditions, e.g. send longer packets in favourable channel conditions.

[0133] Upon reception a network enhancement module 18 will reverse the process applied at the terminal, i.e. it will reconstruct the encoded data stream, then decode and / or decrypt it, and then extract the individual data content for the multiple messages.

[0134] In one embodiment, parameters relating to this method, such as the number of queues, queue lengths, and block size may be controlled over the air via network information.

[0135] In some embodiments this approach is applied to data that is queued prior to, or during, an access window. The enhancement layer may use knowledge of the end of an access window to send a shorter block-based message or based on the QoS setting of the data, in order to send the queued data as soon as possible, rather than waiting until the next access window.

[0136] When more than one queue exists, each queue may be processed separately, or the queued data may be combined and jointly processed.

[0137] In another embodiment the enhancement layer 18 informs the remote user application (e.g. via a command interface or API) if the network is available, and the user application decides if it will transmit a message. In this case the enhancement layer may not queue messages but instead leave the user application to decide if it will buffer a message for later transmission or discard the message. In another embodiment the enhancement layer informs the remote user application of future access windows, thus allowing the user application to wake, collect and process sensor data during (or prior to) the access window.

[0138] In some embodiments the distribution of network information to a terminal is performed in response to receiving a transmission from a terminal (this is known as piggybacking). In many loT applications, the terminals will attempt to extend battery life for as long as possible, and thus will keep the user node, and typically the entire device in a low power or sleep state for the majority of time, and will only wake up for brief periods to perform device functions, e.g., collect data from a sensor or estimate a location) and to transmit data or diagnostic messages. Transmission of data messages by the user node 16 may happen during the same wakeful period during which the data is collected, or messages or data may be sent at a later time, for example when an access node is available. Messages may bequeued by the remote application whilst waiting for an available access node. Similarly, any diagnostic messages generated by any component of the device or terminal (including the user node) may be queued until an access node is available for transmission. Thus, in many cases the network scheduler 64 or core network 40 will not necessarily know when a terminal is awake, or even where the terminal currently is if it is mounted to a mobile asset, and thus it is only when the terminal starts transmitting to an available access node 22 does the scheduler tasker 410 (or the core network 40) become aware the terminal is awake (i.e. it exists). These transmissions thus act as a trigger for the schedule tasker to send network information to the terminal. The trigger may be the receipt of transmissions for establishing a connection which identifies the user node / terminal (i.e. before a connection is established or as part of establishing a connection), the successful establishment of a connection including a terminal identifier, or receipt of a message containing a terminal identifier.

[0139] In some embodiments, in the case of user data, the message handler provides downlink message notifications to the remote user application. The uplink message exchange signals to the network that the terminal is active and informs the network which access node is in range of the terminal, so that downlink messages can piggyback on an uplink message exchange.

[0140] In some embodiments the communications system is a 3GPP standardised communications system and radio resource control is used to establish a connection. Once the connection is established, the network may send downlink data during the same connection that the terminal transmits uplink data. Re-using the already established RRC connection in this way provides improved energy efficiency.

[0141] In one embodiment the terminal regularly sends one or more 3 GPP standard or proprietary system messages on the uplink to update terminal status and also provides an opportunity for the network to piggyback data on the downlink. In other embodiments terminals may be configured to send regular diagnostic messages, and the receipt of a diagnostic message may be used as a trigger for sending the feedback information. Note that regular does not necessarily mean periodic, but simply at any convenient time , i.e., when an access node is available, during some extended time window such as single or multiple hours or days (e.g. once a day).

[0142] In another embodiment if the terminal does not expect any further network communication (e.g. when the queue is empty) it may transition into sleep mode to conserve energy. In this case the terminal may inform the network. In some embodiments where the baseline communications system is a 3GPP standardised communications system, the terminal informs the network via a release assistance indication (RAI). Upon RRC connection release, the terminal enters sleep mode whilst staying attached to the network to conserve energy for subsequent transmission attempts.

[0143] The typical assumption in many communication systems, including those based on the 3GPP based communication standards, is that physical presence of an access node equates to availability.Embodiments of a communication system and method of operation have been described that are configured to be resilient to an access node being present but unavailable for communications. Terminals can be configured to avoid attempting to transmit when an access node is present but unavailable, thus providing more efficient operation and helping to conserve power and extend battery life, which is often of prime importance to remote loT terminals. Embodiments of the communication system at least includes non-terrestrial access nodes, and may also include terrestrial access nodes. Embodiments use a schedule tasker that is configured to receive a network schedule for the access nodes that comprises scheduling information of the availability of the access node for communications. This can then be distributed to terminals, access nodes, gateway nodes, and other system components as network information. The network information for the access nodes and gateway nodes comprises tasking information to control and / or configure operation of the respective access node or gateway node according to the schedule. The network information for the terminals may include scheduling information of the availability for communication of at least one or more of the one or more non terrestrial access nodes, or a sleep command which can be used by a terminal to control the state of the user node such that is allowed (or permitted) to communicate when one or more access nodes are available for communication. In the case of scheduling information, the terminal can use the schedule to control the user node so that it is allowed (permitted) to communicate when one or more access nodes are available for communication and is prevented from communicating when no access nodes are present. This may be performed by sending a sleep command to the user node so that the user node remains asleep when no access nodes are available and woken when an access node is available. The network information could also be sent to the terminal as a sleep command for the user node to control a waking or sleeping state such that the user node is allowed to communicate when one or more access nodes are available for communication.

[0144] The user node can be put to sleep, or otherwise prevented from attempting to communicate when there are no access nodes available for communication, even though they may be physically overhead or in communication range, thus assisting in conserving precious power and extending battery life of the terminals. Other mechanisms could be used to control whether the user node is allowed to communicate, for example an allowance state could be stored in a memory which the user node could check (i.e. lookup), or an error code could be provided to the user node indicating the communication components of the terminal are unavailable or offline. During allowed (or permitted) time periods the user node can separately determine whether to actually communicate (i.e. send a transmission). In some embodiments the user node may also be allowed to attempt to discover an access node for establishing a connection regardless of the network information (e.g. initiate a cold start search). Associated terminal apparatus(referred to simply as terminals) have also been described, along with a schedule tasker and method of operation.

[0145] The reference to any prior art in this specification is not, and should not be taken as, an acknowledgement or any form of suggestion that such prior art forms part of the common general knowledge.

[0146] Those of skill in the art would understand that information and signals may be represented using any of a variety of technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0147] Those of skill in the art would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software or instructions, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

[0148] The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. For a hardware implementation, processing may be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, or other electronic units designed to perform the functions described herein, or a combination thereof.

[0149] In one embodiment a computing apparatus comprises at least one processor and at least one memory operatively connected to the at least one processor (or one of the processors) and may comprises additional devices or apparatus, and input and output devices / apparatus (the term apparatus and device will be used interchangeably). The memory may comprise instructions to cause the processor to execute a method described herein. The computing apparatus may be a unitary computing or programmable apparatus, or a distributed apparatus comprising several components operatively (or functionally) connected via wired or wireless connections. The computing apparatus may also comprise one or moregraphical processing unit (GPUs), Tensor processing units (TPUs), input devices and output devices. A CPU may comprise an Input / Output Interface, an Arithmetic and Uogic Unit (AUU) and a Control Unit and Program Counter element which is in communication with input and output devices through the Input / Output Interface. The Input / Output Interface may comprise a network interface and / or communications module for communicating with an equivalent communications module in another device using a predefined communications protocol (e.g. Bluetooth, Zigbee, IEEE 802.15, IEEE 802.11, TCP / IP, UDP, etc.). The computing or terminal apparatus may comprise a single CPU (core) or multiple CPU’s (multiple core), or multiple processors, as well as GPUs and TPUs. The computing or terminal apparatus may use a parallel processor, a vector processor, or be a distributed computing device, including cloud based computing devices and resources. Memory is operatively coupled to the processor(s) and may comprise RAM and ROM components, and may be provided within or external to the device or processor module. The memory may be used to store an operating system and additional software modules or instructions. Apparatus and devices, including sensing and display apparatus, may comprise unitary apparatus or devices or may be distributed apparatus or devices in which components are separated (for example based on function) and communicate over wired or wireless links.

[0150] Software modules, also known as computer programs, computer codes, or instructions, may contain a number a number of source code or object code segments or instructions, and may reside in any computer readable medium such as a RAM memory, flash memory, ROM memory, EPROM memory, registers, hard disk, a removable disk, a CD-ROM, a DVD-ROM, a Blu-ray disc, or any other form of computer readable medium. In some aspects the computer-readable media may comprise non-transitory computer-readable media (e.g., tangible media). In addition, for other aspects computer-readable media may comprise transitory computer- readable media (e.g., a signal). Combinations of the above should also be included within the scope of computer-readable media. In another aspect, the computer readable medium may be integral to the processor. The processor and the computer readable medium may reside in an ASIC or related device. The software codes may be stored in a memory unit and the processor may be configured to execute them. The memory unit may be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means as is known in the art. A computer program may be written, for example, in a general-purpose programming language (e.g., Python, Java, C++, C, C# etc.) or some specialized application-specific language, and may utilise or call software libraries or packages for example to implement data interfaces (e.g. JSON) or utilise machine learning (e.g. TensorFlow, CUD A) or numerical optimisation.

[0151] Further, it should be appreciated that modules and / or other appropriate means for performing the methods and techniques described herein can be downloaded and / or otherwise obtained by the computing device. For example, such a device can be coupled to a server to facilitate the transfer of means for performing the methods described herein. Alternatively, various methods described herein can beprovided via storage means (e.g., flash disk, RAM, ROM, a physical storage medium such as a compact disc (CD) or floppy disk, etc.), such that a computing device can obtain the various methods upon coupling or providing the storage means to the device. Moreover, any other suitable technique for providing the methods and techniques described herein to a device can be utilized.

[0152] The methods disclosed herein comprise one or more steps or actions for achieving the described method. The method steps and / or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and / or use of specific steps and / or actions may be modified without departing from the scope of the claims.

[0153] As used herein, the terms “estimating” or “determining” encompass a wide variety of actions. For example, “estimating” or “determining” may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, “estimating” or “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, “determining” may include resolving, selecting, choosing, establishing and the like.

[0154] It will be understood that the terms “comprise” and “include” and any of their derivatives (e.g. comprises, comprising, includes, including) as used in this specification, and the claims that follow, is to be taken to be inclusive of features to which the term refers, and is not meant to exclude the presence of any additional features unless otherwise stated or implied.

[0155] In some cases, a single embodiment may, for succinctness and / or to assist in understanding the scope of the disclosure, combine multiple features. It is to be understood that in such a case, these multiple features may be provided separately (in separate embodiments), or in any other suitable combination. Alternatively, where separate features are described in separate embodiments, these separate features may be combined into a single embodiment unless otherwise stated or implied. This also applies to the claims which can be recombined in any combination. That is a claim may be amended to include a feature defined in any other claim. Further a phrase referring to “one or more of’ a list of items refers to any combination of those items, including single members. As an example, “one or more of: a, b, or c” is intended to cover: a, b, c, a-b, a-c, b-c, and a-b-c.

[0156] It will be appreciated by those skilled in the art that the disclosure is not restricted in its use to the particular application or applications described. Neither is the present disclosure restricted in its preferred embodiment with regard to the particular elements and / or features described or depicted herein. It will be appreciated that the disclosure is not limited to the embodiment or embodiments disclosed, butis capable of numerous rearrangements, modifications and substitutions without departing from the scope as set forth and defined by the following claims.

Claims

CLAIMS1. A terminal apparatus for use in a communication system comprising one or more access nodes, the one or more access node comprising one or more non-terrestrial access nodes, one or more gateway nodes, and a schedule tasker, the terminal apparatus comprising:a terminal application that generates messages;one or more antennas;a user node configured to communicate with the one or more access nodes of the communication system using the one or more antennas; andan enhancement layer configured to:receive and process network information, wherein the network information comprises either scheduling information of an availability for communication of at least one or more of the one or more non-terrestrial access nodes in the communication system, or a sleep command; and control a state of the user node based on the network information such that the user node is allowed to communicate when one or more access nodes are available for communication.

2. The terminal apparatus as claimed in claim 1, wherein controlling a state of the user node comprises preventing the user node transmitting when no access nodes are available for communication.

3. The terminal apparatus as claimed in claim 1 or 2, wherein when the network information is a sleep command and controlling a state of the user node comprises controlling a sleep state of the user node by waking up the user node when one or more access nodes are available for communication and putting the user node to sleep when no access nodes are available for communication.

4. The terminal apparatus as claimed in claim 1 or 2, wherein when the network information is scheduling information, and controlling a state of the user node comprises controlling a sleep state such that the user node is allowed to wake up when one or more access nodes are available for communication based on the scheduling information and putting the user node to sleep when no access nodes are available for communication.

5. The terminal apparatus as claimed in claim 4, wherein the scheduling information for the availability for communication of at least one or more of the one or more non-terrestrial access nodes comprises one or more time windows of availability for the respective access node, each time window having a start time and a duration.

6. The terminal apparatus as claimed in claim 4 or 5, wherein the scheduling information for the availability for communication of at least one or more of the one or more non-terrestrial access nodes comprises an ordered list of gaps starting from a reference time.

7. The terminal apparatus as claimed in any one of claims 4 to 6, wherein the communication system is divided into a plurality of service zones, where each service zone is a geographical region, and network information is generated for each service zone, and each service zone is assigned one or more schedules, and a terminal uses a union of the one or more schedules to determine when no access nodes are available.

8. The terminal apparatus as claimed in any one of claims 1 to 7, wherein the enhancement layer is further configured to queue one or more messages received from the terminal application for transmission by the user node at least until one or more access nodes are available for communication.

9. The terminal apparatus as claimed in any one of claims 1 to 8, wherein the network information further comprises an immutable set of access windows for the one or more access nodes which do not change, and the terminal apparatus stores the immutable set of access windows.

10. The terminal apparatus as claimed in any one of claims 1 to 9, wherein the enhancement layer is further configured to allow a user node to wake up to attempt to discover an access node for establishing a connection regardless of the network information.

11. The terminal apparatus as claimed in any one of claims 1 to 10, wherein the network information is stored, and existing network information is updated or replaced based on the received network information.

12. The terminal apparatus as claimed in any one of claims 1 to 11, wherein each terminal calculates or stores a terminal network information version identifier (TNIVI) that represents a version of the network information being used by the terminal apparatus, and the terminal apparatus uses the TNIVI to determine whether to update received network information.

13. The terminal apparatus as claimed in any one of claims 1 to 12, wherein the user nodes are 3GPP compliant user nodes.

14. The terminal apparatus as claimed in any one of claims 1 to 13 wherein the one or more access nodes further comprise one or more terrestrial access nodes and the availability for communication of at least one or more of the one or more non-terrestrial access nodes in the communication system further comprises an availability for communication of one or more of the one or more terrestrial access nodes.

15. The terminal apparatus as claimed in any one of claims 3 to 14, wherein the scheduling information of the availability for communication of at least one or more of the one or more non terrestrial access nodes further comprises one or more operating frequencies of the respective access nodes.

16. A communication system comprising:one or more access nodes, the one or more access node comprising one or more non-terrestrial access nodes;one or more gateway nodes;a service platform;a plurality of terminal apparatus as claimed in any one of claims 1 to 15; anda schedule tasker,wherein,each user node in a terminal apparatus is configured to connect with the one or more access nodes, and the one or more gateways connect the one or more non-terrestrial access nodes to the service platform, such that data may be exchanged unidirectionally in either direction between the terminal application and the service platform, or bi-directionally between the terminal application and the service platform, andthe schedule tasker is configured to receive a network schedule for the one or more access nodes comprising scheduling information of the availability of the at least one or more of the one or more nonterrestrial access nodes, and the schedule tasker is configured to generate and distribute network information for the plurality of terminal apparatus, the one or more access nodes, and the one or more gateway nodes, and the network information for the one or more access nodes and one or more gateway nodes comprises tasking information to control and / or configure operation of the respective access node or gateway node according to the schedule and the network information for a terminal apparatus comprises either a sleep command or scheduling information of the availability for communication of at least one or more of the one or more non-terrestrial access nodes, and each terminal is configured to process received network information to control a state of the user node based on the network information such that a user node of the respective terminal is allowed to communicate when one or more access nodes are available for communication.

17. The communication system as claimed in claim 16, wherein the network information is unicast to a terminal apparatus by an access node.

18. The communication system as claimed in claim 17, wherein at least the network information is sent to a respective terminal apparatus in response to receiving a transmission or message from the terminal apparatus.

19. The communication system as claimed in any one of claims 16 to 18, wherein one or more nonterminal system entities of the communication system comprise a network enhancement module which stores the network information, and on receipt of network information from the schedule tasker, updates the stored network information, and performs configuration and tasking of the respective non-terminal entity based on the network information, wherein the non-terminal system entities comprise the one or more access nodes, the one or more gateway nodes, a core network, the service platform, and a central user application.

20. The communication system as claimed in any one of claims 16 to 19, wherein the schedule tasker is implemented in the service platform.

21. The communication system as claimed in any one of claims 16 to 20, wherein the communication system is divided into a plurality of service zones, where each service zone is a geographical region, and network information is generated for each service zone, and the scheduling information sent to a terminal apparatus comprises scheduling information for the service zone.

22. The communication system as claimed in claim 21, wherein each service zone is assigned one or more schedules, and a terminal apparatus uses a union of the one or more schedules to determine when no access nodes are available.

23. The communication system as claimed in any one of claims 16 to 22, wherein the network schedule comprises an immutable set of access windows which do not change, and the immutable set of access windows are uploaded to terminal apparatus prior to deployment.

24. The communication system as claimed in any one of claims 16 to 23, wherein each terminal apparatus calculates or stores a terminal network information version identifier (TNIVI) that represents a version of the network information being used by the terminal apparatus, and the network tasker or terminal apparatus uses the TNIVI to determine whether to update network information.

25. The communication system as claimed in any one of claims 16 to 24, wherein the scheduling information is stored on the terminal prior to deployment.

26. The communication system as claimed in any one of claims 16 to 25, further comprising a network scheduler configured to generate a network schedule which is sent to the schedule tasker.

27. The communication system as claimed in any one of claims 16 to 26, wherein the one or more access nodes further comprise one or more terrestrial access nodes which are configured to either connect directly to a core network or connect to a core network via one or more gateways, and the networkinformation further comprises scheduling information of the availability of at least one or more of the one or more terrestrial access nodes.

28. The communication system as claimed in any one of claims 16 to 27, wherein the service platform is configured to execute a plurality of central user applications for a plurality of users, and each terminal application in a terminal is a remote user application associated with one or more central user applications in the service platform and the communication system is configured such that data may be exchanged unidirectionally in either direction between the remote user application and the associated one or more central user applications, or bi-directionally between the remote user application and the associated one or more central user applications.

29. A schedule tasker apparatus for use in the communication system of any one of claims 16 to 28 comprising:at least one memory, andat least one processor, wherein the at least one memory comprises instructions to configure the at least one processor to:receive a network schedule for the one or more access nodes in the communication system comprising scheduling information of the availability for communication of at least one or more of the one or more non-terrestrial access nodes; andgenerate and distribute network information for the plurality of terminal apparatus, the one or more access nodes, and the one or more gateway nodes, and the network information for the one or more access nodes and one or more gateway nodes comprises tasking information to control operation of the respective access node or gateway node according to the schedule and the network information for a terminal apparatus comprises either a sleep command or scheduling information of the availability for communication of at least one or more of the one or more non-terrestrial access nodes, and each terminal apparatus is configured to process received network information to control a state of the user node based on the network information such that the user node is allowed to communicate when one or more access nodes are available for communication.

30. A method of maintaining scheduling transmission in the communication system of any one of claims 16 to 28, comprising:receiving by a schedule tasker, a network schedule;determining network information for one or more terminal apparatus wherein the network information comprises scheduling information of the availability for communication of at least one or more of the one or more non-terrestrial access nodes in the communication system;distributing the network information to the one or more terminal apparatus using the communication network; andreceiving, by a terminal apparatus, network information wherein the network information comprises either scheduling information of the availability for communication of at least one or more of the one or more non-terrestrial access nodes in the communication system, or a sleep command, and controlling a state of the user node based on the network information such that the user node is allowed to communicate when one or more access nodes are available for communication.

31. The method as claimed in claim 30, wherein the network schedule for the one or more access nodes comprising scheduling information of the availability of at least the one or more non-terrestrial access nodes and the method further comprises, generating and distributing network information for the one or more access nodes and the one or more gateway nodes, and the network information for the one or more access nodes and the one or more gateway nodes comprises tasking information to control and / or configure operation of the respective access node or gateway node according to the schedule.

32. The method as claimed in claim 30 or 31, further comprising generating, by a terminal apparatus, a terminal network information version identifier (TNIVI) that represents a version of the network information being used by the respective terminal apparatus, and the network tasker or terminal apparatus uses the TNIVI to determine whether to update network information.

Images