User equipment and core network entity for avoiding data loss in a mobile network

Abstract

Described is a user equipment (401, 1300) in a mobile network (400), the user equipment being configured for communication with a core network entity (402, 1400) via a first data link, wherein the core network entity is configured to transmit one or more data packets received from the user equipment to a further network entity (403, 1500) via a second data link, the user equipment being configured to: transmit (1101) one or more data packets over the first data link; cause (1102) a copy of the one or more data packets to be stored in a memory at the user equipment or at the core network entity; determine (1103) whether the one or more data packets were successfully transmitted from the core network entity to the further network entity; and if that determination is positive, cause (1104) the copy of the one or more data packets to be discarded from the memory. This can allow for recovery from data loss, for example as a result of context not being synchronized in a store and forward deployment architecture.

Description

USER EQUIPMENT AND CORE NETWORK ENTITY FOR AVOIDING DATA LOSS IN A MOBILE NETWORKTECHNICAL FIELD

[0001] Embodiments of the present disclosure generally relate to the field of mobile networks, in particular to reducing data loss in such networks.BACKGROUND

[0002] Satellite Store and Forward (S&F) operation is a mode of operation in a mobile network by which the connection between a user equipment (UE) and a satellite, and between the satellite and the ground network, is not available at the same time. At any period, either: the connection between the UE and the satellite (service link) is available, but the connection between the satellite and the ground (feeder link) is not available, or the feeder link is available but not the service link.

[0003] Hence S&F enables the satellite to communicate with the UE, store any information from the UE, and then forward it to the ground (when feeder link is active) , and similarly in the other direction.

[0004] In 3GPP, the so-called mobility management entity (MME) split architecture means that some MME functions are on the satellite (referred to as MME-onboard) and other functions on the ground or terrestrial network (referred to as MME-ground) . The functions that are hosted in MME-onboard versus MME-ground, and how the MME-onboard communicates with MME-ground are not currently specified.

[0005] The S&F operation with MME split architecture creates scenarios in which the context across the UE, MME-onboard, and MME-ground are not synchronized. This lack of synchronization can be more frequent in S&F deployment than in a terrestrial network, where for the latter, the problem of not having both service and feeder link simultaneously is non-existent.

[0006] Figure 1 demonstrates a scenario in a 3GPP 4G mobile network 100 comprising a UE 101, MME-onboard 102 and MME-ground 103 in which the context becomes unsynchronized, stemming from local deactivation of an evolved packet system (EPS) bearer or packet data network (PDN) connection in the MME-ground when there is no feeder link with the MME-onboard.

[0007] In Figure 1, as shown at 111, the overall NAS context should be the same across the UE, MME-onboard (s) and MME-ground. The UE is assumed to have two PDN connections, one of which has EPS bearer ID #6.

[0008] At 112, the service link between the UE and the MME-onboard is available. At step 113, the UE 101 sends data over a packet data network (PDN) connection, in this example with evolved packet system (EPS) bearer #6, and at step 114 obtains confirmation from the MME-onboard 102 that the NAS message, which includes the data, was properly received at the MME onboard. During this time, the feeder link is not established with the MME-ground which performs a local deactivation of the PDN connection with EPS bearer #6 at 115. This local deactivation is not known to the UE or the MME-satellite.

[0009] At 117, the service link is down (deactivated) . When the MME-onboard at the satellite later establishes the feeder link with the MME-ground at 118, the MME-onboard may forward data for EPS bearer identity #6 at 119. However, the MME-ground would not process the data as the corresponding EPS bearer (or PDN connection) has been deactivated. As shown at 120, the data is discarded by the MME-ground, as no corresponding bearer exists.

[0010] A second scenario, shown in Figure 2, highlights the importance of the context synchronization update process, for example between the MME-onboard and the MME-ground.

[0011] As shown at 201, the overall NAS context should be the same across the UE, MME-onboard (s) and MME-ground. The UE is assumed to have two PDN connections, one of which has EPS bearer ID #6.

[0012] At 202, the service link between the UE and the MME-onboard is available. When the service link between the UE and MME-onboard is available, the UE performs two NAS procedures where data is sent at 203, and then the PDN connection is released at 205. At 203, the UE sends a CPSR NAS message to the MME-onboard. This is data for EPS bearer ID #6. At 204, the MME-onboard accepts the service and sends an acknowledgement to the UE. At 205, the PDN connection with bearer ID #6 is released and at 206 the service link is down (unavailable) .

[0013] At 208, the feeder link is available. When the feeder link becomes available, the MME-onboard and MME-ground attempt to synchronize the context. The sequence of context synchronization at 209 and 210 are critical, as if they are performed incorrectly then the UE’s data will be lost. For example, if step 209 (related to PDN connection release) is executed before step 210 (related to UE data transfer) , then the UE’s data will not be transferred.

[0014] With regards to local bearer deactivation, prior approaches simply enable the network or the UE to indicate if there has been any local EPS bearer deactivation when, for example, the UE and the network are not communicating due to the UE being in idle mode. The UE or the network use a so-called EPS bearer context status IE, which is a bitmap corresponding to EPS bearer identities, where the value of the bit indicates if the corresponding EPS bearer is active or not. This alone does not handle the scenario which has been presented in Figure 1.

[0015] With regards to context synchronization, the prior art does not discuss how the MME-onboard should perform context update with the MME-ground.

[0016] Prior approaches also do not cater for a split architecture with S&F operation which, as has been described above, can lead to data loss in the system without knowledge of this and without a way to recover from it.

[0017] With the challenges that S&F deployment presents, existing methods do not support methods to recover from data transfer failure that is caused by unsynchronized context, for example as presented in Figure 1. This may lead to data loss and, more importantly, the UE would not be aware of the data loss. Such data may represent important readings from an internet of things (IoT) device and the loss of critical readings will have a negative impact on the service. Additionally, the data may not be saved locally in the UE, and without any knowledge about the data loss, the UE (or the application client in the UE) would not regenerate the reading or data and so the outcome is loss of data.

[0018] Similarly, prior approaches do not specify how the context update procedure should be performed such that the outcome of the context update on the feeder link matches the outcome of the procedures which were performed on the service link. This interaction is currently left up to implementation, but a lack of any description or requirements can lead to loss of important details as part of the context update and that will in turn have a negative impact on the service.

[0019] It is desirable to develop an approach that may overcome at least some of the above issues.SUMMARY

[0020] According to a first aspect, there is provided a user equipment in a mobile network, the user equipment being configured for communication with a core network entity in the mobile network via a first data link, wherein the core network entity is configured to transmit one or more data packets received from the user equipment to a further network entity in the mobile network via a second data link, the user equipment being configured to: transmit one or more data packets to the core network entity over the first data link; cause a copy of the one or more data packets to be stored in a memory at the user equipment or at the core network entity; determine whether the one or more data packets were successfully transmitted from the core network entity to the further network entity; and if that determination is positive, cause the copy of the one or more data packets to be discarded from the memory.

[0021] This may allow for recovery from data loss, for example as a result of context not being synchronized in a store and forward deployment architecture.

[0022] The first data link and the second data link may not be simultaneously available for data packet transmission. This may allow the approach to be used in network architectures where data cannot be immediately forwarded to other network entities, for example, in a store and forward deployment architecture.

[0023] The user equipment may be configured to: determine whether the one or more data packets were successfully transmitted from the core network entity to the further network entity; and if that determination is negative, transmit the copy of the one or more data packets to the core network entity. This may prevent data loss when the original one or more data packets sent by the user equipment are not successfully transmitted by the network e.g. the further network entity.

