Method for activating or deactivating each session user plane connection

Abstract

The present invention relates to a method of per-session user plane connection activation or deactivation. The present disclosure provides a user equipment (UE) comprising a transmitter configured to send, to a mobility management function (MMF) via an access network (AN) node, at least one protocol data unit (PDU) session identifier (ID) in a non-access stratum (NAS) service request message when the UE has user data to send, each PDU session ID indicating a PDU session that the UE needs to use.

Description

[0001] This application is a divisional application of Chinese invention patent application "Method for Activating or Deactivating Plane Connections for Each Session User", which entered the Chinese national phase on February 18, 2019, with PCT application number PCT / JP2017 / 029618, international filing date of August 18, 2017, and Chinese application number 201780050571.8. Technical Field

[0002] This disclosure relates to communication systems. This disclosure particularly, but not exclusively, relates to wireless communication systems and apparatus thereof operating under 3GPP standards, or their equivalents or derivatives. This disclosure particularly, but not exclusively, relates to so-called "next-generation" systems. Background Technology

[0003] This disclosure includes a method for independently activating or deactivating user plane connectivity for each Protocol Data Unit (PDU) session or network slice, wherein session contexts (e.g., Session Management Function (SMF) and User Plane Function (UPF)) have been established in the User Equipment (UE) and in the network. The scheme proposes a Session Management (SM) state machine for each established PDU session, wherein the state machine is maintained within the SMF or Mobility Management Function (MMF) network function. The SM state machine operates independently of the Mobility Management (MM) state machine.

[0004] Overview

[0005] The following terms are used in this document and can be applied to any generation of mobile networks, such as 2G (Global System for Mobile Communications (GSM)), 3G (Universal Mobile Telecommunications System (UMTS)), 4G (Long Term Evolution (LTE), Evolved Packet Core (EPC)), 5G (New Radio (NR) / NextGen), etc. For example, if “UE” or “serving node” is mentioned in the following description, it can refer to any generation of UE or serving node.

[0006] Typically, the terms "Serving Node," "Mobility Management Entity (MME) / Serving General Packet Radio Service (GPRS) Support Node (SGSN)," "Mobile Switching Center (MSC) / SGSN / MME," or "Cellular Internet of Things (CIoT) Serving Gateway Node (C-SGN)" are used, through various embodiments of this document, to describe functional entities such as the MSC, SGSN, MME, C-SGN, or other possible control plane functional entities in the mobile network that terminate control plane signaling (referred to as Non-Access Stratum (NAS) signaling) between the core network and the terminal. The Serving Node (MME / SGSN) can also be a functional entity from a next-generation network responsible for mobility and session management.

[0007] The term Home Subscriber Server (HSS) / Home Location Register (HLR) refers to a repository that stores the UE's subscription data and can be an HSS, an HLR, or a combination thereof. The terms Next Generation User Data Management (UDM), Subscriber Database Management (SDM), or Authentication, Authorization, and Accounting (AAA) can also be used synonymously for HSS.

[0008] Functional entities or network functions used as separate entities in this document may also be co-located, or more finely separated in a specific deployment, or as illustrated in the architecture diagram.

[0009] The terms “terminal,” “device,” “user terminal,” “user equipment (UE),” or “mobile terminal (MT)” are used interchangeably, wherein all terms similarly express a device for sending / receiving data and signaling from a network, mobile network, or radio access network.

[0010] The term "session" is used in the same sense as "PDU session," "Packet Data Network (PDN) connection," "Access Point Name (APN) connection," or "connection to a specific network slice." An existing session is one in which a UE context already exists (has been established) in the core network control plane and / or user plane, as well as within the UE itself. "Existing session" has the same meaning as "established PDU session" or "established PDN connection." Each session can be identified by a "session ID," which can be similar to an "Evolved Packet System (EPS) Bearer ID," "APN," "slice ID," "slice instance ID," "service ID," or any other temporary or permanent identifier for a PDN connection, PDU session, or service used by the UE.

[0011] The term "connection" is primarily used for user plane connections, where a "path" is established to transmit uplink (UL) or downlink (DL) data between the UE and the user plane gateway (GW) terminating the PDU session. Depending on the context, a connection can be the entire user plane path for a PDU session; or it can simply be a connection via a given interface, such as a connection via a radio interface, or a connection via an NG3 interface (between the UPF and the (radio)access network ((R)AN) in the next-generation core network (NG CN)).

[0012] Use the following terminology for the process:

[0013] - Session establishment: For example, PDU session establishment, where an SM context exists (established) in the UE and in the NG CN control plane and / or user plane.

[0014] - Session Release: Delete the PDU session, which means deleting (releasing) the SM context in the UE and in the NG CN control plane and / or user plane.

[0015] - Session / Connection Activation: Activates the UP connection path for the session, for which the SM context exists in the UE and in the NG CN.

[0016] - Session / Connection Deactivation: Deactivates the UP connection path without deleting the SM context in the UE and NG CN. In other words, it releases the UP connection.

[0017] The mobility states of a UE are called deregistration, registration standby (abbreviated as "standby"), and registration ready (abbreviated as "ready"). These states are also called MM states. Note that there is a difference between mobility states (MM states) and session states (SM states).

[0018] The telecommunications industry has begun working on a new generation of networks known as fifth-generation (5G) networks. Activities from multiple research and standardization organizations have been initiated to develop 5G networks, which will serve multiple vertical service providers and a wide variety of devices. Specifically, 3GPP activities are being initiated in the RAN area under the term "New Radio" (NR), and in the core network (CN) under the term "NextGen" (NG). Note that these terms are likely to change before 5G systems are brought to market. Therefore, terms such as NG CN (or NG AN) as used in this document have any meaning related to 5GCN or AN technologies.

[0019] 3GPP studies the NG system architecture, and the corresponding problems and solutions are found in 3GPP TR 23.799 [see NPL 1]. Figure 1 The NG architecture for simultaneous access to multiple PDN connections (referred to as PDU sessions in the NG study) is described as follows, as agreed in [see NPL 1] up to the time of writing. Figure 1 The upper section shows an example of the NG Control Plane (NG CP), including Subscriber Database Management (SDM) 22, Policy Control Function (PCF) 24, and Core Control Function (CCF) 26. NG CCF 26 includes Mobility Management Function (MMF) and Session Management Function (SMF), among others. User plane (UP) functions are shown as Core Network User Plane Functions (NG UPF) 28, as each configured PDU session can have one or more UPFs. More information on the description of interfaces and network functions can be found in Section 7.3 of TR 23.799 [see NPL 1].

[0020] A key feature of 5G systems is network slicing. 5G use cases require highly diverse, sometimes extreme, requirements. Current architectures use a relatively monolithic network and transport framework. Therefore, the flexibility and scalability of the current architecture are not expected to be sufficient to effectively support a wider range of service needs. To meet these needs, 5G systems can be "sliced" across multiple network instances, called Network Slice Instances (NSIs). A network slice can be described as a logically separated network where resources (processing, storage, and network resources) used for different network slices are isolated. Network operators use network slice templates / blueprints to create NSIs. NSIs provide the network characteristics required to serve service instances. Figure 2 An example of a network architecture is shown, which allows a UE to connect to multiple NSIs simultaneously, as described in [see NPL 1].

[0021] Figure 2 The diagram illustrates a first network slice type / category (e.g., for IoT services) and a second slice type (e.g., for broadband services). The second network slice type may have multiple NSIs for a specific third-party customer. The diagram illustrates shared (R)AN and the application of network slicing within the NG CN. However, in the future, (R)AN network slicing may also be possible, where RAN resources are sliced / isolated in baseband processing, in the spectrum, or both.

[0022] [NPL 1] also describes Common Control Network Function (CCNF) 32 and Slice-Specific Control Plane Network Function (SCNF), such as Figure 3 Details. CCNF 32 may include basic control plane network functionality to support basic functional operations commonly found in NSI, such as:

[0023] 1. Subscriber Authentication Device

[0024] 2. Mobility management

[0025] 3. Network Slice Instance Selector (NSI Selector)

[0026] 4. NAS routing function, etc.

[0027] Typically, NG systems should be designed to support the transmission of any type of data. Assume the NG system supports the following PDU session types:

[0028] - IP type (e.g., IPv4 or IPv6 or both), or

[0029] - Non-IP sessions (any unstructured data) or

[0030] - Ethernet type.

[0031] Figure 4Another solution is illustrated in section 6.4.3, 23.799. UE 34 can establish multiple PDU sessions to the same data network to meet different connectivity requirements (e.g., session continuity) for different applications that require connection to the same data network. In this solution, the MM function and SM function are separate. Thus, a key concept is that each MM context can use multiple SM contexts. Furthermore, different session continuity types for each PDU session are also possible.

[0032] Reference List

[0033] Non-patent literature

[0034] NPL 1: 3GPP TR 23.799v0.6.0, 2016-07, “Study on Architecture for Next Generation System”

[0035] NPL 2: 3GPP TS 23.401, v14.0.0, 2016-06, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access" Summary of the Invention

[0036] Technical issues

[0037] The scenario considered in this document is that the UE is attached to the network and can be associated with multiple UP-GWs (UPFs). Different UPFs can be (a) part of the same PDU session, (b) part of different PDU sessions, or (3) part of different Network Slice Instances (NSIs). In other words, multiple NG3 connections (e.g., tunnels over NG3 interfaces) between the (R)AN and the UP-GW are available. If the UE has established multiple PDU sessions, then each UE can have multiple Session Management Function (SMF) instances.

