Identification of PDU session or PDN connection with lbo

Abstract

The present disclosure is related to methods and network nodes for identifying a PDU session or PDN connection with LBO. A method at a first network node for identifying a PDU session or a PDN connection with LBO comprises: receiving, from a second network node, a first message for creating an SM context for a PDU session or a PDN connection; and determining whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO based on at least the first message.

Description

[0001] Applicant’s Ref. P109419WO2 IDENTIFICATION OF PDU SESSION OR PDN CONNECTION WITH LBO Technical Field The present disclosure is related to the field of telecommunication, and in particular, to methods and network nodes for identifying a Protocol Data Unit (PDU) session or a Packet Data Network (PDN) connection with Local Breakout (LBO). Background With the development of the electronic and telecommunications technologies, mobile devices, such as a mobile phone, a smart phone, a laptop, a tablet, a vehicle mounted device, becomes an important part of our daily lives. To support a numerous number of mobile devices and provide diverse services, a highly efficient and flexible telecommunication system is needed, such as an Evolved Packet System (EPS) or a fifth generation system (5GS), will be required. As one of the most important features provided by telecommunication systems, “roaming” extends the coverage of a home operator’s services, allowing its mobile users to use those services within another operator’s network, which may be in another country (international roaming) or in the same country (national roaming). While the 5GS also supports other use cases such as the Cellular Internet of Things (CIoT), the industrial Internet of Things (IoT), and vehicle use cases, the mobile broadband (MBB) is expected to be the first 5GS roaming use case. Today, the EPS supports a variety of MBB use cases such as internet access and operator-provided services like voice and messaging. In some cases, EPS deployments have already been upgraded for early support of 5G by non-standalone (NSA) New Radio (NR) in the Evolved Universal Terrestrial Radio Access Network (E- UTRAN) and also support NSA NR when roaming. The 5GS introduces support for NR standalone in next-generation RAN (NG-RAN) and new 5G Core (5GC). In the case of roaming, the 5GC supports following possible deployments scenarios for a PDU session: - "Local Break Out" (LBO) where the Session Management Function (SMF) and all User Plane Function(s) (UPF(s)) involved by the PDU session are under control of the Visited Public Land Mobile Network (VPLMN). - "Home Routed" (HR) where the PDU session is supported by an SMF function under control of the Home PLMN (HPLMN), by an SMF function under control of the VPLMN, by at least one UPF under control of the HPLMN, and by at least one UPF under control of the VPLMN. In this case the SMF in HPLMN selects the UPF(s) in the HPLMN and the SMF in VPLMN selects the UPF(s) in the VPLMN. Summary According to clause 4.3.2.2 of 3rdGeneration Partnership Project (3GPP) Technical Specification (TS) 23.502, v18.2.0, in the case of roaming, the Access and Mobility Management Function (AMF) determines if a PDU session is to be established in LBO or Home Routing and selects an appropriate SMF as described in clause 6.3.2 of 3GPP TS 23.501, v18.2.2 and clause 4.3.2.2.3 of 3GPP TS 23.502, v18.2.0. When an SMF is selected, for the SMF, Applicant’s Ref. P109419WO2 during the User Equipment (UE) requested PDU session establishment procedure, if the PDU session is for emergency services, ^ For an authenticated non-roaming UE, the SMF may register in the Unified Data Management (UDM) using Nudm_UECM_Registration for a given PDU session that is applicable for emergency services. As a result, the UDM shall store the applicable PDU session for emergency services. ^ For an unauthenticated UE or a roaming UE, the SMF shall not register in the UDM for a given PDU session. So, the SMF shall also determine if a PDU session is a roaming with LBO session or a non-roaming session, then it can decide whether to register in the UDM or not. Therefore, for an emergency service PDU session, ^ SMF shall determine roaming or non-roaming session while the AMF already knows that. It’s not efficient to let two nodes do the same judgement. ^ For emergency service, the call setup time is critical. Making the analysis of a session is roaming or not in both AMF and SMF may introduce the delays for emergency call setup time. ^ The AMF and SMF deployed in the same visited network should have aligned logic or configuration to determine a roaming or non-roaming session. Otherwise, the AMF and SMF may give opposite results. To solve or at least partially alleviate at least one of these problems, some embodiments of the present disclosure are provided below. According to a first aspect of the present disclosure, a method at a first network node for identifying a PDU session or a PDN connection with LBO is provided. The method comprises: receiving, from a second network node, a first message for creating a Session Management (SM) context for a PDU session or a PDN connection; and determining whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO based on at least the first message. In some embodiments, the step of determining whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO comprises at least one of: determining that the PDU session or the PDN connection is a PDU session or a PDN connection with LBO in response to the first message indicating that the PDU session or the PDN connection is a PDU session or a PDN connection with LBO; determining that the PDU session or the PDN connection is not a PDU session or a PDN connection with LBO in response to the first message indicating that the PDU session or the PDN connection is not a PDU session or a PDN connection with LBO; and determining that the PDU session or the PDN connection is not a PDU session or a PDN connection with LBO in response to the first message not indicating whether or not the PDU session or the PDN connection is a PDU session with LBO or a PDN connection with LBO. In some embodiments, the PDU session or the PDN connection is used for emergency services. In some embodiments, the PDU session or the PDN connection is associated with a roaming UE. In some embodiments, the method further comprises: preventing the PDU session or the PDN connection from being registered by the first network node in a UDM in response to determining that the PDU session or the PDN connection is a PDU session or a PDN connection with LBO. Applicant’s Ref. P109419WO2 In some embodiments, the first message is associated with at least one of: a PDU Session Establishment procedure; an EPS to 5GS handover procedure; an EPS to 5GS Mobility Registration procedure; an EPS / evolved Packet Data Gateway (ePDG) to 5GS handover procedure; and an E-UTRAN Initial Attach procedure. In some embodiments, the first network node is an SMF or an SMF + PDN Gateway Control plane (PGW-C). In some embodiments, the second network node is an AMF or a Serving Gateway Control plane (SGW-C). In some embodiments, the first message is an Nsmf_PDUSession_CreateSMContext Request message or a Create Session Request message. According to a second aspect of the present disclosure, a first network node for identifying a PDU session or a PDN connection with LBO is provided. The first network node comprises: a processor; a memory storing instructions which, when executed by the processor, cause the first network node to: receive, from a second network node, a first message for creating an SM context for a PDU session or a PDN connection; and determine whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO based on at least the first message. In some embodiments, the instructions, when executed by the processor, cause the first network node further to perform any of the methods of the first aspect. According to a third aspect of the present disclosure, a first network node for identifying a PDU session or a PDN connection with LBO is provided. The first network node comprises: a receiving module configured to receive, from a second network node, a first message for creating an SM context for a PDU session or a PDN connection; and a determining module configured to determine whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO based on at least the first message. In some embodiments, the first network node comprises one or more further modules, each of which may perform any of the steps of any of the methods of the first aspect. According to a fourth aspect of the present disclosure, a method at a second network node for facilitating a first network node in identifying a PDU session or a PDN connection with LBO is provided. The method comprises: transmitting, to a first network node, a first message for creating an SM context for a PDU session or a PDN connection, the first message indicating whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO. In some embodiments, the PDU session or the PDN connection is used for emergency services. In some embodiments, the PDU session or the PDN connection is associated with a roaming UE. In some embodiments, the first message is associated with at least one of: a PDU Session Establishment procedure; an EPS to 5GS handover procedure; an EPS to 5GS Mobility Registration procedure; an EPS / ePDG to 5GS handover procedure; and an E- UTRAN Initial Attach procedure. In some embodiments, the first network node is an SMF or an SMF + PGW-C. In some embodiments, the second network node is an AMF or an SGW-C. In some embodiments, the first message is an Nsmf_PDUSession_CreateSMContext Request message or a Create Session Request message. According to a fifth aspect of the present disclosure, a second network node for facilitating a first network node in identifying a PDU session or a PDN connection with LBO is provided. The second network node comprises: a processor; a memory storing instructions which, when executed by the processor, cause the second network node to: transmit, to a first network node, a first message for creating an SM context for a PDU session or a PDN connection, Applicant’s Ref. P109419WO2 the first message indicating whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO. In some embodiments, the instructions, when executed by the processor, cause the second network node further to perform any of the methods of the fourth aspect. According to a sixth aspect of the present disclosure, a second network node for facilitating a first network node in identifying a PDU session or a PDN connection with LBO is provided. The second network node comprises: a transmitting module configured to transmit, to a first network node, a first message for creating an SM context for a SPDU session or a PDN connection, the first message indicating whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO. In some embodiments, the second network node comprises one or more further modules, each of which may perform any of the steps of any of the methods of the fourth aspect. According to a seventh aspect of the present disclosure, a computer program comprising instructions is provided. The instructions, when executed by at least one processor, cause the at least one processor to carry out any of the methods of any of the first and fourth aspects. According to an eighth aspect of the present disclosure, a carrier containing the computer program of the seventh aspect is provided. In some embodiments, the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium. According to a ninth aspect of the present disclosure, a telecommunication system is provided. The telecommunication system comprises: a second network node comprising: a processor; a memory storing instructions which, when executed by the processor, cause the second network node to: transmit, to a first network node, a first message for creating an SM context for a PDU session or a PDN connection, the first message indicating whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO, the first network node comprising: a processor; a memory storing instructions which, when executed by the processor, cause the first network node to: receive, from the second network node, the first message for creating an SM context for a PDU session or a PDN connection; and determine whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO based on at least the first message. In some embodiments, the instructions stored in the memory of the first network node, when executed by the processor of the first network node, cause the first network node further to perform any of the methods of the first aspect. In some embodiments, the instructions stored in the memory of the second network node, when executed by the processor of the second network node, cause the second network node further to perform any of the methods of the fourth aspect. With some embodiments of the present disclosure, duplicated judgements for roaming and non-roaming session in SMF may be avoided, thereby making it more efficient. Further, misalignment of the roaming and non- roaming session between SMF and AMF may be avoided, thereby preventing any potential errors in subsequent operations from happening. Applicant’s Ref. P109419WO2 Brief Description of the Drawings The foregoing and other features of the present disclosure will become more fully apparent from the following description and appended claims, taken in conjunction with the accompanying drawings. Understanding that these drawings depict only several embodiments in accordance with the disclosure and therefore are not to be considered limiting of its scope, the disclosure will be described with additional specificity and detail through use of the accompanying drawings. Fig.1 is a diagram illustrating an exemplary telecommunication network in which identification of a PDU session or PDN connection with LBO may be applicable according to an embodiment of the present disclosure. Fig.2 is a diagram illustrating another exemplary telecommunication network in which identification of a PDU session or PDN connection with LBO may be applicable according to another embodiment of the present disclosure. Fig.3A and Fig.3B are diagrams illustrating an exemplary PDU session establishment procedure in which a PDU session with LBO is identified according to an embodiment of the present disclosure. Fig.4 is a diagram illustrating an exemplary EPS to 5GS handover procedure in which a PDU session with LBO is identified according to an embodiment of the present disclosure. Fig.5A and Fig.5B are diagrams illustrating an exemplary EPS to 5GS mobility registration procedure in which a PDU session with LBO is identified according to an embodiment of the present disclosure. Fig.6 is a diagram illustrating an exemplary EPC / ePDG to 5GS handover procedure in which a PDU session with LBO is identified according to an embodiment of the present disclosure. Fig.7A and Fig.7B are diagrams illustrating an exemplary PDN connection establishment procedure in which a PDU session with LBO is identified according to an embodiment of the present disclosure. Fig.8 is a flow chart illustrating an exemplary method at a first network node for identifying a PDU session or a PDN connection with LBO according to an embodiment of the present disclosure. Fig.9 is a flow chart illustrating an exemplary method at a second network node for facilitating a first network node in identifying a PDU session or a PDN connection with LBO according to an embodiment of the present disclosure. Fig.10 schematically shows an embodiment of an arrangement which may be used in one or more network nodes according to an embodiment of the present disclosure. Fig.11 is a block diagram of an exemplary first network node according to an embodiment of the present disclosure. Fig.12 is a block diagram of an exemplary second network node according to an embodiment of the present disclosure. Applicant’s Ref. P109419WO2 Detailed Description Hereinafter, the present disclosure is described with reference to embodiments shown in the attached drawings. However, it is to be understood that those descriptions are just provided for illustrative purpose, rather than limiting the present disclosure. Further, in the following, descriptions of known structures and techniques are omitted so as not to unnecessarily obscure the concept of the present disclosure. Those skilled in the art will appreciate that the term “exemplary” is used herein to mean “illustrative,” or “serving as an example,” and is not intended to imply that a particular embodiment is preferred over another or that a particular feature is essential. Likewise, the terms “first” and “second,” and similar terms, are used simply to distinguish one particular instance of an item or feature from another, and do not indicate a particular order or arrangement, unless the context clearly indicates otherwise. Further, the term “step,” as used herein, is meant to be synonymous with “operation” or “action.” Any description herein of a sequence of steps does not imply that these operations must be carried out in a particular order, or even that these operations are carried out in any order at all, unless the context or the details of the described operation clearly indicates otherwise. Conditional language used herein, such as "can," "might," "may," "e.g.," and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and / or states. Thus, such conditional language is not generally intended to imply that features, elements and / or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and / or states are included or are to be performed in any particular embodiment. Also, the term "or" is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term "or" means one, some, or all of the elements in the list. Further, the term "each," as used herein, in addition to having its ordinary meaning, can mean any subset of a set of elements to which the term "each" is applied. The term “based on” is to be read as “based at least in part on.” The term “one embodiment” and “an embodiment” are to be read as “at least one embodiment.” The term “another embodiment” is to be read as “at least one other embodiment.” Other definitions, explicit and implicit, may be included below. In addition, language such as the phrase "at least one of X, Y and Z," unless specifically stated otherwise, is to be understood with the context as used in general to convey that an item, term, etc. may be either X, Y, or Z, or a combination thereof. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limitation of example embodiments. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises”, “comprising”, “has”, “having”, “includes” and / or “including”, when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof. It will be also understood that the terms “connect(s),” “connecting”, “connected”, etc. when used herein, just mean that there is an electrical or communicative connection between two elements and they can be connected either directly or indirectly, unless explicitly stated to the contrary. Applicant’s Ref. P109419WO2 Of course, the present disclosure may be carried out in other specific ways than those set forth herein without departing from the scope and essential characteristics of the disclosure. One or more of the specific processes discussed below may be carried out in any electronic device comprising one or more appropriately configured processing circuits, which may in some embodiments be embodied in one or more application-specific integrated circuits (ASICs). In some embodiments, these processing circuits may comprise one or more microprocessors, microcontrollers, and / or digital signal processors programmed with appropriate software and / or firmware to carry out one or more of the operations described above, or variants thereof. In some embodiments, these processing circuits may comprise customized hardware to carry out one or more of the functions described above. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive. Although multiple embodiments of the present disclosure will be illustrated in the accompanying Drawings and described in the following Detailed Description, it should be understood that the disclosure is not limited to the disclosed embodiments, but instead is also capable of numerous rearrangements, modifications, and substitutions without departing from the present disclosure that as will be set forth and defined within the claims. Further, although the following description of some embodiments of the present disclosure is given in the context of 5G system (5GS), the present disclosure is not limited thereto. In fact, as long as identification of a PDU session or a PDN connection with LBO is involved, the inventive concept of the present disclosure may be applicable to any appropriate communication architecture, for example, to Global System for Mobile Communications (GSM) / General Packet Radio Service (GPRS), Enhanced Data Rates for GSM Evolution (EDGE), Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), Time Division - Synchronous CDMA (TD-SCDMA), CDMA2000, Worldwide Interoperability for Microwave Access (WiMAX), Wireless Fidelity (Wi-Fi), Long Term Evolution (LTE), Evolved Packet System (EPS), 5G New Radio (NR), etc. Therefore, one skilled in the arts could readily understand that the terms used herein may also refer to their equivalents in any other infrastructure. For example, the term “User Equipment” or “UE” used herein may refer to a mobile device, a mobile terminal, a mobile station, a user device, a user terminal, a wireless device, a wireless terminal, an Internet of Things (IoT) device, a vehicle, or any other equivalents. For another example, the term “network node” used herein may refer to a base station, a base transceiver station, an access point, a hot spot, a NodeB (NB), an evolved NodeB (eNB), a gNB, a network element, a network function, or any other equivalents. Further, following 3GPP documents are incorporated herein by reference in their entireties: [1] 3GPP TS 23.501 V18.2.2 (2023-07), Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 18); [2] 3GPP TS 29.502 V18.3.0 (2023-06), Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Session Management Services; Stage 3 (Release 18); [3] 3GPP TS 23.502 V18.2.0 (2023-06), Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 18); and Applicant’s Ref. P109419WO2 [4] 3GPP TS 23.401 V18.2.0 (2023-06), Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 18). Figure 1 Fig.1 is a block diagram illustrating an exemplary telecommunication network 10 in which identification of a PDU session or a PDN connection with LBO is applicable according to an embodiment of the present disclosure. Although the telecommunication network 10 is a network defined in the context of 5GS, the present disclosure is not limited thereto. As shown in Fig.1, the network 10 may comprise one or more UEs 100 and a (radio) access network ((R)AN) 105 comprising one or more RAN nodes, such as a base station, a Node B, an evolved NodeB (eNB), a gNB, or an Access Network (AN) node which provides the UEs 100 with access to other parts of the network 10. Further, the network 10 may comprise its 3GPP Core Network portion comprising (but not limited to) one or more UPFs 115, a Network Slice-specific and SNPN (Standalone Non-Public Network) Authentication and Authorization Function (NSSAAF) 120, an Authentication Server Function (AUSF) 125, an AMF 130, an SMF 135, a Service Communication Proxy (SCP) 140, a Network Slice Admission Control Function (NSACF) 145, a Network Slice Selection Function (NSSF) 150, a Network Exposure Function (NEF) 155, a Network Repository Function (NRF) 160, a Policy Control Function (PCF) 165, a UDM 170, an Application Function (AF) 175, and an Edge Application Server Discovery Function (EASDF) 180. As shown in Fig.1, these entities may communicate with each other via the service-based interfaces, such as, Namf, Nsmf, etc. and / or the reference points, such as, N1, N2, N3, N4, N6, N9, etc. However, the present disclosure is not limited thereto. In some other embodiments, the network 10 may comprise additional network functions, less network functions, or some variants of the existing network functions shown in Fig.1. For example, in a network with the 4G EPS architecture, the entities which perform these functions (e.g., Mobility Management Entity (MME)) may be different from those shown in Fig.1 (e.g., the AMF 130). For another example, in a network with a mixed 4G / 5G architecture (e.g., the network shown in Fig.2), some of the entities may be same as those shown in Fig.1, and others may be different. Further, the functions shown in Fig.1 are not essential to some embodiments of the present disclosure. In other words, some of them may be missing from some embodiments of the present disclosure. As shown in Fig.1, the UPFs 115 are communicatively connected to a Data Network (DN) 185 which may be, or in turn communicatively connected to, the Internet, such that the UE 100 may finally communicate its user plane data with other devices outside the network 10, for example, via the RAN 105 and the UPFs 115. Figure 2 Fig.2 is a diagram illustrating another exemplary telecommunication network 20 in which identification of a PDU session or PDN connection with LBO may be applicable according to another embodiment of the present disclosure. Fig.2 represents the non-roaming architecture for interworking between 5GC / NR and EPC / E-UTRAN. As shown in Fig.2, the network 20 may comprise different RANs for providing the UEs 100 (e.g., the UE 100-1 and the UE 100-2) with different Radio Access Technologies (RATs). For example, the network 20 may Applicant’s Ref. P109419WO2 comprise a E-UTRAN 205, which may provide the UE 100-1 with 4G or EUTRA access, while the network 20 may also comprise a NG-RAN 105, which may provide the UE 100-2 with 5G or NR access. Further, the core network portion of the network 20 may comprise one or more network nodes / elements / functions that enable the interworking between 5GC / NR and EPC / E-UTRAN. For example, the network 20 may comprise a UPF+PGW-U (PDN Gateway User plane) 115, an SMF+PGW-C (PDN gateway Control plane) 135, and a Home Subscriber Server (HSS)+UDM 170. Each of them may function as corresponding network nodes / elements / functions for 5GC / NR and EPC / E-UTRAN, respectively. For example, the SMF+PGW-C 135 may function as an SMF for the UE 100-2, the NG-RAN 105, and the AMF 130, while it may also function as a PGW-C for the UE 100-1, the E-UTRAN 205, the MME 230, and the SGW 235. Further, the network 20 may comprise RAT- specific network nodes / elements / functions, such as, the AMF 130 for 5GC / NR and the MME 230 and Serving Gateway (SGW) 235 for EPC / E-UTRAN. With these network nodes / elements / functions, the UEs 100 can be served by the network 20 irrespective of their RATs used. As shown in Fig.2, these entities may communicate with each other via the reference points, such as, S1-U, S1-MME, S5-C, S5-U, S6a, N2, N3, N11, N15, N8, N 10, etc. As mentioned above, according to clause 4.3.2.2 of 3GPP TS 23.502, v18.2.0, in the case of roaming, the AMF determines if a PDU session is to be established in LBO or Home Routing and selects an appropriate SMF as described in clause 6.3.2 of 3GPP TS 23.501, v18.2.2 and clause 4.3.2.2.3 of 3GPP TS 23.502, v18.2.0. When an SMF is selected, for the SMF, during the UE requested PDU session establishment procedure, if the PDU session is for emergency services, ^ For an authenticated non-roaming UE, the SMF may register in the UDM using Nudm_UECM_Registration for a given PDU session that is applicable for emergency services. As a result, the UDM shall store the applicable PDU session for emergency services. ^ For an unauthenticated UE or a roaming UE, the SMF shall not register in the UDM for a given PDU session. So, the SMF shall also determine if a PDU session is a roaming with LBO session or a non-roaming session, then it can decide whether to register in the UDM or not. Therefore, for an emergency service PDU session, ^ SMF shall determine roaming or non-roaming session while the AMF already knows that. It’s not efficient to let two nodes do the same judgement. ^ For emergency service, the call setup time is critical. Making the analysis of a session is roaming or not in both AMF and SMF may introduce the delays for emergency call setup time. ^ The AMF and SMF deployed in the same visited network should have aligned logic or configuration to determine a roaming or non-roaming session. Otherwise, the AMF and SMF may give opposite results. To solve or at least partially alleviate at least one of the problems, in some embodiments of the present disclosure, the AMF may indicate, to the SMF, whether a PDU session is roaming and / or non-roaming with local breakout during a PDU session establishment procedure and / or EPS / ePDG to 5GS mobility procedures (or any other applicable procedure). Applicant’s Ref. P109419WO2 In some embodiments, the SGW-C may indicate, to the SMF+PGW-C, whether a PDN connection is non- roaming or roaming with local breakout during PDN connection setup procedure or any other applicable procedure. In some embodiments, during a PDU session establishment procedure and / or EPS / ePDG to 5GS mobility procedures (or any other applicable procedures), the AMF may determine whether it is a non-roaming session or a roaming-with-LBO session. In some embodiments, the AMF may indicate so to the SMF when it is an LBO session. In some embodiments, during a PDN connection setup procedure, the SGW-C may determine whether it is a non-roaming session or a roaming-with-LBO session, and the SGW-C may indicate so to the SMF+PGW-C when it is an LBO session. In some embodiments, based on the indication received from AMF / SGW-C, for an LBO session, if the PDU session / PDN connection is for emergency service, the SMF shall not register in the UDM for a given PDU session / PDN connection. With some embodiments of the present disclosure, duplicated judgements for roaming and non-roaming session in SMF may be avoided, thereby making it more efficient. Further, misalignment of the roaming and non- roaming session between SMF and AMF may be avoided, thereby preventing any potential errors in subsequent operations from happening. Figures 3A and 3B In some embodiments, during a PDU session establishment procedure (e.g., as shown in Fig.3A and Fig. 3B), EPS to 5GS mobility procedures (e.g., as shown in Fig.4, Fig.5A, and Fig.5B), and ePDG to 5GS handover procedures (e.g., as shown in Fig.6), the AMF may determine if a PDU session is to be established in LBO or non- roaming. In some embodiments, the AMF may select the SMF as described in clause 5.16.4 of 3GPP TS 23.501, v18.2.2 and send Nsmf_PDUSession_CreateSMContext Request message to the SMF. In some embodiments, if it is a roaming-with-LBO UE, the AMF may provide a new indication to the SMF as below. Next, some exemplary procedures will be described in detail with reference to Fig.3A through Fig.7B. Fig.3A and Fig.3B are diagrams illustrating an exemplary PDU session establishment procedure in which a PDU session with LBO is identified according to an embodiment of the present disclosure. As shown in Fig.3A, the procedure may begin with step S301 where a NAS message may be transmitted from the UE 100 to the AMF 130 for requesting the AMF 130 to establish a PDU session for the UE 100. In some embodiments, the UE 100 may initiate the UE Requested PDU Session Establishment procedure by the transmission of the NAS message containing a PDU Session Establishment Request within the N1 Session Management (SM) container. At step S302, upon the reception of the NAS message, the AMF 130 may select an SMF (e.g., the SMF 135 shown in Fig.3A) as described in clause 6.3.2 of 3GPP TS 23.501, v18.2.2 and clause 4.3.2.2.3 of 3GPP TS 23.502, v18.2.0. At step S303, the AMF 130 may transmit to the SMF 135 either Nsmf_PDUSession_CreateSMContext Request message or Nsmf_PDUSession_UpdateSMContext Request message. For example, if the AMF 130 does not have an association with the SMF 135 for the PDU Session ID provided by the UE 100, the AMF 130 may invoke the Nsmf_PDUSession_CreateSMContext Request, but if the AMF 130 already has an association with the SMF 135 Applicant’s Ref. P109419WO2 for the PDU Session ID provided by the UE 100, the AMF 130 may invoke the Nsmf_PDUSession_UpdateSMContext Request. In some embodiments, the AMF 130 may provide the SMF 135 with an indicator “localBreakout=1”, for example, in the Nsmf_PDUSession_CreateSMContext Request message, such that the SMF 135 may be aware of that the PDU session to be created is a PDU session with LBO. In some embodiments, if the SMF 135 determines that the PDU session to be created is an emergency PDU session and AMF 130 indicates that it is local breakout session (e.g., as shown in step S303), the registering of the PDU session in the UDM 170 at step S316c may be skipped. Further, the rest steps of the procedure may be substantially similar to those shown and described in clause 4.3.2.2.1 of 3GPP TS 23.502, v18.2.0, and therefore a detailed description thereof is omitted. Figure 4 Fig.4 is a diagram illustrating an exemplary EPS to 5GS handover procedure in which a PDU session with LBO is identified according to an embodiment of the present disclosure. As shown in Fig.4, before the procedure is started, the UE 100 may already establish a PDN connection in 4G EPC at step S400. The procedure may begin with step S401 where the E-UTRAN 205 (e.g., the eNB that serves the UE 100) may decide to initiate a handover to the target RAN (e.g., the NG-RAN 105). At step S402, the E-UTRAN 205 may send a Handover Required message to the MME 230. At step S403, the MME 230 may send a Forward Relocation Request to the initial AMF 130-1. In some embodiments, the initial AMF 130-1 may convert the received EPS Mobility Management (MM) Context into the 5GS MM Context. This includes converting the EPS security context into a mapped 5G security context as described in 3GPP TS 33.501. At step S404, the initial AMF 130-1 may invoke the Nsmf_PDUSession_CreateSMContext service operation on the SMF identified by the SMF+PGW-C’s 135-3 address and indicate HO Preparation Indication. In some embodiments, the initial AMF 130-1 may provide the SMF+PGW-C 135-3 with an indicator “localBreakout=1”, for example, in the Nsmf_PDUSession_CreateSMContext Request message, such that the SMF+PGW-C 135-3 may be aware of that the PDU session to be created, which corresponds to the PDN connection to be handed over, is a PDU session with LBO. In some embodiments, if the SMF+PGW-C 135-3 determines that the PDU session to be created is an emergency PDU session and the initial AMF 130-1 indicates that it is local breakout session (e.g., as shown in step S404), the registering of the PDU session in the UDM at a subsequent step may be skipped. Further, the rest steps of the procedure may be substantially similar to those shown and described in clause 4.11.1.2.2 of 3GPP TS 23.502, v18.2.0, and therefore a detailed description thereof is omitted. Figures 5A and 5B Fig.5A and Fig.5B are diagrams illustrating an exemplary EPS to 5GS mobility registration procedure in which a PDU session with LBO is identified according to an embodiment of the present disclosure. Applicant’s Ref. P109419WO2 As shown in Fig.5A, the procedure may begin with step S501 where the registration procedure may be triggered, e.g. the UE 100 moves into NG-RAN’s 105 coverage. At step S502, the UE 100 may send a Registration Request with registration type set to "Mobility Registration Update". At steps S503 and S504, steps 2 and 3 of clause 4.2.2.2.2 of 3GPP TS 23.502, v18.2.0 may be performed, and therefore a detailed description thereof is omitted. At optional steps S505a and S505b, the AMF 130-2 may retrieve UE context for the UE 100 from the MME 230. Optional steps S506a and S506b are only performed when the AMF 130-2 is different from the old AMF 130- 1 and the old AMF 130-1 is in the same PLMN as the AMF 130-2. At optional steps S506a and S506b, the AMF 130-2 may retrieve UE context for the UE 100 from the old AMF 130-1. At step S507, if the AMF 130-2 determines to initiate the authentication procedure to the UE 100 at step S506b (e.g. the AMF 130-2 cannot obtain the UE MM context from the old AMF 130-1 or other reasons), steps 8 and 9 of clause 4.2.2.2.2 of 3GPP TS 23.502 v18.2.0 may be optionally performed. At step S508, if step S505b is performed and the AMF 130-2 accepts to serve the UE 100, the AMF 130-2 may send Context Acknowledge (Serving GW change indication) to the MME 230 according to TS 23.401, v18.2.0. At step S509, steps 11 and 12 of clause 4.2.2.2.2 of 3GPP TS 23.502, v18.2.0 may be optionally performed, and therefore a detailed description thereof is omitted. At step S511, steps 13 through 14e of clause 4.2.2.2.2 of 3GPP TS 23.502, v18.2.0 may be performed, and therefore a detailed description thereof is omitted. At step S514, step 16 of clause 4.2.2.2.2 of 3GPP TS 23.502, v18.2.0 (AM Policy Association Establishment) may be optionally performed, and therefore a detailed description thereof is omitted. At step S514a, in non-roaming and LBO cases and idle state mobility, the AMF 130-2 may invoke Nsmf_PDUSession_CreateSMContext Request service operation of the PGW-C+SMF 135-3 and indicate all the PDU Session(s) to be re-activated as received in the Registration request message along with List Of PDU Sessions To Be Activated. In some embodiments, the AMF 130-2 may provide the PGW-C+SMF 135-3 with an indicator “localBreakout=1”, for example, in the Nsmf_PDUSession_CreateSMContext Request message, such that the PGW- C+SMF 135-3 may be aware of that the PDU session to be created is a PDU session with LBO. In some embodiments, if the PGW-C+SMF 135-3 determines that the PDU session to be created is an emergency PDU session and the AMF 130-2 indicates that it is local breakout session (e.g., as shown in step S514a), the registering of the PDU session in the UDM at a subsequent step may be skipped. Further, the rest steps of the procedure may be substantially similar to those shown and described in clause 4.11.1.3.3 of 3GPP TS 23.502, v18.2.0, and therefore a detailed description thereof is omitted. Figure 6 Fig.6 is a diagram illustrating an exemplary EPC / ePDG to 5GS handover procedure in which a PDU session with LBO is identified according to an embodiment of the present disclosure. Applicant’s Ref. P109419WO2 As shown in Fig.6, the initial status before the procedure begins is: one or more PDN connections have been established between the UE 100 and the EPC / ePDG 605 via untrusted non-3GPP access. The procedure may begin with step S601 where for the UE 100 to move its PDU session(s) from EPC / ePDG to 5GC / 3GPP access, the UE 100's behavior may be as follows: - If the UE 100 is operating in single-registration mode and the UE 100 is attached to EPC / E-UTRAN: - the UE 100 may behave as specified in clause 4.11.1 or clause 4.11.2 of 3GPP TS 23.502, v18.2.0 and get registered to 5GC via 3GPP access. - otherwise i.e. either the UE 100 is operating in single registration mode and is not attached to EPC / E- UTRAN, or the UE 100 is operating in dual registration mode; and - if the UE 100 is already registered in 5GS via 3GPP access, the UE 100 may skip to step S602. - otherwise (i.e. the UE 100 is not registered in 5GS via 3GPP access), the UE 100 may perform Registration procedure of type initial registration in 5GS via 3GPP access as described in clause 4.2.2.2 of 3GPP TS 23.502, v18.2.0. At step S602, the UE 100 may initiate a UE requested PDU Session Establishment via 3GPP Access according to clause 4.3.2.2 of 3GPP TS 23.502, v18.2.0 and include the "Existing PDU Session" indication or "Existing Emergency PDU Session" and the PDU Session ID. In some embodiments, a procedure similar to that shown in Fig.3A and Fig.3B may be performed at step S602. In such a case, the AMF 130 may provide the PGW+SMF / UPF 135 / 115 (or more specifically, the PGW-C+SMF 135) with an indicator “localBreakout=1”, for example, in the Nsmf_PDUSession_CreateSMContext Request message, such that the PGW-C+SMF 135 may be aware of that the PDU session to be created is a PDU session with LBO. In some embodiments, if the PGW-C+SMF 135 determines that the PDU session to be created is an emergency PDU session and the AMF 130 indicates that it is local breakout session (e.g., as shown in step S303), the registering of the PDU session in the UDM (e.g., the UDM 170 shown in Fig.3A and Fig.3B) at a subsequent step (e.g., the step S316c) may be skipped. Further, the rest steps of the procedure may be substantially similar to those shown and described in clause 4.11.4.1 of 3GPP TS 23.502, v18.2.0, and therefore a detailed description thereof is omitted. Figures 7A and 7B Fig.7A and Fig.7B are diagrams illustrating an exemplary PDN connection establishment procedure in which a PDU session with LBO is identified according to an embodiment of the present disclosure. As shown in Fig.7A, the procedure may begin with step S701 where the UE 100 may initiate the UE Requested PDN procedure towards the MME 230 by the transmission of a PDN Connectivity Request message. At step S702, upon the reception of the PDN connectivity Request message, the MME 230 may send a Create Session Request message to the SGW-C 235-C. At step S703, the SGW-C 235-C may send a Create Session Request message to the SMF+PGW-C 135. In some embodiments, the SGW-C 235-C may provide the SMF+PGW-C 135 with an indicator “localBreakout=1”, for example, in the Create Session Request message, such that the SMF+PGW-C 135 may be aware of that the PDN connection to be created is a PDN connection with LBO. Applicant’s Ref. P109419WO2 In some embodiments, if the SMF+PGW-C 135 determines that the PDN connection to be created is an emergency PDN connection and SGW-C 235-C indicates that it is local breakout session (e.g., as shown in step S703), the registering of the PDN connection in the UDM 170 at step S725 may be skipped. Further, the rest steps of the procedure may be substantially similar to those shown and described in 3GPP TS 23.502, v18.2.0 and other 3GPP documents, and therefore a detailed description thereof is omitted. In some embodiments, a new attribute “localBreakout” in SmContextCreateData may be introduced and used as described above. For example, the clause 6.1.6.2.2 of 3GPP TS 29.502, v18.3.0 may be modified as follows: Attribute name Data P Cardinality Description type supi Supi C 0..1 This IE shall be present, except if the UE is emergency registered and UICCless. When present, it shall contain the subscriber permanent identify. unauthenticatedSupi boolean C 0..1 This IE shall be present if the SUPI is present in the message but is not authenticated and is for an emergency registered UE. When present, it shall be set as follows: - true: unauthenticated SUPI; - false (default): authenticated SUPI. ...... localBreakout boolean C 0..1 This IE shall be present if the user is inbound roamer during a PDU session establishment procedure, a PDN connection establishment procedure, and EPS / ePDG to 5GS mobility procedures, When present, it shall be set as follows - True: inbound roaming user with local breakout - False: non-roaming user With the embodiments described above, duplicated judgements for roaming and non-roaming session in SMF may be avoided, thereby making it more efficient. Further, misalignment of the roaming and non-roaming session between SMF and AMF may be avoided, thereby preventing any potential errors in subsequent operations from happening. Figure 8 Fig.8 is a flow chart of an exemplary method 800 at a first network node for identifying a PDU session or a PDN connection with LBO according to an embodiment of the present disclosure. The method 800 may be performed by an SMF or SMF+PGW-C (e.g., the SMF 135, the SMF+PGW-C 135-3, or the SMF+PGW-C 135). The method 800 may comprise steps S810 and S820. However, the present disclosure is not limited thereto. In some other embodiments, the method 800 may comprise more steps, less steps, different steps, or any combination thereof. Further the steps of the method 800 may be performed in a different order than that described herein. Further, in some embodiments, a step in the method 800 may be split into multiple sub-steps and performed by different entities, and / or multiple steps in the method 800 may be combined into a single step. The method 800 may begin at step S810 where the first network node may receive, from a second network node, a first message for creating an SM context for a PDU session or a PDN connection. In some embodiments, the step S810 may be carried out by receiving a Nsmf_PDUSession_CreateSMContext Request message as illustrated Applicant’s Ref. P109419WO2 at step S303 of Fig.3A, step S404 of Fig.4, step S514a of Fig.5A, or step S602 of Fig.6, or by receiving a Create Session Request message at step S703 of Fig.7A. At step S820, the first network node may determine whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO based on at least the first message. In some embodiments, the step S820 may be carried out by checking whether or not an IE or field (e.g., the “localBreakout” IE described above) is present in the message received at step S810, and then checking its value if present. In some embodiments, the step of determining whether or not the PDU session or the PDN connection may be a PDU session or a PDN connection with LBO comprises at least one of: determining that the PDU session or the PDN connection is a PDU session or a PDN connection with LBO in response to the first message indicating that the PDU session or the PDN connection is a PDU session or a PDN connection with LBO; determining that the PDU session or the PDN connection is not a PDU session or a PDN connection with LBO in response to the first message indicating that the PDU session or the PDN connection is not a PDU session or a PDN connection with LBO; and determining that the PDU session or the PDN connection is not a PDU session or a PDN connection with LBO in response to the first message not indicating whether or not the PDU session or the PDN connection is a PDU session with LBO or a PDN connection with LBO. In some embodiments, the PDU session or the PDN connection may be used for emergency services. In some embodiments, the PDU session or the PDN connection may be associated with a roaming UE. In some embodiments, the method 800 may further comprise: preventing the PDU session or the PDN connection from being registered by the first network node in a UDM in response to determining that the PDU session or the PDN connection is a PDU session or a PDN connection with LBO. In some embodiments, the first message may be associated with at least one of: a PDU Session Establishment procedure; an EPS to 5GS handover procedure; an EPS to 5GS Mobility Registration procedure; an EPS / ePDG to 5GS handover procedure; and an E-UTRAN Initial Attach procedure. In some embodiments, the first network node may be an SMF or an SMF + PGW-C. In some embodiments, the second network node may be an AMF or an SGW-C. In some embodiments, the first message may be an Nsmf_PDUSession_CreateSMContext Request message or a Create Session Request message. Figure 9 Fig.9 is a flow chart of an exemplary method 900 at a second network node for facilitating a first network node in identifying a PDU session or a PDN connection with LBO according to an embodiment of the present disclosure. The method 900 may be performed by an AMF or SGW-C (e.g., the AMF 130, the initial AMF 130-1, the AMF 130-2, or the SGW-C 235-C). The method 900 may comprise a step S910. However, the present disclosure is not limited thereto. In some other embodiments, the method 900 may comprise more steps, different steps, or any combination thereof. Further the steps of the method 900 may be performed in a different order than that described herein. Further, in some embodiments, a step in the method 900 may be split into multiple sub-steps and performed by different entities, and / or multiple steps in the method 900 may be combined into a single step. The method 900 may begin at step S910 where the second network node may transmit, to the first network node, a first message for creating an SM context for a PDU session or a PDN connection. In some embodiments, the Applicant’s Ref. P109419WO2 first message may indicate whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO. In some embodiments, the step S910 may be carried out by transmitting a Nsmf_PDUSession_CreateSMContext Request message as illustrated at step S303 of Fig.3A, step S404 of Fig.4, step S514a of Fig.5A, or step S602 of Fig.6, or by transmitting a Create Session Request message at step S703 of Fig.7A. In some embodiments, the PDU session or the PDN connection may be used for emergency services. In some embodiments, the PDU session or the PDN connection may be associated with a roaming UE. In some embodiments, the first message may be associated with at least one of: a PDU Session Establishment procedure; an EPS to 5GS handover procedure; an EPS to 5GS Mobility Registration procedure; an EPS / ePDG to 5GS handover procedure; and an E-UTRAN Initial Attach procedure. In some embodiments, the first network node may be an SMF or an SMF + PGW-C. In some embodiments, the second network node may be an AMF or an SGW-C. In some embodiments, the first message may be an Nsmf_PDUSession_CreateSMContext Request message or a Create Session Request message. Figure 10 Fig.10 schematically shows an embodiment of an arrangement which may be used in one or more network nodes (e.g., AMF, SMF, SGW-C, SMF+PGW-C) according to an embodiment of the present disclosure. Comprised in the arrangement 1000 are a processing unit 1006, e.g., with a Digital Signal Processor (DSP) or a Central Processing Unit (CPU). The processing unit 1006 may be a single unit or a plurality of units to perform different actions of procedures described herein. The arrangement 1000 may also comprise an input unit 1002 for receiving signals from other entities, and an output unit 1004 for providing signal(s) to other entities. The input unit 1002 and the output unit 1004 may be arranged as an integrated entity or as separate entities. Furthermore, the arrangement 1000 may comprise at least one computer program product 1008 in the form of a non-volatile or volatile memory, e.g., an Electrically Erasable Programmable Read-Only Memory (EEPROM), a flash memory and / or a hard drive. The computer program product 1008 comprises a computer program 1010, which comprises code / computer readable instructions, which when executed by the processing unit 1006 in the arrangement 1000 causes the arrangement 1000 and / or the network node(s) in which it is comprised to perform the actions, e.g., of the procedure described earlier in conjunction with Fig.3A through Fig.7B or any other variant. The computer program 1010 may be configured as a computer program code structured in computer program modules 1010A and 1010B. Hence, in an exemplifying embodiment when the arrangement 1000 is used in a first network node for identifying a PDU session or a PDN connection with LBO, the code in the computer program of the arrangement 1000 includes: a module 1010A configured to receive, from a second network node, a first message for creating an SM context for a PDU session or a PDN connection; and a module 1010B configured to determine whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO based on at least the first message. Additionally or alternatively, the computer program 1010 may be configured as a computer program code structured in a computer program module 1010C. Hence, in an exemplifying embodiment when the arrangement 1000 is used in a second network node for facilitating a first network node in identifying a PDU session or a PDN Applicant’s Ref. P109419WO2 connection with LBO, the code in the computer program of the arrangement 1000 includes: a module 1010C configured to transmit, to a first network node, a first message for creating an SM context for a PDU session or a PDN connection, the first message indicating whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO. The computer program modules could essentially perform the actions of the flow illustrated in Fig.3A through Fig.7B, to emulate the network node(s). In other words, when the different computer program modules are executed in the processing unit 2306, they may correspond to different modules in the network node(s). Although the code means in the embodiments disclosed above in conjunction with Fig.10 are implemented as computer program modules which when executed in the processing unit causes the arrangement to perform the actions described above in conjunction with the figures mentioned above, at least one of the code means may in alternative embodiments be implemented at least partly as hardware circuits. The processor may be a single CPU (Central processing unit), but could also comprise two or more processing units. For example, the processor may include general purpose microprocessors; instruction set processors and / or related chips sets and / or special purpose microprocessors such as Application Specific Integrated Circuit (ASICs). The processor may also comprise board memory for caching purposes. The computer program may be carried by a computer program product connected to the processor. The computer program product may comprise a computer readable medium on which the computer program is stored. For example, the computer program product may be a flash memory, a Random-access memory (RAM), a Read-Only Memory (ROM), or an EEPROM, and the computer program modules described above could in alternative embodiments be distributed on different computer program products in the form of memories within the network node(s). Figure 11 Correspondingly to the method 800 as described above, an exemplary first network node for identifying a PDU session or a PDN connection with LBO is provided. Fig.11 is a block diagram of a first network node 1100 according to an embodiment of the present disclosure. The first network node 1100 may be, e.g., the AMF 130, the initial AMF 130-1, the AMF 130-2, or the SGW-C 235-C in some embodiments. The first network node 1100 may be configured to perform the method 800 as described above in connection with Fig.8. As shown in Fig.11, the first network node 1100 may comprise a receiving module 1110 configured to receive, from a second network node, a first message for creating an SM context for a PDU session or a PDN connection; and a determining module 1120 configured to determine whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO based on at least the first message. The above modules 1110 and / or 1120 may be implemented as a pure hardware solution or as a combination of software and hardware, e.g., by one or more of: a processor or a micro-processor and adequate software and memory for storing of the software, a Programmable Logic Device (PLD) or other electronic component(s) or processing circuitry configured to perform the actions described above, and illustrated, e.g., in Fig.8. Further, the first network node 1100 may comprise one or more further modules, each of which may perform any of the steps of the method 800 described with reference to Fig.8. Applicant’s Ref. P109419WO2 Figure 12 Correspondingly to the method 900 as described above, an exemplary second network node for facilitating a first network node in identifying a PDU session or a PDN connection with LBO is provided. Fig.12 is a block diagram of a second network node 1200 according to an embodiment of the present disclosure. The second network node 1200 may be, e.g., the SMF 135, the SMF+PGW-C 135-3, or the SMF+PGW-C 135 in some embodiments. The second network node 1200 may be configured to perform the method 900 as described above in connection with Fig.9. As shown in Fig.12, the second network node 1200 may comprise a transmitting module 1210 configured to transmit, to a first network node, a first message for creating an SM context for a PDU session or a PDN connection, the first message indicating whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO. The above module 1210 may be implemented as a pure hardware solution or as a combination of software and hardware, e.g., by one or more of: a processor or a micro-processor and adequate software and memory for storing of the software, a PLD or other electronic component(s) or processing circuitry configured to perform the actions described above, and illustrated, e.g., in Fig.9. Further, the second network node 1200 may comprise one or more further modules, each of which may perform any of the steps of the method 900 described with reference to Fig. 9. The present disclosure is described above with reference to the embodiments thereof. However, those embodiments are provided just for illustrative purpose, rather than limiting the present disclosure. The scope of the disclosure is defined by the attached claims as well as equivalents thereof. Those skilled in the art can make various alternations and modifications without departing from the scope of the disclosure, which all fall into the scope of the disclosure. Some embodiments that are described above may be summarized in the following manner: 1. A method (800) at a first network node (135, 135-3) for identifying a Protocol Data Unit (PDU) session or a Packet Data Network (PDN) connection with Local Breakout (LBO), the method (800) comprising: receiving (S303, S404, S514a, S602, S703, S810), from a second network node (130, 130-1, 130-2, 235-C), a first message for creating a Session Management (SM) context for a PDU session or a PDN connection; and determining (S820) whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO based on at least the first message. 2. The method (800) of embodiment 1, wherein the step of determining (S820) whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO comprises at least one of: determining that the PDU session or the PDN connection is a PDU session or a PDN connection with LBO in response to the first message indicating that the PDU session or the PDN connection is a PDU session or a PDN connection with LBO; Applicant’s Ref. P109419WO2 determining that the PDU session or the PDN connection is not a PDU session or a PDN connection with LBO in response to the first message indicating that the PDU session or the PDN connection is not a PDU session or a PDN connection with LBO; and determining that the PDU session or the PDN connection is not a PDU session or a PDN connection with LBO in response to the first message not indicating whether or not the PDU session or the PDN connection is a PDU session with LBO or a PDN connection with LBO. 3. The method (800) of embodiment 1 or 2, wherein the PDU session or the PDN connection is used for emergency services. 4. The method (800) of any of embodiment 1 to 3, wherein the PDU session or the PDN connection is associated with a roaming User Equipment (UE) (100). 5. The method (800) of any of embodiment 1 to 4, further comprising: preventing (S316c, S725) the PDU session or the PDN connection from being registered by the first network node (135, 135-3) in a Unified Data Management (UDM) (170) in response to determining that the PDU session or the PDN connection is a PDU session or a PDN connection with LBO. 6. The method (800) of any of embodiments 1 to 5, wherein the first message is associated with at least one of: - a PDU Session Establishment procedure; - an Evolved Packet System (EPS) to 5thGeneration System (5GS) handover procedure; - an EPS to 5GS Mobility Registration procedure; - an EPS / evolved Packet Data Gateway (ePDG) to 5GS handover procedure; and - an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) Initial Attach procedure. 7. The method (800) of any of embodiment 1 to 6, wherein the first network node (135, 135-3) is a Session Management Function (SMF) or an SMF + PDN Gateway Control plane (PGW-C), wherein the second network node (130, 130-1, 130-2, 235-C) is an Access and Mobility Management Function (AMF) or a Serving Gateway Control plane (SGW-C). 8. The method (800) of embodiment 7, wherein the first message is an Nsmf_PDUSession_CreateSMContext Request message or a Create Session Request message. 9. A first network node (135, 135-3, 1000, 1100) for identifying a PDU session or a PDN connection with LBO, the first network node (135, 135-3, 1000, 1100) comprising: a processor (1006); Applicant’s Ref. P109419WO2 a memory (1008) storing instructions which, when executed by the processor (1006), cause the first network node (135, 135-3, 1000, 1100) to: receive, from a second network node (130, 130-1, 130-2, 235-C), a first message for creating an SM context for a PDU session or a PDN connection; and determine whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO based on at least the first message. 10. The first network node (135, 135-3, 1000, 1100) of embodiment 9, wherein the instructions, when executed by the processor (1006), cause the first network node (135, 135-3, 1000, 1100) further to perform the method (800) of any of embodiment 2 to 8. 11. A method (900) at a second network node (130, 130-1, 130-2, 235-C) for facilitating a first network node (135, 135-3) in identifying a PDU session or a PDN connection with LBO, the method (900) comprising: transmitting (S303, S404, S514a, S602, S703, S910), to a first network node (135, 135-3), a first message for creating an SM context for a PDU session or a PDN connection, the first message indicating whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO. 12. The method (900) of embodiment 11, wherein the PDU session or the PDN connection is used for emergency services. 13. The method (900) of embodiment 11 or 12, wherein the PDU session or the PDN connection is associated with a roaming UE (100). 14. The method (900) of any of embodiment 11 to 13, wherein the first message is associated with at least one of: - a PDU Session Establishment procedure; - an EPS to 5GS handover procedure; - an EPS to 5GS Mobility Registration procedure; - an EPS / ePDG to 5GS handover procedure; and - an E-UTRAN Initial Attach procedure. 15. The method (900) of any of embodiment 11 to 14, wherein the first network node (135, 135-3) is an SMF or an SMF + PGW-C, wherein the second network node (130, 130-1, 130-2, 235-C) is an AMF or an SGW-C. 16. The method (900) of embodiment 15, wherein the first message is an Nsmf_PDUSession_CreateSMContext Request message or a Create Session Request message. Applicant’s Ref. P109419WO2 17. A second network node (130, 130-1, 130-2, 235-C, 1000, 1200) for facilitating a first network node (135, 135-3) in identifying a PDU session or a PDN connection with LBO, the second network node (130, 130-1, 130-2, 235-C, 1000, 1200) comprising: a processor (1006); a memory (1008) storing instructions which, when executed by the processor (1006), cause the second network node (130, 130-1, 130-2, 235-C, 1000, 1200) to: transmit, to a first network node (135, 135-3), a first message for creating an SM context for a PDU session or a PDN connection, the first message indicating whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO. 18. The second network node (130, 130-1, 130-2, 235-C, 1000, 1200) of embodiment 17, wherein the instructions, when executed by the processor (1006), cause the second network node (130, 130-1, 130-2, 235-C, 1000, 1200) further to perform the method (900) of any of embodiment 12 to 16. 19. A computer program (1010) comprising instructions which, when executed by at least one processor (1006), cause the at least one processor (1006) to carry out the method (800, 900) of any of embodiment 1 to 8 and 11 to 16. 20. A carrier (1008) containing the computer program (1010) of embodiment 19, wherein the carrier (1008) is one of an electronic signal, optical signal, radio signal, or computer readable storage medium. 21. A telecommunication system (10, 20), comprising: a second network node (130, 130-1, 130-2, 235-C) comprising: a processor; a memory storing instructions which, when executed by the processor, cause the second network node (130, 130-1, 130-2, 235-C) to: transmit, to a first network node (135, 135-3), a first message for creating an SM context for a PDU session or a PDN connection, the first message indicating whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO, the first network node (135, 135-3) comprising: a processor; a memory storing instructions which, when executed by the processor, cause the first network node (135, 135-3) to: receive, from the second network node (130, 130-1, 130-2, 235-C), the first message for creating an SM context for a PDU session or a PDN connection; and determine whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO based on at least the first message. Applicant’s Ref. P109419WO2 22. The telecommunication system (10, 20) of embodiment 20, wherein the instructions stored in the memory of the first network node (135, 135-3), when executed by the processor of the first network node (135, 135-3), cause the first network node (135, 135-3) further to perform the method (800) of any of embodiment 2 to 8. 23. The telecommunication system (10, 20) of embodiment 20 or 21, wherein the instructions stored in the memory of the second network node (130, 130-1, 130-2, 235-C), when executed by the processor of the second network node (130, 130-1, 130-2, 235-C), cause the second network node (130, 130-1, 130-2, 235-C) further to perform the method (900) of any of embodiment 12 to 16.

