Method Executed by Radio Base Station and Radio Base Station

Abstract

To solve or at least mitigate a problem by reducing signaling required for NG3 tunnel establishment that enables a particular session among a plurality of existing sessions.SOLUTION: The present disclosure provides user equipment (UE) including a transmitting unit configured to transmit at least one protocol data unit (PDU) session identifier (ID). When the UE has user data to be transmitted, each ID indicates a PDU session which the UE needs to use, to a mobility management function (MMF) via an access network (AN) node, by a non-access stratum (NAS) service request message.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure relates to a communication system. The present disclosure is particularly relevant to, but not limited to, wireless communication systems and their devices operating in accordance with 3rd Generation Partnership Project (3GPP) standards or their equivalents or derivatives. The present disclosure is particularly relevant to, but not limited to, so-called "next generation" systems.

Background Art

[0002] The present disclosure includes a method for independently activating or deactivating user plane connections for each protocol data unit (PDU) session or network slice when the session context in a user equipment (UE) and a network (e.g., a session management function (SMF) or a user plane function (UPF)) is already established. In this solution, a (session management (SM)) state machine for each established PDU session maintained in either the SMF or a mobility management function (MMF) network function is proposed. The SM state machine is executed independently of the mobility management (MM) state machine.

[0003] Summary The following terms are used herein and are applicable to any generation of mobile network, such as 2G (Global System for Mobile Communications (GSM) for mobile communication), 3G (Universal Mobile Telecommunications System (UMTS)), 4G (Long Term Evolution (LTE) / Evolved Packet Core (EPC)), 5G (New Radio (NR) / NextGen), etc. For example, when referring to "UE" or "serving node" in the following description, it may be a UE or serving node of any generation.

[0004] Terms such as "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 widely used in various embodiments herein to describe functional entities such as MSC, SGSN, MME, C-SGN, or other possible control plane functional entities within a mobile network that terminate control plane signaling (known as non-access stratum (NAS) signaling) between the core network and the terminal. A serving node (MME / SGSN) may also be a functional entity of a next-generation network responsible for mobility management and session management.

[0005] Terms such as "home subscriber server (HSS) / home location register (HLR)" mean a repository where UE subscriber data is stored and may be an HSS or HLR or a composite entity. Instead of HSS, terms such as next-generation user data management (UDM), subscriber database management (SDM), or authentication authorization accounting (AAA) may also be used synonymously.

[0006] Functional entities or network functions used as separate entities herein can be co-located, separated more finely in a particular arrangement, or as described in the architecture diagrams.

[0007] Terms such as "terminal", "device", "user terminal", "user equipment (UE)", or "mobile terminal (MT)" are used interchangeably, and all of these terms similarly represent a device used to transmit and receive data and signaling with a network, a mobile network, or a radio access network.

[0008] The term "session" is used in the same sense as "PDU session", "packet data network (PDN) connection", "access point name (APN) connection", or "connection for a specific network slice". An existing session is a session for which a UE context already exists (is established) in the core network control plane and / or user plane and in the UE itself. "Existing session" has the same meaning as "established PDU session" or "established PDN connection". Each session is identifiable by a "session ID", which may be similar to an "evolved packet system (EPS) bearer ID", "APN", "slice ID", "slice instance ID", "service ID", or a temporary or permanent identifier of a PDN connection, PDU session, or service used by the UE.

[0009] The term "connection" is most often used for a user plane connection in which a certain "path" for transmitting uplink (UL) or downlink (DL) data is established between the UE and a user plane gateway (GW) terminating the PDU session. Depending on the context, the connection can be either the entire user plane path for a PDU session or only a connection via a given interface such as a connection via the radio interface or a connection via the NG3 interface (between the user plane function (UPF) of the next generation core network (NG CN) and the (radio) access network ((R)AN)).

[0010] The following terms are used in the procedure. Session establishment: For example, the establishment of a PDU session when an SM context exists (is established) in the UE as well as in the NG CN control plane and / or user plane. Release of session: It means the deletion of the PDU session, and the SM context is deleted (released) in the UE as well as in the NG CN control plane and / or user plane. Activation of session / connection: It is to activate the UP connection path for the session, and the SM context exists in the UE and the NG CN. Deactivation of session / connection: It is to deactivate the UP connection path without deleting the SM context in the UE and the NG CN. In other words, it only releases the UP connection.

[0011] The mobility state of the UE is called deregistration, registration - pending (simply "pending"), registration - ready (simply "ready"). These states are also called MM states. Note that there is a difference between the mobility state (MM state) and the session state (SM state).

[0012] The telecommunications industry has started working on a new - generation network called the fifth - generation (5G) network. In order to develop a 5G network that provides services to multiple vertical service providers and various terminals, activities have been started in multiple research and standardization institutions. In particular, 3GPP has started activities under the term "New Radio" (NR) in the RAN field and under the term "NextGen" (NG) in the core network (CN). Note that these terms will probably be changed before the 5G system is introduced into the market. Therefore, terms such as NG CN (or NG AN) used in this specification have the meaning of any 5G CN or AN technology.

[0013] 3GPP has studied the NG system architecture, and the corresponding issues and solutions are recorded in 3GPP TR 23.799 [see Non-Patent Document 1]. Figure 1 illustrates the NG architecture for simultaneous access to multiple PDN connections (referred to as PDU sessions in the NG study) that has been agreed upon in [Non-Patent Document 1] as of the time of writing of this specification. At the top of Figure 1, an example of the NG control plane (NG CP) including the subscriber database management (SDM) 22, the policy control function (PCF) 24, and the core control function (CCF) 26 is shown. The NG CCF 26 includes, among other things, the mobility management function (MMF) and the session management function (SMF). Since there may be one or more UPFs for each configured PDU session, the user plane (UP) function is shown as the core user plane function (NG UPF) 28. Details regarding the description of interfaces and network functions are described in Section 7.3 of TR 23.799 [see Non-Patent Document 1].

[0014] One of the main features of the 5G system is called network slicing. In 5G use cases, they are very diverse and sometimes require extreme requirements. In the current architecture, a relatively monolithic network and transport framework is utilized. Therefore, it is expected that the current architecture does not have sufficient flexibility and scalability to efficiently support a wider range of business needs. To meet such needs, the 5G NG system can "slice" into multiple network instances called network slice instances (NSIs). A network slice can be called a logical separated network where the resources (processing, storage, and networking resources) of each network slice are separated. The network operator creates NSIs using network slice templates / blueprints. NSIs provide the network characteristics required by service instances. An example of a network architecture that enables a UE to connect to multiple NSIs simultaneously is shown in FIG. 2 as described in [Non-Patent Document 1].

[0015] FIG. 2 shows 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 can have multiple NSIs for a particular third-party customer. In this figure, it is shown that the (R)AN is shared and network slicing is applied to the NG CN. However, in future network slices, it is also possible for the (R)AN where RAN resources are sliced / separated in baseband processing or frequency spectrum or both.

[0016] In [Non-Patent Document 1] as well, as shown in detail in FIG. 3, a common control network function (CCNF) 32 and a slice-specific control plane network function (SCNF) are described. The CCNF 32 may include a basic control plane network function that supports the operation of basic functions common among NSIs. For example, 1. Subscriber Authentication Authority 2. Mobility Management 3. Network Slice Instance Selector (NSI Selector) 4. NAS Routing Function, etc.

[0017] Generally, the NG system design should enable communication of any type of data. Assume that the NG system supports the following PDU session types. IP type (e.g., IPv4 or IPv6 or both), or Non-IP session (any unstructured data), or Ethernet type.

[0018] One further solution described in section 6.4.3 of 23.799 is shown in FIG. 4. The UE 34 may establish multiple PDU sessions to the same data network in order to meet the various connection requirements (e.g., session continuity) of various applications that require connectivity to the same data network. In this solution, the MM function and the SM function are separated. Here, one main concept is that multiple SM contexts can be used for each MM context. Also, different session continuity types are possible for each PDU session.

Prior Art Documents

Non-Patent Documents

[0019] Non-Patent Document 1: 3GPP TR 23.799 v0.6.0, July 2016, "Study on Architecture for Next Generation Systems" Non-Patent Document 2: 3GPP TS 23.401 v14.0.0, June 2016, "Enhancement of General Packet Radio Service (GPRS) for Access to Evolved Universal Terrestrial Radio Access Network (E-UTRAN)"