[0024] The user equipment may be configured to transmit the one or more data packets to the core network entity for storage and wherein the user equipment is configured to, if the determination of whether the one or more data packets were successfully transmitted from the core network entity to the further network entity is negative: retrieve the copy of the one or more data packets from the core network entity; and transmit the copy of the one or more data packets to the core network entity for transmission to the further network entity. This may allow the data packets to be stored at the core network entity and retrieved to prevent data loss when the original one or more data packets sent by the user equipment are not successfully transmitted.

[0025] The determination of whether the one or more data packets were successfully transmitted from the core network entity to the further network entity may be an explicit determination or an implicit determination. This may allow the successful transmission to be determined in different ways, which may depend on the network architecture.

[0026] The one or more data packets may be associated with one or more data identity parameter (s) and wherein the user equipment is configured to determine whether the one or more data packets were successfully transmitted from the core network entity to the further network entity in dependence on the one or more data identity parameter (s) . This may allow the user equipment to determine which particular data packet (s) have been successfully or unsuccessfully transmitted.

[0027] The data identity parameter (s) may be included in a message comprising the one or more data packets transmitted by the user equipment to the core network entity. This may allow the data identity parameter (s) to be easily associated with their corresponding data packet (s) .

[0028] The data identity parameter (s) may be NAS count (s) or a new data identity field in a non-access stratum message transmitted by the user equipment to the core network entity. This may allow the data packets to be identified in the NAS message.

[0029] The user equipment may cause the data identity parameter (s) to be stored in the memory at the user equipment or at the core network entity with the copy of the one or more data packets. This may allow the data packet (s) and their corresponding identity parameter (s) to be retrieved if the original transmission is determined to be unsuccessful.

[0030] The user equipment may be configured to receive an indication of whether the one or more data packets were successfully transmitted or unsuccessfully transmitted from the core network entity to the further network entity via a subsequent data link between the core network entity and the further network entity. This may enable the UE to determine which data packet should be re-transmitted (in the case of the indication of unsuccessful transmission) or should be discarded (in the case of the indication of successful transmission) .

[0031] The user equipment may be configured to determine whether the one or more data packets were successfully transmitted from the core network entity to the further network entity in dependence on an evolved packet system bearer context status information element for an evolved packet system bearer intended for transmission of the one or more data packets from the core network entity to the further network entity. This may allow the user equipment to determine whether transmission has been successful based on easily obtainable information.

[0032] The user equipment may be configured to determine that the one or more data packets were successfully transmitted from the core network entity to the further network entity if the evolved packet system bearer context status information element is not present in a subsequent message received from the core network entity and / or determine that the one or more data packets were unsuccessfully transmitted from the core network entity to the further network entity if the evolved packet system bearer context status information element is present in the subsequent message received from the core network entity and indicates that the evolved packet bearer intended for transmission of the one or more data packets from the core network entity to the further network entity is inactive. This may allow the user equipment to determine whether transmission has been successful based on easily obtainable information.

[0033] The core network entity and / or the further network entity may be sub-entities of a mobility management entity, MME, in the mobile network. The further network entity may be a further core network entity. This may allow the present approach to be used in an MME-split architecture.

[0034] The core network entity may be a non-terrestrial entity. The further network entity may be a terrestrial entity. This may allow the approach to be used for data communication between differently-located entities in a mobile network.

[0035] The user equipment may be configured to operate in store and forward mode or may be configured to access a system which operates in store and forward mode. When configured to operate in store and forward mode, the user equipment may use explicit signalling on the first data link and / or second data link to release or activate an evolved packet system bearer or a packet data network connection, and should preferably not use local deactivation of the evolved packet system bearer or a packet data network connection. This may help to ensure correct context update without impacting the user equipment’s service.

[0036] According to a second aspect, there is provided a method for implementation at a user equipment in a mobile network, the user equipment being configured for communication with a core network entity in the mobile network via a first data link, wherein the core network entity is configured to transmit one or more data packets received from the user equipment to a further network entity in the mobile network via a second data link, the method comprising: transmitting one or more data packets to the core network entity over the first data link; causing a copy of the one or more data packets to be stored in a memory at the user equipment or at the core network entity; determining whether the one or more data packets were successfully transmitted from the core network entity to the further network entity; and if that determination is positive, causing the copy of the one or more data packets to be discarded from the memory.

[0037] This method may allow for recovery from data loss, for example as a result of context not being synchronized in a store and forward deployment architecture.

[0038] According to a third aspect, there is provided a core network entity in a mobile network, the core network entity being configured for communication with a user equipment in the mobile network via a first data link, wherein the core network entity is configured to transmit one or more data packets received from the user equipment to a further network entity in the mobile network via a second data link, the core network entity being configured to: receive one or more data packets from the user equipment over the first data link; and provide an indication to the user equipment to allow the user equipment to determine whether the one or more data packets were successfully transmitted from the core network entity to the further network entity.

[0039] This may allow for recovery from data loss, for example as a result of context not being synchronized in a store and forward deployment architecture.

[0040] The first data link and the second data link may not be simultaneously available for data packet transmission. This may allow the approach to be used in network architectures where data cannot be immediately forwarded to other network entities, for example, in a store and forward deployment architecture.

[0041] The core network entity may be configured to store a copy of the one or more data packets at a memory of the core network entity. This may allow the data packets to be stored at the core network entity so that they may be retrieved and re-transmitted to prevent data loss when the original one or more data packets sent by the user equipment are not successfully transmitted.

[0042] The core network entity may be configured to provide the copy of the one or more data packets to the user equipment for transmission to the core network entity upon a determination by the user equipment that the one or more data packets were not successfully transmitted from the core network entity to the further network entity. This may allow the data packets to be retrieved to prevent data loss when the original one or more data packets sent by the user equipment are not successfully transmitted.

[0043] The one or more data packets may be associated with one or more data identity parameter (s) . The core network entity may be configured to provide the one or more data identity parameter (s) to the user equipment to allow the user equipment to determine whether the one or more data packets were successfully transmitted from the core network entity to the further network entity. This may allow the user equipment to determine which particular data packet (s) have been successfully or unsuccessfully transmitted.

[0044] The data identity parameter (s) may be included in a message comprising the one or more data packets received by the core network entity from the user equipment. This may allow the data identity parameter (s) to be easily associated with their corresponding data packet (s) .

[0045] The data identity parameter (s) may be NAS count (s) or a new data identity field in a non-access stratum message received by the core network entity from the user equipment. This may allow the data packets to be identified in the NAS message.

[0046] The data identity parameter (s) may be stored in the memory with the one or more data packets. This may allow the user equipment to retrieve particular data packets that it has determined to have been unsuccessfully transmitted.

[0047] According to another aspect, which may be performed in combination with the above aspects or independently, the core network entity may be configured to record a sequence of events or procedures occurring on the first data link and record one or more updates to a user equipment context of the user equipment as a result of one or more of the events or procedures on the first data link. The core network entity may forward the recorded events or procedures and / or context and / or timestamp of the occurrent of procedures to the further network entity. This may help to ensure correct context update without impacting the user equipment’s service.

[0048] The core network entity may be further configured to record a sequence of events or procedures occurring on the second data link and provide one or more updates to a user equipment context of the user equipment as a result of one or more of the events or procedures on the second data link. This may help to ensure correct context update.

[0049] The core network entity may be further configured to, for each event or procedure that is completed on the first data link, save the updated user equipment context at a memory of the core network entity and optionally a timestamp indicating a time at which the user equipment context was updated. The core network entity may record the sequence of events or procedures occurring on the second data link and may replicate these events or procedures with the user equipment on the first data link. This may help to ensure correct context update. The replication may be by means of several NAS messages (or procedures) or one NAS message that leads to the final outcome if this is feasible.

[0050] In the above aspects, the core network entity and / or the further network entity may be configured to operate in store and forward mode. The core network entity and / or the further network entity may be configured to use explicit signalling on the second data link to release or deactivate an evolved packet system bearer or a packet data network connection. These entities should preferably not use local deactivation of the evolved packet system bearer or a packet data network connection.