[0002] Applicant’s Ref. P109419WO2 APPENDIX A 3GPP TSG-CT WG4 Meeting #117 C4-233abc Göteborg, Sweden, 21st– 25thAugust 2023 CR-Form-v12.2 CHANGE REQUEST 29.502 CR xxxx rev - Current version: 18.3.0 For HELP on using this form: comprehensive instructions can be found at http: / / www.3gpp.org / Change-Requests. Proposed change affects: UICC apps ME Radio Access Network Core Network X Title: Non-roaming and local breakout PDU session identification Source to WG: Ericsson Source to TSG: CT4 Work item code: SBIProtoc18 Date: 2023-06-19 Category: B Release: Rel-18 Use one of the following categories: Use one of the following releases: F (correction) Rel-8 (Release 8) A (mirror corresponding to a change in an earlier Rel-9 (Release 9) Rel-10 (Release 10) Rel-11 (Release 11) release) … B (addition of feature), Rel-16 (Release 16) C (functional modification of feature) Rel-17 (Release 17) D (editorial modification) Rel-18 (Release 18) Detailed explanations of the above categories can Rel-19 (Release 19) be found in 3GPP TR 21.900. Reason for change: According to TS 23.5024.3.2.2, if PDU Session is for emergency services, SMF shall determine if a PDU session is a roaming with LBO session or a non-roaming session. For roaming UE, the SMF shall not register in the UDM for a given PDU Session. Problem: For an emergency service PDU session, • SMF shall determine roaming or non-roaming session while the AMF already knows that. It’s not efficient to let two nodes do the same judgement. • For Emergency service, the call setup time is critical. Making the analyze of a session is roaming or not in both AMF and SMF may introduce the delays for emergency call setup time. • The AMF and SMF deployed in the same visited network should have aligned logic or configuration to determine a roaming or non-roaming session. Otherwise, the AMF and SMF may give a opposite result. To solve the problmes, the solution is proposed as: • During a PDU session establishment procedure and EPS / ePDG to 5GS Applicant’s Ref. P109419WO2 mobility procedures, the AMF determines whether it’s non-roaming session or roaming with LBO session. The AMF indicates the SMF when it’s an LBO session. • Based on the indication received from AMF, for an LBO session, if the PDU session if for emergency service, the SMF shall not register in the UDM for a given PDU Session. Summary of change: The AMF indicates SMF roaming and non-roaming with a new IE in sends Nsmf_PDUSession_CreateSMContext during a PDU session establishment procedure and EPS / ePDG to 5GS mobility procedures. Consequences if not Without this solution, the SMF needs to do a judagement of local breakout and non- approved: roaming which is no efficent and will prolong the call setup time for emergency call. Clauses affected: 6.1.6.2.2, A.2 Y N Other specs X Other core specifications TS / TR ... CR ... affected: X Test specifications TS / TR ... CR ... (show related CRs) X O&M Specifications TS / TR ... CR ... Other comments: This CR's revision history: * * * First Change * * * * 6.1.6.2.2 Type: SmContextCreateData Table 6.1.6.2.7-1: Definition of type SmContextRetrieveData Table 6.1.6.2.2-1: Definition of type SmContextCreateData Attribute name Data type P Cardi Description Applica nality bility supi Supi C 0..1 This IE shall be present, except if the UE is emergency registered and UICCless. When present, it shall contain the subscriber permanent identify. unauthenticatedSupi boolean C 0..1 This IE shall be present if the SUPI is present in the message but is not authenticated and is for an emergency registered UE. When present, it shall be set as follows: - true: unauthenticated SUPI; - false (default): authenticated SUPI. pei Pei C 0..1 This IE shall be present if the UE is emergency registered and it is either UIClless or the SUPI is not authenticated. For all other cases, this IE shall be present if it is available. When present, it shall contain the permanent Applicant’s Ref. P109419WO2 equipment identifier. gpsi Gpsi C 0..1 This IE shall be present if it is available. When present, it shall contain the user's GPSI. pduSessionId PduSessionId C 0..1 This IE shall be present, except during an EPS to 5GS Idle mode mobility or handover using the N26 interface. When present, it shall contain the PDU Session ID. dnn Dnn C 0..1 This IE shall be present, except during an EPS to 5GS Idle mode mobility or handover using the N26 interface. When present, it shall contain the requested DNN; the DNN shall be the full DNN (i.e. with both the Network Identifier and Operator Identifier) for a HR PDU session, and it should be the full DNN in LBO and non-roaming scenarios. If the Operator Identifier is absent, the serving core network operator shall be assumed. selectedDnn Dnn C 0..1 This IE shall be present, if another DNN other than the UE requested DNN is selected for this PDU session. When present, it shall contain the selected DNN. The DNN shall be the full DNN (i.e. with both the Network Identifier and Operator Identifier) for a HR PDU session, and it should be the full DNN in LBO and non-roaming scenarios. If the Operator Identifier is absent, the serving core network operator shall be assumed. sNssai Snssai C 0..1 This IE shall be present during the PDU session establishment procedure. In this case, it shall contain the requested S-NSSAI for the serving PLMN. This corresponds to an S-NSSAI from the allowed NSSAI. This IE shall also be present during an EPS to 5GS idle mode mobility or handover with I-SMF / V-SMF involved using the N26 interface. In this case, it shall contain the S-NSSAI configured in the AMF for EPS interworking. hplmnSnssai Snssai C 0..1 This IE shall be present for a roaming PDU session, except during an EPS to 5GS idle mode mobility or handover using the N26 interface. When present, it shall contain the requested S- NSSAI for the HPLMN. This corresponds to an S- NSSAI from the Mapping Of Allowed NSSAI corresponding to the SNSSAI value included in the sNssai IE. servingNfId NfInstanceId M 1 This IE shall contain the identifier of the serving NF (e.g. serving AMF). guami Guami C 0..1 This IE shall contain the serving AMF's GUAMI. It shall be included if the NF service consumer is an AMF. serviceName ServiceName O 0..1 When present, this IE shall contain the name of the AMF service to which SM context status notifications are to be sent (see clause 6.5.2.2 of 3GPP TS 29.500 [4]). This IE may be included if the Applicant’s Ref. P109419WO2 NF service consumer is an AMF. servingNetwork PlmnIdNid M 1 This IE shall contain the serving core network operator PLMN ID and, for an SNPN, the NID that together with the PLMN ID identifies the SNPN. requestType RequestType C 0..1 This IE shall be present if the Request type IE is received from the UE for a single access PDU session and if the request refers to an existing PDU session or an existing emergency PDU session. The requestType IE shall not be included for a MA-PDU session establishment request. It may be present otherwise. When present, it shall indicate whether the request refers to a new PDU session or emergency PDU session, or to an existing PDU session or emergency PDU session. For request sent from UE, this IE shall be set based on the Request type IE received (see clause 9.11.3.47 of 3GPP TS 24.501 [7]). n1SmMsg RefToBinaryData C 0..1 This IE shall be present and reference the N1 SM Message binary data (see clause 6.1.6.4.2), except during an EPS to 5GS Idle mode mobility or handover using N26. anType AccessType M 1 This IE shall indicate the Access Network Type to which the PDU session is to be associated. additionalAnType AccessType C 0..1 This IE shall indicate the additional Access Network MAPDU Type to which the PDU session is to be associated. This IE shall be present if a MA-PDU session is requested and the UE is registered over both 3GPP access and Non-3GPP access. ratType RatType C 0..1 This IE shall be present and indicate the RAT Type used by the UE, if available. presenceInLadn PresenceState C 0..1 This IE shall be present if the DNN corresponds to a LADN. When present, it shall be set to "IN" or "OUT" to indicate that the UE is in or out of the LADN service area. ueLocation UserLocation C 0..1 This IE shall contain the UE location information (see clause 5.2.3.4), if it is available. (NOTE 1). ueTimeZone TimeZone C 0..1 This IE shall contain the UE Time Zone, if it is available. addUeLocation UserLocation O 0..1 Additional UE location. This IE may be present, if anType indicates a non- 3GPP access and valid 3GPP access user location information is available. When present, it shall contain: - the last known 3GPP access user location (see clause 5.2.3.4); and - the timestamp, if available, indicating the UTC time when the addUeLocation information was acquired. (NOTE 1) smContextStatusUri Uri M 1 This IE shall include the callback URI to receive notification of SM context status. hSmfUri Uri C 0..1 This IE shall be present in HR roaming scenarios, including Indirect Communication with Delegated Applicant’s Ref. P109419WO2 Discovery, if the AMF and V-SMF do not support the ACSCR feature. This IE shall be present in HR roaming scenarios during a PDU session establishment procedure and EPS to 5GS mobility procedures, if the AMF and V- SMF support the ACSCR feature. When present, it shall contain the API URI of the Nsmf_PDUSession service of the selected H-SMF. The API URI shall be formatted as specified in clause 6.1.1. (NOTE 8) hSmfId NfInstanceId O 0..1 This IE may be present when hSmfUri is present. If present, this IE shall carry the NF instance ID of the selected H-SMF. (NOTE 2) smfUri Uri C 0..1 This IE shall be present for a PDU session with an I- DTSSA SMF, including Indirect Communication with Delegated Discovery, if the AMF and I-SMF do not support the ACSCR feature. This IE shall be present for a PDU session with an I- SMF during a PDU session establishment procedure and EPS to 5GS mobility procedures, if the AMF and I-SMF support the ACSCR feature. When present, it shall contain the API URI of the Nsmf_PDUSession service of the selected SMF. The API URI shall be formatted as specified in clause 6.1.1. (NOTE 8) smfId NfInstanceId O 0..1 This IE may be present when smfUri is present. DTSSA If present, this IE shall carry the NF instance ID of the selected SMF. (NOTE 2) oldPduSessionId PduSessionId C 0..1 This IE shall be present if this information is received from the UE. When present, it shall contain the old PDU Session ID received from the UE. See clauses 4.3.2.2.1 and 4.3.5.2 of 3GPP TS 23.502 [3]. pduSessionsActivateLi array(PduSessionId) C 1..N This IE shall be present, during an EPS to 5GS Idle st mode mobility using the N26 interface, if the UE indicated PDU session(s) to be activated in the Registration Request. When present, it shall indicate all the PDU session(s) requested to be re-activated by the UE. ueEpsPdnConnection EpsPdnCnxContain C 0..1 This IE shall be present, during an EPS to 5GS Idle er mode mobility or handover using the N26 interface. When present, it shall contain an MME / SGSN UE EPS PDN connection including the EPS bearer context(s). hoState HoState C 0..1 This IE shall be present during an EPS to 5GS handover using N26 interface, to request the preparation of a handover of the PDU session. When present, it shall be set as specified in clause 5.2.2.2.3. additionalHsmfUri array(Uri) O 1..N This IE may be present in HR roaming scenarios. When present, it shall contain an array of API URI of the Nsmf_PDUSession service of the additional H- Applicant’s Ref. P109419WO2 SMFs discovered by the AMF for the given DNN, hplmnSnssai and for this PDU session. If provided, the V-SMF shall use these additional H-SMF(s) if the V-SMF is not able to receive any response from the H-SMF identified by hSmfUri. The API URI shall be formatted as specified in clause 6.1.1. additionalHsmfId array(NfInstanceId) O 1..N This IE may be present when additionalHsmfUri is present. If present, this IE shall carry the NF instance ID(s) of H-SMF(s) as stated in additionalHsmfUri IE, in exactly the same order. (NOTE 2) additionalSmfUri array(Uri) O 1..N This IE may be present for a PDU session with an I- DTSSA SMF. When present, it shall contain an array of API URI of the Nsmf_PDUSession service of the additional SMFs discovered by the AMF for the given DNN, Snssai and for this PDU session. If provided, the I-SMF shall use these additional SMF(s) if the I- SMF is not able to receive any response from the SMF identified by smfUri. The API URI shall be formatted as specified in clause 6.1.1. additionalSmfId array(NfInstanceId) O 1..N This IE may be present when additionalSmfUri is DTSSA present. If present, this IE shall carry the NF instance ID(s) of SMF(s) as stated in additionalSmfUri IE, in exactly the same order. (NOTE 2) pcfId NfInstanceId O 0..1 When present, this IE shall contain the identifier of: - the H-PCF selected by the AMF (for UE Policy), for a HR PDU session; or - the V-PCF selected by the AMF (for Access and Mobility Policy), for a PDU session in LBO roaming scenarios; or - the PCF selected by the AMF (for Access and Mobility Policy and / or UE Policy), for a PDU session in non-roaming scenarios. pcfGroupId NfGroupId O 0..1 This IE may be present in non-roaming and HR roaming scenarios. When present, this IE shall contain the identity of the (home) PCF group serving the UE for Access and Mobility Policy and / or UE Policy. pcfSetId NfSetId O 0..1 This IE may be present if pcfId IE is present. When present, this IE shall contain the NF Set ID of the PCF indicated by the pcfId IE. nrfUri Uri O 0..1 This IE may be present to indicate the NRF to use for PCF selection within the same network slice instance. When present, the SMF shall use the NRF URI to select the PCF. Applicant’s Ref. P109419WO2 supportedFeatures SupportedFeatures C 0..1 This IE shall be present if at least one optional feature defined in clause 6.1.8 is supported. selMode DnnSelectionMode C 0..1 This IE shall be present if it is available. When present, it shall be set to: - "VERIFIED", if the requested DNN provided by UE or the selected DNN provided by the network corresponds to an explicitly subscribed DNN; or - "UE_DNN_NOT_VERIFIED", if the requested DNN provided by UE corresponds to the usage of a wildcard subscription; or - "NW_DNN_NOT_VERIFIED", if the selected DNN provided by the network corresponds to the usage of a wildcard subscription. If both the requested DNN (i.e. dnn IE) and selected DNN (i.e. selected Dnn IE) are present, the selMode shall be related to the selected DNN. backupAmfInfo array(BackupAmfInf C 1..N This IE shall be included if the NF service consumer o) is an AMF and the AMF supports the AMF management without UDSF for the following cases: - First interaction with SMF. - Modification of the BackupAmfInfo. traceData TraceData C 0..1 This IE shall be included if trace is required to be activated (see 3GPP TS 32.422