Summary of the Invention

Problems to be Solved by the Invention

[0020] The scenario considered herein 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 (c) part of different network slice instances (NSIs). In other words, multiple NG3 connections (e.g., tunnels via the NG3 interface) between the (R)AN and multiple UP-GWs are available. If the UE has established multiple PDU sessions, multiple session management function (SMF) instances may exist for each UE.

[0021] Under one assumption herein, a "session" of the UE (or also referred to as a "PDN connection" or "PDU session" for 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. When the session is in the "idle" state, there is no NG3 connection / tunnel established between the UPF and the (R)AN. When the session is in the "active" state, there is an NG3 connection / tunnel established between the UPF and the (R)AN. Also, assume that for a certain established UE session, a session management function (SMF) is instantiated / configured in the control plane, and the corresponding one or more UPFs are instantiated / configured in the user plane. Further details regarding the idle and active session states of the control plane function (CPF) and UPF will be understood below.

[0022] Assuming that there is an NG3 tunnel setup for sending data packets between the AN and multiple UPFs, every time the UE transitions from the standby mobility state to the ready mobility state, a problem occurs where multiple NG3 tunnels are established, changed, and released.

[0023] Compared with the EPC where one serving GW is configured per UE and one S1-U tunnel is established and released during the transition from standby to ready, in the NG with multiple UPFs, multiple tunnels are established / released via the NG3 interface. Therefore, there is a problem that when one UPF (or PDU session) is in use but multiple NG3 tunnels are established / released, the signaling for tunnel establishment increases.

[0024] Also, when all existing sessions are in the idle state and downlink data arrives in a specific session, there must be a way to synchronize the SM state between the UE and the NG system. Therefore, in the case of an MT call, it is currently impossible for the UE to activate only one application associated with the session that triggers the MT call.

[0025] Furthermore, as long as the UE is attached / registered to the NG system, the mobility management entity can always maintain the MM state in a ready state in the NG core network (CN). As a result, the NG CN only has the registered mobility state and the deregistered mobility state of the UE. This MM mechanism is mainly advantageous for paging stationary devices or devices with little movement where the paging area is relatively small. In this architecture, the NG CN knows the location of the UE, and the NG3 tunnel is always active. This means that the session state is always "active". This specification also aims to solve potential problems when such a device has other applications configured to access in another session at the same time. In this case, the NG CN performs session management, and 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 the (R)AN node, all tunnels must be updated. This means that the CCNF and SMF need to update all UPFs with the new tunnel endpoint information. This results in an increase in signaling.

[0026] This disclosure aims to solve, or at least mitigate, the above problems by reducing the necessary signaling for NG3 tunnel establishment that enables the activation of a specific session among a plurality of existing sessions.

Means for Solving the Problems

[0027] Exemplary aspects in the present disclosure are user equipment (UE) comprising a transmitter configured to transmit at least one protocol data unit (PDU) session identifier (ID). Each ID indicates, when the UE has user data to transmit, to a mobility management function (MMF) via an access network (AN) node, in a non-access stratum (NAS) service request message, the PDU sessions that the UE needs to use.

Brief Description of the Drawings

[0028]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

DETAILED DESCRIPTION OF THE INVENTION

[0029] To solve the above problems, respective solutions are described in various embodiments of this specification.

[0030] Note that terms such as "idle" session or "active" session are used for the SM state, and the standby state and the ready state are used for the mobility state of the UE. Also, the transition from the idle session state to the active session state can be called "session activation", and the transition from the active session state to the idle session state can be called "session deactivation". This is shown in FIG. 6.

[0031] The terms "session activation" procedure or "session deactivation" procedure relate to the establishment or release of an NG3 connection / tunnel. These terms are different from the "session establishment" procedure and "session release" procedure. The "session establishment" procedure and "session release" procedure involve the establishment of a new session including the establishment of an SM context in both the UE and the NG CN, or the deletion of the corresponding existing session, that is, related to the deletion of the SM context in the UE and the NG CN.

[0032] For the purposes of this specification, in the case of a single established session (network slice or PDU session), the reference architecture shown in Figure 1 is assumed. In the case of multiple established sessions, Figure 5 where the UE has established three different sessions A, B, and C is assumed as the reference architecture. Each session belongs to a different network slice or to a network slice that is the same but has multiple PDU sessions. In the control plane, there is a box indicating the CCNF32 shared among the network slices or PDU sessions. These CCNFs include the mobility management network function (NF) (referred to as MMF), authentication / authorization / security NF, NAS signaling routing NF, and others. As shown in Figure 5, each PDU session or network slice can have an independent dedicated CPF. The dedicated CPF can include the following exemplary network functions. SMF: In this specification, this function is assumed to be responsible for the session management of a specific session (network slice or PDU session). The CPF of the GW (also known as GW-C of the UPF) is called control plane and user plane separation (CUPS) because in the control plane / user plane separation in the EPC, the control plane of the GW is known as the S / PGW-CP function. PCF: All or part of the PCF as described in Figure 1. This means that part of the PCF can be the part called CCNF32 and the other part can be part of the dedicated CPF. Authentication, authorization, and security functions related to a specific network slice of a PDU session.

[0033] Note that UE34 is shown in FIG. 5 by having three arrows towards (R)AN node 30 representing three radio connections corresponding to three sessions / slices A, B, and C. However, this is just an example. UE34 can have, for example, only three user plane radio connections and one control plane radio connection (per session). Alternatively, UE34 can have three user plane radio connections and three control plane radio connections (per session).

[0034] For the sake of brevity, in this specification, the term SMF is used to denote all dedicated CPFs listed above for a PDU session or a network slice. Each SMF has a signaling relationship with CCNF32 for each UE34. 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 the UE's mobility state or session state. Also, CCNF32 and SMF exchange (temporary or permanent) UE IDs or subscriber IDs and use this ID in each signaling message exchange to indicate the corresponding UE context within CCNF32 or SMF.

[0035] Furthermore, a UPF (e.g., the GW function defined by 3GPP for applying service quality (QoS) or traffic policies) for each network slice or PDU session is configured / instantiated. Each of the (NG3) connections A, B, and C is independently manageable, i.e., it can be established, changed, or released independently of other connections. Note that there may be one or more UPFs. For example, a UPF close to the edge can be used as a mobility anchor, and a deeper UPF in the CN can be used as an IP anchor (hosting the UE's IP address). For the sake of brevity, one UPF is used in this specification. However, if multiple UPFs are required and instantiated / configured for a specific session, the SMF can configure multiple UPFs.

[0036] As illustrated in FIG. 5, assume that there are three connections (e.g., tunnels via NG3), each of which is a single connection for slice / session A36, slice / session B38, and slice / session C40, between the (R)AN and the UPF. If tunneling via NG3 is used for each UE34 between the (R)AN and the UPF A36 / B38 / C40, every time UE34 transitions between the idle state and the ready state, the three tunnels are activated / changed / released. Even worse, if tunneling via NG3 is per IP flow or per bearer, more tunnels need to be activated / changed / released for each transition to the idle mobility state and the ready mobility state.

[0037] FIG. 5 shows that a dedicated CPF can include an SMF and a PCF in session C. Note that the presence of a PCF in the dedicated CPF may be based on a specific use case. For example, in a certain network slice, a PCF can be instantiated / configured per slice, and in other network slices, the PCF can be instantiated / configured as a common CPNF.

[0038] In this specification, when there are multiple PDU sessions existing / being established (or there is simultaneous connectivity to multiple network slices), the system architecture enables the activation / deactivation of one session, which means: 1) making the session state active in the corresponding CPF, e.g., the SMF; 2) activating one UP session by establishing the corresponding connection / tunnel between the (R)AN node 30 and the UPF. When there is no transmission data in the uplink (UL) or downlink (DL), other UP sessions (other PDU sessions or other network slices) are not activated (i.e., in the idle state).

[0039] As shown in FIG. 6, there is an independent session state machine for each existing session (i.e., for each network slice or PDU session). This is shown as the session A state machine and the session B state machine. This session state machine is applicable to both the UE 34 and the NG CN. During the establishment of the UE session, the SMF entity is selected and configured by the CCNF (MMF). The SMF entity starts to maintain the UE context regarding this session. For example, the UE session context in the SMF can include, among other things, the following parameters. The temporary or permanent ID of the UE, the corresponding session ID Session type (e.g., IPv4 / IPv6, non-IP, Ethernet) Session continuity and / or service continuity mode (e.g., session and service continuity (SSC) mode 1 / 2 / 3) QoS parameters (e.g., non-guaranteed bit rate (non-GBR), GBR parameters, maximum session bit rate) Policy parameters Required session subscription parameters Session state machine, etc.