[0051] This may allow for recovery from data loss, for example as a result of context not being synchronized in a store and forward deployment architecture.

[0052] The further network entity may be a further core network entity. The core network entity and / or the further network entities may be sub-entities of a mobility management entity, MME, in the mobile network. The further network entity may be a further core network entity, this may allow the present approach to be used in an MME-split architecture.

[0053] The core network entity may be a non-terrestrial entity. The further network entity may be a terrestrial entity. This may allow the approach to be used for data communication between differently-located entities in a mobile network.

[0054] According to a further aspect, there is provided a method for implementation at a core network entity in a mobile network, the core network entity being configured for communication with a user equipment in the mobile network via a first data link, wherein the core network entity is configured to transmit one or more data packets received from the user equipment to a further network entity in the mobile network via a second data link, the method comprising: receiving one or more data packets from the user equipment over the first data link; and providing an indication to the user equipment to allow the user equipment to determine whether the one or more data packets were successfully transmitted from the core network entity to the further network entity.

[0055] This may allow for recovery from data loss, for example as a result of context not being synchronized in a store and forward deployment architecture.

[0056] According to another aspect, there is provided a mobile network comprising a user equipment having any of the features described herein and a core network entity having any of the features described herein.

[0057] According to a further aspect, there is provided one or more computer programs for instructing a computer comprising one or more processors to implement the methods above.

[0058] According to a further aspect there is provided a data carrier storing in non-transitory form the one or more computer programs above.BRIEF DESCRIPTION OF THE FIGURES

[0059] Figure 1 schematically illustrates a situation where local PDN deactivation in an MME-ground entity is not synchronized with the UE or MME-onboard entity in a mobile network;

[0060] Figure 2 schematically illustrates a sequence of synchronization between an MME-onboard entity and an MME-ground entity in a mobile network;

[0061] Figure 3 illustrates a flow diagram showing an overview of an exemplary behaviour of the UE in the approach described herein;

[0062] Figure 4 schematically illustrates an exemplary call flow where the determination of failed data transmission is determined based on data identity;

[0063] Figure 5 schematically illustrates exemplary UE behaviour where an existing information element is used to determine the success of data transmission;

[0064] Figure 6 schematically illustrates exemplary UE behaviour where an existing information element is used to determine unsuccessful data transmission;

[0065] Figure 7 schematically illustrates an exemplary call flow for delayed deactivation;

[0066] Figure 8 schematically illustrates an implementation where an MME-onboard entity records NAS procedures in sequence based on which context is synchronized in a corresponding sequence with an MME-ground entity;

[0067] Figure 9 describes exemplary behaviour of the MME-onboard entity when it is interacting with the MME-onboard entity over the feeder link, where the MME-onboard entity records MME-to-MME procedures in sequence based on which context is synchronized in a corresponding sequence with a UE;

[0068] Figure 10 schematically illustrates an implementation where the MME-onboard entity updates the MME-ground entity based on a sequence of NAS procedures on the service link;

[0069] Figure 11 schematically illustrates the steps of an exemplary method for implementation at a user equipment in a mobile network;

[0070] Figure 12 schematically illustrates the steps of an exemplary method for implementation at a core network entity in a mobile network;

[0071] Figure 13 schematically illustrates an example of a user equipment and some of its associated components;

[0072] Figure 14 schematically illustrates an example of a core network entity and some of its associated components;

[0073] Figure 15 schematically illustrates an example of a further network entity and some of its associated components.DETAILED DESCRIPTION

[0074] The present disclosure relates to mobile networks. The approaches described herein may be implemented in such mobile networks as 3GPP 4G or 5G networks and other mobile communication systems that are currently available or developed in the future. The network may comprise a plurality of network entities (NEs) . The NEs may be network function (NFs) , which may be software-based. The NEs may alternatively be network apparatus (hardware-based) .

[0075] A mobile network generally comprises a radio access network (RAN) and a core network (CN) . The RAN handles the wireless aspects, while the CN handles the management and control aspects. Both the RAN and CN have a User Plane (UP) to transmit traffic. A Control Plane (CP) can carry signaling traffic.

[0076] One problem in such mobile networks is how to detect and recover from unsynchronized context, for example after local EPS bearer (or PDN connection) deactivation, so as to not impact the UE service in a store and forward operation with MME-split architecture.

[0077] Another problem in such mobile networks is how to ensure that the context update between the MME-onboard and MME-ground, or other network entities with data sent therebetween, is performed in a correct manner such that there is not a negative impact on the UE’s service.

[0078] The present disclosure provides solutions in order to avoid or recover from data loss due to unsynchronized context resulting from local context deactivation.

[0079] In the non-limiting examples described herein, the mobile network comprises a satellite with store and forward (S&F) operation mode and MME-split architecture. In this architecture, the satellite with MME function (anon-terrestrial entity) is referred to as the MME-onboard, while the MME on the ground (aterrestrial entity) is referred to as the MME-ground. The MME-onboard may not simultaneously have a link with the UE and with the MME-ground at the same time. In general, at any time, either the link with the UE is available (called the service link) , or the link with the MME-ground is available (called the feeder link) .

[0080] With this architecture, the UE and MME-ground do not communicate directly. The UE and the MME-ground communicate through the satellite which comprises an MME on board (referred to herein as MME-onboard) . Furthermore, the MME functions across the MME-onboard and MME-ground may be split in an implementation-specific manner.

[0081] The operations described herein in the specific examples for the MME entities (MME-onboard and MME-ground) may alternatively be performed by other network entities in alternative network architectures. For example, in a 5G network, the operations may be performed by a session management function (SMF) and an access and mobility management function (AMF) respectively. That is, the core network entity may be an SMF and the further network entity may be an AMF. In other examples, the core network entity may be any non-terrestrial network entity and the further network entity may be a terrestrial entity. The further network entity may be a further core network and / or control plane entity. In other mobile network architectures, other implementations are possible.

[0082] Herein, the first data link between the UE and the core network entity is referred to as the service link and the second data link between the core network entity and the further network entity is referred to as the feeder link.

[0083] In one embodiment, the UE which sends data over NAS, for example to a UE which may use control plane cellular internet of things (CIoT) optimization (either for EPS or 5GS) , or optionally to a UE which operates in store and forward mode, saves any data that is sent over the control plane (or over the user plane) until the UE verifies if the data has been successfully sent by the network to the application server (AS) .

[0084] The UE can locally save any data which it sends (for example, over NAS) , optionally when it is operating in store and forward mode or when it is using a network that is operating in store and forward mode. The UE can verify or determine if the data was successfully sent. As will be described further below, this determination may be based on explicit methods or implicit methods.

[0085] The UE operating a store and forward mode may mean that the UE supports using a network that operates in store and forward mode, or is capable of store and forward mode, or provides an indication to the network that it can use store and forward mode.

[0086] One explicit method for this determination may involve the use of a data identity (DID) parameter which becomes associated with a data packet. As such, the DID can be used to refer to a data packet which is either successfully transmitted or not. The DID parameter may be a new parameter which is included in any NAS message. Alternatively, it may be the NAS COUNT which is an existing parameter in the NAS messages.

[0087] The data packet can also be saved by the network with the associated DID. For example, it may be saved locally at the UE or at the core network entity (for example, the MME-onboard) .

[0088] As will be described in more detail below, the core network can indicate to the UE which data packet (s) was / were successfully sent or not by means of the DID.

[0089] If the UE determines that the data was successfully sent, then the UE can discard the data. If the UE determines that the data was not successfully sent, then the UE can re-transmit the data which it caused to be saved.

[0090] In an alternative solution, the MME-onboard can save the data and if any data was not successfully sent to the MME-ground, the MME-onboard can forward the saved data that was not sent successfully to the UE for re-transmission.

