Method and system for processing mobile termination data / signaling for UEs in RRC inactive state
By determining through notification messages which network entity processes MT data/signaling for UEs in RRC inactive states with long eDRX cycles, the system effectively addresses the challenge of handling MT data/signaling in 3GPP systems, optimizing resource utilization and ensuring seamless communication.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2023-08-14
- Publication Date
- 2026-04-09
AI Technical Summary
Existing 3GPP systems face challenges in handling mobile termination (MT) data/signaling when user equipment (UE) enters a long extended discontinuous reception (eDRX) cycle in the RRC inactive state, as they struggle to determine whether the Core Network (CN) or Radio Access Network (RAN) should process this data/signaling effectively.
The system determines whether the Core Network (CN) or Radio Access Network (RAN) processes MT data/signaling for UEs in an RRC inactive state with long eDRX cycles by providing notification messages, such as INITIAL CONTEXT SETUP REQUEST, UE CONTEXT MODIFICATION REQUEST, HANDOVER REQUEST, PATH SWITCH REQUEST ACKNOWLEDGE, NG/N2 SETUP RESPONSE, and AMF CONFIGURATION UPDATE, to indicate CN support for processing MT data/signaling.
This approach allows efficient handling of MT data/signaling by ensuring that the appropriate network entity, either the CN or RAN, processes the data/signaling, thereby optimizing resource utilization and ensuring seamless communication during extended RRC inactive states.
Smart Images