[0040] In other words, regardless of the state (active or idle) of the session state machine in the SMF, the SMF maintains the UE's session context such as the above parameters.

[0041] Furthermore, if the UE 34 is in a persistent ready mobility state from the perspective of the NG CN, this results in a connection / tunnel that is permanently activated via the NG3 interface, and correspondingly, a session that is permanently in an active session state in the NG CN. The session (SM) state machine can be managed either in the (R)AN or the NG CN.

[0042] The transition of the session state from idle to active occurs, for example, 1) when data for transmission in the UL or DL is available, or 2) when a scheduled session activation is set in the SMF. In the active session state, the SMF knows the current location of the UE from the perspective of the details of the (R)AN node UP for data transfer. Correspondingly, the UPF has established a connection with the (R)AN node 30 via the NG3 interface, and the policy and QoS parameters are applied at the UPF for a given session. When there is no data in the UL or DL, or when it is not necessary to maintain a user plane connection for a specific session, the (R)AN node 30 or the UPF can trigger a transition to the idle session state. Note that since the UE's context is retained in the NG CN (e.g., the SMF) upon deactivation of the connection, the deactivation of the UP connection is different from the release of the session. In the idle session state, the UPF does not have a connection established via the NG3 interface, and the SMF does not know the details and the exact MM mobility state (i.e., registration pending or ready) of the (R)AN node UP.

[0043] When the SMF (e.g., SMF-A) for a given session is in the idle state, at the CP, the SMF does not know the details of the (R)AN node UP, such as the IP address, tunnel identifier, transport port ID, or other parameters. The SMF has the UE context for this session, including, for example, QoS parameters, policy parameters (e.g., charging policy and application detection policy), or necessary session subscription parameters. At the UP, the UPF does not have a connection to the (R)AN node 30 (e.g., does not have an established tunnel).

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

[0045] This specification focuses on the procedures for session activation and deactivation (i.e., activation / deactivation of the UP connection). This is different from the procedures for establishing a new session or releasing an existing session. For example, establishing a new session means establishing the UE's SM session context in the SMF, the session context in the UE 34 itself, and the exchange of corresponding NAS SM messages between the UE 34 and the SMF. For each established session, it is assumed that the SMF and the MMF 32 maintain a signaling association for exchanging session-related signaling.

[0046] In another example, releasing an existing session means deleting the SM context in the SMF, UPF, and UE. For example, when the UE 34 is detached from the network, i.e., when the MM state is deregistered, the MMF 32 triggers the session release procedure, but this is also not within the scope of this specification.

[0047] This specification proposes that the CCNF (e.g., MMF) 32 maintains a UE context that includes knowledge about the session (SM) state within the SMF. In other words, the MMF 32 knows the session state (idle or active) of all configured SMFs for an established session. In addition to the mobility (MM) context, the MMF 32 also maintains information for all established sessions. For example, since the MMF 32 needs to know whether session A is activated, i.e., whether SMF-A is in an active state, whenever the (R)AN node changes, the MMF 32 can update the SMF with details of the new (R)AN node (e.g., IP address, tunnel identifier, transport port ID, or other parameters). On the other hand, when session A is deactivated, i.e., when SMF-A is in an idle state, the MMF 32 does not need to update the SMF when the (R)AN node changes. As one option, the session state as shown in FIG. 6 can be maintained by the MMF 32 alone or by both the MMF 32 and the SMF.

[0048] For this purpose, the signaling exchange between the SMF and the MMF 32 can be based on various options. Direct / explicit signaling (bidirectional) between the SMF and the MMF 32 is used to exchange information about the current session state. The SMF can notify the MMF 32 about the state of the session whenever the session state changes. If the MMF 32 knows that a particular session is in an active state, the MMF 32 notifies the SMF corresponding to this session about changes in the (R)AN node, other radio access technology (RAT) events (e.g., RAT change) and other possible mobility events. Also, during the active session state, the SMF may notify the MMF 32 about, for example, load balancing or UPF changes due to other events where the UPF of this session can be changed. Alternatively, since MMF32 may derive the session state based on the NAS signaling between UE34 and the SMF, there may be no explicit signaling between the SMF and MMF32 required to notify the change of the session state.

[0049] Generally, the SMF does not need to maintain the current MM state information. For example, when a specific session is in the idle state, the SMF does not need to know whether UE34 changes from the ready mobility state to the standby mobility state due to the transmission of UL or DL data for other sessions. In contrast, when the session is in the active state, the corresponding SMF needs to know the details of the (R)AN node (UP details such as IP address and / or tunnel endpoint ID), other RAT events (RAT change), and the change from the ready MM state to the standby MM state. The latter event of the change from the ready MM state to the standby MM state results in triggering the SMF to invalidate the NG3 connection / tunnel at the UPF.

[0050] Assuming that the session state (idle, active) is maintained within UE34 and the SMF, a direct signaling exchange between UE34 and the SMF is advantageous. Such a signaling exchange is based on NAS SM signaling improved with additional parameters such as the session ID, or an instruction for the activation or deactivation of the UP connection.

[0051] Considering various trigger sources, several procedures covering session activation and deactivation are described below.

[0052] Solution 1: Session activation when there are no other active sessions (e.g., the UE is in the standby MM state) The solution described here relates to a scenario where multiple sessions are already established (e.g., for different network slices or different PDU sessions), and the UE 34 is in a standby mobility state. This means that all sessions are in the idle session state. When downlink data arrives for a given session, the solution proposed here enables only this particular session, or alternatively, enables another session as well, while allowing the other existing sessions to remain in the idle state.

[0053] Solution 1.1: Indication of the session ID to the UE during the paging procedure In particular, Figure 7 shows the existence of two sessions already established for a given UE 34. This means that the UE 34 has an IP configuration for each session and can send and receive data on each session. When the UE 34 is in the standby mobility state (shown as the standby state of the CCNF 32), the states of the corresponding Session #1 (represented by the SMF1 42 in the CP) and Session #2 (represented by the SMF2 44 in the CP) are in the idle state. In the UP, the UPF1 46 and UPF2 48 have a UE - related context (e.g., for applying policies for the configured UE IP address and association with the corresponding CPF such as the SMF), but there is no connection / tunnel to the (R)AN node 30 for sending packets.

[0054] The steps shown in Figure 7 are described in detail as follows. Step (1) Downlink data arrives at the UPF2 48. Since Session #2 is in the idle state, the UPF2 48 has no established connection / tunnel to any (R)AN node 30. Assume that there is an NG4 session established between the CPF and the UPF for a given UE 34. Therefore, the UPF2 48 requests the CPF corresponding to this session (e.g., SMF2 44) to start session activation.

[0055] Step (2) UPF2 48 starts the procedure to activate the user plane connection to the (R)AN (e.g., NG3 tunnel). UPF2 48 sends an Activate session request to SMF2 44. This message is also called the same as the Create session request, NG3 / UP session request, or the corresponding Sx interface related message defined in TS23.214. The Activate session request can include one or more of the following information elements, namely, the temporary or permanent identifier of the UE, the session identifier, the DL packet buffering indicator, and one or more of the other parameters.

[0056] Step (3) SMF2 44 receives a request from UPF2 48, verifies the message, and determines the corresponding UE context and session that need to be activated. SMF2 44 sends an Activate session request to CCNF (e.g., MMF) 32. Similar to step (2), this message may be called differently, such as Create session request (or NG3 / UP session request), as long as the message aims to activate / establish the UP connection between the (R)AN node 30 and the UPF. This message may also be called Session activation request or something else representing the activation of an existing PDN (PDU / bearer) context. The request from SMF2 44 may include UE ID, session ID, UPF ID (e.g., IP address, tunneling endpoint ID, and / or transport layer port ID, etc., required for NG3 tunnel establishment), necessary QoS indicators, optionally security key, and other parameters. Depending on the power-saving mode, the Activate session request may include user packets to be buffered. SMF2 44 determines whether another UPF receiving services from the same SMF2 44 already has an active session. If this is not the case, SMF2 44 requests the associated CCNF (e.g., MMF) 32 to execute the session activation procedure towards the (R)AN as needed.

