Improvements in and relating to handling a PDU session for local area data network during interworking with EPS

By having the UE locally delete EPS bearer context for LADN PDU sessions, the invention addresses inconsistent UE behavior during 5G to 4G interworking, ensuring seamless transitions and preventing LADN sessions from being transferred to EPS, thus enhancing network interoperability.

GB2628211BActive Publication Date: 2025-09-03SAMSUNG ELECTRONICS CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
GB2024000463
Authority / Receiving Office
GB · GB
Patent Type
Patents
Current Assignee / Owner
Priority Date
2023-02-16
Filing Date
2024-01-12
Publication Date
2025-09-03
Estimated Expiration
2044-01-12

AI Technical Summary

Technical Problem

There is a lack of clear UE behavior when handling PDU sessions for Local Area Data Networks (LADN) during interworking with Evolved Packet System (EPS), leading to inconsistent and unpredictable behavior, particularly during inter-system changes from 5G (N1 mode) to 4G (S1 mode).

Method used

The User Equipment (UE) is instructed to locally delete mapped EPS bearer context for LADN PDU sessions upon receiving such context, ensuring no transfer to EPS, and can optionally suspend or release the session, set the EPS bearer context status to inactive, or attempt transfer while leaving it to the network to reject.

Benefits of technology

This approach ensures consistent UE behavior, preventing LADN PDU sessions from being transferred to EPS, thereby resolving inter-operability issues and maintaining network integrity during inter-system changes.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000001_0000
    Figure 00000001_0000
Patent Text Reader

Abstract

A method of interworking between a first and a second telecommunication type, wherein if a User Equipment, UE, receives S101 any mapped Evolved Packet System, EPS, bearer context for a Protocol Data U
Need to check novelty before this filing date? Find Prior Art

Description

The present invention relates to interworking between two different network types. In particular, the invention addresses issues encountered when interworking between a Fifth Generation (5G) network and an earlier network, especially a Fourth Generation (4G) network such as Evolved Packet System (EPS). As part of the Protocol Data Unit (PDU) session establishment procedure, or the PDU session modification procedure, a User Equipment (UE) normally checks for numerous conditions with respect to the session context. Some of these conditions stem from certain requirements which must be enforced by the UE, and in some cases if these conditions are not met then the UE will need to take certain actions to correct an error which has been detected locally. For example, it is known that a PDU session of type Unstructured can only have a default Quality of Service (QoS) rule. Although this is a requirement and expectation, the UE - during PDU session establishment or PDU session modification - would verify if the QoS parameters contain any operation to create a QoS rule which is not a default QoS rule. If this is the case, then the UE would perform session management signalling (and in particular the PDU session modification procedure) in order to delete any QoS rule which is not a default QoS rule. This is one of many examples of QoS checks that the UE performs and, in many cases, would need to take corrective actions when certain requirements are not met (or when certain conditions are not in place). The detailed UE behaviour in terms of QoS checks and corrective actions can be found in 3GPP TS 24.501. The Fifth Generation System (5GS) supports the concept of Local Area Data Network (LADN) which is a PDU session, which provides access to a local data network (DN) identified by a DN Name (DNN). The access to this local DN requires physical presence of the UE within one of the Tracking Area Identities (TAIs) where the DN is deployed. The following is an excerpt from TS 23.501 describing the LADN feature: “5.6.5Support for Local Area Data Network The access to a DN via a PDU Session for a LADN is only available in a specific LADN service area. A LADN service area is a set of Tracking Areas. LADN is a service provided by the serving PLMN. It includes: LADN service applies only to 3GPP accesses and does not apply in Home Routed case. The usage of LADN DNN requires an explicit subscription to this DNN or subscription to a wildcard DNN. Whether a DNN corresponds to a LADN service is an attribute of a DNN and is per PLMN. The UE is configured to know whether a DNN is a LADN DNN on a per-PLMN basis, and an association between application and LADN DNN. The configured association is considered to be a UE local configuration defined in TS 23.503

