WO2020146064A1

WO2020146064A1 - System and method for providing assistance data to a core network

Info

Publication number: WO2020146064A1
Application number: PCT/US2019/064602
Authority: WO
Inventors: Torgny Palenius; Lars Nord
Original assignee: Sony Corporation; Sony Electronics, Inc
Priority date: 2019-01-10
Filing date: 2019-12-05
Publication date: 2020-07-16

Abstract

A radio access network (RAN) node (130) of a wireless communication network (102), the RAN node (130) having a first radio link with a user equipment (100). The RAN node (130) is configured to receive, from the core network, downlink data intended for the user equipment (100). The RAN node (130) is further configured to determine that the user equipment (100) is unavailable while in an inactive state, and transmit a message to the core network (104). The message can include at least one of an identification of the user equipment (100), an identification of a Protocol Data Unit (PDU) session associated with the radio link, or an indication of whether the downlink data has been dropped or will be delivered to the user equipment (100).

Description

TITLE: SYSTEM AND METHOD FOR PROVIDING ASSISTANCE DATA TO A CORE NETWORK

RELATED APPLICATION DATA

This application claims the benefit of Swedish Patent Application No. 1930010-2, filed January 10, 2019, the disclosure of which is incorporated herein by reference in its entirety.

TECHNICAL FIELD OF THE INVENTION

The technology of the present disclosure relates generally to cellular network operation and, more particularly, to a system and method for providing assistance data relating to connection of a user equipment from a radio access network to a core network, such data may be used by the core network to implement high latency communication protocols when a user equipment is in an inactive state.

BACKGROUND

In existing mobile networks, the core network has full control of the reachability of the user equipment, since the control network knows the configured extended

discontinuous reception (eDRX) or power save mode (PSM). Additionally, the core network can know the uplink traffic pattern based on the user equipment service request pattern. Prior methods of configuring an extended sleep time are based on the core network having full knowledge and control of the user equipment’s sleep patterns and behavior.

In certain networks, when user equipment sleep patterns and behavior is controllable by the radio access network (RAN) (e.g. when the user equipment is in RRC Inactive status as defined by 3 GPP standards) it is the RAN that configures the eDRX and is also the only node that sees each RRC Connection establishment or resume request. The core network is unaware of how the user equipment behaves with respect to sleep patterns and behavior, and is therefore not aware of when the user equipment is reachable or not. The core network only knows that the user equipment is connected (e.g. CM_Connected status) and, as a result, believes that the user equipment is always reachable even when the user equipment has an RRC Inactive status and is unavailable.

SUMMARY

The disclosed systems and methods provide for a 3 GPP radio access network (RAN) node to provide the core network with assistance data related to the availability of user equipment (UE). Since the core network may not be aware of the UE's sleep pattern or availability, this data serves a fundamental purpose of informing the core network of the UE’s status. For example, the RAN node can provide the core network with a message including at least one of an identification of the user equipment, an identification of a Protocol Data Unit (PDU) session associated with the radio link, an indication of whether the downlink data has been dropped or will be delivered to the user equipment, or a time until next UE availability. The assistance data serves the purpose of enabling the features of long sleep and notification solutions known as high latency communication (HLcom) features, typically used while a UE is in idle mode (e.g. CM idle as defined by 3GPP), to be used with new radio resource control (RRC) states such as RRC Inactive /

CM_Connected in wireless communication systems such as a 5G network.

According to one aspect of the disclosure, a radio access network (RAN) node configured to operate in a radio access network of a wireless communication network includes: a wireless interface to establish a radio link between a user equipment and the radio access network; an interface to a core network of the wireless communication network; and a control circuit configured to receive, from the core network, downlink data intended for the user equipment; determine that the user equipment is unavailable while in an inactive state; and transmit a message to the core network, wherein the message includes at least one of an identification of the user equipment, an identification of a Protocol Data Unit (PDU) session associated with the radio link, or an indication of whether the downlink data has been dropped or will be delivered to the user equipment. According to an embodiment of the RAN node, the control circuit is further configured to determine a time until next user equipment availability to receive the downlink data.

According to an embodiment of the RAN node, the message to the core network further includes the time until next user equipment availability to receive the downlink data.