[0057] The security key is available when there is another security required for a specific UP session and the key is stored in the SMF.

[0058] Step (4) CCNF (e.g., MMF) 32 determines whether UE34 is in the idle mobility state or the ready mobility state. In this example, UE34 is in the idle state and, for example, does not know the location of the (R)AN, so CCNF32 starts the paging procedure.

[0059] Step (5) The CCNF 32 sends a paging request to the (R)AN node 30 where the UE 34 is likely to camp. In this paging message, the CCNF 32 has one or more session IDs. The session ID can be any of an APN, a slice ID, a slice instance ID, or a service ID. The CCNF 32 includes a plurality of session IDs based on the subscriber data within the CCNF 32 obtained from the HSS. The additional session ID may be related to the original session ID corresponding to the SMF 2 44 in this flow or may be completely independent of the original session ID.

[0060]

[0061]

[0062] ​​UE34 can include the session ID in the NAS service request message to indicate to the MMF (which is part of CCNF32) that the session ID has been correctly processed at UE34. Since CCNF32 can have a front-end function for NAS signaling, the NAS service request message after reaching the front-end can be internally transferred to the correct MMF for further processing. If the session ID is missing in the service request message, this may be regarded as an implicit indicator that UE34 could not process the session ID of the paging message.

[0063] Step (8) CCNF (e.g., MMF) 32 determines (interrelatedly) that the NAS service request message is a result of the paging procedure. CCNF32 determines that only the sessions requested by SMF2 44 need to be activated. CCNF32 generates the corresponding UE context setup request message and sends it to the (R)AN node 30. The UE context setup request message includes the session ID parameter in addition to other UE parameters such as the required QoS indicator and security parameters. If multiple sessions need to be activated, this step (8) can be executed for each session or all the requested sessions can be activated in one procedure.

[0064] Step (9) The (R)AN node 30 executes a radio connection reset shown as radio resource control (RRC) connection reset in the figure. During this procedure, the (R)AN node 30 indicates the session ID parameter to UE34.

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

[0066] Step (10) The (R)AN node 30 responds to the request in step (8) regarding the establishment of the radio connection. The (R)AN node 30 transmits, for example, a UE context setup response message. This response can be positive or negative. The UE context setup response message includes the UP identifier (IP address and tunneling endpoint ID, and / or transport layer port ID) of the (R)AN node 30 shown as (R)AN UPF ID in the figure. If the CCNF 32 decides to add an additional session ID in step (5), the CCNF 32 starts the activation of the session towards the relevant UPF for each additional session. The CCNF 32 notifies all relevant UPFs via the relevant SMF of the UP identifier (IP address, tunneling endpoint ID, and / or transport layer port ID) of the (R)AN node 30 shown as (R)AN UPF ID in the figure.

[0067] Step (11) The CCNF 32 responds to the SMF2 44 corresponding to the request in step (3). For example, the CCNF 32 transmits an Activate session response message that can include an indication regarding the successful or failed activation of the session corresponding to the session ID. This message also includes the session ID parameter in addition to other UE parameters such as the requested QoS indication (or modified QoS parameters) and security parameters.

[0068] The SMF2 44 derives the policies and QoS parameters to be applied at the UPF2 48.

[0069] SMF2 44 transitions from the idle session state to the active session state.

[0070] Step (12) SMF2 44 responds to the procedure of step (2). SMF2 44 establishes or modifies the UE context required at UPF2 48 by sending an Activate session response message. This message can include, among other things, parameters for policy enforcement (traffic QoS indicators, traffic gating operations, session maximum bitrate, etc.), (R)AN UPF ID (including (R)AN node IP address, tunneling endpoint ID, and / or transport layer port ID), charging-related settings (e.g., for charging data record (CDR) creation and / or online / offline charging session establishment), and optionally security parameters.

[0071] Note that security parameters are required when security terminates at a CN UPF node such as UPF2 48. When security terminates at the (R)AN node 30, security parameters are not required in this step.

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

[0073] Solution 1.2: Indication of the session ID to the UE during a service request or the corresponding RRC establishment procedure Figure 8 shows an alternative solution in which the paging procedure is enhanced to include a session ID parameter in the paging request message.

[0074] Figure 8 shows that the paging procedure is shown to UE34 during the RRC connection establishment procedure when the paging message does not include a session ID and includes a session ID for the activation of one PDU / PDN session. Since the remaining steps are the same as in Figure 7, only steps (5)-(9) are described in detail below.

[0075] Step (5) CCNF32 sends a paging request to the (R)AN node 30 where UE34 is likely to camp. The paging request message does not include a session ID parameter to indicate to UE34 which session should be activated.

[0076] Step (6) The (R)AN node 30 performs paging via the radio interface. This message does not include a session ID as in step (5).

[0077] After UE34 receives the paging message in step (7), UE34 executes radio connection establishment with (R)AN node 30 and sends a NAS service request message to CCNF32 via NG1.

[0078] Step (8) CCNF32 determines that the NAS service request message is the result of the paging procedure (there is a correlation). CCNF32 determines that it is necessary to activate only the sessions requested by SMF2 44 in step (3). CCNF (e.g., MMF) 32 changes the UE's mobility state from the idle state to the ready state.

[0079] CCNF32 generates a corresponding UE context setup request message and sends it to (R)AN node 30. The UE context setup request message includes a session ID parameter in addition to other UE parameters such as QoS and security parameters. If multiple sessions need to be activated, this step (8) is executed for each session or all the requested sessions are activated at once in one procedure (e.g., by including a list of all session IDs and corresponding parameters).

[0080] Step (9) (R)AN node 30 executes a radio connection reconfiguration shown as RRC connection reconfiguration in the figure. During this procedure, (R)AN node 30 instructs the UE with the session ID parameter for the session to be activated.

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

[0082] Steps (13) to (15) of FIG. 7 can be similarly executed in Solution 1.2 (not shown in FIG. 8).

[0083] The selection between the solution options shown in FIG. 7 or FIG. 8 can be made in the CCNF (e.g., MMF) 32 based on the function of the (R)AN node 30 or based on the function of the UE 34. The function of the UE regarding the supported paging function can be exchanged during the attach procedure or other mobility procedures via NASMM signaling. The function of the (R)AN node can be exchanged during the interface setup between the (R)AN node 30 and the CCNF 32 (e.g., NG2 interface or S1-MME setup exchange).

[0084] Solution 2: Session activation when there are other active sessions (e.g., the UE is in the MM ready state) In the scenario solved by Solution 1, it is assumed that there are no other active sessions (e.g., UE 34 is in the standby mobility state), while in Solution 2, it is assumed that UE 34 is in the ready mobility state while DL data arrives at the session in the idle state. In particular, considering FIG. 9, UE 34 is assumed to have an active session context for Session #1 terminated at UPF1 46.

[0085] The particular problem here is that UE 34 already has an existing PDU session (e.g., SM) context in the idle session state, and the established radio connection must be linked to this one PDU context out of multiple existing PDU session contexts. It is proposed that such a linkage between the new data radio connection / bearer and the existing session context in UE 34 is performed by using the session ID.

[0086] FIG. 9 shows a possible Solution 2.1 for enabling an additional session when other sessions are already in the active state. This alternative, Solution 2.1, is based on a new UE context change request procedure.

[0087] The steps in Figure 9 are described as follows.

[0088] Step (1) is similar to step (1) in Figure 7.

[0089] Step (2) is similar to step (2) in Figure 7.

[0090] Step (3) is similar to step (3) in Figure 7.

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

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

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

[0094] Based on the received session ID, the UE 34 activates the corresponding service, application, or existing PDN / APN / PDU / bearer context. The UE 34 does not additionally activate the existing PDN / APN / PDU / bearer context. In other words, the UE 34 associates the newly established data radio bearer with the existing PDN / APN / PDU / bearer context based on the session ID parameter.

[0095] Step (7) The (R)AN node 30 responds to the CCNF 32. For example, the (R)AN node 30 can send a UE context change response message for the request in step (5).

[0096] Step (8) is similar to step (11) in FIG. 7. The SMF 2 44 transitions from the idle session state to the active session state.

[0097] Step (9) is similar to step (12) in FIG. 7.