[45] . Alternatively, the UE gets the information whether a DNN is a LADN DNN from LADN Information during (re-)registration procedure as described in this clause. NOTE 1: No other procedure for configuring the UE to know whether a DNN is a LADN DNN is defined in this release of the specifications. NOTE 2: The procedure for configuring the UE to know an association between application and LADN DNN is not defined in this release of the specifications. LADN service area and LADN DNN are configured in the AMF on a per DN basis, i.e. for different UEs accessing the same LADN, the configured LADN service area is the same regardless of other factors (e.g. UE's Registration Area or UE subscription). NOTE 3: If a LADN is not available in any TA of an AMF's service area, the AMF is not required to be configured with any LADN related information for that DNN. LADN Information (i.e. LADN Service Area Information and LADN DNN) is provided by AMF to the UE during the Registration procedure or UE Configuration Update procedure. For each LADN DNN configured in the AMF, the corresponding LADN Service Area Information includes a set of Tracking Areas that belong to the Registration Area that the AMF assigns to the UE (i.e. the intersection of the LADN service area and the assigned Registration Area). The AMF shall not create Registration Area based on the availability ofLADNs. NOTE 4: It is thus possible that the LADN Service Area Information sent by the AMF to the UE contains only a sub-set of the full LADN service area as the LADN service area can contain TA(s) outside of the registration area of the UE or outside of the area served by the AMF. When the UE performs a successful (re-)registration procedure, the AMF may provide to the UE, based on local configuration (e.g. via OAM) about LADN, on UE location, and on UE subscription information received from the UDM about subscribed DNN(s), the LADN Information for the list of LADN available to the UE in that Registration Area in the Registration Accept message. The UE may provide either the LADN DNN(s) to retrieve the LADN Information for the indicated LADN DNN(s) or an indication of Requesting LADN Information to retrieve the LADN Information for all LADN(s) available in the current Registration Area. The list of LADN is determined as follows: If neither LADN DNN nor an indication of requesting LADN Information is provided in the Registration Request message, the list of LADN is the LADN DNN(s) in subscribed DNN list except for wildcard DNN. If the UE provides LADN DNN(s) in the Registration Request message, the list of LADN is LADN DNN(s) the UE requested if the UE subscribed DNN(s) includes the requested LADN DNN or if a wildcard DNN is included in the UE's subscription data. NOTE 5: It is assumed that an application can use only one LADN DNN at a time. If the UE provides an indication of requesting LADN Information in the Registration Request message, the list of LADN is all the LADN DNN(s) configured in the AMF if the wildcard DNN is subscribed, or the LADN DNN(s) which is in subscribed DNN list and no wildcard DNN is subscribed. The UE considers the retrieved LADN Information valid only for the registered PLMN and the E-PLMN(s) if the LADN Service Area Information includes Tracking Areas that belong to E-PLMN(s). Additionally, an LADN DNN discovered by the UE via the retrieved LADN Information is considered an LADN DNN also in the E-PLMNs of the Registered PLMN, i.e. the UE can request LADN Information for the discovered LADN DNN in the E-PLMNs. During the subsequent Registration procedure, if the network does not provide LADN Information for a DNN, the UE deletes any LADN Information for that DNN. When the LADN Information for the UE in the 5GC is changed, the AMF shall update LADN Information to the UE through UE Configuration Update / Registration procedure as described in clauses 4.2.4 / 4.2.2.2.2 of TS 23.502. When receiving PDU Session Establishment with LADN DNN or Service Request for the established PDU Session corresponding to LADN, the AMF determines UE presence in LADN service area and forwards it to the SMF if the requested DNN is configured at the AMF as a LADN DNN. Based on the LADN Service Area Information in the UE, the UE determines whether it is in or out of a LADN service area, if the UE does not have the LADN Service Area Information fora LADN DNN, the UE shall consider it is out of the LADN service area. The UE takes actions as follows: a) When the UE is out of a LADN service area, the UE: shall not request to activate UP connection of a PDU Session for this LADN DNN; shall not establish / modify a PDU Session for this LADN DNN (except for PS Data Off status change reporting for an established PDU Session); need not release any existing PDU Session for this LADN DNN unless UE receives explicit SM PDU Session Release Request message from the network. b) M / hen the UE is in a LADN service area, the UE: may request a PDU Session Establishment / Modification for this LADN DNN; may request to activate UP connection of the existing PDU Session for this LADN DNN. NOTE 6: The evaluation of Service Area Restrictions will be performed before the evaluation of LADN service area, if the UE has overlapping areas between Service Area Restrictions and LADN service area. The SMF supporting a DNN is configured with information about whether this DNN is a LADN DNN or not. When receiving SM request corresponding an LADN from the AMF, the SMF determines whether the UE is inside LADN service area based on the indication (i.e. UE Presence in LADN service area) received from the AMF. If the SMF does not receive the indication, the SMF considers that the UE is outside of the LADN service area. The SMF shall reject the request if the UE is outside of the LADN service area. When the SMF receives a request for PDU Session Establishment with the LADN DNN, it shall subscribe to "UE mobility event notification" for reporting UE presence in Area of Interest by providing LADN DNN to the AMF as described in clauses 5.6.11 and 5.3.4.4. Based on the notification about the UE presence in LADN service area notified by AMF (i.e. IN, OUT, or UNKNOWN), the SMF takes actions as follows based on operator's policy: a) When SMF is informed that the UE presence in a LADN service area is OUT, the SMF shall: release the PDU Session immediately; or deactivate the user plane connection for the PDU Session with maintaining the PDU Session and ensure the Data Notification is disabled and the SMF may release the PDU Session if the SMF is not informed that the UE moves into the LADN service area after a period. b) When SMF is informed that the UE presence a LADN service area is IN, the SMF shall: ensure that Data Notification is enabled. trigger the Network triggered Service Request procedure for a LADN PDU Session to active the UP connection when the SMF receives downlink data or Data Notification from UPF. c) When the SMF is informed that the UE presence in a LADN service area is UNKNOWN, the SMF may: ensure that Data Notification is enabled. trigger the Network triggered Service Request procedure for a LADN PDU Session to active the UP connection when the SMF receives downlink data or Data Notification from UPF. SMF may make use of UE mobility analytics provided by NWDAF, as described in clause 6.7.2 of TS 23.288