According to an embodiment of the RAN node, control circuit is further configured to determine whether extended buffering is available; and store the downlink data in a buffer in response to determining that extended buffering is available.

According to an embodiment of the RAN node, the control circuit is further configured to transmit the downlink data from the buffer to the user equipment upon determining that the user equipment is available to receive the downlink data.

According to an embodiment of the RAN node, the control circuit is further configured to determine whether extended buffering is available; and drop the downlink data in response to determining that extended buffering is not available.

According to another aspect of the disclosure, a method of enabling high latency communication features by a radio access network (RAN) node that operates in a wireless communications network includes establishing a radio link between a user equipment and the RAN node; receiving, at the RAN node and from a core network of the wireless communication network, downlink data intended for the user equipment; determining that the user equipment is unavailable while in an inactive state; and transmitting a message to the core network, wherein the message includes at least one of an identification of the user equipment, an identification of a Protocol Data Unit (PDU) session associated with the radio link, and an indication of whether the downlink data has been dropped or will be delivered to the user equipment.

According to an embodiment of the method, the method further includes determining a time until next user equipment availability to receive the downlink data. According to an embodiment of the method, the message to the core network further includes the time until next user equipment availability to receive the downlink data.

According to an embodiment of the method, the method further includes determining whether extended buffering is available; and storing the downlink data in a buffer in response to determining that extended buffering is available.

According to an embodiment of the method, the method further includes transmitting the downlink data from the buffer to the user equipment upon determining that the user equipment is available to receive the downlink data.

According to an embodiment of the method, the method further includes determining whether extended buffering is available; and dropping the downlink data in response to determining that extended buffering is not available.

According to another aspect of the disclosure, a system comprising one or more core network servers of a wireless communications network, the one or more core network servers comprising one or more processors that execute logical operations to receive a message from a RAN node, wherein the message includes at least one of an identification of a user equipment, an identification of a Protocol Data Unit (PDU) session associated with a radio link between the RAN node and the user equipment, or an indication of whether downlink data intended for the user equipment has been dropped or will be delivered to the user equipment; and transmit a high latency communication (HLcom) message to an application server, wherein the HLcom message is generated based on the message from the RAN node.

According to an embodiment of the system, the HLcom message notifies the application server that the user equipment was not available to receive the downlink data from the RAN node, and includes the indication of whether the downlink data has been dropped or will be delivered to the user equipment at a later time.

According to an embodiment of the system, the HLcom message further includes an estimated time that the downlink data will be delivered to the user equipment. According to an embodiment of the system, the one or more processors are further configured to transmit a second HLcom message to the application server to notify the application server that the user equipment is about to become available to receive the downlink data or has become available to receive the downlink data.

According to another aspect of the disclosure, a method of transmitting downlink data intended for a user equipment includes receiving a message from a RAN node, wherein the message includes at least one of an identification of the user equipment, an identification of a Protocol Data Unit (PDU) session associated with a radio link between the RAN node and the user equipment, or an indication of whether downlink data intended for the user equipment has been dropped or will be delivered to the user equipment; and transmitting a high latency communication (HLcom) message to an application server, wherein the HLcom message is generated based on the message from the RAN node.

According to an embodiment of the method, the HLcom message notifies the application server that the user equipment was not available to receive the downlink data from the RAN node, and includes the indication of whether the downlink data has been dropped or will be delivered to the user equipment.

According to an embodiment of the method, the HLcom message further includes an estimated time that the downlink data will be delivered to the user equipment.

According to an embodiment of the method, the method further includes transmitting a second HLcom message to the application server to notify the application server that the user equipment is about to become available to receive the downlink data or has become available to receive the downlink data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of an operational network environment for an electronic device, also referred to as a user equipment.

FIG. 2 is a schematic diagram of a radio access network (RAN) node in the network environment. FIG. 3 is a schematic diagram of a core network function server in the network environment.

FIG. 4 is an exemplary signaling diagram of communications during a first state. FIG. 5 is an exemplary signaling diagram of communications during a second state.

FIG. 6 is an exemplary signaling diagram of communications during a third state. FIG. 7 is a flow diagram of operations carried out by a RAN node.

