WO2025023140A1

WO2025023140A1 - Method performed by access network node, method performed by user equipment, method performed by core network node, access network node, user equipment, and core network node

Info

Publication number: WO2025023140A1
Application number: PCT/JP2024/025773
Authority: WO
Inventors: Yuhua Chen; Neeraj Gupta; Hisashi Futaki
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2023-07-24
Filing date: 2024-07-18
Publication date: 2025-01-30
Anticipated expiration: 2026-01-24
Also published as: GB202311347D0

Abstract

A method performed by an access network node in a non-terrestrial network is disclosed. The method includes receiving, via an available link, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable, without triggering of establishing a connection for another link than the available link; storing the at least one NAS PDU until the another link becomes available; and forwarding, via the another link, the at least one NAS PDU when the another link becomes available.

Description

METHOD PERFORMED BY ACCESS NETWORK NODE, METHOD PERFORMED BY USER EQUIPMENT, METHOD PERFORMED BY CORE NETWORK NODE, ACCESS NETWORK NODE, USER EQUIPMENT, AND CORE NETWORK NODE

　　The present disclosure relates to a communication system and to parts thereof. The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including LTE-Advanced, Next Generation or 5G networks, future generations, and beyond). The disclosure has particular but not exclusive relevance to improvements relating to the use of store and forward techniques for the communication of user data in the context of Non-Terrestrial Networks (NTN).

　　Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the term '5G' and 'new radio' (NR) has started to be used to refer to an evolving communication technology that is expected to support a variety of applications and services. Various details of 5G networks are described in, for example, the 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https://www.ngmn.org/5g-white-paper.html. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.

　　Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipments or 'UEs') connect to a core network and communicate with other communication devices or remote servers. For simplicity, the present application will use the term access network node, RAN node or base station to refer to any such access nodes.

　　For simplicity, the present application will use the term mobile device, user device, or UE to refer to any communication device that is able to connect to the core network via one or more base stations. Although the present application may refer to mobile devices in the description, it will be appreciated that the technology described can be implemented on any communication devices (mobile and/or generally stationary) that can connect to a communication network for sending/receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory. One specific type of UE supported in modern communication systems are so called Internet of Things (IoT) devices that are non-standard hardware devices (including everyday physical objects such as sensor devices, gadgets, appliances and the like) that are able to connect wirelessly to a network to transmit and receive data. Technologies for supporting such IoT UEs in cellular communication systems are often referred to as cellular IoT (CIoT) enhancements or optimisations. CIoT enhancements include, for example, narrowband IoT (NB-IoT) enhancements, which is a radio technology developed, to support cellular network IoT devices and services, in which the bandwidth is limited to a single narrowband (e.g., where transmissions are restricted to occupying a single 180KHz physical resource block (PRB) / 12 subcarriers of 15KHz each). CIoT enhancements also include features supporting so-called "LTE - Machines" (LTE Cat-M1 or simply LTE-M) technologies involving bandwidth limited UEs (BL UEs), which is faster than NB-IoT but operates over a wider narrowband (e.g., limited to 6 PRBs / 1.4MHz).

　　In the current 5G architecture, the gNB structure may be split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by an F1 interface. This enables the use of a 'split' architecture in which the typically 'higher' CU layers (for example, but not necessarily or exclusively, Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) layers) and the, 'lower' DU layers (for example, but not necessarily or exclusively, Radio Link Control (RLC), Media (sometimes referred to as 'Medium') Access Control (MAC), and Physical (PHY) layers) are separated between a particular CU, and one or more DUs that are connected to and controlled by that CU via the F1 interface. Thus, for example, the higher layer CU functionality for a number of gNBs may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each gNB.

　　The core network includes a number of communication entities for providing different functions for supporting communication.

　　For example, in 4G the core network entities include, amongst other things, a mobility management entity (MME), a serving gateway (SGW or S-GW), a packet data network (PDN) gateway (PGW or P-GW), etc. The MME manages general mobility aspects of the UE and ensures that connectivity is maintained with the UE as it is moving within the geographical area covered by the communication system. The MME also handles control-plane signalling for the UE and manages the various bearers associated with the UE (e.g. such as an Evolved Packet System (EPS) bearer and/or a radio bearer), for example by controlling the S-GW and the P-GW (and/or possibly other network nodes) via which such bearers are provided. The S-GW provides a connection between the UE and the core network (via the base station) for sending and receiving user plane data over an associated communication bearer (e.g. an EPS bearer). The communication bearer normally terminates at the P-GW, although it is often complemented by an external bearer as well (for example, another EPS bearer and/or the like) between the P-GW and a communication end-point outside the core network (e.g. in an external network). It will be appreciated that the functionalities of the S-GW and the P-GW could be implemented in a single gateway element.

　　In 5G, the core network entities comprise logical nodes (or 'functions') including control plane functions (CPFs) and one or more user plane functions (UPFs). The CPFs include, amongst other things, one or more Access and Mobility Management Functions (AMFs). The AMF generally corresponds to the MME in 4G and performs many of the functions performed by the MME. Each UPF combines functionality of both the S-GW and P-GW - specifically user plane functionality of the S-GW (SGW-U) and user plane functionality of the P-GW (PGW-U). The SMF provides session management functionality (that formed part of MME functionality in 4G). The SMF also combines the some of the functionality provided by the S-GW and P-GW - specifically control plane functionality of the S-GW (SGW-C) and control plane functionality of the P-GW (PGW-C). The SMF also allocates IP addresses to each UE.

　　In 4G a number of EPS optimisations for supporting CIoT (e.g., NB-IoT) were introduced (which are generally applicable to later generations of technology), these enhancements allowed for communication new user data paths for IoT. In contrast to the original data paths via the S-GW and P-GW, these new data paths allow communication of user data via the MME (in 4G) (and other CN nodes such as S-GW, P-GW and or a Service Capability Exposure Function (SCEF)) although, in later generations, this may be via a different equivalent node (e.g., the AMF in 5G). CIoT EPS optimisation using these newer path is referred to as control plane (CP) mode or 'CP-Mode' CIoT EPS optimisation whereas CIoT EPS optimisation using the original data paths is referred to as user plane (UP) mode or 'UP-Mode' CIoT EPS optimisation.

　　CP-Mode CIoT EPS optimisation reduces the total number of control plane messages when handling a short data transaction (as typically occurs in IoT communication), user data or SMS messages that is conveyed using a service request procedure, via the MME, by encapsulating them in non-access stratum (NAS) messages. In the case of IP data packets, UL data may be transferred from the base station, via the MME, the S-GW, and the P-GW, to the CIoT services. In the case of non-IP data packets, UL data may be transferred from the base station, via the MME, and the SCEF, to the CIoT services.

　　The UP-mode CIoT EPS optimisation, on the other hand, conveys user plane data without using the service request procedure to establish access stratum (AS) context in the serving base station and the UE. This UP-mode method is based on UP transport of user data in which data is transferred over the conventional user plane through the network from the base station to the S-GW and vice-versa. For UP-mode CIoT, two distinct RRC connection scenarios are possible. In a first scenario an RRC connection is released with a possible resume operation indicated, and resumption of the connection may then be requested as part of a resume procedure. If this resume procedure is successful, security is established with updated keys and the radio bearers are set up as in the original connection. In a second scenario, where there is no previous release of an RRC connection with a resume indication, or if a resume request is not accepted by the base station, security and radio bearer have to be re-established.

　　3GPP is also working with the satellite communication industry to specify an integrated satellite and terrestrial network infrastructure in the context of 5G. This is referred to as non-terrestrial networks (NTN) which term refers to networks, or segments of networks, using an airborne or spaceborne vehicle for transmission of data and control signalling. Satellites refer to spaceborne vehicles in Low Earth Orbits (LEO), Medium Earth Orbits (MEO), Geostationary Earth Orbit (GEO) or in Highly Elliptical Orbits (HEO). Airborne vehicles refer to High Altitude Platforms (HAPs) encompassing Unmanned Aircraft Systems (UAS) - including tethered UAS, Lighter than Air UAS and Heavier than Air UAS - all operating quasi-stationary at an altitude typically between 8 and 50 km.

　　3GPP Technical Report (TR) 38.811 is a study on New Radio to support such on-terrestrial networks. The study includes, amongst other things, NTN deployment scenarios and related system parameters (such as architecture, altitude, orbit etc.) and a description of adaptation of the 3GPP channel models for non-terrestrial networks (propagation conditions, mobility, etc.). Non-terrestrial networks are expected to:
-　　help foster the 5G service roll out in un-served or underserved areas to upgrade the performance of terrestrial networks;
-　　reinforce service reliability by providing service continuity for user equipment or for moving platforms (e.g. passenger vehicles - aircraft, ships, high speed trains, buses);
-　　increase service availability everywhere; especially for critical communications, future railway/maritime/aeronautical communications; and
-　　enable 5G network scalability through the provision of efficient multicast/broadcast resources for data delivery towards the network edges or even directly to the user equipment.

　　Non-Terrestrial Network access typically features the following elements (amongst others):
-　　NTN Terminal: This may refer to the 3GPP UE or to a UE specific to the satellite system in the case that the satellite does not serve directly 3GPP UEs;
-　　A service link which refers to the radio link between the user equipment and the space/airborne platform (which may be in addition to a radio link with a terrestrial based RAN);
-　　A space or an airborne platform (e.g., a satellite or the like);
-　　Gateways that connect the satellite or aerial access network to the core network. It will be appreciated that gateways will mostly likely be collocated with a base station (e.g. a gNB);
-　　Feeder links which refer to the radio links between the Gateways and the space/airborne platform.

　　There are a number of different architectures that may be used for providing NTN access. One such architecture is a 'regenerative' access network architecture (sometimes referred to as 'regenerative satellite', 'regenerative payload', or 'regenerative mode') in which the non-terrestrial platform (e.g., satellite) performs some on board processing of the payload being communicated between the UE and the core network. Specifically, in a regenerative architecture, at least some of the base station functionality (e.g., at least the functionality of the DU of a distributed base station, or possibly all the base station functionality) is provided on the non-terrestrial platform. Other regenerative mode architectures are also possible, for example architectures in which at least some of the core network functionality is implemented on the non-terrestrial platform.

　　Another possible architecture is a 'transparent' access network architecture (sometimes referred to as 'transparent satellite', 'transparent mode', or 'transparent payload') in which the base station is terrestrially located and sends and receives communications respectively destined for, and originating from, UEs via a terrestrially located gateway and via a non-terrestrial platform that has no base station functionality. The non-terrestrial platform relays these communications to and from the UEs transparently without on-board processing them in effect acting as a so-called 'bent-pipe'. In this architecture, both the service link and the feeder link effectively act as part of the air interface between the base station and the UEs.