[86] , to determine UE presence pattern in LADN service area and take a decision how to handle LADN PDN Session (e.g. release the PDU Session immediately, or deactivate the user plane connection for the PDU Session with maintaining the PDU Session).” Note that LADN PDU sessions are only supported over 3GPP access in the 5GS. A problem encountered in the prior art is that there is a lack of clear UE behaviour with respect to handling of PDU session for LADN during Interworking (IWK) with EPS. PDU sessions for LADN are only supported in 5GS and hence transferring such a PDU session to EPS will simply not work. As indicated earlier, the UE already performs certain checks and takes certain actions when some requirements are not in place, or when the conditions pertaining to some requirements are met (or not met depending on the problem in question), however there is no clearly defined action that the UE currently performs to meet this requirement. Looking at TS 24.501, the following is stated: “Upon inter-system change from N1 mode to S1 mode in EMM-IDLE mode, the UE shall not transfer a PDU session for LADN to EPS. ” As can be seen, the above is a very general requirement for which no action has been defined for the UE, in order to enforce it. This can lead to inconsistent or unpredictable behaviour. Note that a PDU session is considered to be transferable to EPS when the UE (in 5GS) receives related EPS bearer context, such that the context would be the corresponding EPS context that is activated and used by the UE upon an inter-system change from N1 mode to S1 mode. Moreover, the requirement above does not, and cannot, prohibit the possibility that the network sends related EPS bearer context for a PDU session that is providing access to LADN. Note that such problems already exist i.e. there are certain things that should not happen, yet the UE verifies if they occur and then takes corrective measures accordingly (as has already been discussed). So, the requirement above does not prohibit the UE from receiving EPS bearer context for a PDU session for LADN. The problem therefore becomes as follows: when the UE receives such context, a UE may erroneously conclude that the session may be transferred to EPS despite the requirement that has been quoted above from TS 24.501, There are currently no means provided to handle this scenario and hence the following possible outcomes can occur in which different UEs may act differently: • One UE may thus behave as follows: the UE considers that LADN PDU sessions are not transferrable to EPS because the network is not expected to send any EPS bearer context. However, once it is received, then the UE will attempt to transfer the session • One UE may behave as follows: the UE will attempt to transfer the session but the target network (e.g. EPS, or the MME in EPS) will reject the request to transfer,. There may be other actions that a UE may take and, as such, the problem becomes that there is no standard behaviour and this may result in inter-operability issues especially when this case potentially leads to signalling with a network e.g. the UE attempting to transfer a session for LADN in EPS, thereby involving the MME and potentially MME contacting the AMF to attempt and transfer the session. To summarize, a clear behaviour is desirable to ensure that a PDU session for LADN in 5GS (i.e. N1 mode) is not transferred to EPS (i.e. S1 mode). It is an aim of embodiments of the present invention to address this and possible other problems 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 interworking between a first and a second telecommunication type, wherein if a User Equipment, UE, receives any mapped Evolved Packet System, EPS, bearer context for a Protocol Data Unit, PDU, session for Local Area Data Network, LADN, the UE acts to locally delete the mapped EPS bearer context. In an embodiment, the bearer context information is received by the UE in a Non-Access Stratum, NAS, message. In an embodiment, the EPS bearer context is received as part of a PDU session establishment procedure, in a PDU Session Establishment Accept message, or as part of a PDU session modification procedure, in a PDU Session Modification Command message. In an embodiment, the UE acts to locally delete the mapped EPS bearer context without informing a Session Maintenance Function of the first or second type of telecommunication network. In an embodiment, the UE supports N1 mode and S1 mode. In an embodiment, the UE is operable in single registration mode or dual registration mode. In an embodiment, the UE receives an indication that N26 interface is supported. According to a second aspect of the present invention, there is provided an apparatus arranged to perform the method of the first aspect. Aspects of the invention define clear UE behaviour to handle PDU session for LADN during or after an inter-system change from N1 mode to S1 mode. Some of the behaviours include: deleting any EPS bearer context while in 5GS, where this may occur using explicit signaling or locally, and hence the session for LADN is not transferred. Other solutions include local release of the PDU session during / after the transfer. One proposed solution is for the UE to set any EPS bearer identity, which was received as part of the context for a PDU session for LADN, to indicate that the bearer is inactive in the EPS bearer context status IE. Finally the UE may attempt to transfer the LADN PDU session but leave it up to the network to reject it, or the UE may locally suspend the session and attempt to re-use it when it comes back to N1 mode. 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 representing a first embodiment of the invention. In a first embodiment, the UE further verifies if the context ofthe PDU session for LADN contains EPS bearer context information. The UE with a PDU session for LADN should verify if any EPS bearer context information is received in a 5GSM (5G Session Management) message such as the PDU Session Establishment Accept message (e.g. during the PDU session establishment procedure) or the PDU Session Modification Command message (e.g. during the PDU session modification procedure), then the UE may consider this to be e.g. an error, or the UE may determine that corrective action needs to be taken. Note that the EPS bearer context information should be considered as a general term that refers to any QoS parameter for EPS, or as any form of EPS bearer context, where the EPS bearer context information may be received in the Mapped EPS bearer contexts IE, or as part ofthe QoS flow descriptions IE (e.g. in which the EPS bearer identity may be present and hence this can be a form of EPS bearer context information). When the UE detects that a PDU session for LADN has at least one EPS bearer, the UE may consider that this is an error. Optionally the UE may then take any ofthe actions as described in the following. Actions that the UE should take during the ongoing 5GSM procedure (which may be a PDU session establishment procedure or PDU session modification procedure) include: • After the completion of the ongoing procedure, the UE may initiate the release of the PDU session e.g. by sending the PDU Session Release Request message. The UE may include a new 5GSM cause value or an existing 5GSM cause value e.g. #83 "semantic error in the QoS operation" or #84 "syntactical error in the QoS operation" o Optionally, the UE behaves as described above if the EPS bearer context information which has been received is associated with the default QoS rule • After the completion of the ongoing procedure, the UE may initiate the PDU session modification procedure e.g. by sending the PDU Session Modification Request message in order to delete any EPS bearer context (information) which has been received (either in the QoS rules IE or the QoS flow descriptions IE or in the Mapped EPS bearer contexts IE). The UE may include a new 5GSM cause value or an existing value e.g. #83 "semantic error in the QoS operation "or #84 "syntactical error in the QoS operation" • The UE may locally delete any EPS bearer context (information) that it receives in the NAS message and / or IE without sending any signaling to the network (e.g. to the SMF) • For the case when the 5GSM procedure is a PDU session modification procedure, if the UE detects that there is at least one EPS bearer context (information) that is present as part of the PDU session for LADN, the UE may behave as follows. The UE may reject the PDU session modification procedure by sending a PDU Session Modification Command Reject message. The UE may include a new 5GSM cause value or an existing value e.g. #83 "semantic error in the QoS operation" or #84 "syntactical error in the QoS operation" o Optionally, the UE behaves as described above if the EPS bearer context information which has been received is associated with the default QoS rule • Optionally, during the inter-system change (or after the inter-system change) from N1 mode to S1 mode, the UE may locally release (or deactivate) any PDU session for LADN. Optionally, if the LADN PDU session contains any EPS bearer context, then the UE should set the state of the mapped EPS bearer context to BEARER CONTEXT INACTIVE (in the EPS bearer context status IE). The UE may then include this IE in the Tracking Area Update Request message • Optionally, upon / after an inter-system change from N1 mode to S1 mode, the UE should suspend and maintain any PDU session for LADN and attempt to re-use it when the UE comes back to N1 mode (optionally if the UE is still inside the LADN service area) • Optionally the UE should attempt to transfer the session to S1 mode and leave it up to the core network in EPS (e.g. the MME) to either accept or reject the transfer. Optionally the UE may set the corresponding EPS bearer identity (which was received as part of the PDU session context in 5GS or in N1 mode) to indicate that it is inactive - where the UE may do so using the EPS bearer status IE. It should be noted that the actions that the UE may take can happen as part of an ongoing 5GSM procedure. As such, the above would apply for the case when the UE receives a PDU Session Establishment Accept message (received as part of a PDU session establishment procedure) or a PDU Session Modification Command message (received as part of the PDU session modification procedure). The actions above may occur during or after the ongoing procedure may have terminated. Alternatively, some of the actions may occur during (or after) an intersystem change from N1 mode (5GS) to S1 mode (EPS). The actions above may occur in any order or combination and may apply to any similar concepts (e.g. to any future local PDU session) that may be defined in other systems including 5G or 6G or 4G. Figure 1 shows a flowchart representing a first embodiment of the invention. At S101, a User Equipment, UE, receives a mapped Evolved Packet System, EPS, bearer context for a Protocol Data Unit, PDU, session for Local Area Data Network, LADN. At S102, the UE acts to locally delete the mapped EPS bearer context. The bearer context is received as part of a PDU session establishment or modification procedure. At S103, the UE, optionally, acts to locally delete the mapped EPS bearer context without informing a Session Maintenance Function of the first or second type of telecommunication 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

1. A method of interworking between a first and a second telecommunication type, wherein if a User Equipment, UE, receives any mapped Evolved Packet System, EPS, bearer context for a Protocol Data Unit, PDU, session for Local Area Data Network, LADN, the UE acts to locally delete the mapped EPS bearer context.

2. The method of claims 1 wherein the bearer context information is received by the UE in a Non-Access Stratum, NAS, message.

3. The method of claim 1 or 2 wherein the EPS bearer context is received as part of a PDU session establishment procedure, in a PDU Session Establishment Accept message, or as part of a PDU session modification procedure, in a PDU Session Modification Command message.

4. The method of any preceding clam wherein the UE acts to locally delete the mapped EPS bearer context without informing a Session Maintenance Function of the first or second type of telecommunication network.

5. The method of any preceding claim wherein the UE supports N1 mode and S1 mode.

6. The method of any preceding claim wherein the UE is operable in single registration modeor dual registration mode.

7. The method of any preceding claim wherein the UE receives an indication that N26 interface is supported.

8. Apparatus arranged to perform the method of any preceding claim.

Citation Information

Patent Citations

  • Methods for PDU session interworking across EPS and 5GS for NB-iot

    WO2021235889A1