Methods for handling CIoT data for invalid PDU session ID

Abstract

A telecommunications network receives a Control Plane Service Request (CPSR) message from a user equipment (UE) comprising Cellular Internet of Things (CIoT) user data associated with a Protocol Data

Description

The following terms are registered trade ma: an should be rea assuc w they occur in this document; 3GPP Methods for Handling CloT Data for Invalid PDU Session ID The present invention relates to Cellular Internet of Things, CloT, data handling in a telecommunication system when there is no routing context in the Access and Mobility Management Function, AMF. The Fifth Generation System, 5GS, (and Evolved Packet System, EPS) allows CloT devices or User Equipments, UE, to send data over the Control Plane, CP. For example, the UE in idle mode uses the Control Plane Service Request (CPSR) message to send data over Non Access Stratum, NAS, i.e. over the control plane. The service request procedure, in this case associated with the transmission of the CPSR message, is completed by the AMF sending a Service Accept message. When sending the CPSR message for CloT data, the UE includes the Protocol Data Unit, PDU, session identity (ID) which identifies the session for which the data is being sent. This enables the AMF to identify which Session Management Function, SMF, the data should be forwarded to. In some cases, although the UE may have a PDU session ID and context locally (in the UE), the network may have released a PDU session but this may not have been communicated yet to the UE e.g. because the UE is in idle mode. As such, the UE which does not know this event may attempt to send data towards an identified PDU session which ultimately does not exist in the network. 3GPP TS 24.501, section 5.6.1.8, identifies such a scenario and specifies the following handling at the network side: “gl CONTROL PLANE SERVICE REQUEST message received with the Data type field indicates "control plane user data" in the CloT small data container IE or received with Payload container type IE set to "CloT user data container" and: 1) the AMF does not have a PDU session routing context for the PDU session ID and the UE; or 2) the AMF unsuccessfully attempted to forward the user data container and the PDU session ID, then the AMF may send back to the UE the CloT user data container or control! plane user data which was not forwarded as specified in subclause 5.4.5.3. 1 case 11) or case 12).” From the above, it can be seen that the network, in the case of the identified scenario as described in bullet section 1) of the quoted text, may send back to the UE the data which was not forwarded. However, the network uses the DL NAS TRANSPORT procedure to do so i.e. the network sends the DL NAS TRANSPORT message to send back to the UE the data which was not forwarded. The following describes the AMF behaviour for case I1 which is referenced above: “For case 1) in subclause 5.4.5.3.1, i.e. upon sending a single uplink CloT user data container or control plane user data which was not forwarded due to routing failure, the AMF shall: a) include the PDU session ID in the PDU session ID IE; b) set the Payload container type IE to " CloT user data container”; c) set the Payload container IE to the CloT user data container or control plane user data which was not forwarded; and d) set the 5SGMM cause IE to the 5GMM cause #90 "payload was not forwarded" NOTE 4: For case 1) in subclause 5.4.5.3.1, this is also applied for a single uplink CloT user data container or control plane user data in the CONTROL PLANE SERVICE REQUEST message which was not forwarded due to routing failure.” To summarize, the following observations can be made: The UE may send a CPSR message containing CloT user data for a PDU session for which there is no routing context The network may send the data back to the UE using the DL NAS TRANSPORT message and include the 5GMM cause #90 The following relates to Mobile Management Entity, MME, handling of EPS Session Management, ESM, messages for an EPS bearer identity that is not active. In EPS, itis possible that the UE sends an NAS ESM message for which there is no valid EPS bearer identity. In this case, the MME rejects the NAS ESM message and indicates that the EPS bearer identity is not valid. For example, section 6.5.4.6 of 3GPP TS 24.301 specifies the following behaviour for the MME when such a scenario occurs during the bearer resource modification procedure that is initiated by the UE: “a) Unknown EPS bearer context: If the EPS bearer identity provided in the EPS bearer identity for packet filter IE in the BEARER RESOURCE MODIFICATION REQUEST message indicates an EPS bearer identity value and this does not belong to any already activated EPS bearer context the MME shall reply with a BEARER RESOURCE MODIFICATION REJECT message with ESM cause #43 "invalid EPS bearer identity".” As can be seen, it is already a possibility that an ESM message is sent for which the EPS bearer identity is deemed to be invalid. In this case the network rejects the message as shown above. A problem experienced with the prior art described above is that the UE can erroneously conclude that CloT data has been successfully transmitted when it may not have been. To describe the problem, it is useful to consider the following scenario: The UE sends a CPSR message containing CloT user data The AMF does not have any routing context for the associated PDU session ID The AMF does not send the CloT user data back to the UE (since this step is optional) The AMF sends the Service Accept message (which is needed to complete the service request procedure) which does not contain any indication of a failure to route the CloT user data The UE concludes that the CloT user data has been successfully transferred since no indication whatsoever was received about the failure. The NAS layer in the UE may inform the upper layers (e.g. an application or the 5GSM entity) that the data has been successfully sent The upper layers may discard the CloT user data content since no indication of a failed transmission was received. Hence, this prohibits the UE from resending the data which may actually carry crucial information for the application server The above may repeat over and over and, as such, the UE may end up assuming that CloT data was successfully sent while this is not the case The same problem can also occur in the following scenario: The UE sends a CPSR message containing CloT user data The AMF does not have any routing context for the associated PDU session ID The AMF completes the service request procedure by sending a Service Accept message The AMF sends the CloT user data back to the UE using the DL NAS TRANSPORT message For the latter scenario, the reception — by the UE - of the Service Accept message before the DL NAS TRANSPORT message would lead to the UE concluding that the CloT user data was successfully sent. This is because the Service Accept message currently has no indication of a failure and when received by the UE, it can lead the UE to conclude that the service request procedure for the transmission of CloT user data was indeed successful. Afterwards, the reception of the DL NAS TRANSPORT message containing data which was actually not forwarded by the AMF would be quite late. For example, the reception of the Service Accept by the UE may already have triggered an indication of a successful transfer of data to the upper layers which may actually have discarded the content as a result. Then the subsequent reception of the, rather late, DL NAS TRANSPORT message with the indication of an unsuccessful data forwarding by the AMF would not be of much use since the UE has already informed the upper layers of the success. This indication now seems to be contradictory. The scenarios set out above therefore lead to cases in which the UE assumes a successful CloT user data transfer whereas the reality is that this cannot be concluded. This leads to problems for the application layer which “thinks” that data has been successfully transported by the NAS layer whereas the data was actually not delivered and in fact no notice was received, or a contradictory status indication is received. A further issue is the lack of handling by the MME of CloT user data for which there is an invalid EPS bearer identity. If the UE (in S1 mode i.e. in EPS or in LTE) sends CloT user data in the ESM DATA TRANSPORT message which contains an EPS bearer identity that is invalid, then the MME behaviour is not known since no handling is defined in 3GPP TS 24.301 V18.0.0. As such, the UE does not get any indication about this and would therefore assume that the CloT user data has been successfully transmitted. It is therefore an aim of embodiments of the present invention to address these and other shortcomings in the prior art, whether mentioned herein or not. According to the present invention there is provided an apparatus and method as set forth in the appended claims. Other features of the invention will be apparent from the dependent claims, and the description which follows. According to a first aspect of the present invention, there is provided a method of operating a User Equipment, UE, operable to communicate with a telecommunication network, comprising the steps of: the UE sending to the telecommunication network a Control Plane Service Request, CPSR, message with Cellular Internet of Things, CloT, user data, associated with a Protocol Data Unit, PDU, session; the UE receiving from the telecommunication network a SERVICE ACCEPT message, indicating that the PDU session is inactive in the network; and the UE verifying if the PDU session has an identity the same as an identity of the PDU session included in the CPSR message with CloT user data and, if so then the UE determines that the CloT user data was not successfully sent to the telecommunication network or to a final recipient. In an embodiment, the SERVICE ACCEPT message includes a PDU session status Information Element, IE, which indicates that the PDU session corresponding to the PDU session ID, received in the CPSR message, is inactive. According to a second aspect of the present invention, there is provided A UE arranged to perform the method of the first aspect. According to a third aspect of the present invention, there is provided a method of operating a telecommunication network, operable to communicate with a UE, comprising the steps of: the telecommunication network receiving from the UE a Control Plane Service Request, CPSR, message with Cellular Internet of Things, CloT, user data, associated with a Protocol Data Unit, PDU, session; the telecommunication network discarding the CloT data if the PDU session is deemed to be inactive by the telecommunication network; and the telecommunication network sending to the UE a SERVICE ACCEPT message, indicating that the PDU session is inactive in the network. In an embodiment, an Access and Mobility management Function, AMF, is operable in the telecommunication network to receive the CPSR message and to send the SERVICE ACCEPT message. In an embodiment, the SERVICE ACCEPT message includes a PDU session status Information Element, IE, which indicates that the PDU session corresponding to the PDU session ID, received in the CPSR message. is inactive. According to a fourth aspect of the present invention, there is provided a telecommunication network arranged to perform the method of the third aspect. According to a fifth aspect of the present invention, there is provided a telecommunication system comprising the UE of the second aspect and the telecommunication network of the fourth aspect. Although a few preferred embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims. For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example only, to the accompanying diagrammatic drawings in which: Figure 1 shows a flowchart according to a first embodiment; and Figure 2 shows a flowchart according to a second embodiment. A first embodiment of the invention defines a new AMF behaviour for handing CloT user data when there is no routing information. To address the problem that has been identified earlier, there are multiple possible options. Note that the details set out below are for the case of the AMF receiving a CPSR message which contains CloT user data but the AMF does not have PDU session routing context (or information) that is associated with the PDU session ID, and hence the AMF cannot forward the data to the SMF. It should be noted that this may also mean that the PDU session ID that is included in the CPSR message is considered to be a session that is not active (or that is for a session that is inactive or has been released by the network). Option 1 The AMF sends the DL NAS TRANSPORT message which includes the CloT user data which was not forwarded (and hence being sent back to the UE) before sending the Service Accept message. In this option, when the AMF receives the CloT user data in a CPSR message and the AMF does not have PDU session routing context, the AMF should send the CloT user data back to the UE in the DL NAS TRANSPORT message as already specified in 3GPP TS 24.501 V18.0.1. However, what is important and hence set out herein is that the DL NAS TRANSPORT message should be sent before the AMF sends the Service Accept message to the UE. This ensures that the UE is able to conclude that the CloT user data was not successfully sent even when the Service Accept message is subsequently received. Furthermore, the AMF should send the Service Accept message and include the PDU session status Information Element, IE, in the message. Moreover, the AMF should set the PDU session ID, which was received in the CPSR message and for which there is no PDU session routing context, such that the corresponding bit position in the IE indicates that the PDU session is inactive in the network. For example, the (PSI — PDU Session Identity) bit position corresponding to the PDU session ID (which the AMF received in the CPSR message and for which there is no PDU session routing context) should be set to the value 0 by the AMF i.e. “the 5GSM state of the corresponding PDU session is PDU SESSION INACTIVE” (see section 9.11.3.44 of 3GPP TS 24.501 V18.0.1). During a service request procedure for which the UE has sent the CPSR message with CloT user data, if the UE receives the DL NAS TRANSPORT message with a CloT user data (which was not forwarded) and the 5SGMM cause value #90 "payload was not forwarded", the UE should inform the upper layers that the CloT user data was not successfully transmitted. Optionally, the UE behaves as proposed if the DL NAS TRANSPORT message is received before the Service Accept message. During a service request procedure for which the UE has sent the CPSR message with CloT user data, if the UE receives the Service Accept message with the PDU session status IE such that the PDU session ID, which the UE had included in the CPSR message, is now set to indicate or now indicates (in the PDU session status IE) that the PDU session is inactive, then the UE should consider that the CloT user data which was sent in the CPSR message has not been successfully transmitted or delivered or transferred by the network. The UE should inform the upper layers that the CloT user data was not successfully transferred. The UE may also send the PDU session ID to the upper layers to specify which PDU session ID is being referred to. Note that the UE sending the proposed indication to the upper layer may mean any of the following alternatives with respect to the proposed indication above (optionally with the PDU session ID in question): The UE NAS 5GMM entity informs the SGSM entity, which in turn may inform the application layers The UE NAS SGSM entity informs the application layer The UE NAS SGMM entity informs the application layer Option 2 The AMF sends the SGMM STATUS message to the UE. In this option, when the identified scenario, as explained earlier occurs, the AMF should send the 5GMM STATUS message to the UE. The AMF may set the 5GMM cause value to any existing value (e.g. #90) or to a new value. Optionally the AMF may include the PDU session ID as a new field in the 5GMM STATUS message. It is preferable that the AMF sends the 5GMM STATUS message to the UE before sending the Service Accept message. During a service request procedure for which the UE has sent the CPSR message with CloT user data, if the UE receives the 5GMM STATUS message (optionally with the PDU session ID, optionally where this message may be received before or after receiving a Service Accept message) then the UE should consider that the CloT user data which was sent in the CPSR message has not been successfully transmitted or delivered or transferred by the network. The UE should inform the upper layers that the CloT user data was not successfully transferred. The UE may also send the PDU session ID, if received, to the upper layers to specify which PDU session ID is being referred to. In this case, the UE may also locally deactivate the PDU session that is identified by the PDU session ID, where this identification is either explicitly received by the UE or determined by the UE to be the PDU session ID that was sent by the UE in a previous NAS message such as a Control Plane Service Request message or the UL NAS TRANSPORT message. Note that this local deactivation of the session may also be performed by the UE for any of the options set out herein. Moreover the UE can take this action regardless of the content that was sent by the UE e.g. the content may be CloT user data or any 5GSM message. The UE may behave as described e.g. whenever the cause value #90 is received in any NAS message. Note that the UE sending the proposed indication to the upper layer may mean any of the following alternatives with respect to the proposed indication above (optionally with the PDU session ID in question): The UE NAS 5GMM entity informs the SGSM entity, which in turn may inform the application layers The UE NAS 5GSM entity informs the application layer The UE NAS SGMM entity informs the application layer Option 3 The AMF sends the Service Accept message to the UE and includes an indication that the CloT user data was not forwarded. In this option, when the identified scenario as set out earlier occurs, the AMF sends the Service Accept message to the UE and also includes an indication that the CloT user data (which was received in the CPSR message) was not successfully forwarded or transferred. The AMF may include a new indication or may include the 5GMM cause value and set it to #90 or any other new value which would indicate the lack of success in transferring of the CloT user data. The Service Accept message may also include a PDU session ID to refer to the session for which the CloT user data was not successfully transferred. The Service Accept may also include the CloT user data which was not forwarded by the AMF. During a service request procedure for which the UE has sent the CPSR message with CloT user data, if the UE receives the Service Accept message (optionally with the PDU session ID) with an indication that the CloT user data was not successfully transferred, then the UE should inform the upper layers that the CloT user data was not successfully transferred. The UE may also send the PDU session ID, if received, to the upper layers to specify which PDU session ID is being referred to. The UE may also send the CloT user data transfer (which was not forwarded by the AMF), if received, to the upper layers. Note that the UE sending the indication to the upper layer may mean any of the following alternatives with respect to the proposed indication above (optionally with the PDU session ID in question): The UE NAS 5GMM entity informs the SGSM entity, which in turn may inform the application layers The UE NAS SGSM entity informs the application layer The UE NAS SGMM entity informs the application layer Option 4 The AMF sends the Service Reject message to the UE and includes an indication that the CloT user data was not forwarded. In this option, when the identified scenario as set out earlier occurs, the AMF sends the Service Reject message to the UE and also includes an indication that the CloT user data (which was received in the CPSR message) was not successfully forwarded or transferred. The AMF may include a new indication or may include the 5GMM cause value and set it to #90 or any other new value which would indicate the lack of success in transferring of the CloT user data. The Service Reject message may also include a PDU session ID to refer to the session for which the CloT user data was not successfully transferred. The Service Accept may also include the CloT user data which was not forwarded by the AMF. During a service request procedure for which the UE has sent the CPSR message with CloT user data, if the UE receives the Service Reject message (optionally with the PDU session ID) with an indication that the CloT user data was not successfully transferred (e.g. in the forms of a new or existing 5GMM cause value), then the UE should inform the upper layers that the CloT user data was not successfully transferred. The UE may also send the PDU session ID, if received, to the upper layers to specify which PDU session ID is being referred to. The UE may also send the CloT user data transfer (which was not forwarded by the AMF), if received, to the upper layers. Note that the UE remains in (or enters) 5GMM-REGISTERED state. Note that the UE sending the indication to the upper layer may mean any of the following alternatives with respect to the indication above (optionally with the PDU session ID in question): The UE NAS 5GMM entity informs the 5GSM entity, which in turn may inform the application layers The UE NAS 5GSM entity informs the application layer The UE NAS SGMM entity informs the application layer For any of the options above, during the service request procedure for which the UE sent a CPSR message including a CloT user data, if the UE receives a Service Accept or Service Reject message with the PDU session status IE such that the PDU session ID which was sent in the CPSR message (with the CloT user data) is set such that it indicates that the PDU session is inactive in the network, then the UE should consider (or determine or conclude) that the CloT user data was not successfully sent or transmitted. The UE should inform the upper layers about this failure in CloT user data transmission and optionally also provide the PDU session ID in question, where this ID may be received in the Service Accept message or derived from the CPSR message which was sent earlier. Option 5 The AMF sends the Service Accept message to the UE and includes the PDU session status IE and indicates that the PDU session corresponding to the PDU session ID (received in the CPSR message) is inactive. In this option, when the identified scenario as set out earlier occurs, the AMF should include the PDU session status IE in the Service Accept message. Additionally, the AMF should set the bit (i.e. the PSI bit) corresponding to the PDU session identity (for which there is no PDU session routing context) to indicate that the PDU session is inactive. In other words, when sending the SERVICE ACCEPT message the AMF shall include the PDU session status IE and set the bit corresponding to the received PDU session ID (e.g. from the CPSR message) to indicate that the PDU session is inactive. During a service request procedure for which the UE has sent the CPSR message with CloT user data, if the UE receives the Service Accept message with a PDU session status IE such that a PDU session (identified by a PDU session ID) is indicated to be inactive in the network (e.g. in the AMF) and the PDU session ID is the same as the PDU session ID that the UE had used in a CPSR message which contained CloT user data, then the UE determines that the CloT user data was not successfully sent. The UE informs the 5GSM entity that the CloT user data was not successfully sent for the PDU session identity. Note that the behaviour above may be performed optionally after the UE has locally released the PDU session which has been identified to be inactive at the network (via the PDU session status IE). Optionally, the UE behaves as described above if the UE has not received (optionally before receiving the Service Accept message) a DL NAS TRANSPORT message with the 5GMM cause value #90 and optionally a CloT user data which was not forwarded. Note that when the UE sends the PDU session ID to the upper layers (as described above), the UE may determine the PDU session ID as the PDU session ID that was sent by the UE in the NAS message (which contained the CloT user data) i.e. either the Control Plane Service Request message or the UL NAS TRANSPORT message. Note that this can apply for any of the options herein described. Note that the UE sending the indication to the upper layer may mean any of the following alternatives with respect to the indication above (optionally with the PDU session ID in question): The UE NAS 5GMM entity informs the SGSM entity, which in turn may inform the application layers The UE NAS 5GSM entity informs the application layer The UE NAS SGMM entity informs the application layer The following details apply for the UE regardless of the particular options selected above. If the UE receives any NAS message (e.g. DL NAS TRANSPORT message, Service Accept message, Service Reject message, etc) which includes the 5GMM cause value #90 "payload was not forwarded" and optionally a PDU session identity, the UE should locally deactivate (or release) the PDU session which is identified by the PDU session identity that has been received. Note that the 5GMM entity or the 5GSM entity may perform the actual local release of the PDU session. In the case of the 5GSM entity, the 5GSM can perform this behaviour if it receives the cause value #90 from the 5GMM entity optionally along with (at least a) PDU session identity. Note that the steps above may be applied optionally if the content of the message which was not forwarded is a 5GSM message or a CloT user data, however the main condition is that the cause value should be associated with a PDU session identity. For any of the options 1-5 above, if the AMF receives CloT user data such that the PDU session ID (for which the data is being sent) is inactive in the network, the AMF should discard the contents of the message or the AMF should discard the CloT user data contents. Note that this applies to any NAS message which carries CloT user data such as the Control Plane Service Request message or the UL NAS TRANSPORT message. The following can be an example of AMF behavior when the NAS message received is a Control Plane Service Request message. If a CONTROL PLANE SERVICE REQUEST message (or UL NAS TRANSPORT message) is received with CloT user data for a PDU session that is not active in the network, the AMF shall discard the CloT user data. The AMF shall send the SERVICE ACCEPT message and indicate that this PDU session ID is inactive using the PDU session status IE. Alternatively (optionally for the case of AMF receiving an UL NAS TRANSPORT), the AMF may send a DL NAS TRANSPORT or a 5GMM STATUS message. The AMF may take the same actions for any option or for any NAS message that is received. E.g. AMF may apply similar behaviour for the case when Service Accept is received. Alternatively, the AMF may send a Service Reject message with a Back Off, BO, timer that may be any of the BO timer for DNN, S-NSSAI, or DNN and S-NSSAI congestion. E.g. the timer sent may be related to T3396, T3584 or T3585. Alternatively the timer may be related to 5GMM congestion such as T3446 or congestion for CloT data over control plane e.g. T3448 or a service gap timer T3447, or any BO timer. Note that this can be applied for any of the options 1-5 herein. All of the steps and actions set out herein can be applied in any combination or order. For example, steps or actions from different options set out herein can be combined and applied in any order. Moreover, all the AMF behaviour that has been described herein can also apply to the MME as new MME behaviour and vice versa. For example, for all the detailed descriptions of behaviour herein, the AMF behaviour can be applicable to MME behaviour and vice versa. In doing so, all parameters or messages in specific systems can be either the same or similar. For example, a PDU session ID in N1 mode (5GS) may be considered to be EPS bearer ID in $1 mode (EPS), and vice versa. The skilled person will readily appreciate the correlation and similarities between 5G and EPS and make any necessary adaptations. Note that for the options above (in any of the options or combination of options), the AMF behaviour (or MME behaviour) would be the same regardless of the message which carries the CloT user data. For example, the AMF may receive either Control Plane Service Request message or UL NAS TRANSPORT message with CloT user data and for which the PDU session ID is either invalid or has no routing context. The AMF behaviour may be any combination of the options herein. Similarly, the UE behaviour set out for any of the options may be applied to any NAS message that is received and hence is not tied to a specific NAS message that is received from the AMF. All steps can be applied in any order or combination for any NAS message that is received at the UE and / or the network, and optionally for a PDU session ID that is either invalid (or inactive or not active) or for which there is no routing context. For any of the options above or herein, or for any other use case not necessarily related to CloT user data, if the AMF receives a NAS message (and optionally other data contents such as but not limited to CloT user data) for a PDU session for which the PDU session ID is not active (or is inactive), then the AMF may also locally deactivate the PDU session context (i.e. set the context of the PDU session associated with the PDU session ID to be inactive). The AMF may also inform the SMF to release or deactivate the PDU session. Hence this applies when the NAS message received by the AMF contains a 5GSM message or any other content that is destined for an SMF. Embodiments can be applied for any NAS message that is received or whenever the AMF determines that a PDU session has no routing context. Note that all the details set out for the UE may be applied by the 5GMM entity or the 5GSM entity or both or any other entity in the UE or the entire NAS entity. All details apply for any content that the UE / AMF sends / receives and is not restricted to CloT user data but can also include e.g. 5GSM NAS messages, or any combination of CloT user data and 5GSM NAS messages. For all the details above, the AMF can also include the PDU session status IE (as described above) in the DL NAS TRANSPORT message also. The UE behaviour would be the same when this message is received with PDU session status IE. In other words, regardless of the type of message received (e.g. Service Accept or DL NAS TRANSPORT message), the UE will process the PDU session status IE in the same manner as set out herein or as described in 3GPP TS 24.501 V18.0.1. In relation to the problem of a lack of handling by the MME of CloT user data for which there is an invalid EPS bearer identity, the following embodiment applies. If the MME receives the ESM DATA TRANSPORT message (either as a standalone ESM message or included in the CPSR message) and EPS bearer identity which is included in the ESM DATA TRANSPORT message indicates an EPS bearer identity value (or is for an EPS bearer) which does not belong to any already activated EPS bearer context in the MME, then the MME should behave as follows in any order or combination: The MME should discard the CloT user data or the contents of the ESM DATA TRANSPORT message The MME should abort the service request procedure or abort the transport of user data via the control plane procedure (or the ESM data transport procedure) The MME should send the ESM STATUS message to the UE and include the ESM cause value #43 “Invalid EPS bearer identity”. Note that the MME may still send a Service Accept message to the UE Note that an EPS bearer identity value which does not belong to any already activated EPS bearer context can mean that the state of the EPS bearer (which is associated with the EPS bearer identity in question) is BEARER CONTEXT INACTIVE. During a service request procedure for which the UE sends (or had sent) a CPSR message which included the ESM DATA TRANSPORT message or which included CloT user data, if the UE receives the ESM STATUS message, optionally with cause value #43, then the UE should stop the associated timer i.e. T3417. Optionally, the UE considers that the CloT user data was not successfully transmitted and may also optionally provide an indication to the upper layers that the data was not successfully transmitted. Note that the UE sending the proposed indication to the upper layer may mean any of the following alternatives with respect to the proposed indication above (optionally with the EPS bearer ID in question e.g. the EPS bearer ID that the UE had included in the ESM DATA TRANSPORT message): The UE NAS EMM entity informs the ESM entity, which in turn may inform the application layers The UE NAS ESM entity informs the application layer The UE NAS EMM entity informs the application layer Note that the details above are also applicable for the case when the UE sends the ESM DATA TRANSPORT message in connected mode i.e. the ESM message is not sent as part of the CPSR message. As such, the same would apply. For example, the following MME behaviour is provided for, regardless of whether the ESM DATA TRANSPORT message is sent in the CPSR message or not. If the EPS bearer identity provided in the ESM DATA TRANSPORT message (which is received by the MME) indicates an EPS bearer identity value which does not belong to any already activated EPS bearer context, the MME shall abort the transport of user data via the control plane procedure. The MME shall then send the ESM STATUS message with ESM cause #43 "invalid EPS bearer identity". If the EPS bearer identity provided in the ESM DATA TRANSPORT message (which is received by the MME) indicates an EPS bearer identity value which does not belong to any already activated EPS bearer context, the MME shall discard the contents of the ESM DATA TRANSPORT message. The MME shall send the ESM STATUS message with ESM cause #43 "invalid EPS bearer identity". A similar solution is also provided for the UE which may receive the ESM DATA TRANSPORT message with an EPS bearer identity that is invalid (or that corresponds with an EPS bearer context that is not active in the UE). If the EPS bearer identity provided in the ESM DATA TRANSPORT message (which is received by the UE) indicates an EPS bearer identity value which does not belong to any already activated EPS bearer context, the UE shall abort the transport of user data via the control plane procedure. The UE shall then send the ESM STATUS message with ESM cause #43 "invalid EPS bearer identity". If the EPS bearer identity provided in the ESM DATA TRANSPORT message (which is received by the UE) indicates an EPS bearer identity value which does not belong to any already activated EPS bearer context, the UE shall discard the contents of the ESM DATA TRANSPORT message. The UE shall then send the ESM STATUS message with ESM cause #43 "invalid EPS bearer identity". Note that for every detailed procedure or set of steps described herein, the steps or actions may apply in any order or combination. The proposals also apply in S1 mode or N1 mode. For completeness, Figure 1 shows a flowchart connected with a first embodiment from the UE perspective. At Step S101, the UE sends to the telecommunication network a Control Plane Service Request, CPSR, message with Cellular Internet of Things, CloT, user data, associated with a Protocol Data Unit, PDU, session. At step S102, the UE receives from the telecommunication network a SERVICE ACCEPT message, indicating that the PDU session is inactive in the network. At step S103, the UE verifies if the PDU session has an identity the same as an identity of the PDU session included in the CPSR message with CloT user data and, if so then the UE determines that the CloT user data was not successfully sent to the telecommunication network Figure 2 shows a flowchart connected with a second embodiment from the network perspective. At Step S201, the telecommunication network receives from the UE a Control Plane Service Request, CPSR, message with Cellular Internet of Things, CloT, user data, associated with a Protocol Data Unit, PDU, session. At step S202, the telecommunication network discards the CloT data. At step S203, the telecommunication network sends to the UE a SERVICE ACCEPT message, indicating that the PDU session is inactive in the network. At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as ‘component’, ‘module’ or ‘unit’ used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term “comprising” or “comprises” means including the component(s) specified but not to the exclusion of the presence of others. Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