Figure 0007843418000018 
Figure 0007843418000019 
Figure 0007843418000020
Abstract
Description
Technical Field
[0001] (Related Application) This application claims the benefit of Provisional Patent Application No. 63 / 398317, filed on August 16, 2022, the disclosure of which is hereby incorporated by reference in its entirety. This disclosure relates to the operation of a Radio Access Network and a Core Network of a wireless device in an RRC inactive state with a long eDRX cycle.
Background Art
[0002] The study item FS_RedCap_Ph2 of 3GPP Rel-18 SA2 is to address the support of long eDRX (> 10.24 seconds) values in the RRC inactive state. The important issue is how to handle mobile termination (MT) data / signaling when the user equipment (UE) (alias: wireless device) becomes unreachable due to long eDRX in the RRC inactive state, as described in 3GPP TR 23.700-68 V.1.0.0, which is hereby incorporated by reference.
[0003] The TR describes two types of solutions called Type A) and Type B).
[0004] In a Type A (CN-based) 5G system, the NG-RAN provides the Core Network (CN) with unreachable information (such as eDRX information) when the UE enters a long eDRX RRC inactive state, and the CN processes MT data / signaling while the UE is unreachable. Using the existing CN data buffering capabilities and existing MT data / signaling processing in the CN, the CN triggers MT data / signaling when the UE is deemed reachable (for example, when the UE becomes reachable, the CN triggers NG-RAN paging even if an N3 connection exists). See, for example, Solutions 6.1, 6.3, 6.4, and 6.6 of TR 23.700-68. Solution 6.6 is an integrated solution based on Solutions 6.1, 6.3, and 6.4.
[0005] Type B: NG-RAN based) NG-RAN handles MT data / signaling while the UE is in an RRC inactive state. If the UE moves outside the RAN-based Notification area (RNA) during the unreachable period and restarts outside the RNA, UE context lookup and data transfer between NG-RAN nodes are supported via CN if there is no Xn interface between the NG-RAN nodes. See, for example, Solution 6.2, 6.2a of 3GPP TR 23.700-68.
[0006] Therefore, in Type A, the CN handles MT data / signaling when the UE is unreachable, and in Type B, the RAN handles MT data / signaling when the UE is unreachable.
[0007] These two different types of solutions can be applied to different scenarios / use cases. [Overview of the project]
[0008] Systems, methods, and apparatus are provided for processing the selection or determination of the type of solution to apply to the processing of MT data / signaling for UEs in an RRC inactive state. In some embodiments, the NG-RAN, more specifically the gNB, determines whether the CN processes the MT data / signaling for UEs that enter an RRC inactive state in a long eDRX cycle (Type A) or whether the RAN processes the MT data / signaling for UEs that enter an RRC inactive state in a long eDRX cycle (Type B). The decision by the NG-RAN is based on knowledge of the capabilities of the core network (CN) to support the processing of MT data / signaling. Optionally, the NG-RAN node may consider other policies when selecting whether Type A, Type B, or both should apply.
[0009] In some embodiments, a method is performed by a network function, such as an Access and Mobility Management Function (AMF), in a core network (CN), such as a 5G core network. This method includes the network function determining the CN's ability to support the processing of mobile terminated (MT) data / signaling by a user device (UE) during a Radio Resource Control (RRC) inactive state for a long extended discontinuous reception (eDRX) cycle (e.g., longer than 10.24 seconds), such as buffering MT data / signaling. The method further includes the network function sending a notice to a radio access network (RAN) serving the UE (e.g., a gNB in a 5G system) indicating the CN's support for processing MT data / signaling.
[0010] This notification may be sent to the radio access network (RAN) in the following messages: INITIAL CONTEXT SETUP REQUEST message, UE CONTEXT MODIFICATION REQUEST message, HANDOVER REQUEST message, PATH SWITCH REQUEST ACKNOWLEDGE message, NG / N2 SETUP RESPONSE message, and AMF CONFIGURATION UPDATE message.
[0011] In one embodiment, this notification is transmitted to the RAN in the CN Assistance Information of the RRC INACTIVE Information Element included in one of the N2 messages (shown above).
[0012] In some embodiments, a method is provided that is performed by a radio network node located within a radio access network (RAN) (e.g., a gNB in a 5G system) and connected to a core network (CN). This method includes the radio network node receiving a notification from the CN indicating CN support for processing (e.g., buffering) MT data / signaling of a user equipment (UE) used by the UE during a radio resource control (RRC) inactive state for a long extended discontinuous receive (eDRX) cycle (e.g., longer than 10.24 seconds), and determining, based on the received notification, that the CN can process MT data / signaling for the UE in the RRC inactive state for a long eDRX cycle.
[0013] This notification may be received and transmitted from CN in the CN Assistance Information of the RRC INACTIVE information element, or in other information elements that may be included in the INITIAL CONTEXT SETUP REQUEST message, UE CONTEXT MODIFICATION REQUEST message, HANDOVER REQUEST message, PATH SWITCH REQUEST ACKNOWLEDGE message, NG / N2 SETUP RESPONSE message, and AMF CONFIGURATION UPDATE message.
[0014] This notice may further indicate that the CN does not support the processing of mobile-terminated (MT) data / signaling, in which case the wireless network node may decide whether or not to process MT data / signaling at the wireless network node.
[0015] According to some embodiments, a network node is provided in a core network (CN) that implements network functions, the network node including a processing circuit and a memory containing instructions that are executed by the processing circuit to perform any of the method embodiments described herein.
[0016] According to some embodiments, a wireless network node is provided, which includes a processing circuit and a memory containing instructions that are executed by the processing circuit to perform any of the method embodiments described herein. [Brief explanation of the drawing]
[0017] The figures in the accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate some aspects of this disclosure and are useful in illustrating the principles of this disclosure together with this description.
[0018] [Figure 1] Figure 1 shows an example of a cellular communication system 300 in which embodiments of the present disclosure may be implemented;
[0019] [Figure 2] Figure 2 shows a wireless communication system represented as a 5G network architecture composed of core network functions (NFs), and the interaction between any two NFs is represented by point-to-point reference points / interfaces;
[0020] [Figure 3] Figure 3 shows a 5G network architecture that uses service-based interfaces between NFs in the control plane instead of the point-to-point reference points / interfaces used in the 5G network architecture of Figure 4;
[0021] [Figure 4] Figure 4 shows a method in a network function (e.g., AMF) of a CN according to some embodiments of the present disclosure;
[0022] [Figure 5] Figure 5 shows a method in a radio network node (e.g., gNB) of a radio access network according to some embodiments of the present disclosure;
[0023] [Figure 6] Figure 6 shows an embodiment of a radio access node according to some embodiments of the present disclosure; [Figure 7] Figure 7 shows an embodiment of a radio access node according to some embodiments of the present disclosure;
[0024] [Figure 8] Figure 8 is a schematic block diagram showing a virtualized environment in which functions implemented by some embodiments of the present disclosure can be virtualized;
[0025] [Figure 9]Figure 9 shows exemplary embodiments of wireless devices / UEs according to several embodiments of the present disclosure; [Figure 10] Figure 10 shows exemplary embodiments of wireless devices / UEs according to several embodiments of the present disclosure;
[0026] [Figure 11] Figure 11 shows an example of a communication system that implements an embodiment of the present disclosure;
[0027] [Figure 12] Figure 12 shows exemplary implementations of the UE, base station, and host computer of Figure 13 according to some embodiments of the present disclosure;
[0028] [Figure 13] Figure 13 is a flowchart showing how some embodiments of this disclosure can be implemented in a communication system; [Figure 14] Figure 14 is a flowchart showing how some embodiments of this disclosure can be implemented in a communication system; [Figure 15] Figure 15 is a flowchart showing how some embodiments of this disclosure can be implemented in a communication system; [Figure 16] Figure 16 is a flowchart showing a method implemented in a communication system according to several embodiments of the present disclosure; and,
[0029] (Additional explanation) The embodiments described below are intended to provide information that will enable those skilled in the art to carry out the embodiments and to illustrate the best mode for carrying out the embodiments. Those skilled in the art will understand the concepts of this disclosure and recognize applications of these concepts that are not specifically addressed herein by referring to the accompanying drawings. It should be understood that these concepts and applications are within the scope of this disclosure.
[0030] Wireless node: As used herein, “wireless node” refers to either a wireless access node or a wireless device.
[0031] Radio Access Node: As used herein, “radio access node” or “radio network node” is any node in a radio access network of a cellular communication network that operates to transmit and / or receive signals wirelessly. Examples of radio access nodes include, but are not limited to, base stations (e.g., new radio (NR) base stations (gNBs) in the 3G Partnership Project (3GPP) 5G NR network, or extended or evolved node B (eNBs) in the 3GPP Long Term Evolution (LTE) network), high-power or macro base stations, low-power base stations (micro base stations, pico base stations, home eNBs, etc.), and relay nodes. Future 6G radio access nodes and beyond are also included in the present invention.
[0032] Core Network Node: As used herein, “core network node” means any type of node in a core network that implements core network functions, including servers or data centers. Examples of 4G (EPC) core network functions implemented on a node include, for example, Mobility Management Entity (MME), Packet Data Network Gateway (PGW), Service Capability Exposure Function (SCEF), and Home Subscriber Server (HSS). Examples of 5G core network functions include Access and Mobility Function (AMF), UPF, Session Management Function (SMF), Authentication Server Function (AUSF), Network Slice Selection Function (NSSF), Network Exposure Function (NEF), Network Function (NF) Repository Function (NRF), Policy Control Function (PCF), and Unified Data Management (UDM). Core network functions may be virtualized / containerized on nodes (servers, distributed servers, etc.) or implemented on-premises using dedicated physical nodes (compute, memory, network). Other future core network functions in future core networks such as 6G and beyond are also applicable to the present invention.
[0033] Wireless Device: As used herein, “wireless device” means any type of device that accesses (e.g., is provided with services) a cellular communication network by wirelessly transmitting and / or receiving signals to a wireless access node. Some examples of wireless devices include, but are not limited to, user equipment devices (UEs) and machine-type communication (MTC) devices in a 3GPP network.
[0034] Network node: As used herein, “network node” refers to any node that is part of either the radio access network or the core network of a cellular communication network / system.
[0035] Please note that, as this specification focuses on 3GPP cellular communication systems, 3GPP terminology or terms similar to 3GPP terminology will be frequently used. However, the concepts disclosed herein are not limited to 3GPP systems.
[0036] It should be noted that the term "cell" may be used in this specification. However, particularly with regard to the concept of 5G NR, beams may be used instead of cells, and therefore it is important to note that the concepts described herein are equally applicable to both cells and beams. Furthermore, although the description herein is based on a 5G core network, it should be noted that the present invention can be applied between any core network and radio access network nodes such as EPCs and LTE eNBs.
[0037] Figure 1 shows an example of a cellular communication system 300 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communication system 300 may be a 5G system (5GS) including an NR RAN, an evolved packet system (EPS) including an LTE RAN, or a RAN including components of both 5GS and EPS. In this example, the RAN is called an eNB in LTE and a gNB in 5G NR and includes base stations or NG-RAN nodes 302-1 and 302-2 that control the corresponding (macro) cells 304-1 and 304-2. Base stations 302-1 and 302-2 are generally referred to collectively as base station 302 and individually as base station 302. Similarly, (macro) cells 304-1 and 304-2 are generally referred to collectively as (macro) cell 304 and individually as (macro) cell 304. The RAN may also include a number of low-power nodes 306-1 to 306-4 that control the corresponding small cells 308-1 to 308-4. The low-power nodes 306-1 to 306-4 may be small base stations (such as pico base stations or femto base stations) or remote radio heads (RRHs), etc. Notably, although not shown, one or more of the small cells 308-1 to 308-4 may be provided alternatively by base station 302. The low-power nodes 306-1 to 306-4 are generally referred to collectively as low-power node 306 and individually as low-power node 306 in this specification. Similarly, the small cells 308-1 to 308-4 are generally referred to collectively as small cell 308 and individually as small cell 308 in this specification. The cellular communication system 300 also includes a core network 310, which in 5GS is called the 5G core (5GC). Base station 302 (and optionally low-power node 306) is connected to core network 310.
[0038] Base station 302 and low-power node 306 provide services to radio devices 312-1 to 312-5 in the corresponding cells 304 and 308. Radio devices 312-1 to 312-5 are collectively referred to as radio device 312 and individually as radio device 312. Radio device 312 may also be referred to as UE in this specification.
[0039] Figure 2 shows a wireless communication system represented as a 5G network architecture consisting of core network functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point / interface. Figure 2 can be considered as one specific implementation of system 300 in Figure 1.
[0040] From the access side, the 5G network architecture shown in Figure 2 includes multiple user devices (UEs) connected to either a radio access network (RAN) or an access and mobility management function (AMF). Typically, the (R)AN in Figure 2 is also referred to herein as the NG-RAN and includes, for example, an evolved node B (eNB) or 5G base station (gNB) or similar base station. From the core network side, the 5G core NF shown in Figure 2 includes a network slice selection function (NSSF), authentication server function (AUSF), unified data management (UDM), AMF, session management function (SMF), policy control function (PCF), and user plane function (UPF).
[0041] Reference point representations for 5G network architectures are used in prescriptive standardization to formulate detailed call flows. The N1 reference point is defined to transmit signaling between the UE and the AMF. Reference points connecting the AN and the AMF, and the AN and the UPF, are defined as N2 and N3, respectively. Between the AMF and the SMF is a reference point N11, meaning the SMF is at least partially controlled by the AMF. N4 is used by the SMF and UPF, allowing the UPF to be configured using control signals generated by the SMF, and enabling the UPF to report its status to the SMF. N9 is a reference point connecting different UPFs, and N14 is a reference point connecting different AMFs. N15 and N7 are defined for the PCF to apply policies to the AMF and SMF, respectively. N12 is required for the AMF to perform UE authentication. N8 and N10 are defined because the AMF and SMF require UE join data.
[0042] The 5G core network aims to separate the user plane from the control plane. The user plane transmits user traffic, while the control plane transmits signaling within the network. In Figure 2, the UPF is located in the user plane, while all other NFs (AMF, SMF, PCF, AF, AUSF, UDM, etc.) are located in the control plane. Separating the user plane from the control plane ensures that the resources of each plane can be scaled independently. It is also possible to distribute the UPF separately from the control plane's functions. In this architecture, the UPF is located very close to the UE to reduce round-trip time (RTT) between the UE and the data network, enabling applications that require low latency.
[0043] The core 5G network architecture is composed of modularized functions. For example, AMF and SMF are independent functions of the control plane. Separating AMF and SMF allows for independent evolution and expansion. As shown in Figure 2, other control plane functions such as PCF and AUSF can also be separated. This modular functional design allows the 5G core network to flexibly support a variety of services.
[0044] Each NF interacts directly with other NFs. Intermediate functions can be used to route messages from one NF to another. In the control plane, a set of interactions between two NFs is defined as a service that can be reused. This service enables modularity support. The user plane supports interactions such as forwarding operations between different UPFs.
[0045] Figure 3 shows a 5G network architecture that uses service-based interfaces between control plane NFs instead of the point-to-point reference points / interfaces used in the 5G network architecture of Figure 2. However, the NFs mentioned above with reference to Figure 2 correspond to the NFs shown in Figure 3. Services that an NF provides to other authorized NFs may be exposed to authorized NFs through the service-based interface. In Figure 3, service-based interfaces are indicated by the letter "N" following the NF name. For example, the service-based interface for an AMF is Namf, and the service-based interface for an SMF is Nsmf, and so on. The Network Exposure Function (NEF) and Network Function (NF) Repository Function (NRF) in Figure 3 are not shown in Figure 2. However, it should be made clear that although not explicitly shown in Figure 2, all NFs shown in Figure 2 can interact with the NEF and NRF in Figure 2 as needed.
[0046] Some of the NF characteristics shown in Figures 2 and 3 can be described as follows: The AMF provides UE-based authentication, authorization, mobility management, etc. Because the AMF is independent of the access technology, even UEs using multiple access technologies are essentially connected to a single AMF. The SMF is responsible for session management and assigns Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF for data transfer. If a UE has multiple sessions, a different SMF may be assigned to each session to manage them individually and, in some cases, provide different functions for each session. The AF provides information about packet flow to the PCF, which is responsible for policy control, in order to support quality of service (QoS). Based on this information, the PCF determines policies regarding mobility and session management, and ensures that the AMF and SMF function properly. The AUSF stores data for UE and similar authentication to support UE and similar authentication functions, while the UDM stores UE subscription data. The Data Network (DN) is not part of the 5G core network and provides internet access, operator services, and similar.
[0047] NF can be implemented as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualization function instantiated on an appropriate platform (e.g., cloud infrastructure).
[0048] Currently, AMF provides assistance information to NG-RAN nodes to support NG-RAN's decision on whether a UE can be put into an RRC inactive state. The "RRC Inactive Assistance Information" described in 3GPP TS 23.501 includes the following: - UE-specific DRX value; - UE-specific extended idle mode DRX value (cycle length and paging time window length); - Registration area provided to the UE; - Periodic Registration Update Timer; - If AMF has enabled MICO mode for the UE, notify that the UE is in MICO mode; - Information about the UE identifier that allows RAN to calculate the UE's RAN paging opportunity; - A notification indicating that paging cause notifications for the Voice Service are supported; - AMF Paging Early Indication with Paging Subgrouping (PEIPS) Assistance Information for paging UEs in CM connection while RRC is inactive.
[0049] The above RRC inactive assistance information is provided by the AMF during N2 activation with the (new) serving NG-RAN node (i.e., during registration, service request, and handover) to assist the NG RAN in determining whether it can send the UE to the RRC inactive state.
[0050] The RRC inactive state is part of the RRC state machine, and it is the RAN that determines the conditions for entering the RRC inactive state. If any of the parameters included in the RRC inactive assistance information are changed as a result of a NAS procedure, the AMF must update the RRC inactive assistance information for the NG-RAN node.
[0051] When a UE is in a CM connection state, if the AMF provides RRC inactive assistance information, the RAN node may decide to transition the UE to a CM connection in an RRC inactive state. The 5G core network will not recognize the transition of a UE between a CM connection in an RRC-connected state and a CM connection in an RRC-inactive state unless notified to the 5G core network via the N2 notification procedure. When transitioning to a CM connection in an RRC inactive state, NG-RAN sets a periodic RAN notification area update timer for the UE, taking into account the value of the periodic registration update timer indicated in the RRC inactive assistance information, and uses a guard timer with a value longer than the RAN notification area update timer value provided to the UE. If the periodic RAN notification area update guard timer in NG-RAN expires, NG-RAN must initiate the AN release procedure. If the UE is in a CM connection with RRC inactive, the UE performs the PLMN selection procedure. If the UE is in a CM connection that is RRC inactive, the UE may reactivate the RRC connection for the following reasons: - Uplink data held; - Mobile-initiated NAS signaling procedure; - In response to RAN paging; - Notifies the network that the device has left the RAN Notification Area; - When the periodic RAN notification area update timer expires.
[0052] Embodiments are presented to allow NG-RAN nodes to select type A) and / or type B) (above) solutions to handle MT data / signaling for UEs with long eDRX cycles and RRC inactive when the UE is unreachable, in order for the extended DRX cycle to support RRC inactive states longer than 10.24 seconds. Both type A) and type B) solutions require functionality from the CN side (AMF). When NG-RAN decides to choose between type A) or type B) approaches, it is crucial that NG-RAN knows the capabilities of the CN (especially in the case of multi-vendor). Otherwise, the coexistence of the two solutions will not work well.
[0053] To support the NG-RAN decision, the CN (e.g., AMF for 5G or MME for 4G) provides the NG-RAN with buffering support parameters. The NG-RAN uses this information, and optionally other input parameters, to determine whether CN MT data / signaling processing or RAN MT data / signaling processing should be used for UEs in the RRC inactive state of long eDRX.
[0054] Figure 4 illustrates how the CN function (such as AMF) performs the following actions to enable NG-RAN to determine whether CN MT data / signaling processing or RAN MT data / signaling processing should be used for eDRX UEs in a long period of RRC inactive state.
[0055] The CN function (e.g., AMF) determines CN capability / support for MT data / signaling processing (step 400) and then provides CN capability / support notification parameters related to MT data / signaling processing to the NG-RAN node by sending them to the NG-RAN node during one or more N2 procedures (step 402) using UE-specific or non-UE-specific N2 signaling messages. AMF can send CN capability notifications in any of the following N2 procedures and messages: (Initial UE Context Setup)
[0056] According to one embodiment, when the AMF sends an NGAP Initial Context Setup Request message to the NG-RAN, it may include MT data / signaling processing capability parameters as part of the "Core Network Assistance Information for RRC_INACTIVE" information element (IE) (underlined below) or as a separate IE (for example, the CN MT data / signaling support notification IE underlined below). Details of the modified Initial UE Context Setup message described in 3GPP TS 38.413 are shown below (changes are underlined): <Initial Context Setup Request> This message is sent by AMF to request the setup of the UE context. Direction: AMF → NG-RAN node TIFF0007843418000001.tif236161TIFF0007843418000002.tif176161TIFF0007843418 000003.tif110161TIFF0007843418000004.tif14151TIFF0007843418000005.tif18151
[0057] If MT data / signaling CN capability notifications are included as part of the CN assistance information for RRC Inactive IE, the notifications may be included as follows: (Modified Core Network Assistance Information for RRC INACTIVE) This IE provides assistance information for RRC inactive settings. TIFF0007843418000006.tif158161
[0058] Furthermore, as an alternative to the enumerated format described above, in one embodiment, the CN MT data / signaling support notification can be encoded as a bitstring, as shown below. This also applies during the following set of N2 messages, for example, UE context change, handover request, path switch confirmation, and non-UE-related signaling such as N2 setup and update procedures: TIFF0007843418000007.tif54154<UE Context Modification>
[0059] When the AMF sends the NGAP UE Context Modification Request message (refer to TS 38.413) to the NG-RAN, it can include the MT data / signaling processing capability information as part of the "Core Network Assistance Information for RRC_INACTIVE" IE or as a separate IE. Direction: AMF → NG-RAN node TIFF0007843418000008.tif206161TIFF0007843418000009.tif122161<HANDOVER REQUEST>
[0060] During NGAP handover / N2 handover, when the AMF sends the NGAP Handover Request message (refer to TS 38.413) to the NG-RAN, it can include the MT data / signaling processing capability information as part of the "Core Network Assistance Information for RRC_INACTIVE" IE or as a separate IE. This message is sent from the AMF to the target NG-RAN node to request resource preparation. Direction: AMF → NG-RAN node TIFF0007843418000010.tif208161TIFF0007843418000011.tif208161TIFF0007843418000012.tif32161<Path Switch Request Acknowledge>
[0061] During XNAP handover / Xn handover, when the AMF sends the NGAP Path Switch Request Acknowledge message (see TS 38.413) to the NG-RAN, MT data / signaling processing capability information may be included as part of the "Core Network Assistance Information for RRC_INACTIVE" IE or as a separate IE.
[0062] This message is sent by the AMF to notify the NG-RAN node that the path switch within the 5GC has been successfully completed.
[0063] Direction: AMF → NG-RAN node TIFF0007843418000013.tif203161TIFF0007843418000014.tif202161<N2 Setup Response> During the setup of the N2 (NG-AP) interface, when the AMF sends the Setup Response message (see TS 38.413) to the NG-RAN, MT data / signaling processing capability information may be included in another IE contained in the message. This message is sent by the AMF to transfer the application layer information of the N2 interface instance. Direction: AMF → NG-RAN node TIFF0007843418000015.tif200161
[0064] Furthermore, when the AMF sends an AMF Configuration Update message (see TS 38.413) to the NG-RAN during the NG-AP interface configuration update, MT data / signaling processing capability information may be included in another IE contained in the message. <AMF Configuration Update> This message is sent by the AMF to transfer the update information of the NG-C interface instance. Direction: AMF → NG-RAN node TIFF0007843418000016.tif212161TIFF0007843418000017.tif128161
[0065] According to an embodiment, the CN mobile termination (MT) data / signaling capability or support notification may indicate any of the following · Whether the CN supports all the functions defined by 3GPP for the processing (such as buffering) of MT data / signaling in the CN for RRC-inactive UEs with long eDRX. · Whether the CN supports all the functions defined by 3GPP for the processing (such as buffering) of MT data / signaling in the NG-RAN for RRC-inactive UEs with long eDRX, or · Whether the CN supports all the functions defined by 3GPP for the processing (such as buffering) of MT data / signaling in both the CN and the NG_RAN for RRC-inactive UEs with long eDRX, or · None (optional). Alternatively, the absence of a capability notification is equivalent to receiving a notification with the value "none" or "not supported", and may be interpreted by the NG-RAN as the CN not supporting the functions defined by 3GPP for MT data / signaling processing (e.g., buffering) in the CN and the NG-RAN.
[0066] Figure 5 is a flowchart of the method in an NG-RAN node according to several embodiments. The NG-RAN node receives CN MT data / signaling capability notification from either an N2 message (UE-specific or non-UE signaling) as described above as part of Figure 4 (step 500). NG-RAN uses information to determine when to enter the RRC inactive state for long eDRX values (step 502). More specifically, NG-RAN uses this information, potentially along with other input parameters, to determine whether to use CN MT data / signaling processing or NG-RAN MT data / signaling processing for UEs that are in the RRC inactive state with long eDRX. • If the support / capability notification indicates CN, it means that CN (e.g., 5GC) supports all functions specified by 3GPP for processing MT data / signaling in the CN when the UE is unreachable in an RRC inactive state. In this case, if the processing of CN is also supported by NG-RAN, NG-RAN will determine that CN processes MT data / signaling for the RRC inactive UE for a long eDRX cycle. Otherwise, a long eDRX cannot be used for RRC inactivity (for example, a conventional long eDRX for idle mode functionality may be applied to the UE). • If the support / capability notification indicates NG-RAN, it means that the CN (e.g., 5G CN) will support all 3GPP-defined functions for MT data / signaling processing in the NG-RAN when the UE is unreachable due to an RRC inactive state, including UE context retrieval between two NG-RAN nodes via the CN. In this case, the NG-RAN will determine that it needs to process MT data / signaling from a UE in an RRC inactive state for a long eDRX cycle. • If the parameters indicate both, CN (e.g., 5GC) means that both RAN and CN support all the functions specified by 3GPP for MT data / signaling processing. NG-RAN determines whether CN or NG-RAN will process MT data / signaling for long eDRX RRC-inactive UEs based on NG-RAN's ability to process MT data / signaling and other parameters such as internal / local policies, resources, and traffic patterns. If CN (e.g., 5GC) does not support any of the functions, NG-RAN will not receive any notification. Alternatively, it may receive a notification indicating a code point of "none" or "unsupported". In this case, NG-RAN cannot apply a long eDRX of RRC inactive, regardless of whether NG-RAN supports the capability.
[0067] Figure 6 is a schematic block diagram of a radio access node 1100 according to some embodiments of the present disclosure. The radio access node 1100 may be, for example, a base station 302 or 306. As shown, the radio access node 1100 includes a control system 1102 including one or more processors 1104 (e.g., a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and / or similar), memory 1106, and a network interface 1108. One or more processors 1104 are also referred to herein as processing circuits. Furthermore, the radio access node 1100 includes one or more radio units 1110, each including one or more transmitters 1112 and one or more receivers 1114, each coupled to one or more antennas 1116. The radio units 1110 may refer to or be part of a radio interface circuit. In some embodiments, the wireless unit 1110 is located outside the control system 1102 and is connected to the control system 1102, for example, via a wired connection (e.g., optical cable). However, in some other embodiments, the wireless unit 1110 and potentially the antenna 1116 are integrated with the control system 1102. One or more processors 1104 operate to provide one or more functions of the wireless access node 1100 described herein. In some embodiments, the functions are stored, for example, in memory 1106 and implemented in software executed by one or more processors 1104.
[0068] Figure 8 is a schematic block diagram showing a virtualized embodiment of a wireless access node 1100 according to several embodiments of the present disclosure. This discussion is similarly applicable to other types of network nodes. Furthermore, other types of network nodes may have similar virtualization architectures.
[0069] As used herein, a “virtualized” radio access node is an implementation of the radio access node 1100 in which at least some of the functions of the radio access node 1100 are implemented as virtual components (for example, via a virtual machine running on a physical processing node in the network). As illustrated, in this example, the radio access node 1100 includes a control system 1102 including one or more processors 1104 (e.g., CPU, ASIC, FPGA and / or similar), memory 1106, and a network interface 1108, and one or more radio units 1110, each including one or more transmitters 1112 and one or more receivers 1114 coupled to one or more antennas 1116, as described above. The control system 1102 is connected to the radio units 1110 via, for example, an optical cable. The control system 1102 is connected via the network interface 1108 to one or more processing nodes 1200 that are coupled to or included as part of the network 1202. Each processing node 1200 includes one or more processors 1204 (e.g., CPU, ASIC, FPGA and / or similar), memory 1206, and a network interface 1208.
[0070] In this example, the functions 1210 of the wireless access node 1100 described herein are implemented in one or more processing nodes 1200, or distributed across the control system 1102 and one or more processing nodes 1200 in any desired manner. In some specific embodiments, some or all of the functions 1210 of the wireless access node 1100 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment hosted by the processing node 1200. As will be understood by those skilled in the art, additional signaling or communication between the processing node 1200 and the control system 1102 is used to perform at least some of the desired functions 1210. Notably, in some embodiments, the control system 1102 may not be included, in which case the wireless unit 1110 communicates directly with the processing node 1200 via a suitable network interface.
[0071] In some embodiments, when executed by at least one processor, a computer program is provided which includes instructions causing at least one processor to perform the functions of a node (e.g., a processing node 1200) that implements one or more functions of the wireless access node 1100 or functions 1210 of the wireless access node 1100 in a virtual environment, according to any embodiment described herein. In some embodiments, a carrier is provided which includes the aforementioned computer program product. The carrier is one of the following: an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium (e.g., a non-transient computer-readable medium such as memory).
[0072] Figure 7 is a schematic block diagram of a wireless access node 1100 according to several other embodiments of the present disclosure. The wireless access node 1100 includes one or more modules 1300, each implemented in software. The modules 1300 provide the functionality of the wireless access node 1100 as described herein. This discussion may also apply to the processing node 1200 in Figure 12, where the modules 1300 may be implemented in one of the processing nodes 1200, distributed across multiple processing nodes 1200, and / or distributed across processing nodes 1200 and a control system 1102.
[0073] Figure 9 is a schematic block diagram of a UE1400 according to some embodiments of the present disclosure. As shown, the UE1400 includes one or more processors 1402 (e.g., CPU, ASIC, FPGA and / or similar), a memory 1404, and one or more transceivers 1406, each including one or more transmitters 1408 and one or more receivers 1410 coupled to one or more antennas 1412. The transceiver 1406 includes a radio front-end circuit connected to the antenna 1412, configured to coordinate signals communicated between the antenna 1412 and the processor 1402, as will be understood by those skilled in the art. The processor 1402 is also referred to herein as a processing circuit. The transceiver 1406 is also referred to herein as a radio circuit. In some embodiments, the functions of the UE1400 described above may be fully or partially implemented in software, for example, stored in the memory 1404 and executed by the processor 1402. It should be noted that the UE1400 may include additional components not shown in Figure 14, such as one or more user interface components (e.g., an input / output interface including a display, buttons, a touchscreen, a microphone, a speaker, and / or similar, and / or any other components to enable information input to and / or output from the UE1400), a power supply (e.g., a battery and associated power supply circuitry).
[0074] In some embodiments, when executed by at least one processor, a computer program is provided which includes instructions causing at least one processor to perform the functions of the UE1400 according to any of the embodiments described herein. In some embodiments, a carrier is provided which includes the aforementioned computer program product. The carrier is one of the following: an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium (e.g., a non-transient computer-readable medium such as memory).
[0075] Figure 10 is a schematic block diagram of UE1400 according to some other embodiments of the present disclosure. UE1400 includes one or more modules 1500, each implemented in software. Module 1500 provides the functionality of UE1400 as described herein.
[0076] Figure 11 shows a communication system according to several embodiments of the present disclosure. Referring to Figure 11, according to one embodiment, the communication system includes a telecommunications network 1600, such as a 3GPP type cellular network, comprising an access network 1602, such as a RAN, and a core network 1604. The access network 1602 includes a plurality of base stations 1606A, 1606B, 1606C, such as NBs, eNBs, gNBs, or other types of radio access points (APs), each defining a corresponding coverage area 1608A, 1608B, 1608C. Each base station 1606A, 1606B, 1606C is connectable to the core network 1604 via a wired or wireless connection 1610. A first UE 1612 located in coverage area 1608C is configured to wirelessly connect to the corresponding base station 1606C or to be paged by the corresponding base station 1606C. A second UE 1614 located in coverage area 1608A can wirelessly connect to the corresponding base station 1606A. Although multiple UEs 1612, 1614 are illustrated in this example, the disclosed embodiments are equally applicable to situations where one UE is in a coverage area or where one UE is connected to the corresponding base station 1606.
[0077] The telecommunications network 1600 is connected to a host computer 1616, which may be embodied in hardware and / or software as a standalone server, a cloud implementation server, a distributed server, or a processing resource within a server farm. The host computer 1616 may be owned or controlled by a service provider and may be operated by or on behalf of the service provider. Connections 1618 and 1620 between the telecommunications network 1600 and the host computer 1616 may extend directly from the core network 1604 to the host computer 1616, or via an optional intermediate network 1622. The intermediate network 1622 may be one or more combinations of public, private, or hosted networks, and may be a backbone network or the internet, if any, and in particular may include two or more subnets (not shown).
[0078] The communication system in Figure 11, as a whole, enables connectivity between the connected UEs 1612 and 1614 and the host computer 1616. This connectivity can be described as an Over-the-Top (OTT) connection 1624. The host computer 1616 and the connected UEs 1612 and 1614 are configured to communicate data and / or signaling via the OTT connection 1624, using the access network 1602, the core network 1604, an optional intermediate network 1622, and possible further infrastructure (not shown) as intermediaries. The OTT connection 1624 can be transparent in the sense that participating communication devices through which the OTT connection 1624 passes are not aware of the routing of uplink and downlink communications. For example, base station 1606 does not need to be notified of the past routing of incoming downlink communications that have data originating from host computer 1616 that are forwarded (e.g., handed over) to the connected UE 1612. Similarly, base station 1606 does not need to be aware of the future routing of outgoing uplink communications originating from UE1612 toward host computer 1616.
[0079] Figure 12 shows a communication system according to several embodiments of the present disclosure. Now, with reference to Figure 12, exemplary implementations of the UE, base station, and host computer described in the previous paragraphs will be described. In the communication system 1700, the host computer 1702 includes hardware 1704, which includes a communication interface 1706 configured to establish and maintain wired or wireless connections to the interfaces of different communication devices of the communication system 1700. The host computer 1702 further includes processing circuitry 1708 which may have storage and / or processing capabilities. In particular, the processing circuitry 1708 may include one or more programmable processors, ASICs, FPGAs, or combinations thereof (not shown) adapted to execute instructions. The host computer 1702 further includes software 1710 which is stored within the host computer 1702 or accessible by the host computer 1702 and executable by the processing circuitry 1708. The software 1710 includes a host application 1712. The host application 1712 may be capable of operating to provide services to remote users, such as UE1714, which connects via an OTT connection 1716 that terminates at UE1714 and host computer 1702. When providing services to remote users, the host application 1712 may provide user data transmitted using the OTT connection 1716.
[0080] The communication system 1700 further includes a base station 1718, which is provided within the telecommunications system and includes hardware 1720 enabling communication with the host computer 1702 and the UE 1714. The hardware 1720 may include a communication interface 1722 for setting up and maintaining wired or wireless connections with the interfaces of different communication devices of the communication system 1700, and a wireless interface 1724 for setting up and maintaining at least a wireless connection 1726 with the UE 1714 located within the coverage area (not shown in Figure 12) provided by the base station 1718. The communication interface 1722 may be configured to facilitate a connection 1728 to the host computer 1702. The connection 1728 may be direct, pass through the core network of the telecommunications system (not shown in Figure 12), or pass through one or more intermediate networks outside the telecommunications system. In the illustrated embodiment, the hardware 1720 of the base station 1718 further includes processing circuitry 1730, which may include one or more programmable processors, ASICs, FPGAs, or a combination thereof (not shown) adapted to execute instructions. The base station 1718 further has software 1732 that is stored internally or accessible via an external connection.
[0081] The communication system 1700 further includes the UE 1714 already mentioned. The hardware 1734 of the UE 1714 may include a radio interface 1736 configured to establish and maintain a radio connection 1726 with a base station that provides service to the coverage area in which the UE 1714 is currently located. The hardware 1734 of the UE 1714 further includes a processing circuit 1738 which may include one or more programmable processors, ASICs, FPGAs, or a combination thereof (not shown) adapted to execute instructions. The UE 1714 further includes software 1740, which is stored in or accessible by the UE 1714 and executable by the processing circuit 1738. The software 1740 includes a client application 1742. The client application 1742 may be able to operate to provide services to human or non-human users via the UE 1714 with the support of the host computer 1702. On the host computer 1702, the host application 1712 running on the host computer 1702 can communicate with the client application 1742 running on the UE 1714 and via an OTT connection 1716 terminating on the host computer 1702. When providing services to a user, the client application 1742 can receive request data from the host application 1712 and provide user data in response to the request data. The OTT connection 1716 can transfer both the request data and the user data. The client application 1742 can interact with the user to generate the user data to be provided.
[0082] It should be noted that the host computer 1702, base station 1718, and UE 1714 shown in Figure 12 may be similar to or identical to the host computer 1616, one of the base stations 1606A, 1606B, and 1606C, and one of the UEs 1612 and 1614 in Figure 11, respectively. That is, the internal operation of these entities may be as shown in Figure 12, and independently, the surrounding network topology may be that of Figure 11.
[0083] In Figure 12, the OTT connection 1716 is depicted abstractly to illustrate communication between the host computer 1702 and the UE 1714 via the base station 1718, without explicitly referring to any intermediate devices and the exact routing of messages through these devices. The network infrastructure may determine routing configured to be hidden from the UE 1714, or from the service provider operating the host computer 1702, or both. While the OTT connection 1716 is active, the network infrastructure may further make decisions to dynamically change routing (for example, based on load balancing considerations or network reconfiguration).
[0084] The radio connection 1726 between UE 1714 and base station 1718 follows the teachings of embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to UE 1714 using OTT connection 1716, in which radio connection 1726 forms the final segment. More precisely, the teachings of these embodiments enable processing of MT data or signaling from OTT in CN or NG-RAN, thereby providing benefits such as minimizing packet loss and leading to improved performance for the end user.
[0085] Measurement procedures may be provided for the purpose of monitoring data rate, latency, and other factors that one or more embodiments improve. Further optional network functions may exist for reconfiguring the OTT connection 1716 between the host computer 1702 and the UE 1714 in response to variations in the measurement results. The measurement procedures and / or network functions for reconfiguring the OTT connection 1716 may be implemented in the software 1710 and hardware 1704 of the host computer 1702, or in the software 1740 and hardware 1734 of the UE 1714, or both. In some embodiments, sensors (not shown) may be deployed in or in relation to a communication device through which the OTT connection 1716 passes, and the sensors may participate in the measurement procedures by supplying values of the monitored quantities exemplified above, or by supplying values of other physical quantities that the software 1710, 1740 can calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 1716 may include message formatting, retransmission settings, preferred routing, etc. The reconfiguration does not need to affect base station 1718 and may be unknown or imperceptible to base station 1718. Such procedures and functionalities are publicly known and can be implemented in the art. In certain embodiments, the measurements may include proprietary UE signaling that facilitates measurements of host computer 1702 such as throughput, propagation time, and delay. The measurements may be performed by having software 1710 and 1740 send messages, particularly empty or "dummy" messages, using the OTT connection 1716 while monitoring propagation time, errors, etc.
[0086] Figure 13 is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be described with reference to Figures 11 and 12. For the sake of simplicity, this section will only include drawing references to Figure 13. In step 1800, the host computer provides user data. In a substep 1802 (optional) of step 1800, the host computer provides user data by executing a host application. In step 1804, the host computer initiates a transmission to transmit the user data to the UE. In step 1806 (optional), the base station transmits the user data transmitted in the transmission initiated by the host computer to the UE, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1808 (optional), the UE executes a client application associated with the host application executed by the host computer.
[0087] Figure 14 is a flowchart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and an UE, which may be described with reference to Figures 11 and 12. For simplicity, this section includes only drawing references to Figure 14. In step 1900 of the method, the host computer provides user data. In an optional substep (not shown), the host computer provides user data by running a host application. In step 1902, the host computer initiates a transmission that transmits the user data to the UE. This transmission may pass through a base station, as taught in the embodiments described throughout this disclosure. In step 1904 (which may be optional), the UE receives the user data transmitted in the transmission.
[0088] The appropriate steps, methods, features, functions, or benefits disclosed herein may be performed via one or more functional units or modules of one or more virtual devices. Each virtual device may include a number of these functional units. These functional units may be implemented via processing circuits, which may include one or more microprocessors or microcontrollers, or other digital hardware, such as digital signal processors (DSPs), special-purpose digital logic, etc. The processing circuits may be configured to execute program code stored in memory, which may include one or more types of memory, such as read-only memory (ROM), random-access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. The program code stored in memory includes program instructions for executing one or more telecommunications and / or data communication protocols, and instructions for executing one or more of the techniques described herein. In some implementations, the processing circuits may be used to perform functions corresponding to each functional unit, according to one or more embodiments of this disclosure.
[0089] The steps shown in the figures may represent a specific sequence of operations performed by a particular embodiment of this disclosure, but it should be understood that such a sequence is exemplary (for example, alternative embodiments may perform operations in a different order, combine certain operations, duplicate certain operations, etc.). (Embodiment) Embodiment of Group A - 5G AMF
[0090] Embodiment 1: A method performed by the networking function of a core network (CN), the method comprising: - To determine the capability of the CN, or the Radio Access Network, or both, to support the functions necessary for processing mobile terminated (MT) data / signaling for one or more user devices (UEs) with long eDRX cycles of RRC inactive, - Notifying the aforementioned wireless access network of the aforementioned capability.
[0091] Embodiment 2: The method of Embodiment 1, wherein the 5G network node includes an Access and Mobility Management Function (AMF).
[0092] Embodiment 3: The method of Embodiment 1 or 2, wherein the step of notifying the wireless access network of the capability includes transmitting the capability in an INITIAL CONTEXT SETUP REQUEST message.
[0093] Embodiment 4: The method of Embodiment 1 or 2, wherein the step of notifying the wireless access network of the capability includes transmitting the capability in a UE CONTEXT MODIFICATION REQUEST message.
[0094] Embodiment 5: The method of Embodiment 1 or 2, wherein the step of notifying the wireless access network of the capability includes transmitting the capability in a HANDOVER REQUEST message.
[0095] Embodiment 6: The method of Embodiment 1 or 2, wherein the step of notifying the wireless access network of the capability includes transmitting the capability in a PATH SWITCH REQUEST ACKNOWLEDGE message.
[0096] Embodiment 7: The method of Embodiment 1 or 2, wherein the step of notifying the wireless access network of the capability includes transmitting the capability in an NG / N2 SETUP RESPONSE message.
[0097] Embodiment 8: The method of Embodiment 1 or 2, wherein the step of notifying the wireless access network of the capability includes transmitting the capability in an AMF CONFIGURATION UPDATE message.
[0098] Embodiment 9: Any method of Embodiments 1 to 8, wherein the capability is included in the CN Assistance Information for RRC INACTIVE information element. Group B Embodiment - RAN Wireless Access Node
[0099] Embodiment 10: A method performed by a wireless network node located within a wireless access network and connected to a core network (CN), the method comprising: - To receive notification to one or more user devices (UEs) that are RRC inactive for a long eDRX cycle of the CN's ability to support the functions necessary for processing mobile terminated (MT) data / signaling in the CN or the radio access network or both, - Based on the ability of the wireless network node to process the notification and MT data / signaling, determine whether to use MT data / signaling processing in the CN or MT data / signaling processing in the wireless access node for one or more UEs in an RRC inactive state for a long eDRX cycle.
[0100] Embodiment 11: The method of Embodiment 10, wherein the decision to use MT data / signaling in the CN is based on the notification of the CN's capability indicating that the CN supports the functionality necessary for processing mobile terminated (MT) data / signaling in the CN or in both the radio access network and the CN.
[0101] Embodiment 12: The method of Embodiment 10, wherein the decision to use MT data / signaling at the wireless access node is based on the wireless access network, or the notification of the CN's capability indicating that the CN supports the capabilities necessary for processing mobile terminated (MT) data / signaling in both the wireless access network and the CN, and the capability of the wireless network node to process MT data / signaling.
[0102] Embodiment 13: The notification of the capability is included in the CN Assistance Information for RRC INACTIVE information element, in any of the methods of Embodiments 10 to 12.
[0103] Embodiment 14: The method of Embodiment 10, wherein the step of receiving the notification of the capability includes receiving the notification in the INITIAL CONTEXT SETUP REQUEST message.
[0104] Embodiment 15: The method of Embodiment 10, wherein the step of receiving the notification of the capability includes receiving the notification in a UE CONTEXT MODIFICATION REQUEST message.
[0105] Embodiment 16: The method of Embodiment 10, wherein the step of receiving the notification of the capability includes receiving the notification in a HANDOVER REQUEST message.
[0106] Embodiment 17: The method of Embodiment 10, wherein the step of receiving the notification of the capability includes receiving the notification in a PATH SWITCH REQUEST ACKNOWLEDGE message.
[0107] Embodiment 18: The method of Embodiment 10, wherein the step of receiving the notification of the capability includes receiving the notification in the NG / N2 SETUP RESPONSE message.
[0108] Embodiment 19: The method of Embodiment 10, wherein the step of receiving the notification of the capability includes receiving the notification in the AMF CONFIGURATION UPDATE message.
[0109] Embodiment 20: The method of Embodiment 10, wherein the notification of the capabilities of the CN further indicates that the CN does not support the capabilities necessary for processing mobile terminated (MT) data / signaling in both the CN and the radio access network.
[0110] Embodiment 21: The method of Embodiment 20, wherein the notification is either implicit (e.g., not received by the CN) or explicit (e.g., received by the CN).
[0111] Embodiment 22: The method of Embodiment 20, further comprising not applying a long eDRX to RRC inactive, regardless of the ability of the wireless access node to support MT data / signals. Group C Embodiment - Apparatus
[0112] Embodiment 23: A network node implementing a network function, which includes a processing circuit configured to perform any of the steps of any of the embodiments of Group A.
[0113] Embodiment 24: The network node is the network node of Embodiment 23, which includes an Access and Mobility Management Function (AMF) node.
[0114] Embodiment 25: A wireless network node comprising a processing circuit configured to perform the steps of any of the embodiments of Group B.
[0115] Embodiment 26: The wireless network node is a wireless network node of Embodiment 25, which includes a gNB.
[0116] This disclosure may use at least some of the following abbreviations. In the event of any inconsistency between abbreviations, the usage described above shall prevail. If an abbreviation is mentioned multiple times below, the first mention shall take precedence over any subsequent mentions. • 3GPP Third Generation Partnership Project 5G (5th Generation) • 5GC (5th Generation Core Network) • 5GS (5th Generation System) • AF application function • AMF access and mobility management functions AN Access Network • AP (Access Point) • ASIC (Application-Specific Integrated Circuit) • AUSF Authentication Server Function • CGI Cell Global Identifier ·CM settings management CN Core Network • CPU (Central Processing Unit) DL (Download) DN Data Network DRX discontinuous reception • DSP (Digital Signal Processor) eDRX Extended Discrete Reception eNB Extended or evolved node B EPC Advanced Packet Core • EPS (Advanced Packet System) • E-UTRA Advanced Universal Terrestrial Radio Access • E-UTRAN: Evolved Universal Terrestrial Wireless Access Network • FPGA (Field-Programmable Gate Array) ·gNB New wireless base station LTE Long-Term Evolution • MME Mobility Management Entity MT Mobile Terminated MTC (Mechanical Communication) • NAS Non-Access Layer • NEF Network Exposure Function NF Network Function • NG Next generation (e.g., 5G) ·NR New Radio • NRF Network Function Repository Function • NSSF Network Slice Selection Function • OTT (Over the Top) • PCF policy control function • PLMN Public Terrestrial Mobile Network • RAM (Random Access Memory) RAN (Radio Access Network) • RAT (Radio Access Technology) • RNA Wireless Access Network Notification Area RNTI (Radio Network Temporary Identifier) ROM (Read-only memory) • RRC (Radio Resource Control) • RRH Remote Wireless Head • SMF session management function • TAI Tracking Area Identifier ·TS technical standards • UDM (Unified Data Management) UE User Equipment • UPF User Plane Function UTRA Universal Terrestrial Radio Access UTRAN (Universal Terrestrial Radio Access Network)
[0117] Those skilled in the art will recognize improvements and modifications to embodiments of the present disclosure. All such improvements and modifications are considered to be within the scope of the concepts disclosed herein.
Claims
1. A method performed by the network functions of the core network (CN), Determining the CN's ability to support the processing of mobile terminated (MT) data and / or signaling to a user device (UE) when the UE is in a radio resource control (RRC) inactive state during a long extended discontinuous receive (eDRX) cycle, Sending a capability notification to a radio access network (RAN) node providing services to the UE, indicating whether the CN supports processing MT data / signaling so that the RAN node can request the CN to process MT data and / or signaling for the UE when the UE is in an RRC inactive state for a long eDRX cycle, wherein the CN processes the MT data and / or signaling by buffering the MT data and / or signaling. A method that includes this.
2. The method according to claim 1, wherein the network function includes an access and mobility management function (AMF).
3. The method according to claim 1, wherein the step of transmitting the capability notification to the wireless access network node includes transmitting the capability notification in an INITIAL CONTEXT SETUP REQUEST message or a UE CONTEXT MODIFICATION REQUEST message.
4. The method according to claim 1, wherein the step of transmitting the capability notification to the wireless access network node includes transmitting the capability notification in a HANDOVER REQUEST message or in a PATH SWITCH REQUEST ACKNOWLEDGE message.
5. The method according to claim 1, wherein the step of transmitting the capability notification to the wireless access network node includes transmitting the capability notification in an NG / N2 SETUP RESPONSE message or in an AMF CONFIGURATION UPDATE message.
6. The method according to claim 1, wherein the capability notification is transmitted to the RAN node in the CN Assistance Information for RRC INACTIVE information element.
7. The method according to claim 1, wherein the long eDRX cycle includes a DRX cycle longer than 10.24 seconds.
8. A wireless access network (RAN) node comprising a processing circuit and, when executed by the processing circuit, the RAN node The core network (CN) receives a capability notification from the CN indicating whether or not it supports processing mobile termination (MT) data / signaling for user devices (UEs). Based on the received capability notification, determine whether MT data / signaling is processed by the CN for the UE when the UE is in an RRC inactive state for a long extended discontinuous reception (eDRX) cycle, wherein the CN processes the MT data / signaling by buffering it when the UE is in an RRC inactive state for a long eDRX cycle. A memory containing instructions configured in such a way, and RAN node.
9. The RAN node according to claim 8, wherein the capability notification is included in the CN Assistance Information for RRC INACTIVE information element.
10. The RAN node according to claim 8, wherein the RAN node configured to receive capability notifications includes the RAN node configured to receive the capability notifications in an INITIAL CONTEXT SETUP REQUEST message or a UE CONTEXT MODIFICATION REQUEST message.
11. The RAN node according to claim 8, wherein the RAN node configured to receive capability notifications includes the RAN node configured to receive the capability notifications in a HANDOVER REQUEST message or a PATH SWITCH REQUEST ACKNOWLEDGE message.
12. The RAN node according to claim 8, wherein the RAN node configured to receive capability notifications includes the RAN node configured to receive the capability notifications in an NG / N2 SETUP RESPONSE message or an AMF CONFIGURATION UPDATE message.
13. The capability notification further indicates that the CN does not support processing mobile-terminated (MT) data / signaling, according to claim 8, the RAN node.
14. The RAN node according to claim 13, further configured to determine whether to process MT data / signaling at the RAN node.
15. The RAN node according to claim 8, wherein the long eDRX cycle includes a DRX cycle longer than 10.24 seconds.
16. A network node that implements network functions in a core network (CN), wherein the network node includes a processing circuit and, when executed by the processing circuit, the network node When a user device (UE) is in a Radio Resource Control (RRC) inactive state during a long extended discontinuous receive (eDRX) cycle, the CN's ability to support the processing of mobile terminated (MT) data and / or signaling to the UE is determined. A capability notification is sent to the radio access network (RAN) node providing services to the UE, indicating whether the CN supports processing MT data / signaling so that the RAN node can request the CN to process MT data and / or signaling to the UE when the UE is in an RRC inactive state for a long eDRX cycle, and the CN processes the MT data and / or signaling by buffering the MT data and / or signaling. A memory containing instructions configured in such a way, and Network node.
17. The RAN node according to claim 8, wherein the RAN node is a next-generation node B in a fifth-generation system.
18. The network node according to claim 16, wherein the capability notification is included in the CN Assistance Information for RRC INACTIVE information element.