　　Satellite or aerial vehicles typically generate several satellite beams over a given area. The beams have a typically elliptic footprint on the surface of the earth. The beam footprint may be moving over the earth with the satellite or the aerial vehicle motion on its orbit. Alternatively, the beam footprint may be earth fixed (albeit temporarily), in such case some beam pointing mechanisms (mechanical or electronic steering feature) may be used to compensate for the satellite or the aerial vehicle motion. There are different options for beam identification purposes. In one option multiple (nearby/neighbouring) satellite beams may have the same associated physical cell ID (PCI) and hence the PCI can remain unchanged as a UE 3 moves from beam-to-beam of the set of beams sharing a PCI. Alternatively, there may be a one-to-one relationship between the PCIs and the satellite beams (at least within a particular satellite's coverage area comprising multiple beams).

　　The coverage in 5G is primarily beam-based rather than cell based. There is no cell-level reference channel from where the coverage of the cell could be measured. Instead, each cell has one or more so-called synchronization signal block (SSB) beams (which are different to satellite or NTN beams). SSB beams form a matrix of beams covering an entire cell area. Each SSB beam carries an SSB comprising a primary synchronization signal (PSS), secondary synchronization signal (SSS), and physical broadcast channel (PBCH).

　　The UE searches for and performs measurements on the SSB beams (e.g. of the synchronization signal reference signal received power, 'SS-RSRP', synchronization signal reference signal received quality, 'SS-RSRQ', and/or the synchronization signal to noise or interference ratio, 'SS-SINR'). The UE maintains a set of candidate beams which may contain beams from multiple cells. A PCI and beam ID (or SSB index) thus distinguish the SSB beams from each other. Effectively, therefore, the SSB beams are like mini cells which may be within a larger cell. Once a UE has detected and selected a cell (and/or an SSB beam in the case of 5G) it may attempt to access that cell and/or SSB beam using an initial RRC connection setup procedure comprising a random access procedure.

　　Specifically, the UE may attempt to access that cell and/or beam using a random access procedure that typically involves four distinct steps. Prior to attempting initial access the UE may perform transmission of a preamble to the network (e.g. a base station such as a gNB) over a physical random access channel (PRACH / RACH) for initiating a random access procedure (also referred to as a RACH procedure or simply RACH) for obtaining synchronization in the uplink (UL). This step is often referred to as PRACH transmission or simply transmission of message 1 (Msg1). In response, the network responds with a random access response (RAR). The RAR indicates reception of the preamble and includes: a timing-alignment (TA) command for adjusting the transmission timing of the UE based on the timing of the received preamble; an uplink grant field indicating the resources to be used in the uplink for a physical uplink shared channel (PUSCH); a frequency hopping flag to indicate whether the UE is to transmit on the PUSCH with or without frequency; a modulation and coding scheme (MCS) field from which the UE can determine the MCS for the PUSCH transmission; and a transmit power control (TPC) command value for setting the power of the PUSCH transmission. The RAR transmission step is often referred to as message 2 (Msg2) transmission. The UE then sends a third message (message 3 or 'Msg3') to the network over the physical uplink shared channel (PUSCH) based on the information in the RAR. The specific message sent by the UE in this step, and the content of the message, depends on the context in which the random access procedure is being used. In the example of initial radio RRC connection setup, however, Msg3 typically comprises an RRC Setup request or similar message carrying a temporary randomly generated UE identifier. The network responds with a fourth message (message 4 or 'Msg4') which carries the randomly generated UE identifier received in Msg3 for contention purposes to resolve any collisions between different UEs using the same preamble sequence. When successful, Msg4 also transfers the UE to a connected state.

　　A similar random access procedure may also be used in other contexts including, for example, handover, connection reestablishment, requesting UL scheduling where no dedicated resource for a scheduling-request has been configured for the UE, etc.

　　A so-called two-step random access procedure has also been developed (in addition to the above described four-step random access procedure). The two-step random access is mainly intended for supporting (Ultra) Low Latency Communications, 10ms control plane latency, fast handover, efficient channel access in unlicensed spectrum, and transmission of small data packets, amongst others. However, it may also apply to large cells such as non-terrestrial cells. The main difference is that whilst the four-step random access procedure requires two round-trip cycles between the UE and the base station, the two-step random access procedure aims to reduce latency and control-signalling overhead by using a single round trip cycle between the UE and the base station. Effectively, this is achieved by combining the UE's PRACH preamble (Msg1) transmission and the scheduled PUSCH transmission (Msg3) into a single message (referred to as 'MsgA'). Similarly, the random access response (RAR/Msg2) from the base station to UE and the contention resolution message (Msg4) are combined in the two-step random access procedure (and referred to as 'MsgB').

　　As those skilled in the art will appreciate, while a contention based PRACH procedure is described, a non-contention based (or 'contention free') procedure may also be used in which a dedicated preamble is assigned by the base station to the UE.

　　In addition to the RACH-based initial access procedures described above, a so called RACH-less access procedure was introduced, in the context of handover procedures during the development of later releases of the LTE standards, also with a view to providing reduced latency. RACH-less based handover provides reductions in the data connectivity interruption time at each handover as it removes the need for performing random access when first accessing the target cell, and hence reduces overall handover execution time.

　　As a non-terrestrial platform serving a UE moves, discontinuous coverage for that UE can occur, even if the UE remains stationary, as a result of the service link dropping, e.g., due to the satellite movement. In addition to discontinuous coverage of this type, there could also be intermittent feeder link connectivity (for example with a gateway at an associated ground station) - e.g., in areas where it is not feasible to deploy a gateway or where deployment of the gateway is not cost effective.

　　Moreover, at different times different NTN platforms (and hence on-board base stations where present) may provide the feeder link and service link respectively. Specifically, for a UE at a given location, it is possible that one or multiple satellites may be circulating around and providing communication services for that UE at different times. Thus the UE will, effectively, see different base stations during different time windows. Similarly, one or multiple satellites may be circulating around the ground location of a gateway via which one or more feeder link connections are being provided meaning that the gateway feeder connectivity may be via different satellites (and, potentially, base stations in the case of a regenerative mode architecture).

　　One such scenario is illustrated, for a regenerative architecture, in Fig. 1 which illustrates a change in the satellite, and hence base station, respectively providing a service link and a feeder link in an NTN system. As seen in Fig. 1, two NTN platforms (in this example satellites), which each provide a respective base station, are shown circulating around and providing a service link to a UE and a feeder link to a gateway (GW) for accessing the core network (CN) at different times (T1) and (T2). Specifically, at T1 a first satellite/base station (base station #1) provides the feeder link, and a second satellite/base station (base station #2) provides the service link. At T2 the situation is reversed, and the first satellite/base station (base station #1) provides the service link, and the second satellite/base station (base station #2) provides the feeder link. Hence, data communicated to base station #2 via the service link, and to base station #1 via the feeder link at time T1, cannot be sent respectively on to the core network and on to the UE until time T2.

　　It can be seen, therefore, that at a given time a UE may not have a full (end-to-end) connection all the way to the core network because the feeder link and associated service link connections are not necessarily available at the same time. In such scenarios, to avoid loss of data, the communication over the service link needs to be stored on the non-terrestrial platform for forwarding over the feeder link to the core network, or vice versa. Such techniques are known as "store and forward" techniques. These techniques are particularly applicable for delay-tolerant communications (i.e., non-real-time communications) such as those typically used in CIoT based communications.

　　By way of example only, one possible store and forward technique is illustrated in Fig. 2 which is a simplified sequence diagram illustrating a generalised procedure for forming a connection in an NTN system that involves storing and forwarding of user and control data. The illustrated procedure is in the context of a CIoT CP mode procedure.

　　As seen in Fig. 2 the procedure begins in a scenario in which a UE 3 is in coverage of a first base station 5A-1 on a first NTN-platform but the feeder link is disconnected (at S210). The UE 3 and first base station 5A-1 of a first NTN RAN 5-1 coordinate with each other to establish an RRC connection (at S212). This procedure will typically involve, for example, a random access procedure, as seen at S214 (e.g., as described above). The random access procedure culminates with the UE 3 sending the first base station 5A-1 a message indicating that an RRC has been completed that includes as a non-access stratum (NAS) payload, a UL NAS protocol data unit (PDU) including a control plane service request (CPSR) and/or control plane data (at S216). As the feeder link between the first base station 5A-1 and the core network 7 is disconnected, the first base station 5A-1 stores the NAS PDU and/or any data at S216. The first base station 5A-1 sends, at S218, a message for releasing the RRC connection to the UE 3 that includes an indication that no feeder link is available and an indication of a scheduled time when the UE 3 might expect a response from core network 7 and hence when it can perform the next transmission. The UE 3 may then enter an idle mode - effectively while awaiting a response. When the feeder link subsequently connects, at S220, the first base station 5A-1 can send, at S222 an initial UE message to the core network 7 including the NAS PDU / data. The core network 7 can determine, at S224, a second base station 5A-2 of a second NTN RAN 5-2 (via which a feeder link is/will be connected to the core network 7) will likely provide coverage to the UE 3 at a future juncture. When a feeder link to this second base station 5A-2 is available the core network 7 can send an appropriate DL NAS response PDU with any DL data at S226. The DL NAS PDU/data are stored at the second base station 5A-2 at S228. When the UE 3 is in the coverage of the second base station 5A-2 at S230, the second base station 5A-2 can page the UE 3 at S232. The UE 3 and the second base station 5A-2 can thus coordinate with one another, at S234, to establish a connection via which the DL NAS PDU and data may be delivered.

　　Nevertheless, the procedure in Fig. 2 does not take into account all the impacts of / issues associated with discontinuous coverage and intermittent feeder links.

　　In this context, as long as a full base station is on board the NTN platform, there is likely to be a greater impact on NAS procedures then AS procedures. This is because NAS procedures require connectivity from the UE all the way to the core network in both directions. For example, for conventional registration/attach procedures, a "store and forward" scheme would typically require, for every request message, a respective stored and forward cycle in one direction and, for every corresponding response message, another store and forward cycle in the opposite direction.

　　Whilst there are likely to be less impacts on AS procedures (like initial access), however, data transmission normally requests an end-to-end connection and UE context establishment between the UE and the core network/packet data network.

　　There is, therefore, a need for further improvements to better support implementation of store and forward techniques effectively, especially in the context of (but not limited to) discontinuous coverage / intermittent feeder links arising in an NTN system.

NPL 1: 3GPP Technical Report (TR) 38.811
NPL 2: NGMN 5G White Paper' V1.0

　　The disclosure aims to provide one or more apparatus and/or one or more associated methods that contributes to meeting the above needs.

　　In one aspect there is provided a method performed by an access network node in a non-terrestrial network, the method comprising:
　　receiving, via an available link, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable, without triggering of establishing a connection for another link than the available link;
　　storing the at least one NAS PDU until the another link becomes available; and
　　forwarding, via the another link, the at least one NAS PDU when the another link becomes available.

　　In one aspect there is provided a method performed by an access network node in a non-terrestrial network, the method comprising:
　　transmitting, via system information, information indicating a mode of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable, and
　　wherein the information causes at least one UE which does not support the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable, not to camp on a serving cell of the access network node.

　　In one aspect there is provided a method performed by an access network node in a non-terrestrial network, the method comprising:
　　transmitting, to a core network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable.

　　In one aspect there is provided a method performed by an access network node in a non-terrestrial network, the method comprising:
　　receiving, from a core network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable.

　　In one aspect there is provided a method performed by a user equipment, UE, the method comprising:
　　transmitting, to an access network node in a non-terrestrial network via a service link between the access network node and the UE, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where a feeder link between the access network node and a gateway in a terrestrial network is unavailable, without triggering of establishing a connection for the feeder link, and wherein
　　the at least one NAS PDU is stored by the access network node until the feeder link becomes available, and
　　the at least one NAS PDU is forwarded via the feeder link when the feeder link becomes available.

　　In one aspect there is provided a method performed by a user equipment, UE, the method comprising:
　　receiving, via system information, information indicating a mode of storing and forwarding data in a case where either a service link between an access network node in a non-terrestrial network and the UE or a feeder link between the access network node and a gateway in a terrestrial network is unavailable; and
　　not camping on a serving cell of the access network node in a case where the UE does not support the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable.

　　In one aspect there is provided a method performed by a core network node, the method comprising:
　　receiving, from an access network node in a non-terrestrial network via a feeder link between the access network node and the core network node, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where a service link between the access network node and a user equipment, UE, is unavailable, without triggering of establishing a connection for the service link, and wherein
　　the at least one NAS PDU is stored by the access network node until the service link becomes available, and
　　the at least one NAS PDU is forwarded via the service link when the service link becomes available.

　　In one aspect there is provided a method performed by a core network node, the method comprising:
　　receiving, from an access network node in a non-terrestrial network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network coupled with the core network node is unavailable.

　　In one aspect there is provided a method performed by a core network node, the method comprising:
　　transmitting, to an access network node in a non-terrestrial network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network coupled with the core network node is unavailable.

　　In one aspect there is provided an access network node in a non-terrestrial network, the access network node comprising:
　　means for receiving, via an available link, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable, without triggering of establishing a connection for another link than the available link;
　　means for storing the at least one NAS PDU until the another link becomes available; and
　　means for forwarding, via the another link, the at least one NAS PDU when the another link becomes available.

　　In one aspect there is provided an access network node in a non-terrestrial network, the access network node comprising:
　　means for transmitting, via system information, information indicating a mode of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable, and
　　wherein the information causes at least one UE which does not support the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable, not to camp on a serving cell of the access network node.

　　In one aspect there is provided an access network node in a non-terrestrial network, the access network node comprising:
　　means for transmitting, to a core network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable.

　　In one aspect there is provided an access network node in a non-terrestrial network, the access network node comprising:
　　means for receiving, from a core network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable.

　　In one aspect there is provided a user equipment, UE, comprising:
　　means for transmitting, to an access network node in a non-terrestrial network via a service link between the access network node and the UE, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where a feeder link between the access network node and a gateway in a terrestrial network is unavailable, without triggering of establishing a connection for the feeder link, and wherein
　　the at least one NAS PDU is stored by the access network node until the feeder link becomes available, and
　　the at least one NAS PDU is forwarded via the feeder link when the feeder link becomes available.

　　In one aspect there is provided a user equipment, UE, comprising:
　　means for receiving, via system information, information indicating a mode of storing and forwarding data in a case where either a service link between an access network node in a non-terrestrial network and the UE or a feeder link between the access network node and a gateway in a terrestrial network is unavailable; and
　　means for not camping on a serving cell of the access network node in a case where the UE does not support the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable.

　　In one aspect there is provided a core network node comprising:
　　means for receiving, from an access network node in a non-terrestrial network via a feeder link between the access network node and the core network node, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where a service link between the access network node and a user equipment, UE, is unavailable, without triggering of establishing a connection for the service link, and wherein
　　the at least one NAS PDU is stored by the access network node until the service link becomes available, and
　　the at least one NAS PDU is forwarded via the service link when the service link becomes available.

　　In one aspect there is provided a core network node comprising:
　　means for receiving, from an access network node in a non-terrestrial network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network coupled with the core network node is unavailable.

　　In one aspect there is provided a core network node comprising:
　　means for transmitting, to an access network node in a non-terrestrial network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network coupled with the core network node is unavailable.

　　The various functional means described below that are part of the UE may be provided by a memory and one or more processors that execute instructions stored in the memory. Similarly, the various functional means described below that are part of the access network node may be provided by a memory and one or more processors that execute instructions stored in the memory.

　　Various example described below may be implemented by means of a computer program product comprising computer implementable instructions for causing a programmable computer to carry out the any of the methods described below. The computer implementable instructions may be provided as a signal or on a tangible computer readable medium.

　　According to the present disclosure, it is possible to provide a method performed by an access network node, a method performed by a user equipment, a method performed by a core network node, an access network node, a user equipment, and a core network node.

　　Example embodiments of the disclosure will now be described, by way of example, with reference to the accompanying drawings in which:

Fig. 1 illustrates a scenario in which there is a change in the satellite, and hence base station, respectively providing a service link and a feeder link in an NTN system; Fig. 2 is a simplified sequence diagram illustrating a generalised procedure for forming a connection in an NTN system; Fig. 3 illustrates schematically an exemplary mobile (cellular or wireless) communication system; Fig. 4 is a simplified sequence diagram illustrating an attach procedure that may be used in the communication system of Fig. 3; Fig. 5 is a simplified sequence diagram illustrating a procedure for mobile originated data transport in the context of CP CIoT EPS optimisation that may be used in the communication system of Fig. 3; Fig. 6 is a simplified sequence diagram illustrating a procedure for mobile terminated data transport in the context of CP CIoT EPS optimisation that may be used in the communication system of Fig. 3; Fig. 7 illustrates schematically a non-terrestrial network (NTN) radio access network that may be used in the communication system of Fig. 3; Fig. 8A illustrates a possible architecture of an NTN RAN; Fig. 8B illustrates a possible architecture of an NTN RAN; Fig. 8C illustrates a possible architecture of an NTN RAN; Fig. 9 is a simplified sequence diagram illustrating a CIoT optimisation based data transmission flow between a base station of an NTN RAN, that may be used in the communication system of Fig. 3, when a service link is available, but a feeder link is unavailable; Fig. 10 is a simplified sequence diagram illustrating a CIoT optimisation based data transmission flow between an NTN RAN and a core network, that may be used in the communication system of Fig. 3, when a feeder link is available, but a service link is unavailable; Fig. 11 is a simplified sequence diagram illustrating how parts of the procedures shown in Figs. 9 and 10 may be enhanced; Fig. 12 is a simplified sequence diagram illustrating an S1 setup procedure; Fig. 13 is a simplified block schematic illustrating the main components of a user equipment that may be used in the communication system of Fig. 3; Fig. 14 is a simplified block schematic illustrating the main components of a base station / access network node that may be used in the communication system of Fig. 3; and Fig. 15 is a simplified block schematic illustrating the main components of a core network node that may be used in the communication system of Fig. 3.

　　< Overview >
　　An exemplary communication system will now be described in general terms, by way of example only, with reference to Figs. 3 to 8.

　　Fig. 3 schematically illustrates a mobile ('cellular' or 'wireless') communication system 1 to which the examples described herein are applicable.

　　In the communication system 1, user equipment (UEs) 3 (3-1, 3-2, 3-3) (e.g. mobile telephones and/or other mobile devices) can communicate with each other via a corresponding radio access network (RAN) 5-1, 5-2 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, each RAN 5-1, 5-2 (which may be an NTN based RAN) includes a base station 5A-1, 5A-2 (e.g., an LTE/4G base station such as an eNB) that respectively operates one or more associated cells 9 (9-1, 9-2).

　　As those skilled in the art will appreciate, whilst three UEs 3, and two RANs 5-1, 5-2 are shown in Fig. 3 for illustration purposes, the system, when implemented, will typically include other RAN 5 and UEs 3.

　　In the exemplary system the UEs 3 include one or more so-called 'internet-of-things' ('IoT') devices such as narrowband IoT (NB-IoT) devices or the like.

　　Each RAN 5-1, 5-2 controls one or more associated cells either directly, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, and/or the like). It will be appreciated that the RAN 5 may be configured to support 4G, 5G, 6G and/or later generations, and/or any other 3GPP or non-3GPP communication protocols.

　　The UEs 3 and their serving RAN 5 are connected via an appropriate air interface (for example the so-called 'Uu' interface and/or the like). Base stations 5A of neighbouring RANs 5 may be connected to each other via an appropriate base station to base station interface (such as the so-called 'X2' interface for 4G, 'Xn' interface for 5G, and/or the like).

　　The core network 7 includes a number of communication nodes / logical nodes (or 'functions') for supporting communication in the communication system 1. In this example, the core network 7 comprises control one or more network node entities for the communication of control signalling (e.g. Mobility Management Entities (MMEs) 11 or mobility management nodes 11), one or more network node entities for routing incoming and outgoing packets (e.g. Serving Gateways (S-GWs) 13), one or more network node entities for connecting the core network 7 and external networks 20 (e.g. Packet Data Network Gateways (P-GWs) 15) together with a number of other functional nodes (not shown). It will be appreciated that the nodes or functions may have different names in different systems. It will be appreciated that while the core network 7 is described in the context of 4G entities and interface/reference points, the core network 7 could be any suitable core network (e.g., a 5G/6G and/or later generations core network) with corresponding communication entities (e.g., control functions (CPFs) such as AMF, SMF, etc. - and one or more user plane functions (UPFs)).

　　The RAN 5 is connected to the core network nodes via appropriate interfaces (or 'reference points') such as an S1-MME reference point between the base station 5A of the RAN 5 and the MME 11 and an S1-U reference point between the base station 5A of the RAN 5 and the S-GW 13. The UEs 3 each connect to the MME 11, when applicable, via a non-access stratum (NAS) connection over an appropriate interface (e.g. an S1 reference point (analogous to the N1 reference point in 5G)). It will be appreciated, that S1 communications are routed transparently via the RAN 5.

　　The core network 7 (e.g., the P-GW 15) is connected to an external network 20 (e.g. an IP network such as the internet) via another reference point (e.g., 'SGi') for communication of the user data.

　　The MME 11 manages general mobility aspects of the UEs 3 and ensures that connectivity is maintained with the UE 3 as it is moving within the geographical area covered by the communication system 1 (and/or as the UE 3 is handed over between base stations 5A of the communication system 1). The MME 11 also handles control-plane signalling for the UE 3 and manages the various bearers associated with the UE 3 (e.g. such as an Evolved Packet System (EPS) bearer and/or a radio bearer), for example by controlling the S-GW 13 and the P-GW 15 (and/or possibly other network nodes) via which such bearers are provided.

　　The S-GW 13 provides a connection between the UE 3 and the core network 7 (via a base station 5A) for sending and receiving user plane data over an associated communication bearer (e.g. an EPS bearer). The communication bearer normally terminates at the P-GW 15, although it is often complemented by an external bearer as well (for example, another EPS bearer and/or the like) between the P-GW 15 and a communication endpoint outside the core network 7 (e.g. in the external network 20). It will be appreciated that, whilst shown as separate entities, the functionalities of the S-GW 13 and the P-GW 15 could be implemented in a single gateway element.

　　The RAN 5 is also configured for transmission of, and the UEs 3 are configured for the reception of, control information and user data via a number of downlink (DL) physical channels and for transmission of a number of physical signals. The DL physical channels correspond to resource elements (REs) carrying information originated from a higher layer, and the DL physical signals are used in the physical layer and correspond to REs which do not carry information originated from a higher layer.

　　The physical channels may include, for example, a physical downlink shared channel (PDSCH), a physical broadcast channel (PBCH), and a physical downlink control channel (PDCCH). The PDSCH carries data sharing the PDSCH's capacity on a time and frequency basis. The PDSCH can carry a variety of items of data including, for example, user data, UE-specific higher layer control messages mapped down from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) for supporting a number of functions including, for example, scheduling the downlink transmissions on the PDSCH and also the uplink data transmissions on a physical uplink shared channel (PUSCH). The PBCH provides UEs 3 with a Master Information Block (MIB). It also, in conjunction with the PDCCH, supports the synchronisation of time and frequency, which aids cell acquisition, selection and re-selection.

　　The DL physical signals may include, for example, reference signals (RSs) and synchronization signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the base station 5A of the RAN 5. The reference signals may include, for example, cell specific reference signals, UE-specific reference signal (UE-RS), downlink demodulation signals (DMRS), and channel state information reference signal (CSI-RS).

　　Similarly, the UEs 3 are configured for transmission of, and the base station 5A of the RAN 5 is configured for the reception of, control information and user data via a number of uplink (UL) physical channels corresponding to REs carrying information originated from a higher layer, and UL physical signals which are used in the physical layer and correspond to REs which do not carry information originated from a higher layer. The physical channels may include, for example, the PUSCH, a physical uplink control channel (PUCCH), and/or a physical random-access channel (PRACH). The UL physical signals may include, for example, demodulation reference signals (DMRS) for a UL control/data signal, and/or sounding reference signals (SRS) used for UL channel measurement.

　　< Attach Procedure & Initial Access >
　　The UEs 3, base station 5A of the RAN 5, and core network entities 7 of the communication system 1 are mutually configured for performing an attach procedure for connecting the UE 3 to the network for communication of user data.

　　One possible such procedure that may be performed will now be described, by way of example only, with reference to Fig. 4 which is a simplified sequence diagram illustrating an attach procedure that may be used in the communication system 1.

　　As seen in Fig. 4, after initial synchronisation to the network (e.g., based on receipt of the PSS and SSS) the UE 3 receives a MIB, at S410, and one or more SIBs, at S412 (in this example at least system information block type 1 (SIB1)). The MIB typically provides, for example, information identifying a system bandwidth, an antenna configuration, and a system frame number. Receipt of the MIB and other system information allows the UE 3 to further (downlink) synchronise with the base station 5A of the RAN 5.

　　When the UE 3 needs to connect to the network it can then perform a random access channel (RACH) procedure for the UE 3 to access the network. Specifically, the UE 3 is able to attempt access to access a cell 9 (and/or beam) using an initial RRC connection setup procedure comprising a random access procedure. Prior to attempting initial access the UE 3 chooses random access resources (including, for example, a preamble) to use to initiate the RACH procedure. The UE 3 sends, at S414, the selected preamble (e.g., in 'Msg1') to the base station 5A of the RAN 5 over a physical random access channel (PRACH) for initiating the process to obtain synchronization in the uplink (UL). In response, the base station 5A of the RAN 5 responds, at S416, with a random access response (RAR) (or 'Msg2'). The RAR indicates reception of the preamble and may include (for example): a timing-alignment (TA) command for adjusting the transmission timing of the UE 3 based on the timing of the received preamble; an uplink grant field indicating the resources to be used in the uplink for a physical uplink shared channel (PUSCH); a frequency hopping flag to indicate whether the UE 3 is to transmit on the PUSCH with or without frequency; a modulation and coding scheme (MCS) field from which the UE 3 can determine the MCS for the PUSCH transmission; and a transmit power control (TPC) command value for setting the power of the PUSCH transmission. At this point an initial signalling radio bearer (SRB), 'SRB0', is established for communicating certain types of RRC messages on a common control channel (CCCH). The UE 3 then sends, at S418, a third message ('Msg3') to the network over a physical uplink shared channel (PUSCH) based on the information in the RAR (e.g., using SRB0). The specific message sent by the UE 3 in this step, and the content of the message, depends on the context in which the random access procedure is being used. In the example of initial radio RRC connection setup, however, Msg3 typically comprises an RRC connection request or similar message carrying a temporary randomly generated UE identifier. The network responds, at S420, with a fourth message ('Msg4') carrying the randomly generated UE identifier received in Msg3 (e.g., for contention purposes to resolve any collisions between different UEs 3 using the same preamble sequence). When successful, Msg4 also transfers the UE 3 to a connected state in which and another SRB, 'SRB1', is established for communicating certain RRC and NAS messages on a dedicated control channel (DCCH).

　　The UE 3 then attempts to achieve packet data network (PDN) connectivity by sending to the base station 5A of the RAN 5, at S422, a message indicating that RRC has been completed. This message includes as a NAS payload, an attach request to initiate the attach procedure and a PDN connectivity request. The base station 5A of the RAN 5 then sends, at S424, its first message to the core network 7 - an initial UE message containing the attach request and the PDN Connectivity Request. This message is sent to the core network node for providing mobility management functionality (in this example an MME 11 but for 5G may be an AMF). This message is sent via the S1-MME interface/reference point and includes information such as a tracking area identify (TAI) and E-UTRAN cell global identifier (ECGI) in this 4G example (similar but differently named messages/information elements may be used for 5G and other generations).

　　The mobility management node 11 coordinates, at S426, with another core network node (e.g., a home subscriber server HSS and/or authentication centre (AuC) in this example) to obtain authentication information, for example security information such as: KASME (an intermediate key that is derived in the HSS, and in the UE 3 from a cipher key, an integrity key, and a serving network identity (SN id)); AUTN (a so called authentication token generated at the AuC); XRES (a so-called 'expected response' generated at the AuC); and/or RAND (a random number for use in key generation and authentication).

　　The mobility management node 11 sends, at S428, an authentication request to the UE 3 (including RAND and AUTN) and the UE 3 responds with an authentication response, at S430, including an authentication response parameter calculated based on the RAND and AUTN and a key (K) stored at the UE 3 (e.g., in a subscriber identity module).

　　The mobility management node 11 then initiates NAS signalling security between the mobility management node 11 and the UE 3, at S432, by sending an NAS security mode command message informing the UE 3 of the respective algorithms to use for integrity protection and (de)ciphering. The UE 3 responds, at S434, after deriving appropriate security information, by sending a response message informing the mobility management node 11 that NAS signalling security initialisation is complete (at S436).

　　The mobility management node 11 coordinates, at S438, with one or more other core network nodes (e.g. an HSS) to obtain location update related information such as PDN subscription contexts (including e.g., EPS subscribed quality of service (QoS) profile and the subscribed access point name - aggregate maximum bit rate (APN-AMBR)).

　　The mobility management node 11 coordinates, at S440, with one or more other core network nodes (e.g. a S-GW 13 and/or P-GW 15 or combination thereof) to initiate establishment a communication GPRS tunnelling protocol (GTP) tunnel by sending an appropriate create session request (e.g. to the S-GW 13) and receiving an appropriate response once the tunnel is established. For example, after the S-GW 13 has sent a corresponding default bearer request to the P-GW 15, to create a new entry in its EPS bearer context table and a default bearer response is sent from the P-GW 15 to the S-GW 13 containing a P-GW 15 user plane address, P-GW 15 tunnel endpoint identifiers (TEIDs) for user and control plane, EPS bearer identity and QoS information. The P-GW 15 also sends downlink data that will be buffered in the S-GW 13 until connection is complete. An acknowledgment message is typically from the S-GW 13 to the mobility management node 11 that indicates a GTP for control (GTP-C) tunnel has been established.

　　The mobility management node 11 sends, at S442, initial context setup request (e.g., containing an S1 interface context setup request, NAS attachment accept, and activate default bearer request).

　　A UE capability exchange may follow in which the base station 5A sends (typically using RRC signalling), to the UE 3 (at S444) a UE capability inquiry to request information about the UE's capabilities. The UE 3 responds, at S446, with the requested UE capability information and the base station 5A provides an indication of this UE capability information to the mobility management node 11 at S448.

　　Access stratum (AS) security is then established. Specifically the base station 5A sends, at S450, an RRC security mode command with the AS integrity protection and encryption algorithms and 'START' parameters to the UE 3. The UE 3 calculates appropriate security keys using the received information and sends a message to the base station 5A, at S452, to indicate that RRC security mode completion. During this stage a further signalling radio bearer (SRB2) is established. SRB2 is used for RRC messages which include logged measurement information as well as for NAS messages, all using DCCH logical channel. SRB2 has a lower priority than SRB1 and is configured by the base station 5A after security activation.

　　RRC reconfiguration follows in which the base station 5A sends an RRC reconfiguration to the UE 3, at S454, to activate a default radio bearer. The UE 3 configures itself based on the information in the RRC reconfiguration and sends an RRC reconfiguration complete message at S456. The base station 5A then sends, at S458, a message to the mobility management node 11 to indicate that initial context setup is complete. The mobility management node 11 then coordinates with one or more other core network nodes (e.g. the S-GW 13) to modify the bearer appropriately and establish a data radio bearer (DRB) for the UE's communication.

　　While a four-step contention-based RACH procedure is described it will be appreciated that a UE 3 and the base station 5A of the RAN 5 of the communication system 1 may also perform a non-contention based (or 'contention free') procedure in which a dedicated preamble is assigned by the base station 5A of the RAN 5 to the UE 3. Moreover, a UE 3 and the base station 5A of the RAN 5 of the communication system 1 may perform a two-step RACH procedure (e.g., as described in the introduction).

　　It will be appreciated that while the UE 3 can trigger initiation of the RACH procedure itself (e.g., when the UE 3 needs to connect to the network), initiation of the RACH procedure may be by the network. For example, a RACH procedure may be initiated via a message sent via downlink control information (DCI) with an appropriate DCI format (e.g. 1_0) in a physical downlink control channel (PDCCH) - such a message is commonly known as a PDCCH order. A RACH procedure may be also initiated by the base station 5A of the RAN 5 when handover is required (e.g., using a handover command message).

　　< CP CIoT EPS Optimisation >
　　The UEs 3, base station 5A of the RAN 5, and core network entities 7 of the communication system 1 are mutually configured for implementing a number of procedures in the context of CP CIoT EPS optimisation. These procedures include, for example, mobile originated (MO) and mobile terminated (MT) data transport.
In these general procedures, in which there are no issues associated with discontinuous coverage / intermittent feeder links, there is no need to have a UE context available at the base station 5A. The UL/DL data being transmitted/received by the UE 3 is encapsulated in NAS PDUs as it is transported through the wider network. Over air interface, the NAS data PDUs are transmitted via RRC messages (e.g., piggybacked on an RRC connection complete message, or in UL/DL information transfer messages) during and after RRC connection establishment. In these procedures no DRB is established, and no AS security is set up. Over the S1-AP (NG-AP for 5GS) interface, NAS data PDUs are transmitted via S1-AP (NG-AP for 5GS) messages.

　　< Mobile Originated Data Transport >
　　As mentioned above, the UEs 3, base station 5A of the RAN 5, and core network entities of the communication system 1 are mutually configured for performing MO data transport in the context of CP CIoT EPS optimisation.

　　One such procedure will now be described, by way of example only with reference to Fig. 5 which is a simplified sequence diagram illustrating a procedure for MO data transport, in the context of CP CIoT EPS optimisation, with P-GW connectivity that may be used in the communication system 1. In this procedure, the CP CIoT EPS optimisation is described in the context of the 4G entities illustrated in Fig. 3. It will, nevertheless, be appreciated that a similar procedure may be followed by corresponding 5G entities for CP CIoT 5GS optimisation (or by corresponding devices of future generations). It will be appreciated that the description here is only intended as an overview and therefore not all parameters are listed or described for the message flows.

　　As seen at S500, at the start of the procedure the UE 3 is in an idle mode/state (in this example an EPS connection management (ECM) or 'ECM-IDLE' mode/state in which the UE 3 does not have a signalling connection to the MME 11).

　　At S501, the UE 3 establishes an RRC connection, or sends the RRC early data request message, and includes (e.g., in the RRC connection setup complete message or the RRC early data request message) an integrity protected NAS PDU. The NAS PDU carries an EPS Bearer ID (EBI) and encrypted UL data. The UE 3 may also indicate, e.g., in a NAS release assistance information field of the NAS PDU, whether no further UL or DL data transmissions are expected, or only a single DL data transmission (e.g., an acknowledgement or response to UL data) subsequent to this UL data transmission is expected.

　　At S501b, the base station 5A may (e.g., for an NB-IoT case) coordinate with the MME 11 to retrieve an EPS negotiated QoS profile from the MME 11 (if not previously retrieved).

　　At S502, the NAS PDU provided to the base station 5A at S501 is relayed (with the EBI) to the MME 11 using an S1-AP initial UE message (corresponding to an NG-AP message in 5GS). If an RRC early data request message was used at S501, then the base station 5A may include an "EDT Session" indication in the S1-AP Initial UE message.

　　At S503, the MME 11 checks the integrity of the incoming NAS PDU and decrypts the data it contains.

　　The MME 11 may, nevertheless, reject the request by discarding the NAS data PDU and sending a service reject message to the UE 3 with an appropriate cause. A rejection may occur, for example, if there is a service gap timer running in an MME mobility management (MM) Context for the UE and the MME 11 is not waiting for a MT paging response from the UE 3. The MME 11 may also provide the UE 3 with a mobility management back-off timer set to the remaining value of the service gap timer, followed by triggering an S1 release procedure.

　　At S504, the MME 11 may send a modify bearer request message (e.g., including an MME address, an MME TEID DL, a delay downlink packet notification request, an RAT Type, an LTE-M RAT type reporting to PGW flag, an MO Exception data counter, and/or the like) for each PDN connection to the S-GW 13. The modify bearer request message may be sent, for example, if a connection is not established over the user plane interface/reference point between the MME 11 and S-GW 13 (S11-U interface). The S-GW 13 is now able to transmit downlink data towards the UE 3. Also, regardless of whether the S11-U was already established, a modify bearer request message may be sent with appropriate information in other scenarios, for example: if the P-GW 15 requested the UE's location and/or user closed subscriber group information and that information has changed; if the serving network information has changed compared to the last reported modify bearer request message; then the MME 11 shall send the Modify Bearer Request message and also includes the Serving Network IE in this message; and/or if a UE time zone has changed compared to a last reported UE time zone.

　　At S505, if a modify bearer request message is sent then the S-GW 13 may send the modify bearer request message to the P-GW 15 including information depending on the content of the modify bearer request message and/or the reason it was sent.

　　At S506, if a modify bearer request message is sent at S505, then the P-GW 15 may send a modify bearer response to the S-GW 13.

　　At S507, if a modify bearer request message was sent at S504, then the S-GW 13 may return an appropriate modify bearer response (S-GW address and TEID for uplink traffic) to the MME 11 as a response to the modify bearer request message. The S-GW address for S11-U User Plane and S-GW TEID are used by the MME 11 to forward UL data to the S-GW 13 as seen at S508.

　　If no DL data is expected based on NAS release assistance information provided by the UE 3 at S501, this indicates that all application layer data exchanges have completed with the UL data transfer, and if the MME 11 is not aware of pending MT traffic and S1-U bearers are not established, the procedure may skip to S511.

　　Otherwise, DL data may arrive at the P-GW 15 and the P-GW 15 may sends the DL data to the MME 11 via the S-GW 13 at S509. If no data is received S510 to S512 may be skipped and the base station 5A may trigger S514 after it detects no activity at S513. While the RRC connection is active, the UE 3 may still send UL data and may receive DL data in NAS PDUs that are carried in a S1-AP UL or DL messages respectively (not shown in the figure). At any time the UE 3 has no user plane bearers established it may provide NAS release assistance information with the UL data. In this case, to assist location services, the base station 5A may indicate, if needed, the UE's coverage level to the MME 11.

　　At S510, if DL data is received at S509, the MME 11 encrypts, and integrity protects the DL data.

　　At S511, if S510 occurs, then the DL data is encapsulated in a NAS PDU and sent to the base station 5A in a DL NAS transport message, e.g., in an S1-AP downlink NAS transport message.

　　If the configuration in the MME 11 indicates that the base station 5A supports acknowledgements of downlink NAS data PDUs and if acknowledgements of downlink NAS data PDUs are enabled in the subscription information for the UE 3, then the MME 11 may indicate in the S1-AP downlink NAS message that acknowledgment is requested from the base station 5A.

　　If, on the other hand, S510 does not occur, or a NAS service accept message is not to be sent, then the MME 3 may send (at S511) a connection establishment indication message to the base station 5A to complete the establishment of the UE-associated logical S1-connection.

　　The UE radio capability may be provided from the MME 11 to the base station 5A in the DL NAS transport message or connection establishment indication message, and the base station 5A may store the received UE radio capability information.

　　If NAS release assistance information was received with UL data and it indicated that DL data was expected, then the next DL packet following the sending of the NAS release assistance information will be the last packet of the application layer data exchange. For this case, unless the MME 11 is aware of additional pending MT traffic and unless S1-U bearers are established, the MME 11 sends, at S512, an S1 UE context release command immediately after the S1-AP message including the DL data encapsulated in the NAS PDU as an indication that the base station 5A should release the RRC connection promptly after successfully sending data to the UE 3. Alternatively, if an "EDT Session" indication was received at S502, then the MME 11 may include an "End Indication" for no further data in the S1-AP message including the DL data encapsulated in NAS PDU. If the MME 11 includes the "End Indication" indicating no further data and if the base station 5A does not proceed with RRC connection establishment, then the base station 5A skips S512a and initiates S512b.

　　If the NAS release assistance information was received indicating no downlink data expected, then all application layer data exchanges have completed with the UL data transfer. For this case, unless the MME 11 is aware of additional pending MT traffic and unless S1-U bearers are established:
　　- the MME may send an S1-AP UE Context Release Command either immediately after the S1-AP DL NAS transport (indicating NAS Service Accept), in which case S512b and S514 may be skipped, or immediately after the S1-AP connection establishment indication, in which case S512b to S514 may all be skipped.
　　- alternatively, if the MME 11 received the "EDT Session" indication from the base station 5A at S502, the MME 11 may include the "End Indication" with no further data in the S1-AP DL NAS transport (indicating NAS Service Accept), or S1-AP connection establishment indication. If the base station 5A does not proceed with RRC connection establishment, then the base station 5A may skip S512a and initiate S512b.

　　At S512a, the base station 5A sends, to the UE 3, an RRC DL data message including the DL data encapsulated in a NAS PDU. If, at S511, the S1-AP message with the NAS data PDU was followed by an S1 UE context release command, S515 may be completed promptly after the DL data transmission of the NAS PDU to the UE 3 has completed and any acknowledgement has been sent to the MME 11 (as seen at S513), without the base station 5A needing to monitor NAS PDU activity (at S514).

　　At S512b, if an "End Indication" with no further data was received in the S1-AP message from the MME 11, then the base station 5A may send an RRC early data complete message together with any NAS payload received at S511 (either a NAS data PDU or a NAS service accept). S514 may also be skipped in this case.

　　At S513, the base station 5A may send a NAS delivery indication to the MME 11 (if requested).

　　At S514, NAS PDU activity is monitored at the base station 5A.

　　If there is no NAS PDU activity for a while, then the base station 5A detects inactivity and initiates the S1 release procedure at S515.

　　< Mobile Terminated Data Transport >
　　As mentioned above, the UEs 3, base station 5A of the RAN 5, and core network entities 7 of the communication system 1 are mutually configured for performing MT data transport in the context of CP CIoT EPS optimisation.

　　One such procedure will now be described, by way of example only with reference to Fig. 6 which is a simplified sequence diagram illustrating a procedure for MT data transport, in the context of CP CIoT EPS optimisation, with P-GW connectivity that may be used in the communication system 1. In this procedure, the CP CIoT EPS optimisation is described in the context of the 4G entities illustrated in Fig. 3. It will, nevertheless, be appreciated that a similar procedure may be followed by corresponding 5G entities for CP CIoT 5GS optimisation (or by corresponding devices of future generations). It will be appreciated that the description here is only intended as an overview and therefore not all parameters are listed or described for the message flows.

　　As seen at S600, at the start of the procedure the UE 3 is in an idle mode/state (in this example an EPS connection management (ECM) or 'ECM-IDLE' mode/state in which the UE 3 does not have a signalling connection to the MME 11).

　　At S601, the S-GW 13 receives, from a P-GW 15, a DL data packet/control signalling for a UE 3. If the S-GW context data indicates that no DL user plane TEID towards the MME 11, then the S-GW buffers the DL data packet and identifies which MME 11 is serving that UE 3.

　　At S602a, if the S-GW 13 is buffering data (e.g., as described for S601 above), then the S-GW 13 sends a downlink data notification message (e.g., including an allocation and retention priority (ARP) and an EPS Bearer ID) to the MME 11 for which it has control plane connectivity for the given UE 3. The MME 11 responds to the S-GW 13 with a downlink data notification acknowledgement message at S602b.

　　At S603, assuming that the UE 3 is registered in the MME 11 and considered reachable (and possibly subject to other criteria), the MME 11 may send one or more paging messages.

　　At S604, a base station 5A of a RAN 5 that receives one or more paging messages from the MME 11, pages the UE 3.

　　At S605, as the UE 3 is in the ECM-IDLE state, upon reception of the paging indication, the UE 3 and base station 5A coordinate with one another to establish an RRC connection (e.g., as described with reference to Fig. 4). During connection establishment the UE 3 may send a control plane service request NAS message using RRC Connection request. The base station 5A may send this to the MME 11 in an S1-AP initial UE message as seen at S606.

　　The control plane service request NAS message, when Control Plane CIoT EPS optimisation applies, does not trigger data radio bearer establishment by the MME 11, and the MME 11 can immediately send downlink data it receives, using a NAS PDU, to the base station 5A. The MME 11 supervises the paging procedure with a timer. If the MME 11 receives no response from the UE 3, to the paging request message, it may repeat the paging according to any applicable paging strategy.

　　At S605b, the base station 5A may (e.g., for an NB-IoT case) coordinate with the MME 11 to retrieve an EPS negotiated QoS profile from the MME 11 (if not previously retrieved).

　　At S607, the MME 11 may send a modify bearer request message (e.g., including an MME address, an MME TEID DL, a delay downlink packet notification request, an RAT Type, an LTE-M RAT type reporting to PGW flag, and/or the like) for each PDN connection to the S-GW 13. The modify bearer request message may be sent, for example, if a connection is not established over the user plane interface/reference point between the MME 11 and S-GW 13 (S11-U interface). The S-GW 13 is now able to transmit downlink data towards the UE 3. Also, regardless of whether the S11-U was already established, a modify bearer request message may be sent with appropriate information in other scenarios, for example: if the P-GW 15 requested the UE's location and/or user closed subscriber group information and that information has changed; if the serving network information has changed compared to the last reported modify bearer request message; then the MME 11 shall send the Modify Bearer Request message and also includes the Serving Network IE in this message; and/or if a UE time zone has changed compared to a last reported UE time zone.

　　At S608, if a modify bearer request message is sent then the S-GW 13 may send the modify bearer request message to the P-GW 15 including information depending on the content of the modify bearer request message and/or the reason it was sent.

　　At S609, if a modify bearer request message is sent at S608, then the P-GW 15 may send an appropriate modify bearer response to the S-GW 13.

　　At S610, if a modify bearer request message was sent at S607, then the S-GW 13 may return an appropriate modify bearer response (S-GW address and TEID for uplink traffic) to the MME 11 as a response to the modify bearer request message. The S-GW address for S11-U User Plane and S-GW TEID are used by the MME 11 to forward any UL data to the S-GW 13.

　　At S611, buffered (if S11-U was not established) downlink data may be sent by the S-GW 13 to the MME 11.

　　At S612, the MME 11 encrypts, and integrity protects downlink data.

　　At S613, the MME 11 may send the encrypted and integrity protected downlink data to the base station 5A using a NAS PDU carried by a downlink S1-AP message. If the configuration in the MME 11 indicates that the base station 5A supports acknowledgements of downlink NAS data PDUs and if acknowledgements of downlink NAS data PDUs are enabled in the subscription information for the UE 3, then the MME 11 may indicate in the S1-AP downlink NAS message that acknowledgment is requested from the base station 5A.

　　At S614, the NAS PDU with data is delivered to the UE 3 via a downlink RRC message. This is taken by the UE 3 as implicit acknowledgment of the service request message sent at S605.

　　At S615, the base station 5A sends a NAS Delivery indication to the MME 11 (if requested).

　　At S616, while the RRC connection is still up, further UL (and DL) data may be transferred using NAS PDUs. In the figure a UL data transfer is shown using a UL RRC message encapsulating a NAS PDU with the UL data. At any time the UE 3 has no user plane bearers established, the UE 3 may provide release assistance information with uplink data in the NAS PDU.

　　At S617, a NAS PDU with data is sent to the MME 11 in a UL S1-AP message.

　　At S618, the data is checked for integrity and decrypted.

　　At S619a and S619b, the MME 11 sends UL data to the P-GW 15 via the S-GW 13 and executes any action related to the presence of release assistance information as follows:
-　　for the case where the release assistance information indicates there is no downlink data to follow the uplink data then unless the MME 11 is aware of pending MT traffic, and unless S1-U bearers exist, the MME 11 immediately releases the connection and skips to S621.
-　　for the case where the release assistance information indicates that downlink data will follow the uplink transmission then unless the MME 11 is aware of additional pending MT traffic, and unless S1-U bearers exist, the MME 11 sends a S1 UE context release command to the base station 5A immediately after the S1-AP message including the downlink data encapsulated in a NAS PDU.

　　At S620, NAS PDU activity is monitored at the base station 5A.

　　If there is no NAS PDU activity for a while, then the base station 5A detects inactivity and initiates the S1 release procedure at S621.

　　< NTN RAN >
　　In the exemplary communication system 1, each RAN 5 may be implemented as a non-terrestrial network (NTN) RAN.

　　Fig. 7 illustrates schematically one such NTN RAN 5 that may be used in the communication system of Fig. 3.

　　As seen in Fig. 7, the NTN RAN 5 comprises a base station 5A operating one or more associated cells 9, a gateway 5B, and a non-terrestrial (space or air borne) platform 5C (e.g. comprising one or more satellites and/or airborne vehicles), which may be referred to generally as a 'satellite' for simplicity. Communication via the NTN RAN 5 is routed through the core network 7 and external network 20 (e.g. via the N6 interface / reference point).

　　The NTN RAN 5 controls a number of directional satellite beams via which associated NTN cells 9 may be provided. Specifically, each satellite beam has an associated footprint on the surface of the Earth which forms an NTN cell, or part of an NTN cell. Each NTN cell has an associated Physical Cell Identity (PCI). The satellite beam footprints may be moving as the non-terrestrial (space or air borne) platform 5C is travelling along its orbit (e.g. as illustrated by the arrows A in Fig. 7). Alternatively, the satellite beam footprint may be earth fixed, in which case an appropriate satellite beam pointing mechanism (mechanical or electronic steering) may be used to compensate for the movement of the non-terrestrial (space or air borne) platform 5C. Satellite beams and satellites are not considered visible from a UE perspective in NTN. This does not, however, preclude differentiating at the public land mobile network (PLMN) level the type of network (e.g. NTN vs. terrestrial).

　　The base station 5A of the NTN RAN 5 is configured to provide ephemeris data for the non-terrestrial (space or air borne) platform 5C, to the UEs 3, to help UEs 3 perform measurement and cell selection/reselection and for supporting initial access. This ephemeris data may comprise information on orbital information such as information on orbital plane level or on satellite level and/or information (e.g. a pointer or index) from which more detailed ephemeris data stored in the UE 3 (e.g. in a subscriber identity module, 'SIM') may be obtained. At least some of this ephemeris information may, for example, be provided in system information and/or may be provided using UE specific (dedicated) signalling such as RRC signalling.

　　Specifically, the base station 5A is able to provide satellite assistance information for the satellite as part of a dedicated system information block (SIB) that is broadcast to UEs 3 in a corresponding cell 9 of the NTN RAN 5 (for 5G NTN this may, for example, be SIB19 but for future generations it may be provided in another SIB or in a different way). The satellite assistance information may include, for example, information identifying at least one associated NTN configuration (e.g., as part of an NTN-Config IE or the like). The NTN configuration includes parameters for assisting the UE 3 to access the network using NTN access (e.g., ephemeris data, common timing alignment parameters, a scheduling (e.g., k_offset), validity duration for uplink synchronisation information, and an epoch time (a reference time for which assistance information is valid)).

　　< NTN RAN Architecture >
　　Fig. 8A, Fig. 8B, and Fig. 8C each respectively illustrate a possible architecture of an NTN RAN 5 that may be used.

　　The architecture of Fig. 8A may be referred to as a 'transparent satellite' based RAN architecture. In this architecture, the base station 5A is a terrestrially located base station that sends and receives communications respectively destined for and originating from the UEs 3 via a terrestrially located gateway 5B and via a non-terrestrial (space or air borne) platform 5C that has no base station functionality. The non-terrestrial (space or air borne) platform 5C relays these communications to and from the UEs 3 in each cell operated by the base station 5A, and from and to the gateway 5B as required. The non-terrestrial (space or air borne) platform 5C relays these communications transparently without on-board processing them in effect acting as a so-called 'bent-pipe'. In this implementation, the feeder link between the gateway 5B and the non-terrestrial (space or air borne) platform 5C effectively acts as part of the respective Uu interface (or reference point) between the base station 5A and each UE 3. Similarly, the respective service link between the non-terrestrial (space or air borne) platform 5C and each UE 3 effectively acts as another part of the respective Uu interface (or reference point) between the base station 5A and each UE 3. The base station's communication link with the core network 7 (e.g. for signalling over the N1, N2, N3 interface/reference point etc.) is provided solely terrestrially.

　　The architecture of Fig. 8B may be referred to as a 'regenerative satellite' based RAN architecture (i.e., in which the satellite performs on board processing of the payload being communicated between the UE 3 and the core network 7). In this architecture, the base station 5A is a base station 5A of a distributed type having a terrestrially located central unit (CU) 5A_CU and a distributed unit (DU) 5A_DU provided on-board the non-terrestrial (space or air borne) platform 5C. The terrestrially located CU 5A_CU performs some of the (typically higher layer) functionality of the base station 5A whereas the non-terrestrially located DU 5A_DU performs other (typically lower layer) functionality of the base station 5A. The terrestrially located CU 5A_CU communicates with the non-terrestrially located DU 5A_DU via the gateway 5B and an F1 interface implemented via a satellite radio interface between the gateway 5B and the non-terrestrial (space or air borne) platform 5C in which the DU 5A_DU is provided.

　　The non-terrestrial (space or air borne) platform 5C transmits communications destined for and originating from the UEs 3 in each cell 9 operated by the base station 5A, and from and to the gateway 5B as required. However, in this implementation lower layer processing of communication respectively destined for and originating from the UEs 3 is performed on-board the non-terrestrial (space or air borne) platform 5C by the DU 5A_DU and higher layer processing of that communication respectively destined for and originating from the UEs 3 is performed by the terrestrially located CU 5A_CU.

　　Accordingly, in this implementation, the feeder link between the gateway 5B and the non-terrestrial (space or air borne) platform 5C effectively acts as the F1 interface (or reference point) between the CU 5A_CU and DU 5A_DU of the base station 5A. The respective service link between the non-terrestrial (space or air borne) platform 5C and each UE 3, on the other hand, effectively acts as the respective Uu interface (or reference point) between the base station 5A and each UE 3. The base station's communication link with the core network 7 (e.g. for signalling over the N1, N2, N3 interface/reference point etc.) is provided solely terrestrially.

　　The architecture of Fig. 8C may also be referred to as a 'regenerative satellite' based RAN architecture (i.e., in which the satellite performs on board processing of the payload being communicated between the UE 3 and the core network 7). In this architecture, the base station 5A is provided on-board the non-terrestrial (space or air borne) platform 5C. The base station 5A on board the non-terrestrial (space or air borne) platform 5C transmits communications destined for and originating from the UEs 3 in each cell 9 operated by the base station 5A, and from and to the core network 7 via the gateway 5B as required. However, in this implementation, processing of communication respectively destined for and originating from the UEs 3 is performed on-board the non-terrestrial platform 5C by the base station 5A.

　　Accordingly, in this implementation, the feeder link between the gateway 5B and the non-terrestrial (space or air borne) platform 5C effectively acts as part of the N1/N2/N3 interfaces (or reference points) between the base station 5A and the core network 7. The base station's communication link with the core network 7 (e.g. for signalling over the N1, N2, N3 interface/reference point etc.) is thus provided partly via the feeder link and partly terrestrially. The respective service link between the non-terrestrial (space or air borne) platform 5C and each UE 3, on the other hand, effectively acts as the respective Uu interface (or reference point) between the base station 5A and each UE 3.

　　The base station 5A thus controls one or more associated cells via the non-terrestrial (space or air borne) platform 5C. It will be appreciated that the base station 5A may be configured to support 4G, 5G, 6G and/or later generations, and/or any other 3GPP or non-3GPP communication protocols.

　　For the purposes of description, when implemented in the communication system 1, the NTN RAN 5 will be described in terms of the regenerative architecture illustrated in Fig. 8C. It will be appreciated, however, that the NTN RAN 5 could potentially use a different one of the architectures and the entities of the communication system 1 could be adapted accordingly.

　　< Enhanced Store and Forward Techniques based on CP CIoT EPS Optimisation >
　　Beneficially, for MO/MT data transmission without a full/end to end UE to CN/PDN connection (e.g., as result of discontinuous coverage / intermediate feeder link connection in the context of an NTN deployed RAN 5), the UE 3, base station 5A of the NTN RAN 5, and the communication entities of the core network 7 in the communication system 1 are mutually configured to implement one or more enhanced CP CIoT optimisation based features (i.e., where data encapsulated in (initial) NAS messages can be sent to a base station 5A via an RRC message without a UE context) to support improved store and forward techniques.

　　Specifically, effective "store and forward" data transmission is enabled by means of one or more enhancements to the MT/MO data transmission procedures (e.g., as described with reference to Figs. 5 and 6) in a "store and forward" mode cell 9.

　　These enhancements are described in more detail later with reference to control plane CIoT EPS optimisations but may be adapted appropriately based on CIoT 5GS optimisations (or similar).

　　In summary, the possible enhancements include:
　　Introduction of an allowed UE list and/or associated information/context kept at the base station 5A;
　　Enhanced cell access control in a "store and forward" mode cell based on a new information element in system information;
　　Paging enhancements including introduction of a new paging trigger at the MME 11 (or AMF for 5GS) and redefined handling of paging information/messages at the base station 5A;
　　Enhancement of the RRC connection setup procedure to confirm/indicate that the RRC connection setup procedure is for data/signalling transmission in accordance with a "store and forward" framework;
　　Introduction of the ability to include multiple (DL/UL) "NAS PDU" transmissions in a single S1-AP (or NG-AP for 5GS) transport message;
　　Introduction of the ability to include a respective downlink NAS PDU forward status for each of multiple downlink NAS PDUs over S1-AP (or NG-AP for 5GS), after re-connection to the MME (or AMF for 5GS);
　　Enhancement to the S1 setup procedure including introduction of a new indicator in the S1 setup procedure to support interoperability between the base station 5A and core network 7; and/or
　　Enhancement of the interaction between the access stratum (AS) and non-access stratum (NAS) layers of the UE 3.

　　It will be appreciated that any of these enhancements could potentially be introduced individually, without necessarily introducing all or any of the other enhancements, to provide benefits in terms of "store and forward" data transmission.

　　It will be appreciated that use of the CP CIoT based data "store and forward" enhancements described herein beneficially have the potential to allow a small amount of data to be transmitted without UE context and to support inter-base station mobility with relative ease, with minimal impact on existing procedures.

　　< Store and Forward Data Transmission - Overview >
　　A possible CP CIoT optimisation based store and forward data transmission flow will now be described, by way of example only, with reference to Figs. 9 and 10.

　　In Figs. 9 and 10, it will be appreciated that EDT could potentially be used (in a similar manner to that described with reference to Figs. 5 and 6) with the CP CIoT based method for only one data packet in one direction for transmission. Nevertheless, in the interests of simplicity, EDT has not been included in the message flows.

　　< Service link available / feeder link unavailable >
　　Fig. 9 is a simplified sequence diagram illustrating a CP CIoT optimisation based data transmission flow between a base station 5A of an NTN RAN 5, that may be used in the communication system 1, when a service link is available, but a feeder link is unavailable.

　　In Fig. 9, the procedure generally follows the relevant parts of the procedures illustrated in Fig. 5 (for MO case) and Fig. 6 (for the MT case) between the base station 5A and the UE 3 and the general description related to corresponding steps of those procedure also applies here.

　　In Fig. 9, the base station 5A stores/maintains, for each UE 3 that the base station 5A is serving (and possibly that has an associated UE capability, is in allowed list, and/or meets some other criterion) a respective UE specific buffer / data area 930. Each UE specific buffer / data area 930 includes a set of data type specific (sub)buffers /

data areas

932, 934, and 936. In this example the data type specific (sub)buffers /

data areas

932, 934, and 936, include: an uplink data buffer 932 for storing uplink data; a paging storage area 934 for storing paging information; and a downlink data buffer 936 for storing downlink. It will be appreciated, nevertheless, that the UE specific buffer / data area 930 may be configured to store a different set of information depending on requirements. Moreover, the UE specific buffer / data area 930 may be configured to additionally/alternatively store other data/information types such as, for example, UE context information. It will also be appreciated that while the UE specific buffer 930 is described as being 'logically' divided into the different (sub)buffers for clarity, in an implemented system such divisions into (sub)buffers may not be immediately apparent whilst still storing the same types of information.

　　In Fig. 9, at the start of the procedure it is assumed that the downlink data buffer 936 for the UE 3 is not empty as indicated at S920 (e.g., because the base station 5A has received downlink data, destined for the UE 3, encapsulated in one or more NAS PDUs provided from the core network 7 (via the MME 11) over the feeder link).

　　When the service link becomes available, for the MO case, the UE 3 initiates an RRC connection to the base station 5A. This typically involves for example, a random access procedure similar to that described with reference to Fig. 4 (e.g., in particular in respect of steps S414 to S420) in which the UE 3 sends a random access preamble (S901), receives a random access response (S902), sends a connection request (S903), and receiving an associated connection setup message (S904). The UE 3 then sends to the base station 5A, at S905, a message indicating that RRC connection setup has been completed. The UE 3 will transmit UL data to the base station 5A using NAS data PDUs. A UL NAS data PDU may, for example, be included in the connection setup complete message sent at S905, and/or in one or more UL information transfer messages (as seen at S907). In the example of Fig. 9, the base station 5A buffers each received UL NAS Data PDU in its UL data buffer 932, without triggering procedures towards the core network 7 (e.g., without triggering S1-AP procedures in this 4G/EPS example). The base station 5A may also forward any stored downlink data from the downlink data buffer 936 (in this example it is assumed that some downlink data has been stored previously). The downlink data is stored as one or more DL NAS data PDUs and is forwarded using one or more DL information transfer messages (as seen at S906).

　　When there is no more data to be transmitted or received by the base station 5A, the base station 5A can initiate a release of the RRC connection as seen at S908. This may, for example, be triggered if the UL/DL buffers are empty, there is no NAS PDU activity for a while, and the base station 5A detects inactivity and initiates a release procedure (in a similar manner to at S515 in Fig. 5, although in this case there may be no need to perform S1 release).

　　The procedure is similar when the service link becomes available for the MT case. However, for MT data transfer, in addition to one or more downlink NAS data PDUs previously received from an MME 11 having been buffered in the downlink data buffer 936 of the base station 5A, the base station 5A has corresponding paging information stored in the paging storage area 934. The base station 5A uses this paging information in order to page the UE 3 at S900, for example, at a time that the base station 5A has predicted the UE 3 will be in coverage, but that the UE 3 is not connected.

　　In response to the paging at S900, the UE 3 initiates an RRC connection to the base station 5A. This typically involves, for example, a random access procedure similar to that described with reference to Fig. 4 (e.g., in particular in respect of steps S414 to S420) in which the UE 3 sends a random access preamble (S901), receives a random access response (S902), sends a connection request (S903), and receiving an associated connection setup message (S904). The UE 3 then sends to the base station 5A, at S905, a message indicating that RRC connection setup has been completed. For this MT case (assuming the UE 3 has no UL data to transmit), after RRC connection establishment, the base station 5A forwards the buffered downlink NAS data PDUs to UE 3 using one or more DL information transfer messages (as seen at S906). The UE 3 may, of course, also send any uplink NAS data PDU to base station 5A using the connection setup complete message sent at S905 and/or one or more UL information transfer messages sent at S907.

　　When there is no more data to be transmitted or received by the base station 5A, the base station 5A can initiate a release of the RRC connection as seen at S908. This may, for example, be triggered if the UL/DL buffers are empty, there is no NAS PDU activity for a while, and the base station 5A detects inactivity (in a similar manner to at S514 in Fig. 5).

　　< Feeder link available / Service link unavailable >
　　Fig. 10 is a simplified sequence diagram illustrating a CIoT optimisation based data transmission flow between an NTN RAN 5 and the core network 7, that may be used in the communication system 1, when a feeder link is available, but a service link is unavailable.

　　In Fig. 10, the procedure generally follows the relevant parts of the procedures illustrated in Fig. 5 (for MO case) and Fig. 6 (for the MT case) between the NTN RAN 5 and the core network entities such as the MME 11, the S-GW 13, and the P-GW 15 and the general description related to corresponding steps of that procedure also applies here. It will be appreciated that the procedures of Fig. 9 and Fig. 10 are not mutually exclusive and may be used in conjunction with one another in the communication system 1 depending on the service link / feeder link status.

　　In Fig. 10, the base station 5A stores/maintains, for each UE 3 that the base station 5A is serving (and possibly that has an associated UE capability, is in allowed list, and/or meets some other criterion) the respective UE specific buffer / data area 930 described with reference to Fig .9. Specifically, each UE specific buffer / data area 930 includes: an uplink data buffer 932 for storing uplink data; a paging storage area 934 for storing paging information; and a downlink data buffer 936 for storing downlink. It will be appreciated, nevertheless, that the UE specific buffer / data area 930 may be configured to store a different set of information depending on requirements. Moreover, the UE specific buffer / data area 930 may be configured to additionally/alternatively store other data/information types such as, for example, UE context information. It will also be appreciated that while the UE specific buffer 930 is described as being 'logically' divided into the different (sub)buffers for clarity, in an implemented system such divisions into (sub)buffers may not be immediately apparent whilst still storing the same types of information.

　　In Fig. 10, at the start of the procedure the UE 3 is in an idle mode/state (in this example an EPS connection management (ECM) or 'ECM-IDLE' mode/state in which the UE 3 does not have a signalling connection to the MME 11) as seen at S1000.

　　When feeder link becomes available, for the MO case, the procedure generally follows the procedure from S1004 to S1012 (which is similar, but not identical, to the procedure from step S502 to step S515 described with reference to Fig. 5).

　　Assuming that there is UL data in the UL data buffer 932 of the base station 5A for the UE 3, the base station 5A sends, at S1004, an S1-AP initial UE message to the MME 11 (e.g., corresponding to step S502 of Fig. 5) and UE-associated logical S1-connection establishment is initiated as part of the procedure. As shown, and UL NAS data PDU from the UL data buffer 932 can be included in the initial UE message.

　　At S1005, the MME 11 checks the integrity of the incoming NAS PDU and decrypts the data it contains. At S1006, the MME 11 may coordinate with the S-GW 13 (and indirectly the P-GW 15), if necessary, to perform a modify bearer procedure (e.g., with the MME 11, S-GW 13, and P-GW 15, following the general modify bearer procedure described with reference steps S504 to S507 of Fig. 5).

　　Hence, the UL data may be forwarded to the S-GW 13 at S1020 (e.g., as described with reference step S508 of Fig. 5).

　　If there is incoming data in the downlink from the S-GW 13, at the same time (as indicated at S1021), the MME 11 may, beneficially, also send the data on to base station 5A (as indicated at S1008), to be stored in the downlink data buffer 936 (possibly following any necessary encryption and integrity protection of the DL data as indicated S1007). Any downlink data sent at S1008 may be encapsulated in a NAS PDU and sent to the base station 5A in one or more DL NAS transport messages, e.g., in one or more S1-AP downlink NAS transport messages (e.g., as described with reference to step S511 in Fig. 5). The MME 11 may also send (as indicated at S1003a) appropriate paging information to the base station 5A, for storage in the paging buffer 932, for potential subsequent use for paging the UE 3 later (i.e., when UE 3 is in - or is expected to be in - coverage). This paging information may be sent at the same time as sending the downlink data (but may be sent before or after).

　　Any further uplink data in the UL data buffer may, beneficially, be sent by the base station 5A to the MME 11 in one or more UL NAS transport messages, e.g., in one or more S1-AP uplink NAS transport messages (as indicated at S1009) for forwarding to the S-GW 13. This UL communication may occur in parallel with the communication of any DL data described above (but may occur before or after).

　　When there is no more data to be transmitted or received by the base station 5A, the base station 5A can initiate an S1 release procedure, e.g., by sending an S1-AP UE context release request as seen at S1010. This may, for example, be triggered if the UL/DL buffers are empty, there is no NAS PDU activity for a while, and the base station 5A detects inactivity (in a similar manner to at S514 in Fig. 5). The S1 release procedure may, for example, proceed with the MME 11 sending an S1-AP UE context release command to the base station 5A, at S1011, and the base station 5A responding with an S1-AP UE context release complete message to indicate that S1 release is completed.

　　When feeder link becomes available, for the MT case, the procedure generally follows a procedure that is similar, but is not identical, to the procedure described with reference to Fig. 6.

　　At S1001, the S-GW 13 having received, from a P-GW 15, a DL data packet for the UE 3 (e.g., as described for step S601 of the procedure of Fig. 6), may send a downlink data notification message to the MME 11 for which it has control plane connectivity for the given UE 3 (e.g., as described for step S602a of the procedure of Fig. 6). Although not shown the MME 11, may respond to the S-GW 13 with a downlink data notification acknowledgement message (e.g., as described for step S602b of the procedure of Fig. 6).

　　At S1002, the MME 11 determines which base station 5A, the UE 3 will (next) be in coverage of. Then, at S1003, the MME 11 sends associated paging information to the base station 5A. It will be appreciated that this paging does not trigger paging over the air (Uu) interface in the normal manner. Instead, this triggers the base station 5A to initiate the establishment of a UE-associated logical connection by sending the initial UE message over S1-AP (as seen at S1004). The base station 5A also stores the paging information received from MME 11 in the paging buffer 932 for potential subsequent use for paging the UE 3 later for downlink data forwarding over the air interface/service link when available.

　　If there is UL data in the UL data buffer 932 of the base station 5A for the UE 3, the base station 5A may include an associated UL NAS data PDU in the initial UE message sent at S1004.

　　At S1005, the MME 11 checks the integrity of any incoming UL NAS data PDU and decrypts the data it contains. At S1006, the MME 11 may coordinate with the S-GW 13 (and indirectly the P-GW 15), if necessary, to perform a modify bearer procedure (e.g., with the MME 11, S-GW 13, and P-GW 15, following the general modify bearer procedure described with reference steps S607 to S610 of Fig. 6). Hence, any UL data may be forwarded to the S-GW 13 at S1020.

　　Any incoming data in the downlink from the S-GW 13 may be sent, by the MME 11, on to base station 5A (as indicated at S1008), to be stored in the downlink data buffer 936 (possibly following any necessary encryption and integrity protection of the DL data as indicated S1007). Any downlink data sent at S1008 may be encapsulated in a NAS PDU and sent to the base station 5A in one or more DL NAS transport messages, e.g., in one or more S1-AP downlink NAS transport messages (e.g., as described with reference to step S613 in Fig. 6).

　　When there is no more data to be transmitted or received by the base station 5A, the base station 5A can initiate an S1 release procedure, e.g., by sending an S1-AP UE context release request as seen at S1010. This may, for example, be triggered if the UL/DL buffers are empty, there is no NAS PDU activity for a while, and the base station 5A detects inactivity (in a similar manner to at S620 in Fig. 6). The S1 release procedure may, for example, proceed with the MME 11 sending an S1-AP UE context release command to the base station 5A, at S1011, and the base station 5A responding with an S1-AP UE context release complete message to indicate that S1 release is completed.

　　< Allowed UE List and Associated Information/Context >
　　As mentioned above, an allowed UE list and/or associated information/context for each UE 3 may also be maintained at the base station 5A (e.g., during a procedure similar to that described with reference to Fig. 9 and/or 10).

　　This contrasts with existing communication systems in which UE context is not available (or considered necessary) at the base station 5A when the corresponding UE 3 is in an RRC-idle mode, and the UE 3 is able to establish an RRC connection and, at the same time, transmit at least one NAS data PDU to the base station 5A.

　　However，for a "store and forward" scenario, an RRC connection and UE-associated logical S1-connection will not exist at the same time, and so the base station 5A cannot obtain the necessary UE information from the MME 11 at the time the UE 3 becomes RRC connected (e.g., for the purposes of access admission, to determine a proper RRC configuration, to execute data rate control, and/or the like).

　　Accordingly, in one beneficial example, the base station 5A is configured to store/maintain a list of allowed UEs 3, and for each allowed UE information indicating one or more of the following: a UE identity (e.g., a serving temporary mobile subscriber identity (S-TMSI)); one or more UE level QoS parameters (e.g., maximum data rate and/or number of NAS PDUs); a priority; a basic capability; and/or paging information.

　　The base station 5A will store this UE information for each UE 3 in the allowed UE list, even if the corresponding UE 3 is in RRC-idle mode, for later use. The stored information may, for example, be used for one or more of the following: performing access admission; prioritising and/or deprioritising a UE's RRC connection request, paging, and/or data transmission; controlling a maximum amount of data that can be sent to/from and/or stored at a base station 5A for a certain UE 3; and/or calculating paging occasions.

　　It will be appreciated that alternatively or additionally, the base station 5A may maintain an unallowed UE list correspondingly.

　　In order to obtain this information, the MME 11 may compile a list of access/service allowed UEs 3 based on: history information; operations, administration, and management (OAM) information, registration data, predictions, and/or UEs 3 that have downlink data stored in a base station and/or MME buffer. The MME 11 may then send this list of allowed UEs 3, with their identification information (and possibly further information) to the base station 5A, regardless the RRC states of the listed UEs 3.

　　Alternatively or additionally, some or all of the information may be obtained via a dedicated, UE triggered "store and forward" access request procedure as follows:
1.　　A UE 3 initially initiates an RRC connection to a "store and forward" mode cell;
2.　　If the UE 3 is not in an access allowed UE list stored at the base station 5A, the base station 5A may: a) release/reject the UE connection request and inform the UE 3 that it is "waiting for identification /authentication for more data store and forward"; and/or b) allow a limited amount of NAS PDUs transmission from that UE 3;
3.　　When a feeder link become available, the base station 5A requests the core network 7 (e.g., via the MME 11) to authorise whether the UE 3 is allowed/authorised to use the store and forward service;
4.　　The core network 7 responds with further necessary UE information if that UE 3 is allowed/authorised; and
5.　　If the UE 3 is authorised/allowed by the core network 7, then the base station 5A adds the UE 3 into the access allowed UE list (in association with any corresponding information obtained in the procedure).