FIG. 8 is a flow diagram of operations carried out by a core network.

DETAILED DESCRIPTION OF EMBODIMENTS

Embodiments will now be described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. It will be understood that the figures are not necessarily to scale. Features that are described and/or illustrated with respect to one embodiment may be used in the same way or in a similar way in one or more other embodiments and/or in combination with or instead of the features of the other embodiments.

As used herein, the term“inactive state” refers to a state in which a user equipment (UE) 100 is registered to the wireless network 102 and is in a connected state as seen from the Core Network (CM_Connected), but is not continuously available to receive data from a RAN node 130. An example of such an inactive state is RRC_Inactive as defined by 3GPP technical specifications.

System Architecture

FIG. 1 is a schematic diagram of an exemplary network environment in which the disclosed techniques are implemented. It will be appreciated that the illustrated network environment is representative and other environments or systems may be used to implement the disclosed techniques. Also functions disclosed as being carried out by a single device, such as the disclosed core network server, may be carried out in a distributed manner across nodes of a computing environment.

The network environment relates to an electronic device, such a user equipment (UE) 100. As contemplated by 3GPP standards, the UE may be a mobile radiotelephone (a "smartphone"). Other exemplary types of UEs 100 include, but are not limited to, a gaming device, a media player, a tablet computing device, a computer, and an internet of things (IoT) device that communicates using machine-to-machine (M2M) communications or machine-type communications (MTC).

The network environment includes a wireless communication network 102 that is configured in accordance with one or more 3GPP standards, such as a 3G network, a 4G network or a 5G network. The wireless communication network 102 also may be referred to as a 3GPP network 102. The 3GPP network 102 includes a core network (CN) 104 and a radio access network (RAN) 106. The core network could be, for example, a 5G Core Network. FIG. 1 is a service-based representation to illustrate the 3GPP network 102, but other representations are possible, such as a reference point representation. The CN 104 includes a user plane function (UPF) 108 that provides an interface to a data network, which represents operator services, connection to the Internet, third party services, etc.

The 5G core network, 5GC, 104 includes one or more servers (e.g. core network server 300) that host a variety of functions, illustrated examples of which include, but are not limited to, the UPF 108, an authentication server function (AUSF) 112, a core access and mobility management function (AMF) 114, a session management function (SMF)

116, a network exposure function (NEF) 118, a network repository function (NRF) 120, a policy control function (122), a unified data management (UDM) 124, and an application function (AF) 126. In one embodiment, the NEF 118 provides an interface to an application server 110 that may be, for example, located on the internet.

The RAN 106 can include a plurality of RAN nodes 130. Each RAN node 130 may be a base station such as an evolved node B (eNB) base station or a 5G generation gNB base station. A radio link may be established between the UE 100 and one of the RAN nodes 130. The RAN 106 is considered to have a user plane and a control plane, the control plane implemented with radio resource control (RRC) signaling between the UE 100 and the RAN node 130. Another control plane between the UE 100 and the CN 104 is present and implemented with non-access stratum (NAS) signaling.

With reference to FIG. 2, illustrated is a schematic block diagram of the RAN node 130. The RAN node 130 includes a control circuit 200 that is responsible for overall operation of the RAN node 130, including controlling the RAN node 130 to carry out the operations described in herein. In an exemplary embodiment, the control circuit 200 may include a processor (e.g., a central processing unit (CPU), microcontroller, or

microprocessor) that executes logical instructions (e.g., lines or code, software, etc.) that are stored by a memory (e.g., a non-transitory computer readable medium) of the control circuit 200 in order to carry out operation of the RAN node 130.

The RAN node 130 includes a wireless interface 202, such as a radio transceiver, for establishing an over the air connection with the UE 100. The RAN node 130 also includes an interface 204 to the core network 104, which typically includes operative connectivity to the AMF 114 and/or the UPF 108. The RAN node 130 can also include an interface 206 to one or more neighboring RAN nodes 130 for conducting network coordination in the RAN 106.

With additional reference to FIG. 3, illustrated is a schematic block diagram of a core network function server 300 of the core network 104 that executes logical instructions (e.g., in the form of one or more software applications) to carry out one or more of the functions of the core network 104. It will be understood, however, that aspects of the one or more functions may be distributed across nodes of a computing environment.