[0091] Data not successfully transmitted to the further network entity may refer to data that is not received by the further network entity. Data not successfully transmitted to the further network entity (for example, MME-ground) may also refer to the case that the further network entity does receive the data from the core network entity (for example, MME-onboard) , but the further network entity does not process or transmit the data further, for example due to an EPS bearer or PDN connection being deactivated wherein the data to be processed or transmitted is related to the deactivated EPS bearer or PDN connection.

[0092] Alternatively, local bearer or PDN deactivation can be handled differently such that the network or the UE is configured to wait for an additional (subsequent) link establishment with the MME-onboard to verify if data is available or not, and if not, then the local deactivation can be performed. Optionally, local deactivation may be avoided in S&F operation and instead explicit NAS signaling can be used.

[0093] In the above implementations, if the UE determines that the data was transmitted successfully, the UE may discard the saved data. If the UE determines that the data was not transmitted successfully, the UE may re-transmit the saved data.

[0094] The UE may inform the upper layers (for example, an application client) about a successful transmission, failed transmission, and / or re-transmission of data.

[0095] Figure 3 summarises the exemplary behaviour of the UE in a method 300 according to embodiments of the present invention.

[0096] At 301, the UE has data (for example, one or more data packets) to send to the core network entity (for example, MME-onboard) , in this case over non-access stratum (NAS) . At 302, the UE transmits the data over NAS to the core network entity. The UE locally saves the data that has been transmitted in memory, for example locally at a memory of the UE. Optionally, the data may be labelled, for example with a DID. The label (s) may also be saved in memory with the data. At 303, the UE determines whether that data was successfully transmitted. If yes (i.e. the data was successfully transmitted) , at 304, the UE discards the saved data. If no (i.e. the data was not successfully transmitted) , the process starts again and the UE sends the saved data over the NAS.

[0097] The UE may wait for the next service link establishment period for it to determine if the data was transmitted successfully or not. This may be necessary if, for example, the data link between the UE and the core network entity is deactivated after sending the data.

[0098] The NAS messages may be any NAS message that is either new or existing. The behaviour of each entity may be applicable to a UE operating according to a particular protocol (4G, 5G etc) , and the core network entity may be a suitable entity (4G entity, 5G entity, etc) .

[0099] One exemplary way in which the determination of whether the data has been successfully transmitted over the control plane (for example, for an MME-onboard to an MME-ground) will now be described.

[0100] In one implementation, which the determination of whether the data has been successfully transmitted is performed in dependence on data identity (DID) . In this implementation, the UE uses a DID to label or identify each packet that gets sent to the network. The DID may be included in the message (for example, NAS message) that contains the data packet.

[0101] The DID may be a new parameter that is defined and included in the message (for example, in a NAS message) . The DID may be set to any default value (for example, zero or one, etc) , at the establishment of the PDU session. The DID may be per direction for which the data is sent (for example, it may be a DID for the uplink direction, and there may be a DID for the downlink direction) .

[0102] Figure 4 shows an exemplary call flow based on this implementation. In this example, a mobile network 400 comprises a UE 401 for uplink data transmission. The core network entity is an MME-onboard 402 and the further network entity is an MME-ground 403. This approach may be used for other suitable network entities.

[0103] At 404, the UE401 sends one or more data packets to the MME-onboard 402. In this example, the data packet (s) is / are sent as a NAS message. The NAS message includes data and a data ID. At 405, an optional NAS response can be sent by the MME-onboard to the UE 401.

[0104] At 406, the UE 401 saves the data and the corresponding DID (s) locally at the UE. At 407, the MME-onboard associates the data with the data ID (s) .

[0105] At 408, the feeder link (the data link between the MME-ground and MME-onboard) is available. At 409, the MME-onboard forwards the data received from the UE to the MME-ground, optionally with the DID (s) of the data packet (s) . At 410, the MME-ground reports data failure (i.e. the transmission of the data from the MME-onboard to the MME-ground was unsuccessful) , optionally with the DID (s) .

[0106] At 411, the service link (the data link between the MME-onboard and the UE) is available. At 412, the MME-onboard reports the data transmission failure with the associated DID (s) of the data packets that were not successfully transmitted and / or data transmission success with the associated DID (s) of the data packets that were successfully transmitted.

[0107] At 413, the UE determines which data packet (s) have not been successfully sent. For these data packets, the UE resends the data by transmitting the data that was saved at the UE to the MME-onboard. For data packet (s) that the UE determines to have been successfully transmitted to the MME-ground, the UE deletes the corresponding locally saved data packet (s) .

[0108] The UE 401 can use the current value of the DID for the current data packet to be sent and assign it to current data packet. After the transmission of the data packet, which may contain the DID value in the same message as the data packet, the UE can increment the DID value by one for the subsequent data packet.

[0109] The core network entity (for example, MME-onboard) for downlink data transmission can use the current value of the DID for the current data packet to be sent. After the transmission of the data packet, which may contain the DID value in the same NAS message as the data packet, the network (e.g. MME-onboard) can increment the DID value by one and so on.

[0110] When the MME-onboard receives data from the UE, including a DID, the MME-onboard may locally save the data and the DID. When the feeder link is established, the MME-onboard forwards the data to the MME-ground. If the MME-ground reports failure of data transfer, the MME-ground may identify the data which is reported to not have been successfully transferred by the MME-ground. The MME-onboard may also identify the data which was successfully delivered by the network and may also indicate that to the UE.

[0111] The core network entity (for example, MME-onboard) may indicate to the UE any combination of the following: the data packet (s) that was / were unsuccessfully transferred by the network, the data packet (s) that was / were successfully transferred by the network, or both. The core network entity can use the DID to identify this.

[0112] The MME-onboard and the MME-ground can also identify data packets using a DID parameter or any other new parameter. However, regardless of the name or type of parameter, both MMEs can label and / or identify data that is sent, or data that is successfully sent, or data that is not successfully sent, to the AS.

[0113] The UE which receives an indication that a data packet has not been successfully sent can then re-transmit the data packet.

[0114] The UE and the core network may exchange new capabilities to indicate the support of labelling data with the new DID parameter, or with the capability to indicate that the UE and / or the network can provide indications about what data packets have been successfully sent and / or which have not been successfully sent. The UE or the network can use any information element, new or existing, to provide any of these indications. The UE indication can be sent in any NAS message such as Attach Request, Tracking Area Update Request, Registration Request, etc. The network indication can be sent in any NAS message such as Attach Accept, Tracking Area Update Accept, Registration Accept, etc.

[0115] The UE, core network entity (for example, MME-onboard) or further network entity (MME-ground) , or any combination of these entities may additionally or optionally include a timestamp representing the time at which the message was sent. The sending entity may save the timestamp associated with each packet and may also use the timestamp as a means, or as an additional means (e.g. in addition to a DID) for identifying data packets. Thus, the implementations described above may also be implemented or achieved using a timestamp, or may also be achieved or implemented by additionally sending a timestamp information with each packet that an entity sends (where a sending entity may be a UE, MME-ground, or MME-onboard) .

[0116] In another implementation, which may be used in combination with features from other implementations described herein, the core network entity (for example, MME-onboard) may save the data received from the UE (and / or also data received from the MME-ground) .

[0117] If data was received from the UE, the core network entity (for example, MME-onboard) can save the data including any DID as proposed earlier. In this case, the UE need not save the data locally e.g. due to storage limitations in an IoT device. The core network entity can attempt to send the data to the further network entity when the feeder link is established. If a data packet is not successfully transferred as determined by the core network entity or the UE, the core network entity can send the data back to the UE (e.g. after the service link is established with the UE again) . The core network entity can include a DID (and / or timestamp) with the data in order to identify the packet which was not sent successfully.

