Access network nodes and user equipment

Abstract

A method is disclosed that is performed by an access network node in a non-terrestrial network. The method includes receiving user plane data over an available link without triggering the resumption of connection on another link other than the available link, when either a service link between the access network node and user equipment (UE) or a feeder link between the access network node and a gateway in a terrestrial network is unavailable; storing the user plane data until another link becomes available; and, once another link becomes available, transferring the user plane data over the other link.

Description

[Technical Field]

[0001] This disclosure relates to communication systems and components thereof. This disclosure has a non-exclusive but specific relevance to wireless communication systems and devices operating in accordance with 3rd Generation Partnership Project (3GPP®) standards or equivalent standards (including LTE Advanced, Next Generation or 5G networks, Future Generation and beyond) or derivative standards thereof. This disclosure is particularly relevant to, but not limited to, improvements in the use of storage and transfer technologies for the communication of user data in the context of Non-Terrestrial Networks (NTN). [Background technology]

[0002] Previous developments of the 3GPP standard were referred to as Long Term Evolution (LTE) and Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) on Evolved Packet Core (EPC) networks, and are commonly known as "4G." More recently, the terms "5G" and "new radio" (NR) have begun to be used to refer to evolving communication technologies that are expected to support a variety of applications and services. Various details of 5G networks are described in the "NGMN 5G White Paper" V1.0 by the Next Generation Mobile Network (NGMN) Alliance, which is available, for example, at https: / / www.ngmn.org / 5g-white-paper.html. 3GPP intends to support 5G through the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and 3GPP NextGen core network.

[0003] Under the 3GPP standard, a NodeB (or eNB in ​​LTE, and gNB in ​​5G) is a radio access network (RAN) node (or simply an “access node,” “access network node,” or “base station”) through which communication devices (user equipment or “UE”) connect to the core network and communicate with other communication devices or remote servers. For simplicity, this application uses the terms access network node, RAN node, or base station to refer to any such access node.

[0004] For simplicity, this application uses the terms mobile device, user device, or UE to refer to any communication device capable of connecting to a core network via one or more base stations. While this application may refer to mobile devices in its description, it will be understood that the technology described can be implemented on any (mobile and / or generally fixed) communication device capable of connecting to a communication network to transmit / receive data, whether such communication device is controlled by human input or software instructions stored in memory. One particular type of UE supported in modern communication systems is the so-called Internet of Things (IoT) device, which is a non-standard hardware device (including everyday physical objects such as sensor devices, gadgets, and appliances) capable of wirelessly connecting to a network to transmit and receive data. The technology for supporting such IoT UEs in cellular communication systems is often referred to as cellular IoT (CIoT) extension or optimization. The CIoT extension includes, for example, the narrowband IoT (NB-IoT) extension, a wireless technology developed to support cellular network IoT devices and services, where the bandwidth is limited to a single narrowband (e.g., transmission is limited to occupying a single 180kHz physical resource block (PRB) / 12 subcarriers of 15kHz each). The CIoT extension also includes features that support so-called "LTE machine" (LTE Cat-M1 or simply LTE-M) technology with a bandwidth-limited UE (BL UE) that operates over a wider narrowband (e.g., limited to 6 PRBs / 1.4MHz), although it is faster than NB-IoT.

[0005] In current 5G architectures, the gNB structure can be divided into two or more parts. In some RAN implementations, there are two parts, sometimes referred to as the "control unit," known as the Central Unit (CU or gNB-CU), and the Distributed Unit (DU or gNB-DU), connected by an F1 interface. This makes it possible to use a "divided" architecture. Typically, a "partitioned" architecture separates a "higher" CU layer (such as the Packet Data Convergence Protocol (PDCP) layer and the Radio Resource Control (RRC) layer, but not limited to these) and a "lower" DU layer (such as the Radio Link Control (RLC) layer, the Media Access Control (MAC) layer (sometimes referred to as "Medium"), and the Physical (PHY) layer, but not limited to these) from a specific CU and one or more DUs connected to and controlled by that CU via an F1 interface. Thus, for example, the higher-layer CU functionality for multiple gNBs may be implemented centrally (for example, by a single processing unit or in a cloud-based or virtualized system), while the lower-layer DU functionality is maintained locally and separately for each gNB.

[0006] The core network includes multiple communication entities that provide different functions to support communication.

[0007] For example, in 4G, the core network entities include, among other things, the Mobility Management Entity (MME), the serving gateway (SGW or S-GW), and the packet data network (PDN) gateway (PGW or P-GW). The MME manages the general mobility of the UE and ensures that connectivity with the UE is maintained when the UE is moving within the geographic area covered by the communication system. The MME also handles the UE's control plane signaling and manages various bearers associated with the UE (e.g., Evolved Packet System (EPS) bearers and / or radio bearers) by controlling, for example, the S-GW and P-GW (and / or possibly other network nodes) to which such bearers are served. The S-GW provides connectivity between the UE and the core network (via base stations) to send and receive user plane data via associated communication bearers (e.g., EPS bearers). Communication bearers typically terminate at the P-GW, but are often complemented by external bearers (e.g., another EPS bearer) between the P-GW and communication endpoints outside the core network (e.g., in the external network). It will be understood that the functions of the S-GW and P-GW can be implemented in a single gateway element.

[0008] In 5G, the core network entity comprises a logical node (or "function") containing a control plane function (CPF) and one or more user plane functions (UPFs). The CPF includes, among 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 the functions of both the S-GW and P-GW, specifically the user plane functions of the S-GW (SGW-U) and the P-GW (PGW-U). The SMF provides session management functions (which formed part of the MME functions in 4G). The SMF also combines some of the functions provided by the S-GW and P-GW, specifically the control plane functions of the S-GW (SGW-C) and the P-GW (PGW-C). The SMF also assigns an IP address to each UE.

[0009] In 4G, several EPS optimizations were introduced to support CIoT (e.g., NB-IoT) (these are generally applicable to later generations of technology), and these enhancements enabled communication of new user data paths for IoT. In contrast to the original data paths via S-GW and P-GW, these new data paths enable communication of user data via MME (as well as other CN nodes such as S-GW, P-GW, and / or Service Capability Exposure Function (SCEF) in 4G), although in later generations this may be via different equivalent nodes (e.g., AMF in 5G). CIoT EPS optimizations using these newer paths are referred to as control plane (CP) mode or "CP mode" CIoT EPS optimizations, while CIoT EPS optimizations using the original data paths are referred to as user plane (UP) mode or "UP mode" CIoT EPS optimizations.

[0010] CP-mode CIoT EPS optimization reduces the total number of control plane messages when handling short data transactions (typically occurring in IoT communications), user data, or SMS messages transmitted via the MME using the service request procedure by encapsulating them in non-access stratum (NAS) messages. For IP data packets, UL data can be forwarded from the base station to the CIoT service via the MME, S-GW, and P-GW. For non-IP data packets, UL data can be forwarded from the base station to the CIoT service via the MME and SCEF.

[0011] On the other hand, UP-mode CIoT EPS optimization transmits user plane data without using a service request procedure to establish an access stratum (AS) context at the serving base station and UE. This UP-mode method is based on UP transport of user data, where data is transferred over the network from the base station to the S-GW and vice versa over the conventional user plane. In UP-mode CIoT, two distinct RRC connection scenarios are possible. In the first scenario, the RRC connection is released with a possible reactivation action indicated, and then a reactivation of the connection may be requested as part of the reactivation procedure. If this reactivation procedure is successful, security is established with the updated key, and the radio bearer is configured as with the original connection. In the second scenario, where there is no prior release of the RRC connection with a reactivation instruction, or the reactivation request is not accepted by the base station, security and the radio bearer must be re-established.

[0012] 3GPP is also working with the satellite communications industry to define integrated satellite and terrestrial network infrastructure in the context of 5G. This is referred to as a non-terrestrial network (NTN), a term that refers to a network or segment of a network that uses aircraft or spacecraft for the transmission of data and control signaling. Satellites refer to spacecraft in Low Earth Orbit (LEO), Medium Earth Orbit (MEO), Geostationary Earth Orbit (GEO), or Highly Elliptical Orbit (HEO). Aircraft refer to High Altitude Platforms (HAPs) that encompass Unmanned Aircraft Systems (UAS), including tethered UAS, lighter-than-air UAS, and heavier-than-air UAS, all of which typically operate in a quasi-geostationary state at altitudes of 8-50 km.

[0013] 3GPP Technical Report (TR) 38.811 is a study on New Radio for supporting such terrestrial networks. This study includes, among other things, NTN deployment scenarios and related system parameters (such as architecture, altitude, orbit, etc.), as well as a description of the adaptation of the 3GPP channel model for non-terrestrial networks (propagation conditions, mobility, etc.). Non-terrestrial networks are, - To help promote the deployment of 5G services in areas that are not serviced or have insufficient service, in order to upgrade the performance of terrestrial networks. - To enhance service reliability by providing service continuity to user equipment or mobile platforms (e.g., passenger vehicles, aircraft, ships, high-speed trains, buses), - To improve service availability everywhere, especially for critical communications, and for future rail / maritime / air communications, and - It is expected that 5G network scalability will be enabled by providing efficient multicast / broadcast resources for data distribution to the network edge or directly to user devices.

[0014] Non-terrestrial network access typically involves the following elements, among others: -NTN terminal: This may refer to a 3GPP UE or a UE specific to the satellite system if the satellite does not directly serve a 3GPP UE. - A service link refers to a radio link between user equipment and a space / airborne platform (which may also be added to a radio link with a ground-based RAN). - (e.g., satellites) space or aerial platforms, - It features a gateway that connects a satellite or air access network to the core network. The gateway is almost always co-located with a base station (e.g., gNB), i.e., - A feeder link should be understood as referring to a wireless link between a gateway and a space / airborne platform.

[0015] There are several different architectures that can be used to provide NTN access. One such architecture is a “regenerative” access network architecture (sometimes referred to as “regenerative satellite,” “regenerative payload,” or “regenerative mode”) in which a non-terrestrial platform (e.g., a satellite) performs some onboard processing of the payload being communicated between the UE and the core network. Specifically, in the regenerative architecture, at least some of the base station functions (e.g., at least the functions of the DU of a distributed base station, or possibly all of the base station functions) are provided on the non-terrestrial platform. Other regenerative mode architectures are also possible, such as architectures in which at least some of the core network functions are implemented on the non-terrestrial platform.

[0016] Another possible architecture is a “transparent” access network architecture (sometimes referred to as “transparent satellite,” “transparent mode,” or “transparent payload”), in which base stations are located on the ground and transmit and receive communications destined for and originating from the UE via ground-based gateways and via non-terrestrial platforms that do not have base station functionality. The non-terrestrial platforms transparently relay these communications to and from the UE without onboard processing, effectively acting as a so-called “vent pipe.” In this architecture, both service links and feeder links effectively function as part of the air interface between the base station and the UE.

[0017] A satellite or aerial vehicle typically generates several satellite beams over a given area. These beams typically have an elliptical footprint on the Earth's surface. The beam footprint can move across the Earth along with the movement of the satellite or aerial vehicle in its orbit. Alternatively, the beam footprint may be (temporarily) fixed to the Earth, in which case several beampointing mechanisms (mechanical or electronic maneuvering mechanisms) can be used to compensate for the movement of the satellite or aerial vehicle. There are various options for beam identification purposes. One option is that multiple (nearby / adjacent) satellite beams may have the same associated physical cell ID (PCI), and therefore the PCI may remain unchanged as the UE3 moves between beams in a set of beams sharing the PCI. Alternatively, there may be a one-to-one relationship between the PCI and the satellite beams (at least within the coverage area of ​​a particular satellite containing multiple beams).

[0018] 5G coverage is primarily beam-based, not cell-based. There is no cell-level reference channel from which cell coverage can be measured. Instead, each cell has one or more so-called synchronization signal block (SSB) beams (different from satellite beams or NTN beams). The SSB beams form a matrix of beams that cover the entire cell area. Each SSB beam carries the SSB, including the primary synchronization signal (PSS), secondary synchronization signal (SSS), and physical broadcast channel (PBCH).

[0019] The UE searches for SSB beams and performs measurements (e.g., synchronization signal reference signal received power (SS-RSRP), synchronization signal reference signal received quality (SS-RSRQ), and / or synchronization signal to noise or interference ratio (SS-SINR)). The UE maintains a set of candidate beams that may include beams from multiple cells. Thus, PCI and beam ID (or SSB index) distinguish SSB beams from one another. In essence, an SSB beam is like a minicell that can exist within a larger cell. Once the UE has detected and selected a cell (and / or SSB beam in the case of 5G), the UE may attempt to access that cell and / or SSB beam using an initial RRC connection setup procedure with random access procedures.

[0020] Specifically, a UE may attempt to access its cells and / or beams using a random access procedure, which generally involves four distinct steps. Before attempting initial access, the UE may transmit a preamble to the network (e.g., a base station such as a gNB) via a physical random access channel (PRACH / RACH) to initiate a random access procedure (also referred to as the RACH procedure or simply RACH) to achieve synchronization at the uplink (UL). This step is often referred to as the PRACH transmission or simply the transmission of message 1 (Msg1). In response, the network responds with a random access response (RAR). The RAR includes a timing-alignment (TA) command to indicate the reception of the preamble and adjust the UE's transmission timing based on the timing of the received preamble, an uplink grant field indicating the resources to be used on the uplink for the physical uplink shared channel (PUSCH), a frequency hopping flag to indicate whether the UE transmits on PUSCH with or without frequency, an MCS field that allows the UE to determine the modulation and coding scheme (MCS) for the PUSCH transmission, and a transmit power control (TPC) command value to set the power for the PUSCH transmission. The RAR transmission step is often referred to as the message 2 (Msg2) transmission. The UE then sends message 3 (message 3 or "Msg3") to the network via 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, depend on the context in which the random access procedure is being used. However, in the example of initial wireless RRC connection setup, Msg3 contains an RRC setup request or similar message carrying a temporary, randomly generated UE identifier.The network responds with a message 4 (message 4 or "Msg4") that carries a randomly generated UE identifier received in Msg3 for contention purposes, in order to resolve any collisions between different UEs using the same preamble sequence. If successful, Msg4 also transitions the UE to the connected state.

[0021] Similar random access procedures can also be used in other contexts, including, for example, handover, connection re-establishment, and UL scheduling requests when dedicated resources for scheduling requests are not configured for the UE.

[0022] (In addition to the 4-step random access procedure described above), so-called 2-step random access procedures have also been developed. The two-step random access is mainly intended to support, among other things, (ultra) low latency communication, 10 ms control plane latency, fast handover, efficient channel access in unlicensed spectrum, and the transmission of small data packets. However, this procedure can also be applied to large cells such as non-terrestrial cells. The main difference is that the 4-step random access procedure requires two round-trip cycles between the UE and the base station, while the 2-step random access procedure aims to reduce latency and control signaling overhead by using a single round-trip cycle between the UE and the base station. In fact, 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) and the contention resolution message (Msg4) from the base station to the UE are combined (and referred to as "MsgB") in the 2-step random access procedure.