The server 300 may be implemented as a computer-based system that is capable of executing computer applications (e.g., software programs) that, when executed, carry out functions of the server 300. As is typical for a computing platform, the server 300 may include a non-transitory computer readable medium, such as a memory 304 that stores data, information sets and software, and a processor 306 for executing the software. The processor 306 and the memory 304 may be coupled using a local interface 308. The local interface 308 may be, for example, a data bus with accompanying control bus, a network, or other subsystem. The server 300 may have various input/output (I/O) interfaces for operatively connecting to various peripheral devices, as well as one or more

communications interfaces 310. The communications interface 310 may include for example, a modem and/or a network interface card. The communications interface 310 may enable the server 300 to send and receive data signals to and from other computing devices in the core network 104, RAN nodes 130, and/or other locations as is appropriate.

Core Network Assistance Operations

With additional reference to FIGS. 4-6, shown are exemplary signaling diagrams representing communication among the application server 110, core network 104, RAN node 130, and UE 100 in the wireless communication network 102. When the UE 100 is in RRC_Connected/CM_Connected state, the user plane is configured and all tunnels are setup for user downlink data to be automatically routed to the RAN node 130 that the UE 100 is connected to. Once the downlink data arrives at the RAN node 130, the RAN node 130 will allocate the radio resources to send the downlink data to the UE 100. When the RAN node 130 decides to release the UE 100 to RRC_Inactive state, the core network 104 is not made aware and therefore the user plane path between the core network 104 and the RAN node 130 is still available. This means that any downlink data will be sent down to the RAN node 130 even when the UE 100 is in the RRC Inactive state and unavailable to immediately receive the downlink data. Furthermore, the AMF 114 could send, for example, a short message service (SMS) message or NAS signaling message to the RAN node 130, since the AMF 114 believes that the UE 100 is still reachable.

Messaging and interactions between the RAN node 130 and the core network 104 can allow the core network 104 to apply the full HLcom features for a UE 100 in RRC Inactive mode. The notification message discussed below allows the RAN node 130 to disclose information needed by the core network 104 in the HLcom notification message service between the core network 104 and application server 110. By introducing the notification message from the RAN node 130 to the core network 104, it is possible to apply improved levels of sleep and power save modes for a UE 100 even if the UE 100 is in RRC_Inactive mode. Without this new notification message, the UE 100 sleep time is limited by, for example, NAS retransmission timers of 10-20s. In an exemplary embodiment, the application server 110 transmits a downlink data packet to the core network 104. For example, the application server 110 can transmit the downlink data to the UPF 108, which acts as a gateway connecting the core network 104 to the Data Network/application server. The application server 110 can furthermore be connected to the NEF 118. Next, the UPF 108 transmits the downlink data packet to the RAN node 130, for example, through an established connection between the RAN node 130 and UPF 108. Once the RAN node receives the downlink data, the RAN node 130 can respond in different ways depending on various factors as detailed below.

Turning now to FIG. 4, once the RAN node 130 receives the downlink data packet, the RAN node 130 determines whether or not the UE 100 is available to receive the downlink data packet. If the UE 100 is unavailable while in an inactive state (e.g. if the UE 100 is between paging occasions while in RRC_Inactive state), the RAN node 130 then determines the UE’s 100 next time to availability to receive the downlink data packet. If the RAN node 130 determines that the UE’s 100 time to availability is short (e.g. less than a predetermined threshold based on implementation considerations such as available RAN node 130 memory and/or the requirements of other users), then the RAN node 130 stores the downlink data in a buffer. The RAN node 130 will then either page the UE 100 at the next paging occasion or include the downlink data with the next UE-triggered RRC connection due to mobile-originated data. In other words, once the UE 100 becomes available (e.g. responds to paging and/or changes to RRC_Connected state), the RAN node 130 then transmits the downlink data packet stored in the buffer to the UE 100.