[0118] The UE and the network may exchange capabilities regarding where to save the data, for example locally, or for example in the network (in the MME-onboard) .

[0119] The UE can determine to retransmit the message if the data was not transmitted to the further network entity (for example, MME-ground) , as described earlier.

[0120] In a further implementation, the UE uses existing information to determine if data previously sent was indeed successfully transmitted or not (and hence to determine the need for re-transmission of the saved copy of the data) .

[0121] Figure 5 shows an exemplary call flow and behaviour of the UE and core network entities based on the description above, where the figure shows the case when the data was successfully sent. In this example, the core network entity and the further network entity are an MME-onboard and MME-ground respectively. However, this approach may be used for other suitable network entities.

[0122] At 501, the UE401 sends one or more data packets to the MME-onboard 402. In this example, the data packet (s) is / are sent as a NAS message. The NAS message includes one or more data packets and optionally the corresponding DID (s) . At 502, an optional NAS response can be sent by the MME-onboard to the UE 401.

[0123] At 503, the data packet (s) are saved at the UE until the next time the service link is established. At 504, the service link is down (unavailable) .

[0124] At 505, the feeder link is available and at 506, the MME-onboard forwards the data packet (s) to the MME-ground.

[0125] At 507, the service link is available. At 508, the MME-onboard sends a message (in this example, a NAS message) to the UE. In this example, the message lacks an indication of the EPS bearer that was intended for the transmission of the data packet (s) between the MME-onboard and the MME-ground being deactivated.

[0126] At 509, the lack of indication that the EPS bearer is deactivated leads to the determination by the UE of successful transmission of the data packet (s) from the MME-onboard to the MME-ground.

[0127] In this implementation, the existing information used by the UE in the determination of whether the data was successfully transmitted is the EPS bearer context status information element (IE) in 4G, which informs the recipient by means of a bitmap whether an EPS bearer in 4G is still active or not. If the bit is set to one, then the corresponding EPS bearer in 4G is active. If the bit is set to zero, then the corresponding EPS bearer in 4G (or a PDU session identity in 5GS) is inactive.

[0128] In a 5G system, the existing information may be the PDU session status IE in 5GS which informs the recipient by means of a bitmap whether a PDU session identity is still active or not. If the bit is set to one, then the corresponding PDU session identity in 5GS is active. If the bit is set to zero, then the corresponding PDU session identity in 5GS is inactive.

[0129] In this embodiment, the UE can save a data packet after transmission, noting that the packet is sent using an EPS bearer which has an EPS bearer identity.

[0130] For 5GS systems, the PDU session is used for sending data and the PDU session is identified by a PDU session identity. The PDU session status IE provides similar information as EPS bearer context status IE in 4G. However, in the 5GS the IE represents a bitmap for PDU sessions instead of EPS bearers.

[0131] In this example, the UE saves a packet which is sent and the UE knows the bearer identity which was used for sending the packet.

[0132] The UE waits for the next time it establishes a service link, where this may be with the same satellite that is used for sending the data or not. If it is for the same satellite, then the UE needs to also memorize the satellite ID on which a packet was sent. The UE may optionally do so always.

[0133] When the service link (the data link between the UE and the core network entity) is established, the UE verifies if the EPS bearer context status IE is included in a NAS message, optionally received from the network, or not. If the IE is missing, then the UE concludes that the data previously sent was successfully transferred. If the IE is present, the UE verifies if an EPS bearer, referred to by an EPS bearer identity, is indicated to be active or deactivated.

[0134] If the EPS bearer is not active (or is deactivated) , then the UE further verifies which packet was sent on the EPS bearer that is indicated to be deactivated. The UE can then retransmit the data which was previously sent on the EPS bearer that the UE now determines to be deactivated as per the IE. If the EPS bearer is determined to be active, then for any data which was previously sent on the EPS bearer (indicated to be active) , the UE can discard the data as the data was successfully sent.

[0135] The above behaviour shows how the UE can use the existing IE to determine if data previously sent on an EPS bearer was successfully transferred or not. Note that the UE can behave as above even if it had previously received a NAS response or accept message when it sent the data over the service link.

[0136] The examples described above can also be applicable to the MME-ground (or MME-onboard) . As such, either the UE or the network can behave as described above.

[0137] For example, an entity can send data over an EPS bearer, identified by an EPS bearer identity. The entity saves the data which is sent. The entity verifies if a NAS message (e.g. received immediately on the current link, or at a subsequent link establishment) contains the EPS bearer context status IE or not. The entity verifies if the EPS bearer is deactivated or still active as described above. If the EPS bearer is determined to be active, the entity discards the data and concludes that the data was successfully sent. If the EPS bearer is determined to be deactivated, the entity determines that the data was not successfully sent and can retransmit the data.

[0138] An exemplary call flow and behaviour for the case of an unsuccessful data transmission is shown in Figure 6. In this example, the core network entity and the further network entity are an MME-onboard and MME-ground respectively. However, this approach may be used for other suitable network entities.

[0139] At 601, the UE 401 sends one or more data packets to the MME-onboard 402. In this example, the data packet (s) is / are sent as a NAS message. The NAS message includes one or more data packets and optionally the corresponding DID (s) . At 602, an optional NAS response can be sent by the MME-onboard to the UE 401. Since the UE 401 is operating in store and forward mode in this example, receiving a NAS response message at 602 from the MME-onboard 402, the UE 401 does not necessarily determine that the data has been successfully sent and may have to perform a further check as has been described herein.

[0140] At 603, the data packet (s) are saved at the UE until the next time the service link is established.

[0141] At 604, the EPS bearer on which the transmission of the data from the MME-onboard to the MME-ground was intended is locally deactivated. At 605, the service link is down (unavailable) .

[0142] At 606, the feeder link is available and at 607, the MME-onboard forwards the data packet (s) to the MME-ground.

[0143] At 608, the MME-ground reports a data failure due to inactive EPS bearer context to the MME-onboard. Note that the MME-ground should indeed report a data failure to the MME-onboard, for a UE in question, whenever data is received for an EPS bearer or PDN connection such that the EPS bearer or PDN connection is considered deactivated in the MME-onboard.

[0144] At 609, the service link is available. At 610, the MME-onboard sends a message to the UE with an indication of the deactivated bearer context.

[0145] At 611, the UE resends the data (by sending the locally saved copy of the data packet (s) ) to the MME-onboard and, subsequently, once the UE has determined that transmission from the MME-onboard to the MME-ground was successful, deletes the data from the memory.

[0146] The implementations described with reference to Figure 5 and Figure 6 show how the existing information element can be used to determine if data was successfully sent or not, respectively, and if the UE (or network) should perform a re-transmission.

[0147] In another embodiment, the network (or UE) can delay the local deactivation (for example, deactivation of a PDN connection or EPS bearer) until the next time a data link is established with the satellite. This enables the network (or UE) to determine if data was pending (or has been sent) on the corresponding PDN connection (or EPS bearer) and hence the EPS bearer or PDN connection will not be deactivated when there is pending data.

[0148] For example, if the MME-ground determines to locally deactivate an EPS bearer (or PDN connection) , the MME-ground should wait until the subsequent link establishment with the MME-satellite. At that point, the MME-ground would determine if data was sent or not by the UE. If data was not sent (i.e. MME-ground did not receive data for a UE from the MME-onboard) , then the MME-ground can perform the local deactivation of the EPS bearer (or PDN connection) and can use the EPS bearer context status IE to indicate which bearer has been deactivated. The MME-onboard can then also use the EPS bearer context status IE to inform the UE that the EPS bearer has been deactivated.

[0149] If the MME-ground receives data for a UE (from the MME-onboard) , then the MME-ground would have kept the EPS bearer active and can therefore forward the data to the AS. Then the MME-ground can further delay the deactivation of the bearer until the next link becomes established again with the satellite, and so on.