[0038] One assumption in this document is that a UE's "session" (or, also referred to as a "PDN connection" or "PDU session" to a specific data network) can be in an idle (inactive) state or an active (connected) state. In this sense, the terms "idle session" or "active session" are used. If the session is in an "idle" state, then no NG3 connection / tunnel is established between the UPF and the (R)AN. If the session is in an "active" state, then an established NG3 connection / tunnel exists between the UPF and the (R)AN. Further assumptions are made that for an established UE session, a Session Management Function (SMF) is instantiated / configured in the control plane, and one or more corresponding UPFs are instantiated / configured in the user plane. More details regarding the IDLE and ACTIVE session states of the Control Plane Function (CPF) and UPF can be found below.

[0039] Assuming that there are NG3 tunnels for transmitting data packets between the AN and multiple UPFs, the problem of establishing, modifying and releasing multiple NG3 tunnels will arise whenever the UE transitions from standby state to ready mobility state.

[0040] In an NG with multiple UPFs, multiple tunnels are established / released on the NG3 interface, compared to an EPC where each UE is configured with a single serving GW, and thus a single S1-U tunnel is established and released during the standby-to-ready transition. Therefore, the problem lies in the increased signaling required for tunnel establishment when using a single UPF (or PDU session), but with the establishment / release of multiple NG3 tunnels.

[0041] Furthermore, if all existing sessions are idle and downlink data for a specific session arrives, there should be a method to synchronize the SM state between the UE and the NG system. Therefore, for MT calls, it is currently not possible for the UE to activate only the single application associated with the session that triggered the MT call.

[0042] Furthermore, as long as the UE is attached / registered to the NG system, the mobility management mechanism can maintain the MM state in the ready state within the NG core network (CN). Thus, the NG CN only has the UE's registration and deregistration mobility states. This MM mechanism primarily benefits paging for fixed or low-mobility devices with relatively narrow paging areas. Through this architecture, the NGCN knows the UE's location, and the NG3 tunnels are always active. This means the session state is always "active." Moreover, this document aims to address potential problems in cases where such devices have another application configured to access simultaneously through different sessions. In this case, the NG CN performs session management, while the (R)AN performs mobility management. As a result, all NG3 connections / tunnels for all sessions are always established; that is, all sessions are always in an active session state. When the UE moves and changes (R)AN nodes, all tunnels need to be updated, meaning the CCNF and SMF need to update all UPFs with new tunnel endpoint information. This leads to an increase in signaling.

[0043] This disclosure attempts to address or at least mitigate the aforementioned issues by reducing the signaling required to establish an NG3 tunnel, thereby allowing a specific session to be activated from multiple existing sessions.

[0044] Solution to the problem

[0045] An exemplary solution of this disclosure is a user equipment (UE), including: a transmitter configured to send at least one Protocol Data Unit (PDU) session identifier (ID) to a Mobility Management Function (MMF) via an Access Network (AN) node in a Non-Access Stratum (NAS) Service Request message when the UE has user data to send, each PDU session ID indicating the PDU session that the UE needs to use. Attached Figure Description

[0046] Figure 1 Describe the NG architecture used for accessing multiple PDN connections (referred to as PDU sessions in NG studies);

[0047] Figure 2 This illustrates an example of a network architecture that allows a UE to connect to multiple NSIs;

[0048] Figure 3 Describe CCNF and SCNF;

[0049] Figure 4 Another solution described in section 6.4.3, 23.799, is shown;

[0050] Figure 5 An exemplary architecture is shown, illustrating multiple network slices or PDU sessions with corresponding multiple CPFs and UPFs;

[0051] Figure 6 It shows multiple session state machines (one for each established session) and a single movement state machine;

[0052] Figure 7 This indicates that two sessions have already been established for the given UE;

[0053] Figure 8 The paging process is illustrated during a Radio Resource Control (RRC) connection establishment request, instructing the UE to provide the session ID for activating a single PDU / PDN session.

[0054] Figure 9 This illustrates a possible solution 2.1 for activating an additional session when another session is already active;

[0055] Figure 10 Another alternative solution 2.2 is shown, in which the NAS SM signaling between SMF2 and UE is used to activate session 2 to UPF2;

[0056] Figure 11 This shows that the UE has two session contexts for session #1 and session #2;

[0057] Figure 12 Describe the situation where two sessions are active and one session becomes idle because there is no user plane activity during the predefined UE inactivity period determined by the (R)AN node;

[0058] Figure 13 Describe an alternative solution in which the session deactivation process is initiated by the corresponding session's UPF;

[0059] Figure 14 It is shown Figure 1 The block diagram of the main components of the UE shown; and

[0060] Figure 15 It is shown Figure 1 The diagram shows the block diagram of the main components of the MMF / SMF node. Detailed Implementation

[0061] To address the aforementioned issues, different solutions are described in various example embodiments.

[0062] Note that the terms "idle" session or "active" session are used for the SM state, while standby and ready states are used for the UE's mobility states. Furthermore, the transition from an idle session state to an active session state can be called "session activation," and the transition from an active session state to an idle session state can be called "session deactivation." This is in... Figure 6 As shown.

[0063] The terms “session activation” or “session deactivation” are related to the establishment or release of NG3 connections / tunnels. These terms differ from the “session establishment” or “session release” procedures related to establishing a new session, which involves establishing an SM context in both the UE and the NG CN or correspondingly deleting an existing session, i.e., deleting the SM context in both the UE and the NG CN.

[0064] For the purposes of this document, it is assumed that Figure 1 Reference architecture for a single established session (network slice or PDU session). For multiple established sessions, assume... Figure 5 As a reference architecture, the UE has established three different sessions, A, B, and C. These different sessions can belong to different network slices, or they can belong to the same network slice but have multiple PDU sessions. In the control plane, there is a box labeled CCNF 32, which is shared between network slices or PDU sessions. These CCNFs can include Mobility Management Network Functions (NFs) (called MMFs), Authentication / Authorization / Security NFs, NAS signaling routing NFs, etc. Figure 5 As shown, each PDU session or network slice can have an independent dedicated CPF. A dedicated CPF may include the following exemplary network functions:

[0065] -SMF: In this document, it is assumed that this function is responsible for session management of a specific session (network slice or PDU session).

[0066] - As the control plane (CP) of the GW, the CPF of the GW (also known as the GW-C of the UPF) is called the S / PGW-CP function from the control / user plane separation in the EPC (called control and user plane separation (CUPS)).

[0067] -PCF: All or part of PCF, such as Figure 1 As shown. This means that some parts of the PCF can be part of CCNF 32, while other parts can be part of a dedicated CPF.

[0068] - Authentication, authorization, and security features associated with specific network slices of a PDU session.

[0069] Notice, Figure 5 The diagram shows UE 34 with three arrows pointing towards (R)AN node 30, representing three radio connections corresponding to three sessions / slices A, B, and C. However, this is just an example. For instance, UE 34 could have three user plane radio connections (one per session) and only one control plane radio connection. Alternatively, UE 34 could have three user plane radio connections and three control plane radio connections (one per session).

[0070] For simplicity, in this document, the term SMF is used to refer to all the dedicated CPFs listed above for PDU sessions or network slices. Each SMF has a signaling association with CCNF 32 for each UE 34. For each established session, CCNF (e.g., MMF) 32 and SMF are aware of each other and can send signaling at any time independent of UE mobility or session state. Furthermore, CCNF 32 and SMF have exchanged UE ID or subscriber ID (temporary or permanent) and use this ID in each signaling message exchange to point to the context of the corresponding UE in CCNF 32 or in SMF.

[0071] Furthermore, a UPF is configured / instantiated for each network slice or PDU session (e.g., a 3GPP-specified GW function for implementing Quality of Service (QoS) or traffic policies). Each of the (NG3) connections A, B, or C can be managed independently, meaning it can be established, modified, or released independently of other connections. Note that there can be one or more UPFs. For example, a UPF closer to the edge can be used as a mobility anchor, and a UPF deeper within the CN can be used as an IP anchor (the IP address of the hosting UE). For simplicity, a single UPF is used in this document. However, if multiple UPFs are required and multiple UPFs are instantiated / configured for a given session, the SMF can configure multiple UPFs.

[0072] like Figure 5 As illustrated in the example, assume there are three connections (e.g., tunnels over NG3) between the (R)AN and UPF: a single connection for slice / session A 36, slice / session B 38, and slice / session C 40. If each UE 34 between the (R)AN and UPF A / B / C 36 / 38 / 40 uses tunnels over NG3, then three tunnels will be activated / modified / released whenever UE 34 transitions between standby and ready mobility states. Worse still, if the tunnels over NG3 are per IP flow or per bearer, even more tunnels need to be activated / modified / released for each standby and ready mobility state transition.

[0073] Figure 5 The diagram shows that for session C, a private CPF may include an SMF and a PCF. Note that the presence of a PCF within a private CPF can be based on specific use cases; for example, for some network slices, a PCF may be instantiated / configured for each slice, while for other network slices, the PCF may be instantiated / configured as a public CPNF.

[0074] This paper proposes a system architecture that allows for the activation / deactivation of a single session in the presence of multiple existing / established PDU sessions (or simultaneous connections to multiple network slices). This means: 1) activating the session state in the corresponding CPF (e.g., SMF); and 2) activating a single UP session by establishing a corresponding connection / tunnel between the (R)AN node 30 and the UPF. If no data is transmitted in the uplink or downlink (UL or DL), other UP sessions are not activated (for other PDU sessions or other network slices) (i.e., they are in an idle state).