[0022] ). udmGroupId NfGroupId O 0..1 When present, it shall indicate the identity of the UDM group serving the UE. routingIndicator string O 0..1 When present, it shall indicate the Routing Indicator of the UE. hNwPubKeyId integer O 0..1 When present, it shall indicate the Home Network Public Key Identifier of the UE. (NOTE 3) epsInterworkingInd EpsInterworkingIndi O 0..1 The AMF may provide the indication when a PGW- cation C+SMF is selected to serve the PDU Session. When present, this IE shall indicate whether the PDU session may possibly be moved to EPS and whether N26 interface to be used during EPS interworking procedures. The AMF may derive the value of the indication from different sources, like UE 5GMM capabilities (e.g. "S1 mode supported"), UE subscription data (e.g. "Core Network Type Restriction to EPC" and "Interworking with EPS Indication" for the DNN) and configurations. indirectForwardingFlag boolean C 0..1 The AMF shall include this indication during N26 based Handover procedure from EPS to 5GS (see 3GPP TS 23.502 [3], clause 4.11.1.2.2), to inform the SMF of the applicability or non-applicability of indirect data forwarding. When present, it shall be set as follows: - True: indirect data forwarding is applicable Applicant’s Ref. P109419WO2 - False: indirect data forwarding is not applicable directForwardingFlag boolean C 0..1 The AMF shall include this indication during N26 based Handover procedure from EPS to 5GS (see 3GPP TS 23.502 [3], clause 4.11.1.2.2), to inform the SMF of the applicability or non-applicability of direct data forwarding. When present, it shall be set as follows: - True: direct data forwarding is applicable - False: direct data forwarding is not applicable targetId NgRanTargetId C 0..1 This IE shall be present in the following cases: - during an EPS to 5GS handover preparation using the N26 interface, when the hoState IE is set to the value "PREPARING"; - during N2 based handover procedure with I-SMF or V-SMF insertion / change / removal, when hostate IE is set to the value "PREPARING". When present, it shall contain the Target ID identifying the target RAN Node ID and TAI. In case of EPS to 5GS handover, the TAI is received in the Forward Relocation Request from the Source MME. epsBearerCtxStatus EpsBearerContextSt C 0..1 This IE shall be present during an EPS to 5GS idle atus mode mobility using the N26 interface, if received in the Registration Request from the UE. When present, it shall be set to the value received from the UE. cpCiotEnabled boolean C 0..1 This IE shall be present with the value "True", if CIOT - the NF service consumer (e.g. the AMF) has verified that the CIOT feature is supported by the SMF (and for a home-routed session, that it is also supported by the H-SMF); and - Control Plane CIoT 5GS Optimisation is enabled for the PDU session (see 3GPP TS 23.502 [3], clauses 4.3.2.2.1 and 4.3.2.2.2). When present, it shall be set as follows: - True: Control Plane CIoT 5GS Optimisation is enabled. - False (default): Control Plane CIoT 5GS Optimisation is not enabled. cpOnlyInd boolean C 0..1 This IE shall be present with the value "True", if the CIOT PDU session shall only use Control Plane CIoT 5GS Optimisation (see clause 5.31.4.1 of 3GPP TS 23.501 [2]). When present, it shall be set as follows: - True: the PDU session shall only use Control Plane CIoT 5GS Optimisation - False (default): the PDU session is not constrained to only use Control Plane CIoT 5GS Optimisation. Applicant’s Ref. P109419WO2 invokeNef boolean C 0..1 This IE shall be present with the value "True", if CIOT Control Plane CIoT 5GS Optimisation is enabled and data delivery via NEF is selected for the PDU session (see 3GPP TS 23.502 [3], clause 4.3.2.2.2). When present, it shall be set as follows: - True: Data delivery via NEF is selected. - False (default): Data delivery via NEF is not selected. maRequestInd boolean C 0..1 This IE shall be present if a MA-PDU session is MAPDU requested to be established. When present, it shall be set as follows: - True: a MA-PDU session is requested - False (default): a MA-PDU session is not requested maNwUpgradeInd boolean C 0..1 This IE shall only be present if the PDU session is MAPDU allowed to be upgraded to MA PDU session (see clause 4.22.3 of 3GPP TS 23.502 [3]). When present, it shall be set as follows: - True: the PDU session is allowed to be upgraded to MA PDU session - False (default): the PDU session is not allowed to be upgraded to MA PDU session When maRequestInd is present and set to "true", this IE shall not be present. n2SmInfo RefToBinaryData C 0..1 This IE shall be present if N2 SM Information needs DTSSA to be sent to the I-SMF. n2SmInfoType N2SmInfoType C 0..1 This IE shall be present if "n2SmInfo" attribute is DTSSA present. When present, this IE shall indicate the NG AP IE type for the NG AP SMF related IE container carried in "n2SmInfo" attribute. n2SmInfoExt1 RefToBinaryData C 0..1 This IE shall be present if more than one N2 SM DTSSA Information has been received from the AN. When present, this IE shall reference the N2 SM Information binary data (see clause 6.1.6.4.3). n2SmInfoTypeExt1 N2SmInfoType C 0..1 This IE shall be present if "n2SmInfoExt1" attribute is DTSSA present. When present, this IE shall indicate the NG AP IE type for the NG AP SMF related IE container carried in "n2SmInfoExt1" attribute. smContextRef Uri C 0..1 This IE shall be present during an I-SMF or V-SMF DTSSA insertion if available and during an I-SMF or V-SMF change or removal. When present, this IE shall contain the URI of the SM Context resource in the SMF or of the SM context resource in the source I-SMF or V-SMF during an I-SMF or V-SMF insertion or during an I- SMF or V-SMF change / removal respectively. The URI shall be an absolute URI, including apiRoot (see clause 6.1.3.3.2). (NOTE 6) Applicant’s Ref. P109419WO2 smContextSmfPlmnId PlmnIdNid C 0..1 This IE shall be present during an inter-PLMN DTSSA mobility procedure if the smContextRef IE is present. It may be present otherwise, if the smContextRef IE is present. When present, this IE shall carry the PLMN ID of the SMF which hosts the SM Context resource identified by smContextRef IE. For an SNPN, the NID together with the PLMN ID shall identify the SNPN. (NOTE 7) smContextSmfId NfInstanceId O 0..1 This IE may be present if smContextRef is present. DTSSA When present, this IE shall carry the NF instance ID of the SMF which hosts the SM Context resource identified by smContextRef IE. (NOTE 2) smContextSmfSetId NfSetId C 0..1 This IE shall be present, if available. DTSSA When present, this IE shall contain the NF Set ID of the old V-SMF or the old I-SMF or the SMF as identified by the smContextSmfId. smContextSmfService NfServiceSetId C 0..1 This IE shall be present, if available. DTSSA SetId When present, this IE shall contain the NF Service Set ID of the PDUSession service instance (for this SmContext) in the old V-SMF or the old I-SMF or the SMF. smContextSmfBinding SbiBindingLevel C 0..1 This IE shall be present, if available. DTSSA When present, this IE shall contain the SBI binding level of the SM context resource. upCnxState UpCnxState C 0..1 This IE shall be present to request the activation of DTSSA the user plane connection of the PDU session, in the following cases: - during Service Request procedure with an I-SMF insertion / change / removal, or with a V-SMF change (see clause 5.2.2.2.6); - during Registration procedure with an I-SMF insertion / change / removal, or with a V-SMF insertion / change / removal (see clause 5.2.2.2.7), if this PDU session is requested to be activated by the UE. smallDataRateStatus SmallDataRateStatu C 0..1 This IE shall be present if the small data rate control CIOT s status is available in AMF, see clause 5.31.14.3 of 3GPP TS 23.501 [2] and clause 4.3.2.2.1 of 3GPP TS 23.502 [3]. apnRateStatus ApnRateStatus C 0..1 This IE shall be present if the APN rate control status CIOT is available in AMF, see clause 4.7.7.3 in 3GPP TS 23.401