　　Afterward this procedure, the UE 3 is therefore able to access the "store and forward" cell for data transmission services when the UE 3 is in coverage.

　　It will be appreciated that the UE 3 may also, optionally, maintain a list of base stations 5A and/or cells 9 that have a "store and forward "mode (e.g., that the UE 3 has previously accessed) and prioritise these cells 9 for future data transmissions.

　　< Cell Access Control >
　　As mentioned above, the communication system 1 may implement an enhanced cell access control in a "store and forward" mode cell based on a new information element provided in system information in that cell 9. This will now be described in more detail by way of example only.

　　In more detail, a base station 5A that operates a cell in "store and forward" mode may be configured to: bar legacy UEs 3 (that cannot use / do not support store and forward data transmission); allow a UE 3 that supports store and forward data transmission to camp on and/or access the "store and forward" mode cell; and/or not allow a (non-legacy) UE 3 that is incapable of store and forward transmission to camp on and/or access the store and forward" mode cell.

　　To achieve this, a new "store-forward mode" (or similar) indicator is introduced into system information (e.g., system information block type 1 (SIB1) or the like) that is broadcast in the "store and forward" mode cell and set a "legacy bar bit" in the system information to indicate barring.

　　As a result any legacy UE 3 will be barred from accessing the cell 9. A non-legacy UE 3 that supports, and wishes to use, a "store and forward" feature, will ignore this legacy bar bit, but will check for the "store-forward" indicator, for determining whether to camp on a particular cell 9 and/or whether to initiate the access to a cell 9.