[0023] As will be understood by those skilled in the art, while competitive-based PRACH procedures are described, non-competitive-based (or "collision-free") procedures where a dedicated preamble is assigned by the base station to the UE may also be used.

[0024] In addition to the RACH-based initial access procedures described above, so-called RACH-less access procedures have also been introduced in the context of handover procedures under development in later releases of the LTE standard, also for the purpose of providing latency reduction. RACH-less-based handovers eliminate the need to perform random access when first accessing the target cell, thus shortening the data connection interruption time in each handover and therefore shortening the overall handover execution time.

[0025] When a non-terrestrial platform providing services to a UE moves, even if the UE remains stationary, discontinuous coverage of that UE may occur as a result of, for example, degradation of the service link due to satellite movement. In addition to this type of discontinuous coverage, there may also be intermittent feeder link connectivity (e.g., with a gateway at the associated terrestrial station) in areas where, for example, it is not feasible to deploy a gateway, or where gateway deployment is not cost-effective. [[ID=Io]]

[0026] Furthermore, at different times, different NTN platforms (and thus, if present, on-board base stations) may each provide a feeder link and a service link. Specifically, for a UE at a given location, one or more satellites may be orbiting and may provide communication services to that UE at different times. Thus, the UE will effectively see different base stations during different time windows. Similarly, one or more satellites may orbit around the terrestrial location of a gateway through which one or more feeder link connections are provided, which means that gateway feeder connectivity may be through different satellites (and, potentially, base stations in the case of a regenerative mode architecture).

[0027] One such scenario is illustrated in Figure 1 for a regenerative architecture, which shows the changes in satellites, and therefore base stations, providing service links and feeder links, respectively, in an NTN system. As seen in Figure 1, two NTN platforms (satellites in this example), each providing its own base station, cycle through providing service links to the UE and feeder links to the gateway (GW) to access the core network (CN) at different times (T1) and (T2). Specifically, at T1, the first satellite / base station (base station #1) provides the feeder link, and the second satellite / base station (base station #2) provides the service link. At T2, the situation is reversed, with the first satellite / base station (base station #1) providing the service link and the second satellite / base station (base station #2) providing the feeder link. Therefore, data communicated to base station #2 via the service link and to base station #1 via the feeder link at time T1 cannot be transmitted to the core network and UE, respectively, until time T2.

[0028] Therefore, since feeder link connections and associated service link connections are not necessarily available simultaneously, it can be seen that, given a given time, the UE may not have a complete (end-to-end) connection to the core network. In such scenarios, to avoid data loss, communications over the service link must be stored on a non-terrestrial platform for forwarding to the core network via the feeder link, and vice versa. Such techniques are known as “storage and forwarding” techniques. These techniques are particularly applicable to delay-tolerant communications (i.e., non-real-time communications), such as those typically used in CIoT-based communications.

[0029] As an example, one possible storage and transfer technique is shown in Figure 2, which is a simplified sequence diagram illustrating a generalized procedure for forming a connection in an NTN system, including the storage and transfer of user and control data. The illustrated procedure is in the context of a CIoT CP mode procedure.

[0030] As shown in Figure 2, the procedure begins in a scenario where UE3 is within the coverage of the first base station 5A-1 on the first NTN platform, but the feeder link is disconnected (in S210). UE3 and the first base station 5A-1 of the first NTN RAN 5-1 cooperate to establish an RRC connection (S212). This procedure typically includes a random access procedure, as seen in S214 (for example, as described above). The random access procedure ends (in S216) when UE3 sends a message to the first base station 5A-1 indicating that the RRC is complete, containing a UL NAS protocol data unit (PDU) containing a control plane service request (CPSR) and / or control plane data as a non-access stratum (NAS) payload. When 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 in S216. In S218, the first base station 5A-1 sends a message to the UE3 to release the RRC connection, which includes an instruction that the feeder link is unavailable and an instruction for a scheduled time when the UE3 may expect a response from the core network 7 and therefore can perform the next transmission. The UE3 can then effectively enter idle mode while waiting for a response. Subsequently, once the feeder link is connected, in S220, the first base station 5A-1 may send an initial UE message containing the NAS PDU / data to the core network 7 in S222. In S224, the core network 7 may determine that the second base station 5A-2 of the second NTN RAN 5-2 (whose feeder link is connected to / will be connected to the core network 7) is likely to provide coverage to the UE3 at some point in the future. If the feeder link to this second base station 5A-2 is available, the core network 7 may send the appropriate DL NAS response PDU along with any DL data in S226. The DL NAS PDU / data is stored in the second base station 5A-2 at S228.When UE3 is within the coverage of the second base station 5A-2 in S230, the second base station 5A-2 can page UE3 in S232. Thus, UE3 and the second base station 5A-2 can cooperate to establish a connection in S234, from which DL NAS PDU and data can be delivered.

[0031] Nevertheless, the procedure in Figure 2 does not take into account all the effects / problems associated with discontinuous coverage and intermittent feeder links.

[0032] In this context, as long as the complete base station is built on the NTN platform, the NAS procedure is likely to have a greater impact than the AS procedure. This is because the NAS procedure requires bidirectional connectivity from the UE to the core network. For example, in the case of a conventional registration / attach procedure, the "storage and transfer" method typically requires a one-way storage and transfer cycle for each request message and another storage and transfer cycle in the opposite direction for each corresponding response message.

[0033] While the impact on AS procedures (such as initial access) is likely to be minimal, data transmission typically requires end-to-end connectivity between the UE and the core network / packet data network, as well as the establishment of the UE context.

[0034] Therefore, further improvements are needed to more effectively support the implementation of storage and transfer technologies, particularly in situations of discontinuous coverage / intermittent feeder links (but not limited to) that occur in NTN systems. [Prior art documents] [Non-patent literature]

[0035] [Non-Patent Document 1] 3GPP Technical Report(TR)38.811 [Non-Patent Document 2] NGMN 5G White Paper V1.0 [Overview of the Initiative] [Problems that the invention aims to solve]

[0036] This disclosure aims to provide one or more apparatuses and / or one or more related methods that contribute to satisfying the above-mentioned needs.

[0037] While the following disclosures generally refer to "satellite"-based NTNs, it should be understood that the principles and methods described are more broadly applicable to other space or airborne platforms used to implement NTNs. [Means for solving the problem]

[0038] In one embodiment, a method is provided that is performed by an access network node in a non-terrestrial network, and the method is In the event that either the service link between the access network node and the user equipment (UE), or the feeder link between the access network node and the gateway in the terrestrial network, becomes unavailable, user plane data is received via an available link without triggering the reactivation of a connection on another link other than the available link. The user plane data is stored until another link becomes available, This includes transferring user plane data via another link when another link becomes available.

[0039] In one embodiment, a method is provided that is performed by user equipment (UE), and the method is The invention further includes transmitting user plane data to an access network node in a non-terrestrial network via a service link between the access network node and the UE without triggering the reconnection of the feeder link when the feeder link between the access network node and the gateway in the terrestrial network is unavailable, User plane data is stored by the access network node until a feeder link becomes available. User plane data is transferred via the feeder link when the feeder link becomes available.

[0040] In one embodiment, a method is provided that is performed by a core network node, and the method is This includes receiving user plane data from an access network node in a non-terrestrial network via a feeder link between an access network node and a core network node, without triggering the resumption of connectivity for the service link, when the service link between the access network node and the user equipment (UE) is unavailable. User plane data is stored by the access network node until a service link becomes available. User plane data is transferred via the service link when the service link becomes available.

[0041] In one embodiment, an access network node is provided within a non-terrestrial network, and the access network node is A means for receiving user plane data via an available link without triggering the resumption of connection on another link other than the available link, when either the service link between the access network node and user equipment (UE), or the feeder link between the access network node and a gateway in the terrestrial network, is unavailable. A means for storing user plane data until another link becomes available, The system includes means for transferring user plane data via another link when another link becomes available.

[0042] In one embodiment, user equipment (UE) is provided. In the event that the feeder link between the access network node and the gateway in the terrestrial network is unavailable, the system provides means for transmitting user plane data to an access network node in a non-terrestrial network via a service link between the access network node and the UE without triggering the reconnection of the feeder link. User plane data is stored by the access network node until a feeder link becomes available. User plane data is transferred via the feeder link once the feeder link becomes available.

[0043] In one embodiment, core network nodes are provided, In the event that the service link between the access network node and the user equipment (UE) is unavailable, the system provides means for receiving user plane data from an access network node in a non-terrestrial network via a feeder link between the access network node and the core network node without triggering the resumption of the service link connection. User plane data is stored by the access network node until a service link becomes available. User plane data is transferred via the service link when the service link becomes available.

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

[0045] The various examples described below can be implemented by computer program products that include computer-implementable instructions for causing a programmable computer to perform one of the methods described below. These computer-implementable instructions may be provided as signals or on a tangible computer-readable medium. [Effects of the Invention]

[0046] According to this disclosure, methods performed by access network nodes, methods performed by user equipment, methods performed by core network nodes, access network nodes, user equipment, and core network nodes can be provided. [Brief explanation of the drawing]

[0047] Herein, exemplary embodiments of the present disclosure will be described by reference to the accompanying drawings.

[0048] [Figure 1] This figure shows a scenario in which there are changes to the satellites providing service links and feeder links, and therefore to the base stations, in the NTN system. [Figure 2] This is a simplified sequence diagram showing the generalized procedure for establishing a connection in an NTN system. [Figure 3] An illustrative mobile (cellular or wireless) communication system is shown schematicly. [Figure 4] This is a simplified sequence diagram showing the attachment procedure that may be used in the communication system shown in Figure 3. [Figure 5] This is a simplified sequence diagram showing the RRC connection interruption procedure that may be used in the communication system shown in Figure 3. [Figure 6] This is a simplified sequence diagram showing the RRC connection reactivation procedure that may be used in the communication system shown in Figure 3. [Figure 7] This is a simplified sequence diagram showing another RRC connection reactivation procedure that may be used in the communication system shown in Figure 3. [Figure 8] Figure 3 schematically shows a non-terrestrial network (NTN) wireless access network that may be used in the communication system. [Figure 9A] This shows possible architectures for NTN RAN. [Figure 9B] This shows possible architectures for NTN RAN. [Figure 9C] This shows possible architectures for NTN RAN. [Figure 10] This is a simplified sequence diagram showing a CIoT-optimized data transmission flow between NTN RAN base stations, which may be used in the communication system shown in Figure 3 when the service link is available but the feeder link is unavailable. [Figure 11] This is a simplified sequence diagram showing a CIoT-optimized data transmission flow between the NTN RAN and the core network, which may be used in the communication system shown in Figure 3 when the feeder link is available but the service link is unavailable. [Figure 12] This is a simplified sequence diagram showing the S1 setup procedure that may be used in the communication system shown in Figure 3. [Figure 13] This is a simplified sequence diagram showing the first step in supporting UE context lookup between different base stations, which may be used in the communication system shown in Figure 3. [Figure 14] This is a simplified sequence diagram illustrating a second procedure for supporting UE context lookup between different base stations within a communication system, which may be used in the communication system shown in Figure 3. [Figure 15] This is a simplified sequence diagram illustrating a third step for supporting UE context lookup between different base stations, which may be used in the communication system shown in Figure 3. [Figure 16] This is a simplified sequence diagram showing the overall attach-resume-suspend flow that can be used in the communication system shown in Figure 3. [Figure 17]Figure 3 is a simplified block diagram showing the main components of user equipment that may be used in the communication system. [Figure 18] Figure 3 is a simplified block diagram showing the main components of a base station / access network node that may be used in the communication system. [Figure 19] Figure 3 is a simplified block diagram showing the main components of a core network node that may be used in the communication system. [Modes for carrying out the invention]

[0049] <Overview> Next, an exemplary communication system will be explained using general terminology, with reference to Figures 3 to 9.

[0050] Figure 3 schematically shows a mobile ("cellular" or "wireless") communication system 1 to which the examples described herein can be applied.

[0051] In communication system 1, user equipment (UE) 3 (3-1, 3-2, 3-3) (e.g., mobile phones and / or other mobile devices) can communicate with each other via corresponding Radio Access Networks (RANs) 5-1, 5-2 operating 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 base stations 5A-1, 5A-2 (e.g., LTE / 4G base stations such as eNBs) that operate one or more associated cells 9 (9-1, 9-2), respectively.

[0052] As those skilled in the art will understand, three UE3s and two RAN5-1s and 5-2s are shown in Figure 3 for illustrative purposes, but the system, when implemented, typically includes other RAN5s and UE3s.

[0053] In an exemplary system, UE3 includes one or more so-called “internet-of-things” (“IoT”) devices, such as narrowband IoT (NB-IoT) devices.

[0054] Each RAN5-1, 5-2 directly controls one or more associated cells, or indirectly controls them through one or more other nodes (e.g., home base stations, relays, remote radio heads, distributed units, etc.). It will be understood that RAN5 may be configured to support 4G, 5G, 6G and / or later generations, and / or any other 3GPP or non-3GPP communication protocols.

[0055] UE3 and their serving RAN5 are connected via appropriate air interfaces (e.g., so-called "Uu" interfaces and / or similar). Adjacent base stations 5A in RAN5 may be connected to each other via appropriate inter-base station interfaces (such as the so-called "X2" interface for 4G, the "Xn" interface for 5G, etc.).

[0056] The core network 7 includes multiple communication nodes / logical nodes (or “functions”) to support communication in the communication system 1. In this example, the core network 7 includes one or more control network node entities (e.g., Mobility Management Entity (MME) 11 or mobility management node 11) for control signaling communication, one or more network node entities (e.g., Serving Gateway (S-GW) 13) for routing incoming and outgoing packets, and one or more network node entities (e.g., Packet Data Network Gateway (P-GW) 15) for connecting the core network 7 and the external network 20, along with several other function nodes (not shown). It will be understood that nodes or functions may have different names in different systems. While Core Network 7 is described in the context of 4G entities and interfaces / reference points, it should be understood that the core network can be any suitable core network (e.g., 5G / 6G and / or later generation core networks) with corresponding communication entities (e.g., control functions (CPFs) such as AMF and SMF, and one or more user plane functions (UPFs)).

[0057] RAN5 connects to the core network nodes via appropriate interfaces (or "reference points"), such as the S1-MME reference point between RAN5 base station 5A and MME11, and the S1-U reference point between RAN5 base station 5A and S-GW13. Each UE3 connects to MME11 via a non-access stratum (NAS) connection via an appropriate interface (e.g., the S1 reference point, similar to the N1 reference point in 5G) where applicable. It will be understood that S1 communication is routed transparently through RAN5.

[0058] The core network 7 (e.g., P-GW15) is connected to an external network 20 (e.g., an IP network such as the Internet) via another reference point (e.g., "SGi") for the communication of user data.

[0059] The MME11 manages the general mobility of the UE3 and ensures that connectivity with the UE3 is maintained when the UE3 is moving within the geographic area covered by the communication system 1 (and / or when the UE3 is handed over between base stations 5A of the communication system 1). The MME11 also handles control plane signaling for the UE3 and manages various bearers associated with the UE3 (e.g., Evolved Packet System (EPS) bearers and / or radio bearers, etc.) by controlling, for example, the S-GW13 and P-GW15 (and / or other network nodes to which such bearers are served).

[0060] S-GW13 provides connectivity (via base station 5A) between UE3 and core network 7 to send and receive user plane data via associated communication bearers (e.g., EPS bearers). Communication bearers typically terminate at P-GW15, but are often complemented by external bearers (e.g., another EPS bearer) between P-GW15 and communication endpoints outside core network 7 (e.g., within external network 20). Although presented as separate entities, it will be understood that the functions of S-GW13 and P-GW15 may be implemented in a single gateway element.

[0061] Furthermore, RAN5 is configured to transmit control information and user data via multiple downlink (DL) physical channels, and UE3 is configured to receive them and transmit multiple physical signals. DL physical channels correspond to resource elements (REs) that carry information transmitted from higher layers, and DL physical signals correspond to REs used in the physical layer that do not carry information transmitted from higher layers.

[0062] 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 that shares its capacity on a time and frequency basis. The PDSCH can carry various types of data, such as user data, UE-specific upper-layer control messages mapped from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) to support multiple functions, including scheduling downlink transmissions on the PDSCH and uplink data transmissions on the physical uplink shared channel (PUSCH). The PBCH provides the Master Information Block (MIB) to the UE3. It also supports time and frequency synchronization in conjunction with the PDCCH, which assists in cell acquisition, selection, and re-selection.