[0033] and clause 5.2.8.2.5 in 3GPP TS 23.502 [3]. extendedNasSmTimer boolean C 0..1 This IE shall be present with the value "True" if the CIOT Ind UE supports CE mode B and use of CE mode B is not restricted according to the Enhanced Coverage Restriction information in the UE context in the AMF. Applicant’s Ref. P109419WO2 When present, it shall indicate whether extended NAS SM timers shall be used for the UE as specified in 3GPP TS 24.501 [7], as follows: - True: extended NAS SM timers shall be used - False (default): normal NAS SM timers shall be used. dlDataWaitingInd boolean C 0..1 This IE shall be present during an EPS to 5GS Idle CIOT mode mobility using N26 interface with data forwarding (see clause 4.11.1.3.3A of 3GPP TS 23.502 [3]), if the same indication is received from the MME in the Context Response message. When present, it shall be set as follows: - true: DL data needs to be sent to the UE; - false (default): no DL data needs to be sent to the UE. ddnFailureSubs DdnFailureSubs C 0..1 This IE shall be present to subscribe the notification CIOT of the DDN Failure if the Availability after DDN failure event is subscribed by the UDM, see clause 4.15.3.2.7 of 3GPP TS 23.502 [3]. smfTransferInd boolean C 0..1 This IE shall be present during an SMF Context CTXTR Transfer procedure, LBO or no Roaming, no I-SMF. When present, it shall be set as follows: - True: SMF Context Transfer - False (default): Not an SMF Context Transfer oldSmfId NfInstanceId C 0..1 This IE shall be present if smfTransferInd is set to CTXTR true. When present, it shall indicate old SMF instance identifier. oldSmContextRef Uri C 0..1 This IE shall be present if smfTransferInd is set to CTXTR true. When present, this IE shall contain the identifier of the SM Context resource in the old SMF. This IE shall also be present, without smfTransferInd EnEDGE set, if this information was received earlier in Notify SM Context Status, see clause 4.3.5.2 of 3GPP TS 23.502 [3]. wAgfInfo WAgfInfo C 0..1 This IE shall be present, if received from the W-AGF. When present, it shall contain information about the N3 terminations of the W-AGF. The SMF may use this information when selecting the UPF. tngfInfo tngfInfo C 0..1 This IE shall be present, if received from the TNGF. When present, it shall contain information about the N3 terminations of the TNGF. The SMF may use this information when selecting the UPF. twifInfo twifInfo C 0..1 This IE shall be present, if received from the TWIF. When present, it shall contain information about the N3 terminations of the TWIF. The SMF may use this information when selecting the UPF. ranUnchangedInd boolean C 0..1 This IE shall be present if the NG-RAN is not DTSSA Applicant’s Ref. P109419WO2 changed in case of I-SMF / V-SMF change or insertion during CM-CONNECTED registration procedure after EPS to 5GS handover (see clause 5.2.2.2.7) or I- SMF selection per DNAI (see clause 5.2.2.2.12). When present, it shall be set as follows: - true: NG-RAN is not changed; - false: NG-RAN is changed. samePcfSelectionInd boolean C 0..1 This IE shall be present, if the AMF received the PCF Selection Assistance info from the UDM indicating that the same PCF is required. (NOTE 4) When present, it shall be set as follows: - True: the SMF is indicated to select the same PCF instance for the PDU session. - False (default): the SMF is not indicated to select the same PCF instance for the PDU session. targetDnai Dnai C 0..1 This IE shall be present, if this information was EnEDGE received earlier in Notify SM Context Status. I-SMF or SMF shall use this information for I-UPF / L-PSA / PSA selection, see clauses 4.3.5.1, 4.3.5.2 or 4.23.5.4 of 3GPP TS 23.502 [3]. nrfManagementUri Uri C 0..1 If included, this IE shall contain the API URI of the NFManagement Service (see clause 6.1.1 of 3GPP TS 29.510

[0019] ) of the NRF or hNRF. It shall be present during the PDU session establishment procedure with an I-SMF / V-SMF or mobility procedure with I-SMF / V-SMF insertion / change, if it is returned from the NSSF or hNSSF (see clause 6.1.6.2.7 of 3GPP TS 29.531

[0040] ). nrfDiscoveryUri Uri C 0..1 If included, this IE shall contain the API URI of the NFDiscovery Service (see clause 6.2.1 of 3GPP TS 29.510

[0019] ) of the NRF or hNRF. It shall be present during the PDU session establishment procedure with an I-SMF / V-SMF or mobility procedure with I-SMF / V-SMF insertion / change, if it is returned from the NSSF or hNSSF (see clause 6.1.6.2.7 of 3GPP TS 29.531

[0040] ). nrfAccessTokenUri Uri C 0..1 If included, this IE shall contain the API URI of the Access Token Service (see clause 6.3.2 of 3GPP TS 29.510

[0019] ) of the NRF or hNRF. It shall be present during the PDU session establishment procedure with an I-SMF / V-SMF or mobility procedure with I-SMF / V-SMF insertion / change, if it is returned from the NSSF or hNSSF (see clause 6.1.6.2.7 of 3GPP TS 29.531

[0040] ). nrfOauth2Required map(boolean) C 1..N This IE should be present if the nrfUri IE, Applicant’s Ref. P109419WO2 nrfManagementUri IE or nrfDiscoveryUri IE is present and if the information is available. When present, this IE shall indicate whether the NRF requires Oauth2-based authorization for accessing its services. The key of the map shall be the name of an NRF service, e.g. "nnrf-nfm" or "nnrf-disc". The value of each entry of the map shall be encoded as follows: - true: OAuth2 based authorization is required. - false: OAuth2 based authorization is not required. The absence of this IE means that no indication is available about the usage of Oauth2 for authorization of NRF services. smfBindingInfo string C 0..1 This IE shall be present, if available. DTSSA When present, this IE shall contain the Binding indications of the SM context resource and shall be set to the value of the 3gpp-Sbi-Binding header defined in clause 5.2.3.2.6 of 3GPP TS 29.500 [4], without the header name. pvsInfo array(ServerAddres C 1..N This IE shall be present, if the AMF received this ENPN singInfo) information from AUSF during User Plane Remote Provisioning of UEs procedure (see clause 5.30.2.10.4 of 3GPP TS 23.501

[0040] ). When present, this IE shall contain the remote Provisioning Server(s) information. onboardingInd boolean C 0..1 This IE shall be present, if the UE is registered for ENPN onboarding in an SNPN (see clause 5.30.2.10.4 in 3GPP TS 23.501

[0040] and clause 4.2.2.2.4 in 3GPP TS 23.502 [3]). - false (default): The UE is not registered in an SNPN for the purpose of onboarding; - true: The UE has registered in the SNPN for the purpose of onboarding. oldPduSessionRef Uri C 0..1 This IE shall be present if this information was EnEDGE received earlier in Notify SM Context Status, see clause 4.3.5.2 of 3GPP TS 23.502 [3]. When present, this IE shall contain the URI of the PDU session resource in the old SMF. The URI shall be an absolute URI, including apiRoot (see clause 6.1.3.6.2). smPolicyNotifyInd boolean O 0..1 When present, this IE shall indicate whether the SM SPAE Policy Association Establishment and Termination events shall be reported for the PDU session by the PCF for the SM Policy to the PCF for the UE: Applicant’s Ref. P109419WO2 - true: SM Policy Association Establishment and Termination events shall be reported - false (default): SM Policy Association Establishment and Termination events is not required (NOTE 5) pcfUeCallbackInfo PcfUeCallbackInfo C 0..1 This IE shall be present when the smPolicyNotifyInd SPAE IE is present with value true. When present, this IE shall contain the callback information of the PCF for the UE to receive SM Policy Association Establishment and Termination events notification from the PCF for the SM Policy. (NOTE 5) satelliteBackhaulCat SatelliteBackhaulCa O 0..1 This IE may be present if the AMF supports the 5GSAT tegory 5GSAT feature and the AMF is aware that there is a satellite backhaul towards the 5G AN serving the UE. When present, this IE shall indicate the category of the satellite backhaul used towards the 5G AN serving the UE. upipSupported boolean C 0..1 This IE shall be present during the PDU session UPIPE establishment procedure, if the UE supports User Plane Integrity Protection with EPS and if the AMF supports the related functionality. It may be present otherwise. When present, this IE shall be set as follows: - true: User Plane Integrity Protection with EPS is supported; - false (default): User Plane Integrity Protection with EPS is not supported. uavAuthenticated boolean C 0..1 This IE shall be present during the PDU session establishment procedure, if the UAV has been authenticated by the USS for the requested DNN subject to aerial services. It may be present otherwise. When present, this IE shall be set as follows: - true: UAV has been authenticated by the USS; - false: UAV has not been authenticated by the USS. If both the requested DNN (i.e. dnn IE) and selected DNN (i.e. selected Dnn IE) are present, the uavAuthenticated shall be related to the selected DNN. disasterRoamingInd boolean O 0..1 This IE may be set during the PDU session establishment. When present, this IE shall be set as follows: - true: the UE is registered for Disaster Roaming Applicant’s Ref. P109419WO2 service - false (default): the UE is not registered for Disaster Roaming service anchorSmfOauth2Req boolean O 0..1 When present, this IE shall indicate whether the H- uired SMF or SMF for a PDU session with an I-SMF requires Oauth2-based authorization for accessing its Nsmf_PDUSession service. - true: OAuth2 based authorization is required. - false: OAuth2 based authorization is not required. The absence of this IE means that no indication is available about the usage of Oauth2 for authorization of the anchor SMF's Nsmf_PDUSession service. (NOTE 2) smContextSmfOauth2 boolean O 0..1 This IE may be present during an I-SMF insertion, Required change or removal. This IE may be present when V- SMF changes within the same PLMN. When present, this IE shall indicate whether the SMF hosting the SM Context requires Oauth2-based authorization for accessing its Nsmf_PDUSession service. - true: OAuth2 based authorization is required. - false: OAuth2 based authorization is not required. The absence of this IE means that no indication is available about the usage of Oauth2 for authorization of the Nsmf_PDUSession service on the SMF hosting the SM Context. (NOTE 2) localBreakout boolean C 0..1 This IE shall be present if the user is inbound roamer during a PDU session establishment procedure, a PDN connection establishment procedure, and EPS / ePDG to 5GS mobility procedures, When present, it shall be set as follows: - True: inbound roaming user with local breakout - False: non-roaming user NOTE 1: In shared networks, when the message is sent from the VPLMN to the HPLMN, the PLMN ID that is communicated in this IE shall be that of the selected Core Network Operator. In shared networks, when the AMF and SMF pertain to the same PLMN, the Primary PLMN ID shall be communicated in the ECGI or NCGI to the SMF. The Core Network Operator PLMN ID shall be communicated in the TAI and the Serving Network. NOTE 2: If the SMF is aware that Oauth is enabled for the indicated next hop SMF, e.g. when the anchorSmfOauth2Required IE and / or the smContextSmfOauth2Required IE are received with the value true or when received a "401 Unauthorized" response code from next hop SMF, the SMF shall use the NF instance Identifier to acquire the access token for the Nsmf_PduSession service on the indicated SMF. NOTE 3: If present, this attribute shall be used together with routingIndicator. This attribute is only used by the HPLMN in roaming scenarios. NOTE 4: If present, this attribute shall be used together with the PCF ID received from the AMF for selecting the same Applicant’s Ref. P109419WO2 PCF instance for the PDU session. NOTE 5: If the AMF has received the callback information of the PCF for the UE together with the information of the PDU sessions (i.e. Slice and DNN combination) that are applicable for notification of SM Policy Association events, the AMF shall identify whether the non-roaming or local breakout PDU session to be created is applicable for SM Policy Association events, i.e, whether the slice and DNN combination of the PDU session is listed in the received PDU session information from the PCF for the UE. If the PDU session is applicable for notification of SM Policy Association events, the AMF shall include the smPolicyNotifyInd IE with the value "true" and the callback information of the PCF for the UE in the request. The SMF shall forward the callback information of the PCF for the UE to the PCF for SM Policy during SM Policy Association Establishment. See clause 4.3.2.2.1 of 3GPP TS 23.502 [3]. NOTE 6: See NOTE 2 of Table 6.1.6.2.3-1. NOTE 7: If the PLMN ID of the SMF holding the SM context received in smContextSmfPlmnId attribute is different from the PLMN ID of the target V-SMF / I-SMF / anchor SMF, the target V-SMF / I-SMF / anchor SMF shall retrieve the SM Context from the SMF via the SEPP. In this case, the smContextSmfPlmnId attribute may also be used for the discovery and selection of the local SEPP. NOTE 8: The smfUri and hSmfUri attributes need not be included in Create SM Context request in procedures other than PDU session establishment procedure and EPS to 5GS mobility procedures if the NF Service Consumer (e.g. AMF) and I-SMF / V-SMF support the "ACSCR" feature. See clause 6.1.8. * * * Next Change * * * * Table 6.1.6.2.10-1: Definition of type PduSessionCreatedData Attribute name Data type P Card Description Applica inalit bility y pduSessionType PduSessionType M 1 This IE shall indicate the selected PDU type. sscMode string M 1 This IE shall indicate the SSC mode applicable to the PDU session. When present, it shall be encoded as one character in hexadecimal representation, taking a value of "0" to "7", representing the 3 bits of the SSC mode value of the SSC mode IE specified in clause 9.11.4.16 of 3GPP TS 24.501 [7]. Pattern: "^[0-7]$" Example: SSC mode 3 shall be encoded as "3". (NOTE 1). hcnTunnelInfo TunnelInfo C 0..1 This IE shall be present for a HR PDU session, except when Control Plane CIoT 5GS Optimisation is enabled and data delivery via NEF is selected for this PDU session. When present, this IE shall contain the N9 tunnel information of the home CN side, i.e. H-UPF. cnTunnelInfo TunnelInfo C 0..1 This IE shall be present for a PDU session involving DTSSA an I-SMF, except when Control Plane CIoT 5GS Optimisation is enabled and data delivery via NEF is selected for this PDU session. When present, this IE shall contain the N9 tunnel information of the PSA UPF. additionalCnTunnelInf TunnelInfo C 0..1 This IE shall be present if a MA-PDU session is MAPDU o established for a UE registered over both 3GPP Applicant’s Ref. P109419WO2 access and Non-3GPP access. When present, it shall contain additional N9 tunnel information of the UPF controlled by the H-SMF or SMF. sessionAmbr Ambr C 0..1 This IE shall be present, except when Control Plane CIoT 5GS Optimisation is enabled for the PDU session. When present, this IE shall contain the Session AMBR granted to the PDU session. qosFlowsSetupList array(QosFlowSetupI C 1..N This IE shall be present, except when Control Plane tem) CIoT 5GS Optimisation is enabled for the PDU session. When present, this IE shall contain the full set of QoS flow(s) to establish for the PDU session. It shall contain at least the Qos flow associated to the default Qos rule. In V-SMF / I-SMF insertion scenarios where no QoS Rule(s) associated to a QoS flow can or need to be sent to the UE, the qosRules attribute of the QosFlowSetupItem may be set to an empty string or to the latest QoS Rule(s) associated to the QoS flow. (NOTE 3) hSmfInstanceId NfInstanceId C 0..1 This IE shall be present for a HR PDU session. When present, it shall contain the identifier of the home SMF. smfInstanceId NfInstanceId C 0..1 This IE shall be present for a PDU session with an I- DTSSA SMF. When present, it shall contain the identifier of the SMF. pduSessionId PduSessionId C 0..1 This IE shall be present during an EPS to 5GS Idle mode mobility or handover preparation using the N26 interface. When present, it shall be set to the PDU Session ID. sNssai Snssai C 0..1 This IE shall be present during an EPS to 5GS Idle mode mobility or handover using the N26 interface. When present, it shall contain: - the S-NSSAI assigned to the PDU session in the Home PLMN, for a HR PDU session; - the S-NSSAI assigned to the PDU session in the serving PLMN, for a PDU session with an I-SMF. The Snssai shall overwrite the S- NSSAI earlier stored in I-SMF, if they are different. enablePauseCharging boolean C 0..1 This IE shall be present, based on operator's policy, to enable the use of Pause of Charging for the PDU session (see clause 4.4.4 of 3GPP TS 23.502 [3]). When present, it shall be set as follows: - true: enable Pause of Charging; Applicant’s Ref. P109419WO2 - false (default): disable Pause of Charging. ueIpv4Address Ipv4Addr C 0..1 This IE shall be present if the SMF assigns a UE IPv4 address to the PDU session. ueIpv6Prefix Ipv6Prefix C 0..1 This IE shall be present if the SMF assigns a UE IPv6 prefix to the PDU session. n1SmInfoToUe RefToBinaryData C 0..1 This IE shall be present if the SMF needs to send N1 SM information to the UE that does not need to be interpreted by the V-SMF or I-SMF. When present, this IE shall reference the n1SmInfoToUe binary data (see clause 6.1.6.4.4). epsPdnCnxInfo EpsPdnCnxInfo C 0..1 This IE shall be present if the PDU session may be moved to EPS during its lifetime. epsBearerInfo array(EpsBearerInfo) C 1..N This IE shall be present if the PDU session may be moved to EPS during its lifetime. supportedFeatures SupportedFeatures C 0..1 This IE shall be present if at least one optional feature defined in clause 6.1.8 is supported. maxIntegrityProtected MaxIntegrityProtecte C 0..1 This IE shall be present if the upSecurity IE is DataRate dDataRate present and indicates that integrity protection is preferred or required. When present, it shall indicate the maximum integrity protected data rate for uplink. If the maxIntegrityProtectedDataRateDl IE is absent, this IE applies to both uplink and downlink. (NOTE 6) maxIntegrityProtected MaxIntegrityProtecte C 0..1 This IE may be present if the upSecurity IE is present DataRateDl dDataRate and indicates that integrity protection is preferred or required. When present, it shall indicate the maximum integrity protected data rate for downlink. (NOTE 6) alwaysOnGranted boolean C 0..1 This IE shall be present if the alwaysOnRequested IE was received in the request or if the SMF determines, based on local policy, that the PDU session needs to be established as an always-on PDU session. When present, it shall be set as follows: - true: always-on PDU session granted. - false (default): always-on PDU session not granted. gpsi Gpsi C 0..1 This IE shall be present if no GPSI IE is provided in the request, e.g. for a PDU session moved from another access or another system, and the SMF knows that a GPSI is already associated with the PDU session. When present, it shall contain the user's GPSI associated with the PDU session. upSecurity UpSecurity O 0..1 When present, this IE shall indicate the security policy for integrity protection and encryption for the user plane of the PDU session. If this IE is present, it shall not indicate that integrity Applicant’s Ref. P109419WO2 protection is preferred or required, if the maxIntegrityProtectedDataRate IE is not present (e.g. if UE Integrity Protection Maximum Data Rate is not available in the SMF). (NOTE 6) roamingChargingProfil RoamingChargingPr O 0..1 Roaming Charging Profile selected by the HPLMN e ofile (see clauses 5.1.9.1, 5.2.1.7 and 5.2.2.12.2 of 3GPP TS 32.255

