Method and system for mobile terminating data / signaling processing for UEs in RRC inactive state
The system enables the NG-RAN to select between Type A and Type B solutions for MT data/signaling processing based on CN capabilities, addressing inefficiencies in handling UEs with long eDRX cycles, thereby optimizing data/signaling management and reducing latency.
Patent Information
- Application Number
- JP2025506052
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-08-16
- Filing Date
- 2023-08-14
- Publication Date
- 2025-09-09
- Estimated Expiration
- 2043-08-14
AI Technical Summary
Existing 3GPP technologies face challenges in handling Mobile Terminating (MT) data/signaling for User Equipment (UE) in RRC inactive state with long eDRX cycles, as the UE becomes unreachable, leading to inefficiencies in data processing and signaling management.
The system and method allow the NG-RAN to decide between Type A and Type B solutions for MT data/signaling processing based on core network (CN) capabilities, using notifications in N2 messages to determine whether the CN or RAN processes the data/signaling for UEs in RRC inactive state with long eDRX cycles.
Enhances data/signaling handling efficiency by ensuring appropriate processing is selected for UEs in RRC inactive state with long eDRX cycles, optimizing resource utilization and reducing latency.
Smart Images

Figure 2025529683000001_ABST
Abstract
Description
[Technical Field]
[0001] (Related Applications) This application claims the benefit of Provisional Patent Application No. 63 / 398317, filed August 16, 2022, the disclosure of which is incorporated herein by reference in its entirety. The present 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 technology]
[0002] The study item FS_RedCap_Ph2 in 3GPP Rel-18 SA2 addresses support for long eDRX (>10.24 seconds) values in RRC inactive state. The key issue is how to handle Mobile Terminating (MT) data / signaling when the User Equipment (UE) (aka Wireless Device) becomes unreachable due to long eDRX in RRC inactive state, as described in 3GPP TR 23.700-68 V.1.0.0, which is incorporated herein 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 UE unreachability information (e.g., eDRX information) to the core network (CN) when the UE enters a long eDRX RRC inactive state, and the CN processes MT data / signaling while the UE is unreachable. Using 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 (e.g., 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 in 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) The NG-RAN handles MT data / signaling while the UE is in RRC inactive state. If the UE moves outside the RAN based Notification area (RNA) during unreachable periods and performs a resume outside the RNA, UE context lookup and data transfer between NG-RAN nodes is supported via the 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] Thus, in Type A, the CN handles the MT data / signaling if the UE is unreachable, and in Type B), the RAN handles the MT data / signaling if the UE is unreachable.
[0007] These two different types of solutions are applicable to different scenarios / use cases. Summary of the Invention
[0008] Systems, methods, and apparatuses are provided for selecting or determining the type of solution to apply to the processing of MT data / signaling for a UE in an RRC inactive state. In some embodiments, the NG-RAN, more specifically the gNB, decides whether the CN processes the MT data / signaling for a UE that enters the RRC inactive state with a long eDRX cycle (Type A) or whether the RAN processes the MT data / signaling for a UE that enters the RRC inactive state with a long eDRX cycle (Type B). The decision by the NG-RAN is based on knowledge of the core network (CN)'s capabilities to support the processing of MT data / signaling. Optionally, the NG-RAN node may also consider other policies when selecting whether Type A, Type B, or both should be applied.
[0009] In some embodiments, a method 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, includes determining, by the network function, a capability of the CN to support processing of mobile terminated (MT) data / signaling for a user equipment (UE) when in 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 of MT data / signaling. The method further includes sending, by the network function, a notification to a radio access network (RAN) (e.g., a gNB in a 5G system) serving the UE indicating the CN's support for processing the MT data / signaling.
[0010] This notification may be sent to the Radio Access Network (RAN) in an INITIAL CONTEXT SETUP REQUEST message, a UE CONTEXT MODIFICATION REQUEST message, a HANDOVER REQUEST message, a PATH SWITCH REQUEST ACKNOWLEDGE message, an NG / N2 SETUP RESPONSE message, or an AMF CONFIGURATION UPDATE message.
[0011] In one embodiment, this notification is sent to the RAN in the CN Assistance Information of the RRC INACTIVE Information Element contained in one of the N2 messages (shown above).
[0012] In some embodiments, a method is provided that is performed by a radio network node in a radio access network (RAN) (e.g., a gNB in a 5G system) and connected to a core network (CN), the method including receiving, by the radio network node, a notification from the CN indicating CN support for processing (e.g., buffering) user equipment (UE) MT data / signaling for use by the UE when in a radio resource control (RRC) inactive state with a long extended discontinuous reception (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 with the long eDRX cycle.
[0013] This notification may be received and sent from the CN in the CN Assistance Information of the RRC INACTIVE information element or in another information element that may be included in the INITIAL CONTEXT SETUP REQUEST message, the UE CONTEXT MODIFICATION REQUEST message, the HANDOVER REQUEST message, the PATH SWITCH REQUEST ACKNOWLEDGE message, the NG / N2 SETUP RESPONSE message, and the AMF CONFIGURATION UPDATE message.
[0014] The notification may further indicate that the CN does not support processing of mobile terminated (MT) data / signaling, in which case the radio network node may decide whether to process the MT data / signaling at the radio network node.
[0015] According to some embodiments, there is provided a network node for implementing network functions in a core network (CN), the network node including a processing circuit and a memory including instructions for performing any of the method embodiments described herein when performed by the processing circuit.
[0016] According to some embodiments, a radio network node is provided, the radio network node including a processing circuit and a memory including instructions that, when executed by the processing circuit, perform any of the method embodiments described herein. [Brief explanation of the drawings]
[0017] The accompanying drawing figures, which are incorporated in and constitute a part of this specification, illustrate several aspects of the disclosure and, together with the description, serve to explain the principles of the disclosure.
[0018] [Figure 1] FIG. 1 illustrates 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 consisting of core Network Functions (NFs), where the interaction between any two NFs is represented by a point-to-point reference point / interface;
[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 in Figure 4;
[0021] [Figure 4] FIG. 4 illustrates a method in a network function (e.g., AMF) of a CN according to some embodiments of the present disclosure;
[0022] [Figure 5] FIG. 5 illustrates 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] FIG. 6 illustrates an embodiment of a radio access node according to some embodiments of the present disclosure; [Figure 7] FIG. 7 illustrates an embodiment of a radio access node according to some embodiments of the present disclosure;
[0024] [Figure 8] FIG. 8 is a schematic block diagram illustrating a virtualization environment in which functionality implemented by some embodiments of the present disclosure may be virtualized;
[0025] [Figure 9]FIG. 9 illustrates an exemplary embodiment of a wireless device / UE according to some embodiments of the present disclosure; [Figure 10] FIG. 10 illustrates an exemplary embodiment of a wireless device / UE according to some embodiments of the present disclosure;
[0026] [Figure 11] FIG. 11 illustrates an example of a communication system implementing an embodiment of the present disclosure;
[0027] [Figure 12] FIG. 12 illustrates an exemplary implementation according to an embodiment of the UE, base station, and host computer of FIG. 13 according to some embodiments of the present disclosure;
[0028] [Figure 13] FIG. 13 is a flowchart illustrating a method implemented in a communication system according to some embodiments of the present disclosure; [Figure 14] FIG. 14 is a flowchart illustrating a method implemented in a communication system according to some embodiments of the present disclosure; [Figure 15] FIG. 15 is a flowchart illustrating a method implemented in a communication system according to some embodiments of the present disclosure; [Figure 16] FIG. 16 is a flowchart illustrating a method implemented in a communication system according to some embodiments of the present disclosure; and
[0029] (Additional explanation) The embodiments described below represent information to enable those skilled in the art to practice the embodiments and illustrate the best modes for practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the present disclosure and will recognize applications of these concepts not specifically addressed herein. It is understood that these concepts and applications are within the scope of the present disclosure.
[0030] Wireless Node: As used herein, a "wireless node" is either a wireless access node or a wireless device.
[0031] Radio Access Node: As used herein, a "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., a New Radio (NR) base station (gNB) in a 3rd Generation Partnership Project (3GPP) fifth-generation (5G) NR network, or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), high-power or macro base stations, low-power base stations (e.g., micro base stations, pico base stations, home eNBs), and relay nodes. Future 6G radio access nodes and beyond are also encompassed by the present invention.
[0032] Core network node: As used herein, a "core network node" refers to any type of node, including a server or data center, in a core network that implements core network functions. Examples of 4G (EPC) core network functions implemented in a node include, for example, a mobility management entity (MME), a packet data network gateway (PGW), a service capability exposure function (SCEF), a home subscriber server (HSS), etc. Examples of 5G core network functions include an access and mobility function (AMF), a user function processor (UPF), a session management function (SMF), an authentication server function (AUSF), a network slice selection function (NSSF), a network exposure function (NEF), a network function (NF) repository function (NRF), a policy control function (PCF), a unified data management (UDM), etc. Core network functions may be virtualized / containerized on a node (e.g., a server, a distributed server), or may be implemented on-premise 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, a "wireless device" is any type of device that accesses (e.g., is served by) a cellular communication network by transmitting and / or receiving signals wirelessly to a wireless access node. Some examples of wireless devices include, but are not limited to, User Equipment devices (UE) and Machine Type Communication (MTC) devices in 3GPP networks.
[0034] Network Node: As used herein, a "network node" refers to any node that is part of either the radio access network or the core network of a cellular communications network / system.
[0035] It should be noted that the description herein focuses on 3GPP cellular communication systems and therefore 3GPP terminology or terminology similar to 3GPP terminology is often used, however, the concepts disclosed herein are not limited to 3GPP systems.
[0036] It should be noted that in the description herein, reference may be made to the term "cell." However, it is important to note that, particularly with regard to 5G NR concepts, beams may be used instead of cells, and therefore the concepts described herein are equally applicable to both cells and beams. Furthermore, it should be noted that while the description herein is based on a 5G core network, the present invention may be applied between any core network and radio access network nodes, such as EPCs and LTE eNBs.
[0037] FIG. 1 illustrates an example of a cellular communication system 300 in which embodiments of the present disclosure may be implemented. In 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 both 5GS and EPS components. In this example, the RAN is referred to as an eNB for LTE and a gNB for 5G NR and includes base stations or NG-RAN nodes 302-1 and 302-2 that control corresponding (macro) cells 304-1 and 304-2. Base stations 302-1 and 302-2 are generally referred to herein collectively as base stations 302 and individually as base stations 302. Similarly, (macro) cells 304-1 and 304-2 are generally referred to herein collectively as (macro) cells 304 and individually as (macro) cells 304. The RAN may also include a number of low-power nodes 306-1 through 306-4 that control corresponding small cells 308-1 through 308-4. The low-power nodes 306-1 through 306-4 may be small base stations (e.g., pico or femto base stations) or remote radio heads (RRHs), etc. It should be noted that, although not shown, one or more of the small cells 308-1 through 308-4 may alternatively be provided by the base station 302. The low-power nodes 306-1 through 306-4 are generally referred to herein collectively as low-power nodes 306 and individually as low-power nodes 306. Similarly, the small cells 308-1 through 308-4 are generally referred to herein collectively as small cells 308 and individually as small cells 308. The cellular communication system 300 also includes a core network 310, which in 5GS is referred to as 5G Core (5GC). The base station 302 (and optionally the low power node 306 ) is connected to a core network 310 .
[0038] Base station 302 and low power node 306 serve wireless devices 312-1 through 312-5 within corresponding cells 304 and 308. Wireless devices 312-1 through 312-5 are generally referred to herein collectively as wireless devices 312 and individually as wireless devices 312. Wireless devices 312 may also be referred to herein as UEs.
[0039] 2 illustrates a wireless communication system represented as a 5G network architecture composed 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 one specific implementation of the system 300 of Figure 1.
[0040] From the access side, the 5G network architecture shown in Figure 2 includes multiple user equipments (UEs) connected to either a radio access network (RAN) and an access and mobility management function (AMF). Typically, the (R)AN in Figure 2, also referred to herein as an NG-RAN, includes, for example, an evolved node B (eNB) or a 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), an authentication server function (AUSF), a unified data management (UDM), an AMF, a session management function (SMF), a policy control function (PCF), and a user plane function (UPF).
[0041] Reference point representations for 5G network architecture are used to define detailed call flows in normative standardization. The N1 reference point is defined to carry signaling between the UE and the AMF. Reference points connecting the AN and the AMF and between the AN and the UPF are defined as N2 and N3, respectively. There is a reference point called N11 between the AMF and the SMF, which means that the SMF is at least partially controlled by the AMF. N4 is used by the SMF and the UPF to configure the UPF using control signals generated by the SMF and to allow 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 the SMF, respectively. N12 is required for the AMF to perform UE authentication. N8 and N10 are defined because the AMF and the SMF require UE subscription data.
[0042] The 5G core network aims to separate the user plane and the control plane. The user plane carries user traffic, while the control plane carries signaling within the network. In Figure 2, the UPF is in the user plane, and all other NFs (AMF, SMF, PCF, AF, AUSF, UDM, etc.) are in the control plane. Separating the user plane and the control plane ensures that resources in each plane can be scaled independently. It is also possible to distribute the UPF separately from the control plane functions. In this architecture, the UPF is deployed very close to the UE to shorten the round-trip time (RTT) between the UE and the data network and support applications that require low latency.
[0043] The core 5G network architecture consists of modularized functions. For example, AMF and SMF are independent control plane functions. Separating AMF and SMF allows them to evolve and expand independently. As shown in Figure 2, other control plane functions such as PCF and AUSF can also be separated. The modularized function design enables the 5G core network to flexibly support various services.
[0044] Each NF interacts directly with other NFs. It is possible to use intermediate functions to route messages from one NF to another. In the control plane, a set of interactions between two NFs is defined as a service, allowing for their reuse. This service allows for modularity support. The user plane supports interactions such as forwarding operations between different UPFs.
[0045] Figure 3 illustrates 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 2. However, the NFs described 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 service-based interfaces. In Figure 3, service-based interfaces are indicated by the letter "N" following the name of the NF. For example, the service-based interface of the AMF is Namf, the service-based interface of the SMF is Nsmf, etc. The Network Exposure Function (NEF) and Network Function (NF) Repository Function (NRF) in Figure 3 are not shown in Figure 2 described above. However, it should be clear that, although not explicitly shown in Figure 2, all NFs shown in Figure 2 can interact with the NEFs and NRFs in Figure 2 as needed.
[0046] Some of the characteristics of the NFs shown in Figures 2 and 3 can be explained in the following way: The AMF provides UE-based authentication, authorization, mobility management, etc. The AMF is independent of the access technology, so even a UE using multiple access technologies is essentially connected to one AMF. The SMF is responsible for session management and assigns an Internet Protocol (IP) address to the UE. It also selects and controls the UPF for data forwarding. If a UE has multiple sessions, a different SMF may be assigned to each session to manage them separately and possibly provide different functions for each session. The AF provides information about packet flows to the PCF, which is responsible for policy control, to support quality of service (QoS). Based on this information, the PCF determines policies for mobility and session management and operates the AMF and SMF appropriately. The AUSF stores data for UE authentication and similar functions 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] An NF may be implemented either as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on a suitable platform (e.g., a cloud infrastructure).
[0048] Currently, the AMF provides assistance information to NG-RAN nodes to help the NG-RAN decide whether a UE can be put into an RRC inactive state. The "RRC Inactive Assistance Information" described in 3GPP TS 23.501 includes: - UE-specific DRX value; - UE-specific Extended Idle Mode DRX values (cycle length and paging time window length); - Registration Area provided to the UE; - Periodic Registration Update timer; - Notification that the UE is in MICO mode if the AMF has enabled MICO mode for the UE; - UE identifier information that allows the RAN to calculate the RAN paging occasion for the UE; - Notification that Voice Service Paging Cause Notification is supported; - AMF Paging Early Indication with Paging Subgrouping (PEIPS) Assistance Information for paging UEs in a CM connection in an RRC inactive state.
[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, handover) to assist the NG RAN in deciding whether the UE can be sent to RRC inactive state.
[0050] The RRC inactive state is part of the RRC state machine and it is up to the RAN to determine the conditions for entering the RRC inactive state. If any of the parameters contained in the RRC inactive assistance information change as a result of an NAS procedure, the AMF must update the RRC inactive assistance information for the NG-RAN node.
[0051] When the UE is in a CM connected state, if the AMF provides RRC inactive assistance information, the RAN node may decide to transition the UE to a CM connected state in an RRC inactive state. The 5G core network is unaware of the UE transitioning between CM connected in the RRC connected state and CM connected in the RRC inactive state unless the 5G core network is notified in the N2 notification procedure. Upon transition to CM connected in RRC inactive state, the NG-RAN configures a Periodic RAN Notification Area Update timer for the UE taking into account the Periodic Registration Update timer value 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 expires in the NG-RAN, the NG-RAN shall initiate the AN release procedure. If the UE is in a CM connection in the RRC inactive state, the UE performs a PLMN selection procedure. If the UE is in a CM connection in the RRC inactive state, the UE may resume the RRC connection for the following reasons: - Uplink data pending; - Mobile initiated NAS signaling procedures; - In response to RAN paging; - Notify the network that it has left the RAN Notification Area; - Upon expiration of the periodic RAN notification area update timer.
[0052] To support RRC inactivity with an extended DRX cycle longer than 10.24 seconds, embodiments are presented to enable an NG-RAN node to select between Type A) and / or Type B) (above) solutions for handling MT data / signaling for UEs with RRC inactivity and long eDRX cycles when the UE is unreachable. Both Type A) and Type B) solutions require functionality from the CN side (AMF). When the NG-RAN decides to select the Type A) or Type B) approach, it is very important for the NG-RAN to know the capabilities of the CN (especially in multi-vendor cases). Otherwise, the coexistence of the two solutions will not work well.
[0053] To support the NG-RAN decision, the CN (e.g., AMF in 5G or MME in 4G) provides the NG-RAN with buffering support parameters. The NG-RAN uses this information, optionally together with other input parameters, to decide whether CN MT data / signaling processing or RAN MT data / signaling processing should be used for UEs in RRC inactive state with long eDRX.
[0054] Figure 4 shows how a CN function (e.g., AMF) can enable the NG-RAN to decide whether CN MT data / signaling processing or RAN MT data / signaling processing should be used for UEs with long eDRX in RRC inactive state.
[0055] After the CN function (e.g., AMF) determines the CN capability / support for MT data / signaling processing (step 400), it provides the NG-RAN with CN capability / support indication parameters related to MT data / signaling processing by sending them to the NG-RAN node during one or more N2 procedures (using UE-specific or non-UE-specific N2 signaling messages) (step 402). The AMF can send the CN capability indication in any of the following N2 procedures and messages: (INITIAL UE Context Setup)
[0056] According to an embodiment, when the AMF sends an NGAP Initial Context Setup Request message to the NG-RAN, it may include the 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 (e.g., the CN MT Data / Signaling Support Indication IE (underlined below)). The details of the modified Initial UE Context Setup message described in 3GPP TS 38.413 are shown below (the changes are underlined): <INITIAL CONTEXT SETUP REQUEST> This message is sent by the AMF to request the setup of a UE context. Direction: AMF → NG-RAN node TIFF2025529683000002.tif236161TIFF2025529683000003.tif176161TIFF2025529683 000004.tif110161TIFF2025529683000005.tif14151TIFF2025529683000006.tif18151
[0057] If the CN capability indication for MT data / signaling is included as part of the CN assistance information in the RRC Inactive IE, the indication may be included as follows: (Modified Core Network Assistance Information for RRC INACTIVE) This IE provides assistance information for RRC inactive configuration. TIFF2025529683000007.tif158161
[0058] Further, as an alternative to the above-enumerated format, 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: TIFF2025529683000008.tif54154<UE Context Modification>
[0059] When the AMF sends an NGAP UE Context Modification Request message (see 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 TIFF2025529683000009.tif206161TIFF2025529683000010.tif122161<HANDOVER REQUEST>
[0060] During an NGAP handover / N2 handover, when the AMF sends an NGAP Handover Request message (see 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 and requests the preparation of resources. Direction: AMF → NG-RAN node TIFF2025529683000011.tif208161TIFF2025529683000012.tif208161TIFF2025529683000013.tif32161<Path Switch Request Acknowledge>
[0061] During XNAP handover / Xn handover, when the AMF sends a NGAP Path Switch Request Acknowledge message (see TS 38.413) to the NG-RAN, it may 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.
[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 TIFF2025529683000014.tif203161TIFF2025529683000015.tif202161<N2 Setup Response> During the setup of the N2 (NG-AP) interface, when the AMF sends a Setup Response message (see TS 38.413) to the NG-RAN, it may include the MT data / signaling processing capability information 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 TIFF2025529683000016.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 TIFF2025529683000017.tif212161TIFF2025529683000018.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 / signal processing (e.g., buffering) in the CN and the NG-RAN.
[0066] Figure 5 is a flowchart of a method in an NG-RAN node according to some embodiments. The NG-RAN node receives a 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). The NG-RAN uses the information for its decision on entering the RRC inactive state for long eDRX values (step 502). More specifically, the NG-RAN uses this information, potentially together with other input parameters, to decide whether to use CN MT data / signaling processing or NG-RAN MT data / signaling processing for UEs in RRC inactive state and long eDRX. If the support / capability notification indicates CN, it means that the CN (e.g., 5GC) supports all functions specified in 3GPP for processing MT data / signaling in the CN when the UE is unreachable in RRC inactive state. In this case, if the CN processing is also supported by NG-RAN, NG-RAN determines that the CN processes MT data / signaling for the UE in RRC inactive state with a long eDRX cycle. If not, long eDRX cannot be used for RRC inactive (e.g., 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) supports all functions specified in 3GPP for handling MT data / signaling in the NG-RAN when the UE is in RRC inactive and unreachable, including UE context retrieval between two NG-RAN nodes via the CN. In this case, the NG-RAN determines that it needs to process MT data / signaling for the UE in RRC inactive state with a long eDRX cycle. If the parameter indicates both, it means that the CN (e.g., 5GC) supports all 3GPP-specified functions for processing MT data / signaling in the RAN and CN. For UEs with long eDRX RRC inactivity, the NG-RAN decides whether to process the MT data / signaling between the CN and NG-RAN based on the NG-RAN's ability to process MT data / signaling and other parameters such as internal / local policies, resources, and traffic patterns. If the CN (e.g., 5GC) does not support any of the features, the NG-RAN will not receive any notification. Alternatively, it may receive a notification indicating "none" or "unsupported" codepoints. In this case, the NG-RAN cannot apply RRC inactive long eDRX, regardless of whether the NG-RAN supports the capability.
[0067] 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 the like), a memory 1106, and a network interface 1108. The one or more processors 1104 are also referred to herein as processing circuits. Additionally, 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 coupled to one or more antennas 1116. The radio units 1110 may refer to or be part of air interface circuitry. In some embodiments, the radio unit 1110 is external to the control system 1102 and is connected to the control system 1102, for example, via a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit 1110 and potentially the antenna 1116 are integrated with the control system 1102. The one or more processors 1104 operate to provide one or more functions of the radio access node 1100 described herein. In some embodiments, the functions are implemented in software that is stored, for example, in the memory 1106 and executed by the one or more processors 1104.
[0068] 8 is a schematic block diagram illustrating a virtualized embodiment of a radio access node 1100 in accordance with some embodiments of the present disclosure. This discussion is equally 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 functionality of the radio access node 1100 is implemented as virtual components (e.g., via virtual machines running on physical processing nodes in a network). As shown, in this example, the radio access node 1100 includes a control system 1102 including one or more processors 1104 (e.g., CPUs, ASICs, FPGAs, and / or the like), 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 coupled to or included as part of a network 1202. Each processing node 1200 includes one or more processors 1204 (eg, CPUs, ASICs, FPGAs, and / or the like), memory 1206, and a network interface 1208.
[0070] In this example, the functions 1210 of the radio access node 1100 described herein are implemented in one or more processing nodes 1200, or distributed in any desired manner between the control system 1102 and one or more processing nodes 1200. In some particular embodiments, some or all of the functions 1210 of the radio 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 appreciated 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 radio unit 1110 communicates directly with the processing node 1200 via an appropriate network interface.
[0071] In some embodiments, a computer program is provided that includes instructions that, when executed by at least one processor, cause the at least one processor to perform the functions of the radio access node 1100 or the functions 1210 of the radio access node 1100 in a virtual environment (e.g., processing node 1200) in accordance with any of the embodiments described herein. In some embodiments, a carrier is provided that includes the aforementioned computer program product. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium (e.g., a non-transitory computer-readable medium such as a memory).
[0072] 7 is a schematic block diagram of a radio access node 1100 in accordance with some other embodiments of the present disclosure. The radio access node 1100 includes one or more modules 1300, each implemented in software. The modules 1300 provide the functionality of the radio access node 1100 described herein. This discussion may equally apply to the processing node 1200 of FIG. 12 , where the modules 1300 may be implemented on one of the processing nodes 1200, distributed across multiple processing nodes 1200, and / or distributed across the processing nodes 1200 and the control system 1102.
[0073] 9 is a schematic block diagram of a UE 1400 according to some embodiments of the present disclosure. As shown, the UE 1400 includes one or more processors 1402 (e.g., a CPU, an ASIC, an FPGA, and / or the like), 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 transceivers 1406 include radio front-end circuitry connected to the antennas 1412 configured to condition signals communicated between the antennas 1412 and the processor 1402, as will be appreciated by those skilled in the art. The processor 1402 is also referred to herein as a processing circuit. The transceivers 1406 are also referred to herein as radio circuitry. In some embodiments, the functionality of the UE 1400 described above may be implemented, fully or partially, in software, for example, stored in the memory 1404 and executed by the processor 1402. It should be noted that UE1400 may include additional components not shown in FIG. 14 , such as, for example, one or more user interface components (e.g., an input / output interface including a display, buttons, a touchscreen, a microphone, a speaker, and / or the like, and / or any other components for enabling the input of information to UE1400 and / or the output of information from UE1400), a power source (e.g., a battery and associated power circuitry), etc.
[0074] In some embodiments, a computer program is provided that includes instructions that, when executed by at least one processor, cause the at least one processor to perform the functions of the UE 1400 according to any of the embodiments described herein. In some embodiments, a carrier is provided that includes the aforementioned computer program product. The carrier is one of an electronic signal, an optical signal, a wireless signal, or a computer-readable storage medium (e.g., a non-transitory computer-readable medium such as a memory).
[0075] 10 is a schematic block diagram of a UE 1400 according to some other embodiments of the present disclosure. The UE 1400 includes one or more modules 1500, each implemented in software. The modules 1500 provide the functionality of the UE 1400 described herein.
[0076] 11 is a diagram illustrating a communication system according to some embodiments of the present disclosure. Referring to FIG. 11, according to one embodiment, the communication system includes a telecommunications network 1600, such as a 3GPP-type cellular network, composed of an access network 1602, such as a RAN, and a core network 1604. The access network 1602 includes multiple base stations 1606A, 1606B, 1606C, such as NBs, eNBs, gNBs, or other types of wireless access points (APs), each defining a corresponding coverage area 1608A, 1608B, 1608C. Each base station 1606A, 1606B, 1606C can be connected to the core network 1604 via a wired or wireless connection 1610. A first UE 1612 located in the coverage area 1608C is configured to wirelessly connect to or be paged by the corresponding base station 1606C. A second UE 1614 located in the coverage area 1608A can wirelessly connect to the corresponding base station 1606A. While multiple UEs 1612, 1614 are shown in this example, the disclosed embodiments are equally applicable to situations where one UE is within a coverage area or connected to the corresponding base station 1606.
[0077] The telecommunications network 1600 is itself connected to a host computer 1616, which may be embodied in hardware and / or software as a standalone server, a cloud-implemented server, a distributed server, or a processing resource within a server farm. The host computer 1616 may be under the ownership or control of 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 may go through an optional intermediate network 1622. The intermediate network 1622 may be one or a combination of two or more of a public, private, or hosted network; the intermediate network 1622, if any, may be a backbone network or the Internet; in particular, the intermediate network 1622 may include two or more subnetworks (not shown).
[0078] The communication system of FIG. 11 as a whole enables connectivity between connected UEs 1612, 1614 and a host computer 1616. This connectivity may be described as an Over-the-Top (OTT) connection 1624. The host computer 1616 and connected UEs 1612, 1614 are configured to communicate data and / or signaling via the OTT connection 1624 using the access network 1602, the core network 1604, any intermediate networks 1622, and possible further infrastructure (not shown) as intermediaries. The OTT connection 1624 may be transparent in the sense that the participating communication devices through which the OTT connection 1624 passes are unaware of the routing of the uplink and downlink communications. For example, the base station 1606 may not and need not be informed of the past routing of an incoming downlink communication having data originating from the host computer 1616 that is forwarded (e.g., handed off) to the connected UE 1612. Similarly, the base station 1606 does not need to be aware of the future routing of outgoing uplink communications originating from the UE 1612 towards the host computer 1616 .
[0079] FIG. 12 illustrates a communication system according to some embodiments of the present disclosure. Referring now to FIG. 12, an exemplary implementation of the UE, base station, and host computer described in the previous paragraph will be described. In the communication system 1700, the host computer 1702 includes hardware 1704 including a communication interface 1706 configured to establish and maintain wired or wireless connections with interfaces of different communication devices in the communication system 1700. The host computer 1702 further includes processing circuitry 1708, which may have memory 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 stored within 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 operable to provide services to a remote user, such as a UE 1714, connecting via an OTT connection 1716 that terminates at the UE 1714 and the host computer 1702. In providing services to the remote user, the host application 1712 may provide user data that is transmitted using the OTT connection 1716.
[0080] The communications system 1700 further includes a base station 1718 including hardware 1720 provided within the telecommunications system to enable communications with the host computer 1702 and the UE 1714. The hardware 1720 may include a communications interface 1722 for establishing and maintaining wired or wireless connections with interfaces of different communications devices of the communications system 1700, and a wireless interface 1724 for establishing and maintaining at least a wireless connection 1726 with a UE 1714 located within a coverage area (not shown in FIG. 12 ) provided by the base station 1718. The communications interface 1722 may be configured to facilitate a connection 1728 to the host computer 1702. The connection 1728 may be direct, may pass through a core network of the telecommunications system (not shown in FIG. 12 ), or may 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 combinations thereof (not shown) adapted to execute instructions. The base station 1718 further includes software 1732 stored internally or accessible via an external connection.
[0081] The communications system 1700 further includes the previously mentioned UE 1714. The hardware 1734 of the UE 1714 may include a wireless interface 1736 configured to establish and maintain a wireless connection 1726 with a base station serving a 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 combinations thereof (not shown) adapted to execute instructions. The UE 1714 further includes software 1740, which is stored on 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, with support from the host computer 1702, may be operable to provide services to a human or non-human user via the UE 1714. At the host computer 1702, a running host application 1712 may communicate with a running client application 1742 via a UE 1714 and an OTT connection 1716 that terminates at the host computer 1702. In providing a service to a user, the client application 1742 may receive request data from the host application 1712 and provide user data in response to the request data. The OTT connection 1716 may transfer both the request data and the user data. The client application 1742 may interact with the user to generate the user data to provide.
[0082] It should be noted that the host computer 1702, base station 1718, and UE 1714 illustrated in Figure 12 may be similar to or identical to the host computer 1616, one of the base stations 1606A, 1606B, 1606C, and one of the UEs 1612, 1614, respectively, of Figure 11. 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] 12 , the OTT connection 1716 is depicted abstractly to show communication between the host computer 1702 and the UE 1714 via the base station 1718, without explicitly referencing any intermediate devices and the exact routing of messages through those devices. The network infrastructure may determine the routing to be configured to be hidden from the UE 1714, from the service provider operating the host computer 1702, or both. The network infrastructure may also determine to dynamically change the routing (e.g., based on load balancing considerations or network reconfiguration) while the OTT connection 1716 is active.
[0084] The wireless connection 1726 between the UE 1714 and the base station 1718 follows the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of the OTT service provided to the UE 1714 using the OTT connection 1716 of which the wireless connection 1726 forms the last segment. More precisely, the teachings of these embodiments enable MT data or signaling from the OTT to be processed in the 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 rates, delays, and other factors that one or more embodiments improve. There may further be optional network functionality for reconfiguring the OTT connection 1716 between the host computer 1702 and the UE 1714 in response to fluctuations in the measurement results. The measurement procedures and / or the network functionality 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 associated with the communication devices through which the OTT connection 1716 passes, and the sensors may participate in the measurement procedures by providing values of the monitored quantities exemplified above, or by providing values of other physical quantities from which the software 1710, 1740 can calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 1716 may include message formats, retransmission settings, priority routing, etc. The reconfiguration need not affect the base station 1718 and may be unknown or imperceptible to the base station 1718. Such procedures and functionality are known in the art and may be implemented. In particular embodiments, the measurements may include proprietary UE signaling that facilitates the host computer 1702 measuring throughput, propagation time, delay, etc. The measurements may be implemented to have the OTT connection 1716 send messages, particularly empty or "dummy" messages, while the software 1710 and 1740 monitors propagation time, errors, etc.
[0086] FIG. 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 FIGS. 11 and 12. To simplify this disclosure, this section includes only the drawing reference to FIG. 13. In step 1800, the host computer provides user data. In sub-step 1802 of step 1800 (which may be optional), the host computer provides the user data by executing a host application. In step 1804, the host computer initiates a transmission that transmits the user data to the UE. In step 1806 (which may be optional), the base station transmits the user data transmitted in the host computer-initiated transmission to the UE, according to the teachings of the embodiments described throughout this disclosure. In step 1808 (which may be optional), the UE executes a client application associated with the host application executed by the host computer.
[0087] FIG. 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 a UE, which may be described with reference to FIGS. 11 and 12. To simplify this disclosure, this section includes only drawing references to FIG. 14. In step 1900 of the method, the host computer provides user data. In an optional substep (not shown), the host computer provides the user data by executing 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 in accordance with the teachings of the embodiments described throughout this disclosure. In step 1904 (which may be optional), the UE receives the user data transmitted in the transmission.
[0088] Pertinent steps, methods, features, functions, or advantages disclosed herein may be performed via one or more functional units or modules of one or more virtual devices. Each virtual device may include many of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessors or microcontrollers, or other digital hardware including digital signal processors (DSPs), special-purpose digital logic, etc. The processing circuitry 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 implementing 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 circuitry may be used to cause each functional unit to perform a function corresponding to the respective functional unit in accordance with one or more embodiments of the present disclosure.
[0089] While steps in the figures may indicate a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, etc.). (Embodiment) Group A Implementation - 5G AMF
[0090] Embodiment 1: A method performed by a network function of a core network (CN), the method including: - determining the capabilities of the CN to support the functionality required for processing mobile terminated (MT) data / signaling in the CN or in a radio access network, or both, for one or more RRC inactive user equipments (UEs) with long eDRX cycles; - Informing the radio access network of the capabilities.
[0091] Embodiment 2: The method of embodiment 1, wherein the 5G network node includes an Access and Mobility Management Function (AMF).
[0092]
[0013] Embodiment 3: The method of embodiment 1 or 2, wherein the step of informing the radio access network of the capabilities includes sending the capabilities in an INITIAL CONTEXT SETUP REQUEST message.
[0093]
[0021] Embodiment 4: The method of embodiment 1 or 2, wherein the step of informing the radio access network of the capabilities includes sending the capabilities in a UE CONTEXT MODIFICATION REQUEST message.
[0094]
[0021] Embodiment 5: The method of embodiment 1 or 2, wherein the step of informing the radio access network of the capabilities includes sending the capabilities in a HANDOVER REQUEST message.
[0095]
[0021] Embodiment 6: The method of embodiment 1 or 2, wherein the step of informing the radio access network of the capabilities includes sending the capabilities in a PATH SWITCH REQUEST ACKNOWLEDGE message.
[0096]
[0021] Embodiment 7: The method of embodiment 1 or 2, wherein the step of informing the radio access network of the capabilities includes sending the capabilities in a NG / N2 SETUP RESPONSE message.
[0097]
[0013] Embodiment 8: The method of embodiment 1 or 2, wherein the step of informing the radio access network of the capabilities includes sending the capabilities in an AMF CONFIGURATION UPDATE message.
[0098]
[0023] Embodiment 9: The method of any one of embodiments 1 to 8, wherein the capability is included in a CN Assistance Information for RRC INACTIVE information element. Group B Embodiment - Radio Access Node of RAN
[0099]
[0023] Embodiment 10: A method performed by a radio network node in a radio access network and connected to a core network (CN), the method including: - receiving, for one or more user equipments (UEs) in RRC inactivity with a long eDRX cycle, notification of the CN's capability to support functionality required for processing mobile terminated (MT) data / signaling in the CN or the radio access network or both; - determining whether MT data / signaling processing in the CN or MT data / signaling processing in the radio access node will be used for the one or more UEs in RRC inactive state with a long eDRX cycle based on the notification and the capability of the radio network node to process MT data / signaling.
[0100] Embodiment 11: The method of embodiment 10, wherein determining that MT data / signaling is used in the CN is based on the notification of the capabilities of the CN indicating that the CN supports functions 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 determination in the radio access node that MT data / signaling is used is based on the notification of the capabilities of the CN indicating that the CN supports the functionality required for processing mobile terminated (MT) data / signaling in the radio access network or both the radio access network and the CN, and the capability of the radio network node to process MT data / signaling.
[0102] Embodiment 13: The method of any one of embodiments 10 to 12, wherein the notification of the capability is included in a CN Assistance Information for RRC INACTIVE information element.
[0103]
[0023] Embodiment 14: The method of embodiment 10, wherein the step of receiving the notification of the capability includes receiving the notification in an INITIAL CONTEXT SETUP REQUEST message.
[0104]
[0023] 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]
[0023] 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]
[0033] 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]
[0033] Embodiment 18: The method of embodiment 10, wherein the step of receiving the notification of the capability includes receiving the notification in an 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 an AMF CONFIGURATION UPDATE message.
[0109]
[0033] Embodiment 20: The method of embodiment 10, wherein the notification of the capabilities of the CN further indicates that the CN does not support functionality required 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 implicit (e.g., not received by the CN) or explicit (e.g., received by the CN).
[0111]
[0042] Embodiment 22: The method of embodiment 20, wherein the method further includes not applying long eDRX for RRC inactivity regardless of the capability of the radio access node to support MT data / signaling. Group C Embodiments - Devices
[0112] Embodiment 23: A network node implementing a network function including processing circuitry configured to perform the steps of any of the embodiments of any of Group A.
[0113]
[0072] Embodiment 24: The network node of embodiment 23, wherein the network node includes an Access and Mobility Management Function (AMF) node.
[0114] Embodiment 25: A radio network node including processing circuitry configured to perform any of the steps of any of the embodiments of Group B.
[0115] Embodiment 26: The radio network node of embodiment 25, wherein the radio network node includes a gNB.
[0116] In this disclosure, at least some of the following abbreviations may be used. In case of conflict between abbreviations, the above usage shall prevail. If multiple occurrences below occur, the first occurrence shall prevail over any subsequent occurrences. 3GPP 3rd Generation Partnership Project 5G (fifth 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 Downlink ·DN Data Network DRX discontinuous reception DSP Digital Signal Processor eDRX enhanced discontinuous reception eNB Enhanced or evolved Node B EPC Evolved Packet Core EPS Evolutionary Packet System E-UTRA Evolved Universal Terrestrial Radio Access E-UTRAN Evolved Universal Terrestrial Radio 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 Telecommunications) 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 Radio Access Network Notification Area RNTI Radio Network Temporary Identifier ROM Read-Only Memory RRC Radio Resource Control RRH Remote Radio 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 the embodiments of the present disclosure, and all such improvements and modifications are considered to be within the scope of the concepts disclosed herein.
Claims
1. 1. A method performed by a network function of a core network (CN), comprising: determining the capability of the CN to support processing of mobile terminated (MT) data / signaling for a user equipment (UE) when in a radio resource control (RRC) inactive state with a long extended discontinuous reception (eDRX) cycle; sending a notification to the Radio Access Network (RAN) serving the UE indicating that the CN supports MT data / signaling processing; A method comprising:
2. 10. The method of claim 1, wherein the 5G network node includes an Access and Mobility Management Function (AMF).
3. 3. The method of claim 1, wherein the step of sending the notification to the radio access network comprises sending the notification in an INITIAL CONTEXT SETUP REQUEST message.
4. The method of claim 1 or 2, wherein the step of sending the notification to the radio access network comprises sending the notification in a UE CONTEXT MODIFICATION REQUEST message.
5. The method of claim 1 or 2, wherein the step of sending the notification to the radio access network comprises sending the notification in a HANDOVER REQUEST message.
6. 3. The method of claim 1, wherein the step of sending the notification to the radio access network comprises sending the notification in a PATH SWITCH REQUEST ACKNOWLEDGE message.
7. The method of claim 1 or 2, wherein the step of sending the notification to the radio access network comprises sending the notification in a NG / N2 SETUP RESPONSE message.
8. The method of claim 1 or 2, wherein the step of sending the notification to the radio access network comprises sending the notification in an AMF CONFIGURATION UPDATE message.
9. The method of claim 1 , wherein the notification is sent to the RAN in a CN Assistance Information for RRC INACTIVE information element.
10. 2. The method of claim 1, wherein the long eDRX cycle comprises a DRX cycle longer than 10.24 seconds.
11. 11. The method of claim 1 or 10, wherein the step of determining the capability of the CN to support processing of mobile terminated (MT) data / signaling for a user equipment (UE) when in an RRC state with a long eDRX cycle comprises determining the capability to buffer MT data / signaling for the UE when in an RRC inactive state with a long eDRX cycle.
12. 1. A method performed by a radio network node in a radio access network (RAN) and connected to a core network (CN), comprising: receiving a notification from a user equipment (CN) indicating that the CN supports processing of MT data / signaling for a user equipment (UE) when in a radio resource control (RRC) inactive state with a long extended discontinuous reception (eDRX) cycle; and determining, based on the received notification, that MT data / signaling can be processed in the CN for the UE in an RRC inactive state with a long eDRX cycle. method.
13. The method of claim 12 , wherein the notification is received from the CN in a CN Assistance Information for RRC INACTIVE information element.
14. 14. The method of claim 12, wherein the step of receiving the notification comprises receiving the notification in an INITIAL CONTEXT SETUP REQUEST message.
15. 14. The method of claim 12, wherein the step of receiving the notification comprises receiving the notification in a UE CONTEXT MODIFICATION REQUEST message.
16. 14. The method of claim 12, wherein the step of receiving the notification comprises receiving the notification in a HANDOVER REQUEST message.
17. 14. The method of claim 12, wherein the step of receiving the notification comprises receiving the notification in a PATH SWITCH REQUEST ACKNOWLEDGE message.
18. 14. The method of claim 12, wherein the step of receiving the notification comprises receiving the notification in a NG / N2 SETUP RESPONSE message.
19. 14. The method of claim 12, wherein the step of receiving the notification comprises receiving the notification in an AMF CONFIGURATION UPDATE message.
20. The method of claim 12 , wherein the notification further indicates that the CN does not support processing of mobile-terminated (MT) data / signaling.
21. 21. The method of claim 20, further comprising determining whether to process MT data / signaling at the RAN node.
22. 15. The method of claim 14, wherein the long eDRX cycle comprises a DRX cycle longer than 10.24 seconds.
23. 23. The method of claim 14 or 22, wherein the indication that the CN supports MT data / signaling processing used for user equipment (UE) in a radio resource control (RRC) inactive state with a long extended discontinuous reception (eDRX) cycle corresponds to the CN being able to buffer MT data / signaling for the UE in an RRC inactive state with a long eDRX cycle.
24. A network node implementing a network function in a Core Network (CN), said network node comprising a processing circuit and a memory containing instructions which, when executed by said processing circuit, perform the method of any one of claims 1 to 13. Network node.
25. A radio network node comprising a processing circuit and a memory containing instructions which, when executed by said processing circuit, perform the method of any one of claims 14 to 23. Wireless network node.
26. 22. The radio network node of claim 21, wherein the radio network node is a next generation node B in a fifth generation system.