　　In the event that a feeder link connection becomes available temporarily in a "store and forward" capable cell 9 in which the "store-forward mode" indicator is currently set to indicate the cell is operated in the "store-forward mode" (e.g., to 'true' or '1'), the base station 5A may be configured to set the "store-forward mode" indicator to indicate that the cell 9 is not operated in the "store-forward mode" (e.g., to 'false' or '1').

　　Nevertheless, it will be appreciated that, alternatively, the "store-forward mode" indicator may be maintained as indicating that the cell 9 is operated in the "store-forward mode" (e.g., kept as 'true' or '1'). In this case, the base station 5A may broadcast a time when (or a time window for which) the feeder link will be available temporarily to inform UEs 3 when/how long the feeder link will be available. The base station 5A may indicate the time (time window) when the feeder link will be available in system information (e.g. SIB1), for example, the base station 5A may indicate a time window (T0 to T1) before or upon feeder link connection becoming available. It will be appreciated that the base station 5A may also indicate a list of times/time windows (e.g., plural [T0-T1] indications) to indicate multiple times/time windows when the feeder link connection will be available.

　　< Paging >
　　As mentioned above, the communication system 1 may implement one or more paging enhancements. A number of possible paging enhancements will now be described in more detail by way of example only.

　　Conventionally, paging is initiated by an MME 11 (or equivalent node) e.g., when a data notification is received, or data is buffered in the MME 11 (or equivalent node). The paging is received at a base station 5A and the base station 5A sends the paging over the air interface. The paging triggers the UE 3 to initiate an RRC connection and establishment of an S1-AP connection afterwards. MT data can then be transmitted to the UE 3.