[0025] ). hSmfServiceInstanceI string O 0..1 When present, this IE shall contain the d serviceInstanceId of the H-SMF service instance serving the PDU session, for a HR PDU session. This IE may be used by the V-SMF to identify PDU sessions affected by a failure or restart of the H-SMF service (see clause 6.2 of 3GPP TS 23.527

[0024] ). smfServiceInstanceId string O 0..1 When present, this IE shall contain the DTSSA serviceInstanceId of the SMF service instance serving the PDU session, for a PDU session with an I-SMF. This IE may be used by the I-SMF to identify PDU sessions affected by a failure or restart of the SMF service (see clause 6.2 of 3GPP TS 23.527

[0024] ). recoveryTime DateTime O 0..1 Timestamp when the SMF service instance serving the PDU session was (re)started (see clause 6.3 of 3GPP TS 23.527

[0024] ). dnaiList array(Dnai) C 1..N This IE shall be present over N16a, if available and DTSSA an I-SMF has been inserted into a PDU session, during the following procedures: PDU session establishment, Registration, Service Request, Xn based handover, Inter NG-RAN node N2 based handover (see clause 4.23 of 3GPP TS 23.502 [3]). When present, it shall include the list of DNAIs of interest for the PDU session for local traffic steering at the I-SMF. If the I-SMF and the SMF support the DTSSA-Ext1 DTSSA- feature, when present, this IE should include the full Ext1 list of DNAIs of interest for PDU session, including DNAIs that may not be supported by the I-SMF and excluding the ones supported by the Anchor SMF. ipv6MultiHomingInd boolean C 0..1 This IE shall be present over N16a, if available and DTSSA an I-SMF has been inserted into the PDU session during the following procedures: PDU session establishment, Registration, Service Request, Xn based handover, Inter NG-RAN node N2 based handover (see clause 4.23 of 3GPP TS 23.502 [3]). When present, it shall be set as follows: - true: IPv6 multi-homing is permitted. - false (default): IPv6 multi-homing is not allowed. maAcceptedInd boolean C 0..1 This IE shall be present if a request to establish a MAPDU MA PDU session was accepted or if a single access PDU session was upgraded into a MA PDU session Applicant’s Ref. P109419WO2 (see clauses 4.22.2 and 4.22.3 of 3GPP TS 23.502 [3]). When present, it shall be set as follows: - true: MA PDU session - false (default): single access PDU session homeProvidedChargin string O 0..1 When present, this IE shall contain the Home gId provided Charging ID (see 3GPP TS 32.255

[0025] ). This IE shall be present during an EPS to 5GS Idle mode mobility or Handover of a HR PDU session. (NOTE 5) The string shall encode the Charging ID (32-bit unsigned integer value, with maximum value "4294967295") in decimal representation. Pattern: '^(0|([1-9]{1}[0-9]{0,9}))$' (NOTE 8) nefExtBufSupportInd boolean C 0..1 This IE shall be present with value "true", if NEF has CIOT indicated Extended Buffering Support for mobile terminated data in SMF-NEF connection establishment response. When present, this IE shall be set as following: - true: Extended Buffering supported by NEF - false (default): Extended Buffering not supported by NEF smallDataRateControl boolean C 0..1 This IE shall be present and set to "true" if small data CIOT Enabled rate control is applicable on the PDU session. When present, it shall be set as follows: - true: small data rate control is applicable. - false (default): small data rate control is not applicable. ueIpv6InterfaceId string C 0..1 This IE shall be present if the H-SMF / SMF has assigned IPv6 interface identifier to the UE during the PDU session establishment for the Home-routed Roaming scenario or for a PDU session with an I- SMF. When present, it shall encode the UE IPv6 Interface Identifier to be used by the UE for its link-local address configuration with 16 hexadecimal digits. Pattern: "^[A-Fa-f0-9]{16}$" ipv6Index IpIndex C 0..1 This IE shall be present if IPv6 Index has been DTSSA received from PCF during SM Policy Creation. (NOTE 4) dnAaaAddress IpAddress O 0..1 When present, this IE shall contain the address of DTSSA DN-AAA server for UE IP Address allocation that has been received from UDM. (NOTE 4). redundantPduSessionI RedundantPduSessi C 0..1 This IE shall be present for a PDU session with an I- DCE2E nfo onInformation SMF, if Dual Connectivity based end to end R Applicant’s Ref. P109419WO2 Redundant User Plane Paths shall apply as specified in clause 5.33.2.1 of 3GPP TS 23.501 [2], regardless of whether the redundantPduSessionInfo IE was received or not in the request. If an RSN and / or PDU Session Pair ID was received from the UE, the same RSN and / or PDU Session Pair ID shall be returned in the response; additionally, if either the RSN or PDU Session Pair ID was not received from the UE, the anchor SMF shall determine and also return an RSN or PDU Session Pair ID respectively in the response. nspuSupportInd boolean C 0..1 This IE shall be present and set to "true" if enablePauseCharging is set to "true" and if the (H- )SMF and PSA UPF support Notify Start Pause of Charging via user plane feature as specified in clause 5.30 of 3GPP TS 29.244