[0075] like Figure 6 As shown, each existing session (i.e., each network slice or PDU session) has multiple independent session state machines. This is shown as Session A state machine and Session B state machine. These session state machines can be applied to both UE 34 and NG CN. During UE session establishment, the SMF entity is selected and configured by the CCNF (MMF). The SMF entity begins maintaining the UE's context associated with that session. For example, the UE session context in the SMF may contain parameters such as:

[0076] -UE temporary or permanent ID, corresponding session ID;

[0077] - Session type (e.g., IPv4 / IPv6, non-IP, Ethernet);

[0078] - Session continuity and / or service continuity modes (e.g., Session and Service Continuity (SSC) modes 1 / 2 / 3);

[0079] - QoS parameters (e.g., non-guaranteed bit rate (non-GBR), GBR parameters, maximum session bit rate);

[0080] - Strategy parameters;

[0081] - Required session subscription parameters;

[0082] - Session state machine, etc.

[0083] In other words, independent of the state (active or idle) of the session state machine in the SMF, the SMF maintains the UE's session context, as shown by the parameters listed above.

[0084] Furthermore, if UE 34 is in a permanently ready mobility state from the perspective of the NG CN, this could result in a permanently active connection / tunnel on the NG3 interface and correspondingly, a session in a permanently active session state in the NG CN. The session (SM) state machine can then be managed in the (R)AN or in the NG CN.

[0085] For example, a transition from idle to active session state occurs if 1) data transmitted in the UL or DL ​​is available, or 2) scheduled session activation is configured in the SMF. In the active session state, the SMF knows the UE's current location based on the (R)AN node UP details used for data forwarding. Correspondingly, the UPF has established a connection with the (R)AN node 30 via the NG3 interface and enforces policies and QoS parameters for a given session in the UPF. If there is no data in the UL or DL ​​or if maintaining a user plane connection for a specific session is not required, the (R)AN node 30 or the UPF can trigger a transition to the idle session state. Note that UP connection deactivation differs from session release because the UE's context remains in the NG CN (e.g., the SMF) during connection deactivation. In the idle session state, the UPF does not have a connection established via the NG3 interface, and the SMF is unaware of the (R)AN node UP details and the accurate MM mobility state (i.e., registered standby or ready).

[0086] When the SMF used for a given session (e.g., SMF-A) is idle, in the CP, the SMF is unaware of the (R)AN node UP details, such as IP address, tunnel identifier, transport port ID, or other parameters. The SMF does have context about the UE for that session, including QoS parameters, policy parameters (e.g., charging policies or application detection policies), or required session subscription parameters, etc. In the UP, the UPF has no connection to the (R)AN node 30 (e.g., no established tunnel).

[0087] On the other hand, if the SM instance is active, the SMF (e.g., SMF-A) in the CP knows the details of the (R)AN node, such as the IP address, tunnel identifier, transport port ID, or other parameters. In the UP, the UPF has an established connection / tunnel to the (R)AN node 30.

[0088] This document focuses on the procedures for activating and deactivating sessions (i.e., activating / deactivating UP connections), which differ from the procedures for establishing new sessions or releasing existing sessions. For example, establishing a new session means establishing the UE's SM session context in the SMF, the session context within the UE 34 itself, and the corresponding NAS SM message exchange between the UE 34 and the SMF. It is assumed that for each established session, the SMF and MMF 32 maintain signaling associations for exchanging session-related signaling.

[0089] In another example, releasing an existing session means deleting the SM context in the SMF, the UPF, and the UE. For example, if UE 34 is decoupled from the network, i.e., its MM state is deregistered, then MMF 32 triggers the session release procedure, which is also outside the scope of this document.

[0090] This document proposes that the CCNF (e.g., MMF) 32 maintains the UE's context, possessing knowledge about the session (SM) state in the SMFs (multiple). In other words, the MMF 32 knows the session state (idle or active) of all configured SMFs (multiple) for established sessions. Besides the mobility (MM) context, the MMF 32 also maintains information about all established sessions. For example, the MMF 32 needs to know whether session A is active, i.e., whether SMF-A is active, so that whenever the (R)AN node changes, the MMF 32 can update the SMF with the new (R)AN node details (e.g., IP address, tunnel identifier, transport port ID, or other parameters). On the other hand, if session A is deactivated, i.e., SMF-A is idle, then the MMF 32 does not need to update the SMF when the (R)AN node changes. In an alternative, this could also be maintained only in the MMF 32 or in both the MMF 32 and the SMF. Figure 6 The session status is shown.

[0091] For this purpose, signaling exchange between SMF and MMF 32 can be based on various alternatives:

[0092] Direct / explicit signaling (in both directions) between the SMF and MMF 32 is used to exchange information about the current session state. Whenever the session state changes, the SMF can notify the MMF 32 of the session state. If the MMF 32 knows that a particular session is active, it will notify the corresponding SMF of (R)AN node changes, other Radio Access Technology (RAT) events (e.g., RAT changes), and other possible mobility events. Furthermore, during an active session, the SMF can notify the MMF 32 of events such as UPF changes due to load balancing or other events that may cause the UPF used for that session to change.

[0093] - Alternatively, there may be no explicit signaling required to notify of a change in session state between the SMF and MMF 32, because the MMF32 can derive the session state based on the NAS signaling between the UE 34 and the SMF.

[0094] Typically, the SMF does not need to maintain the current MM state information. For example, if a particular session is idle, the SMF does not need to know whether UE 34 has changed from a ready-to-mobile state to a standby-mobile state due to the transmission of UL or DL ​​data for other sessions. Conversely, if the session is active, the corresponding SMF needs to know the (R)AN node details (UP details, such as IP address and / or tunnel endpoint ID), other RAT events (RAT changes), and the change from ready to standby MM state. The latter event of the change from ready to standby MM state will cause the SMF to trigger a UPF to disable the NG3 connection / tunnel.

[0095] Assuming session states (idle, active) are maintained in UE 34 and SMF, direct signaling exchange between UE 34 and SMF is advantageous. This signaling exchange is based on NAS SM signaling enhanced by additional parameters such as session ID or indications for UP connection activation or deactivation.

[0096] Several procedures are described below to account for various triggering sources to cover session activation and deactivation.

[0097] Solution 1: Session activation when no other active session exists (e.g., UE is in standby MM state)

[0098] The solution described here addresses a scenario where multiple sessions have been established (e.g., towards different network slices or different PDU sessions) and UE 34 is in a standby mobility state. This means all sessions are in an idle session state. If downlink data arrives for a given session, the proposed solution here only allows activation of that specific session or another session (or multiple sessions), while other existing sessions remain idle.

[0099] Solution 1.1: Indicate the session ID to the UE during the paging process.

[0100] In particular, Figure 7 This shows that two sessions have been established for a given UE 34. This means that UE 34 has an IP configuration for each session and can send and receive data on each session. When UE 34 is in a standby mobility state (shown as CCNF 32 in standby state), the corresponding session #1 state (represented by SMF1 42 in CP) and session #2 state (represented by SMF2 44 in CP) are also in an idle state. In the UP, UPF146 and UPF2 48 have UE-related context (e.g., policies are implemented for the configured IP address of the UE and its association with the corresponding CPF (e.g., SMF), but there is no connection / tunnel to any (R) node 30 to transmit packets.

[0101] Figure 7 The steps are detailed below:

[0102] Step (1) Downlink data arrives at UPF2 48. When session #2 is idle, UPF2 48 has no established connections / tunnels to any (R)AN node 30. Assume there is an NG4 session established for a given UE 34 between the CPF and UPF. Therefore, UPF2 48 requests the CPF (e.g., SMF2 44) corresponding to that session to initiate session activation.

[0103] Step (2) UPF2 48 initiates the process for activating the user plane connection (e.g., NG3 tunnel) toward (R)AN. UPF2 48 sends an activation session request to SMF2 44. This message may also be referred to as a session creation request, an NG3 / UP session request, or any other message similar to the corresponding Sx interface-related message specified in TS 23.214. The activation session request may include one or more of the following information elements: UE temporary or permanent identifier, session identifier, DL packet buffer indication, and other parameters.

[0104] Step (3) SMF2 44 receives the request from UPF2 48 and verifies the message, as well as determining the context of the corresponding UE and the sessions (multiple) to be activated. SMF2 44 sends an activation session request to CCNF (e.g., MMF) 32. Similar to step (2), this message may be referred to as a session creation request (or NG3 / UP session request) in different ways, as long as the message is used for the purpose of activating / establishing a UP connection between (R)AN node 30 and UPF. The message may also be referred to as a session activation request or any other request indicating the activation of an existing PDN (PDU / bearer) context. The request from SMF2 44 may include UE ID (multiple), session ID, UPF ID (required for NG3 tunnel establishment, such as IP address, tunnel endpoint ID, and / or transport layer port ID), required QoS indication, optional security key, and other parameters. Whether the activation session request may include user packets to be buffered depends on the power saving mode. SMF2 44 determines whether another UPF served by the same SMF2 44 already has an active session. If this is not the case, then when necessary, SMF2 44 requests the associated CCNF (e.g., MMF) 32 to perform a session activation procedure toward (R)AN.

[0105] In cases where different levels of security are required for a specific UP session, a security key can be used, and the key is stored in the SMF.

[0106] Step (4) CCNF (e.g., MMF) 32 determines whether UE 34 is in a standby or ready-to-move state. In this example, because UE 34 is in a standby state, for example, it does not know the (R)AN location, so CCNF 32 initiates a paging procedure.