　　Beneficially, for "store and forward" mode cells, the base station 5A of the communication system 1 (rather than the MME 11) initiates paging to the UE 3, when there is stored downlink data at base station 5A for that UE 3.

　　To support this the base station 5A is provided with paging relevant information by the MME 11 (e.g., as described, with reference to Figs. 9 and 10). This paging information may include, for example, an identity and discontinuous reception (DRX) for paging occasion calculation. This paging information is stored at the base station 5A (e.g., in the paging storage area 934) so that the base station 5A can initiate paging to the UE 3 at an appropriate time.

　　There are a number of different ways that the base station 5A may be informed of the paging relevant information. For example, the paging relevant information may be provided as part of a UE context that is stored at the base station 5A (e.g., as described above in the section titled "Allowed UE List and Associated Information/Context").

　　Alternatively, or additionally, the paging relevant information may be provided as part of a conventional paging message sent over the S1-AP interface, for example, when a downlink data/data notification is received at MME 11 and the feeder link has become available to the base station 5A to which the MME 11 intends to send the downlink data for "store and forward" data transmission (e.g., as described with reference to Fig. 10). The "paging "message can be sent to the base station 5A, and this can be followed by an "S1-AP" UE initial message (e.g., as described with reference to steps S1003 and S1004 in Fig. 10).