[0029] . When present, it shall be set as follows: - true: Notify Start Pause of Charging via user plane feature is supported. interPlmnApiRoot Uri C 0..1 This IE should be present if the PDU session may be subject to inter-PLMN mobility and different PDU session context URIs shall be used for intra-PLMN and inter-PLMN signaling requests targeting the PDU session context. When present, it shall contain the apiRoot of the PDU session context to be used in inter-PLMN signalling request targeting the PDU session context. (NOTE 7) intraPlmnApiRoot Uri C 0..1 This IE should be present if the PDU session may be subject to inter-PLMN mobility and different PDU session context URIs shall be used for intra-PLMN and inter-PLMN signaling requests targeting the PDU session context. When present, it shall contain the apiRoot of the PDU session context to be used in intra-PLMN signalling request targeting the PDU session context. (NOTE 7) udmGroupId NfGroupId O 0..1 This IE may be present during an EPS to 5GS handover using the N26 interface procedure. When present, it shall indicate the identity of the UDM group serving the UE. pcfGroupId NfGroupId O 0..1 This IE may be present during an EPS to 5GS handover using the N26 interface procedure. When present, this IE shall contain the identity of the (home) PCF group serving the PDU session for Session Management policy. hrsboRspInfo HrsboRspInfo C 0..1 This IE shall be present in HR roaming scenarios if HR-SBO the H-SMF supports the HR-SBO feature and it receives a request for HR-SBO. When present, this IE shall Include the information for HR-SBO. The absence of this IE shall indicate that the HR- SBO is not allowed. pendingUpdateInfoList array(PendingUpdat O 1..N When present, this IE shall indicate the list of eInfo) information that are not required to be updated in Applicant’s Ref. P109419WO2 real-time to the (H-)SMF, i.e. the change of the listed information (e.g. UE location or Timezone) may be piggybacked in a subsequent essential update (e.g. to exchange the N1 message from the UE) to the (H-)SMF. The NF service consumer (i.e. I-SMF / V-SMF) should not trigger an Update to the (H-)SMF including only the change(s) of the listed information. NOTE 1: This IE contains information that the V-SMF or I-SMF only needs to transfer to the UE (without interpretation). It is sent as a separate IE rather than within the n1SmInfoToUE binary data because the Selected SSC mode IE is defined as a "V" IE (i.e. without a Type field) in the NAS PDU Session Establishment Accept message. NOTE 2: In scenarios with a V-SMF / I-SMF insertion, the V-SMF / I-SMF may receive in the Create Response some IEs it has already received during the earlier SM context retrieval from the SMF (e.g. due to the condition of presence of IEs in the Create Response). In such a case, the V-SMF / I-SMF shall overwrite the IEs earlier received with the new IEs received in the Create Response. NOTE 3: The V-SMF / I-SMF shall ignore any QoS Rule(s) associated to a QoS flow received in PduSessionCreatedData during V-SMF / I-SMF insertion scenarios where no QoS Rule(s) can be sent to the UE, i.e. during Registration, Inter NG-RAN node N2 based handover, and EPS to 5GS Idle mode mobility / handover using N26 interface procedures with V-SMF / I-SMF insertion, or during Service Request and Xn based handover procedures with I- SMF insertion. In such scenarios, the (H-)SMF shall initiate a subsequent PDU session modification procedure if it needs to change the QoS Rules associated to the QoS flows. NOTE 4: The I-SMF may use IPv6 index to assist in selecting how the IPv6 prefix is to be allocated for local PSA when IPv6 multi-homing is applied for the PDU session. If the IPv6 index indicates UE IP address allocation should be performed towards DN-AAA server, the DN-AAA server address may be included from the SMF to the I-SMF. NOTE 5: The chargingId IE in SmContext (see clause 6.1.6.2.39) shall be set to the value received in the homeProvidedChargingId IE during an EPS to 5GS Idle mode mobility or Handover of a HR PDU session. NOTE 6: During inter-system mobility from EPS to 5GS, the UE Integrity Protection Maximum Data Rate is not available at the SMF during PDU Session Creation. The UE will provide UE Integrity Protection Maximum Data Rate to the network within a subsequent UE triggered PDU session modification procedure, as specified in clause 4.3.3.2 of 3GPP TS 23.502 [3]. NOTE 7: During an inter-PLMN mobility, after retrieving the SM context from the old V-SMF, I-SMF or anchor SMF, the target V-SMF or I-SMF shall replace the apiRoot of the pduSessionRef with the interPlmnApiRoot (if available) if the anchor SMF is not in the target PLMN, or with the intraPlmnApiRoot (if available) otherwise. The Operator Identifier in the DNN indicates the PLMN ID of the anchor SMF. NOTE 8: Usage of Charging ID with Uint32 value for roaming scenarios may lead to Charging ID collision between SMFs. * * * Next Change * * * * Table 6.1.6.2.7-1: Definition of type SmContextRetrieveData Attribute name Data type P Cardi Description Applica nality bility targetMmeCap MmeCapabilities C 0..1 This IE shall be present if it is available. When present, it shall contain the target MME capabilities. smContextType SmContextType C 0..1 This IE shall be present if this is a request to retrieve DTSSA, the complete SM context, during scenarios with an I- CTXTR SMF or V-SMF insertion / change / removal, or during SMF Context Transfer procedure for LBO or non- roaming PDU session without I-SMF (see clause 4.26.5.3 of 3GPP TS 23.502 [3]). This IE shall also be present if this is a request to EnEDGE Applicant’s Ref. P109419WO2 retrieve the AF Coordination Information during the change of SSC mode 3 PDU Session Anchor with multiple PDU Sessions, if the runtime coordination between old SMF and AF is enabled (see clause 4.3.5.2 of 3GPP TS 23.502 [3]). servingNetwork PlmnId C 0..1 This IE shall be present when the procedure is DTSSA triggered by a new V-SMF, if the new V-SMF supports inter-PLMN V-SMF change or insertion. This IE shall also be present during the procedure with an I-SMF insertion. When present, this IE shall contain the serving core network operator PLMN ID of the NF Service Consumer (i.e. new V-SMF or new I-SMF). notToTransferEbiList array(EpsBearerId) C 1..N This IE shall be present, if the SM context type IE is absent or indicate a request to retrieve the EPS PDN connection, and the AMF determines that certain EPS bearers shall not to be transferred to EPS during a 5GS to EPS mobility procedure, as specified in clause 4.11.1 of 3GPP TS 23.502 [3]. When present, it shall contain the EBI list not to be transferred. ranUnchangedInd boolean C 0..1 This IE shall be present if AN Tunnel is required, in DTSSA scenario of I-SMF / V-SMF change / insertion during registration procedure after EPS to 5GS handover or I-SMF selection per DNAI, when UE is in CM- CONNECTED state (see clause 5.2.2.6.1). When present, it shall be set as follows: - true: NG-RAN is not changed and the tunnel information is required; - false (default):NG-RAN is changed and the tunnel information is not required. * * * Next Change * * * * A.2 Nsmf_PDUSession API openapi: 3.0.0********************** Text Skipped for Clarity ************************* # # STRUCTURED DATA TYPES # SmContextCreateData: description: Data within Create SM Context Request type: object properties: supi: $ref: 'TS29571_CommonData.yaml# / components / schemas / Supi' unauthenticatedSupi: type: boolean Applicant’s Ref. P109419WO2 Applicant’s Ref. P109419WO2 ueEpsPdnConnection: $ref: '# / components / schemas / EpsPdnCnxContainer' hoState: $ref: '# / components / schemas / HoState' pcfId: $ref: 'TS29571_CommonData.yaml# / components / schemas / NfInstanceId' pcfGroupId: $ref: 'TS29571_CommonData.yaml# / components / schemas / NfGroupId' pcfSetId: $ref: 'TS29571_CommonData.yaml# / components / schemas / NfSetId' nrfUri: $ref: 'TS29571_CommonData.yaml# / components / schemas / Uri' supportedFeatures: $ref: 'TS29571_CommonData.yaml# / components / schemas / SupportedFeatures' selMode: $ref: '# / components / schemas / DnnSelectionMode' backupAmfInfo: type: array items: $ref: 'TS29571_CommonData.yaml# / components / schemas / BackupAmfInfo'minItems: 1 traceData: $ref: 'TS29571_CommonData.yaml# / components / schemas / TraceData' udmGroupId: $ref: 'TS29571_CommonData.yaml# / components / schemas / NfGroupId' routingIndicator: type: string hNwPubKeyId: type: integer epsInterworkingInd: $ref: '# / components / schemas / EpsInterworkingIndication' indirectForwardingFlag: type: boolean directForwardingFlag: type: booleantargetId: $ref: 'TS29518_Namf_Communication.yaml# / components / schemas / NgRanTargetId' epsBearerCtxStatus: $ref: '# / components / schemas / EpsBearerContextStatus' cpCiotEnabled: type: boolean default: false cpOnlyInd: type: boolean default: false invokeNef: type: boolean default: false maRequestInd: type: booleandefault: false maNwUpgradeInd: type: boolean default: false n2SmInfo: $ref: 'TS29571_CommonData.yaml# / components / schemas / RefToBinaryData' n2SmInfoType: $ref: '# / components / schemas / N2SmInfoType' n2SmInfoExt1: $ref: 'TS29571_CommonData.yaml# / components / schemas / RefToBinaryData' n2SmInfoTypeExt1: $ref: '# / components / schemas / N2SmInfoType' smContextRef: $ref: 'TS29571_CommonData.yaml# / components / schemas / Uri'smContextSmfPlmnId:$ref: 'TS29571_CommonData.yaml# / components / schemas / PlmnIdNid' smContextSmfId: $ref: 'TS29571_CommonData.yaml# / components / schemas / NfInstanceId' smContextSmfSetId: $ref: 'TS29571_CommonData.yaml# / components / schemas / NfSetId' smContextSmfServiceSetId: $ref: 'TS29571_CommonData.yaml# / components / schemas / NfServiceSetId' smContextSmfBinding: $ref: 'TS29518_Namf_Communication.yaml# / components / schemas / SbiBindingLevel' upCnxState: $ref: '# / components / schemas / UpCnxState' smallDataRateStatus: $ref: 'TS29571_CommonData.yaml# / components / schemas / SmallDataRateStatus' Applicant’s Ref. P109419WO2 localBreakout type: boolean Applicant’s Ref. P109419WO2 default: false required: - servingNfId - servingNetwork - anType - smContextStatusUri ******************** Text Skipped for Clarity *********************** HsmfUpdateData: description: Data within Update Request towards H-SMF, or from I-SMF to SMF type: object properties: requestIndication: $ref: '# / components / schemas / RequestIndication' pei: $ref: 'TS29571_CommonData.yaml# / components / schemas / Pei' vcnTunnelInfo: $ref: '# / components / schemas / TunnelInfo' icnTunnelInfo: $ref: '# / components / schemas / TunnelInfo' additionalCnTunnelInfo: $ref: '# / components / schemas / TunnelInfo' servingNetwork: $ref: 'TS29571_CommonData.yaml# / components / schemas / PlmnIdNid' anType: $ref: 'TS29571_CommonData.yaml# / components / schemas / AccessType' additionalAnType: $ref: 'TS29571_CommonData.yaml# / components / schemas / AccessType' ratType: $ref: 'TS29571_CommonData.yaml# / components / schemas / RatType' ueLocation: $ref: 'TS29571_CommonData.yaml# / components / schemas / UserLocation' ueTimeZone: $ref: 'TS29571_CommonData.yaml# / components / schemas / TimeZone' addUeLocation: $ref: 'TS29571_CommonData.yaml# / components / schemas / UserLocation' pauseCharging: type: boolean pti: $ref: '# / components / schemas / ProcedureTransactionId' n1SmInfoFromUe: $ref: 'TS29571_CommonData.yaml# / components / schemas / RefToBinaryData'unknownN1SmInfo: $ref: 'TS29571_CommonData.yaml# / components / schemas / RefToBinaryData' qosFlowsRelNotifyList: type: array items: $ref: '# / components / schemas / QosFlowItem' minItems: 1 qosFlowsVsmfRejectedList: type: array items: $ref: 'TS29571_CommonData.yaml# / components / schemas / Qfi' minItems: 1 qosFlowsNotifyList: type: array items:$ref: '# / components / schemas / QosFlowNotifyItem' minItems: 1 NotifyList: type: array items: $ref: '# / components / schemas / PduSessionNotifyItem' minItems: 1 # The attribute name does not follow the naming conventions specified in 3GPP TS 29.501. The attribute name is kept though as defined in the current specification for backward compatibility reason. epsBearerId: type: array items: $ref: '# / components / schemas / EpsBearerId' minItems: 0hoPreparationIndication: type: boolean Applicant’s Ref. P109419WO2 Applicant’s Ref. P109419WO2 ********************** Text Skipped for Clarity ************************* * * * End of Changes * * * *