[0098] Note that steps (13) to (15) in FIG. 7 can also be executed in the same way in Solution 2.1 (not shown in FIG. 9).

[0099] FIG. 10 shows another alternative Solution 2.2 in which the NAS SM signaling between the SMF 2 44 and the UE 34 is used for the activation of session 2 towards the UPF 2 48.

[0100] The steps in FIG. 10 are described as follows.

[0101] Step (1) is similar to step (1) in FIG. 7

[0102] Step (2) is similar to step (2) in FIG. 7

[0103] Step (3) SMF2 44 generates a NAS SM message (exemplarily called NAS SM activation request) and sends it towards UE 34. This NAS message includes a UE ID, a session ID, a cause value (e.g., activation, modification, deletion) and other parameters. There can be multiple options for sending the NAS SM activation request message to UE34.

[0104] (A) It is sent via MMF32 by encapsulating the NAS SM activation request message into an Activate session request message from SMF2 44 to MMF32.

[0105] (B) It is sent in a separate transmission / transport message between SMF2 44 and MMF32.

[0106] (C) It is sent to the NAS front-end function within CCNF32, and the NAS front-end function transfers the message to UE34, that is, the NAS SM message does not pass through MMF32. In this latter case (C), in order to notify MMF32 about the need to activate session #2 (UP connection), SMF2 44 needs to send another message, e.g., an Activate session request message, to MMF 32.

[0107] Step (4) CCNF (e.g., MMF) 32 determines that UE34 is in the ready mobility state and that the session corresponding to the "session ID" parameter needs to be activated. Further, CCNF32 needs to route and encapsulate the NAS SM activation request towards the (R)AN node 30. CCNF32 can initiate a UE context change procedure that is used to update the UE context within the (R)AN node 30 with the new session parameters.

[0108] Step (5) CCNF32, for example, sends a UE context change request message. This message includes the session ID parameter received during step (3) in addition to other UE parameters such as QoS parameters and security parameters. CCNF32 sends a NAS SM activation request towards (R)AN node 30 either within the UE context change request message or within another NG2 message used for the transport of NAS signaling, for example, within an NG DL transport message (not shown in FIG. 10).

[0109] Step (6) This step may include the transmission of two independent messages. Step (6.a) represents an example of a radio resource control (RRC) DL direct transfer message for sending a NAS SM activation request towards UE34. In step (6.b), (R)AN node 30 performs a radio connection reconfiguration procedure shown as an RRC connection re-establishment, similar to step (6) in FIG. 9.

[0110] Based on the received NAS SM activation request, UE34 activates the corresponding service, application, or existing PDN / APN / PDU / bearer context. UE34 does not additionally activate an existing PDN / APN / PDU / bearer context. In other words, UE34 associates the newly established data radio bearer with the existing PDN / APN / PDU / bearer context based on the session ID parameter.

[0111] Step (7) (R)AN node 30 responds to CCNF32. For example, (R)AN node 30 can send a UE context change response message in response to the request in step (5).

[0112] Step (8) UE34 generates a NAS SM activation response message and sends it to SMF2 44. This NAS SM message can be sent via an RRC UL direct transfer message.

[0113] Step (9) The (R)AN node 30 receives the RRC UL direct transfer message, extracts the NAS SM activation response message, and transfers it to the CCNF32.

[0114] Step (10) is similar to step (11) in FIG. 7. Further, the CCNF (MMF) 32 transfers the NAS SM activation response message to the SMF2 44 as part of the Activate session response message or as part of a new transfer message between the MMF32 and the SMF2 44.

[0115] The SMF2 44 transitions from the idle session state to the active session state.

[0116] Step (11) is similar to step (12) in FIG. 7.

[0117] Note that steps (13) to (15) in FIG. 7 can also be executed in Solution 2.2 (not shown in FIG. 10).

[0118] Alternatively, in Solution 2.2, the SMF2 44 may trigger the activation of the session by itself without being triggered by the UPF2 48. This is possible if there is a scheduled session activation within the SMF2 44. Such scheduling can be based on timers or clocks operating within the SMF2 44 as part of the processing of the UE's SM context within the SMF2 44. The SMF2 44 triggers the establishment of the UP connection by executing step (3) towards the MMF32 based on such a clock for scheduling, and executes a new step for inserting UP-related information towards the UPF2 48 (basically the above step (11)).

[0119] In summary, Solution 2.1 and Solution 2.2 enable the activation of individual sessions (UP connections) while other UP connections exist.

[0120] Solution 3: Session activation triggered by UL data (at the UE) While Solutions 1 and 2 (along with their variations) explain the activation of the UP connection triggered by DL data (in the UPF), this solution explains the activation of one UP connection triggered by UL data (in the UE).

[0121] Figure 11 shows that UE34 has two session contexts for Session #1 and Session #2. Two different cases are described. In case (A), UE34 is in the idle mobility (MM) state, and thus all session states are in the idle state. In case (B), UE34 is in the ready mobility (MM) state, and Session #1 is in use, i.e., a radio connection and an NG3 connection are established.

[0122] The steps in Figure 11 are described in detail as follows.

[0123] Step (1) UL data from a specific application / service must be sent by UE34, for example, on Session #2. Since Session #2 is in the idle state, UE34 needs to activate the UP connection to send the data.

[0124] Step (2) If UE34 is in the MM idle state, UE34 first needs to activate the radio CP connection (RRC) and the NAS connection by starting the service request procedure. For this purpose, UE34 first establishes the RRC connection.

[0125] In step (3), if UE34 is in the MM waiting state, UE34 sends a NAS service request message to activate the NAS signaling connection. The NAS service request message can also include, among other things, the "session ID" parameter. If the NAS signaling connection terminates at the NAS front-end function, the NAS front-end function transfers the NAS service request message to MMF32.

[0126] In step (4), CCNF (for example, MMF) 32 verifies and processes the NAS service request message. Based on the "session ID" parameter, MMF32 determines which session needs to be activated. In this specific example, MMF32 determines that it needs to activate session #2. MMF32 starts the procedure to activate the UP connection towards SMF2 44. MMF32 sends an Activate session request message (or a message similar to that already described in step (3) of FIG. 7). This message includes, among other parameters, UE ID, session ID, cause value (for example, activation, modification, deletion), etc.

[0127] In step (5), if UE34 is in the MM ready state, UE34 already has a signaling connection towards the NG CN. UE34 can start the NAS connection activation procedure. For this purpose, UE34 sends a NAS SM session activation request message towards the corresponding SMF, in this specific example, SMF2 44. The NAS SM session activation request message can be transferred towards SMF2 44 via the common NAS front-end function, or transferred towards SMF2 44 via MMF32. The NAS SM session activation request message also includes parameters such as UE ID, session ID, and / or cause value (for example, activation, modification, deletion), etc.

[0128] In step (6), SMF2 44 receives the message in either step (4) or step (5) and processes it. SMF2 44 determines the QoS parameters and other policy parameters to be applied at UPF2 48. SMF2 44 initiates a session activation procedure for UPF2 48. SMF2 44 sends an Activate session request message to UPF2 48, including, inter alia, QoS and policy parameters and optionally NG3-specific parameters (such as tunneling information like the IP address used by UPF2 48 and / or the General Packet Radio Service Tunneling Protocol (GTP) tunnel endpoint identifier (TEID)).

[0129]

[0130]

[0131] In step (7), UPF2 48 receives and processes the Activate session request message. UPF2 48 sends an Activate session response message to SMF2 44, indicating the activation result cause value and NG3-specific parameters (such as tunneling information like the IP address used by UPF2 48 and / or the GTP TEID) if necessary.In step (8), if necessary, SMF2 44 may send a NAS SM message, such as a NAS SM session activation response message, to UE34. Such a NAS SM message can include various session management parameters, such as parameters for session QoS or policy changes.Step (9) Depending on the option (A) or (B) above, SMF2 44 may perform another operation. In one option, SMF2 44 responds to step (4). In another option, SMF2 44 may initiate a session activation procedure for the CCNF (e.g., MMF) 32 and the (R)AN node 30. For example, SMF2 44 may send an Activate session request / response message containing a session ID and UPF NG3-related information (e.g., tunneling information such as the IP address of UPF2 48 and / or GTP TEID) to the CCNF (e.g., MMF) 32.