[0063] DL physical signals may include, for example, a reference signal (RS) and a synchronization signal (SS). The reference signal (sometimes referred to as a pilot signal) is a signal with a predetermined special waveform known to both the UE3 and RAN5 base stations 5A. The reference signal may include, for example, a cell-specific reference signal, a UE-specific reference signal (UE-RS), a downlink demodulation signal (DMRS), and a channel state information reference signal (CSI-RS).

[0064] Similarly, UE3 is configured to transmit control information and user data via multiple uplink (UL) physical channels corresponding to REs that carry information transmitted from higher layers, and to transmit UL physical signals used in the physical layer that do not carry information transmitted from higher layers, and base station 5A of RAN5 is configured to receive that control information and user data and UL physical signals. Physical channels may include, for example, PUSCH, physical uplink control channel (PUCCH), and / or physical random-access channel (PRACH). UL physical signals may include, for example, demodulation reference signal (DMRS) for UL control / data signals, and / or sounding reference signal (SRS) used for UL channel measurement.

[0065] <Attachment Procedure and Initial Access> UE3, base station 5A of RAN5, and core network entities of communication system 1 are configured to perform an attach procedure to connect UE3 to the network for communication of user data.

[0066] Here, with reference to Figure 4, a simplified sequence diagram showing an attachment procedure that may be used in communication system 1, one possible such procedure that can be performed will be described as a mere example.

[0067] As shown in Figure 4, after initial synchronization to the network (for example, based on the reception of PSS and SSS), UE3 receives an MIB at S410 and one or more SIBs (in this example, at least system information block type 1 (SIB1)) at S412. MIBs typically provide information that identifies, for example, the system bandwidth, antenna configuration, and system frame number. The reception of MIBs and other system information enables UE3 to further (downlink) synchronize with base station 5A of RAN5.

[0068] When UE3 needs to connect to the network, it can perform a random access channel (RACH) procedure to access the network. Specifically, UE3 can attempt to access cell 9 (and / or beam) using an initial RRC connection setup procedure that includes a random access procedure. Before attempting initial access, UE3 selects a random access resource (e.g., including a preamble) to use to initiate the RACH procedure. In S414, UE3 sends the selected preamble (e.g., in "Msg1") to base station 5A of RAN5 via physical random access channel (PRACH) to initiate the process of obtaining synchronization on the uplink (UL). In response, base station 5A of RAN5 responds in S416 with a random access response (RAR) (or "Msg2"). The RAR includes a timing-alignment (TA) command to indicate the reception of a preamble and adjust the transmission timing of UE3 based on the timing of the received preamble (for example), an uplink grant field indicating the resources to be used on the uplink for the physical uplink shared channel (PUSCH), a frequency hopping flag to indicate whether UE3 will transmit on PUSCH with or without frequency, an MCS field to allow UE3 to determine the modulation and coding scheme (MCS) for PUSCH transmission, and a transmit power control (TPC) command value to set the power for PUSCH transmission. At this point, an initial signaling radio bearer (SRB) "SRB0" is established to communicate a specific type of RRC message on the common control channel (CCCH). Then, in S418, UE3 sends a third message ("Msg3") to the network via the physical uplink shared channel (PUSCH) based on the information in the RAR (for example, using SRB0).The specific messages sent by UE3 in this step, and the content of those messages, depend on the context in which the random access procedure is being used. However, in the example of an initial wireless RRC connection setup, Msg3 typically contains an RRC connection request or similar message carrying a temporary, randomly generated UE identifier (e.g., serving temporary mobile subscriber identity (S-TMSI)). The network responds at S420 with a fourth message ("Msg4") carrying the randomly generated UE identifier received in Msg3 (for example, for the purpose of resolving any conflicts between different UE3s using the same preamble sequence). If successful, Msg4 also causes UE3 to transition to a connection state in which another SRB "SRB1" is established to communicate specific RRC and NAS messages over a dedicated control channel (DCCH).

[0069] Next, UE3 attempts to achieve a packet data network (PDN) connection by sending a message to base station 5A of RAN5 in S422 indicating that RRC is complete. This message, as a NAS payload, includes an attach request to initiate the attach procedure and a PDN connection request. Then, base station 5A of RAN5 sends its first message, an initial UE message containing the attach request and PDN connection request, to core network 7 in S424. This message is sent to the core network node that provides mobility management functionality (MME11 in this example, but AMF in the case of 5G). This message is sent via the S1-MME interface / reference point and, in this 4G example, includes information such as the tracking area identify (TAI) and E-UTRAN cell global identifier (ECGI) (similar but differently named message / information elements may be used for 5G and other generations).

[0070] In S426, the mobility management node 11 coordinates with another core network node (for example, the home subscriber server HSS and / or authentication centre (AuC)) to obtain security information such as authentication information, for example, KASME (cryptographic key, integrity key, and intermediate key derived in HSS and UE3 from serving network identity (SN id)), AUTN (so-called authentication token generated in AuC), XRES (so-called "expected response" generated in AuC), and / or RAND (random number for use in key generation and authentication).

[0071] In S428, the mobility management node 11 sends an authentication request (including RAND and AUTN) to the UE3, and in S430, the UE3 responds with an authentication response that includes authentication response parameters calculated based on RAND and AUTN, and a key (K) stored in the UE3 (for example, in the subscriber identity module).

[0072] Next, the mobility management node 11 initiates NAS signaling security between itself and the UE3 by sending a NAS security mode command message in S432 that notifies the UE3 of the respective algorithms to be used for integrity protection and (de)encryption. In S434, the UE3 derives the appropriate security information and then (in S436) responds by sending a response message to the mobility management node 11 that the NAS signaling security initialization is complete.

[0073] In S438, the mobility management node 11 coordinates with one or more other core network nodes (e.g., HSS) to obtain location update-related information, such as the PDN enrollment context (including, for example, the EPS enrollment Quality of Service (QoS) profile and subscription access point name aggregate maximum bit rate (APN-AMBR)).

[0074] At S440, the mobility management node 11 initiates the establishment of a communication GPRS tunnelling protocol (GTP) tunnel by coordinating with one or more other core network nodes (e.g., S-GW13 and / or P-GW15 or a combination thereof) to send an appropriate session creation request (e.g., to S-GW13) and receiving an appropriate response once the tunnel is established. For example, after S-GW13 sends a corresponding default bearer request to P-GW15 to create a new entry in its EPS bearer context table, a default bearer response is sent from P-GW15 to S-GW13, containing P-GW15's user plane address, P-GW15's tunnel endpoint identifier (TEID) for the user plane and control plane, EPS bearer identification information, and QoS information. P-GW15 also sends downlink data to S-GW13, which is buffered until the connection is complete. An acknowledgment message indicating that a GTP for control (GTP-C) tunnel has been established is typically sent from S-GW13 to mobility management node 11.

[0075] In S442, the mobility management node 11 sends an initial context setup request (including, for example, an S1 interface context setup request, a NAS attachment acceptance request, and a default bearer activation request).

[0076] A UE capability exchange may follow, in which base station 5A (in S444) sends a UE capability query to UE3 (typically using RRC signaling) to request information about the UE's capabilities. In S446, UE3 responds with the requested UE capability information, and in S448, base station 5A provides instructions for this UE capability information to mobility management node 11.

[0077] Next, access stratum (AS) security is established. Specifically, in S450, base station 5A sends an RRC security mode command to UE3 containing the AS integrity protection and encryption algorithm and the "START" parameter. UE3 uses the received information to calculate an appropriate security key and, in S452, sends a message to base station 5A indicating that the RRC security mode is complete. During this stage, an additional signaling radio bearer (SRB2) is established. SRB2 is used for RRC messages and NAS messages containing logged measurement information, all using DCCH logical channels. SRB2 has a lower priority than SRB1 and is configured by base station 5A after security activation.

[0078] The RRC reconfiguration continues, and in S454, base station 5A sends the RRC reconfiguration to UE3 to activate the default radio bearer. UE3 configures itself based on the information in the RRC reconfiguration and sends an RRC reconfiguration complete message in S456. Next, in S458, base station 5A sends a message to mobility management node 11 indicating that the initial context setup is complete. Mobility management node 11 then coordinates with one or more other core network nodes (e.g., S-GW13) to properly correct the bearer and establish a data radio bearer (DRB) for UE communication.

[0079] Although a four-step contention-based RACH procedure is described, it will be understood that UE3 of communication system 1 and base station 5A of RAN5 can also perform a non-contention-based (or "contention-free") procedure in which a dedicated preamble is assigned to UE3 by base station 5A of RAN5. Furthermore, UE3 of communication system 1 and base station 5A of RAN5 can also perform a two-step RACH procedure (for example, as described in the introduction).

[0080] UE3 can trigger the start of the RACH procedure by itself (for example, when UE3 needs to connect to the network), but it should be understood that the start of the RACH procedure may also be triggered by the network. For example, the RACH procedure may be started by a message transmitted via downlink control information (DCI) having an appropriate (e.g., 1_0, etc.) DCI format in the physical downlink control channel (PDCCH), and such a message is generally known as a PDCCH order. The RACH procedure may be started by the base station 5A of RAN5 when handover is required (for example, using a handover command message).

[0081] <UP CIoT EPS Optimization> UE3, the base station 5A of RAN5, and the core network entity of the communication system 1 are configured with each other to implement a plurality of procedures particularly related to UP CIoT EPS optimization, without limitation. These procedures include, for example, procedures for interrupting and resuming the AS (e.g., RRC) connection.

[0082] <Connection Interruption Procedure> As described above, UE3, the base station 5A of RAN5, and the core network entity of the communication system 1 are configured with each other to execute a connection interruption procedure (for example, for interrupting an established RRC connection).

[0083] One such procedure will be described here as an example, with reference to Figure 5, a simplified sequence diagram showing an RRC connection interruption procedure that may be used in communication system 1. This procedure describes the interruption of an RRC connection established for UP CIoT EPS optimization in the context of the 4G entity shown in Figure 3. Nevertheless, it will be understood that a similar procedure may be followed by the corresponding 5G entity (or by a corresponding device of a future generation) for UP CIoT 5GS optimization. The description here is intended to be a summary only, and therefore, it will be understood that not all parameters are enumerated in the message flow.

[0084] As shown in Figure 5, UL data and / or DL ​​data may be communicated via an established RRC connection before the interruption procedure begins.

[0085] In S501, due to one or more triggers (for example, the expiration of the UE inactivity timer), base station 5A of RAN5 decides to suspend the RRC connection.

[0086] In S502, base station 5A initiates the S1-AP UE context interruption procedure by, for example, sending an S1-AP UE context interruption request to notify MME11 that the RRC connection has been interrupted (in the case of 5GS, base station 5A may also initiate the NG-AP UE context interruption procedure by sending an NG-AP UE context interruption request to notify AMF that the RRC connection has been interrupted).

[0087] In S503, MME11 requests S-GW13 to release all S1-U bearers for UE3 (in the case of 5GS, AMF may request SMF to suspend the PDU session, and SMF may request UPF to release the tunnel information for UE3).

[0088] In S504, MME11 (AMF for 5GS) acknowledges the request sent in S502, for example by sending an S1-AP UE context interruption response (or an NG-AP UE context interruption response for 5GS).

[0089] In S505, base station 5A suspends the RRC connection, for example, by sending an RRC connection release message with the release cause set to "rrc-Suspend". The message includes a reactivation identifier held by UE3, and optionally, for transmission using early data transmission (EDT) and Preconfigured Uplink Resource (PUR), the message may also include at least one security parameter (e.g., "NextHopChainingCount" (NCC)) held by UE3 and used to determine the AS security key (in the case of 5GS, the message may also include a radio network temporary identifier (RNTI), such as a so-called inactive RNTI (I-RNTI), along with the security parameter).

[0090] In S506, UE3 remembers the AS context, suspends all SRB and DRB, and enters RRC idle mode / state (RRC_IDLE).

[0091] <Procedure for resuming connection (same base station)> As described above, UE3, base station 5A of RAN5, and the core network entities of communication system 1 are configured to perform connection resumption procedures (for example, to resume a suspended RRC connection).

[0092] Figure 6 is a simplified sequence diagram showing the RRC connection reactivation procedure that can be used in communication system 1, in which a suspended connection (e.g., suspended using a procedure similar to the one described with reference to Figure 5) is reactivated at the same base station 5A from which the original connection was suspended. This procedure describes the reactivation of an RRC connection for UP CIoT EPS optimization in the context of the 4G entity shown in Figure 3. Nevertheless, it will be understood that a similar procedure may be followed by the corresponding 5G entity (or by corresponding devices of future generations) for UP CIoT 5GS optimization. The explanation here is intended to be for illustrative purposes only, and therefore, it will be understood that not all parameters are enumerated in the message flow.