Claims

Applicant’s Ref. P109419WO2 Claims What is claimed is:

1. A method (800) at a first network node (135, 135-3) for identifying a Protocol Data Unit (PDU) session or a Packet Data Network (PDN) connection with Local Breakout (LBO), the method (800) comprising: receiving (S303, S404, S514a, S602, S703, S810), from a second network node (130, 130-1, 130-2, 235-C), a first message for creating a Session Management (SM) context for a PDU session or a PDN connection; and determining (S820) whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO based on at least the first message.

2. The method (800) of claim 1, wherein the step of determining (S820) whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO comprises at least one of: determining that the PDU session or the PDN connection is a PDU session or a PDN connection with LBO in response to the first message indicating that the PDU session or the PDN connection is a PDU session or a PDN connection with LBO; determining that the PDU session or the PDN connection is not a PDU session or a PDN connection with LBO in response to the first message indicating that the PDU session or the PDN connection is not a PDU session or a PDN connection with LBO; and determining that the PDU session or the PDN connection is not a PDU session or a PDN connection with LBO in response to the first message not indicating whether or not the PDU session or the PDN connection is a PDU session with LBO or a PDN connection with LBO.

3. The method (800) of claim 1 or 2, wherein the PDU session or the PDN connection is used for emergency services.