　　Alternatively or additionally, a "paging message over S1-AP" may be triggered when any downlink data is available for sending to the base station 5A for store and forward data transmission. This paging message over S1-AP may be sent from the MME 11 together with or following the downlink data to transmitted to the base station 5A for store and forward (e.g., as described with reference to steps S1003a and S1008 in Fig. 10).

　　< RRC Connection Setup Procedure >
　　As mentioned above, the communication system 1 may implement an enhanced RRC connection setup procedure in which an indication is sent to the base station 5A to confirm/indicate that the RRC connection setup procedure (e.g., as described with reference to Fig. 9) is for data/signalling transmission in accordance with a "store and forward" framework.

　　Specifically, an indication may be included in the RRC connection setup complete message sent by the UE 3 at the end of RRC connection establishment to confirm/indicate that the RRC connection is for data/signalling transmissions in accordance with the "store and forward" framework (i.e., for store and forward data transmission).

　　An abstract syntax notation one (ASN.1) description of how this indication may be introduced in an RRC connection setup complete message is provided, purely for illustrative purposes, below:
　　(Conventional Information Elements)
　　attachWithoutPDN-Connectivity-r13　　ENUMERATED {true}
　　　　OPTIONAL,
　　up-CIoT-EPS-Optimisation-r13　　　　ENUMERATED {true}
　　　　OPTIONAL,
　　cp-CIoT-EPS-Optimisation-r13　　　　ENUMERATED {true}
　　　　OPTIONAL,
　　…
　　(New Information Elements)
　　attachWithoutPDN-ConnectivityNTN-r1x　　ENUMERATED {true}
　　　　OPTIONAL,
　　up-CIoT-EPS-OptimisationNTN-r1x　　ENUMERATED {true}
　　　　OPTIONAL,

　　< Multiple NAS PDUs Over S1-AP >
　　As mentioned above, the communication system 1 may implement the ability to include multiple (DL/UL) "NAS PDU" transmissions in a single S1-AP (or NG-AP for 5GS) transport message.

　　Specifically, in previous communication systems, messages that may be used for NAS PDU transport (including the initial UE message, the UL NAS transport message, and the DL NAS transport message) can only include a single NAS data PDU.

　　In this example, however, in which store and forward data transmission techniques are used, there may be multiple accumulated NAS data PDUs stored at the base station 5A for transmission in the uplink over the S1-AP interface, or at the MME 11 for transmission in the downlink over the S1-AP interface.

　　To support efficient communication of these NAS data PDUs over the S1-AP interface, therefore, in this exemplary enhancement, the base station 5A and MME 11 are able to encapsulate more than one NAS data PDU in each of the different S1-AP messages that may be used for NAS PDU transport (e.g., the initial UE message, the UL NAS transport message, and/or the DL NAS transport message) that the base station 5A / MME 11 is able to send.

　　< Multiple NAS PDU Delivery Status Reporting >
　　As mentioned above, the communication system 1 may implement the ability to include a respective downlink NAS PDU forward status for each of multiple downlink NAS PDUs over S1-AP (or NG-AP for 5GS), after re-connection to the MME 11 (or AMF for 5GS).

　　Specifically, the base station 5A is configured for providing delivery indication messages for indicating the delivery/non-delivery status of a NAS PDU received over the S1-AP interface (e.g., in a DL NAS transport message as described earlier and, in particular, with reference to Figs. 9 and 10). These messages include:
　　The NAS non delivery indication message:
　　　　This message is sent by the base station 5A and is used for reporting the non-delivery of a NAS PDU previously received within a downlink NAS transport message over the S1 interface.
　　The NAS delivery indication message:
　　　　This message is sent by the base station 5A and is used for reporting the successful delivery, to the UE 3, of a NAS PDU that was previously received within a downlink NAS transport message.

　　In earlier communication system 1 these messages can only be used to indicate if the previously received NAS PDU has been delivered or not. However, in a "store and forward" scenario, it is not possible to indicate the delivery status of a downlink NAS PDU over the Uu interface immediately following receipt of that NAS PDU from MME 11. Moreover, in the context of store and forward data transmission, it is not efficient to indicate only a single NAS PDU delivery status.

　　In this exemplary enhancement, therefore, the base station 5A is configured to be able to send a dedicated S1-AP message (e.g., a "downlink NAS forward status report" message or the like) for reporting the forwarding (delivery) status of multiple downlink NAS PDUs.

　　This message may include, for example, each NAS PDU (of one or more NAS PDUs) that was not successfully delivered (it will be appreciated that, implicitly, this means a NAS PDU which is not included was forwarded successfully to the UE 3).

　　Nevertheless, it will be appreciated that the NAS PDUs may be indexed, by the MME 11, when they are sent to the base station 5A, and the base station 5A may explicitly indicate which PDUs were successfully forwarded and/or which PDUs were not successfully forwarded. It will be appreciated here that the message indicates this information in any suitable way, for example: by including a list of indexes of the PDUs were successfully and/or unsuccessfully forwarded; by means of a bit map with each bit representing a corresponding PDU (e.g., '1' indicates successful forwarding and '0' indicates unsuccessful forwarding or vice versa); or in some other way.

　　It will be appreciated that, alternatively or additionally, the S1-AP NAS non delivery indication and NAS delivery indication messages may be enhanced to allow indication, to the MME 11, of the forward status of one or more downlink NAS PDUs, which were received from MME 11 when the feeder link was previously available.

　　< Exemplary Implementation >
　　An exemplary implementation involving some of the enhancements described above will now be described by way of example only with reference to Fig. 11, which is a simplified sequence diagram illustrating how parts of the procedures shown in Figs. 9 and 10 may be enhanced.