Turning now to FIG. 5, if the time until the next availability is long (e.g. greater than a predetermined threshold based on implementation considerations such as available RAN node 130 memory and/or the requirements of other users), but extended buffering could apply, the RAN node 130 will buffer the data and send a notification message to the core network 104 that can trigger a high latency communications (HLcom) notification messages to the application server via the NEF 118. Extended buffering can apply when the buffer has enough memory available for storing the downlink data until the time of next UE 100 availability. Once the RAN node 130 receives the downlink data packet, the RAN node 130 determines whether or not the UE 100 is available to receive the downlink data packet.

If the UE 100 is unavailable while in an inactive state (e.g. if the UE 100 is between paging occasions while in RRC_Inactive state), the RAN node 130 then determines the UE 100 next time to availability to receive the downlink data packet. If the RAN node 130 determines that the UE’s time to availability is long, but extended buffering applies, then the RAN node 130 stores the downlink data in a buffer and also sends a notification message to the core network 104 (e.g. from the RAN node 130 to the AMF 114). The notification message can include information such as an identification of the UE 100 (e.g. 5G Globally Unique Temporary Identity (5G-GUTI) or S-TMSI), an identification of the relevant Protocol Data Unit (PDU) session, the time until next estimated reachability event or availability of the UE 100 to receive downlink transmissions, and whether the downlink data packet has been dropped by the RAN node 130 or is planned to be delivered to the UE 100 at the UE’s 100 next reachability event or availability. In this case, the notification message would inform the core network 104 that the downlink data packet will be delivered to the UE 100 at the UE’s 100 next availability to receive the downlink data packet.

After receiving the notification message from the RAN node 130, the core network 104 can communicate with the application server 110 via the NEF 118 regarding the transmission and/or status of the downlink data packet delivery to the UE 100, based on the information received in the notification message. The identification of the relevant PDU session can be used by the core network 104 to identify the proper application server 110. The SMF 116 stores the PDU relationships to application servers and can identify the corresponding application server based on the PDU session identification included in the notification message from the RAN node 130. The core network’s 104 interaction with the application server 110 (via the NEF 118) is specified for HLcom features and the northbound application program interface (API) is used between the NEF 118 and the application server 110. In this manner, the core network 104 can effectively use the HLcom features to inform the application server based on the information received by the new notification message received from the RAN node 130. Meanwhile, the RAN node 130 transmits the downlink data packet to the UE 100 as soon as, or after the UE 100 has become available to receive the downlink data packet (e.g. the UE 100 has switched to RRC Connected).

Turning now to FIG. 6, once the RAN node 130 receives the downlink data packet, the RAN node 130 again determines whether or not the UE 100 is available to receive the downlink data packet. If the UE 100 is unavailable while in an inactive state (e.g. if the UE 100 is between paging occasions while in RRC_Inactive state), the RAN node 130 then determines the UE 100 next time to availability to receive the downlink data packet. If the RAN node 130 determines that the time until the next UE 100 availability is too long for the RAN node 130 to store the data in a buffer, or if the RAN node’s 130 buffer storage is too full, the RAN node 130 will drop the downlink data packet and send a notification message to the core network 104. By dropping the downlink data packet, the RAN node 130 is neither transmitting the downlink data packet to the UE 100 or saving it to a buffer.

The notification message can include information such as an identification of the UE 100 (e.g. 5G Globally Unique Temporary Identity (5G-GUTI) or S-TMSI), an identification of the relevant Protocol Data Unit (PDU) session, the time until next estimated reachability event or availability of the UE 100 to receive downlink

transmissions, and that the downlink data packet has been dropped by the RAN node 130. Further, the notification message could inform the core network 104 of the time until next availability of the UE 100 to receive the downlink data packet.

The identification of the relevant PDU session can be used by the core network 104 to identify the proper application server 110. The SMF 116 stores the PDU relationships to application servers and can identify the corresponding application server based on the PDU session identification included in the notification message from the RAN node 130. The core network 104 will use HLcom features to notify the application server 110 that the UE 100 was not available to receive the downlink data packet and, optionally, with an indication of the next possible time when the UE 100 will become available. In certain embodiments, the application server 110 can also request to receive a second notification just before the UE 100 becomes reachable or at the time when the UE 100 has become reachable, in order to retransmit the downlink data to the core network 104 at the right time so that the downlink data packet reaches the UE 100 while the UE 100 is available (e.g. in RCC_Connected state). For example, the application server 110 can retransmit the downlink data packet to the core network 104 at a time determined based on the time until next availability of the UE 100, or based on the second HLcom message informing the application server 110 that the UE 100 is about to become available or has become available. When the core network 104 receives the retransmitted downlink data packet from the application server 110, the core network 104 again transmits the downlink data packet to the RAN node 130. At this point in time, the RAN node 130 determines that the UE 100 is available (e.g. RRC_Connected state or a present paging occasion), and transmits the downlink data packet to the UE 100 directly or once the UE 100 responds to the page.