[0107] Step (5) CCNF 32 sends a paging request to the possible (R)AN node 30 where UE 34 is camped. In this paging message, CCNF 32 includes one or more session IDs. The session ID(s) can be any of the APN, slice ID, slice instance ID, or service ID. CCNF 32 includes multiple session IDs based on subscriber data already obtained from HSS in CCNF 32. The additional session ID(s) can be related to the original session ID or completely independent of the original session ID, which corresponds to SMF2 44 in this procedure.

[0108] Step (6) (R)AN node 30 performs a paging process via radio interface, including the session ID received in step (5).

[0109] In step (7), after UE 34 receives the paging message, UE 34 establishes a radio connection with (R)AN node 30 and sends a NAS service request message to CCNF 32 via NG1. Both the radio connection establishment message and the NAS service request message may include one or more session IDs. The UE radio layer(s) indicate the service, application, or existing PDN / APN / PDU / bearer context corresponding to this explicit session to be activated via an internal application programming interface (API). This internal cross-layer exchange in UE 34 can be performed in step (7) or after step (9).

[0110] UE 34 can include a session ID in the NAS service request message to indicate to the MMF (as part of CCNF 32) that the session ID(s) has been successfully processed in UE 34. Note that CCNF 32 can have front-end functionality for NAS signaling, so NAS service request messages arriving at the front-end can be internally forwarded to the correct MMF for further processing. If the session ID(s) are missing in the service request message, this can be an implicit indication that UE 34 cannot process the session ID(s) from the paging message.

[0111] Step (8) CCNF (e.g., MMF) 32 determines that the (associated) NAS service request message is a result of the paging process. CCNF 32 determines that only the session requested by SMF2 44 needs to be activated. CCNF 32 generates the corresponding UE context setting request message and sends it to (R)AN node 30. In addition to other UE parameters such as required QoS indications and security parameters, the UE context setting request message also contains a session ID parameter. When multiple sessions need to be activated, step (8) can be performed session by session, or all requested sessions can be activated at once in one procedure.

[0112] Step (9) (R)AN node 30 performs radio connection reconfiguration, shown in the figures as Radio Resource Control (RRC) connection reconfiguration. During this process, (R)AN node 30 indicates the session ID parameters to UE 34.

[0113] Based on the received session ID, UE 34 can activate the corresponding service, application, or existing PDN / APN / PDU / bearer context. UE 34 does not activate all existing PDN / APN / PDU / bearer contexts. UE 34 updates the SM state in UE 34, which corresponds to the session ID (multiple) received in step (6).

[0114] Step (10) (R)AN node 30 responds to the request in step (8) regarding the establishment of a radio connection. (R)AN node 30, for example, sends a UE context setting response message. The response can be positive or negative. The UE context setting response message includes the UP identifier (IP address and tunnel endpoint ID and / or transport layer port ID) of (R)AN node 30, shown in the figures as the (R)AN UPF ID. In step (5), if CCNF 32 decides to add an additional session ID, CCNF 32 initiates a session (multiple) toward the associated UPF for each additional session. CCNF 32 notifies all associated UPFs (multiple) of the UP identifier of (R)AN node 30, shown in the figures as the (R)AN UPF ID, via the associated SMFs (multiple).

[0115] Step (11) CCNF 32 responds to the SMF2 44 corresponding to the request in step (3). For example, CCNF 32 sends an activation session response message, which may contain an indication of whether the session corresponding to the session ID was successfully or unsuccessfully activated. In addition to other UE parameters such as the required QoS indication (or modified QoS parameters) and security parameters, this message also includes the session ID parameter.

[0116] SMF2 44 exports the policies and QoS parameters to be implemented in UPF2 48.

[0117] SMF2 44 transitions from an idle session state to an active session state.

[0118] Step (12) SMF2 44 responds to the procedure of step (2). SMF2 44 establishes or modifies the required UE context in UPF2 48 by sending an Activate Session Response message. This message may include parameters for policy enforcement (e.g., traffic QoS indication, traffic gating behavior, maximum session bit rate), (R)AN UPF ID (including (R)AN node IP address, tunnel endpoint ID, and / or transport layer port ID), billing-related configurations (e.g., for billing data record (CDR) generation and / or online / offline billing session establishment), security parameters (optional), etc.

[0119] Note that security parameters are required when terminating security at a CN UPF node such as UPF2 48. Security parameters are not required at (R)AN node 30 when terminating security.

[0120] Steps (13) to (15): If the UPF information for NG3 connection / tunnel establishment has not been exchanged during step (3), UPF2 48 may optionally initiate an update session procedure toward SMF2 44 to update UP connection information called the UPF ID (e.g., IP address, tunnel endpoint ID, and / or transport layer port ID). Alternatively, SMF2 44 itself may have such NG3-related UP information, allowing SMF2 44 to initiate an update session procedure toward CCNF (e.g., MMF) 32 (by sending a session update request message including the UPF ID). Finally, CCNF (e.g., MMF) 32 updates (R)AN node 30 with the UPF ID.

[0121] Solution 1.2: Indicate the session ID to the UE during the service request or the corresponding RRC establishment process.

[0122] Figure 8 An alternative solution is shown, in which the paging process is enhanced to include the session ID parameter in the paging request message.

[0123] Figure 8 The diagram illustrates the instruction of a paging procedure to UE 34 during the RRC connection establishment process, wherein the paging message does not include a session ID, but instead includes a session ID used to activate a single PDU / PDN session. Only steps (5) through (9) are described in detail below, as the remaining steps are similar. Figure 7 .

[0124] Step (5) CCNF 32 sends a paging request to the possible (R)AN node 30 where UE 34 is camped. The paging request message does not include the session ID parameter, which is used to indicate to UE 34 which session should be activated.

[0125] Step (6) (R)AN node 30 performs a paging process via the radio interface. According to step (5), this message does not include a session ID.

[0126] Step (7) After UE 34 receives the paging message, UE 34 establishes a radio connection with (R)AN node 30 and sends a NAS service request message to CCNF 32 via NG1.

[0127] Step (8) CCNF 32 determines that the (associated) NAS service request message is a result of the paging process. CCNF 32 determines that only the session requested by SMF2 44 in step (3) needs to be activated. CCNF (e.g., MMF) 32 changes the UE mobility state from standby to ready.

[0128] CCNF 32 generates the corresponding UE context setting request message and sends it to (R)AN node 30. In addition to other UE parameters such as QoS and security parameters, the UE context setting request message also contains session ID parameters. When multiple sessions need to be activated, this step (8) can be performed session by session, or all requested sessions can be activated at once in one process (e.g., by including a list of all session IDs and corresponding parameters).

[0129] Step (9) (R)AN node 30 performs radio connection reconfiguration, shown in the attached figure as RRC connection reconfiguration. During this process, (R)AN node 30 indicates the session ID parameter of the session to be activated to the UE.

[0130] Based on the received session ID, UE 34 can activate the corresponding service, application, or existing PDN / APN / PDU / bearer context. UE 34 does not activate all existing PDN / APN / PDU / bearer contexts, but only the indicated PDN / APN / PDU / bearer context. UE 34 updates its session / SM state (multiple) corresponding to the session ID (multiple) received in step (9).