　　Specifically, as in Fig. 10, in Fig. 11 the base station 5A stores/maintains, for each UE 3 that the base station 5A is serving (and possibly that has an associated UE capability, is in allowed list, and/or meets some other criterion) the respective UE specific buffer / data area 930 described with reference to Fig .9. Specifically, each UE specific buffer / data area 930 includes: an uplink data buffer 932 for storing uplink data; a paging storage area 934 for storing paging information; and a downlink data buffer 936 for storing downlink. Fig. 11 illustrates, however, how the UE specific buffer / data area 930 may (optionally) also store 'offline' UE context information 938.

　　As in Fig. 10, in Fig. 11, at the start of the procedure the UE 3 is in an idle mode/state (in this example an EPS connection management (ECM) or 'ECM-IDLE' mode/state in which the UE 3 does not have a signalling connection to the MME 11) as seen at S1100.

　　It will be appreciated that in box (A) of Fig. 11, the feeder link is available, the service link is not available, and the general procedure described in Fig. 10 may followed. However, as described above in the section titled "Multiple NAS PDUs Over S1-AP", when uplink NAS data PDUs are forwarded to the MME 11 over the S1-AP interface multiple NAS data PDUs may be forwarded in a single S1-AP message (e.g., as a list of UL NAS data PDUs) if more than one such NAS PDU is present in the uplink data buffer 932 (as seen at S1102). Similarly, when downlink NAS data PDUs are forwarded to the base station 5A over the S1-AP interface multiple NAS data PDUs may be forwarded in a single S1-AP message (e.g., as a list of DL NAS data PDUs) if more than one such NAS PDU require forwarding (as seen at S1104).

　　When there is no more data to be transmitted or received by the base station 5A, a UE context release procedure may be performed over the S1-AP interface (e.g., as described with reference to S1010 to S1012 in Fig. 10).

　　In box (B) of Fig. 11, when the feeder link is not available but the service link is available, the base station 5A may page the UE 3 (e.g., based on paging information 934 stored in the UE buffer 930 , as described above in the section titled "Paging") in an attempt to get the UE 3 to initiate an RRC connection for receiving the downlink NAS data PDUs stored in the downlink data buffer 936 (e.g., as described with reference to Fig. 9). These downlink NAS data PDUs may, or may not, be forwarded successfully.

　　In box (C) of Fig. 11, when the feeder link becomes available again and the service link is not available, the base station 5A may report the forwarding (delivery) status of multiple downlink NAS PDUs (e.g., in a downlink NAS PDUs forward status report), e.g., as described above in the section titled "Multiple NAS PDU Delivery Status Reporting").

　　< S1 Setup Procedure >
　　As mentioned above, the communication system 1 may implement enhancements to the S1 setup procedure. The purpose of the S1 setup procedure is to exchange application level data needed for the base station 5A and the MME 11 to correctly interoperate on the S1 interface. The S1 procedure is the first S1-AP procedure triggered after a transport network layer (TNL) association has become operational. The procedure uses non-UE associated signalling.

　　In more detail, in this exemplary enhancement, the base station 5A and the MME 11 are mutually configured for performing an enhanced S1 Setup procedure, e.g., for use after a feeder link has become available but before any UE associated signalling has happened. Specifically, to ensure support for a multi-vendor network (RAN 5 and core network 7), the enhanced S1 Setup procedure allows for the inclusion of an indication of network capability/support for store and forward data transmission in at least one of the messages used during the S1 setup procedure.

　　This will now be described in more detail, by way of example only, with reference to Fig. 12, which is a simplified sequence diagram illustrating an S1 setup procedure.

　　As seen at S1200, in one option, an S1 setup request includes an information element to indicate capability/support for store and forward data transmission. For example, the information element may indicate support for "Store-forward mode", "Discontinuous feeder link", "Intermittent NTN connection", "Non-contiguous S1 connection for NTN", and/or the like. The information element may be an enumerated type indicating, for example, 'true' or 'false' for the capability/support. If the feature is supported at the MME 11, then the MME 11 may respond with a normal S1 setup response message (as seen at S1202a). If the feature is not supported at the MME 11, then the MME 11 may respond with an S1 setup failure message (as seen at S1202b).

　　As seen at S1210, in another option, a normal S1 setup request is sent, and the MME 11 may respond with an S1 setup response message (as seen at S1212) includes an information element to indicate a capability/support for store and forward data transmission. For example, the information element may indicate support for "Store-forward mode", "Discontinuous feeder link", "Intermittent NTN connection", "Non-contiguous S1 connection for NTN", and/or the like. The information element may be an enumerated type indicating, for example, 'true' or 'false' for the capability/support.

　　< UE AS/NAS Interaction >
　　As mentioned above, the communication system 1 may implement enhancements to the interaction between the access stratum (AS) and non-access stratum (NAS) layers of the UE 3.

　　For example, in one option, when the UE 3 receives an RRC release message from the base station 5A, the UE's NAS layer may enter an idle mode/state (e.g., ECM idle). To facilitate this, the RRC release message may include an appropriate cause value (e.g., nas-Release, s1-Release, ntn-NoS1-Connection, ntn-FeederlinkNotAvailable, and/or the like). The UE's AS layer forwards this RRC release cause to the UE's NAS layer and, in response, the UE's NAS layer will locally terminate the procedure (and enter ECM idle).

　　Alternatively or additionally, in another option, when the UE 3 receives an RRC release message from the base station 5A, the UE's NAS layer may remain in a connected mode/state (e.g., ECM connected). To facilitate this, the RRC release message may include an appropriate cause value (e.g., e.g. pendingNas-ConnectionRelease, pendingS1-Release, ntn-NoS1-Connection, ntn-FeederlinkNotAvailable, and/or the like). The UE's AS layer forwards this RRC release cause to the UE's NAS layer. In response, the UE's NAS layer stays in ECM connected (instead of entering ECM idle). Following this, the UE's NAS layer may locally terminate the procedure (and enter ECM idle) after a timer has expired. Alternatively or additionally, the MME 11 may send (via the base station 5A) the necessary information for S1 release to the UE's NAS layer and the UE's NAS layer can then move to ECM idle.

　　< User Equipment >
　　Fig. 13 is a simplified block schematic illustrating the main components of a UE 3 for implementation in the system of Fig. 3.

　　As shown, the UE 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a base station 5A via one or more air interface 33 (e.g., comprising one or more antenna elements). The UE 3 has a controller 37 to control the operation of the UE 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily required for its operation, the UE 3 might, of course, have all the usual functionality of a conventional UE 3 (e.g., a user interface 35, such as a touch screen / keypad / microphone / speaker and/or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 39 and/or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

　　The controller 37 is configured to control overall operation of the UE 3 by, in this example, program instructions or software instructions stored within memory 39. As shown, these software instructions include, among other things, an operating system 41, and a communications control module 43.

　　The communications control module 43 is operable to control the communication between the UE 3 and its serving base station 5A or base stations 5A (and other communication devices connected to the base station 5A, such as further UEs 3 and/or core network nodes). The communications control module 43 is configured for the overall handling of uplink communications via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), random access channel (RACH), and/or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communications control module 43 is also configured for the overall handling of receipt of downlink communications via associated downlink channels (e.g., of DCI via a physical downlink control channel (PDCCH) and/or a physical downlink shared channel (PDSCH)) including both dynamic and semi-persistent scheduling (e.g., SPS). The communications control module 43 is responsible, for example: for determining where to monitor for downlink control information; for determining the resources to be used by the UE 3 for transmission/reception of UL/DL communications (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the UE 3 side; for determining how slots/symbols are configured (e.g., for UL, DL or full duplex communication, or the like); for determining which bandwidth parts are configured for the UE 3; for determining how uplink transmissions should be encoded and the like.

　　It will be appreciated that the communications control module 43 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communications control module 43 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc.

　　The communications control module 43 is configured, in particular, to control the UE's communications, in accordance with any of the methods described herein.

　　< Base Station >
　　Fig. 14 is a simplified block schematic illustrating the main components of a base station 5A for implementation in the system of Fig. 3 (e.g. in an NTN access network or other such RAN 5).

　　As shown, the base station 5A has a transceiver circuit 51 for transmitting signals to and for receiving signals from the communication devices (such as UEs 3) via one or more air interface 53 (e.g., a single or multi-panel antenna array / massive antenna), and a core network interface 55 for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the base station 5A may also be coupled to other base stations 5A via an appropriate interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR). The base station 5A has a controller 57 to control the operation of the base station 5A. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 and/or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the base station 5A by, in this example, program instructions or software instructions stored within memory 59.

　　As shown, these software instructions include, among other things, an operating system 61 and a communications control module 63.

　　The communications control module 63 is operable to control the communication between the base station 5A and UEs 3 and other network entities (e.g., core network nodes) that communicate with the base station 5A. The communications control module 63 is configured for the overall control of the reception and decoding of uplink communications, via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), a random-access channel (RACH), and/or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communications control module 63 is also configured for the overall control of the transmission of downlink communications via associated downlink channels (e.g., via a physical downlink control channel (PDCCH) and/or a physical downlink shared channel (PDSCH)) including both dynamic and semi-persistent scheduling (e.g., SPS). The communications control module 63 is responsible, for example: for determining where to configure the UE 3 to monitor for downlink control information (e.g., the location of search spaces, CORESETs, and associated PDCCH candidates to monitor); for determining the resources to be scheduled for UE 3 transmission/reception of UL/DL communications (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the base station 5A side; for configuring slots/symbols appropriately (e.g., for UL, DL or full duplex communication, or the like); for configuring bandwidth parts for the UE 3; for providing related configuration signalling to the UE 3; and the like.

　　It will be appreciated that the communications control module 63 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communications control module 63 may include, for communicating with a UE 3, a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc. Moreover, the communications control module 63 may include, for communicating with a core network entity such as an MME 11 (or similar node such as an AMF), an S1 application protocol (S1-AP) sub-module, a stream control transmission protocol (SCTP) sub-module, an IP sub-module, a layer 1 (L1) sub-module, a layer 2 (L2) sub-module, etc (or corresponding sub-modules for communicating with an AMF).

　　The communications control module 63 is configured in particular, to control the base station's communications, in accordance with any of the methods described herein.

　　< Core Network Node / Function >
　　Fig. 15 is a block diagram illustrating the main components of a core network node or function, such as the MME 11, S-GW 13, or P-GW 15 (or functionally similar node/function of 5G or other cellular technology such as an AMF, CPF, UPF, SMF etc.).

　　As shown, the core network function includes a transceiver circuit 71 which is operable to transmit signals to and to receive signals from other nodes (including the UE 3, the base station 5A, and other core network nodes) via a network interface 72. A controller 73 controls the operation of the core network function in accordance with software stored in a memory 74. The software may be pre-installed in the memory 74 and/or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 75, and a communications control module 76.

　　The communications control module 76 is responsible for handling (generating/sending/ receiving) signalling between the core network function and other nodes, such as the UE 3, the base station 5A, and other core network nodes.

　　It will be appreciated that the communications control module 76 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, where the core network node is implemented as an MME 11 (or AMF for 5G), the communications control module 76 may include, for communicating with the base station 5A, an S1-AP sub-module, an SCTP sub-module, an IP sub-module, an L1 sub-module, an L2 sub-module, etc (or corresponding sub-modules for an AMF).

　　The communications control module 76 is configured in particular, to control the core network node's communications, in accordance with any of the methods described herein.

　　< Modifications and Alternatives >
　　Detailed examples been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above examples whilst still benefiting from the disclosures embodied therein.

　　It will be appreciated that description of features of and actions performed by a base station 5A (or eNB or gNB), NTN nodes, and UEs 3 may be applied equally to base stations 5A and UEs 3 that communicate in the terrestrial plane only (i.e. as part of a terrestrial RAN 5 without features of an NTN RAN 5 such as a gateway 5B and space or airborne platform) as to base stations 5A that communicate via a non-terrestrial plane.

　　Moreover, description of features of and actions performed by a base station 5A (or eNB or gNB), apply equally to distributed type base stations 5A as to non-distributed type base stations.

　　It will also be appreciated that whilst information elements having specific names have been described differently named information elements but having a similar purpose may be used.

　　In the above description the UE 3 and the base station 5A are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the disclosure, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.

　　In the above examples, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the UE 3 or base station 5A as a signal over a computer network, or on a recording medium. Further, the functionality performed by part, or all, of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the UE 3 or the base station 5A in order to update their functionalities.

　　Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input/output (IO) circuits; internal memories / caches (program and/or data); processing registers; communication buses (e.g. control, data and/or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and/or timers; and/or the like. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

　　The User Equipment (or "UE", "mobile station", "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface.

　　It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.

　　The terms "User Equipment" or "UE" (as the term is used by 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with one another, and include standalone mobile stations, such as terminals, cell phones, smart phones, tablets, cellular IoT devices, IoT devices, and machinery. It will be appreciated that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for an extended period of time.

　　A UE may, for example, be an item of equipment for production or manufacture and/or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and/or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and/or their application systems; tools; moulds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and/or related machinery; paper converting machinery; chemical machinery; mining and/or construction machinery and/or related equipment; machinery and/or implements for agriculture, forestry and/or fisheries; safety and/or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and/or application systems for any of the previously mentioned equipment or machinery etc.).

　　A UE may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motorcycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.).

　　A UE may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).

　　A UE may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and/or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).

　　A UE may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).

　　A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and/or system, a weapon, an item of cutlery, a hand tool, or the like.

　　A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).

　　A UE may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)", using a variety of wired and/or wireless communication technologies.

　　Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and/or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and/or inactive for an extended period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g. vehicles) or attached to animals or persons to be monitored/tracked.

　　It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communications network for sending/receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

　　It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be appreciated that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in the following table 1. This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.

　　　　

　　Table 1

　　Further, the above-described UE categories are merely examples of applications of the technical ideas and examples described in the present document. Needless to say, these technical ideas and examples are not limited to the above-described UE and various modifications can be made thereto.

　　Each feature disclosed in this specification (which term includes the claims) and/or shown in the drawings may be incorporated in the disclosure independently of (or in combination with) any other disclosed and/or illustrated features where it is technically feasible to do so. In particular but without limitation the features of any of the claims dependent from a particular independent claim may be introduced into that independent claim in any combination or individually wherever doing so does not cause a technically incompatibility or result in something that does not make technical sense.

　　Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

　　Although the present disclosure has been described with reference to the example embodiments, the present disclosure is not limited to the above. Various changes that can be understood by those skilled in the art can be made to the configuration and details of the present disclosure within the scope of the disclosure.

　　This application is based upon and claims the benefit of priority from UK patent application No. 2311347.5, filed on July 24, 2023, the disclosure of which is incorporated herein in its entirety by reference.

　　The program can be stored and provided to the computer device using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (Read Only Memory), CD-R, CD-R/W, and semiconductor memories (such as mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM (Random Access Memory), etc.). The program may be provided to the computer device using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to the computer device via a wired communication line, such as electric wires and optical fibers, or a wireless communication line.