CLAIMS 1. A method of operating a User Equipment, UE, operable to communicate with a telecommunication network, comprising the steps of: the UE sending to the telecommunication network a Control Plane Service Request, CPSR, message with Cellular Internet of Things, CloT, user data, associated with a Protocol Data Unit, PDU, session: the UE receiving from the telecommunication network a SERVICE ACCEPT message, indicating that the PDU session is inactive in the network; and the UE verifying if the PDU session has an identity the same as an identity of the PDU session included in the CPSR message with CloT user data and, if so then the UE determines that the CloT user data was not successfully sent to the telecommunication network or to a final recipient.

2. The method of claim 1 wherein the SERVICE ACCEPT message includes a PDU session status Information Element, IE, which indicates that the PDU session corresponding to the PDU session ID, received in the CPSR message, is inactive.

3. A UE arranged to perform the method of any preceding claim.

4. A method of operating a telecommunication network, operable to communicate with a UE, comprising the steps of: the telecommunication network receiving from the UE a Control Plane Service Request, CPSR, message with Cellular Internet of Things, CloT, user data, associated with a Protocol Data Unit, PDU, session; the telecommunication network discarding the CloT data if the PDU session is deemed to be inactive by the telecommunication network; and the telecommunication network sending to the UE a SERVICE ACCEPT message, indicating that the PDU session is inactive in the network.

5. The method of claim 4 wherein an Access and Mobility management Function, AMF, is operable in the telecommunication network to receive the CPSR message and to send the SERVICE ACCEPT message.

6. The method of claim 4 or 5 wherein the SERVICE ACCEPT message includes a PDU session status Information Element, IE, which indicates that the PDU session corresponding to the PDU session ID, received in the CPSR message, is inactive. A A telecommunication network arranged to perform the method of any of claims 4 to 6.

8. A telecommunication system comprising the UE of claim 3 and the telecommunication network of claim 7.

Images