FIG. 7 illustrates an exemplary process flow representing steps that may be embodied by the RAN node 130. Complimentary operations of the core network 104, the UE 100 and/or the RAN node 130 also will be understood from this disclosure. Although illustrated in a logical progression, the illustrated blocks of FIG. 7 may be carried out in other orders and/or with concurrence between two or more blocks. Therefore, the illustrated flow diagram may be altered (including omitting steps) and/or may be implemented in an object-oriented manner or in a state-oriented manner.

The logical flow may start in block 700 where the RAN node 130 receives, from the core network 104, downlink data intended for the UE 100. At block 702, the RAN node 130 determines that the UE 100 is unavailable while in an inactive state. For example, the RAN node 130 may determine that the UE 100 is currently in an

RRC_Inactive state and in between paging occassions. When the UE 100 is in an inactive state, the UE 100 is registered to the wireless network 102 and is in a connected state as seen from the Core Network (CM_Connected), but is not continuously available to receive data from a RAN node 130. At block 704, the RAN node 130 transmits a notification message to the core network 104. The notification message can include at least one of an identification of the UE 100, an identification of a PDU session associated with the radio link, or an indication of whether the downlink data has been dropped (not buffered or transmitted to the UE 100) or will be delivered to the UE 100 at a later time. In certain embodiments, the message can also include an indication of a time until next user equipment 100 availability to receive the downlink data.

FIG. 8 illustrates an exemplary process flow representing steps that may be embodied by the core network 104, or more specifically, a core network server 300. Complimentary operations of the core network server 300, the UE 100 and/or the RAN node 130 also will be understood from this disclosure. Although illustrated in a logical progression, the illustrated blocks of FIG. 8 may be carried out in other orders and/or with concurrence between two or more blocks. Therefore, the illustrated flow diagram may be altered (including omitting steps) and/or may be implemented in an object-oriented manner or in a state-oriented manner. At block 800, one or more core network servers 300 receives a notification message from the RAN node 130. The notification message can include at least one of an identification of the UE, an identification of a PDU session associated with a radio link between the RAN node and the UE, or an indication of whether the downlink data has been dropped or will be delivered to the UE. In certain embodiments, the message can also include an indication of a time until next user equipment (100) availability to receive the downlink data. At block 802, the one or more core network servers 300 transmit a HLcom message to the application server 110. The HLcom message is generated by the core network server 300 based on information included in the notification message received from the RAN node 130. The HLcom message is communicated to the application server 110 via the NEF 118.

Conclusion

Although certain embodiments have been shown and described, it is understood that equivalents and modifications falling within the scope of the appended claims will occur to others who are skilled in the art upon the reading and understanding of this specification.

Claims

CLAIMS What is claimed is:

1. A radio access network (RAN) node (130) configured to operate in a radio access network (106) of a wireless communication network (102), comprising:

a wireless interface (202) to establish a radio link between a user equipment (100) and the radio access network (106);

an interface (204) to a core network (104) of the wireless communication network (102); and

a control circuit (200) configured to:

receive, from the core network (104), downlink data intended for the user equipment (100);

determine that the user equipment (100) is unavailable while in an inactive state; and

transmit a message to the core network (104), wherein the message includes at least one of an identification of the user equipment (100), an identification of a Protocol Data Unit (PDU) session associated with the radio link, or an indication of whether the downlink data has been dropped or will be delivered to the user equipment (100).

2. The RAN node of claim 1, wherein the control circuit (200) is further configured to determine a time until next user equipment (100) availability to receive the downlink data.

3. The RAN node of claim 2, wherein the message to the core network (104) further includes the time until next user equipment (100) availability to receive the downlink data.