　　For example, the whole or part of the example embodiments disclosed above can be described as, but not limited to, the following supplementary notes.
(Supplementary note 1)
　　A method performed by an access network node in a non-terrestrial network, the method comprising:
　　receiving, via an available link, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable, without triggering of establishing a connection for another link than the available link;
　　storing the at least one NAS PDU until the another link becomes available; and
　　forwarding, via the another link, the at least one NAS PDU when the another link becomes available.
(Supplementary note 2)
　　The method according to Supplementary note 1, wherein
　　the receiving is performed using Control Plane CIoT optimization feature or Early Data Transmission, EDT.
(Supplementary note 3)
　　The method according to Supplementary note 1, wherein
　　the forwarding is performed using Control Plane CIoT optimization feature or Early Data Transmission, EDT.
(Supplementary note 4)
　　The method according to any one of Supplementary notes 1 to 3, further comprising:
　　maintaining UE information for at least one UE which is allowed by a core network coupled with the gateway, in a case where either the service link or the feeder link is unavailable.
(Supplementary note 5)
　　The method according to Supplementary note 4, wherein
　　the UE information includes at least one of:
　　　　UE identity;
　　　　at least one Quality of Service, QoS, parameter;
　　　　priority information;
　　　　capability information; or
　　　　paging information.
(Supplementary note 6)
　　The method according to Supplementary note 4 or 5, wherein
　　the UE information is determined based on at least one of:
　　　　history information,
　　　　Operations and Management, OAM, data,
　　　　registration data,
　　　　prediction, or
　　　　at least one UE which has downlink data in a buffer of the access network node or the core network.
(Supplementary note 7)
　　The method according to any one of Supplementary notes 4 to 6, further comprising:
　　receiving, from the core network, the UE information regardless of a Radio Resource Control, RRC, state of the UE.
(Supplementary note 8)
　　The method according to any one of Supplementary notes 4 to 6, further comprising:
　　receiving, from the UE, a message for establishing a connection to the access network node;
　　transmitting, to the core network, a request for authorizing whether the UE can be allowed; and
　　receiving, from the core network, the UE information in a case where the core network has authorized that the UE is allowed.
(Supplementary note 9)
　　The method according to any one of Supplementary notes 1 to 8, further comprising:
　　receiving, via the feeder link, paging information used for the forwarding at least one NAS PDU to the UE via the service link; and
　　paging the UE using the paging information in a case where the service link becomes available.
(Supplementary note 10)
　　The method according to Supplementary note 9, wherein
　　the paging information is included in at least one of:
　　　　a paging message from a core network, or
　　　　UE information from the core network.
(Supplementary note 11)
　　The method according to any one of Supplementary notes 1 to 10, wherein
　　the at least one NAS PDU is included in a signaling message.
(Supplementary note 12)
　　The method according to any one of Supplementary notes 1 to 11, further comprising:
　　transmitting, via the feeder link to a core network, message for informing a status of the forwarding the at least one NAS PDU which is received from the core network node while the feeder link was previously available.
(Supplementary note 13)
　　The method according to Supplementary note 12, wherein
　　the message includes information indicating at least one NAS PDU which was not delivered.
(Supplementary note 14)
　　A method performed by an access network node in a non-terrestrial network, the method comprising:
　　transmitting, via system information, information indicating a mode of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable, and
　　wherein the information causes at least one UE which does not support the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable, not to camp on a serving cell of the access network node.
(Supplementary note 15)
　　The method according to Supplementary note 14, wherein
　　the information is updated based on whether the feeder link is available or not.
(Supplementary note 16)
　　The method according to Supplementary note 14, wherein
　　the information includes time information indicating a time window when the feeder link will be available temporarily for enabling, and
　　the at least one UE which does not support the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable to camp on the serving cell of the access network node during the time window.
(Supplementary note 17)
　　The method according to any one of Supplementary notes 14 to 16, further comprising:
　　receiving, from the UE, support information indicating that the UE supports the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable.
(Supplementary note 18)
　　The method according to Supplementary note 17, wherein
　　the support information is included in a Radio Resource Control, RRC connection setup complete message.
(Supplementary note 19)
　　A method performed by an access network node in a non-terrestrial network, the method comprising:
　　transmitting, to a core network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable.
(Supplementary note 20)
　　A method performed by an access network node in a non-terrestrial network, the method comprising:
　　receiving, from a core network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable.
(Supplementary note 21)
　　The method according to any one of Supplementary notes 1 to 20, further comprising:
　　transmitting, to the UE, information indicating a Radio Resource Control, release cause in a case where the service link becomes unavailable, and wherein
　　the RRC release causes the UE to at least one of:
　　　　enter an Evolved Packet System, EPS, Connection Management, ECM idle state, or
　　　　stay an ECM-connected state.
(Supplementary note 22)
　　A method performed by a user equipment, UE, the method comprising:
　　transmitting, to an access network node in a non-terrestrial network via a service link between the access network node and the UE, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where a feeder link between the access network node and a gateway in a terrestrial network is unavailable, without triggering of establishing a connection for the feeder link, and wherein
　　the at least one NAS PDU is stored by the access network node until the feeder link becomes available, and
　　the at least one NAS PDU is forwarded via the feeder link when the feeder link becomes available.
(Supplementary note 23)
　　A method performed by a user equipment, UE, the method comprising:
　　receiving, via system information, information indicating a mode of storing and forwarding data in a case where either a service link between an access network node in a non-terrestrial network and the UE or a feeder link between the access network node and a gateway in a terrestrial network is unavailable; and
　　not camping on a serving cell of the access network node in a case where the UE does not support the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable.
(Supplementary note 24)
　　A method performed by a core network node, the method comprising:
　　receiving, from an access network node in a non-terrestrial network via a feeder link between the access network node and the core network node, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where a service link between the access network node and a user equipment, UE, is unavailable, without triggering of establishing a connection for the service link, and wherein
　　the at least one NAS PDU is stored by the access network node until the service link becomes available, and
　　the at least one NAS PDU is forwarded via the service link when the service link becomes available.
(Supplementary note 25)
　　A method performed by a core network node, the method comprising:
　　receiving, from an access network node in a non-terrestrial network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network coupled with the core network node is unavailable.
(Supplementary note 26)
　　A method performed by a core network node, the method comprising:
　　transmitting, to an access network node in a non-terrestrial network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network coupled with the core network node is unavailable.
(Supplementary note 27)
　　An access network node in a non-terrestrial network, the access network node comprising:
　　means for receiving, via an available link, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable, without triggering of establishing a connection for another link than the available link;
　　means for storing the at least one NAS PDU until the another link becomes available; and
　　means for forwarding, via the another link, the at least one NAS PDU when the another link becomes available.
(Supplementary note 28)
　　An access network node in a non-terrestrial network, the access network node comprising:
　　means for transmitting, via system information, information indicating a mode of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable, and
　　wherein the information causes at least one UE which does not support the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable, not to camp on a serving cell of the access network node.
(Supplementary note 29)
　　An access network node in a non-terrestrial network, the access network node comprising:
　　means for transmitting, to a core network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable.
(Supplementary note 30)
　　An access network node in a non-terrestrial network, the access network node comprising:
　　means for receiving, from a core network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable.
(Supplementary note 31)
　　A user equipment, UE, comprising:
　　means for transmitting, to an access network node in a non-terrestrial network via a service link between the access network node and the UE, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where a feeder link between the access network node and a gateway in a terrestrial network is unavailable, without triggering of establishing a connection for the feeder link, and wherein
　　the at least one NAS PDU is stored by the access network node until the feeder link becomes available, and
　　the at least one NAS PDU is forwarded via the feeder link when the feeder link becomes available.
(Supplementary note 32)
　　A user equipment, UE, comprising:
　　means for receiving, via system information, information indicating a mode of storing and forwarding data in a case where either a service link between an access network node in a non-terrestrial network and the UE or a feeder link between the access network node and a gateway in a terrestrial network is unavailable; and
　　means for not camping on a serving cell of the access network node in a case where the UE does not support the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable.
(Supplementary note 33)
　　A core network node comprising:
　　means for receiving, from an access network node in a non-terrestrial network via a feeder link between the access network node and the core network node, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where a service link between the access network node and a user equipment, UE, is unavailable, without triggering of establishing a connection for the service link, and wherein
　　the at least one NAS PDU is stored by the access network node until the service link becomes available, and
　　the at least one NAS PDU is forwarded via the service link when the service link becomes available.
(Supplementary note 34)
　　A core network node comprising:
　　means for receiving, from an access network node in a non-terrestrial network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network coupled with the core network node is unavailable.
(Supplementary note 35)
　　A core network node comprising:
　　means for transmitting, to an access network node in a non-terrestrial network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network coupled with the core network node is unavailable.

1　　communication system
3　　UEs
5　　radio access network (RAN) node, NTN RAN
5A　　base station
5B　　gateway
5C　　platform
7　　core network
9　　cells
11　　Mobility Management Entities (MMEs)
13　　Serving Gateways (S-GWs)
15　　Packet Data Network Gateways (P-GWs)
20　　external network
31, 51, 71　　transceiver circuit
33, 53　　air interface
35　　user interface
55　　core network interface
37, 57, 73　　controller
39, 59, 74　　memory
72　　network interface
41, 61, 75　　operating system
43, 63, 76　　communications control module

Claims

　　A method performed by an access network node in a non-terrestrial network, the method comprising:
　　receiving, via an available link, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable, without triggering of establishing a connection for another link than the available link;
　　storing the at least one NAS PDU until the another link becomes available; and
　　forwarding, via the another link, the at least one NAS PDU when the another link becomes available.
　　The method according to claim 1, wherein
　　the receiving is performed using Control Plane CIoT optimization feature or Early Data Transmission, EDT.
　　The method according to claim 1, wherein
　　the forwarding is performed using Control Plane CIoT optimization feature or Early Data Transmission, EDT.
　　The method according to any one of claims 1 to 3, further comprising:
　　maintaining UE information for at least one UE which is allowed by a core network coupled with the gateway, in a case where either the service link or the feeder link is unavailable.
　　The method according to claim 4, wherein
　　the UE information includes at least one of:
　　　　UE identity;
　　　　at least one Quality of Service, QoS, parameter;
　　　　priority information;
　　　　capability information; or
　　　　paging information.
　　The method according to claim 4 or 5, wherein
　　the UE information is determined based on at least one of:
　　　　history information,
　　　　Operations and Management, OAM, data,
　　　　registration data,
　　　　prediction, or
　　　　at least one UE which has downlink data in a buffer of the access network node or the core network.
　　The method according to any one of claims 4 to 6, further comprising:
　　receiving, from the core network, the UE information regardless of a Radio Resource Control, RRC, state of the UE.
　　The method according to any one of claims 4 to 6, further comprising:
　　receiving, from the UE, a message for establishing a connection to the access network node;
　　transmitting, to the core network, a request for authorizing whether the UE can be allowed; and
　　receiving, from the core network, the UE information in a case where the core network has authorized that the UE is allowed.
　　The method according to any one of claims 1 to 8, further comprising:
　　receiving, via the feeder link, paging information used for the forwarding at least one NAS PDU to the UE via the service link; and
　　paging the UE using the paging information in a case where the service link becomes available.
　　The method according to claim 9, wherein
　　the paging information is included in at least one of:
　　　　a paging message from a core network, or
　　　　UE information from the core network.
　　The method according to any one of claims 1 to 10, wherein
　　the at least one NAS PDU is included in a signaling message.
　　The method according to any one of claims 1 to 11, further comprising:
　　transmitting, via the feeder link to a core network, message for informing a status of the forwarding the at least one NAS PDU which is received from the core network node while the feeder link was previously available.
　　The method according to claim 12, wherein
　　the message includes information indicating at least one NAS PDU which was not delivered.
　　A method performed by an access network node in a non-terrestrial network, the method comprising:
　　transmitting, via system information, information indicating a mode of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable, and
　　wherein the information causes at least one UE which does not support the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable, not to camp on a serving cell of the access network node.
　　The method according to claim 14, wherein
　　the information is updated based on whether the feeder link is available or not.
　　The method according to claim 14, wherein
　　the information includes time information indicating a time window when the feeder link will be available temporarily for enabling, and
　　the at least one UE which does not support the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable to camp on the serving cell of the access network node during the time window.
　　The method according to any one of claims 14 to 16, further comprising:
　　receiving, from the UE, support information indicating that the UE supports the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable.
　　The method according to claim 17, wherein
　　the support information is included in a Radio Resource Control, RRC connection setup complete message.
　　A method performed by an access network node in a non-terrestrial network, the method comprising:
　　transmitting, to a core network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable.
　　A method performed by an access network node in a non-terrestrial network, the method comprising:
　　receiving, from a core network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable.
　　The method according to any one of claims 1 to 20, further comprising:
　　transmitting, to the UE, information indicating a Radio Resource Control, release cause in a case where the service link becomes unavailable, and wherein
　　the RRC release causes the UE to at least one of:
　　　　enter an Evolved Packet System, EPS, Connection Management, ECM idle state, or
　　　　stay an ECM-connected state.
　　A method performed by a user equipment, UE, the method comprising:
　　transmitting, to an access network node in a non-terrestrial network via a service link between the access network node and the UE, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where a feeder link between the access network node and a gateway in a terrestrial network is unavailable, without triggering of establishing a connection for the feeder link, and wherein
　　the at least one NAS PDU is stored by the access network node until the feeder link becomes available, and
　　the at least one NAS PDU is forwarded via the feeder link when the feeder link becomes available.
　　A method performed by a user equipment, UE, the method comprising:
　　receiving, via system information, information indicating a mode of storing and forwarding data in a case where either a service link between an access network node in a non-terrestrial network and the UE or a feeder link between the access network node and a gateway in a terrestrial network is unavailable; and
　　not camping on a serving cell of the access network node in a case where the UE does not support the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable.
　　A method performed by a core network node, the method comprising:
　　receiving, from an access network node in a non-terrestrial network via a feeder link between the access network node and the core network node, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where a service link between the access network node and a user equipment, UE, is unavailable, without triggering of establishing a connection for the service link, and wherein
　　the at least one NAS PDU is stored by the access network node until the service link becomes available, and
　　the at least one NAS PDU is forwarded via the service link when the service link becomes available.
　　A method performed by a core network node, the method comprising:
　　receiving, from an access network node in a non-terrestrial network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network coupled with the core network node is unavailable.
　　A method performed by a core network node, the method comprising:
　　transmitting, to an access network node in a non-terrestrial network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network coupled with the core network node is unavailable.
　　An access network node in a non-terrestrial network, the access network node comprising:
　　means for receiving, via an available link, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable, without triggering of establishing a connection for another link than the available link;
　　means for storing the at least one NAS PDU until the another link becomes available; and
　　means for forwarding, via the another link, the at least one NAS PDU when the another link becomes available.
　　An access network node in a non-terrestrial network, the access network node comprising:
　　means for transmitting, via system information, information indicating a mode of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable, and
　　wherein the information causes at least one UE which does not support the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable, not to camp on a serving cell of the access network node.
　　An access network node in a non-terrestrial network, the access network node comprising:
　　means for transmitting, to a core network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable.
　　An access network node in a non-terrestrial network, the access network node comprising:
　　means for receiving, from a core network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network is unavailable.
　　A user equipment, UE, comprising:
　　means for transmitting, to an access network node in a non-terrestrial network via a service link between the access network node and the UE, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where a feeder link between the access network node and a gateway in a terrestrial network is unavailable, without triggering of establishing a connection for the feeder link, and wherein
　　the at least one NAS PDU is stored by the access network node until the feeder link becomes available, and
　　the at least one NAS PDU is forwarded via the feeder link when the feeder link becomes available.
　　A user equipment, UE, comprising:
　　means for receiving, via system information, information indicating a mode of storing and forwarding data in a case where either a service link between an access network node in a non-terrestrial network and the UE or a feeder link between the access network node and a gateway in a terrestrial network is unavailable; and
　　means for not camping on a serving cell of the access network node in a case where the UE does not support the mode of the storing and forwarding data in a case where either the service link or the feeder link is unavailable.
　　A core network node comprising:
　　means for receiving, from an access network node in a non-terrestrial network via a feeder link between the access network node and the core network node, at least one non access stratum, NAS, Protocol Data Unit, PDU, in a case where a service link between the access network node and a user equipment, UE, is unavailable, without triggering of establishing a connection for the service link, and wherein
　　the at least one NAS PDU is stored by the access network node until the service link becomes available, and
　　the at least one NAS PDU is forwarded via the service link when the service link becomes available.
　　A core network node comprising:
　　means for receiving, from an access network node in a non-terrestrial network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network coupled with the core network node is unavailable.
　　A core network node comprising:
　　means for transmitting, to an access network node in a non-terrestrial network, information indicating a capability of storing and forwarding data in a case where either a service link between the access network node and a user equipment, UE, or a feeder link between the access network node and a gateway in a terrestrial network coupled with the core network node is unavailable.