[0132] Step (10) Depending on the initial MM state of the UE34, i.e., depending on options (A) and (B), the CCNF (e.g., MMF) 32 initiates different procedures.

[0133] In the case of option (A), i.e., when the UE34 is in the MM standby state, the CCNF32 initiates a UE context setup procedure for the (R)AN node 30 by sending a UE context setup request message. This message may include, inter alia, a session ID, QoS parameters, security parameters, and other parameters necessary for the establishment of a radio connection, e.g., UPF NG3-related information (e.g., tunneling information such as the IP address of UPF2 48 and / or GTP TEID). In the case of option (B), i.e., when the UE 34 is in the MM ready state, the CCNF (MMF) 32 starts a UE context change procedure towards the (R)AN node 30. The CCNF (MMF) 32 changes the radio connection and sends a UE context change request message to the (R)AN node 30 to assist in the establishment of the NG3 connection to the UPF2 48. The UE context change request message can include, among other things, the session ID, QoS parameters, security parameters, and other parameters necessary for the establishment of the radio connection, such as tunneling information like the IP address of the UPF2 48 and / or the GTP TEID.

[0134] Step (11) The (R)AN node 30 executes an RRC connection reconfiguration to establish the data radio connection for session #2. For this purpose, the (R)AN node 30 executes the RRC connection reconfiguration procedure.

[0135] Step (12) The (R)AN node 30 responds to step (10). The (R)AN node 30 sends a UE context setup response message containing (R)AN node UP NG3 related information (such as tunneling information like the IP address of the UPF2 48 and / or the GTP TEID) to the CCNF 32.

[0136] Note that several options are conceivable.

[0137] Option 1: The (R)AN node 30 sends a UE context setup response message to the MMF32.

[0138] Option 2: The (R)AN node 30 sends a UE context setup response message to the NG2 front-end function within the CCNF32. The front-end function can transfer the content of the UE context setup response message to the MMF32 and / or the SMF2 44.

[0139] Option 3: The (R)AN node 30 sends a UE context setup response message to the SMF2 44.

[0140] Option 4: The (R)AN node 30 sends two different messages to the MMF32 and the SMF2 44. The message to the MMF32 confirms the success of establishing a new data radio connection, while the message to the SMF2 44 further conveys the (R)AN node UP NG3 related information (e.g., tunneling information such as the IP address of the UPF2 48 and / or the GTP TEID).

[0141] Step (13) In the case of Option 1 of the above Step (12), the MMF32 starts a session update procedure towards the SMF2 44 to update the (R)AN node UP NG3 related information (e.g., tunneling information such as the IP address of the UPF2 48 and / or the GTP TEID).

[0142] Step (14) The SMF2 44 starts a session update procedure towards the UPF2 48. The SMF2 44 sends an Update session request message containing the (R)AN node UP NG3 related information (e.g., tunneling information such as the IP address of the UPF2 48 and / or the GTP TEID) to the UPF2 48.

[0143] Solution 4: Deactivating one session while other sessions remain active Solution 4.1: Session deactivation initiated by the RAN node To manage sessions independently (i.e., per session), it is assumed that it is possible to release the UP connection of one session (referred to herein as "session deactivation"). In other words, it is possible to release one radio connection and the NG3 connection while keeping the connections of the remaining existing sessions active.

[0144] In one solution, it is assumed that the (R)AN node 30 triggers the invalidation of a session. Usually, the (R)AN node 30 manages radio-related parameters such as the UE inactivity timer, the active discontinuous reception (DRX) cycle, the idle DRX cycle, etc. This solution proposes to maintain such radio parameters for each session. Thus, when multiple radio connections for multiple sessions are activated, the (R)AN node 30 maintains a so-called "session inactivity timer" for each activated session. The "session inactivity timer" is applied to one session (a radio connection such as an LTE data radio bearer (DRB)), and thus is different from the UE inactivity timer.

[0145] Figure 12 illustrates the case where two sessions are active and one of the two sessions becomes idle because there is no user plane activity within a predetermined UE inactivity period determined by the (R)AN node 30. First, the thick arrows indicate the data flows in the UL and DL between the UE 34 and the UPF1 46, and between the UE 34 and the UPF2 48.

[0146] The steps in Figure 12 are described as follows.

[0147] Step (1) The UE inactivity timer in the (R)AN node 30 expires for session #1. This means that the (R)AN node 30 has determined that no data has been transmitted in the UL or DL during a given period shown as the "inactivity timer" for session #1.

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

[0149] Option (2.a) If this is not the last active session, the (R)AN node 30 initiates a UE connection release procedure to the CCNF 32. The (R)AN node 30 sends a UE connection release request message to the CCNF 32. This message includes the UE's temporary / permanent ID, an indicator of which session(s) need to be invalidated (e.g., session #1), a cause value, and other parameters.

[0150] Option (2.b) If this is the last active session (e.g., an existing radio connection), the (R)AN node 30 initiates a UE context release procedure. As a result, the mobility (MM) state changes from ready to standby. This message includes the UE's temporary / permanent ID, an indicator regarding the cause value, and other parameters.

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

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

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

[0154] Step (6) SMF1 42 sends an NG3 release response message containing the UE ID, session ID, and other parameters to CCNF 32.

[0155] Step (7) CCNF32 has two options depending on the number of remaining active sessions.

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

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

[0158] Step (8) There are two options depending on the number of remaining active sessions and the instruction from CCNF32.

[0159] Option (8.a) The (R)AN node 30 executes an RRC connection change procedure. For this purpose, the (R)AN node 30 sends an RRC connection reconfiguration message to UE34 to release the data radio connection to the relevant session #1. Other active radio connections are not released.

[0160] Option (8.b): If this is the last remaining radio connection for UE34, the (R)AN node 30 executes the RRC connection release procedure. For this purpose, the (R)AN node 30 sends an RRC connection reconfiguration message to UE34 to release the radio connection to the associated session #1.