[0150] Note that the behaviour can also be applicable to the UE.

[0151] In another example, local deactivation may be performed due to inactivity on an EPS bearer or for other reasons. If the reason is not related to configuration issues (i.e. no eminent problem with configuration) , then when the UE or MME (in ground network) determines to deactivate an EPS bearer (or PDN connection) locally, then the following behaviour can be adopted.

[0152] The UE and / or MME can delay the deactivation until after the next link establishment occurs with the satellite (service link for UE, feeder link for MME-ground) . For example, MME-ground determines to locally deactivate a PDN connection (or EPS bearer) while there is no feeder link available.

[0153] The MME should first wait for the feeder link to be established with the satellite. If the satellite does not forward any data for the EPS bearer (or PDN connection) in question, then the MME can perform the deactivation and synchronize with the satellite MME. If the MME receives data, then it can first process  / send the data and then deactivate the bearer (or PDN connection) . This ensures data delivery for the UE. The same proposal can apply for the UE in case it wants to perform local deactivation.

[0154] Figure 7 shows an exemplary call flow based on this delayed deactivation embodiment. In this example, the core network entity and the further network entity are an MME-onboard and MME-ground respectively. However, this approach may be used for other suitable network entities.

[0155] At 701, the UE401 sends one or more data packets to the MME-onboard 402. In this example, the data packet (s) is / are sent as a NAS message. The NAS message includes one or more data packets and optionally the corresponding DID (s) . At 702, an optional NAS response can be sent by the MME-onboard to the UE 401.

[0156] At 703, the MME wants to deactivate the EPS bearer, but delays this until the feeder link is established.

[0157] At 704, the service link is down (unavailable) . At 705, the feeder link is available.

[0158] At 706, if no data is received for the EPS bearer (in the case of a 4G network) , or the PDN connection, which is pending deactivation, the EPS bearer (or PDN connection) is deactivated. If data is received, the data is processed and then the EPS bearer (or PDN connection) is deactivated, or deactivation is delayed again.

[0159] At 707, the MME-ground sends the MME-onboard an EPS bearer (or PDN connection) a deactivation indication.

[0160] At 708, the service link is available. At 709, the MME-onboard sends the UE a bearer deactivation indication. At 710, the UE determines that the data packet (s) were sent to the MME-ground successfully.

[0161] Alternatively, the MME-ground and / or MME-onboard may include a new indication in the NAS message which informs the UE if data was sent despite an EPS bearer being indicated as deactivated. For example, in step 709, the EPS bearer is indicated to be deactivated but the data was successfully sent before the deactivation of the EPS bearer. The NAS message from the network can include a new indication e.g. to inform the UE that the data was successfully sent even though the EPS bearer is deactivated. This indication may mean that the EPS bearer was deactivated after successful transmission of the data. The UE may use this explicit indication to determine that the data was successfully sent.

[0162] In the case of a multiple satellite scenario, the MME-ground can delay the deactivation while taking into account the total time needed for all the satellites or some of the satellites to reach the UE on the service link. For example, the MME-ground can consider the time required for N number of satellites, where N is an integer. N may be the total number of satellites that are deployed. Alternatively, the MME-ground may consider that the local deactivation can be delayed until a feeder link is established with a particular satellite, where for example the satellite may be the one with which the MME-ground first establishes a feeder link and then waits until the next feeder link establishment occurs with the same satellite. Then the MME-ground can locally deactivate any EPS bearer if not data is received from this satellite in question. This method enables one particular satellite to have contacted the UE and then subsequently contacted the MME-ground which then can determine if data was sent from the UE or not via this satellite.

[0163] In an alternative solution within this embodiment, the UE or MME-onboard, or MME-ground should avoid the use of local deactivation when operating in store and forward mode. Hence the use of the EPS bearer context status IE (or PDU session status IE) should not be allowed when operating in store and forward mode. Instead, all deactivation of an EPS bearer or PDN connection or PDU session should be performed by means of explicit NAS signaling.

[0164] In a further example, related to the updating of the context for a UE which then results in data loss, the following actions may be performed to synchronize the context between the MME-onboard and the MME-ground by considering the sequence of procedures (for example, NAS procedures) . This approach may be applied with or without (i.e. independently of) any of the above-described implementations.

[0165] The MME-onboard can memorize the sequence of events  / procedures that occur with the UE on the service link, and the sequent of events  / procedures that occur with the MME-ground on the feeder link. During communication with the UE on the service link, the MME, for every NAS procedure that is completed, may save the updated UE context and optionally a timestamp to indicate the time at which the context became updated. The MME-onboard may for each procedure save updates to the UE context.

[0166] The MME-onboard may communicate with the MME-ground during the feeder link period such that each UE context update is provided alongside its timestamp. The MME-onboard should ensure that the final update context that occurs with the MME-ground for a UE in question should consider each NAS procedure that had been completed with the UE. For example, the MME-onboard initiates the necessary procedure and  / or context up towards the MME-ground for each NAS procedure that was completed in a sequential manner.

[0167] The MME-onboard can consider the timing or sequence of events that occurred over one link (e.g. service link or feeder link) when performing or updating context on the other link (feeder link or service link, respectively) .

[0168] When a link is established (for example, the feeder link between MME-ground and MME-onboard or service link between MME-onboard and UE) , either with the UE or MME-ground, the MME-onboard may either have data or signaling, or both, based on some procedures that occurred on the other link (e.g. service link or feeder link, respectively) .

[0169] If the MME-onboard simply synchronizes context without replicating the corresponding procedures on the current link, then data can be lost especially when the context update is related to PDN connections or EPS bearers on which data is sent.

[0170] Figure 8 describes exemplary behaviour of the core network entity, which in this example is an MME-onboard, when it is interacting with the UE over the service link. The MME-onboard can record NAS procedures in sequence based on which context is synchronized in a corresponding sequence with MME-ground.

[0171] In this method 800, the MME-onboard establishes a service link with the UE at 801. At 802, the MME-onboard records a sequence or order of NAS procedures, optionally with a timestamp and / or NAS context changes per procedure if applicable. At 803, the MME-onboard establishes a feeder data link with the MME-ground. At 804, the context update considers the order of NAS procedures previously performed on the service link. The MME-onboard may provide indications of type of procedures, context impacts per procedure, and timestamp. The MME-onboard avoids making a net context update which ignores the order and / or details of the NAS procedures.

[0172] Figure 9 describes exemplary behaviour of the core network entity, which in this example is an MME-onboard, when it is interacting with the further network entity, which in this example is the MME-ground, over the feeder link. MME-onboard records MME-to-MME procedures in sequence based on which context is synchronized in corresponding sequence with UE.

[0173] In this method 900, the MME-onboard at step 901 establishes a feeder data link with the MME-ground. At 902, the MME-onboard records a sequence or order of MME-MME procedures, optionally with a timestamp and / or NAS context changes per procedure if applicable. At 903, the MME-onboard establishes a service data link with the UE. At 904, the context update considers the order of MME-MME procedures previously performed on the feeder link. The MME-onboard may perform NAS procedures such that there is correspondence with procedures on the MME-MME feeder link when applicable.

[0174] For example, if the UE initially sends data over the control plane and then later sends a Detach Request or PDN Disconnect Request to the MME-onboard, the MME-onboard can record the sequence of events of these procedures.

[0175] For every procedure that occurs, the MME-onboard may also record a time stamp corresponding to when the procedure was initiated or completed. The MME-onboard may update a UE context based on one procedure. If this occurs, then the MME-onboard should record the context update that occurs for each NAS procedure.

[0176] For example, the MME-onboard may have a context CONTEXT-0 for the UE at time T-0.