4. The RAN node of any of claims 1-3, wherein the control circuit (200) is further configured to:

determine whether extended buffering is available; and store the downlink data in a buffer in response to determining that extended buffering is available.

5. The RAN node of claim 4, wherein the control circuit (200) is further configured to transmit the downlink data from the buffer to the user equipment (100) upon determining that the user equipment (100) is available to receive the downlink data.

6. The RAN node of any of claims 1-3, wherein the control circuit (200) is further configured to:

determine whether extended buffering is available; and

drop the downlink data in response to determining that extended buffering is not available.

7. A method of enabling high latency communication features by a radio access network (RAN) node (130) that operates in a wireless communications network (102), comprising:

establishing a radio link between a user equipment (100) and the RAN node (130); receiving (700), at the RAN node (130) and from a core network (104) of the wireless communication network, downlink data intended for the user equipment (100); determining (702) that the user equipment (100) is unavailable while in an inactive state; and

transmitting (704) a message to the core network (104), wherein the message includes at least one of an identification of the user equipment (100), an identification of a Protocol Data Unit (PDU) session associated with the radio link, or an indication of whether the downlink data has been dropped or will be delivered to the user equipment (100).

8. The method of claim 7, further comprising:

determining a time until next user equipment (100) availability to receive the downlink data.

9. The method of claim 8, wherein the message to the core network (104) further includes the time until next user equipment (100) availability to receive the downlink data.

10. The method of any of claims 7-9, further comprising:

determining whether extended buffering is available; and

storing the downlink data in a buffer in response to determining that extended buffering is available.

11. The method of claim 10, further comprising:

transmitting the downlink data from the buffer to the user equipment (100) upon determining that the user equipment (100) is available to receive the downlink data.

12. The method of any of claims 7-9, further comprising:

determining whether extended buffering is available; and

dropping the downlink data in response to determining that extended buffering is not available.

13 A system comprising one or more core network servers (300) of a wireless communications network (102), the one or more core network servers (300) comprising one or more processors (306) that execute logical operations to:

receive a message from a RAN node (130), wherein the message includes at least one of an identification of a user equipment (100), an identification of a Protocol Data Unit (PDU) session associated with a radio link between the RAN node (130) and the user equipment (100), or an indication of whether downlink data intended for the user equipment (100) has been dropped or will be delivered to the user equipment (100); and transmit a high latency communication (HLcom) message to an application server (110), wherein the HLcom message is generated based on the message from the RAN node (130).

14. The system of claim 13, wherein the HLcom message notifies the application server (110) that the user equipment (100) was not available to receive the downlink data from the RAN node (130), and includes the indication of whether the downlink data has been dropped or will be delivered to the user equipment (100) at a later time.

15. The system of claim 14, wherein the HLcom message further includes an estimated time that the downlink data will be delivered to the user equipment (100).

16. The system of any of claims 13-15, wherein the one or more processors (306) are further configured to transmit a second HLcom message to the application server (110) to notify the application server that the user equipment (100) is about to become available to receive the downlink data or has become available to receive the downlink data.

17. A method of transmitting downlink data intended for a user equipment (100), comprising:

receiving (800) a message from a RAN node (130), wherein the message includes at least one of an identification of the user equipment (100), an identification of a Protocol Data Unit (PDU) session associated with a radio link between the RAN node (130) and the user equipment (100), or an indication of whether downlink data intended for the user equipment (100) has been dropped or will be delivered to the user equipment (100); and transmitting (802) a high latency communication (HLcom) message to an application server (110), wherein the HLcom message is generated based on the message from the RAN node (130).

18. The method of claim 17, wherein the HLcom message notifies the application server (110) that the user equipment (100) was not available to receive the downlink data from the RAN node (130), and includes the indication of whether the downlink data has been dropped or will be delivered to the user equipment (100).

19. The method of claim 18, wherein the HLcom message further includes an estimated time that the downlink data will be delivered to the user equipment (100).

20. The method of any of claims 17-19, further comprising:

transmitting a second HLcom message to the application server (110) to notify the application server (110) that the user equipment (100) is about to become available to receive the downlink data or has become available to receive the downlink data.