[0131] Notice, Figure 7 Steps (13) to (15) in the solution can also be performed in solution 1.2 (although in Figure 8 (Not shown in the image).

[0132] This can be accomplished in CCNF (e.g., MMF) 32 based on the capabilities of (R)AN node 30 or UE 34. Figure 7 or Figure 8 The alternative solutions shown are selected. UE capabilities regarding supported paging features(s) can be exchanged via NASMM signaling during the attach procedure or other mobility procedures. (R)AN node capabilities can be exchanged during interface setup between (R)AN node 30 and CCNF 32 (e.g., NG2 interface or S1-MME setup exchange).

[0133] Solution 2: Activate the session when other active sessions (multiple sessions) exist (e.g., the UE is in MM-ready state). While Solution 1 addresses a scenario where no other sessions are active (e.g., UE 34 is in a standby mobility state), Solution 2 assumes that UE 34 is in a ready mobility state during the arrival of DL data for an idle session. Specifically, consider... Figure 9 Assume that UE 34 has an active session context for session #1, which is terminated in UPF1 46.

[0134] The only issue is that UE 34 already has an existing PDU session (e.g., SM) context in an idle session state, and the radio connection to be established should be linked to that single PDU context, which originates from multiple existing PDU session contexts. This paper proposes using a session ID to establish this link between the new data radio connection / bearer and the existing session context in UE 34.

[0135] Figure 9 This illustrates a possible solution 2.1 for activating an additional session when another session is already active. This alternative solution 2.1 is based on a new UE context modification request procedure.

[0136] Figure 9 The steps are described below:

[0137] Step (1) is similar to Figure 7 Step (1) in the process.

[0138] Step (2) is similar to Figure 7 Step (2) in the process.

[0139] Step (3) is similar to Figure 7 Step (3) in the process.

[0140] Step (4) CCNF (e.g. MMF) 32 determines that UE 34 is in a mobility-ready state. CCNF 32 initiates a UE context modification procedure to update the UE context in (R)AN node 30 with new session parameters.

[0141] Step (5) CCNF 32, for example, sends a UE context modification request message. In addition to other UE parameters such as QoS and security parameters, this message also includes the session ID parameter received during step (3).

[0142] Step (6) (R)AN node 30 performs a radio connection reconfiguration procedure, shown in the attached figure as RRC connection reconfiguration. During this procedure, (R)AN node 30 indicates the session ID parameters to UE 34. (R)AN node 30 may set up a new data radio bearer or may reuse an existing data radio bearer. (R)AN node 30 makes this decision based on QoS parameters associated with the new session and the established data radio bearer.

[0143] Based on the received session ID, UE 34 activates the corresponding service, application, or existing PDN / APN / PDU / bearer context. UE 34 does not activate any additional existing PDN / APN / PDU / bearer contexts. In other words, UE 34 establishes a link between the newly established data radio bearer and the existing PDN / APN / PDU / bearer context based on the session ID parameter.

[0144] Step (7) (R)AN node 30 responds to CCNF 32. For example, (R)AN node 30 may send a UE context modification response message with reference to the request in step (5).

[0145] Step (8) is similar to Figure 7 Step (11) in SMF2 44 transitions from the idle session state to the active session state.

[0146] Step (9) is similar to Figure 7 Step (12) in the process.

[0147] Notice, Figure 7 Steps (13) to (15) in the solution can also be performed in solution 2.1 (although in Figure 9 (Not shown in the image).

[0148] Figure 10 Another alternative solution 2.2 is shown, in which NAS SM signaling between SMF2 44 and UE 34 is used to activate session 2 toward UPF2 48.

[0149] Figure 10 The steps are described below:

[0150] Step (1) is similar to Figure 7 Step (1) in the process.

[0151] Step (2) is similar to Figure 7 Step (2) in the process.

[0152] Step (3) SMF2 44 generates a NAS SM message (exemplarily called a NAS SM activation request) and sends it to UE34. This NAS message includes the UE ID, session ID, reason value (e.g., activation, modification, deletion), and other parameters. Several options are available for transmitting the NAS SM activation request message to UE34:

[0153] (A) By encapsulating the NAS SM activation request message into an activation session request message from SMF2 44 to MMF 32 and sending it via MMF 32; or

[0154] (B) Sent in a separate send / transmit message between SMF2 44 and MMF 32; or

[0155] (C) The NAS front-end function within CCNF 32 forwards the message to UE 34; that is, the NAS SM message does not traverse MMF 32. In the latter case (C), SMF2 44 needs to send another message to MMF 32, such as an activation session request message, to notify MMF 32 that session #2 (UP connection) needs to be activated.

[0156] Step (4) CCNF (e.g., MMF) 32 determines that UE 34 is in a mobility-ready state and needs to activate the session corresponding to the “Session ID” parameter. Furthermore, CCNF 32 needs to route and encapsulate the NAS SM activation request toward (R)AN node 30. CCNF 32 can initiate a UE context modification procedure to update the UE context in (R)AN node 30 with the new session parameters.

[0157] Step (5) CCNF 32 sends a UE context modification request message, for example. This message includes the session ID parameter received during step (3), in addition to other UE parameters such as QoS parameters and security parameters. CCNF 32 sends a NAS SM activation request to (R)AN node 30 either within the UE context modification request message or in another NG2 message (e.g., an NG DL transport message) used for transmitting NAS signaling. Figure 10 (Not shown in the image).

[0158] Step (6) This step may contain two independent message transmissions: Step (6.a) represents an example of a Radio Resource Control (RRC) DL direct transfer message, which is used to transmit a NAS SM activation request to UE 34. In step (6.b), (R)AN node 30 performs a radio connection reconfiguration process (shown as RRC connection reconfiguration), similar to... Figure 9 Step (6) in the process.

[0159] Based on the received NAS SM activation request, UE 34 activates the corresponding service, application, or existing PDN / APN / PDU / bearer context. UE 34 does not activate any additional existing PDN / APN / PDU / bearer contexts. In other words, UE 34 establishes a link between the newly established data radio bearer and the existing PDN / APN / PDU / bearer context based on the session ID parameter.

[0160] Step (7) (R)AN node 30 responds to CCNF 32. For example, (R)AN node 30 may send a UE context modification response message with reference to the request in step (5).

[0161] Step (8) UE 34 generates a NAS SM activation response message and sends it to SMF2 44. This NAS SM message can be transmitted via RRC UL direct transfer message.

[0162] Step (9) AN node 30 receives the RRC UL direct transfer message, extracts the NAS SM activation response message and forwards it to CCNF 32.

[0163] Step (10) is similar to Figure 7 Step (11) in the process. In addition, CCNF(MMF)32 transfers the NAS SM activation response message to SMF2 44 as part of the activation session response message or as part of a new transfer message between MMF 32 and SMF2 44.

[0164] SMF2 44 transitions from an idle session state to an active session state.

[0165] Step (11) is similar to Figure 7 Step (12) in the process.

[0166] Notice, Figure 7 Steps (13) to (15) in the solution can also be performed in solution 2.2 (although in Figure 10 (Not shown in the image).

[0167] Alternatively, in solution 2.2, SMF2 44 can trigger session activation itself, i.e., without triggering from UPF2 48. This is possible if scheduled session activation exists in SMF2 44. Such scheduling can be based on a timer or clock running in SMF2 44 as part of the processing of the UE SM context in SMF2 44. Based on this clock used for scheduling, SMF2 44 can trigger the establishment of the UP connection by proceeding to step (3) in MMF 32 and performing a new step (essentially step (11) above) to insert UP-related information into UPF2 48.

[0168] In summary, Solution 2.1 or Solution 2.2 allows individual sessions (UP connections) to be activated while other UP connections exist.

[0169] Solution 3: Activation of a session triggered by UL data (in the UE)

[0170] While Solutions 1 and 2 (and their variations) explain the activation of UP connections triggered by DL data (in UPF), this solution describes the activation of a single UP connection triggered by UL data (in UE).

[0171] Figure 11 The diagram shows UE 34 with two session contexts for session #1 and session #2. Two different scenarios are described. In scenario (A), UE 34 is in standby mobility (MM) state, therefore, all session states are idle. In scenario (B), UE 34 is in ready mobility (MM) state and session #1 is in use, i.e., a radio connection and an NG3 connection have been established.

[0172] Figure 11 The steps are detailed below:

[0173] Step (1) UL data from a specific application / service must be sent by UE 34, for example, via session #2. When session #2 is idle, UE 34 needs to activate the UP connection in order to transmit data.

[0174] Step (2) If UE 34 is in MM standby mode, UE 34 first needs to activate the radio CP connection (RRC) and NAS connection by initiating the service request procedure. For this purpose, UE 34 first establishes the RRC connection.

[0175] Step (3) If UE 34 is in MM standby mode, UE 34 sends a NAS service request message to activate the NAS signaling connection. The NAS service request message may also include a "session ID" parameter, etc. If the NAS signaling connection is terminated at the NAS front-end function, the NAS front-end function forwards the NAS service request message to MMF 32.

[0176] Step (4) The CCNF (e.g., MMF) 32 verifies and processes the NAS service request message. Based on the "Session ID" parameter, the MMF 32 determines which session needs to be activated. In this specific example, the MMF 32 determines that session #2 needs to be activated. The MMF 32 initiates the process for activating the UP connection to the SMF244. The MMF 32 sends an activate session request message (or has already...) Figure 7 (Similar to the message described in step (3)). This message contains other parameters, UE ID, session ID, reason value (e.g., activation, modification, deletion), etc.

[0177] Step (5) If UE 34 is in MM-ready state, then UE 34 already has a signaling connection to the NG CN. UE 34 can initiate the NAS connection activation process. For this purpose, UE 34 sends a NAS SM session activation request message to the corresponding SMF (SMF2 44 in this specific example). The NAS SM session activation request message can be forwarded to SMF2 44 via the common NAS front-end function or via MMF 32. The NAS SM session activation request message also includes parameters such as UE ID, session ID, and / or reason value (e.g., activation, modification, deletion).

[0178] Step (6) SMF2 44 receives and processes the message as in step (4) or (5). SMF2 44 determines the QoS parameters and other policy parameters to be implemented in UPF248. SMF244 initiates a session activation process to UPF2 48. SMF2 44 sends an activation session request message to UPF248, including QoS and policy parameters and optional NG3-specific parameters (such as tunnel information, such as the IP address to be used by UPF2 48 and / or the General Packet Radio Service Tunneling Protocol (GTP) Tunnel Endpoint Identifier (TEID)).

[0179] Step (7) UPF2 48 receives and processes the activation session request message. UPF2 48 sends an activation session response message to SMF244 and, if necessary, indicates the activation result reason value and NG3 specific parameters (such as tunnel information, such as the IP address to be used by UPF2 48 and / or GTP TEID).

[0180] Step (8) When necessary, SMF2 44 can send a NAS SM message to UE 34, such as a NAS SM session activation response message. This NAS SM message may include various session management parameters, such as those used for session QoS or policy modification.

[0181] Step (9) SMF2 44 can behave differently depending on the previous option (A) or (B). In one option, SMF2 44 responds to step (4). In another option, SMF2 44 can initiate a session activation process toward CCNF (e.g., MMF) 32 and (R)AN node 30. For example, SMF2 44 can send an activation session request / response message to CCNF (e.g., MMF) 32, including the session ID and UPF NG3 related information (e.g., tunnel information, such as the IP address of UPF2 48 and / or GTP TEID).

[0182] Step (10) Based on the MM state of UE 34 at the start, i.e., based on options (A) and (B), CCNF (e.g., MMF) 32 initiates different procedures:

[0183] - In option (A), where UE 34 is in MM standby mode, CCNF 32 initiates the UE context setup process by sending a UE context setup request message to (R)AN node 30. This message may include session ID, QoS, security, and other parameters required to establish a radio connection, such as UPF NG3 related information (e.g., tunnel information, such as the IP address of UPF2 48 and / or GTP TEID).

[0184] - In option (B), where UE 34 is in MM-ready state, CCNF(MMF)32 initiates the UE context modification procedure to (R)AN node 30. CCNF(MMF)32 sends a UE context modification request message to (R)AN node 30 to modify the radio connection and facilitate the establishment of an NG3 connection toward UPF2 48. The UE context modification request message may contain session ID, QoS, security, and other parameters required to establish the radio connection, such as UPF NG3 related information (e.g., tunnel information, such as the IP address of UPF2 48 and / or GTP TEID).

[0185] Step (11) (R)AN node 30 performs RRC connection reconfiguration to establish a data radio connection for session #2. For this purpose, (R)AN node 30 performs the RRC connection reconfiguration process.

[0186] Step (12) (R)AN node 30 responds to step (10). (R)AN node 30 sends a UE context setting response message to CCNF 32, including relevant information about (R)AN node UP NG3 (e.g., tunnel information, such as the IP address of UPF2 48 and / or GTP TEID).

[0187] Note that several options are possible:

[0188] - Option 1: (R)AN node 30 sends the UE context setting response message to MMF 32.

[0189] Option 2: (R)AN node 30 sends the UE context setting response message to the NG2 front-end function within CCNF 32. The front-end function can then forward the contents of the UE context setting response message to MMF 32 and / or SMF2 44.

[0190] - Option 3: (R)AN node 30 sends the UE context setting response message to SMF244.

[0191] Option 4: (R)AN node 30 sends two different messages to MMF 32 and SMF2 44. The message to MMF 32 confirms the successful establishment of the new data radio connection, while message 44 to SMF2 also carries information related to (R)AN node UP NG3 (such as tunnel information, such as the IP address of UPF2 48 and / or GTP TEID).

[0192] In step (13), under option 1 of step (12) above, MMF 32 initiates a session update procedure to SMF244 to update information related to (R)AN node UP NG3 (e.g., tunnel information, such as the IP address of UPF2 48 and / or GTP TEID).

[0193] Step (14) SMF2 44 initiates a session update process to UPF2 48. SMF2 44 sends an update session request message to UPF2 48 containing information related to (R)AN node UP NG3 (such as tunnel information, such as the IP address of UPF2 48 and / or GTP TEID).

[0194] Solution 4: Deactivate a single session while other sessions (multiple sessions) remain active.

[0195] Solution 4.1: Disabling Sessions Initiated by RAN Nodes

[0196] To manage sessions independently (i.e., on a per-session basis), the UP connection of a single session can be released (referred to as "session deactivation" in this document). In other words, a single radio connection and NG3 connection can be released while keeping the remaining existing session connections active.

[0197] In an alternative solution, it is assumed that (R)AN node 30 triggers the deactivation of a session. Typically, (R)AN node 30 manages radio-related parameters such as UE inactivity timers, active discontinuous reception (DRX) periods, idle DRX periods, etc. This solution proposes that each session maintains these radio parameters. Thus, if multiple radio connections for multiple sessions are active, (R)AN node 30 maintains a so-called "session inactivity timer" for each active session. This "session inactivity timer" differs from the UE inactivity timer because the "session inactivity timer" applies to a single session (like a data radio bearer (DRB) in LTE).

[0198] Figure 12 This describes a situation where two sessions are active and one becomes idle due to no user plane activity during a predefined UE inactivity period determined by (R)AN node 30. As a starting point, thick arrows correspondingly indicate the data flow in the UL and DL between UE34, UPF1 46, and UPF2 48.

[0199] Figure 12 The steps are described below:

[0200] Step (1) The UE inactivity timer in node 30 expires for session #1. This means that node 30 has determined that, for session #1, no data was transmitted in the UL or DL ​​within a given period denoted as "inactivity timer".

[0201] Step (2) Based on the number of remaining active sessions (or radio connections), (R)AN node 30 has two options.

[0202] Option (2.a) If this is not the last active session, then (R)AN node 30 initiates the UE connection release procedure to CCNF 32. (R)AN node 30 sends a UE connection release request message to CCNF 32. This message includes the UE temporary / permanent ID, an indication of which session must be deactivated (e.g., session #1), a reason value, and other parameters.

[0203] Option (2.b) If this is the last active session (e.g., an existing wireless connection), then (R)AN node 30 initiates the UE context release procedure. This will implement the change of the mobility (MM) state from ready to standby. The message includes the UE temporary / permanent ID, an indication of the cause value, and other parameters.

[0204] Step (3) CCNF 32 processes the UE connection release request message and determines which SMF needs to be contacted. CCNF 32 sends an NG3 release request to SMF1 42. Note that this message can also be called a deactivate session request. This means that the NG3 connection / tunnel should be released, but the UE context in SMF1 42 should be maintained and moved from active to idle. This message includes the UE temporary / permanent ID, an indication of the specific session ID (e.g., session #1), and other parameters.

[0205] Step (4) SMF1 42 sends an NG3 release request message to UPF1 46. This message includes the UE temporary / permanent ID, an indication of a specific session ID (e.g., session #1), and other parameters. UPF1 46 releases all associated resources to session #1 with respect to the NG3 reference point.

[0206] Step (5) UPF1 46 sends an NG3 release response message to SMF1 42, including UEID, session ID, and other parameters. At this time, SMF1 42 changes the session state from active to idle.

[0207] Step (6) SMF1 42 sends an NG3 release response message to CCNF 32, including UEID, session ID, and other parameters.

[0208] Step (7) Based on the number of remaining active sessions, CCNF 32 has two alternatives.

[0209] Option (7.a) If this is not the last active session, CCNF 32 sends a UE connection release command message to (R)AN node 30, including the UE ID, session ID, and other parameters. This message contains information indicating that only session #1 will be deactivated.

[0210] Option (7.b) If this is the last active session, CCNF 32 sends a UE context release command message to (R)AN node 30, including the UE ID, session ID, and other parameters. This message contains information indicating that only session #1 will be released.

[0211] Step (8) has two possible alternatives based on the number of remaining active sessions and the instructions from CCNF 32:

[0212] Option (8.a) (R)AN node 30 performs the RRC connection modification procedure. For this purpose, (R)AN node 30 sends an RRC connection reconfiguration message to UE 34 to release the associated data radio connection to session #1. Other active radio connections (multiple) are not released.

[0213] Option (8.b) If this is the last existing radio connection for UE 34, then (R)AN node 30 performs an RRC connection release procedure. For this purpose, (R)AN node 30 sends an RRC connection reconfiguration message to UE 34 to release the associated radio connection to session #1.

[0214] If option (8.a) has been selected, UE 34 will change the state of the corresponding session (e.g., session #1) from active to idle.

[0215] It is important to mention that in UE 34, the session #1 context is not deleted, but remains in an idle state, while other session states can be in an active state.

[0216] Step (9) AN node 30 sends a (9.a) UE connection release complete message to CCNF 32, or sends a (9.b) UE context release complete message to CCNF 32.

[0217] Assuming that the deactivated session #1 was not the last active session, Figure 12 As shown at the bottom, the wireless connection and NG3 connection / tunneling for session #2 are maintained after the deactivation process for session #1 is performed.

[0218] Solution 4.2: Disabling sessions initiated by UPF

[0219] Figure 13 An alternative solution is presented, in which the session deactivation process is initiated by the corresponding session's UPF. This solution proposes that each UPF manages an inactivity timer (which may be referred to as a "session inactivity timer"). This timer can be configured via the SMF when the session is activated, for example... Figure 7 or Figure 8 Step (12) may include the “Session Inactive Timer” parameter. UPF measures the time during which no DL or UL data has been exchanged. When the measurement time of data inactivity reaches the value of the “Session Inactive Timer” parameter, UPF triggers the UP connection release process.

[0220] As a starting point, UE 34 is in MM-ready state, and sessions #1 and #2 are activated. This is indicated by the corresponding thick arrows, which correspond to the two radio connections and two NG3 connections between (R)AN node 30, UPF1 46, and UPF2 48.

[0221] Figure 13 The steps are described below:

[0222] Step (1) UPF1 46 detects that the session inactive timer has expired. This means that UPF146 has determined that, for session #1, no data has been sent in the UL or DL ​​within the given period of time, which is represented as the "inactive timer".

[0223] Step (2) UPF1 46 initiates the release request procedure for the UP connection toward (R)AN. UPF1 46 sends an NG3 release request message (or a similar message, such as a deactivate session request or release connection request) to SMF1 42. This message may contain UEID, session ID, reason value, and other parameters.

[0224] Step (3) SMF1 42 initiates the UP connection release procedure. SMF1 42 sends an NG3 release request message (or a similar message, such as a deactivate session request or release connection request) to CCNF 32. This message may contain the UE ID, session ID, reason value, and other parameters.

[0225] Step (4) CCNF (e.g. MMF) 32 has two options, depending on the number of remaining active sessions (or radio connections).

[0226] Option (4.a) If this is not the last active session, CCNF32 initiates the UE connection release procedure to (R)AN node 30. CCNF32 sends a UE connection release request message to (R)AN node 30. This message includes the UE temporary / permanent ID, an indication of which session must be deactivated (e.g., session #1), and other parameters.

[0227] Option (4.b) If this is the last active session (e.g., there are no longer any active sessions and corresponding radio or NG3 connections), CCNF 32 initiates the UE context release procedure. This will implement the change of the mobility (MM) state from ready to standby.

[0228] Step (5) has two possible alternatives based on the number of remaining active sessions and the instructions from CCNF 32:

[0229] Option (5.a) (R)AN node 30 performs the RRC connection modification procedure. For this purpose, (R)AN node 30 sends an RRC connection reconfiguration message to UE 34 to release the associated radio connection to session #1. It is assumed that the radio data bearer / connection to be released has a one-to-one association with the NAS SM context corresponding to the session to be deactivated. Furthermore, the radio signaling on the RRC contains an indication (session ID) of the session to be deactivated. Other active radio connections (multiple) are not released.

[0230] Option (5.b) If this is the last existing radio connection for UE34, then (R)AN node 30 performs an RRC connection release procedure. For this purpose, (R)AN node 30 sends an RRC connection reconfiguration message to UE34 to release the associated radio connection to session #1.

[0231] If option (5.a) has been selected, UE 34 will change the state of the corresponding session (e.g., session #1) from active to idle.

[0232] Step (6) AN node 30 sends a (6.a) UE connection release complete message to CCNF 32, or sends a (6.b) UE context release complete message to CCNF 32.

[0233] Step (7) CCNF 32 responds to the UP connection release procedure in step (3). CCNF 32 sends an NG3 release response message (or a similar message, such as a deactivate session response or release connection response) to SMF1 42. This message may contain the UE ID, session ID, reason value, and other parameters.

[0234] Step (8) SMF1 42 responds to the UP connection release procedure in step (2). SMF1 42 sends an NG3 release response message (or a similar message, such as a deactivate session response or release connection response) to UPF1 46. This message may contain the UE ID, session ID, reason value, and other parameters.

[0235] At this point, SMF1 42 changes the session state from active to idle.

[0236] Another alternative to Solution 4.2 is to use a NAS SM session deactivation procedure between SMF1 42 and UE 34. SMF1 42 can use this procedure to notify UE 34 that the SM context is deactivated, which causes the session SM state in UE 34 to change from active to idle. This NAS SM procedure can be used between SMF1 42 and UE 34. Figure 13 Steps (3), (4) and (5) are initiated in parallel.

[0237] Option 4.3: UE-initiated session deactivation

[0238] This is an alternative method of session deactivation (i.e., releasing the UP connection), where the process is initiated by UE 34. Because UE 34 is aware of the applications running at higher layers, it can determine whether the application has completed data transfer. If such indication is available from the higher layer down to the NAS layer, the NAS layer in UE 34, specifically the NAS SM portion, can initiate a session deactivation process toward the NG CN.

[0239] In a specific example, if the application associated with session A indicates to the NAS SM instance in UE 34 that such an application no longer needs an UP connection, or if the NAS SM instance learns by any means that an active UP connection is not being used, then the NAS SM instance of the UE for session A can initiate a session deactivation procedure to the NG CN. The following steps can be performed:

[0240] Step (1) UE 34 initiates a NAS SM session deactivation procedure with SMF1 42 to notify SMF1 42 that the UP connection can be released. UE 34 generates a NAS SM deactivation session request message and sends it to NG CN via NAS signaling. In addition to the usual NASSM parameters, the message also includes indications regarding UP connection deactivation and session ID. NG CN processes the message and forwards it to the corresponding SMF1 42.

[0241] Step (2) SMF1 42 initiates the NG3 release process to UPF1 46.

[0242] Step (3) SMF1 42 initiates the NG3 release request (or deactivate session request) procedure to CCNF (e.g. MMF) 32.

[0243] Step (4) MMF 32 processes the NG3 release request message from SMF1 42. MMF 32 initiates the NG3 release procedure (or deactivate session procedure) to (R)AN node 30.

[0244] Step (5) (R)AN node 30 performs an NG3 release procedure (or session deactivation procedure) to UE 34, for example via an RRC connection modification procedure. Additionally, (R)AN node 30 modifies the context of UE 34 by deleting the NG3 parameters of the corresponding UPF node. (R)AN node 30 replies to MMF 32 with the result of the NG3 release procedure.

[0245] Step (6) MMF 32 changes the state of the corresponding session to idle. MMF 32 replies to SMF1 42 with the result of the NG3 release procedure.

[0246] Step (7) SMF1 42 confirms the NAS SM session deactivation request message in step (1).

[0247] Note that steps (2) to (6) above are similar to Figure 13 Steps (3) to (7) in Solution 4.2 are shown. The main difference between Solution 4.3 and Solution 4.2 is the NAS SM session deactivation procedure performed between UE 34 and SMF1 42.

[0248] The following description applies to all solutions described in this document.

[0249] The examples above describe solutions for activating or deactivating a single session. However, it is also possible to activate / deactivate several sessions simultaneously by including multiple session IDs in the corresponding message. Activating multiple sessions simultaneously can be beneficial when there are multiple PDU sessions per data network, assuming the same SMF controls multiple PDU sessions. In an alternative, the SMF decides whether to activate a single PDU session (e.g., which DL data is arriving at) or to activate some or even all PDU sessions controlled by that SMF (which could mean some or all PDU sessions heading towards a specific network slice or data network).

[0250] Note that signaling to and from (R)AN node 30 via the NG2 interface can be terminated at the common front-end NG2 termination function in CCNF 32. The common front-end NG2 function can route / forward the content of NG2 messages to MMF 32 and / or SMF2 44. Furthermore, (R)AN node 30 can send two different NG2 messages: a separate message to MMF 32 and a separate message 44 to SMF2. The message to MMF 32 can request MM-specific actions or confirm the successful establishment / release of the data radio connection. The message to SMF2 44 can primarily contain (R)AN node UP NG3 related information (e.g., tunnel information, such as the IP address of UPF2 48 and / or GTP TEID).

[0251] Note that all the above figures illustrate a scenario with a single UPF for each session. However, this document applies to scenarios with multiple different UPFs served by a single SMF. In this case, it can be assumed that multiple PDU sessions exist for the same data network. Sessions can be activated independently for each UPF. In this case, the activated session exists in another UPF served by the same SMF244 (i.e., UE 34 is in a ready mobility state, and SMF2 44 is in an active session state). Then, SMF2 44 does not need to initiate a paging procedure; instead, SMF244 can modify an existing session or initiate activation on a new UP session. For this purpose, the SM requests CCNF(MMF)32 to add a new UP session including UPF2 48 information.

[0252] Co-addressing of control plane functions (such as MMF and SMF in a common control plane function entity) is possible.

[0253] The proposed solution is based on the following principles:

[0254] - Session Management Function (SMF) and Mobility Management Function (MMF) are divided into different network functions. In the specific case of a UE registered through multiple network slice instances, the UE will be served by multiple SMFs, that is, multiple PDU sessions will be established.

[0255] - Establish multiple PDU sessions for a given UE (to the same network slice or different network slices). PDU sessions can be in an idle state or an active state.

[0256] - UP connections (including data radio connections and NG3 tunnel establishment) can be activated for a single PDU session. UP connections for other PDU sessions (to the same network slice or other network slices) can be activated / deactivated independently.

[0257] - Propose a process for activating and deactivating PDU sessions, which means:

[0258] - PDU session activation is the transition to an "active" session state in SMF and the establishment of an UP connection;

[0259] - PDU session deactivation is the transition to an "idle" session state in SMF and releases the UP connection.

[0260] General node description

[0261] The following description applies to all solutions described in this document.

[0262] UE impact

[0263] Note that the solution described in this document is mainly for UEs as NG UEs, but the solution can also be applied to 2G, 3G and 4G access systems, that is, when the UE is a 2G / 3G / 4G UE.

[0264] According to the above example embodiment, UE 34 is modified to handle signaling between (R)AN and CN functional entities (e.g., (R)AN nodes, MMF, SMF). Furthermore, UE 34 can receive, process, and transmit relevant information to the (R)AN and CN functional entities. This can be achieved through... Figure 14 The block diagram schematically describes UE 34.

[0265] Figure 14 It is shown, for example, in Figure 1The block diagram shown is of the main components of the user equipment (UE) 34 (hereinafter referred to as "NG UE"). As shown, the UE 34 has transceiver circuitry 50, which is operable to transmit signals to and receive signals from a radio access network node 30 via one or more antennas 52. This radio access network node 30 (in...) Figure 1 The Chinese character is represented as "NG(R)AN". Figure 2 The Chinese character is represented as "RAN". Figure 4 The UE 34 (referred to as "AN") may include a base station and / or any other suitable access point / transmission point. The UE 34 has a controller 54 to control the operation of the UE 34. The controller 54 is associated with the memory 56 and coupled to the transceiver circuitry 50. The UE 34 may have all the common functions of a conventional mobile device / telephone (e.g., a user interface), which may be provided by any one or any combination of hardware, software, and firmware, as appropriate. For example, software may be pre-installed in the memory 56 and / or may be downloaded via a telecommunications network or from a removable data storage device (RMD).

[0266] In this example, the controller 54 controls the overall operation of the UE34 through program instructions or software instructions stored in the memory 56. As shown, these software instructions include the operating system 58, the communication control module 60, and the transceiver control module 62 (shown as a component of the communication control module 60), etc.

[0267] The communication control module 60 controls the communication between the UE 34 and the (R)AN's base station / access node. The communication control module 60 also controls separate streams of control data (control plane) and user data (user plane, referring to both uplink and downlink) to be transmitted to the base station / access node and other nodes (via the base station / access node), such as mobility management functions (MMF) and session management functions (SMF).

[0268] MMF / SMF influence

[0269] Based on the above example embodiments, the Mobility Management Function (MMF) or Session Management Function (SMF) can be modified / extended to be applicable to the proposed solutions (multiple). This can be achieved via the appendix. Figure 15 The block diagram in the diagram schematically describes MMF or SMF.

[0270] Figure 15 It is shown in, for example Figure 1 The diagram shows a block diagram of the main components of the Mobility Management Function (MMF) / Session Management Function (SMF) node. Although the MMF and SMF are shown as part of a combined control function entity, their functionality can be implemented in separate nodes.

[0271] As shown, the MMF / SMF has transceiver circuitry 64 and a network interface 66 for transmitting signals to and receiving signals from other network nodes (including UE 34). The MMF / SMF has a controller 68 to control the operation of the MMF / SMF node. The controller 68 is associated with a memory 70. For example, software may be pre-installed in the memory 70 and / or downloadable via a communication network or from a removable data storage device (RMD). In this example, the controller 68 is configured to control the overall operation of the MMF / SMF via program instructions or software instructions stored in the memory 70. As shown, these software instructions include an operating system 72, a communication control module 74, and a transceiver control module 76 (shown as a component of the communication control module 74), etc.

[0272] The communication control module 74 controls the communication between the MMF / SMF and other network entities connected to the MMF / SMF (e.g., base stations / access nodes, and UEs 34 when connected to base stations / access nodes).

[0273] Summarize

[0274] Advantageously, the above example embodiments include, but are not limited to, one or more of the following functions.

[0275] 1) The UE can link the data radio connection activation or deactivation process with the existing PDU session management context in the UE.

[0276] a. This link in the UE is based on the session ID indication carried in the relevant signaling from the SMF to the UE.

[0277] 2) User plane connection deactivation is performed through the session management function in the triggered NG CN:

[0278] a. Or through user plane functions in the core network; or

[0279] b. Via NAS SM signaling via UE.

[0280] As can be seen, the above example embodiment describes a method for independently activating or deactivating user plane connections for each PDU session or network slice, the method comprising:

[0281] 1) Initiate activation or deactivation of user plane connections from SMF based on the following:

[0282] a. Triggered from UPF (due to the arrival of DL data for session activation, or due to the expiration of a timer for session deactivation);

[0283] b. Triggered from the UE (due to UL data transmission for session activation, or due to the UP connection not being needed for session deactivation).

[0284] 2) Control plane session management functions, mobility management functions, access networks and terminals use session IDs as reference IDs to represent the same session.

[0285] benefit

[0286] It can be seen that the above embodiments provide many benefits, including but not limited to:

[0287] (1) Even if there are multiple user plane functions instantiated / configured for the UE, the number of active NG3 connections is limited, which also limits signaling via radio and NG2 and NG3 interfaces in the case of UE mobility.

[0288] (2) If the UE receives or sends data through a single specific session, only the user plane connection of that specific session is activated. If frequent mobility state changes occur between standby and ready states, this reduces the signaling used by other sessions for connection establishment.

[0289] Modification and replacement

[0290] Detailed exemplary embodiments have been described above. As those skilled in the art will understand, various modifications and substitutions can be made to the above exemplary embodiments while still benefiting from the invention specifically implemented herein. For illustration, only a portion of these substitutions and modifications are described below.

[0291] In the above description, for ease of understanding, the UE and MMF / SMF nodes are described as having multiple discrete modules (e.g., communication control modules). While these modules can be provided in this way for certain applications, such as where existing systems have been modified to implement the present invention, in other applications, such as in systems designed from the outset with inventive features in mind, these modules may be built into the entire operating system or code, and therefore may not be identifiable as discrete entities. These modules can also be implemented in software, hardware, firmware, or a combination thereof.

[0292] Each controller may include any suitable form of processing circuitry, such as (but not limited to): one or more hardware-implemented computer processors, microprocessors, central processing units (CPUs), arithmetic logic units (ALUs), input / output (I / O) circuitry, internal memory / cache (program and / or data), processing registers, communication buses (e.g., control, data, and / or address buses), direct memory access (DMA) functionality, hardware or software-implemented counters, pointers, and / or timers, etc.

[0293] In the above example embodiments, numerous software modules have been described. As those skilled in the art will understand, software modules may be provided in compiled or uncompiled form and may be provided to the UE and MMF / SMF nodes as signals via a computer network or on a recording medium. Furthermore, one or more dedicated hardware circuits may be used to perform some or all of the functions executed by the software. However, the use of software modules is preferred because it facilitates updating the UE and MMF / SMF nodes to update their functionality.

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

[0295] List of abbreviations

[0296] 3GPP: Third Generation Partnership Project

[0297] AS: Access Layer (using RRC signaling similar to that in this document)

[0298] CCF: Core Control Functions

[0299] CCNF: Common Control Network Functions

[0300] CPF: Control Plane Functions

[0301] NB, eNB: Node B, Evolved Node B (but can also be any "RAN node" implementing 2G, 3G, 4G or future 5G technologies)

[0302] E-UTRAN: Evolved Universal Terrestrial Radio Access Network (also known as EUTRAN)

[0303] GGSN: Gateway GPRS Support Node

[0304] GPRS: General Packet Radio Service

[0305] HPLMN: Home Public Land Mobile Network

[0306] HSS: Home Subscriber Server

[0307] IE: Information element (used as part of a signaling message)

[0308] MME: Mobility Management Entity

[0309] MMF: Mobility Management Function

[0310] MNO: Mobile Network Operator

[0311] NAS: Non-Access Layer

[0312] NFV: Network Functions Virtualization

[0313] NNSF: NAS / Network Node Selection Function

[0314] NSI: Network Slicing Example

[0315] PCF: Policy Control Function

[0316] PCRF: Policy and Charging Rules Functionality

[0317] PGW: Packet Data Network Gateway

[0318] PSM: Power Saving Mode

[0319] RAU: Routing Area Update

[0320] RNC: Radio Network Controller

[0321] RRC: Radio Resource Control

[0322] PLMN: Public Land Mobile Network

[0323] SCNF: Slice-Specific Control Plane Network Functions

[0324] SMF: Session Management Function

[0325] SGSN: Serving GPRS Support Node

[0326] SGW: Service Gateway

[0327] TAU: Tracking Area Updates

[0328] UE: User Equipment

[0329] UPF: User Plane Functions (any UP function used for policy / QoS enforcement, mobility, UE IP anchor, similar to SGW / PGW in EPC)

[0330] UTRAN: UMTS Terrestrial Radio Access Network

[0331] VPLMN: Public Land Mobile Networks Interviewed

[0332] This application is based on and claims priority to European patent application No. EP 16185042.5 filed on 19 August 2016, the entire disclosure of which is incorporated herein by reference.

Claims

1. A control method in a network node for mobility management, comprising: receiving, from a user equipment, UE, via an access network, AN, node, information in a non-access stratum, NAS, service request message, the information indicating at least one protocol data unit, PDU, session identifier, ID, the at least one PDU session ID indicating that at least one PDU session is to be activated; and transmitting, to a session management function, SMF, node associated with one of the at least one PDU session ID, a message related to a PDU session corresponding to the one of the at least one PDU session ID, and the control method comprising: receiving, from the SMF node, a further message comprising tunnel information related to a reference point between a user plane function, UPF, node and the AN node and the one of the at least one PDU session ID.

2. The control method according to claim 1, wherein The PDU session ID is related to pending uplink user data to be transmitted.

3. The method of claim 1, the information being related to pending uplink user data to be transmitted.

4. The control method of any of claims 1 to 3, comprising: transmitting, from the SMF node to the AN node, a request message comprising information included in the further message.

5. The control method of any of claims 1 to 3, comprising: receiving, from the AN node, a response message comprising tunnel information related to a reference point between the AN node and the network node; and transmitting, to the SMF node, a message comprising the tunnel information related to the reference point between the AN node and the network node.

6. The control method of any of claims 1 to 3, comprising: transmitting, to the SMF node, the message related to the PDU session with a type set to indicate establishment of user plane resources.

7. A network node for mobility management, comprising: a receiver configured to receive, from a user equipment, UE, via an access network, AN, node, information in a non-access stratum, NAS, service request message, the information indicating at least one protocol data unit, PDU, session identifier, ID, the at least one PDU session ID indicating that at least one PDU session is to be activated; and a transmitter configured to transmit, to a session management function, SMF, node associated with one of the at least one PDU session ID, a message related to a PDU session corresponding to the one of the at least one PDU session ID, and the receiver configured to receive, from the SMF node, a further message comprising tunnel information related to a reference point between a user plane function, UPF, node and the AN node and the one of the at least one PDU session ID.

8. The network node for mobility management according to claim 7, wherein, The PDU session ID is related to pending uplink user data to be sent.

9. The network node for mobility management of claim 7, the information related to pending uplink user data to be sent.

10. The network node for mobility management of any of claims 7 to 9, comprising: transmitting a request message from the SMF node to the AN node, the request message including information included in the other message.

11. The network node for mobility management of any of claims 7 to 9, comprising: receiving a response message from the AN node, the response message including tunnel information related to a reference point between the AN node and the network node; and transmitting a message to the SMF node including the tunnel information related to the reference point between the AN node and the network node.

12. The network node for mobility management of any of claims 7 to 9, comprising: transmitting the message related to the PDU session to the SMF node with a type set to indicate establishment of user plane resources.

Images