[0177] At time T-1, the UE may send data and this may not lead to any context change, so the UE context becomes CONTEXT-1 at T-1, but in this example CONTEXT-1 is the same as CONTEXT-0 in the sense that the NAS configurations did not change by virtue of sending a data packet. At time T-2, the UE sends a Detach Request (or PDN Disconnect Request) which causes a change to the UE context, and so the context becomes CONTEXT-2 at time T-2.

[0178] When the MME-onboard establishes a feeder link with MME-ground, the MME-onboard should not just provide the latest context in addition to the data. If this occurs, the latest context may indicate a UE is detached (or has no PDN connection) and so the MME-ground may update the context for the UE to indicate that the UE is detached (or that it has no PDN connection) . By doing so, any data which is received for the UE may be discarded since the UE’s context indicate that the UE is detached (or has no PDN connection) .

[0179] Instead, the MME-onboard should consider the sequence of NAS procedures which occurred and update the MME-ground according to the order in which the NAS procedures occurred. For example, the MME-onboard should first send data to the MME-ground which corresponds to the first NAS procedure that the UE had performed. The MME-onboard may also forward an associated UE context to indicate the change of UE context as a result of this procedure. The MME-onboard may also provide a timestamp to indicate the time at which the procedure was performed and / or the time at which the context was updated.

[0180] After this is completed, the MME-onboard can then perform another procedure with the MME-ground to reflect the detach procedure (or PDN disconnect procedure) which was also performed with the UE. The MME-onboard may also send CONTEXT-2 and timestamp T-2.

[0181] By behaving as described above, the UE’s context is updated in a manner that does not lead to data loss.

[0182] Note that the example provided above is not to be restrictive but is meant as a way to explain how the MME-onboard should behave with regards to context update in that the sequence of NAS procedures should be considered. As such the behavior would apply if the actual NAS procedures which had occurred are different from the ones used in the example above.

[0183] Figure 10 shows an exemplary call flow to describe how the MME-onboard can update the MME-ground based on a sequence of procedures on the service link between the MME-onboard and the UE.

[0184] At 1001, the MME-onboard 402 indicates to the UE 401 that the service data link is available. At 1002, the UE sends a CPSR NAS message to the MME-onboard. This is data for EPS bearer ID #6. At 1003, the MME-onboard accepts the service and sends an acknowledgement to the UE.