[0161] If Option (8.a) is executed, UE34 transitions the state of the corresponding session (e.g., session #1) from the active state to the idle state.

[0162] Importantly, in UE34, the context of session #1 is maintained in the idle state without being deleted, while other session states may be in the active state.

[0163] Step (9): The (R)AN node 30 either (9.a) sends a UE connection release complete message to the CCNF32 or (9.b) sends a UE context release complete message to the CCNF32.

[0164] Assuming that the invalidated session #1 is not the last active session, the lower part of Figure 12 shows that after executing the invalidation procedure for session #1, the radio connection and NG3 connection / tunnel of session #2 are maintained.

[0165] Solution 4.2: Session deactivation initiated by the UPF Figure 13 illustrates an alternative solution where the session deactivation procedure is initiated by the UPF of the corresponding session. This solution proposes that each UPF manages an inactivity timer called the "session inactivity timer". This timer can be set by the SMF when the session is activated. For example, step (12) in Figure 7 or Figure 8 can include the "session inactivity timer" parameter. The UPF measures the time during which no DL or UL data is exchanged. When the measured inactivity time of the data reaches the value of the "session inactivity timer" parameter, the UPF triggers the UP connection release procedure.

[0166] First, UE 34 is in the MM ready state, and session #1 and session #2 are activated. This is indicated by the thick arrows corresponding to two radio connections and two NG3 connections between (R)AN node 30 and UPF1 46, and between (R)AN node 30 and UPF2 48.

[0167] The steps in Figure 13 are described as follows.

[0168] Step (1) UPF1 46 detects that the session inactivity timer has expired. This means that UPF1 46 has determined that no data has been transmitted in UL or DL for a given period shown as the "inactivity timer" of session #1.

[0169] Step (2) UPF1 46 initiates the release request procedure for the UP connection towards the (R)AN. UPF1 46 sends an NG3 release request message (or a similar message, e.g., Deactivate session request or Release connection request) to SMF1 42. This message can include the UE ID, session ID, cause value, and other parameters.

[0170] Step (3) SMF1 42 initiates the UP connection release procedure. SMF1 42 sends an NG3 release request message (or a similar message, e.g., Deactivate session request or Release connection request) to CCNF32. This message can include the UE ID, session ID, cause value, and other parameters.

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

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

[0173] Option (4.b) If this is the last active session (e.g., there are no other active sessions and corresponding radio or NG3 connections), CCNF32 initiates the UE context release procedure. This causes the mobility (MM) state to change from ready to standby.

[0174] Step (5) There are two options depending on the number of remaining active sessions and the indication from CCNF32.

[0175] Option (5.a) The (R)AN node 30 executes the RRC connection reconfiguration procedure. For this purpose, the (R)AN node 30 sends an RRC connection reconfiguration message to the UE 34 to release the related radio connection to session #1. Assume 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. Also, the radio signaling via RRC includes an indicator (session ID) regarding the session to be deactivated. Other active radio connections are not released.

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

[0177] If Option (5.a) is executed, the UE 34 transitions the state of the corresponding session (e.g., session #1) from the active state to the idle state.

[0178] Step (6) The (R)AN node 30 either (6.a) sends a UE connection release complete message to the CCNF 32 or (6.b) sends a UE context release complete message to the CCNF 32.

[0179] Step (7) The CCNF 32 responds to the UP connection release procedure in step (3). The CCNF 32 sends an NG3 release response message (or a similar message, e.g., Deactivate session response or Release connection response) to the SMF 142. This message may include the UE ID, session ID, cause value, and other parameters.

[0180] 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, e.g., Deactivate session response or Release connection response) to UPF1 46. This message may include a UE ID, a session ID, a cause value, and other parameters.

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

[0182] Another alternative for solution 4.2 would be to use the NAS SM session deactivation procedure between SMF1 42 and UE34. SMF1 42 can use this procedure to notify UE34 about the SM context deactivation, whereby the session SM state in UE34 is changed from active to idle. Such NAS SM procedures can be initiated by SMF1 42 in parallel with steps (3), (4), and (5) in FIG. 13.

[0183] Solution 4.3: Session deactivation initiated by the UE This is an alternative way of session deactivation (i.e., release of the UP connection) where the procedure is initiated by UE34. Since UE34 can recognize the application operating at the upper layer, UE34 can determine whether the application has finished data transfer. If such an indicator is available from the upper layer to the NAS layer, the NAS layer in UE34, specifically the NAS SM part, can initiate the session deactivation procedure towards the NG CN.

[0184] In a particular example, if the application associated with session A indicates to the NAS SM instance in UE34 that the application no longer requires an UP connection, or if the NAS SM instance has recognized by some means that the active UP connection is not being used, the NAS SM instance of the UE for session A can initiate a session deactivation procedure towards the NG CN. The following steps are executed.

[0185] Step (1) UE34 initiates a NAS SM session deactivation procedure towards SMF1 42 to notify SMF1 42 that the UP connection can be released. UE34 generates a NAS SM Deactivation session request message and sends it towards the NG CN via NAS signaling. This message includes, in addition to normal NAS SM parameters, an indicator regarding UP connection deactivation and a session ID. The NG CN processes the message and forwards it to the corresponding SMF1 42.

[0186] Step (2) SMF1 42 initiates an NG3 release procedure towards UPF1 46.

[0187] Step (3) SMF1 42 initiates an NG3 release request (or Deactivate session request) procedure towards the CCNF (e.g., MMF) 32.

[0188] Step (4) MMF32 processes the NG3 release request message from SMF1 42. MMF32 initiates an NG3 release procedure (or session deactivation procedure) towards the (R)AN node 30.

[0189] Step (5) The (R)AN node 30 executes an NG3 release procedure (or session deactivation procedure) towards the UE 34, for example, by means of an RRC connection reconfiguration procedure. Also, the (R)AN node 30 modifies the context of the UE 34 by deleting the NG3 parameters of the corresponding UPF node. The (R)AN node 30 returns the result of the NG3 release procedure to the MMF 32.

[0190] Step (6) The MMF 32 changes the state of the corresponding session to idle. The MMF 32 returns the result of the NG3 release procedure to the SMF 1 42.

[0191] Step (7) The SMF 1 42 verifies the NAS SM session deactivation request message in step (1).

[0192] Note that the above steps (2)-(6) are similar to steps (3)-(7) of solution 4.2 shown in FIG. 13. The main difference between solution 4.3 and solution 4.2 is the NAS SM session deactivation procedure executed between the UE 34 and the SMF 1 42.

[0193] The following description applies to all solutions described in this specification.

[0194] The above example describes a solution for activating or deactivating one session. However, it is also possible to activate / deactivate multiple sessions simultaneously by including multiple session IDs in the corresponding message. If there are multiple PDU sessions for each data network, it may be beneficial to activate multiple sessions simultaneously assuming the same SMF controls multiple PDU sessions. In one solution, the SMF decides whether to activate one PDU session (e.g., the session to which DL data arrives) or some or all of the PDU sessions controlled by this SMF (which would probably mean some or all of the PDU sessions for a particular network slice or data network).

[0195] Note that the signaling to / from the (R)AN node 30 via the NG2 interface can be terminated by the common front-end NG2 termination function in the CCNF32. The common front-end NG2 function can route / forward the content of the NG2 message to the MMF32 and / or the SMF2 44. Also, the (R)AN node 30 can send two different NG2 messages, namely, an individual message to the MMF32 and an individual message to the SMF2 44. The message to the MMF32 may require MM-specific operations or can also confirm the success of establishing / releasing a data radio connection. The message to the SMF2 44 can mainly include (R)AN node UP NG3-related information (e.g., tunneling information such as the IP address of the UPF2 48 and / or the GTP TEID).

[0196] Note that all the above figures show a scenario with one UPF per session. However, this specification is applicable to scenarios where there are multiple different UPFs receiving services from one SMF. In such cases, it can be assumed that there are multiple PDU sessions for the same data network. These sessions can be activated independently for each UPF. In such cases, the activated sessions exist for other UPFs receiving services from the same SMF2 44 (i.e., UE34 is in the ready mobility state and SMF2 44 is in the active session state). At this time, SMF2 44 does not need to initiate the paging procedure. Instead, SMF2 44 can change the existing session or initiate activation in a new UP session. For this purpose, SM requests CCNF(MMF)32 to add a new UP session containing the information of UPF2 48.

[0197] Collocation of control plane functions such as MMF and SMF within a common control plane function entity is possible.

[0198] The proposed solution is based on the following principles. The session management function (SMF) and the mobility management function (MMF) are separated into different network functions. In the specific case where a UE is registered to multiple network slice instances, the UE is served by multiple SMFs, i.e., multiple PDU sessions are established. For a given UE, multiple PDU sessions (to the same or different network slices) are established. The PDU session can be in the idle state or the active state. The UP connection (including the data radio connection and the NG3 tunnel establishment) can be activated for one PDU session. The UP connections for other PDU sessions (to the same or other network slices) can be activated / deactivated independently. Procedures for activating and deactivating PDU sessions are proposed. Activation of a PDU session is a transition to the "active" session state in the SMF, and the UP connection is established. Deactivation of a PDU session is a transition to the "idle" session state in the SMF, and the UP connection is released.

[0199] Description of general nodes The following description applies to all solutions described in this specification.

[0200] Effect on the UE Most of the solutions described in this specification are described including the UE as an NG UE, but the solutions can also be applied to 2G, 3G, and 4G access systems, i.e., even if the UE is a 2G / 3G / 4G UE.

[0201] According to the above exemplary embodiment, the UE34 is modified to be able to process signaling to / from (R)AN and CN functional entities (e.g., (R)AN nodes, MMF, SMF). Further, the UE34 can receive, process, and transmit corresponding information to (R)AN and CN functional entities. The UE34 can be schematically described by a block diagram as shown in FIG. 14.

[0202] FIG. 14 is a block diagram showing the main components of a user equipment (UE) 34 (represented as "NG UE" in the figure) as shown in FIG. 1, for example. As shown, the UE 34 has a transceiver circuit 50 operable to transmit and receive signals with a radio access network node 30 via one or more antennas 52. Such a radio access network node 30 (represented as "NG(R)AN" in FIG. 1, "RAN" in FIG. 2, and "AN" in FIG. 4) may include a base station and / or any other suitable access point / transmission point. The UE 34 has a controller 54 for controlling the operation of the UE 34. The controller 54 is associated with a memory 56 and coupled to the transceiver circuit 50. The UE 34 may have all the normal functions of a conventional mobile device / cellular phone (such as a user interface), or may be provided as appropriate by any one or any combination of hardware, software, and firmware. The software may be pre-installed in the memory 56, or may be downloaded, for example, via a telecommunications network or from a removable data storage device (RMD).

[0203] In this example, the controller 54 controls the overall operation of the UE 34 by program instructions or software instructions stored in the memory 56. As shown, these software instructions include, among other things, an operating system 58, a communication control module 60, and a transceiver control module 62 (shown as forming part of the communication control module 60).

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

[0205] Effect on the MMF / SMF According to the above exemplary embodiments, the Mobility Management Function (MMF) or the Session Management Function (SMF) is modified / extended so that it can operate according to the proposed solution. The MMF or SMF can be schematically illustrated in a block diagram as shown in FIG. 15.

[0206] FIG. 15 is a block diagram showing the main components of the Mobility Management Function (MMF) / Session Management Function (SMF) node shown in FIG. 1, for example. Although the MMF and SMF are shown as part of an integrated control function entity, their functions may be implemented in separate nodes.

[0207] As shown in the figure, the MMF / SMF has a transceiver circuit 64 and a network interface 66 for transmitting and receiving signals with other network nodes (including UE34). The MMF / SMF has a controller 68 for controlling the operation of the MMF / SMF node. The controller 68 is associated with a memory 70. Software may be pre-installed in the memory 70, for example, or downloaded 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 by program instructions or software instructions stored in the memory 70. As shown in the figure, these software instructions include, among other things, an operating system 72, a communication control module 74, and a transceiver control module 76 (shown as forming part of the communication control module 74).

[0208] The communication control module 74 controls the communication between the MMF / SMF and other network entities connected to the MMF / SMF (for example, a base station / access node, or UE34 if connected to a base station / access node).

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

[0210] 1) The UE can link the activation or deactivation procedure of the data radio connection to the existing PDU session management context within the UE. a) Such a linkage in the UE is based on a session ID indicator sent in the relevant signaling from the SMF to the UE.