4. The method (800) of any of claims 1 to 3, wherein the PDU session or the PDN connection is associated with a roaming User Equipment (UE) (100).

5. The method (800) of any of claims 1 to 4, further comprising: preventing (S316c, S725) the PDU session or the PDN connection from being registered by the first network node (135, 135-3) in a Unified Data Management (UDM) (170) in response to determining that the PDU session or the PDN connection is a PDU session or a PDN connection with LBO.

6. The method (800) of any of claims 1 to 5, wherein the first message is associated with at least one of: - a PDU Session Establishment procedure; - an Evolved Packet System (EPS) to 5thGeneration System (5GS) handover procedure; - an EPS to 5GS Mobility Registration procedure;Applicant’s Ref. P109419WO2 - an EPS / evolved Packet Data Gateway (ePDG) to 5GS handover procedure; and - an Evolved-Universal Terrestrial Radio Access Network (E-UTRAN) Initial Attach procedure.

7. The method (800) of any of claims 1 to 6, wherein the first network node (135, 135-3) is a Session Management Function (SMF) or an SMF + PDN Gateway Control plane (PGW-C), wherein the second network node (130, 130-1, 130-2, 235-C) is an Access and Mobility Management Function (AMF) or a Serving Gateway Control plane (SGW-C).

8. The method (800) of claim 7, wherein the first message is an Nsmf_PDUSession_CreateSMContext Request message or a Create Session Request message.

9. A first network node (135, 135-3, 1000, 1100) for identifying a PDU session or a PDN connection with LBO, the first network node (135, 135-3, 1000, 1100) comprising: a processor (1006); a memory (1008) storing instructions which, when executed by the processor (1006), cause the first network node (135, 135-3, 1000, 1100) to: receive, from a second network node (130, 130-1, 130-2, 235-C), a first message for creating an SM context for a PDU session or a PDN connection; and determine whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO based on at least the first message.

10. The first network node (135, 135-3, 1000, 1100) of claim 9, wherein the instructions, when executed by the processor (1006), cause the first network node (135, 135-3, 1000, 1100) further to perform the method (800) of any of claims 2 to 8.

11. A method (900) at a second network node (130, 130-1, 130-2, 235-C) for facilitating a first network node (135, 135-3) in identifying a PDU session or a PDN connection with LBO, the method (900) comprising: transmitting (S303, S404, S514a, S602, S703, S910), to a first network node (135, 135-3), a first message for creating an SM context for a PDU session or a PDN connection, the first message indicating whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO.

12. The method (900) of claim 11, wherein the PDU session or the PDN connection is used for emergency services.

13. The method (900) of claim 11 or 12, wherein the PDU session or the PDN connection is associated with a roaming UE (100).Applicant’s Ref. P109419WO2 14. The method (900) of any of claims 11 to 13, wherein the first message is associated with at least one of: - a PDU Session Establishment procedure; - an EPS to 5GS handover procedure; - an EPS to 5GS Mobility Registration procedure; - an EPS / ePDG to 5GS handover procedure; and - an E-UTRAN Initial Attach procedure.

15. The method (900) of any of claims 11 to 14, wherein the first network node (135, 135-3) is an SMF or an SMF + PGW-C, wherein the second network node (130, 130-1, 130-2, 235-C) is an AMF or an SGW-C.

16. The method (900) of claim 15, wherein the first message is an Nsmf_PDUSession_CreateSMContext Request message or a Create Session Request message.

17. A second network node (130, 130-1, 130-2, 235-C, 1000, 1200) for facilitating a first network node (135, 135-3) in identifying a PDU session or a PDN connection with LBO, the second network node (130, 130-1, 130-2, 235-C, 1000, 1200) comprising: a processor (1006); a memory (1008) storing instructions which, when executed by the processor (1006), cause the second network node (130, 130-1, 130-2, 235-C, 1000, 1200) to: transmit, to a first network node (135, 135-3), a first message for creating an SM context for a PDU session or a PDN connection, the first message indicating whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO.

18. The second network node (130, 130-1, 130-2, 235-C, 1000, 1200) of claim 17, wherein the instructions, when executed by the processor (1006), cause the second network node (130, 130-1, 130-2, 235-C, 1000, 1200) further to perform the method (900) of any of claims 12 to 16.

19. A computer program (1010) comprising instructions which, when executed by at least one processor (1006), cause the at least one processor (1006) to carry out the method (800, 900) of any of claims 1 to 8 and 11 to 16.

20. A carrier (1008) containing the computer program (1010) of claim 19, wherein the carrier (1008) is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

21. A telecommunication system (10, 20), comprising: a second network node (130, 130-1, 130-2, 235-C) comprising: a processor;Applicant’s Ref. P109419WO2 a memory storing instructions which, when executed by the processor, cause the second network node (130, 130-1, 130-2, 235-C) to: transmit, to a first network node (135, 135-3), a first message for creating an SM context for a PDU session or a PDN connection, the first message indicating whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO, the first network node (135, 135-3) comprising: a processor; a memory storing instructions which, when executed by the processor, cause the first network node (135, 135-3) to: receive, from the second network node (130, 130-1, 130-2, 235-C), the first message for creating an SM context for a PDU session or a PDN connection; and determine whether or not the PDU session or the PDN connection is a PDU session or a PDN connection with LBO based on at least the first message.

22. The telecommunication system (10, 20) of claim 20, wherein the instructions stored in the memory of the first network node (135, 135-3), when executed by the processor of the first network node (135, 135-3), cause the first network node (135, 135-3) further to perform the method (800) of any of claims 2 to 8.

23. The telecommunication system (10, 20) of claim 20 or 21, wherein the instructions stored in the memory of the second network node (130, 130-1, 130-2, 235-C), when executed by the processor of the second network node (130, 130-1, 130-2, 235-C), cause the second network node (130, 130-1, 130-2, 235-C) further to perform the method (900) of any of claims 12 to 16.

Images