[0185] At 1004, the MME-onboard records the NAS procedure on the feeder link, optionally recording timestamp (s) and the resulting NAS context (for example, Context-1 and Time T-1.

[0186] At 1005, the UE sends a PDN disconnect request (or detach request) to the MME-onboard. At 1006, the MME-onboard sends a deactivate EPS bearer context request (or detach accept) to the UE.

[0187] At 1007, the MME-onboard records the NAS procedure on the feeder link, optionally recording timestamp (s) and the resulting NAS context (for example, Context-2 and Time T-2) .

[0188] At 1008, the service link is down (unavailable) . At 1009, the feeder link is available.

[0189] At 1010, the MME-onboard updates the context based on Context-1 corresponding to data transfer from the UE, and optionally provides timestamp T-1.

[0190] At 1011, the MME-onboard updates the context based on Context-2 corresponding to PDN disconnect request (or detach request) from the UE, and optionally provides timestamp T-2.

[0191] In an alternative option, when the core network entity (for example, MME-onboard) updates the further network entity (for example, MME-ground) with the context, including forward of data from the UE, the core network entity may not perform two consecutive procedures as described above (which is one option) . The core network entity may send one message to the further network entity and provide all the contexts at different times and may also label each context with a NAS procedure name such that each context can be associated with a NAS procedure. This enables the further network entity to know the procedure that led to the context update. Therefore the core network entity may perform one context update procedure towards the further network entity and include in one message all the partial context updates that occurred per NAS procedure, optionally a NAS procedure name for each context update, and optionally a timestamp per procedure.

[0192] The further network entity may receive partial context for each UE, optionally with a NAS procedure name and optionally with a timestamp. The further network entity may attempt to update the UE’s context based on the sequence of NAS procedures that occurred. As such the update may consider the timestamp or the partial context updates that occurred and the further network entity may perform partial context update to match the NAS procedures that occurred in their sequence of occurrence.

[0193] Figure 11 shows exemplary steps of a method for implementation at a user equipment.

[0194] The user equipment being configured for communication with a core network entity in the mobile network via a first data link, wherein the core network entity is configured to transmit one or more data packets received from the user equipment to a further network entity in the mobile network via a second data link. At step 1101, the method comprises transmitting one or more data packets to the core network entity over the first data link. At step 1102, the method comprises causing a copy of the one or more data packets to be stored in a memory at the user equipment or at the core network entity. At step 1103, the method comprises determining whether the one or more data packets were successfully transmitted from the core network entity to the further network entity. At step 1104, if that determination is positive, the method comprises causing the copy of the one or more data packets to be discarded from the memory.

[0195] Figure 12 shows an exemplary method for implementation at a core network entity. The core network entity is configured for communication with a user equipment in the mobile network via a first data link, wherein the core network entity is configured to transmit one or more data packets received from the user equipment to a further network entity in the mobile network via a second data link. At step 1201, the method comprises receiving one or more data packets from the user equipment over the first data link. At step 1202, the method comprises providing an indication to the user equipment to allow the user equipment to determine whether the one or more data packets were successfully transmitted from the core network entity to the further network entity.

[0196] Figures 13, 14 and 15 show examples of a user equipment, a core network entity (such as an MME-onboard) and a further network entity (such as an MME-ground) respectively.

[0197] The entities 1300, 1400, 1500 comprise a processor 1301, 1401, 1501 and a memory 1302, 1402, 1502. The memory 1302, 1402, 1502 stores in a non-transient way code that is executable by the processor 1301, 1401, 1501 to implement the respective entity in the manner described herein. The network entities 1400, 1500 may be implemented by hardware or may be service-based entity or function, for example it may be implemented as a cloud-based computing device.

[0198] The entities 1300, 1400, 1500 also comprise a transceiver 1303, 1403, 1503 that is capable of communicating with other entities. These entities may be logical entities. In practice they may each be provided by one or more physical devices such as servers and data stores, and the functions of two or more of the entities may be provided by a single physical device. Each physical device implementing an entity comprises a processor and a memory.

[0199] In embodiments of the present invention, the UE, optionally in store and forward operation, sends data, saves a copy locally (or MME on satellite saves a copy) , data is properly identified with a new parameter. If MME-satellite is informed about unsuccessful data transfer, the MME-satellite informs the UE that a data packet was not successfully transferred.

[0200] The UE can re-transmit any data which is indicated to be not successfully transferred. This can allow for recovery from data loss as a result of context not being synchronized in a store and forward deployment architecture.

[0201] The MME entity on satellite can advantageously consider the sequence and order of procedures with the UE when updating the MME on the ground. This can be done by including timestamps and partial context updates to reflect each procedure. This can ensure correct context update without impact on the UE’s service.

[0202] The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein. The applicant indicates that aspects of the present invention may consist of any such individual feature or combination of features. In view of the foregoing description, it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

1.A user equipment (401, 1300) in a mobile network (400) , the user equipment being configured for communication with a core network entity (402, 1400) in the mobile network via a first data link, wherein the core network entity is configured to transmit one or more data packets received from the user equipment to a further network entity (403, 1500) in the mobile network via a second data link, the user equipment being configured to:transmit (1101) one or more data packets to the core network entity over the first data link;cause (1102) a copy of the one or more data packets to be stored in a memory at the user equipment or at the core network entity;determine (1103) whether the one or more data packets were successfully transmitted from the core network entity to the further network entity; andif that determination is positive, cause (1104) the copy of the one or more data packets to be discarded from the memory.2.The user equipment as claimed in claim 1, wherein the first data link and the second data link are not simultaneously available for data packet transmission.3.The user equipment as claimed in claim 1 or claim 2, wherein the user equipment is configured to:determine whether the one or more data packets were successfully transmitted from the core network entity to the further network entity; andif that determination is negative, transmit the copy of the one or more data packets to the core network entity.4.The user equipment as claimed in claim 3, wherein the user equipment is configured to transmit the one or more data packets to the core network entity for storage and wherein the user equipment is configured to, if the determination of whether the one or more data packets were successfully transmitted from the core network entity to the further network entity is negative:retrieve the copy of the one or more data packets from the core network entity; andtransmit the copy of the one or more data packets to the core network entity for transmission to the further network entity.5.The user equipment as claimed in any preceding claim, wherein the determination of whether the one or more data packets were successfully transmitted from the core network entity to the further network entity is an explicit determination or an implicit determination.6.The user equipment as claimed in any preceding claim, wherein the one or more data packets are associated with one or more data identity parameter (s) and wherein the user equipment is configured to determine whether the one or more data packets were successfully transmitted from the core network entity to the further network entity in dependence on the one or more data identity parameter (s) .7.The user equipment as claimed in claim 6, wherein the data identity parameter (s) is / are included in a message comprising the one or more data packets transmitted by the user equipment to the core network entity.8.The user equipment as claimed in claim 6 or claim 7, wherein the data identity parameter (s) are NAS count (s) or a new data identity field in a non-access stratum message transmitted by the user equipment to the core network entity.9.The user equipment as claimed in any of claims 6 to 8, wherein the user equipment causes the data identity parameter (s) to be stored in the memory at the user equipment or at the core network entity with the copy of the one or more data packets.10.The user equipment as claimed in any preceding claim, wherein the user equipment is configured to receive an indication of whether the one or more data packets were successfully transmitted or unsuccessfully transmitted from the core network entity to the further network entity via a subsequent data link between the core network entity and the further network entity.11.The user equipment as claimed in any preceding claim, wherein the user equipment is configured to determine whether the one or more data packets were successfully transmitted from the core network entity to the further network entity in dependence on an evolved packet system bearer context status information element for an evolved packet system bearer intended for transmission of the one or more data packets from the core network entity to the further network entity.12.The user equipment as claimed in claim 11, wherein the user equipment is configured to determine that the one or more data packets were successfully transmitted from the core network entity to the further network entity if the evolved packet system bearer context status information element is not present in a subsequent message received from the core network entity and / or determine that the one or more data packets were unsuccessfully transmitted from the core network entity to the further network entity if the evolved packet system bearer context status information element is present in the subsequent message received from the core network entity and indicates that the evolved packet bearer intended for transmission of the one or more data packets from the core network entity to the further network entity is inactive.13.The user equipment as claimed in any preceding claim, wherein the core network entity and / or the further network entity are sub-entities of a mobility management entity, MME, in the mobile network.14.The user equipment as claimed in any preceding claim, wherein the core network entity is a non-terrestrial entity and the further network entity is a terrestrial entity.15.The user equipment as claimed in any preceding claim, wherein the user equipment is configured to operate in store and forward mode or is configured to access a system which operates in store and forward mode.16.A method (1100) for implementation at a user equipment (401, 1300) in a mobile network (400) , the user equipment being configured for communication with a core network entity (402, 1400) in the mobile network via a first data link, wherein the core network entity is configured to transmit one or more data packets received from the user equipment to a further network entity (403, 1500) in the mobile network via a second data link, the method comprising:transmitting (1101) one or more data packets to the core network entity over the first data link;causing (1102) a copy of the one or more data packets to be stored in a memory at the user equipment or at the core network entity;determining (1103) whether the one or more data packets were successfully transmitted from the core network entity to the further network entity; andif that determination is positive, causing (1104) the copy of the one or more data packets to be discarded from the memory.17.A core network entity (402, 1400) in a mobile network (400) , the core network entity being configured for communication with a user equipment (401, 1300) in the mobile network via a first data link, wherein the core network entity is configured to transmit one or more data packets received from the user equipment to a further network entity (403, 1500) in the mobile network via a second data link, the core network entity being configured to:receive (1201) one or more data packets from the user equipment over the first data link; andprovide (1202) an indication to the user equipment to allow the user equipment to determine whether the one or more data packets were successfully transmitted from the core network entity to the further network entity.18.The core network entity as claimed in claim 17, wherein the first data link and the second data link are not simultaneously available for data packet transmission.19.The core network entity as claimed in claim 17 or claim 18, wherein the core network entity is configured to store a copy of the one or more data packets at a memory of the core network entity.20.The core network entity as claimed in claim 19, wherein the core network entity is configured to provide the copy of the one or more data packets to the user equipment for transmission to the core network entity upon a determination by the user equipment that the one or more data packets were not successfully transmitted from the core network entity to the further network entity.21.The core network entity as claimed in any of claims 17 to 20, wherein the one or more data packets are associated with one or more data identity parameter (s) and wherein the core network entity is configured to provide the one or more data identity parameter (s) to the user equipment to allow the user equipment to determine whether the one or more data packets were successfully transmitted from the core network entity to the further network entity.22.The core network entity as claimed in claim 21, wherein the data identity parameter (s) is / are included in a message comprising the one or more data packets received by the core network entity from the user equipment.23.The core network entity as claimed in claim 21 or claim 22, wherein the data identity parameter (s) are NAS count (s) or a new data identity field in a non-access stratum message received by the core network entity from the user equipment.24.The core network entity as claimed in any of claims 21 to 23 as dependent on claim 19 or claim 20, wherein the data identity parameter (s) are stored in the memory with the one or more data packets.25.The core network entity as claimed in any of claims 17 to 24, wherein the core network entity is configured to record a sequence of events or procedures occurring on the first data link and record one or more updates to a user equipment context of the user equipment as a result of one or more of the events or procedures on the first data link and optionally forward the recorded events or procedures and / or context to the further network entity.26.The core network entity as claimed in any of claims 17 to 25, wherein the core network entity is configured to record a sequence of events or procedures occurring on the second data link and provide one or more updates to a user equipment context of the user equipment as a result of one or more of the events or procedures on the second data link.27.This core network entity as claimed in claim 26, wherein the core network entity is configured to record the sequence of events or procedures occurring on the second data link and replicate these events or procedures with the user equipment on the first data link.28.The core network entity as claimed in claim 25, wherein the core network entity is configured to, for each event or procedure that is completed on the first data link, save the updated user equipment context at a memory of the core network entity and optionally a timestamp indicating a time at which the user equipment context was updated.29.The core network entity as claimed in any of claims 17 to 28, wherein the core network entity and / or the further network entity is / are configured to operate in store and forward mode and is / are configured to use explicit signalling on the second data link between the core network entity and the further network entity to release or deactivate an evolved packet system bearer or a packet data network connection.30.The core network entity as claimed in any of claims 17 to 29, wherein the core network entity and / or the further network entities are sub-entities of a mobility management entity, MME, in the mobile network.31.The core network entity as claimed in any of claims 17 to 30, wherein the core network entity is a non-terrestrial entity and the further network entity is a terrestrial entity.32.A method (1200) for implementation at a core network entity (402, 1400) in a mobile network (400) , the core network entity being configured for communication with a user equipment (401, 1300) in the mobile network via a first data link, wherein the core network entity is configured to transmit one or more data packets received from the user equipment to a further network entity (403, 1500) in the mobile network via a second data link, the method comprising:receiving (1201) one or more data packets from the user equipment over the first data link; andproviding (1202) an indication to the user equipment to allow the user equipment to determine whether the one or more data packets were successfully transmitted from the core network entity to the further network entity.33.A mobile network (400) comprising the user equipment (401, 1300) of any of claims 1 to 15 and the core network entity (402, 1400) of any of claims 17 to 31.

Images