[0093] At some point after the connection has been interrupted (for example, when UE3 is paged or when new data arrives in UE3's uplink buffer), UE3 requests the connection to be resumed in S601, for example, by sending an RRC connection resume request to base station 5A. It will be understood that this may occur after UE3 has performed the random access procedure by sending a random access preamble and receiving a corresponding random access response to obtain the uplink resources for the request. UE3 includes its resume identifier (e.g., "resumeID" (or I-RNTI for 5GS)), the reason for establishment / resumption (e.g., "resumeCause"), and an authentication token (e.g., "shortResumeMAC-I"). The authentication token is calculated in the same way as the short message authentication code-integrity (MAC-I) used in RRC connection re-establishment, enabling base station 5A to verify the UE identity (in the case of 5GS, UE3 may resume SRB1 and re-establish AS security, for example, by deriving a new security key using the NCC provided in the RRC connection release message of the previous RRC connection).

[0094] In S602, if a restart identifier (or I-RNTI for 5GS) exists and the authentication token is successfully validated, base station 5A responds with an RRC connection restart message. The RRC connection restart message includes the NCC value required to re-establish AS security (in the case of EPS).

[0095] In S603, UE3 restarts all SRBs and DRBs and re-establishes AS security (in the case of 5GS, UE3 restarts all other SRBs, i.e., SRB1 which was restarted in S601, and all DRBs). Therefore, UE3 is now in connected mode / state (RRC_CONNECTED).

[0096] In S604, UE3 indicates that the RRC connection has been successfully reactivated, for example, by sending an RRC connection reactivation complete message to base station 5A, along with the uplink buffer status report and / or UL data, whenever possible, confirming that the RRC connection has been successfully reactivated.

[0097] In S605, base station 5A initiates the S1-AP UE context restart procedure and notifies MME11 of the UE state change by, for example, sending an S1-AP UE context restart request message (in the case of 5GS, the base station initiates the NG-AP context restart procedure and notifies AMF of the UE state change by, for example, sending an NG-AP restart request message).

[0098] In S606, MME11 works in conjunction with S-GW13 to activate the S1-U bearer for UE3 (in the case of 5GS, AMF works in conjunction with SMF to restart the PDU session, and SMF works in conjunction with UPF to establish tunnel information for UE3).

[0099] In S607, MME11 (AMF for 5GS) acknowledges the request sent in S605, for example by sending an S1-AP UE context restart response (or by sending an NG-AP restart response for 5GS).

[0100] As shown in Figure 6, after the restart procedure is complete, UL data and / or DL ​​data can be communicated via the restarted RRC connection.

[0101] Therefore, it can be seen that the UE context is stored in UE3, base station 5A of RAN5, and MME11 (or AMF for 5GS) when the connection is interrupted. Mobile originated (MO) and / or mobile terminated (MT) data may trigger the resumption of both RRC and S1 connections (or NG connections for 5GS) at the same base station 5A.

[0102] <Procedure for resuming connection (different base station)> In addition to the restart at base station 5A as described with reference to Figure 6, UE3, RAN5's base station 5A, and the core network entities of communication system 1 are configured to perform a restart procedure to resume the interrupted RRC connection at base station 5A-2, which is different from base station 5A-1 where the original connection was interrupted.

[0103] One such procedure will be described here as an example only, with reference to Figure 7, a simplified sequence diagram showing another RRC connection reactivation procedure that may be used in communication system 1. In this procedure, the connection is reactivated at base station 5A-2, which is different from the original base station 5A-1 from which the original connection was interrupted.

[0104] At some point after the connection is interrupted at the original base station 5A-1 of the original RAN5-1 (for example, when UE3 is paged or when new data arrives at UE3's uplink buffer), UE3 requests the resumption of the connection at the new base station 5A-2 of the new RAN5-2 by sending, for example, an RRC connection resumption request to the new base station 5A-2 in S701. It will be understood that this may occur after UE3 has performed the random access procedure by sending a random access preamble and receiving a corresponding random access response to obtain the uplink resources for the request. UE3 includes its resumption identifier (or I-RNTI for 5GS), the reason for establishment / resumption, and an authentication token (for example, "shortResumeMAC-I"). The authentication token is calculated in the same way as the short message authentication code-integrity (MAC-I) used in RRC connection re-establishment, enabling base station 5A-2 to verify the UE identity (in the case of 5GS, UE3 may restart SRB1 and re-establish AS security, for example, by deriving a new security key using the NCC provided in the RRC connection release message of the previous RRC connection).

[0105] In S702, the new base station 5A-2 uses a restart identifier (or I-RNTI for 5GS) to locate the original base station 5A-1 and initiates the X2-AP (or Xn-AP for 5GS) UE context lookup procedure by sending an X2-AP (or Xn-AP for 5GS) UE context lookup request message to the original base station 5A-1.

[0106] In S703, the original base station 5A-1 responds to the new base station 5A-2 using the UE context associated with the restart identifier (or I-RNTI for 5GS) in the X2-AP (or Xn-AP for 5GS) and obtains a UE context lookup response message.

[0107] In S704, if a restart identifier (or I-RNTI for 5GS) exists and the authentication token is successfully validated, the new base station 5A-2 responds with an RRC connection restart message. The RRC connection restart message includes the NCC value required to re-establish AS security (in the case of EPS).

[0108] In S705, UE3 restarts all SRBs and DRBs and re-establishes AS security (in the case of 5GS, UE3 restarts all other SRBs, i.e., SRB1 which was restarted in S701, and all DRBs). Therefore, UE3 is now in connected mode / state (RRC_CONNECTED).

[0109] In S706, UE3 indicates that the RRC connection has been successfully reactivated, for example, by sending an RRC connection reactivation complete message to the new base station 5A-2, along with the uplink buffer status report and / or UL data, whenever possible, confirming that the RRC connection has been successfully reactivated.

[0110] In S707, the new base station 5A-2 initiates the S1-AP routing procedure (for example, by sending an S1-AP routing request) to establish an S1 UE-related signaling connection to the serving MME11 and request the MME11 to resume the UE context (the serving MME11 may be the same as or different from the MME11 that served the original base station 5A-1). In the case of 5GS, it will be understood that the new base station 5A-2 may also initiate the NG-AP routing procedure (for example, by sending an NG-AP routing request) to establish an NG UE-related signaling connection to the serving AMF and request the AMF to resume the UE context.

[0111] In S708, MME11 works with S-GW13 to activate the S1-U bearer for UE3 and update the downlink path (in the case of 5GS, AMF works with SMF to restart the PDU session, SMF works with UPF to create tunnel information for UE3 and update the downlink path).

[0112] In S709, MME11 (AMF for 5GS) acknowledges the request sent in S707, for example by sending an S1-AP route switching request acknowledgment (or by sending an NG-AP route switching request acknowledgment for 5GS).

[0113] In S710, after the S1-AP route switching procedure, the new base station 5A-2 triggers the release of the UE context at the old base station 5A-1 by, for example, sending an X2-AP UE context release message to initiate the X2-AP UE context release procedure (in the case of 5GS, after the NG-AP route switching procedure, the new base station 5A-2 triggers the release of the UE context at the old base station 5A-1 by, for example, sending an Xn-AP UE context release message to initiate the Xn-AP UE context release procedure).

[0114] As shown in Figure 7, after the restart procedure is complete, UL data and / or DL ​​data can be communicated via the restarted RRC connection.

[0115] Therefore, it can be seen that the UE context is stored in UE3, base station 5A-1 of RAN5-1, and MME11 (or AMF for 5GS) when the connection is interrupted. MO / MT data transmission may trigger the resumption of both RRC and S1 connections (or NG connections for 5GS) at the new base station 5A-2.

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

[0117] Figure 8 schematically shows one such NTN RAN5 that may be used in the communication system 1 of Figure 3.

[0118] As shown in Figure 8, NTN RAN5 includes a base station 5A operating one or more associated cells 9, a gateway 5B, and a non-terrestrial (space or air) platform 5C (including, for example, one or more satellites and / or aircraft), which are sometimes commonly referred to as "satellites" for simplicity. Communications over NTN RAN5 are routed via the core network 7 and the external network 20 (for example, via the appropriate interface (e.g., N6 interface / reference point)).

[0119] NTN RAN5 controls multiple directional satellite beams that can provide associated NTN cells 9. Specifically, each satellite beam has an associated footprint on the Earth's surface that forms an NTN cell 9 or part of an NTN cell 9. Each NTN cell 9 has an associated Physical Cell Identity (PCI). The satellite beam footprint may move as the non-terrestrial (space or air) platform 5C moves along its orbit (e.g., as indicated by arrow A in Figure 8). Alternatively, the satellite beam footprint may be fixed to the Earth, in which case appropriate satellite beam directing mechanisms (mechanical or electronic steering) may be used to compensate for the movement of the non-terrestrial (space or air) platform 5C. In NTN, satellite beams and satellites are not considered to be visible from the perspective of the UE. However, this does not preclude the distinction of network types (e.g., NTN and terrestrial systems) at the public land mobile network (PLMN) level.

[0120] NTN RAN5 base station 5A is configured to provide ephemeris data from a non-terrestrial (space or air) platform 5C to UE3 to assist UE3 in performing measurements and cell selection / reselection and to support initial access. This ephemeris data may include orbital information, such as information at the orbital plane level or satellite level, and / or information (e.g., pointers or indices) that allows for the retrieval of more detailed ephemeris data stored in UE3 (e.g., subscriber identification module "SIM"). At least a portion of this ephemeris information may be provided, for example, in system information, and / or using UE-specific (dedicated) signaling, such as RRC signaling.

[0121] Specifically, base station 5A may provide satellite support information about the satellite as part of a dedicated system information block (SIB) broadcast to UE3 in the corresponding cell 9 of NTN RAN5 (in the case of 5G NTN, this may be, for example, SIB19, but in future generations, it may be provided in a different SIB or in a different way). The satellite support information may include information that identifies at least one relevant NTN configuration (for example, as part of NTN-Config IE). The NTN configuration includes parameters (for example, ephemeris data, common timing alignment parameters, scheduling (e.g., k_offset), validity period of uplink synchronization information, and epoch time (reference time for which the support information is valid)) to help UE3 access the network using NTN access.

[0122] <NTN RANアーキテクチャ> Figures 9A, 9B, and 9C show possible architectures for NTN RAN5 that can be used, respectively.

[0123] The architecture in Figure 9A can be referred to as a “transparent satellite” based RAN architecture. In this architecture, base station 5A is a ground-based base station that sends and receives communications destined for and originating from UE3 via a ground-based gateway 5B and via a non-terrestrial (space or air) platform 5C that does not have base station functionality. The non-terrestrial (space or air) platform 5C relays these communications between UE3s in each cell 9 operated by base station 5A, and, if necessary, between UE3s and gateway 5B. The non-terrestrial (space or air) platform 5C relays these communications transparently without onboard processing, effectively functioning as a so-called “vent pipe.” In this implementation, the feeder link between gateway 5B and the non-terrestrial (space or air) platform 5C effectively functions as part of the respective Uu interface (or reference point) between base station 5A and each UE3. Similarly, the respective service links between the non-terrestrial (space or air) platform 5C and each UE3 effectively function as another part of the respective Uu interface (or reference point) between base station 5A and each UE3. The base station's communication link with the core network 7 (for signaling via, for example, N1, N2, N3 interfaces / reference points, etc.) is provided only on the ground.

[0124] The architecture in Figure 9B can be described as a “regenerative satellite” based RAN architecture (i.e., the satellite performs onboard processing of the payload being communicated between UE3 and core network 7). In this architecture, base station 5A is located on the ground, as is central unit (CU) 5A CU And distributed unit (DU) 5A mounted on non-ground (space or air) platform 5C DU It is a distributed base station 5A having the following: CU5 A located on the ground. CU DU5 A performs some of the functions (typically higher layers) of base station 5A and is not located on the ground. DUexecutes other (typically lower layer) functions of the base station 5A. The CU5 A located on the ground CU is implemented via a suitable interface (e.g., F1 interface) between the gateway 5B and the non-ground (space or air) platform 5C provided to the DU5 A DU communicates with the non-ground located DU5 A via the satellite radio interface between the gateway 5B and the non-ground (space or air) platform 5C provided to the DU5 A DU communicates.

[0125] The non-ground (space or air) platform 5C transmits communications addressed to the UEs 3 within each cell 9 operated by the base station 5A and communications from the UEs 3, and communicates with the gateway 5B as necessary. However, in this implementation form, the lower layer processing of the communications addressed to each UE 3 and the communications transmitted from each UE 3 is executed on the non-ground (space or air) platform 5C by the DU5 A DU and the upper layer processing of the communications addressed to each UE 3 and the communications transmitted from each UE 3 is executed by the CU5 A located on the ground CU by.

[0126] Therefore, in this implementation form, the feeder link between the gateway 5B and the non-ground (space or air) platform 5C effectively functions as the F1 interface (or reference point) between the CU5 A CU and the DU5 A DU of the base station 5A. On the other hand, each service link between the non-ground (space or air) platform 5C and each UE 3 effectively functions as the respective Uu interface (or reference point) between the base station 5A and each UE 3. The communication link of the base station with the core network 7 (for signaling via, for example, N1, N2, N3 interfaces / reference points, etc.) is provided only on the ground.

[0127] The architecture in Figure 9C is sometimes referred to as a "regenerative satellite" based RAN architecture (i.e., the satellite performs onboard processing of payloads communicated between UE3 and the core network 7). In this architecture, base station 5A is mounted on a non-terrestrial (space or air) platform 5C. Base station 5A, mounted on the non-terrestrial (space or air) platform 5C, transmits and receives communications destined for UE3 within each cell 9 operated by base station 5A, as well as communications originating from UE3, to and from the core network 7 via gateway 5B as needed. However, in this implementation, the processing of communications destined for UE3 and communications originating from UE3 is performed by base station 5A on the non-terrestrial (space or air) platform 5C.

[0128] Therefore, in this implementation, the feeder link between Gateway 5B and the non-terrestrial (space or air) platform 5C effectively functions as part of the N1 / N2 / N3 interface (or reference point) between Base Station 5A and Core Network 7. Thus, the base station's communication link with Core Network 7 (e.g., for signaling via N1, N2, N3 interface / reference point, etc.) is provided partly via the feeder link and partly on the ground. On the other hand, each service link between the non-terrestrial (space or air) platform 5C and each UE3 effectively functions as the respective Uu interface (or reference point) between Base Station 5A and each UE3.

[0129] Therefore, base station 5A controls one or more associated cells via a non-terrestrial (space or air) platform 5C. It will be understood that 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.

[0130] For illustration purposes, NTN RAN5 when implemented in communication system 1 will be described with respect to the playback architecture shown in FIG. 9C. However, it will be understood that NTN RAN5 may potentially use a different one of the architectures and the entities of communication system 1 may be adapted accordingly.

[0131] <Extended memory and transfer technology based on UP CIoT EPS optimization> Advantageously, in the case of MO / MT data transmission without a complete end-to-end connection from the UE to the CN / PDN (e.g., as a result of discontinuous coverage / intermediate feeder link connection in the context of NTN deployed RAN5), the communication entities of UE3, base station 5A of NTN RAN5, and core network 7 within communication system 1 implement one or more extended UP CIoT optimization-based features (i.e., an interrupted UE context with configured DRBs can be resumed for data transmission) and are configured with each other to support improved memory and transfer technology.

[0132] Specifically, effective "memory and transfer" data transmission is enabled by one or more extensions to the resume procedure in the "memory and transfer" mode cell 9 (e.g., as described with reference to FIGS. 6 and 7).

[0133] These extensions will be described in more detail later with reference to user plane CIoT EPS optimization, but can be suitably adapted based on CIoT 5GS optimization (or the like).

[0134] In summary, possible extensions include the following. Enabling data transmission via the Uu interface between UE3 and base station 5A to proceed without waiting for the S1 interface to resume, Enabling data transmission via the S1 interface between base station 5A and MME11 to proceed without waiting for the RRC connection to resume, Enhancements to the S1 setup procedure, including the introduction of a new indicator in the S1 setup procedure to support interoperability between base station 5A and core network 7. Paging enhancements include base station 5A maintaining UE paging information at least when downlink data is stored, and the introduction of a new paging trigger in MME11. Introducing support for UE context lookup from the previous "anchor" base station 5A-1 to the new anchor base station 5A-2, which includes the following: Support for storing backups of the anchor base station-side UE context in core network 7. Introduction of anchor base station reassignment procedures triggered by UE, Introduction of a network-triggered anchor base station reassignment procedure, and The use of the UP CIoT-based data “storage and transfer” extension described herein is advantageous in that it reduces security risks, provides increased network control (e.g., the maximum amount of data that can be stored and transferred for a given UE3, and other QoS capabilities), and has the potential to support larger amounts of data in general, which will be advantageous considering that the UE3 may have more data waiting to be transmitted after losing coverage for an extended period.

[0135] <Data Storage and Transfer - Overview> Next, a possible UP CIoT-optimized storage and transfer data transmission flow will be described as a simple example, with reference to Figures 10 and 11.

[0136] In Figures 10 and 11, it will be understood that EDT can potentially be used in conjunction with UP CIoT-based methods (in the same way as described with reference to Figure 5) for only one data packet in one direction for transmission. Nevertheless, for simplicity, EDT is not included in the message flow.

[0137] <Service Link available / Feeder Link unavailable> As described above, one extension makes it possible to proceed with data transmission via the Uu interface between UE3 and base station 5A without waiting for the S1 interface to be reopened. Next, a possible implementation of this will be described, only as an example, with reference to Figure 10.

[0138] Figure 10 is a simplified sequence diagram showing a UP CIoT-optimized data transmission flow between NTN RAN5 base station 5A and communication system 1, which may be used when the service link is available but the feeder link is unavailable.

[0139] In Figure 10, the procedure generally follows the relevant parts of the procedure shown in Figures 5 and 6 (for restart at the same base station 5A) between base station 5A and UE3, and the general explanation relating to the corresponding steps of these procedures also applies here.

[0140] In Figure 10, base station 5A stores / maintains a UE-specific buffer / data area 1030 for each UE3 that base station 5A serves (which, in some cases, has the associated UE capability, is in the permitted list, and / or meets any other criteria). Each UE-specific buffer / data area 1030 contains a set of data type-specific (sub)buffer / data areas 1032, 1034, 1036, and 1038. In this example, the shown data type-specific (sub)buffer / data areas 1032, 1034, 1036, and 1038 include an uplink data buffer 1032 for storing uplink data, a paging storage area 1034 for storing paging information, a downlink data buffer 1036 for storing downlink data, and a UE context storage area 1038 for storing the UE context. Nevertheless, it will be understood that the UE-specific buffer / data area 1030 may be configured to store different sets of information depending on the requirements. For clarity, the UE-specific buffer 1030 is described as being "logically" divided into different (sub)buffers, but it should be understood that in implemented systems, such division into (sub)buffers may still store the same type of information, though this may not be immediately apparent.

[0141] In Figure 10, it is assumed that at the start of the procedure, UE3 is registered / attached to the core network 7 (following a procedure similar to that shown in Figure 4, for example) as shown in S1020, and has a suspended connection (following a procedure similar to that shown in Figure 5, for example). Furthermore, the UE context of UE3 is stored in UE3 (shown in S1040a), base station 5A (shown in S1040b), and MME11 (shown in S1040c) during or after the UE registration / UE attachment procedure. It will be understood that the UE context of UE3 may be stored in multiple base stations 5A.

[0142] In Figure 10, when the service link becomes available, the uplink data (i.e., MO data) at UE3 and / or the downlink data (i.e., MT data) stored in the downlink data buffer 1036 of base station 5A may trigger the resumption of the RRC connection. The uplink data transmitted over the service link is stored in the uplink data buffer 1032 of base station 5A, and the downlink data stored in the downlink data buffer 1036 is transferred over the service link. The storage of the uplink data and / or the transfer of the downlink data occurs substantially immediately after the RRC connection is re-established between UE3 and base station 5A (i.e., the data is stored and / or transferred without waiting for the corresponding S1 connection to be re-established).

[0143] More specifically, once the service link becomes available, at some point (for example, in the case of MT, when UE3 is paged or there is pending data in UE3's uplink buffer, or in the case of MO, when new data arrives in UE3's uplink buffer), UE3 requests the resumption of the connection by, for example, sending an RRC connection resumption request to base station 5A in S1001. This may be after UE3 has performed the random access procedure by sending a random access preamble (as shown in S1000a) and receiving a corresponding random access response (as shown in S1000b) to obtain the uplink resources for the request. UE3 includes its resumption identifier, establishment / resumption reason, and authentication token (for example, "shortResumeMAC-I"), as described with respect to step S601 in Figure 6.

[0144] In the case of MT data, it will be understood that paging-related information may be stored in the paging memory area 1034 to support paging (as shown in S1050b). The base station 5A may be configured to start paging (as shown in S1050a) when the base station 5A predicts that the UE3 has entered coverage and that downlink data is stored in the downlink data buffer 1036.

[0145] In the case of MO data, it will also be understood that UE3 may potentially wait until it is within the coverage of the same base station 5A where the UE connection was first interrupted, before initiating RRC connection reactivation. This base station 5A will have the UE context for UE3, and therefore waiting has the potential benefit of avoiding / reducing the need for UE context reassignment.

[0146] In S1002, assuming that a reactivation identifier exists and the authentication token has been successfully verified, base station 5A responds with an RRC connection reactivation message. The RRC connection reactivation message includes an NCC value (for EPS) for the purpose of re-establishing AS security (for example, as described with respect to step S602 in Figure 6).

[0147] In S1003, UE3 restarts all SRBs and DRBs and re-establishes AS security (for example, as described in step S603 in Figure 6). Therefore, UE3 is now in connected mode / state (RRC_CONNECTED).

[0148] In S1004, UE3 indicates that the RRC connection has been successfully reactivated by sending an RRC connection reactivation completion message to base station 5A, along with the uplink buffer status report and / or UL data, whenever possible, confirming that the RRC connection has been successfully reactivated (for example, as described with respect to step S604 in Figure 6).

[0149] However, unlike the procedure in Figure 6, at this stage, any pending / newly arriving uplink data is transmitted to base station 5A (S1010a) and stored in uplink data buffer 1032 (S1010b), and any downlink data stored in downlink data buffer 1036 is transferred to UE3 without requiring the initiation of the S1-AP context UE restart procedure.

[0150] Following the uplink / downlink data exchange (for example, if no further uplink / downlink data is available and / or if base station 5A determines that the service link will soon become unavailable), instead of initiating the S1-AP context reactivation procedure, base station 5A determines in S1005 that the RRC connection should be suspended (for example, as described with respect to step S501 in Figure 5). At this stage, the suspension procedure is similar to that described with reference to Figure 5, except that it is not necessary to perform the S1-AP UE context suspension procedure (S502 to S504 in Figure 5). Instead, base station 5A suspends the RRC connection in S1006 by sending an RRC connection release message with the release cause set to "rrc-Suspend". The message includes a reactivation identifier stored by UE3, and optionally, the message may also include NCC parameters stored by UE3 and used to determine the AS security key (for example, as described with respect to step S505 in Figure 5).

[0151] In S1007, UE3 stores the AS context (as described, for example, in step S506 in Figure 5), suspends all SRBs and DRBs, and enters RRC idle mode / state (RRC_IDLE).

[0152] <Feeder link available / Service link unavailable> As described above, one extension allows data transmission to proceed via the S1 interface between base station 5A and MME11 without waiting for the RRC connection to be restored. Next, this possible implementation will be described as an example only, with reference to Figure 11.

[0153] Figure 11 is a simplified sequence diagram showing a CIoT-optimized data transmission flow between NTN RAN5 and core network 7 that can be used in communication system 1 when the feeder link is available but the service link is unavailable.

[0154] In Figure 11, this procedure is largely similar to the relevant parts of the procedure shown in Figures 5 and 6 between NTN RAN5 and core network entities such as MME11 and S-GW13, and the general explanation relating to the corresponding steps of that procedure also applies here. It will be understood that the procedures in Figures 10 and 11 are not mutually exclusive and may be used in relation to each other in communication system 1 depending on the service link / feeder link status.

[0155] In Figure 11, base station 5A stores / maintains a separate UE-specific buffer / data area 1030 for each UE3 that base station 5A serves (which, in some cases, has the associated UE capability, is on the permitted list, and / or meets any other criteria), as described with reference to Figure 10. Specifically, each UE-specific buffer / data area 1030 includes an uplink data buffer 1032 for storing uplink data, a paging storage area 1034 for storing paging information, a downlink data buffer 1036 for storing downlinks, and a UE context storage area 1038 for storing the UE context. Nevertheless, it will be understood that the UE-specific buffer / data area 1030 may be configured to store different sets of information depending on the requirements. For clarity, the UE-specific buffer 1030 is described as being "logically" divided into different (sub)buffers, but it will be understood that in implemented systems, such division into (sub)buffers may still store the same type of information, though this may not be immediately apparent.

[0156] In Figure 11, it is assumed that at the start of the procedure, UE3 is registered / attached to the core network 7 (following a procedure similar to that shown in Figure 4, for example) as shown in S1120, and has a suspended connection (following a procedure similar to that shown in Figure 5, for example). Furthermore, the UE context of UE3 is stored in UE3 (shown in S1140a), base station 5A (shown in S1140b), and MME11 (shown in S1140c) during or after the UE registration / UE attachment procedure.

[0157] In Figure 11, when the feeder link becomes available, the uplink data (i.e., MO data) stored in the uplink data buffer 1032 of base station 5A and / or the pending / newly arriving downlink data (i.e., MT data) in the core network 7 can trigger the resumption of the S1 UE context between base station 5A and the core network 7.

[0158] Downlink data transmitted via the feeder link is stored in the downlink data buffer 1036 of base station 5A, and uplink data stored in the uplink data buffer 1032 is transferred via the feeder link. The storage of downlink data and / or the transfer of uplink data takes place substantially immediately after the UE context is re-established between base station 5A and the core network 7.

[0159] Although not shown in the diagram, in the case of MT data, it will be understood that S-GW13, having received a downlink data packet from UE3 from P-GW15, may send a downlink data notification message to MME11, which has control plane connectivity to a given UE3. Similarly, MME11 may respond to S-GW13 with a downlink data notification acknowledgment message. MME11 can then determine which base station 5A's coverage UE3 is (next) in and which base station 5A stores the UE context of UE3.

[0160] Furthermore, in the case of MT data, when there is data waiting to be transmitted to UE3, MME11 may determine that UE3 is within coverage of base station 5A (and that UE3's UE context is stored there), and a feeder link between MME11 and base station 5A is available, and there may be other ways in which the UE context can be resumed via the S1 interface.

[0161] In one optional choice (shown in box (A) of Figure 11), MME11 may send a paging message to base station 5A (as shown in S1100). Base station 5A may store the paging information and initiate the S1-AP UE context restart procedure by sending an S1-AP UE context restart request message (as shown in S1101a). MME11 may coordinate with S-GW13 to activate the S1-U bearer for UE3 (as shown in S1102a). MME11 can then acknowledge the request sent in S1101a by sending an S1-AP UE context restart response (as shown in S1103a).

[0162] In another optional choice (shown in box (B) of Figure 11), base station 5A's MME paging may be skipped, and instead, MME 11 may initiate the UE context restart procedure by sending an S1-AP UE context restart message to base station 5A (as shown in S1101b). In this case, MME 11 can still work in coordination with S-GW 13 to activate the S1-U bearer for UE3 (as shown in S1102b). Base station 5A may respond to the restart message sent in S1101b by sending an S1-AP UE context restart complete message (as shown in S1103b).

[0163] For MO data, base station 5A may simply initiate the UE context restart procedure shown in box (A) (without paging) by sending an S1-AP UE context restart request message (as shown in S1101a). MME11 may coordinate with S-GW13 to activate the S1-U bearer for UE3 (as shown in S1102a). MME11 may then acknowledge the request sent in S1101a by sending an S1-AP UE context restart response (as shown in S1103a).

[0164] When the UE context is resumed during that time, any uplink data stored in the uplink data buffer 1032 of the base station 5A may be transferred to the core network 7 (as shown in S1110), and any pending / newly arrived downlink data may be transmitted to the base station 5A (as shown in S1012) and stored in the downlink data buffer 1036.

[0165] Following the uplink / downlink data exchange (e.g., if there is no further uplink / downlink data and / or if the base station 5A determines that the service link will soon become unavailable), the base station 5A determines in S1104 that the S1 connection should be interrupted. At this stage, the same interruption procedure as described with reference to FIG. 5 is followed. Specifically, in S1105, the base station 5A starts the S1-AP UE context interruption procedure by transmitting, for example, an S1-AP UE context interruption request (as described with respect to step S502 in FIG. 5). In S1106, the MME 11 requests the S-GW 13 to release all S1-U bearers for the UE 3 (as described with respect to step S503 in FIG. 5). In S1107, the MME 11 acknowledges the request transmitted in S1105, for example, by transmitting an S1-AP UE context interruption response (as described with respect to step S504 in FIG. 5).

[0166] <S1 Setup Procedure> As described above, the communication system 1 can implement an extension to the S1 setup procedure. The purpose of the S1 setup procedure is to exchange the application level data necessary for the base station 5A and the MME 11 to operate correctly on the S1 interface. The S1 procedure is the first S1-AP procedure triggered after the transport network layer (TNL) association becomes operational. This procedure uses non-UE related signaling.

[0167] More specifically, in this exemplary extension, base station 5A and MME11 are configured to perform an extended S1 setup procedure for use, for example, after the feeder link is available but before any UE-related signaling occurs. Specifically, to ensure support for multi-vendor networks (RAN5 and core network7), the extended S1 setup procedure allows at least one of the messages used during the S1 setup procedure to include instructions regarding network capability / support for storage and forwarding data transmission.

[0168] This will be explained in more detail as an example, with reference to Figure 12, a simplified sequence diagram showing the S1 setup procedure.

[0169] As seen in S1200, in one optional case, the S1 setup request includes an information element to indicate capability / support for storage and transfer data transmission. For example, the information element may indicate support for "storage transfer mode," "discontinuous feeder link," "intermittent NTN connection," and "UE context interruption-resumption for NTN." The information element may be an enumeration type indicating "true" or "false" for capability / support. If the feature is supported by MME11, MME11 may respond with a normal S1 setup response message (as seen in S1202a). If the feature is not supported by MME11, MME11 may respond with an S1 setup failure message (as seen in S1202b).

[0170] As seen in S1210, in another optional case, a normal S1 setup request is sent, and the MME11 can respond with an S1 setup response message (as seen in S1212) that includes information elements to indicate the capability / support for storage and transfer data transmission. For example, the information elements may indicate support for "storage transfer mode," "discontinuous feeder link," "intermittent NTN connection," or "discontinuous S1 connection for NTN." The information elements may be, for example, an enumeration type indicating "true" or "false" for capability / support.

[0171] <paging> As described above, communication system 1 may implement one or more paging extension means. Several possible paging extension means will be described in detail here as just one example.

[0172] As described above, in order to support paging of UE3 when there is no feeder link / S1 connection, paging-related information can be stored in base station 5A (for example, in paging memory area 1034), so that when base station 5A predicts that UE3 has entered coverage and that there is downlink data in the downlink data buffer 1036 for transmission, base station 5A can start paging.

[0173] It will be understood that there are several different ways in which paging-related information can be obtained from MME11 by base station 5A.

[0174] For example, paging-related information may be included as part of the stored UE context, and the paging-related information may be transmitted to / updated at base station 5A during the UE context management procedure. In this case, there may not be separate and distinct storage of paging information and UE context within the UE buffer 1038.

[0175] Alternatively or additionally, paging-related information may be included as part of a message sent by MME11 as part of the UE context resume / suspend procedure if MME11 recognizes that there is (or is likely to be) downlink data stored in base station 5A (e.g., download data buffer 1036) for “storage and transfer” data transfer. For example, paging-related information may be included in one or more of the UE context resume / suspend response messages from MME11 shown in Figure 11 (e.g., in S1103a, S1101a, and / or S1105). In this case as well, there may not be separate storage of paging information and UE context in UE buffer 1038.

[0176] Alternatively or additionally, paging-related information may be included as part of a “paging message” sent from MME11 to base station 5A before and / or after the UE context restart procedure (for example, as shown in S1100 in Figure 11). For example, the “paging message” may be sent when a downlink data notification is received at MME11 and the feeder link becomes available to base station 5A, which is attempting to transmit downlink data for “storage and transfer” data transfer. This may be followed by the UE context restart procedure (for example, as described with reference to box (A) in Figure 11). However, alternatively or additionally, if there is downlink data to be transmitted to base station 5A for “storage and transfer” data transmission, MME11 may send a “paging message” to base station 5A after base station 5A has initiated the context restart procedure. In this case, this may be advantageous because the paging message / information may not yet be available at base station 5A.

[0177] Regarding the behavior of base station 5A, instead of triggering paging via the air interface immediately after receiving the "paging message" and / or related paging information, base station 5A may simply store the paging information for later use (for example, when the service link becomes available).

[0178] <Anchor eNB reassignment and UE context fetch> As described above, in one extension, the communication system 1 may provide support for UE context lookup from the previous "anchor" base station 5A to the new anchor base station 5A.

[0179] In this context, the term "anchor" base station 5A is used to refer to the base station 5A where the RRC connection was last interrupted and where the UE AS context is stored. Therefore, the RRC connection resumption procedure can generally be performed on such an anchor base station 5A without having to perform a UE context fetch.

[0180] In this regard, there may be cases where an X2 interface is not available via the inter-satellite link, and therefore, in the case of NTN RAN5, normal UE context lookup between base stations 5A may not be possible, and it will be understood that these extensions are intended to address this problem.

[0181] "Storage and Transfer": To support UE context lookup between different base stations 5A within NTN RAN5, a backup of the anchor base station's UE context can be stored in the core network 7 (and maintained to keep it up-to-date). When a reassignment of an anchor base station 5A is required, the new anchor base station 5A may retrieve the UE context directly from the MME 11 (i.e., retrieve the stored backup version). The UE context in the original anchor base station 5A may then be released when the feeder link between the original anchor base station 5A and the core network 7 becomes available.

[0182] Next, referring to Figures 13 to 15, we will describe in more detail some of the procedures for supporting UE context lookup between different base stations 5A in NTN RAN5 under "Storage and Transfer".

[0183] <Anchor base station-side UE context backup stored in the core network> Figure 13 is a simplified sequence diagram showing a first procedure in the communication system 1 that supports UE context lookup between different base stations 5A, where a backup of the anchor base station-side UE context can be stored in the core network 7.

[0184] As shown in Figure 13, at the start of the procedure, it is assumed that UE3 is registered / attached to the core network 7 (for example, by following a procedure similar to that shown in Figure 4) as shown in S1320. UE3 was previously connected to the first base station 5A-1 when the service link was available and has terminated that connection (for example, when the service link was about to become unavailable). Thus, the first base station 5A-1 may be considered the anchor base station 5A-1 for future reactivation procedures, and the corresponding MME11 may be considered the anchor MME11. The relevant UE context for UE3 (including, e.g., resumeID, NextHopChainingcount, etc.) is stored in UE3 (as shown in S1340a). Similarly, the anchor base station-side UE context (including, e.g., resumeID, NextHopChainingcount, etc.) is stored in anchor base station 5A-1 (as shown in S1340b), and the anchor MME-side UE context is stored in MME11 (as shown in S1340c).

[0185] If the interrupted connection is resumed and then interrupted again (for example, by following a procedure similar to the one shown in Figure 10), the updated UE context may be stored in the anchor base station 5A-1 (for example, in the UE context storage area 1038 of the UE-specific buffer 1030), as shown in S1301.

[0186] When the feeder link between the first base station 5A-1 and MME11 becomes available (as illustrated with reference to box (A) in Figure 11, for example) and the S1-AP UE context is resumed, the UE context resume request includes a container that carries an updated version of the base station-stored UE context (including, for example, a new resumeID, NextHopChainingcount, etc.).

[0187] MME11 stores a copy of the updated version of the base station stored UE context, as shown in S1360, which serves as a backup version to look up if UE3 wishes to resume connectivity at a different base station than anchor base station 5A-1 (e.g., base station #2 5A-2). If a feeder link between anchor base station 5A-1 and MME11 is available, a previous (e.g., original or previously updated) version of the base station stored UE context may also be stored in MME11 following a previous interruption using a similar procedure, and this previous version may be replaced by the updated version. Specifically, the original / previously updated version of the base station-side UE context may have been provided to MME11 using a UE context resume request during a previous S1-AP UE context resume procedure. Furthermore, updated / original UE context information may also be provided alternatively / additionally in a different message from anchor base station 5A-1 (e.g., in the UE context resume complete message or UE context interruption request message in the CN-led context resume procedure shown in box (B) of Figure 11).

[0188] As described with reference to FIG. 11, then, the MME 11 can activate the S1-U bearer for the UE 3 in cooperation with the S-GW 13 (as shown in S1302). Then, the MME 11 can acknowledge the request transmitted in S1301, for example, by transmitting an S1-AP UE context resume response (as shown in S1303).

[0189] (Following the uplink / downlink data exchange (in S1310 and / or S1312), the anchor base station 5A-1 determines in S1304 that the S1 connection should be interrupted. At this stage, the same interruption procedure as described with reference to FIG. 5 is followed. Specifically, in S1305, the anchor base station 5A-1 starts the S1-AP UE context interruption procedure, for example, by transmitting an S1-AP UE context interruption request (as described with respect to step S502 in FIG. 5). In S1306, the MME 11 requests the S-GW 13 to release all S1-U bearers for the UE 3 (as described with respect to step S503 in FIG. 5, for example). In S1307, the MME 11 acknowledges the request transmitted in S1305, for example, by transmitting an S1-AP UE context interruption response (as described with respect to step S504 in FIG. 5, for example).

[0190] Therefore, in summary, in this example, it can be seen that the MME 11 maintains a backup of the anchor base station side UE context. If there is any change (e.g., NCC, resumeID) after the UE 3 reconnects to the anchor base station 5A-1 and interrupts the connection to the anchor base station 5A-1, the anchor base station 5A-1 updates the MME 11 with the updated UE context.

[0191] <UE-triggered Reallocation of Anchor Base Station> Figure 14 is a simplified sequence diagram illustrating a second procedure for supporting UE context lookup between different base stations 5A in communication system 1, in which anchor base station reassignment from the first base station 5A-1 to the second base station 5A-2 is triggered by UE3.

[0192] In this example, UE3 can favorably trigger a procedure to reassign the anchor base station from the first base station 5A-1 to the second base station 5A-2, in the meantime, retrieve the base station-side UE context from MME11 and store it in the second base station 5A-2. Thus, UE3 can resume the RRC connection to the second base station 5A-2. Nevertheless, UE3 may be configured to restrict attempts to connect to a different base station 5A unless necessary, for example, it would be understood that UE3 is configured to attempt to reconnect to the original anchor base station 5A-1 unless UE3 is not within the coverage of the original anchor base station for a very long period of time (e.g., network configuration / pre-configured period) and / or the different base station 5A-2 becomes available more regularly than the original anchor base station 5A-1.

[0193] As shown in Figure 14, at the start of the procedure, it is assumed that UE3 is registered / attached to the core network 7 (for example, by following a procedure similar to that shown in Figure 4) as shown in S1420. UE3 was previously connected to the first base station 5A-1 when the relevant service link was available and terminated that connection (for example, when the service link was about to become unavailable). Thus, the first base station 5A-1 is the anchor base station 5A-1. The relevant UE context for UE3 is stored in UE3 (as shown in S1440a), and the anchor base station-side UE context is stored in anchor base station 5A-1 (as shown in S1440b). The MME-UE context is stored in MME11 (S1440c). In this example, the UE context information stored in MME11 includes a backup anchor base station-side UE context (as shown in S1460) by following a procedure similar to that shown in Figure 13 for storing / updating the anchor base station-side UE context.

[0194] When the service link becomes available to the second base station 5A-2, UE3 sends a message to the second base station 5A-2 in S1401 indicating that a change of anchor base station is requested. The message may be a conventional request for resuming the connection (e.g., an RRC connection resumption request, which may include a dedicated resumption cause indicating that the connection is for requesting an anchor change). The message may contain the same, or at least a related subset of, the information provided in the RRC connection resumption request (e.g., "resumeID", "resumeCause", and / or "shortResumeMAC-I"). Nevertheless, the message may trigger a change of anchor base station, for example, based on the resumption cause or based on a resumeID that points to a different base station (e.g., a first base station 5A-1) than the base station 5A-2 on which the connection is being made.

[0195] It will be understood that a message indicating a request for a change in the anchor base station may be sent after the UE3 has performed the random access procedure by sending a random access preamble (as shown in S1400a) and receiving a corresponding random access response (as shown in S1400b) to obtain the uplink resources for the request.

[0196] In S1430, the second base station 5A-2 determines that the context is unavailable and / or that a context fetch is required, and in S1402, sends a message to UE3 acknowledging / responding to the message sent in S1401 indicating that a change of anchor base station is requested. This message may be an RRC connection resumption denial message, an RRC connection denial message, or a dedicated anchor base station change response message. As shown, the message may include cause values ​​or other parameters indicating that base station 5A-2 is waiting for a serving / anchor base station reassignment or a UE context fetch. Thus, UE3 is released into idle mode while waiting for the feeder link between the second base station 5A-2 and MME11 to become available and for the context fetch procedure to be executed.

[0197] The second base station 5A-2 waits for the feeder link between the second base station 5A-2 and MME11 to become available. Once available, the second base station 5A-2 initiates the S1-AP procedure to perform route switching in S1403, searching for the (backup) UE base station-side context (for example, by sending an S1-AP search UE context and route switching request). This establishes an S1 UE-related signaling connection to the serving MME11 and requests MME11 to resume the UE context. In S1404, MME11, in coordination with S-GW13, activates the S1-U bearer for UE3 and updates the downlink route.

[0198] In S1405, MME11 responds to the request sent in S1405 (for example, by sending the S1-AP search UE context and route switching response) using an information container that carries the stored base station-side UE context of the previous anchor base station 5A-1. Thus, the second base station 5A-2 can store this UE context in the UE context storage area 1038 of the UE-specific buffer 1030 for UE3. Consequently, when UE3 next attempts to re-establish an RRC connection with the second base station 5A-2 when the corresponding service link is available, UE3 can successfully follow a procedure similar to that shown in Figure 10 to do so.

[0199] At this stage, in S1412, MME11 may forward any downlink data for UE3 to the second base station 5A-2 to be stored in the downlink data buffer 1036 of the UE-specific buffer 1030 for UE3. Subsequently, the second (new anchor) base station 5A-2 may determine in S1406 that the S1 connection should be interrupted. At this stage, the interruption procedure is similar to that described with reference to Figure 5. Specifically, in step S1407, the new anchor base station 5A-2 initiates the S1-AP UE context interruption procedure by sending an S1-AP UE context interruption request, for example (as described with reference to step S502 in Figure 5). In S1408, MME11 requests S-GW13 to release all S1-U bearers for UE3, for example (as described with reference to step S503 in Figure 5). In S1409, MME11 acknowledges the request sent in S1407 by sending, for example, an S1-AP UE context interruption response, as described in relation to step S504 in Figure 5.

[0200] Subsequently, if the feeder link between the original base station 5A-1 and MME11 is available, the UE context may be released from that base station 5A-1, as shown in S1470.

[0201] Therefore, in summary, in this example, UE3 triggers a procedure in which the second base station 5A-2 waits until a feeder link between the second base station 5A-2 and MME11 becomes available in order to retrieve a backup of the UE context stored in the anchor base station 5A-1 from MME11. After the retrieval, MME11 releases the UE context from the previous anchor base station 5A-1 when the feeder link between the first base station 5A-1 and MME11 becomes available. The second base station 5A-2 becomes the new anchor base station 5A-2, and UE3 should be able to successfully resume the RRC connection to the second base station 5A-2 for data transmission once the corresponding service link becomes available.

[0202] <Core Network CN Trigger Anchor Base Station Reassignment> Figure 15 is a simplified sequence diagram illustrating a third procedure to support UE context lookup between different base stations 5A in the communication system 1, in which the reassignment of an anchor base station for UE3 from the first base station 5A-1 to the second base station 5A-2 is triggered by the communication system 1.

[0203] In this example, MME11 can advantageously trigger a procedure to reassign the anchor base station 5A-1 for a given UE3 from the first base station 5A-1 to the second base station 5A-2, while simultaneously transferring the base station-side UE context from MME11 to the second base station 5A-2. Thus, its UE3 can resume RRC connectivity to the second base station 5A-2, even if it had not previously connected to the second base station 5A-2.

[0204] As shown in Figure 15, at the start of the procedure, it is assumed that UE3 is registered / attached to the core network 7 (for example, by following a procedure similar to that shown in Figure 4) as shown in S1520. UE3 was previously connected to the first base station 5A-1 when the relevant service link was available and disconnected that connection (for example, when the service link was about to become unavailable). Thus, the first base station 5A-1 is the anchor base station 5A-1 for its UE3. The relevant UE context for UE3 is stored in UE3 (as shown in S1540a), and the anchor base station-side UE context is stored in anchor base station 5A-1 (as shown in S1540b). The MME-UE context is stored in MME11 (S1540c). In this example, the UE context information stored in MME11 includes a backup anchor base station-side UE context (as shown in S1560) by following a procedure similar to that shown in Figure 13 for storing / updating the anchor base station-side UE context.

[0205] MME11 decides to reassign the anchor base station 5A for UE3 from the first base station 5A-1 to the second base station 5A-2, as shown in S1550. If the feeder link between the first base station 5A-1 and MME11 is available, MME11 releases the UE context at the first base station 5A-1, as shown in S1555. Although the context release is shown and described as occurring before the reassignment of the context to the second (new anchor) base station 5A-2, it will be understood that MME11 may wait to release the UE context from the first base station 5A-1 until the reassignment of the context to the second base station 5A-2 is complete.

[0206] MME11 waits for the feeder link between the second base station 5A-2 and MME11 to become available. Once available, MME11 sends an S1-AP message in S1501 that includes an information container carrying the stored base station-side UE context of the previous anchor base station 5A-1. Thus, the second base station 5A-2 can store this UE context in the UE context storage area 1038 of the UE-specific buffer 1030 for UE3. Therefore, if UE3 attempts to re-establish an RRC connection with the second base station 5A-2 when the corresponding service link is available, UE3 can successfully follow a procedure similar to that shown in Figure 10 to do so.

[0207] The second base station 5A-2 may acknowledge the message received in S1501 using an appropriate S1-AP acknowledgment message, as shown in S1502 (however, such acknowledgment may not be necessary).

[0208] At this stage, in S1512, MME11 may forward any downlink data to UE3 to the second base station 5A-2 for storage in the downlink data buffer 1036 of the UE-specific buffer 1030 for UE3. Subsequently, the S1-AP context is interrupted using an appropriate interruption procedure (as described, for example, with reference to steps S1406 to S1409 in Figure 14).

[0209] Therefore, once a service link becomes available between UE3 and the second (new anchor) base station 5A-2, UE3 can re-establish its connection with the second base station 5A-2.

[0210] In an exemplary procedure, as shown in S1506, UE3 resumes the connection in response to base station 5A-2 paging UE3 based on paging-related information provided during the UE context transfer procedure and stored in the second base station 5A-2 (e.g., in paging memory area 1036 and / or as part of the UE context). In response to paging, UE3 performs a random access procedure by sending a random access preamble (as shown in S1507a) and receiving a corresponding random access response (as shown in S1507b) to obtain uplink resources for the connection request. UE3 then requests the resumption of the connection by sending an RRC connection resumption request to base station 5A-2 in S1508, for example. UE3 includes its resumption identifier, establishment / resumption reason, and authentication token (e.g., "shortResumeMAC-I") in the request. The resumption procedure may then proceed between UE3 and the second base station 5A-2, as described with reference to Figure 10.

[0211] <Overall Attach-Resume-Suspend Flow> Therefore, it can be seen that communication system 1 may include one or more extensions based on UP CIoT optimization-based resume and / or interruption procedures to support improved storage and transfer technologies.

[0212] In summary, a typical sequence of events that may occur in communication system 1 is illustrated here only as an example, with reference to Figure 16, a simplified sequence diagram showing the overall attach-resume-suspend flow that may occur in communication system 1.

[0213] It should be understood that the overall flow is generalized for illustrative purposes and does not detail all messages and related information exchanged between various communication entities within a fully implemented system.

[0214] In Figure 16, we assume that the procedure begins with UE3 attached / registered (in S1600), following the UE attach / register procedure (as described, for example, with reference to Figure 4). Base station 5A has released the previous RRC connection for UE3 and is remembering the UE context (including the S-TMSI), as seen in S1610.

[0215] As shown in S1650, when the feeder link is unavailable but UE3 has some uplink data (MO data) to transmit, UE3 establishes a connection in cooperation with base station 5A in S1612 (as described with reference to, for example, Figure 10). Then, in S1614, base station 5A checks to verify UE3 that the UE context (e.g., S-TMSI) matches the stored context and checks whether a “storage transfer” data transfer based on UP CIoT EPS optimization (e.g., based on UE capabilities, etc.) can be used. In S1616, base station 5A activates AS security (e.g., via an AS SMC procedure using the stored security context, as described with reference to, for example, Figure 4).

[0216] UE3 transmits the UL data to base station 5A, and base station 5A stores the UL data (for example, as described in the uplink data buffer 1032 as shown in Figure 10).

[0217] Base station 5A, for example, as described with reference to Figure 10, makes a decision in S1620 to suspend the RRC connection (for example, because the service link is about to drop), and releases the RRC connection with suspension in S1622 by sending an RRC connection release (with a cause value (e.g., "rrc-Suspend") indicating that the release is for the purpose of suspending the connection) to UE3.

[0218] As shown in S1660, if the service link is unavailable but the feeder link is available (i.e., following a switch from the service link to the feeder link), base station 5A sends an initial UE message to MME11 in S1624 (which occurs, for example, in a normal call flow following an RRC connection, as described with reference to Figure 4, but in this case there is no (active) RRC connection). MME11 responds appropriately, and MME11 and base station 5A coordinate with each other to perform the initial context setup as seen in S1626.

[0219] Next, base station 5A can transfer the stored uplink data to S-GW13 (via MME11) as seen in S1628 (for example, as described with reference to Figure 11).

[0220] When there is no more uplink data to transmit, base station 5A initiates the UE context interruption procedure by sending a UE context interruption request in S1630 to notify MME 11 that the connection has been interrupted (for example, as described with respect to step S502 in Figure 5). Although not shown, MME 11 may then proceed, in coordination with S-GW 13, to release all S1-U bearers for UE3 and acknowledge the request sent in S1630 as described above.

[0221] <User Equipment> Figure 17 is a simplified block diagram showing the main components of UE3 for implementation in the system shown in Figure 3.

[0222] As shown, UE3 has a transceiver circuit 31 capable of operating to send and receive signals to and from base station 5A via one or more antennas 33 (e.g., having one or more antenna elements). UE3 has a controller 37 that controls the operation of UE3. The controller 37 is associated with memory 39 and coupled to the transceiver circuit 31. Although not necessarily required for the operation of UE3, UE3 may, of course, have all the usual functions of a conventional UE3 (e.g., a user interface 35 such as a touchscreen / keypad / microphone / speaker to enable direct user control and interaction with the user), which may be provided, as appropriate, by one or any combination of hardware, software, and firmware. The software may be pre-installed in memory 39 and / or downloaded, for example, via communication system 1 or from a removable data storage device (RMD).

[0223] In this example, the controller 37 is configured to control the overall operation of the UE3 by program instructions or software instructions stored in memory 39. As shown in the figure, these software instructions include, among other things, the operating system 41 and the communication control module 43.

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

[0225] It will be understood that the communication control module 43 may include multiple submodules ("layers" or "entities") to support specific functions. For example, the communication control module 43 may include a PHY submodule, a MAC submodule, an RLC submodule, a PDCP submodule, an RRC submodule, and so on.

[0226] The communication control module 43 is configured, in particular, to control the communications of the UE in accordance with any of the methods described herein.

[0227] <Base station> Figure 18 is a simplified block diagram showing the main components of base station 5A for implementation in the system of Figure 3 (for example, in the NTN access network or other such RAN5).

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

[0229] As shown in the figure, these software instructions include, in particular, an operating system 61 and a communication control module 63.

[0230] The communication control module 63 is operable to control communication between base station 5A, UE3, and other network entities (e.g., core network nodes) communicating with base station 5A. The communication control module 63 is configured to generally control the reception and decoding of uplink communications via associated uplink channels (e.g., via the physical uplink control channel (PUCCH), random-access channel (RACH), and / or physical uplink shared channel (PUSCH)), which include both dynamic and quasi-static signaling (e.g., SRS). The communication control module 63 is also configured to generally control the transmission of downlink communications via associated downlink channels (e.g., via the physical downlink control channel (PDCCH) and / or physical downlink shared channel (PDSCH)), which include both dynamic scheduling and semi-persistent scheduling (e.g., SPS). The communication control module 63 is responsible for, for example, determining where to configure UE3 to monitor downlink control information (e.g., the locations of the search space, CORESET, and associated PDCCH candidates to monitor), determining resources to be scheduled for UE transmission / reception of UL / DL communications (including interleaved resources and resources subject to frequency hopping), managing frequency hopping on the base station 5A side, appropriately configuring slots / symbols (e.g., for UL, DL, or full-duplex communications), configuring the bandwidth portion of UE3, and providing relevant configuration signaling to UE3.

[0231] It will be understood that the communication control module 63 may include multiple submodules ("layers" or "entities") to support specific functions. For example, the communication control module 63 may include a PHY submodule, a MAC submodule, an RLC submodule, a PDCP submodule, an RRC submodule, etc., in order to communicate with the UE3. Furthermore, the communication control module 63 may include S1 application protocol (S1-AP) submodules, stream control transmission protocol (SCTP) submodules, IP submodules, layer 1 (L1) submodules, layer 2 (L2) submodules, etc. (or corresponding submodules for communicating with AMF) for communicating with core network entities such as MME11 (or similar nodes such as AMF).

[0232] The communication control module 63 is configured to control the base station's communications, in particular, according to one of the methods described herein.

[0233] <Core network node / function> Figure 19 is a block diagram showing the main components of a core network node or function, such as MME11, S-GW13, or P-GW15 (or a functionally similar node / function for 5G or other cellular technologies, such as AMF, CPF, UPF, SMF, etc.).

[0234] As shown, the core network function includes a transceiver circuit 71 capable of transmitting and receiving signals to and from other nodes (including UE3, base station 5A, and other core network nodes) via the network interface 72. The controller 73 controls the operation of the core network function according to software stored in memory 74. The software may be pre-installed in memory 74 and / or downloaded, for example, via the communication system 1 or from a removable data storage device (RMD). The software includes, among other things, an operating system 75 and a communication control module 76.

[0235] The communication control module 76 is responsible for handling (generating / transmitting / receiving) signaling between the core network functions and other nodes such as UE3, base station 5A, and other core network nodes.

[0236] It will be understood that the communication control module 63 may include multiple submodules ("layers" or "entities") to support specific functions. For example, if the core network node is implemented as MME11 (or AMF in the case of 5G), the communication control module 76 may include an S1-AP submodule, an SCTP submodule, an IP submodule, an L1 submodule, an L2 submodule, etc. (or the corresponding submodule in the case of AMF) to communicate with the base station 5A.

[0237] The communication control module 76 is configured to control communication of the core network nodes, in particular, according to one of the methods described herein.

[0238] <Variations and alternative examples> Detailed examples are given above. As those skilled in the art will understand, several modifications and substitutions can be made to the above examples while still benefiting from the disclosures embodied herein.

[0239] It will be understood that the descriptions of the features of base station 5A (or eNB or gNB), NTN node, and UE3, and the operations performed by them, may apply equally to base station 5A and UE3 communicating only in the terrestrial plane (i.e., as part of a terrestrial RAN5 that does not have features of NTN RAN5 such as gateway 5B and space or airborne platforms) as to base station 5A communicating via a non-terrestrial plane.

[0240] Furthermore, the description of the characteristics of base station 5A (or eNB or gNB) and the operations performed by base station 5A applies equally to distributed base station 5A as it does to non-distributed base station 5A.

[0241] Furthermore, while we have described information elements with specific names, it should be understood that information elements with different names but serving similar purposes can also be used.

[0242] In the above description, UE3 and base station 5A are described as having multiple separate functional components or modules for ease of understanding. These modules may be provided in this way in certain applications, for example, where an existing system is modified to implement the present disclosure, but in other applications, such as systems designed from the outset with the features of the present invention in mind, these modules may be incorporated into the overall operating system or code, and therefore these modules may not be identifiable as separate entities.

[0243] The above example described several software modules. As those skilled in the art will understand, these software modules can be provided in compiled or uncompiled form and supplied to the UE3 or base station 5A as signals over a computer network or on a recording medium. Furthermore, some or all of the functions performed by this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred because it facilitates updating the UE3 or base station 5A to update its functions.

[0244] Each controller may include, but is not limited to, one or more hardware-implemented computer processors, microprocessors, central processing units (CPUs), arithmetic logic units (ALUs), input / output (IO) circuits, internal memory / cache (programs and / or data), processing registers, communication buses (e.g., control buses, data buses and / or address buses), direct memory access (DMA) functions, hardware or software-implemented counters, pointers and / or timers, and any other suitable form of processing circuitry. Various other modifications are obvious to those skilled in the art and will not be described in further detail here.

[0245] In this disclosure, user equipment (or "UE," "mobile station," "mobile device," or "wireless device") is an entity connected to a network via a wireless interface.

[0246] Furthermore, as explained below, this disclosure is applicable not only to dedicated communication devices but also to any device having communication capabilities.

[0247] The terms “User Equipment” or “UE” (as used by 3GPP), “Mobile Station,” “Mobile Device,” and “Radio Device” are generally intended to be synonymous with each other and include standalone mobile stations such as terminals, cell phones, smartphones, tablets, cellular IoT devices, IoT devices, and machines. The terms “Mobile Station” and “Mobile Device” will be understood to also include devices that remain stationary for extended periods.

[0248] UE may be items of equipment for production or manufacture and / or items of energy-related machinery, such as equipment or machinery (including boilers, engines, turbines, solar panels, wind turbines, hydroelectric generators, thermal generators, nuclear generators, batteries, nuclear systems and / or related equipment, heavy electrical machinery, pumps including vacuum pumps, compressors, fans, blowers, hydraulic equipment, pneumatic equipment, metalworking machinery, manipulators, robots and / or their application systems, tools, molds or dies, rolls, conveying equipment, elevators, material handling equipment, textile machinery, sewing machinery, printing and / or related machinery, paper conversion machinery, chemical machinery, mining machinery and / or construction machinery and / or related equipment, machinery and / or equipment for agriculture, forestry and / or fisheries, safety and / or environmental protection equipment, tractors, precision bearings, chains, gears, power transmission equipment, lubrication equipment, valves, pipe fittings and / or application systems for any of the aforementioned equipment or machinery, etc.).

[0249] UE may be items of transport equipment, such as (railway cars, automobiles, motorcycles, bicycles, trains, buses, carts, rickshaws, ships and other vessels, aircraft, rockets, satellites, drones, balloons, and other transport equipment).

[0250] UE may be, for example, an item of information and communication equipment (such as electronic computers and related equipment, communication and related equipment, electronic components, etc.).

[0251] The UE may be, for example, a refrigerator, a refrigeration appliance product, an item of trading and / or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, (such as a home appliance and electronic device like audio equipment, video equipment, loudspeaker, radio, television, microwave oven, rice cooker, coffee machine, dish washer, washing machine, dryer, electric fan or related equipment, vacuum cleaner, etc.).

[0252] The UE may be, for example, an electrical application system or equipment (such as an electrical application system or equipment like an X-ray system, particle accelerator, radioisotope equipment, sonic equipment, electromagnetic application equipment, electrical power application equipment, etc.).

[0253] The UE may be, for example, an electronic lamp, lighting fixture, measuring instrument, analyzer, tester, or detecting or sensing instrument (such as a detecting or sensing instrument like a smoke alarm, human alarm sensor, motion sensor, wireless tag, etc.), a wristwatch or clock, laboratory equipment, optical device, medical device and / or system, weapon, cutting tool, or hand tool, etc.

[0254] The UE may be, for example, a personal digital assistant or related equipment of wireless equipment (such as a wireless card or module designed to be attached to or inserted into another electronic device (such as a personal computer, electrical measuring instrument, etc.)).

[0255] The UE may be part of a device or system that uses various wired and / or wireless communication technologies to provide the applications, services, and solutions described below with respect to the "internet of things (IoT)".

[0256] Internet of Things devices (or "things") can comprise suitable electronic devices, software, sensors, network connectivity, and / or the like that enable these devices to collect and exchange data with each other and with other communication devices. IoT devices can comprise automated devices that follow software instructions stored in internal memory. IoT devices may operate without human supervision or interaction. IoT devices may also remain stationary and / or inactive for long periods of time. IoT devices may be implemented as part of (generally) stationary equipment. IoT devices can also be incorporated into non-stationary equipment (such as, for example, a vehicle), or attached to an animal or person to be monitored / tracked.

[0257] It will be appreciated that IoT technology can be implemented on any communication device that can connect to a communication network to send / receive data, whether such communication device is controlled by human input or software instructions stored in memory.

[0258] It will be appreciated that IoT devices are sometimes referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be appreciated that a UE can support one or more IoT applications or MTC applications. Some examples of MTC applications are listed in Table 1 below. This list is not exhaustive and is intended to show some examples of machine type communication applications.

[0259] (Table 1) TIFF2026524937000002.tif226150TIFF 2026524937000003.tif2

[0260] Furthermore, the UE categories described above are merely examples of applications of the technical concepts and embodiments described herein. Of course, such technical concepts and examples are not limited to the UEs described above, and various modifications are possible.

[0261] Each feature disclosed herein (this term includes the claims) and / or shown in the drawings may be incorporated into this 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 not limited to, any feature of a claim dependent on a particular independent claim may be introduced into that independent claim in any combination or individually, provided that doing so does not result in a technical incompatibility or result in something that does not make technical sense.

[0262] Various other variations are obvious to those skilled in the art and will not be described in further detail here.

[0263] While the present disclosure has been described above with reference to embodiments, the disclosure is not limited thereto. Various modifications to the structure and details of the present disclosure are possible, as can be understood by those skilled in the art within the scope of the present disclosure.

[0264] This application claims priority based on UK Patent Application No. 2311351.7, filed on 24 July 2023, and incorporates all of its disclosures by reference herein.

[0265] A program can be stored and provided to a computer device using any type of non-temporary computer-readable medium. Non-temporary computer-readable medium includes any type of tangible storage medium. Examples of non-temporary computer-readable medium include magnetic storage media (such as floppy disks, magnetic tapes, and hard disk drives), magneto-optical storage media (e.g., magneto-optical disks), CD-ROMs (Read Only Memory), CD-Rs, CD-R / Ws, and semiconductor memory (such as mask ROMs, PROMs (Programmable ROMs), EPROMs (Erasable PROMs), flash ROMs, and RAMs (Random Access Memory)). A program may also be provided to a computer device using any type of temporary computer-readable medium. Examples of temporary computer-readable medium include electrical signals, optical signals, and electromagnetic waves. Temporary computer-readable medium can be provided to a computer device via wired communication lines such as electric wires and optical fibers, or via wireless communication lines.

[0266] For example, some or all of the embodiments disclosed above may also be described as follows, but are not limited to the following: (Note 1) A method performed by an access network node in a non-terrestrial network, the method is: In the event that either the service link between the access network node and the user equipment (UE), or the feeder link between the access network node and the gateway in the terrestrial network, becomes unavailable, user plane data is received via an available link without triggering the reactivation of a connection on another link other than the available link. The user plane data is stored until another link becomes available, A method that includes transferring user plane data via another link when another link becomes available. (Note 2) Receiving data is performed using control plane CIoT optimization features or Early Data Transmission (EDT). The method described in Appendix 1. (Note 3) The transfer is performed using control plane CIoT optimization features or Early Data Transmission (EDT). The method described in Appendix 1. (Note 4) The paging information used to transfer user plane data to the UE via the service link is received via the feeder link, This further includes, when a service link becomes available, paging the UE using paging information, The method described in any one of the appendices 1 to 3. (Note 5) Paging information is, Paging messages from the core network, Messages to resume or interrupt the UE context from the core network, or UE context information from the core network, which is included in at least one of the following: The method described in Appendix 4. (Note 6) Transferring user plane data over another link is performed when the UE context for the UE has been retrieved from the core network and the other link has been reconnected at the access network node. The method described in any one of the appendices 1 to 5. (Note 7) The core network receives UE context from at least one access network node via each feeder link. The method described in Appendix 6. (Note 8) The UE context from at least one access network node is transmitted when there is a change in the UE context as each feeder link becomes available. The method described in Supplementary Note 7. (The UE triggered the anchor eNB reassignment from eNB1 to eNB2). (Supplementary Note 9) Further comprising receiving, from the UE, a request to resume connection of a service link to an access network node, transmitting, via a feeder link, a request for the UE context of the UE to the core network, and receiving, in response to a request from the access network node, the UE context of the UE from the core network via the feeder link, where the UE context of the UE is transmitted from a further access network node where the connection of the service link has been interrupted to the core network, The method described in Supplementary Note 7 or 8. (Supplementary Note 10) Further comprising receiving, from the core network via a feeder link, the UE context of the UE when the core network has determined an anchor access network node to provide a connection for a service link to the access network node, where the UE context of the UE is transmitted from a further access network node where the connection for the service link has been interrupted to the core network, The method described in Supplementary Note 7 or 8. (Supplementary Note 11) where the UE context at the further access network node is released when a corresponding feeder link between the further access network node and a gateway coupled to the core network becomes available, The method described in Supplementary Note 9 or 10. (Supplementary Note 12) Further comprising transmitting, to the core network, information indicating the ability to store and transfer data when either a service link between an 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 described in any one of the appendices 1 to 11. (Note 13) The system further includes receiving information from the core network indicating the ability to store and transmit data when either the service link between the access network node and the user equipment (UE), or the feeder link between the access network node and the gateway in the terrestrial network, is unavailable. The method described in any one of the appendices 1 to 11. (Note 14) A method performed by user equipment (UE), the method is: The invention further includes transmitting user plane data to an access network node in a non-terrestrial network via a service link between the access network node and the UE without triggering the reconnection of the feeder link when the feeder link between the access network node and the gateway in the terrestrial network is unavailable, User plane data is stored by the access network node until a feeder link becomes available. User plane data is transferred via a feeder link when the feeder link becomes available. (Note 15) This includes the UE initiating the resumption of connectivity for a service link when the UE is within coverage of an access network node where the connectivity for the service link has been interrupted. The method described in Appendix 14. (Note 16) A method performed by the core network nodes, the method is This includes receiving user plane data from an access network node in a non-terrestrial network via a feeder link between an access network node and a core network node, without triggering the resumption of connectivity for the service link, when the service link between the access network node and the user equipment (UE) is unavailable. User plane data is stored by the access network node until a service link becomes available. User plane data is transferred via the service link when the service link becomes available. (Note 17) An access network node in a non-terrestrial network, and the access network node is A means for receiving user plane data via an available link without triggering the resumption of connection on another link other than the available link, when either the service link between the access network node and user equipment (UE), or the feeder link between the access network node and a gateway in the terrestrial network, is unavailable. A means for storing user plane data until another link becomes available, An access network node comprising means for transferring user plane data via another link when another link becomes available. (Note 18) User equipment (UE), In the event that the feeder link between the access network node and the gateway in the terrestrial network is unavailable, the system provides means for transmitting user plane data to an access network node in a non-terrestrial network via a service link between the access network node and the UE without triggering the reconnection of the feeder link. User plane data is stored by the access network node until a feeder link becomes available. User plane data is transferred via the feeder link to the UE when the feeder link becomes available. (Note 19) It is a core network node, In the event that the service link between the access network node and the user equipment (UE) is unavailable, the system provides means for receiving user plane data from an access network node in a non-terrestrial network via a feeder link between the access network node and the core network node without triggering the resumption of the service link connection. User plane data is stored by the access network node until a service link becomes available. User plane data is transferred via the service link to the core network node when the service link becomes available. [Explanation of Symbols]

[0267] 1. Communication System 3 UE 5 Radio Access Network (RAN) nodes, NTN RAN 5A base station 5A-1 First base station, anchor base station, original base station 5A-2 Second base station, new anchor 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 Circuits 33, 53 Antennas 35 User Interface 55 Core Network Interfaces 37, 57, 73 Controllers 39, 59, 74 memory 72 Network Interfaces 41, 61, 75 Operating Systems 43, 63, 76 Communication control modules

Claims

1. A method performed by an access network node in a non-terrestrial network, wherein the method is If either the service link between the access network node and the user equipment (UE), or the feeder link between the access network node and the gateway in the terrestrial network, is unavailable, user plane data is received via an available link without triggering the reactivation of a connection on another link other than the available link. The user plane data is stored until the aforementioned link becomes available, A method comprising transferring the user plane data via the aforementioned alternative link when the alternative link becomes available.

2. The aforementioned receiving is performed using user-plane CIOT optimization features or Early Data Transmission (EDT). The method according to claim 1.

3. The aforementioned transfer is performed using control plane CIot optimization features or Early Data Transmission (EDT). The method according to claim 1.

4. The paging information used to transfer the user plane data to the UE via the service link is received via the feeder link, The further includes, when the service link becomes available, paging the UE using the paging information, The method according to any one of claims 1 to 3.

5. The aforementioned paging information is, Paging messages from the core network, A message to resume or interrupt the UE context from the core network, or At least one of the UE context information from the core network includes, The method according to claim 4.

6. Transferring the user plane data over the aforementioned other link is performed when the UE context for the UE has been retrieved from the core network and the aforementioned other link has been reopened at the access network node. The method according to any one of claims 1 to 5.

7. The core network receives a UE context from at least one access network node via each feeder link. The method according to claim 6.

8. The UE context from at least one access network node is transmitted when there is a change in the UE context when each of the feeder links becomes available. The method according to claim 7. (The UE triggered an anchor eNB reassignment from eNB1 to eNB2).

9. Receiving a request from the UE to resume the connection of the service link to the access network node, The request for the UE context of the UE is transmitted to the core network via the feeder link, The further includes receiving the UE context of the UE from the core network via the feeder link in response to the request from the access network node, The UE context of the UE is transmitted to the core network from a further access network node where the connection of the service link has been interrupted. The method according to claim 7 or 8.

10. The core network determines an anchor access network node that provides a connection for the service link to the access network node, and further includes receiving the UE context of the UE from the core network via the feeder link. The UE context of the UE is transmitted to the core network from a further access network node where the connection for the service link has been interrupted. The method according to claim 7 or 8.

11. When the corresponding feeder link between the further access network node and the gateway connected to the core network becomes available, the UE context in the further access network node is released. The method according to claim 9 or 10.

12. The further includes transmitting information to the core network indicating the ability to store and transfer data when either the service link between the access network node and user equipment (UE), or the feeder link between the access network node and a gateway in the terrestrial network, is unavailable. The method according to any one of claims 1 to 11.

13. The further includes receiving information from the core network indicating the ability to store and transfer data when either the service link between the access network node and user equipment (UE), or the feeder link between the access network node and a gateway in the terrestrial network, is unavailable. The method according to any one of claims 1 to 11.

14. A method performed by user equipment (UE), wherein the method is If the feeder link between the access network node and the gateway in the terrestrial network is unavailable, the system further includes transmitting user plane data to the access network node in the non-terrestrial network via a service link between the access network node and the UE without triggering the reconnection of the feeder link. The user plane data is stored by the access network node until the feeder link becomes available. A method wherein the user plane data is transferred via the feeder link when the feeder link becomes available.

15. The UE includes initiating a resumption of the connection for the service link when the connection for the service link is within the coverage of an access network node where the connection for the service link was interrupted. The method according to claim 14.

16. A method performed by a core network node, the method is This includes receiving user plane data from the access network node in a non-terrestrial network via a feeder link between the access network node and the core network node, without triggering the resumption of the connection for the service link, when the service link between the access network node and the user equipment (UE) is unavailable. The user plane data is stored by the access network node until the service link becomes available. A method by which the user plane data is transferred via the service link when the service link becomes available.

17. An access network node in a non-terrestrial network, wherein the access network node is When either the service link between the access network node and user equipment (UE), or the feeder link between the access network node and a gateway in the terrestrial network, is unavailable, means for receiving user plane data via an available link without triggering the resumption of connection to another link other than the available link, An access network node comprising means for storing the user plane data until the other link becomes available, and means for transferring the user plane data via the other link when the other link becomes available.

18. User mode (UE), When the feeder link between the access network node and the gateway in the terrestrial network is unavailable, the system provides means for transmitting user plane data to an access network node in a non-terrestrial network via a service link between the access network node and the UE without triggering the reconnection of the feeder link. The user plane data is stored by the access network node until the feeder link becomes available. The user plane data is transferred via the feeder link when the feeder link becomes available.

19. It is a core network node, In the event that the service link between the access network node and the user equipment (UE) is unavailable, the means for receiving user plane data from the access network node in a non-terrestrial network via a feeder link between the access network node and the core network node without triggering the resumption of the connection for the service link, The user plane data is stored by the access network node until the service link becomes available. The user plane data is transferred to the core network node via the service link when the service link becomes available.

Images