[0211] 2) The deactivation of the user plane connection is a) by the user plane function in the core network, or b) by the UE via NAS SM signaling triggered by the session management function in the NG CN.

[0212] It can be seen that the above exemplary embodiments describe a method for independently activating or deactivating the user plane connection for each PDU session or network slice. This method includes the following. 1) The activation or deactivation of the user plane connection is initiated from the SMF based on the following. a) A trigger from the UPF (due to DL data for session activation arriving or a timer for session deactivation expiring), b) A trigger from the UE (due to transmitting UL data for session activation or the UP connection for session deactivation becoming unnecessary). 2) The control plane session management function, mobility management function, access network, and terminal use the session ID as a reference ID for referring to the same session.

[0213] Advantages It is understood that the above embodiments provide several advantages including, but not limited to, the following. (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 the radio and NG2 and NG3 interfaces in the case of UE mobility. (2) When the UE transmits and receives data on one specific session, only the user plane connection to this specific session is activated, thereby reducing the signaling for connection establishment for other sessions when frequent mobility state changes occur between the standby state and the ready state.

[0214] Variants and alternatives Exemplary embodiments have been described in detail as above. As will be understood by those skilled in the art, while benefiting from the invention embodied herein, many variations and alternatives can be made to the above exemplary embodiments. For the sake of explanation, only some of these alternatives and variations will be described.

[0215] In the above description, the UE and the MMF / SMF nodes have been described as having several individual modules (such as a communication control module) for ease of understanding. These modules can be provided in this way, for example, for a certain application in which an existing system is modified to implement the present invention, and also in other applications of a system designed with the features of the present invention in mind from the beginning. However, since these modules are incorporated into the operating system or the entire code, they may not be recognized as individual entities. These modules may also be implemented in software, hardware, firmware, or a combination thereof.

[0216] Each controller may include, for example, but not limited to, any suitable form of processing circuitry including the following. That is, One or more hardware-implemented computer processors Microprocessors Central Processing Unit (CPU) Arithmetic Logic Unit (ALU) Input / Output (I / O) Circuit Internal Memory / Cache (Program and / or Data) Processing Register Communication Bus (e.g., Control, Data, and / or Address Bus) Direct Memory Access (DMA) Function Hardware or Software Implemented Counters, Pointers, and / or Timers, etc.

[0217] In the above exemplary embodiments, several software modules are described. As will be understood by those skilled in the art, the software modules may be provided in compiled or uncompiled form, and may be supplied to the UE and MMF / SMF nodes as signals via a computer network or on a recording medium. Also, the functions executed by some or all of this software may be executed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the update of the UE and MMF / SMF nodes to update their functions.

[0218] Various other modifications will be apparent to those skilled in the art and are not described in further detail herein.

[0219] List of abbreviations 3GPP 3rd Generation Partnership Project: 3rd Generation Partnership Project AS Access Stratum: Access Stratum (used in this specification in the same way as RRC signaling) CCF Core Control Functions: Core Control Functions CCNF Common Control Network Functions: Common Control Network Functions CPF Control Plane Function: Control Plane Function NB, eNB: Node B, evolved Node B: Node B, evolved Node B (however, it can also be any "RAN Node" implementing 2G, 3G, 4G, or future 5G technology) E-UTRAN Evolved Universal Terrestrial Radio Access Network: Evolved Universal Terrestrial Radio Access Network (also used as EUTRAN) GGSN Gateway GPRS Support Node: Gateway GPRS Support Node GPRS General Packet Radio Service: General Packet Radio Service HPLMN Home Public Land Mobile Network: Home Public Land Mobile Network HSS Home Subscriber Server: Home Subscriber Server IE Informational Element: Information Element (used as part of a signaling message) MME Mobility Management Entity: Mobility Management Entity MMF Mobility Management Function: Mobility Management Function MNO Mobile Network Operator: Mobile Network Operator NAS Non Access Stratum: Non-Access Stratum NFV Network Function Virtualization: Network Function Virtualization NNSF NAS / Network Node Selection Function: NAS / Network Node Selection Function NSI Network Slice Instances: Network Slice Instances PCF Policy Control Function: Policy Control Function PCRF Policy and Charging Rules Function: Policy / Charging Rules Function PGW Packet Data Network Gateway: Packet Data Network Gateway PSM Power Saving Mode: Power Saving Mode RAU Routing Area Update: Routing Area Update RNC Radio Network Controller: Radio Network Controller RRC Radio Resource Control: Radio Resource Control PLMN Public Land Mobile Network: Public Land Mobile Network SCNF Slice-specific Control Plane Network Functions: Slice-specific Control Plane Network Functions SMF Session Management Function: Session Management Function SGSN Serving GPRS Support Node: Serving GPRS Support Node SGW Serving Gateway: Serving Gateway TAU Tracking Area Update: Tracking Area Update UE User Equipment: User Equipment UPF User Plane Function: User Plane Function (Similar to the SGW / PGW in EPC, any UP function used for policy / QoS enforcement, mobility, UE's IP anchor) UTRAN UMTS Terrestrial Radio Access Network: UMTS Terrestrial Radio Access Network VPLMN Visited Public Land Mobile Network: Visited Public Land Mobile Network

[0220] This application claims the benefit of priority under European Patent Application No. 16185042.5, filed on August 19, 2016, and all of the content described in the said patent application is incorporated herein by reference.

Claims

1. A method performed by a radio base station, comprising: Receiving, from a core network node, a request message for activating an existing connection, the request message including information regarding QoS parameters, when DL data arrives; Performing a radio connection reconfiguration procedure with a radio terminal based on the information regarding the QoS parameters, the information regarding the QoS parameters being information used for determining a data radio bearer; The method.

2. The method according to claim 1, wherein the request message includes a session ID.

3. The method according to claim 1, wherein the request message includes security information.

4. The method according to claim 2, wherein the radio base station performs the radio connection reconfiguration procedure based on the session ID.

5. The method according to claim 3, wherein the radio base station performs the radio connection reconfiguration procedure based on the security information.

6. Means for receiving, from a core network node, a request message for activating an existing connection, the request message including information regarding QoS parameters, when DL data arrives; and Means for performing a radio connection reconfiguration procedure with a radio terminal based on the information regarding the QoS parameters, the information regarding the QoS parameters being information used for determining a data radio bearer, in a radio base station.

7. The radio base station according to claim 6, wherein the request message includes a session ID.

8. The radio base station according to claim 6, wherein the request message includes security information.

9. The radio base station according to claim 7, wherein the radio connection reconfiguration procedure is performed based on the session ID.

10. The radio base station according to claim 8, wherein the radio connection reconfiguration procedure is performed based on the security information.

Images