WO2020029167A1

WO2020029167A1 - Methods, apparatus and systems for managing a local cache associated with a wireless communication node

Info

Publication number: WO2020029167A1
Application number: PCT/CN2018/099595
Authority: WO
Inventors: Qian Dai; Jianxun Ai; He Huang
Original assignee: Zte Corporation
Priority date: 2018-08-09
Filing date: 2018-08-09
Publication date: 2020-02-13
Also published as: CN112703766B; CN112703766A

Abstract

Methods, apparatus and systems for managing local caches associated with wireless communication nodes are disclosed. In one embodiment, a method performed by a first wireless communication node is disclosed. The method comprises: transmitting first cache related information to a second wireless communication node. The first cache related information comprises information about a first local cache associated with the first wireless communication node. The first local cache is configured for supporting at least one service in the first wireless communication node.

Description

METHODS, APPARATUS AND SYSTEMS FOR MANAGING A LOCAL CACHE ASSOCIATED WITH A WIRELESS COMMUNICATION NODE

TECHNICAL FIELD

The disclosure relates generally to wireless communications and, more particularly, to methods, apparatus and systems for managing local caches associated with wireless communication nodes.

BACKGROUND

The 4th Generation mobile communication technology (4G) Long-Term Evolution (LTE) or LTE-Advance (LTE-A) and the 5th Generation mobile communication technology (5G) face more and more demands. Based on the current development trend, 4G and 5G systems are developing supports on features of enhanced mobile broadband (eMBB) , ultra-reliable low-latency communication (URLLC) , and massive machine-type communication (mMTC) .

In order to support the features of ultra-high reliability and ultra-low latency transmissions, it is desirable to transmit low-delay and high-reliability services with a short transmission time. A cache can store traffic data that are frequently desired or visited by many users to provide low-latency services to the users. While a traditional cache is located at the core network (CN) side of a wireless communication system, local cache is introduced in an evolved packet core (EPC) network structure as a radio access network (RAN) network element used to cache the traffic data having same content but required by a large number of users. Deploying a local cache at RAN level can shorten the latency and reduce CN overhead. The local cache may be connected to or collocated with an associated RAN node.

But not all RAN nodes will be deployed with local caches. In addition, different local caches may support caching content of different applications. As such, the local cache deployment will impact the resource management of RAN nodes, especially in at least one of user equipment (UE) mobility and multi-connection scenarios. While RAN nodes may need the deployment and/or capability information of the local cache to help improving the performance of UE mobility and multi-connection, no existing method can satisfy this need with a local cache management. Thus, existing systems and methods for managing local caches are not entirely satisfactory.

SUMMARY OF THE INVENTION

The exemplary embodiments disclosed herein are directed to solving the issues relating to one or more of the problems presented in the prior art, as well as providing additional features that will become readily apparent by reference to the following detailed description when taken in conjunction with the accompany drawings. In accordance with various embodiments, exemplary systems, methods, devices and computer program products are disclosed herein. It is understood, however, that these embodiments are presented by way of example and not limitation, and it will be apparent to those of ordinary skill in the art who read the present disclosure that various modifications to the disclosed embodiments can be made while remaining within the scope of the present disclosure.

In one embodiment, a method performed by a first wireless communication node is disclosed. The method comprises: transmitting first cache related information to a second wireless communication node. The first cache related information comprises information about a first local cache associated with the first wireless communication node. The first local cache is configured for supporting at least one service in the first wireless communication node.

In another embodiment, a method performed by a first wireless communication node is disclosed. The method comprises: transmitting cache related information to a second wireless communication node. The cache related information comprises information about a local cache associated with the second wireless communication node. The local cache is configured for supporting at least one service in the second wireless communication node.

In yet another embodiment, a method performed by a wireless communication node is disclosed. The method comprises: receiving cache related information from a wireless communication device. The cache related information comprises information about a local cache associated with the wireless communication node. The local cache is configured for supporting at least one service in the wireless communication node.

In a different embodiment, a wireless communication node configured to carry out a disclosed method in some embodiment is disclosed.

In yet another embodiment, a non-transitory computer-readable medium having stored thereon computer-executable instructions for carrying out a disclosed method in some embodiment is disclosed.

BRIEF DESCRIPTION OF THE DRAWINGS

Various exemplary embodiments of the present disclosure are described in detail below with reference to the following Figures. The drawings are provided for purposes of illustration only and merely depict exemplary embodiments of the present disclosure to facilitate the reader's understanding of the present disclosure. Therefore, the drawings should not be considered limiting of the breadth, scope, or applicability of the present disclosure. It should be noted that for clarity and ease of illustration these drawings are not necessarily drawn to scale.

FIG. 1 illustrates an exemplary 5G radio access network (RAN) in which techniques disclosed herein may be implemented, in accordance with an embodiment of the present disclosure.

FIG. 2 illustrates an exemplary dual-connectivity (DC) system in which techniques disclosed herein may be implemented, in accordance with an embodiment of the present disclosure.

FIG. 3 illustrates a block diagram of a base station (BS) , in accordance with some embodiments of the present disclosure.

FIG. 4 illustrates a flow chart for a method performed by a BS for managing a local cache, in accordance with some embodiments of the present disclosure.

FIG. 5 illustrates a block diagram of a user equipment (UE) , in accordance with some embodiments of the present disclosure.

FIG. 6 illustrates a flow chart for a method performed by a UE to help for managing a local cache, in accordance with some embodiments of the present disclosure.

FIG. 7A illustrates an exemplary deployment of a local cache associated with a BS, in accordance with some embodiments of the present disclosure.

FIG. 7B illustrates another exemplary deployment of a local cache associated with a BS, in accordance with some embodiments of the present disclosure.

FIG. 8 illustrates an exemplary process of exchanging local cache related information between two wireless communication nodes, in accordance with some embodiments of the present disclosure.

FIG. 9 illustrates an exemplary process of exchanging local cache related information among wireless communication nodes for handover, in accordance with some embodiments of the present disclosure.

FIG. 10 illustrates an exemplary process of exchanging local cache related information among wireless communication nodes for secondary node addition, in accordance with some embodiments of the present disclosure.

FIG. 11 illustrates an exemplary process of exchanging local cache related information among wireless communication nodes for handover of a master node having a secondary node, in accordance with some embodiments of the present disclosure.

FIG. 12 illustrates another exemplary process of exchanging local cache related information between wireless communication nodes, in accordance with some embodiments of the present disclosure.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Various exemplary embodiments of the present disclosure are described below with reference to the accompanying figures to enable a person of ordinary skill in the art to make and use the present disclosure. As would be apparent to those of ordinary skill in the art, after reading the present disclosure, various changes or modifications to the examples described herein can be made without departing from the scope of the present disclosure. Thus, the present disclosure is not limited to the exemplary embodiments and applications described and illustrated herein. Additionally, the specific order and/or hierarchy of steps in the methods disclosed herein are merely exemplary approaches. Based upon design preferences, the specific order or hierarchy of steps of the disclosed methods or processes can be re-arranged while remaining within the scope of the present disclosure. Thus, those of ordinary skill in the art will understand that the methods and techniques disclosed herein present various steps or acts in a sample order, and the present disclosure is not limited to the specific order or hierarchy presented unless expressly stated otherwise.

A typical wireless communication network includes one or more base stations (typically known as a “BS” ) that each provides geographical radio coverage, and one or more wireless user equipment devices (typically known as a “UE” ) that can transmit and receive data within the radio coverage. In the wireless communication network, a BS and a UE can communicate with each other via a communication link, e.g., via a downlink radio frame from the BS to the UE or via an uplink radio frame from the UE to the BS.

The present disclosure provides methods, apparatus and systems for managing local caches of wireless communication nodes to ensure a smooth communication of a UE, especially during handover and secondary node addition processes. During a handover process, a data session of a UE is transferred from a source BS to a target BS without disconnecting the session. Because the source BS may have a local cache storing information related to the current data session, to ensure a seamless handover of the UE, the source BS may transmit information related to the local cache associated with, e.g. connected to or collocated with, the source BS to the target BS. The source BS may also receive information related to the local cache associated with the target BS from the target BS. In a process to establish a multi-connection (MC) , e.g. a dual-connectivity (DC) , a secondary node may be added or modified, to serve the same UE with multiple BSs. Because the original BS, called master node, may have a local cache storing information related to the current data session, to ensure a smooth process of secondary node addition or modification, the master node may transmit information related to the local cache associated with the master node to the secondary node. The master node may also receive information related to the local cache associated with the secondary node from the secondary node.

In one embodiment, a RAN node may receive information related to a local cache associated with the RAN node from a core network (CN) node. In another embodiment, a UE may transmit local cache related information to a BS to inform the BS that some data transmission for the UE can be delayed or sent again.

In various embodiments, a BS may be referred to as a network side node and can include, or be implemented as, a next Generation Node B (gNB) , an E-UTRAN Node B (eNB) , a Transmission Reception Point (TRP) , an Access Point (AP) , a donor node (DN) , a relay node, a core network (CN) node, a RAN node, a master node, a secondary node, a distributed unit (DU) , a centralized unit (CU) , etc. A UE in the present disclosure can be referred to as a terminal and can include, or be implemented as, a mobile station (MS) , a station (STA) , etc. A BS and a UE may be described herein as non-limiting examples of “wireless communication nodes; ” and a UE may be described herein as non-limiting examples of “wireless communication devices. ” The BS and UE can practice the methods disclosed herein and may be capable of wireless and/or wired communications, in accordance with various embodiments of the present disclosure.

FIG. 1 illustrates an exemplary 5G radio access network (RAN) 100 in which techniques disclosed herein may be implemented, in accordance with an embodiment of the present disclosure. In FIG. 1, 5GC 110 refers to a core network of the 5G network. The bottom half of FIG. 1 shows a NG-RAN 120, which is referred to as the 5G New Radio Access Technology (RAT) Radio Access Network. The NG-RAN 120 in this example includes a set of one or more gNBs 121, 122 connected to the 5GC 110 through the NG interface. Each gNB is a base station of the 5G RAN. A gNB can support operations of frequency division duplex (FDD) mode, time division duplex (TDD) mode, and/or dual connectivity mode. The set of gNBs can be interconnected through the Xn interface. A gNB may include a gNB-CU and one or more gNB-DU (s) . A gNB-CU and a gNB-DU are connected via F1 interface. NG, Xn and F1 are logical interfaces used in the network 100.

In a New Radio (NR) framework, the forward network interface can be divided by considering transmission capacity, transmission delay, and/or ease of deployment. For example, considering non-ideal forward transmission, the delay-insensitive network function can be placed on a network element such as in a Centralized Unit (CU) ; and a delay-sensitive network function can be placed on another network element, such as a Distributed Unit (DU) .

In FIG. 1, the gNB 121 is not split into CU and DU, whereas the gNB 122 is split into CU and DU. The decision about whether to split the gNB can be based on an operator’s network deployment requirements. An example of the division of CU and DU functions in the protocol stack is that the CU can include Radio Resource Control (RRC) and Packet Data Convergence Protocol (PDCP) functions and the DU can include radio link control (RLC) , media access control (MAC) , and physical (PHY) functions.

FIG. 2 illustrates an exemplary dual-connectivity (DC) system 200 in which techniques disclosed herein may be implemented, in accordance with an embodiment of the present disclosure. The DC architecture 200 may be part of an NR system. As shown in FIG. 2, the DC system 200 may include two (or more) network-side nodes (the first network node 222 and the second network node 224) that provide data connectivity to or from UEs (e.g. the UE 230) . For example, the network nodes may include master and secondary nodes. In another example, the network nodes in a DC system may include an eNB and a gNB or other types of serving network nodes that provide wireless connectivity to UEs.

For a UE 230 having multiple transceivers in the DC system 200, a current serving base station, e.g. the first network node 222 in FIG. 2, of the UE in the NG-RAN may select a suitable wireless channel for the UE 230. For example, the first network node 222 can select a wireless channel having a quality that meets or exceeds a certain threshold. In the DC system 200, a second base station, e.g. the second network node 224 in FIG. 2 can also be added to the UE 230. In the DC system 200, the two base stations can jointly provide radio resources for the UE 230 to perform user plane data transmission. Further, in terms of a wired interface, a first NG control plane (NG-C) can be established between the first network node 222 and the Next Generation Core Network (NG-CN) 210, and at most a NG-U can be established between the second network node 224 and the NG-CN 210 for the UE 230. The first network node 222 and the second network node 224 may be connected by an ideal or non-ideal interface called an Xn interface.

In terms of a wireless interface, the first network node 222 and the second network node 224 may provide the same or different Radio Access Technology (RAT) , and relatively independent scheduling of UEs. In the DC system 200, the first network node 222 connected to the control plane of the core network can be referred to as a master node, and the core network can have only the user plane connection even if there may be no user plane connection with the core network in some cases. The second network node 224 can be referred to as a secondary node. If there are more than two network nodes connected to the UE, all nodes except the master node are called secondary nodes.

Based on the above described dual-connectivity (DC) concept, a multi-RAT dual-connectivity refers to a dual-connectivity architecture where the master node and the secondary node can be access points of different radio access technologies. For example, one access point can be a NR RAN node (e.g., gNB) ; and another access point can be an LTE RAN node (eNB) . In this example, the eNB and the gNB can be connected to a 5G core network at the same time. In another example, a dual-connectivity scenario can include both the master node and the secondary node as NR RAN nodes (e.g., gNB) . Similar to dual-connectivity, MC (Multi-Connection) can be achieved when UE’s capability reaches a requirement, where UE can simultaneously support more than two working radio interfaces. When MC is configured, more than one SN (Secondary Node) can be configured by the MN (Master Node) to serve the UE and provide a bigger throughput than the DC structure.

FIG. 3 illustrates a block diagram of a base station (BS) 300, in accordance with some embodiments of the present disclosure. The BS 300 is an example of a node that can be configured to implement the various methods described herein. As shown in FIG. 3, the BS 300 includes a housing 340 containing a system clock 302, a processor 304, a memory 306, a transceiver 310 comprising a transmitter 312 and receiver 314, a power module 308, a cache related information generator 320, a user equipment service manager 322, a cache related information analyzer 324, and a secondary node manager 326.

In this embodiment, the system clock 302 provides the timing signals to the processor 304 for controlling the timing of all operations of the BS 300. The processor 304 controls the general operation of the BS 300 and can include one or more processing circuits or modules such as a central processing unit (CPU) and/or any combination of general-purpose microprocessors, microcontrollers, digital signal processors (DSPs) , field programmable gate array (FPGAs) , programmable logic devices (PLDs) , controllers, state machines, gated logic, discrete hardware components, dedicated hardware finite state machines, or any other suitable circuits, devices and/or structures that can perform calculations or other manipulations of data.

The memory 306, which can include both read-only memory (ROM) and random access memory (RAM) , can provide instructions and data to the processor 304. A portion of the memory 306 can also include non-volatile random access memory (NVRAM) . The processor 304 typically performs logical and arithmetic operations based on program instructions stored within the memory 306. The instructions (a.k.a., software) stored in the memory 306 can be executed by the processor 304 to perform the methods described herein. The processor 304 and memory 306 together form a processing system that stores and executes software. As used herein, “software” means any type of instructions, whether referred to as software, firmware, middleware, microcode, etc. which can configure a machine or device to perform one or more desired functions or processes. Instructions can include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code) . The instructions, when executed by the one or more processors, cause the processing system to perform the various functions described herein.

The transceiver 310, which includes the transmitter 312 and receiver 314, allows the BS 300 to transmit and receive data to and from a remote device (e.g., another BS or a UE) . An antenna 350 is typically attached to the housing 340 and electrically coupled to the transceiver 310. In various embodiments, the BS 300 includes (not shown) multiple transmitters, multiple receivers, and multiple transceivers. In one embodiment, the antenna 350 is replaced with a multi-antenna array 350 that can form a plurality of beams each of which points in a distinct direction. The transmitter 312 can be configured to wirelessly transmit packets having different packet types or functions, such packets being generated by the processor 304. Similarly, the receiver 314 is configured to receive packets having different packet types or functions, and the processor 304 is configured to process packets of a plurality of different packet types. For example, the processor 304 can be configured to determine the type of packet and to process the packet and/or fields of the packet accordingly.

In a communication system including the BS 300 serving a UE, to ensure a seamless handover or secondary node addition, the BS 300 may provide information related to its local cache. In one embodiment, the cache related information generator 320 may generate and transmit, via the transmitter 312, first cache related information to a second BS. The first cache related information may comprise information about a first local cache associated with the BS 300. The first cache may be configured for supporting at least one service in the BS 300.

In one embodiment, the BS 300 is a source radio access network (RAN) node in a handover process for a given UE, while the second BS is a target RAN node in the handover process. In one embodiment, the BS 300 is a master RAN node in a dual connection or multi-connection for the given UE, while the second BS is a secondary RAN node in the dual connection or multi-connection. In one embodiment, the BS 300 is a distributed unit (DU) , while the second BS is a centralized unit (CU) . In one embodiment, the BS 300 is a CU, while the second BS is a DU. In one embodiment, the BS 300 is a core network (CN) node, while the second BS is a RAN node.

In one embodiment, the first cache related information comprises information about at least one of the following: an identifier of the first local cache; an indication to indicate whether the BS 300 has a local cache support; an indication to indicate whether the first local cache is shared by the BS 300 and the second BS; and a service information list indicating which services are supported by the first local cache. The service information list may be described by one of the following types: high level classifier of each service supported by the first local cache; Quality of Service (QoS) level classifier of each service supported by the first local cache; network slice identifier supported by the first local cache; and application level classifier supported by the first local cache. According to various embodiments, the first cache related information is carried by at least one of an interface setup request message and an interface setup response message, during an inter-node interface setup process between the BS 300 and the second BS.

The user equipment service manager 322 in this example may manage services of a UE, and provide service information of the UE to the cache related information generator 320 for generating the first cache related information. In one embodiment, the first cache related information comprises information about at least one of the following: an indication to indicate whether the first local cache supports a given UE; a first identifier of each service of the given UE supported by the first local cache; a first data volume of service data associated with the given UE in the first local cache; application information corresponding to the given UE; information of first content data required by the given UE and stored in the first local cache; and a last transmission location of the first content data in the first local cache. The first identifier identifies at least one of: a protocol data unit (PDU) session, a Quality of Service (QoS) flow, and a bearer. The first data volume and the application information are indicated with a granularity of at least one of: per UE, per PDU session, per QoS flow, and per bearer. The information of the first content data comprises at least one of feature and address of the first content data and is indicated with a granularity of at least one of: per UE, per PDU session, per QoS flow, and per bearer.

The secondary node manager 326 in this example may manage secondary node (s) when the BS 300 serves as a master node for the secondary node (s) in a DC or MC system. The secondary node manager 326 may provide cache related information of the secondary node (s) to the cache related information generator 320 for generating and transmitting the first cache related information. In one embodiment, the first cache related information comprises information about at least one of the following: an indication to indicate whether the given UE is supported by a second local cache of a secondary node; an indication to indicate whether the secondary node has a local cache support; a second identifier of each service of the given UE supported by the second local cache; a second data volume of service data associated with the given UE in the second local cache; information of second content data information required by the given UE and stored in the second local cache; and a last transmission location of the second content data in the second local cache. The given UE may be configured with a multi-connection by the BS 300 and the secondary node. The second identifier identifies at least one of: a PDU session, a QoS flow, and a bearer. The second data volume is indicated with a granularity of at least one of: per UE, per PDU session, per QoS flow, and per bearer. The information of the second content data comprises at least one of feature and address of the second content data and is indicated with a granularity of at least one of: per UE, per PDU session, per QoS flow, and per bearer.

The cache related information analyzer 324 in this example may receive and analyze second cache related information from the second BS. In one embodiment, the second cache related information comprises information about a second local cache associated with the second BS. In one embodiment, the second cache related information comprises information about at least one of the following: a size of free space of the second local cache; a data forwarding transport address of the second local cache; an available buffer size or an acceptable data amount of data forwarding for a given UE, in case there is no second local cache associated with the second BS or the second local cache cannot support the services of the given UE moved from the BS 300; an indication to indicate whether the second local cache has cached same data as the first local cache for the given UE; and an indication of at least one cause for rejecting a request from the BS 300. The at least one cause may be one of the following: the second BS has no local cache support; the second local cache does not support the service requested by the BS 300; the second local cache has a congestion; the second local cache is overloaded; or the second local cache does not have enough free space. At least one of the above causes is indicated with a granularity of at least one of: per UE, per PDU session, per QoS flow, and per bearer.

In another embodiment, the cache related information generator 320 may generate and transmit, via the transmitter 312, cache related information to a second BS. The cache related information may comprise information about a local cache associated with the second BS. The local cache may be configured for supporting at least one service in the second BS. In one example, the BS 300 is a core network (CN) node, while the second BS is a RAN node. In another example, the BS 300 is a centralized unit (CU) , while the second BS is a distributed unit (DU) . Based on the UE service information provided by the user equipment service manager 322, the cache related information generated by the cache related information generator 320 may be related to a given UE and comprise information about at least one of the following: a first indication to indicate whether a service of the given UE is supported by the local cache, a second indication to indicate whether a service of the given UE is supported by a local cache of a neighbor node of the second BS; an identifier of a neighbor node whose local cache supports at least one service of the given UE, and application information corresponding to the given UE. The first indication, the second indication, and/or the application information is with a granularity of at least one of: per PDU session, per QoS flow, per bearer. In one example, the cache related information is related to neighbor communication nodes of the second BS and comprises information about at least one of the following: a first identifier list to indicate a first set of neighbor communication nodes each of which is associated with a local cache; and a second identifier list to indicate a second set of neighbor communication nodes each of which is associated with a local cache supporting same services as the local cache associated with the second BS.

In a different embodiment, the cache related information analyzer 324 receives and analyzes cache related information from a UE being served by the BS 300. The cache related information comprises information about a local cache associated with the BS 300. The local cache is configured for supporting at least one service in the BS 300. In one example, the cache related information indicates that a downlink data transmission for the UE can be delayed or sent again. In one example, the cache related information comprises information about at least one of the following: an indication to indicate a transmission of pending data in the local cache can be delayed; an indication to indicate a transmission of data buffered in 300 can be delayed; a first identifier of each service to be delayed, wherein the first identifier identifies at least one of: a PDU session, a QoS flow, and a bearer; and a delay time window during which the BS 300 can stop the downlink data transmission to the UE. In another example, the cache related information further comprises information about at least one of the following: an indication to indicate a transmission of pending data in the local cache can be sent again; an indication to indicate a transmission of data buffered in the BS 300 can be sent again; and a second identifier of each service to be sent again, wherein the second identifier identifies at least one of: a PDU session, a QoS flow, and a bearer. In yet another example, the cache related information further comprises information about a third identifier of a PDU session, a QoS flow, or a bearer which needs to be supported by the local cache.

The power module 308 can include a power source such as one or more batteries, and a power regulator, to provide regulated power to each of the above-described modules in FIG. 3. In some embodiments, if the BS 300 is coupled to a dedicated external power source (e.g., a wall electrical outlet) , the power module 308 can include a transformer and a power regulator.

The various modules discussed above are coupled together by a bus system 330. The bus system 330 can include a data bus and, for example, a power bus, a control signal bus, and/or a status signal bus in addition to the data bus. It is understood that the modules of the BS 300 can be operatively coupled to one another using any suitable techniques and mediums.

Although a number of separate modules or components are illustrated in FIG. 3, persons of ordinary skill in the art will understand that one or more of the modules can be combined or commonly implemented. For example, the processor 304 can implement not only the functionality described above with respect to the processor 304, but also implement the functionality described above with respect to the cache related information generator 320. Conversely, each of the modules illustrated in FIG. 3 can be implemented using a plurality of separate components or elements.

FIG. 4 illustrates a flow chart for a method 400 performed by a BS, e.g. the BS 300 in FIG. 3, for managing a local cache, in accordance with some embodiments of the present disclosure. At operation 402, the BS obtains service information related to a user equipment. Optionally at operation 404, the BS obtains cache related information about an associated secondary node. At operation 406, the BS generates cached related information for handover or secondary node addition. At operation 408, the BS transmits the generated cached related information to a receiving node. At operation 410, the BS receives and analyzes cached related information from the receiving node.

FIG. 5 illustrates a block diagram of a user equipment (UE) 500, in accordance with some embodiments of the present disclosure. The UE 500 is an example of a device that can be configured to implement the various methods described herein. As shown in FIG. 5, the UE 500 includes a housing 540 containing a system clock 502, a processor 504, a memory 506, a transceiver 510 comprising a transmitter 512 and a receiver 514, a power module 508, a cache related information generator 520 and a data priority determiner 522.

In this embodiment, the system clock 502, the processor 504, the memory 506, the transceiver 510 and the power module 508 work similarly to the system clock 302, the processor 304, the memory 306, the transceiver 310 and the power module 308 in the BS 300. An antenna 550 or a multi-antenna array 550 is typically attached to the housing 440 and electrically coupled to the transceiver 510.

In a communication system, the UE 500 may be associated with a BS. For example, the UE 500 may be served by the BS that has a local cache connected to or collocated with the BS. In one embodiment, the cache related information generator 520 may generate and transmit, via the transmitter 512, cache related information to the BS. The cache related information may comprise information about a local cache connected to or collocated with the BS. The local cache may be configured for supporting at least one service in the BS. The cache related information may indicate that a downlink data transmission for the UE can be delayed, or sent again.

The data priority determiner 522 in this example may determine priority information of data transmissions related to the UE 500, identify data and services based on the priority information, and provide the identified information to the cache related information generator 520 for generating the cache related information. In one example, the cache related information comprises information about at least one of the following: an indication to indicate a transmission of pending data in the local cache can be delayed; an indication to indicate a transmission of data buffered in the BS can be delayed; a first identifier of each service to be delayed, wherein the first identifier identifies at least one of: a PDU session, a QoS flow, and a bearer; and a delay time window during which the BS can stop the data transmission to the UE. In another example, the cache related information comprises information about at least one of the following: an indication to indicate a transmission of pending data in the local cache can be sent again; an indication to indicate a transmission of data buffered in the BS can be sent again; and a second identifier of each service to be sent again, wherein the second identifier identifies at least one of: a PDU session, a QoS flow, and a bearer. In yet another example, the cache related information comprises information about a third identifier of a PDU session, a QoS flow, or a bearer which needs to be supported by the local cache.

The various modules discussed above are coupled together by a bus system 530. The bus system 530 can include a data bus and, for example, a power bus, a control signal bus, and/or a status signal bus in addition to the data bus. It is understood that the modules of the UE 500 can be operatively coupled to one another using any suitable techniques and mediums.

Although a number of separate modules or components are illustrated in FIG. 5, persons of ordinary skill in the art will understand that one or more of the modules can be combined or commonly implemented. For example, the processor 504 can implement not only the functionality described above with respect to the processor 504, but also implement the functionality described above with respect to the cache related information generator 520. Conversely, each of the modules illustrated in FIG. 5 can be implemented using a plurality of separate components or elements.

FIG. 6 illustrates a flow chart for a method 600 performed by a UE, e.g. the UE 500 in FIG. 5, to help for managing a local cache, in accordance with some embodiments of the present disclosure. At operation 602, the UE determines priority information of data transmissions related to the UE. At operation 604, the UE identifies data and services based on the priority information. At operation 606, the UE generates cached related information based on the identified data and services. At operation 608, the UE transmits the generated cached related information to a node, e.g. a BS, associated with the UE.

Different embodiments of the present disclosure will now be described in detail hereinafter. It is noted that the features of the embodiments and examples in the present disclosure may be combined with each other in any manner without conflict.

A local cache is introduced as an eNB implemented deployment in EPC network structure to cache the traffic data that has the same content but required by many users. Deploying the local cache at RAN level can shorten the latency and reduce CN overhead.

FIG. 7A illustrates an exemplary deployment 710 of a local cache 716 associated with a BS 715, in accordance with some embodiments of the present disclosure. In the exemplary deployment 710, the local cache 716 is directly connected or coupled to the eNB 715, while the eNB 715 communicates with the UE 711 and the serving gateway (SGW) 718.

FIG. 7B illustrates another exemplary deployment 720 of a local cache 726 associated with a BS 725, in accordance with some embodiments of the present disclosure. In the exemplary deployment 720, the local cache 726 is indirectly connected to the eNB 725, while the eNB 725 communicates with the UE 721 and the SGW 728.

In a first case, before a handover (HO) or secondary node (SN) addition is triggered, a source network node needs to have pre-knowledge of the local cache deployment of the neighbor network nodes, which can assist the source network node to choose more proper target node if HO or SN addition is needed for a given UE.

In a first exemplary solution, the first network node provides the connected local cache (i.e. the local cache connected to or collocated with the first network node) assistance information to the second network node. The said local cache assistance information may include at least one of the following.

The local cache assistance information may include the identifier of the local cache. Upon receiving it, the second network node can use it, e.g. to check if the second network node share a same local cache with the first network node. For example, in some deployment one local cache server may be connected with more than one network nodes.

The local cache assistance information may also include an indication of whether the first network node shares the same local cache with the second network node. This indication might be provided if the first network node has received the local cache identifier of the second network node before.

The local cache assistance information may also include an indication of whether or not the first network node has local cache support (e.g. at least one local cache server directly or indirectly connected to or collocated with the first network node) . This indication could be a simple indication like one bit.

The local cache assistance information may also include a service information list to indicate which services are supported by the local cache (if the first network node has local cache support) . In some deployment scenarios, different local caches may support different services, e.g. based on operator’s management. The service information may be constructed by one of the following types: high level classifiers of the supported services, e.g. signaling, data, MT (Mobile Terminated) , emergency, high priority access; QoS level classifiers, e.g. the 3GPP defined QoS classification could be used, such as the QCI defined in TS23.401 or the 5QI defined in TS23.501; network slices identifiers supported by the local cache; application level classifiers, e.g. identifier or name of application, or identifier or name of application (or service) provider, or address (URL or IP address) of application (or service) provider, or application server address (URL or IP address) , or content server address (URL or IP address) , content address (URL or IP address) , or the APN name or APN address, or the URL (or IP) address of the application list supported by the local cache.

The said local cache assistance information could be carried in the inter-node interface setup procedure. For example, it could be carried in the X2 or Xn interface setup request message or in the X2 or Xn interface setup response message, during the inter-node interface, e.g. X2 or Xn interface, setup procedure between the first network node and the second network node. The inter-node interface may be called X2 interface in case between two LTE RAN nodes, or one LTE RAN node and one NR (New RAT) RAN node which both connect to EPC core network; the inter-node interface may be called Xn interface in case between two NR RAN nodes, or one LTE RAN node and one NR (New RAT) RAN node which both connect to NGC core network.

Based on the first exemplary solution, the network nodes will know whether another network node has local cache support and additionally which services can be supported by the local cache, with which the network node can know whether another node is suitable to be a target node in case a UE has met the HO condition or need to construct a dual connection. For example, if the running service of a UE is supported by the local cache of a source network node, it is better to choose a target node which also has local cache and the cache an also support the service of the UE if the UE needs to handover.

In a second case, when handover is triggered for a given UE (e.g. when the UE moves out of the current serving network node) , or SN (secondary node) addition or modification or change procedure is triggered for a given UE (e.g. when the service of the UE requires big throughput and the current serving network node cannot satisfy the QoS, then the serving node decides to set up dual connection to serve the UE) .

In one exemplary solution, the first network node sends local cache assistance information to the second network node if the first network node has local cache and at least one of the services of said UE are supported by the local cache, the said local cache assistance information includes at least one of the following.

The local cache assistance information may include: an indication to indicate whether the said UE is supported by the first network node’s local cache, and optionally include an indication to indicate whether the said UE is supported by a local cache of a SN (Secondary Node) in case the UE is configured with MC (multi-connection) by the first network node and the SN also has a local cache. DC (Dual Connection) is a sub-case of MC (Multi-Connection) .

The local cache assistance information may also include: the identifiers of the said UE’s PDU-sessions or the QoS flows or the bearers, which can be supported by the first network node’s local cache, and optionally include the identifiers of the said UE’s PDU-sessions or the QoS flows or the bearers, which can be supported by the SN’s local cache in case the UE is configured with MC by the first network node and the SN also has a local cache.

The local cache assistance information may also include: the data volume of the UE associated service data stored in the first network node local cache, and optionally include the data volume of the UE associated service data stored in the SN’s local cache in case the UE is configured with MC by the first network node and the SN also has a local cache. The volume could be indicated with the granularity of per UE, or per PDU session or per QoS flow or per bearer.

The local cache assistance information may also include: the application information corresponding to the said UE, which could be indicated with the granularity of per PDU session or per QoS flow or per bearer. The application information refers to the application level classifiers, e.g. identifier or name of application, or identifier or name of application (or service) provider, or address (URL or IP address) of application (or service) provider, or application server address (URL or IP address) , or content server address (URL or IP address) , content address (URL or IP address) , or the APN name or APN address, or the URL (or IP) address of the application. The application information could be carried in the message by either using explicit IE (Information Element) or being included in a container which is transparent to the network node.

In one example, the local cache assistance information is related to neighbor communication nodes of the second network node and comprises information about at least one of the following: a first identifier list to indicate a first set of neighbor communication nodes each of which is associated with a local cache; and a second identifier list to indicate a second set of neighbor communication nodes each of which is associated with a local cache supporting same services as the local cache associated with the second network node.

The local cache assistance information may also include: information of the UE required content data stored in the local cache. This information indicates the cached data in the first node local cache and/or SN’s local cache (in case MC is configured and SN also has a local cache) which is associated with the UE’s PDU-sessions or QoS flows or bearers and acquired by the UE currently or subsequently. This information may include at least one of the following: content data’s feature, e.g. Name, Size, format, date, author, owner, free or not, etc.; content data’s address, e.g. Uniformed address like URL or fixed IP address, or address temporarily assigned by operator or service provider. The said information could be indicated with the granularity of per UE or per PDU-session or per QoS flow or per bearer. The said information can be provided by the first network node local cache and/or SN’s local cache (in case MC is configured and SN also has a local cache) . The said information can be carried in the message by either using explicit IE (Information Element) or being included in a container which is transparent to the network node. Upon this information, the second network node can check whether its local cache has already stored the same content data as the first network node’s local cache.

The local cache assistance information may also include: the last transmission location of the content data which UE is requiring from the local cache. This information is used to ensure UE’s transmission continuity. The location also indicates which part of the content data has been successfully transmitted to the UE and which part has not. Based on this information the second node cache knows from which location to continuously send data to the UE. The transmission location in the content can be acquired from the first node local cache and/or SN’s local cache (in case MC is configured and SN also has a local cache) . It could be carried in the message by either using explicit IE (Information Element) or being included in a container which is transparent to the network node.

The local cache assistance information may also include: an indication to indicate whether the SN has local cache support in case MC is configured by the first network node for the said UE. The first network node needs to inform the second network node this indication, so that the second network node can in advance know how to manage the bearers related with the SN’s local cache of the given UE if the SN can be retained after handover. The said local cache assistance information could be carried in the request message sent by the first network node, e.g. Handover request message, SN addition request message, SN modification request message.

In another exemplary solution, the second network node should send response message which include local cache related information to the first network node. The local cache related information may include at least one of the following.

First, the local cache related information may include: an indication to indicate whether the second network node’s local cache has cached same content or data as the source network node indicated. This indication can be indicated with the granularity of per PDU session or per QoS flow or per bearer.

The local cache related information may also include: the free space size of the local cache of the second network node. The free space size could represent the total free space of the local cache, or the free space size that the local cache can allocate to the said UE, or the free space size that the local cache can allocate for each of the PDU session, or QoS flow, or bearer of the said UE.

If the second network node cannot accept the request from the first network node or only accept part of the request from the first network node (i.e. some of the PDU sessions or QoS flows or bearers are not accepted by the second node) , the second network node indicates the cause in the local cache related information in the response to the first network node. The cause could include at least one of the following: “no local cache support” : to indicated that the second node has no local cache; “cache not support or incompatible or service not supported by local cache” : to indicate that the second node has local cache but the cache does not support the service requested by the first node, which can be indicated with the granularity of per UE or per PDU session, or per QoS flow, or per bearer; “cache congestion or overloaded or not-enough” : to indicate that the second node has local cache but the cache is full or has no enough free space, which can be indicated with the granularity of per UE or per PDU session, or per QoS flow, or per bearer.

The local cache related information may also include: the data forwarding transport address of the second node local cache. This information is used for the first network node to directly forward the data stored in the local cache to the second node local cache without going through the second network node.

The local cache related information may also include an available PDCP buffer size or an acceptable data amount of data forwarding for the given UE, in case there is no local cache connected or collocated with the second node, or the second local cache of the second network node cannot support the services of the given UE moved from the first network node to the second network node.

The said response message which includes local cache related information could be carried in the request response message sent by the second network node, e.g. Handover request acknowledge message, Handover preparation failure message, SN addition request acknowledge or reject message, SN modification request acknowledge or reject message.

According to various embodiments, the first and second network nodes could be: (a) source RAN node and target RAN node in case of handover; (b) Master RAN node and Secondary RAN node in case of Dual Connection; (c) DU and CU; or (d) CU and DU, respectively.

In a third case, for a given UE connected to the network node, the network node should be aware that which services established for the given UE is supported by the local cache. In an exemplary solution, the first network node gets the local cache assistance information of a given UE from the secondary network node. The local cache assistance information may include at least one of the following.

The local cache assistance information may include: whether the running or to-be-setup PDU-sessions or QoS flows or bearers of the given UE can be supported by the local cache connected with the serving RAN node, it could be indicated with the granularity of per PDU-session or QoS flow or bearer.

The local cache assistance information may include: whether the running or to-be-setup PDU-sessions or QoS flows or bearers of the given UE can be supported by the local cache connected with the neighbor RAN nodes. If a PDU-session or QoS flow or bearer of the given UE can be supported by the local cache of neighbor RAN nodes, the said local cache assistance information further includes the identifier of the corresponding neighbor RAN nodes. If a PDU-session or QoS flow or bearer of the given UE can be supported by the local cache of neighbor RAN nodes, the said local cache assistance information further includes the application level classifiers associated with the said PDU-session or QoS flow or bearer.

The local cache assistance information may include: the application information corresponding to the said UE’s PDU sessions or QoS flows or bearers, which could be indicated with the granularity of per PDU session or per QoS flow or per bearer. The application information refers to the application level classifiers, e.g. identifier or name of application, or identifier or name of application (or service) provider, or address (URL or IP address) of application (or service) provider, or application server address (URL or IP address) , or content server address (URL or IP address) , content address (URL or IP address) , or the APN name or APN address, or the URL (or IP) address of the application. The application information could be carried by including it in a container which is transparent to the RAN node.

According to various embodiments, the first network node and the second network nodes could be: (a) the first network node is RAN node, the second network node is CN node; (b) the first network node is DU, the second network node is CU. The CN node might include MME, SGW, PGW for EPC network; and include AMF, SMF, AF, UPF for 5G core network.

The said local cache assistance information of a given UE can be obtained from the CN node during: bearer or PDU session setup or modification procedure; or path switch procedure in case of handover; or UE context setup procedure.

In another case, a UE can provide assistance information to the network node (the serving RAN node) that the downlink data transmission for the UE could be delayed or sent again. This requirement may come from the UE app layer. The said assistance information includes at least one of the following: an indication to indicate the transmission of the pending data in the local cache could be delayed or could be sent again; an indication to indicate the transmission of the data buffered in the network nodes could be delayed or could be sent again. The said assistance information may optionally include the PDU-session-ID or the QoS flow-ID or the DRB-ID of the data indicated to be delayed or sent again. The said assistance information may optionally include an identifier of a PDU session, or a QoS flow, or a bearer that needs to be supported by the local cache. The said assistance information may optionally include the delay time window or length, during which the RAN can stop the downlink data transmission to the said UE. Based on the said assistance information, the RAN node can know for how long to delay the UE’s data transmission and whether the UE can be transferred to RRC inactive state for a power saving purpose.

In a first embodiment, as shown in FIG. 8, assuming an eNB1 810 and an eNB2 820 are both connected to EPC core network. The inter-node interface (X2 interface) setup procedure may be as below. In Step 1, in the X2 setup request message sent by eNB1 to eNB2, if eNB1 has connected to a local cache, eNB1 can add the local cache related information in the message. This could be helpful in case the eNB2 wants to find a target RAN node for UE handover. The local cache related information added in the X2 setup request may simply include an indication of whether the eNB1 has local cache support, e.g. it could be one-bit indication.

Further, eNB1 also can give more detailed information, such as: the identifier of the local cache, or an identifier list if eNB1 connects more than one local cache. Further, eNB1 can give service information list to indicate the services supported by the local cache, which can enable eNB2 or eNB2’s local cache to know the difference of the supported service. The said service information list could be one of the following types: high level classifiers of the supported services, e.g. Signaling, data, MT (Mobile Terminated) , emergency, high priority access; QoS level classifiers, e.g. the 3GPP defined QoS classification could be used; network slices identifiers supported by the local cache; application level classifiers, e.g. identifier or name of application, or identifier or name of application (or service) provider, or address (URL or IP address) of application (or service) provider, or application server address (URL or IP address) , or content server address (URL or IP address) , content address (URL or IP address) , or the APN name or APN address, or the URL (or IP) address of the application list supported by the local cache. To carry the local cache related information, it could be either explicitly added in the message as an IE (Information Element) , or be contained in a container which is transparent to the eNB.

In Step 2, upon receiving the X2 setup request, the eNB2 should send feedback. The local cache related information is added in the X2 setup response if eNB2 also has connected to a local cache. If the eNB2 connected local cache is same with the eNB1, eNB2 may simply add an indication, e.g. one bit, in the response message. Otherwise, eNB2 may include the identifier of the local cache in the response message.

Similarly, eNB2 also can further include more detailed information, e.g. service information list, as in the Step 1, to indicate the services supported by the local cache, in the response message. In one example, the first network node is an eNB, and the second network node is a gNB (NR-RAN node) , and both of them connect to EPC. In this case either eNB or gNB can initiate an EN-DC X2 interface setup procedure, which also includes two steps: EN-DC X2 interface setup request and EN-DC X2 interface setup response. In this example the above embodiment is also suitable to be used.

In another example, the first network node is a gNB and the second network node is a eNB or gNB, and both of them connect to NGC. In this case either eNB or gNB can initiate an Xn interface setup procedure, which also includes two steps: Xn interface setup request and Xn interface setup response. In this example the above embodiment is also suitable to be used.

In a second embodiment, as shown in FIG. 9, assuming a UE 910 sends measurement report to the serving eNB (e.g. eNB1 920) which connects to EPC, and the eNB1 920 finds that the UE 910 has met the HO condition. The eNB1 920 chooses a target RAN node (e.g. eNB2 930) based on UE’s measurement report and initiates HO procedure. In some cases, the source and the target RAN nodes can also be a gNB connected to EPC. For an EPC network, the CN 940 could represent MME and SGW; for a 5GC, the CN 940 could represent AMF and SMF.

In Step 1, the UE 910 performs the measurement and send result to the service eNB, i.e. eNB1 920. In Step 2, the UE 910 decides to handover the UE to the eNB1 920 based on the measurement report received from the UE 910. The eNB1 910 sends HO request message to the target eNB (the eNB1 920) . The HO request message includes the local cache assist information.

To assist the target eNB making proper decision whether can accept the UE and further which services of the UE can be accepted and which cannot, the local cache assist information may include at least one of the following.

The local cache assist information may include: an indication to indicate whether the UE is supported by the source eNB1’s local cache, e.g. one bit indication could be used to represent “has” or “has not” . The local cache assist information may include: the identifiers of the UE’s PDU-sessions or the QoS flows or the bearers which are supported by the source eNB1’s local cache. The local cache assist information may include: the data volume of the UE associated service data stored in the source eNB1’s local cache, the volume could be indicated with the granularity of per UE, or per PDU session or per QoS flow or per bearer. The local cache assist information may include: the application information corresponding to the UE, which could be indicated with the granularity of per PDU session or per QoS flow or per bearer. The application information refers to the application level classifiers, e.g. identifier or name of application, or identifier or name of application (or service) provider, or address (URL or IP address) of application (or service) provider, or application server address (URL or IP address) , or content server address (URL or IP address) , content address (URL or IP address) , or the APN name or APN address, or the URL (or IP) address of the application. The application information could be carried in the message by either using explicit IE (Information Element) or being included in a container which is transparent to the RAN node.

In one example, the local cache assistance information is related to neighbor communication nodes of the target eNB2 and comprises information about at least one of the following: a first identifier list to indicate a first set of neighbor communication nodes each of which is associated with a local cache; and a second identifier list to indicate a second set of neighbor communication nodes each of which is associated with a local cache supporting same services as the local cache associated with the target eNB2.

The local cache assist information may include: information of the UE required content data stored in the local cache. This information indicates the cached data in the source node local cache which is associated with the UE’s PDU-sessions or QoS flows or bearers and acquired by the UE currently or subsequently. The said information may include at least one of the following: content data’s feature, e.g. Name, Size, format, date, author, owner, free or not, etc.; content data’s address, e.g. Uniformed address like URL or fixed IP address, or address temporarily assigned by operator or service provider. The said information could be indicated with the granularity of per UE or per PDU-session or per QoS flow or per bearer. The said information can be provided by the source eNB1 local cache. The said information can be carried in the message by either using explicit IE (Information Element) or being included in a container which is transparent to the eNB. Upon this information, the target eNB2 can check whether its local cache has already stored the same content data with the source eNB1’s local cache.

The local cache assist information may include: the last transmission location of the content data which UE is requiring from the local cache. This information is used to ensure UE’s transmission continuity. The location also indicates which part of the content data has been successfully transmitted to the UE and which part has not, based on this information the target eNB2’s local cache knows from which location to continuously send data to the UE after UE handover from eNB1 to eNB2. The transmission location in the content data can be acquired from the source eNB1’s local cache. It could be carried in the message by either using explicit IE (Information Element) or being included in a container which is transparent to the eNB.

In case of an inter-MN HO with or without SN change, the local cache assist information may include: an indication to indicate whether the SN connected to the source eNB1 has local cache support. This indication is sent by the source eNB1 in case the given UE meets the handover condition and the source eNB1 already configured dual connection (i.e. UE simultaneously connects to 2 RAN nodes, e.g. eNB1 and a secondary eNB or gNB) for the given UE. Then the source eNB1 needs to inform the target eNB2 this indication, so that the target eNB2 can in advance know how to manage the bearers related with the SN’s local cache of the given UE if the SN can be retained after handover.

In Step 3, based on the said local cache related information sent from source eNB1 920, the eNB2 930 can decide whether can accept the UE’s handover. If yes, it is further decided to accept all the UE’s services or only part of them, where eNB2 can send response message to the eNB1 by including the decision in it, which includes the local cache related responses. If the eNB2 accepts the eNB2’s HO request, then eNB2 also can include radio configuration assigned for the said UE which is for the UE accessing to the eNB2. The said local cache related responses include at least one of the following: one indication to indicate whether the eNB2’s local cache has cached same content or data as the source network node indicated; the free space size of the local cache of the eNB2, the free space size could represent the total free space of the local cache, or could be the free space size that the local cache can allocate to the said UE, or the free space size that the local cache can allocate for each of the PDU session, or QoS flow, or bearer of the said UE; if the second network node cannot accept the request from the first network node or only accept part of the request from the first network node (i.e. some of the PDU sessions or QoS flows or bearers are not accepted by the second node) , the second network node indicates the cause in the response to the first network node, the cause could include at least one of the following: “no local cache support” : to indicate that the second eNB2 has no local cache, “cache not support or incompatible or service not supported by local cache” : to indicate that the eNB2 has local cache but the cache does not support the service requested by the eNB1, this cause can be indicated with the granularity of per UE or per PDU session, or per QoS flow, or per bearer, “cache congestion or overloaded or not-enough” : to indicate that the eNB2 has local cache but the cache is full or has no enough free space, this cause can be indicated with the granularity of per UE or per PDU session, or per QoS flow, or per bearer; the data forwarding transport address of the eNB2’s local cache: this information is used for the eNB1 to directly forward the data stored in the local cache to the eNB2’s local cache without going through the eNB2; and an available PDCP buffer size or an acceptable data amount of data forwarding for the given UE, in case there is no local cache connected or collocated with the second node, or the second local cache of the second network node cannot support the services of the given UE moved from the first network node to the second network node.

In Step 4, if the response from eNB2 indicates that the handover of the said UE can be accepted, eNB1 sends RRC reconfiguration message to the said UE which including the radio configuration sent from eNB2. In Step 5, UE gains access to eNB2 to achieve uplink synchronization with eNB2 and setup RRC connection with eNB2. In Step 6, if the RRC connection setup is successful, UE sends RRC reconfiguration complete to the eNB2.

In Step 7, eNB1 forwards the UE’s pending data during Step 5 and Step 6 (i.e. the DL data not been transmitted to UE successfully, and the UL data which are received but not delivered to the core network) to the eNB2, which not only include the data pended in the eNB1’s buffer, but also include the data pended in the eNB1’s local cache. The eNB1 can forward only the pended data in local cache which correspond to the bearers accepted by the eNB2’s local cache, and may not forward the cached pended data for those bearers accepted by the eNB2 but not accepted by the eNB2’s local cache.

In Step 8, eNB2 sends path switch request message to the CN 940 (e.g. MME) to switch the user plane tunnel of the said UE from eNB1 to eNB2. In Step 9, the MME 940 sends path switch response to the eNB2, in which the MME 940 may optionally include the local cache related information, which include at least one of the following: whether the running or to-be-setup PDU-sessions or QoS flows or bearers of the said UE can be supported by the local cache connected with the eNB2; whether the running or to-be-setup PDU-sessions or QoS flows or bearers of the said UE can be supported by the local cache connected with the neighbor RAN nodes of eNB2: if a PDU-session or QoS flow or bearer of the given UE can be supported by the local cache of neighbor RAN nodes, the said local cache assistance information further includes the identifier of the corresponding neighbor RAN nodes, if a PDU-session or QoS flow or bearer of the given UE can be supported by the local cache of neighbor RAN nodes, the said local cache assistance information further includes the application level classifiers associated with the said PDU-session or QoS flow or bearer; the application information corresponding to the said UE’s PDU sessions or QoS flows or bearers, which could be indicated with the granularity of per PDU session or per QoS flow or per bearer. The application information refers to the application level classifiers, e.g. identifier or name of application, or identifier or name of application (or service) provider, or address (URL or IP address) of application (or service) provider, or application server address (URL or IP address) , or content server address (URL or IP address) , content address (URL or IP address) , or the APN name or APN address, or the URL (or IP) address of the application. The application information could be carried by either using explicit IE (Information Element) or being included in a container which is transparent to the eNB2.

In a third embodiment, as shown in FIG. 10, assuming a UE 1010 connected to a serving eNB1 1020 which connects to EPC, and the eNB1 1020 cannot afford the UE1’s QoS due to radio interface congestion. Then the eNB1 chooses a target RAN node 1030 to offload all or part of the UE1’s services to the target node. The eNB1 initiates SN addition procedure. In FIG. 10, the eNB1 is called MN 1020, and the target RAN node is called SN 1030. For an EPC network, the CN 1040 could represent MME and SGW, for a 5G core network, the CN 1040 could represent AMF and SMF. In this embodiment, assuming MN has a local cache and UE’s service can be supported by this local cache, and SN has a local cache as well.

In Step 1, UE is currently connecting with MN. When MN finds that the QoS of the UE cannot be satisfied due to, e.g. radio resource congestion, MN tries to add an SN to offload all or part of the UE’s services. MN sends an SN addition request message to the SN, which includes the ERAB (in case the network is EPC) or PDU session or QoS flow (in case the network is 5GC) information which MN tries to offload to the SN. Optionally, MN can include the local cache assist information if MN has a local cache and at least one of the said UE’s services is supported by the local cache. The said local cache assist information may include at least one of the following: (a) an indication to indicate whether the UE is supported by the MN’s local cache, e.g. one bit indication could be used to represent “has” or “has not” ; (b) the identifiers of the UE’s PDU-sessions or the QoS flows or the bearers which are supported by the MN’s local cache; (c) the data volume of the UE associated service data stored in the MN’s local cache, the volume could be indicated with the granularity of per UE, or per PDU session or per QoS flow or per bearer; (d) the application information corresponding to the UE, which could be indicated with the granularity of per PDU session or per QoS flow or per bearer. The application information refers to the application level classifiers, e.g. identifier or name of application, or identifier or name of application (or service) provider, or address (URL or IP address) of application (or service) provider, or application server address (URL or IP address) , or content server address (URL or IP address) , content address (URL or IP address) , or the APN name or APN address, or the URL (or IP) address of the application. The application information could be carried in the message by either using explicit IE (Information Element) or being included in a container which is transparent to the RAN node.

The said local cache assist information may also include information of the UE required content data stored in the local cache. This information indicates the cached data in the MN’s local cache which is associated with the UE’s PDU-sessions or QoS flows or bearers and acquired by the UE currently or subsequently. The said information may include at least one of the following: content data’s feature, e.g. Name, Size, format, date, author, owner, free or charge, etc.; content data’s address, e.g. uniformed address like URL or fixed IP address, or address temporarily assigned by operator or service provider. The said information could be indicated with the granularity of per UE or per PDU-session or per QoS flow or per bearer. The said information can be provided by the MN’s local cache. The said information can be carried in the message by either using explicit IE (Information Element) or being included in a container which is transparent to the MN. Upon this information, the SN can check whether its local cache has already stored the same content data with the MN’s local cache.

The said local cache assist information may also include the last transmission location of the content data which UE is requiring from the local cache. This information is used to ensure UE’s transmission continuity. The location also indicates which part of the content data has been successfully transmitted to the UE and which part has not. Based on this information the SN’s local cache knows from which location to continuously send data to the UE after UE’s services are offloaded from MN to SN, the transmission location in the content data can be acquired from the source MN’s local cache, which could be carried in the message by either using explicit IE (Information Element) or being included in a container which is transparent to the MN.

In Step2, SN decides whether the MN requested services of the given UE can be accepted, and whether the services can be supported by SN’s local cache. Based on SN’s decision, SN can send the response message to MN which includes the accepted services and corresponding radio configuration for the said UE to access to the SN, and optionally includes the local cache related information if some of the accepted services can be supported by the SN’s local cache. The said local cache related information includes at least one of the following: (a) an indication to indicate whether the SN’s local cache has cached same content or data as the MN indicated, which can be indicated with the granularity of per PDU session or per QoS flow or per bearer; (b) the free space size of the local cache of the SN, the free space size could represent the total free space of the local cache, or could be the free space size that the local cache can allocate to the said UE, or the free space size that the local cache can allocate for each of the PDU session, or QoS flow, or bearer of the said UE; (c) if the SN cannot accept the request from the MN or only accept part of the request from the MN (i.e. some of the PDU sessions or QoS flows or bearers are not accepted by the second node) , the SN indicates the cause in the response to the MN, the cause could include at least one of the following: “no local cache support” : to indicate that the SN has no local cache, “cache not support or incompatible or service not supported by local cache” : to indicate that the SN has local cache but the cache does not support the service requested by the MN, which can be indicated with the granularity of per UE or per PDU session, or per QoS flow, or per bearer, “cache congestion or overloaded or not-enough” : to indicate that the SN has local cache but the cache is full or has no enough free space, which can be indicated with the granularity of per UE or per PDU session, or per QoS flow, or per bearer; (d) the data forwarding transport address of the SN’s local cache, which is used for the MN to directly forward the data stored in the local cache to the SN’s local cache without going through the SN; (e) an available PDCP buffer size or an acceptable data amount of data forwarding for the given UE, in case there is no local cache connected or collocated with the second node, or the second local cache of the second network node cannot support the services of the given UE moved from the first network node to the second network node.

In Step 3, if the response from SN indicates that the SN addition for the said UE can be accepted, MN sends RRC reconfiguration message to the said UE which including the radio configuration sent from SN. In Step 4, if the RRC connection setup is successful, UE sends RRC reconfiguration complete to the MN. In Step 5, MN sends SN reconfiguration complete to SN to indicate that UE accepts the radio configuration configured by SN. In Step 6, UE gains access to SN, to achieve uplink synchronization with SN. In Step 7, MN forwards the UE’s pending data of the offloaded services to the SN, which not only includes the data pended in the MN’s buffer, but also includes the data pended in the MN’s local cache. In one embodiment, the MN can only forward the pended data in local cache which correspond to the bearers (or PDU sessions or QoS flows) accepted by the SN’s local cache, and should not forward the cached pended data for those bearers accepted by the SN but not accepted by the SN’s local cache.

In Step 8, MN sends ERAB or PDU session modification indication message to the CN to inform the CN about the SN addition and the UE’s services offloading, so that CN can adjust the UP downlink transport address of the indicated ERABs or PDU sessions to the SN. In Step 9, CN sends ERAB or PDU session modification confirmation message to the MN, in which the CN may optionally include the local cache related information, which includes at least one of the following: (a) whether the running or to-be-setup PDU-sessions or QoS flows or bearers of the said UE can be supported by the local cache of MN and/or SN; (b) whether the running or to-be-setup PDU-sessions or QoS flows or bearers of the said UE can be supported by the local cache connected with the neighbor RAN nodes of MN and/or SN. If a PDU-session or QoS flow or bearer of the given UE can be supported by the local cache of neighbor RAN nodes, the said local cache assistance information further includes the identifier of the corresponding neighbor RAN nodes. If a PDU-session or QoS flow or bearer of the given UE can be supported by the local cache of neighbor RAN nodes, the said local cache assistance information further includes the application level classifiers associated with the said PDU-session or QoS flow or bearer. The local cache related information may also include the application information corresponding to the said UE’s PDU sessions or QoS flows or bearers, which could be indicated with the granularity of per PDU session or per QoS flow or per bearer. The application information refers to the application level classifiers, e.g. identifier or name of application, or identifier or name of application (or service) provider, or address (URL or IP address) of application (or service) provider, or application server address (URL or IP address) , or content server address (URL or IP address) , content address (URL or IP address) , or the APN name or APN address, or the URL (or IP) address of the application. The application information could be carried by either using explicit IE (Information Element) or being included in a container which is transparent to the MN.

In a fourth embodiment, referring to an inter MN handover without SN change, as shown in FIG. 11, assuming S-MN (source MN) 1120, S-SN (source SN) 1130 and T-MN (Target MN) 1140 all has local caches. Assuming UE 1110 is configured with DC by the source MN, i.e. UE 1110 is simultaneously connected to S-MN 1120 and S-SN 1130.

In Step 1, S-MN decides to handover the UE to T-MN based on, e.g. the measurement report received from the UE. The S-MN sends HO request message to the T-MN, which includes the local cache assist information. To assist the T-MN to make proper decision whether it can accept the UE and which services of the UE can be accepted and which cannot, the local cache assist information may include at least one of the following: (a) an indication to indicate whether the UE is supported by the S-MN’s local cache, and an optional indication to indicate whether the said UE is supported by the S-SN’s local cache, e.g. one bit indication could be used to represent “has” or “has not” ; (b) the identifiers of the UE’s PDU-sessions or the QoS flows or the bearers which are supported by the source S-MN’s local cache and/or S-SN’s local cache; (c) the data volume of the UE associated service data stored in the S-MN’s local cache and/or S-SN’s local cache, the volume could be indicated with the granularity of per UE, or per PDU session or per QoS flow or per bearer; (d) the application information corresponding to the UE, which could be indicated with the granularity of per PDU session or per QoS flow or per bearer. The application information refers to the application level classifiers, e.g. identifier or name of application, or identifier or name of application (or service) provider, or address (URL or IP address) of application (or service) provider, or application server address (URL or IP address) , or content server address (URL or IP address) , content address (URL or IP address) , or the APN name or APN address, or the URL (or IP) address of the application. The application information could be carried in the message by either using explicit IE (Information Element) or being included in a container which is transparent to the RAN node.

The local cache assist information may also include information of the UE required content data stored in the local cache. This information indicates the cached data in the S-MN’s local cache and/or the S-SN’s local cache, which are associated with the UE’s PDU-sessions or QoS flows or bearers and acquired by the UE currently or subsequently. The said information may include at least one of the following: content data’s feature, e.g. Name, Size, format, date, author, owner, free or charge, etc.; content data’s address, e.g. uniformed address like URL or fixed IP address, or address temporarily assigned by operator or service provider. The said information could be indicated with the granularity of per UE or per PDU-session or per QoS flow or per bearer. The said information can be provided by the S-MN’s local cache and/or the S-SN’s local cache. The said information can be carried in the message by either using explicit IE (Information Element) or being included in a container which is transparent to the S-MN. Upon this information, the T-MN can check whether its local cache has already stored the same content data with the S-MN’s local cache.

The local cache assist information may also include the last transmission location of the content data which UE is requiring from the local cache. This information is used to ensure UE’s transmission continuity. The location also indicates which part of the content data has been successfully transmitted to the UE and which part has not, based on this information the T-MN’s local cache knows from which location to continuously send data to the UE after UE handover. The transmission location in the content data can be acquired from the S-MN’s local cache and/or the S-SN’s local cache, which could be carried in the message by either using explicit IE (Information Element) or being included in a container which is transparent to the S-MN. The local cache assist information may also include an indication to indicate whether the S-SN has local cache support.

In Step 2, T-MN can add the S-SN to try whether it can retain the S-SN for the UE. In the SN addition request message the T-MN can decide whether to include the local cache related information. If T-MN decides to keep all the UE’s services in the S-SN with no change, MN does not need to include the local cache related information. If T-MN decides to offload some of the UE’s services supported by the S-SN’s local cache back to the T-MN after the HO, MN may need to include the local cache related information, which may include at least one of the following: (a) the identifiers of the UE’s PDU sessions or QoS flows or bearers which T-MN decide to move back to T-MN; (b) an indication to indicate whether the T-MN’s local cache has cached same content or data as the S-MN indicated, which can be indicated with the granularity of per PDU session or per QoS flow or per bearer; (c) the free space size of the local cache of the T-MN, the free space size could represent the total free space of the local cache, or could be the free space size that the local cache can allocate to the said UE, or the free space size that the local cache can allocate for each of the PDU session, or QoS flow, or bearer of the said UE; (d) the data forwarding transport address of the T-MN’s local cache, this information is used for the S-SN to directly forward the data stored in the local cache to the T-MN’s local cache without going through the S-SN or S-MN; (e) an available PDCP buffer size or an acceptable data amount of data forwarding for the given UE, in case there is no local cache connected or collocated with the T-MN, or the second local cache of the T-MN cannot support the services of the given UE moved from the S-MN to the T-MN.

The local cache related information may optionally include the identifiers of the UE’s PDU sessions or QoS flows or bearers which T-MN decides to move to S-SN. The local cache related information may include the data volume of the UE associated service data stored in the S-MN’s local cache if T-MN decides to move some more services to S-SN. The local cache related information may include the application information corresponding to the UE, if T-MN decides to move some more services to S-SN. The local cache related information may include information of the UE required content data stored in the S-MN’s local cache if T-MN decides to move some more services to S-SN.

In Step 3, if S-SN accepts the SN addition, it sends the response to T-MN which includes the radio configuration and optionally includes the local cache related information. If the T-MN not only decides to move back some of the UE’s service, but also decides to offload some other UE’s service to S-SN, S-SN may need to include the local cache related information, which may include at least one of the following: (a) an indication to indicate whether the S-SN’s local cache has cached same content or data as the S-MN indicated, this indication can be indicated with the granularity of per PDU session or per QoS flow or per bearer; (b) the free space size of the local cache of the S-SN; (c) the data forwarding transport address of the S-SN’s local cache.

In Step 4, upon receiving the SN add request Ack from the S-SN, T-MN can send HO request Ack to the S-MN to accept the HO request, which may optionally include the local cache related information, which may include at least one of the following: (a) an indication to indicate whether the T-MN’s local cache has cached same content or data as the S-MN indicated; this indication can be indicated with the granularity of per PDU session or per QoS flow or per bearer; (b) the free space size of the local cache of the T-MN; (c) the failure cause if the T-MN cannot accept some of the PDU sessions or QoS flows or bearers, e.g. one of the following: “no local cache support” , “cache not support or incompatible or service not supported by local cache” , “cache congestion or overloaded or not-enough” ; and (d) the data forwarding transport address of the T-MN’s local cache.

Steps

5 and 6 are performed to release the connection between S-MN and S-SN. Steps 7 to 12 are to finish the UE accessing to the T-MN.

In a fifth embodiment, referring to the gNB composed by CU and DU, assuming the local cache is directly connected with DU. In one example, for a given UE connected to the gNB, the following steps are performed. In Step 1, if the DU detects a AILC bit in a PDCP PDU which indicates the PDCP PDU should be delivered to the local cache instead of CU, DU knows the PDCP PDU containing the AILC corresponds to which bearer or QoS flow or PDU session, DU can then inform the identifier of the said bearer or QoS flow or PDU session to the CU to tell which bearer or QoS flow or PDU session is supported by the local cache. In Step 2, depending on the information that which bearer or QoS flow or PDU session is supported by the local cache, CU can use this information in HO algorithm and SN choosing algorithm etc., to find a better target RAN node, e.g. a node that also has local cache and can support the same services.

In another example, for a given UE connected to the gNB, the following steps are performed. In Step 1, DU can get local cache related information by implementation from the connected local cache. The said local cache related information may include at least one of the following: (a) whether or not the DU has local cache support, which could be a simple indication like one bit; (b) the identifier of the local cache if has local cache support; (c) services information list to indicate which services are supported by the local cache. The services information may be constructed by one of the following types: identifiers of the PDU sessions or QoS flows or bearers of the given UE; high level classifiers of the supported services, e.g. Signaling, data, MT (Mobile Terminated) , emergency, high priority access; QoS level classifiers, e.g. the 3GPP defined QoS classification could be used, such as the QCI defined in TS23.401 or the 5QI defined in TS23.501; network slices identifiers supported by the local cache; application level classifiers, e.g. identifier or name of application, or identifier or name of application (or service) provider, or address (URL or IP address) of application (or service) provider, or application server address (URL or IP address) , or content server address (URL or IP address) , content address (URL or IP address) , or the APN name or APN address, or the URL (or IP) address of the application list supported by the local cache.

The said local cache related information may include: the data volume of the UE associated service data stored in the local cache. The volume could be indicated with the granularity of per UE, or per PDU session or per QoS flow or per bearer. The said local cache related information may include: information of the UE required content data stored in the local cache, which may include: content data’s feature, e.g. Name, Size, format, date, author, owner, free or charge, etc.; content data’s address, e.g. uniformed address like URL or fixed IP address, or address temporarily assigned by operator or service provider. The said local cache related information may include at least one of: the free space size of the local cache; and the data forwarding transport address of the local cache.

In Step 2, depending on the information, CU can use this information in HO algorithm and SN choosing algorithm etc., to find a better target RAN node, e.g. a node that also has local cache and can support the same services. In the above examples of the fifth embodiment, the message sent by DU to CU could be: Notify message, UE context setup response message, UE context modification response message, UE context modification required message, etc.

In a sixth embodiment, as shown in FIG. 12, a standalone gNB 1220 connected to 5GC is given for a UE 1210 connected to the said gNB 1220. The gNB 1220 can get the local cache related information from the CN 1230 in case the gNB 1220 is deployed with a local cache.

As shown in FIG. 12, in Step 1, when the UE requests a service, it sends a NAS message to the CN which is transparently relayed by the gNB. In Step 2, if CN allows the service requested by the UE, CN sends UE initial context setup request message to the gNB to build the UE context, in which the CN can optionally include the local cache related information if CN knows the gNB is deployed with a local cache. The local cache related information may include at least one of the following: (a) the identifier of the local cache; (b) services information list to indicate which services are supported by the local cache. The services information may be constructed by one of the following types: identifiers of the PDU sessions or QoS flows or bearer of the given UE; high level classifiers of the supported services, e.g. signaling, data, MT (Mobile Terminated) , emergency, high priority access; QoS level classifiers, e.g. the 3GPP defined QoS classification could be used, such as the QCI defined in TS23.401 or the 5QI defined in TS23.501; network slices identifiers supported by the local cache; application level classifiers, e.g. identifier or name of application, or identifier or name of application (or service) provider, or address (URL or IP address) of application (or service) provider, or application server address (URL or IP address) , or content server address (URL or IP address) , content address (URL or IP address) , or the APN name or APN address, or the URL (or IP) address of the application list supported by the local cache.

The local cache related information may include which PDU-sessions or QoS flows or bearers of the given UE can be supported by the local cache of the neighbor RAN nodes. If a PDU-session or QoS flow or bearer of the given UE can be supported by the local cache of neighbor RAN nodes, the said local cache related information further includes the identifier of the corresponding neighbor RAN nodes. If a PDU-session or QoS flow or bearer of the given UE can be supported by the local cache of neighbor RAN nodes, the said local cache related information further includes the application level classifiers associated with the said PDU-session or QoS flow or bearer.

In Step 3, gNB sends RRC reconfiguration which includes the configuration information of the established PDU session and the bearers. In Step 4, if the UE wants to trigger a new PDU session setup, it can send PDU session establishment request message to the CN. In Step 5, based on the UE request, CN sends PDU session setup request message to the gNB, in which CN can optionally include local cache related information if CN has not sent it before. In Step 6, gNB sends RRC reconfiguration which includes the configuration information of the new established PDU session and the bearer.

In addition, CN may also deliver the local cache related information to the gNB by using other messages between CN and the gNB, such as: UE CONTEXT MODIFICATION REQUEST, PDU SESSION RESOURCE MODIFY REQUEST, HANDOVER COMMAND, HANDOVER REQUEST, PATH SWITCH REQUEST ACKNOWLEDGE, DOWNLINK RAN STATUS TRANSFER, NG SETUP RESPONSE, RAN CONFIGURATION UPDATE ACKNOWLEDGE, AMF CONFIGURATION UPDATE, etc.

In a seventh embodiment, in case UE knows some of the running services are supported by the local cache of the serving gNB or eNB, and the cached data is not delay sensitive and is not required by the user right now, the UE can choose to send an assistance information to the serving RAN node that the downlink data transmission of the data stored in the local cache for the UE could be delayed, or sent again.

The said assistance information may include at least one of the following: (a) an indication to indicate the data stored in the local cache could be delayed or could be sent again; (b) the PDU-session-ID or the QoS flow-ID or the DRB-ID of the delayed data; (c) an identifier of a PDU session, or a QoS flow, or a bearer that needs to be supported by the local cache; (d) the delay time window or length, during which the RAN can stop the downlink data transmission to the said UE. The serving RAN node can decide whether to adjust the scheduling for the UE based on the above assistance information. Furthermore, this solution can also be used for the data stored in the RAN node’s buffer, e.g. the PDCP buffer. In this case, the said assistance information can further include: an indication to indicate the data buffered in the network node could be delayed or could be sent again. Based on the said assistance information, the RAN node can also know for how long to delay the UE’s data transmission and whether the UE can be transferred to RRC inactive state for a power saving purpose.

While various embodiments of the present disclosure have been described above, it should be understood that they have been presented by way of example only, and not by way of limitation. Likewise, the various diagrams may depict an example architectural or configuration, which are provided to enable persons of ordinary skill in the art to understand exemplary features and functions of the present disclosure. Such persons would understand, however, that the present disclosure is not restricted to the illustrated example architectures or configurations, but can be implemented using a variety of alternative architectures and configurations. Additionally, as would be understood by persons of ordinary skill in the art, one or more features of one embodiment can be combined with one or more features of another embodiment described herein. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments.

It is also understood that any reference to an element herein using a designation such as "first, " "second, " and so forth does not generally limit the quantity or order of those elements. Rather, these designations can be used herein as a convenient means of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements can be employed, or that the first element must precede the second element in some manner.

Additionally, a person having ordinary skill in the art would understand that information and signals can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits and symbols, for example, which may be referenced in the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

A person of ordinary skill in the art would further appreciate that any of the various illustrative logical blocks, modules, processors, means, circuits, methods and functions described in connection with the aspects disclosed herein can be implemented by electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two) , firmware, various forms of program or design code incorporating instructions (which can be referred to herein, for convenience, as "software" or a "software module) , or any combination of these techniques.

To clearly illustrate this interchangeability of hardware, firmware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware or software, or a combination of these techniques, depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in various ways for each particular application, but such implementation decisions do not cause a departure from the scope of the present disclosure. In accordance with various embodiments, a processor, device, component, circuit, structure, machine, module, etc. can be configured to perform one or more of the functions described herein. The term “configured to” or “configured for” as used herein with respect to a specified operation or function refers to a processor, device, component, circuit, structure, machine, module, etc. that is physically constructed, programmed and/or arranged to perform the specified operation or function.

Furthermore, a person of ordinary skill in the art would understand that various illustrative logical blocks, modules, devices, components and circuits described herein can be implemented within or performed by an integrated circuit (IC) that can include a general purpose processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) or other programmable logic device, or any combination thereof. The logical blocks, modules, and circuits can further include antennas and/or transceivers to communicate with various components within the network or within the device. A general purpose processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, or state machine. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other suitable configuration to perform the functions described herein.

If implemented in software, the functions can be stored as one or more instructions or code on a computer-readable medium. Thus, the steps of a method or algorithm disclosed herein can be implemented as software stored on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that can be enabled to transfer a computer program or code from one place to another. A storage media can be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer.

In this document, the term "module" as used herein, refers to software, firmware, hardware, and any combination of these elements for performing the associated functions described herein. Additionally, for purpose of discussion, the various modules are described as discrete modules; however, as would be apparent to one of ordinary skill in the art, two or more modules may be combined to form a single module that performs the associated functions according embodiments of the present disclosure.

Additionally, memory or other storage, as well as communication components, may be employed in embodiments of the present disclosure. It will be appreciated that, for clarity purposes, the above description has described embodiments of the present disclosure with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processing logic elements or domains may be used without detracting from the present disclosure. For example, functionality illustrated to be performed by separate processing logic elements, or controllers, may be performed by the same processing logic element, or controller. Hence, references to specific functional units are only references to a suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.

Various modifications to the implementations described in this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other implementations without departing from the scope of this disclosure. Thus, the disclosure is not intended to be limited to the implementations shown herein, but is to be accorded the widest scope consistent with the novel features and principles disclosed herein, as recited in the claims below.

Claims

A method performed by a first wireless communication node, the method comprising:

transmitting first cache related information to a second wireless communication node, wherein the first cache related information comprises information about a first local cache associated with the first wireless communication node, where the first local cache is configured for supporting at least one service in the first wireless communication node.
The method of claim 1, wherein the first cache related information comprises information about at least one of the following: an identifier of the first local cache; and an indication to indicate whether the first wireless communication node has a local cache support.
The method of claim 1, wherein the first cache related information comprises information about an indication to indicate whether the first local cache is shared by the first wireless communication node and the second wireless communication node.
The method of claim 1, wherein the first cache related information comprises information about a service information list indicating which services are supported by the first local cache.
The method of claim 4, wherein the service information list is described by one of the following types:

high level classifier of each service supported by the first local cache;

Quality of Service (QoS) level classifier of each service supported by the first local cache;

network slice identifier supported by the first local cache;

application level classifier supported by the first local cache.
The method of claim 1, wherein the first cache related information is carried by at least one of: an interface setup request message and an interface setup response message, during an inter-node interface setup process between the first wireless communication node and the second wireless communication node.
The method of claim 1, wherein the first wireless communication node is at least one of:

a source radio access network (RAN) node in a handover process for a given wireless communication device, wherein the second wireless communication node is a target RAN node in the handover process;

a master RAN node in a dual connection or multi-connection for the given wireless communication device, wherein the second wireless communication node is a secondary RAN node in the dual connection or multi-connection;

a distributed unit (DU) , wherein the second wireless communication node is a centralized unit (CU) ; and

a CU, wherein the second wireless communication node is a DU.
The method of claim 1, wherein the first cache related information comprises information about at least one of the following:

an indication to indicate whether the first local cache supports a given wireless communication device;

an indication to indicate whether the given wireless communication device is supported by a second local cache of a secondary node, wherein the given wireless communication device is configured with a multi-connection by the first wireless communication node and the secondary node; and

an indication to indicate whether the secondary node has a local cache support.
The method of claim 1, wherein the first cache related information comprises information about at least one of the following:

a first identifier of each service of the given wireless communication device supported by the first local cache, wherein the first identifier identifies at least one of: a protocol data unit (PDU) session, a Quality of Service (QoS) flow, and a bearer; and

a second identifier of each service of the given wireless communication device supported by the second local cache, wherein the second identifier identifies at least one of: a PDU session, a QoS flow, and a bearer.
The method of claim 1, wherein the first cache related information comprises information about at least one of the following:

a first data volume of service data associated with the given wireless communication device in the first local cache, wherein the first data volume is indicated with a granularity of at least one of: per user equipment (UE) , per PDU session, per QoS flow, and per bearer; and

a second data volume of service data associated with the given wireless communication device in the second local cache, wherein the second data volume is indicated with a granularity of at least one of: per UE, per PDU session, per QoS flow, and per bearer.
The method of claim 1, wherein the first cache related information comprises application information corresponding to the given wireless communication device, wherein the application information is indicated with a granularity of at least one of: per UE, per PDU session, per QoS flow, and per bearer.
The method of claim 1, wherein the first cache related information comprises information about at least one of the following:

information of first content data required by the given wireless communication device and stored in the first local cache, wherein the information of the first content data comprises at least one of feature and address of the first content data and is indicated with a granularity of at least one of: per UE, per PDU session, per QoS flow, and per bearer; and

information of second content data information required by the given wireless communication device and stored in the second local cache, wherein the information of the second content data comprises at least one of feature and address of the second content data and is indicated with a granularity of at least one of: per UE, per PDU session, per QoS flow, and per bearer.
The method of claim 12, wherein the first cache related information further comprises information about at least one of the following:

a last transmission location of the first content data in the first local cache; and

a last transmission location of the second content data in the second local cache.
The method of claim 1, further comprising:

receiving second cache related information from the second wireless communication node, wherein the second cache related information comprises information about a second local cache associated with the second wireless communication node.
The method of claim 14, wherein the second cache related information comprises information about at least one of the following:

a size of free space of the second local cache;

a data forwarding transport address of the second local cache;

an available buffer size or an acceptable data amount of data forwarding for a given communication device, in case there is no second local cache associated with the second wireless communication node or the second local cache cannot support the services of the given communication device.
The method of claim 14, wherein the second cache related information comprises information about an indication to indicate whether the second local cache has cached same data as the first local cache for the given communication device.
The method of claim 14, wherein the second cache related information comprises information about an indication of at least one cause for rejecting a request from the first wireless communication node.
The method of claim 17, wherein the at least one cause comprises one of the following:

the second wireless communication node has no local cache support;

the second local cache does not support the service requested by the first wireless communication node;

the second local cache has a congestion;

the second local cache is overloaded;

the second local cache does not have enough free space, wherein at least one of the above causes is indicated with a granularity of at least one of: per UE, per PDU session, per QoS flow, and per bearer.
A method performed by a first wireless communication node, the method comprising:

transmitting cache related information to a second wireless communication node, wherein the cache related information comprises information about a local cache associated with the second wireless communication node, where the local cache is configured for supporting at least one service in the second wireless communication node.
The method of claim 19, wherein the first wireless communication node is at least one of:

a core network (CN) node, wherein the second wireless communication node is a radio access network (RAN) node; and

a centralized unit (CU) , wherein the second wireless communication node is a distributed unit (DU) .
The method of claim 19, wherein the cache related information is related to a given wireless communication device and comprises information about at least one of the following:

a first indication to indicate whether a service of the given wireless communication device is supported by the local cache, wherein the first indication is with a granularity of at least one of: per protocol data unit (PDU) session, per Quality of Service (QoS) flow, per bearer;

a second indication to indicate whether a service of the given wireless communication device is supported by a local cache of a neighbor node of the second wireless communication node, wherein the second indication is with a granularity of at least one of: per PDU session, per QoS flow, per bearer; and

an identifier of a neighbor node whose local cache supports at least one service of the given wireless communication device.
The method of claim 19, wherein the cache related information is related to a given wireless communication device and comprises application information corresponding to the given wireless communication device, wherein the application information is indicated with a granularity of at least one of: per PDU session, per QoS flow, and per bearer.
The method of claim 19, wherein the cache related information is related to neighbor communication nodes of the second wireless communication node and comprises information about at least one of the following:

a first identifier list to indicate a first set of neighbor communication nodes each of which is associated with a local cache; and

a second identifier list to indicate a second set of neighbor communication nodes each of which is associated with a local cache supporting same services as the local cache associated with the second wireless communication node.
The method of claim 19, wherein:

the first wireless communication node is a user equipment (UE) ;

the second wireless communication node is a base station serving the first wireless communication node; and

the cache related information indicates that a downlink data transmission for the UE can be delayed.
The method of claim 24, wherein the cache related information comprises information about at least one of the following:

an indication to indicate a transmission of pending data in the local cache can be delayed;

an indication to indicate a transmission of data buffered in the second wireless communication node can be delayed;

a first identifier of each service to be delayed, wherein the first identifier identifies at least one of: a PDU session, a QoS flow, and a bearer; and

a delay time window during which the second wireless communication node can stop the downlink data transmission to the UE.
The method of claim 24, wherein the cache related information comprises information about at least one of the following:

an indication to indicate a transmission of pending data in the local cache can be sent again;

an indication to indicate a transmission of data buffered in the second wireless communication node can be sent again; and

a second identifier of each service to be sent again, wherein the second identifier identifies at least one of: a PDU session, a QoS flow, and a bearer.
The method of claim 24, wherein the cache related information comprises information about a third identifier of a PDU session, a QoS flow, or a bearer which needs to be supported by the local cache.
A method performed by a wireless communication node, the method comprising:

receiving cache related information from a wireless communication device, wherein the cache related information comprises information about a local cache associated with the wireless communication node, where the local cache is configured for supporting at least one service in the wireless communication node.
The method of claim 28, wherein:

the wireless communication device is a user equipment (UE) ;

the wireless communication node is a base station serving the UE; and

the cache related information indicates that a downlink data transmission for the UE can be delayed.
The method of claim 29, wherein the cache related information comprises information about at least one of the following:

an indication to indicate a transmission of pending data in the local cache can be delayed;

an indication to indicate a transmission of data buffered in the wireless communication node can be delayed;

a first identifier of each service to be delayed, wherein the first identifier identifies at least one of: a PDU session, a QoS flow, and a bearer; and

a delay time window during which the wireless communication node can stop the downlink data transmission to the UE.
The method of claim 29, wherein the cache related information comprises information about at least one of the following:

an indication to indicate a transmission of pending data in the local cache can be sent again;

an indication to indicate a transmission of data buffered in the wireless communication node can be sent again; and

a second identifier of each service to be sent again, wherein the second identifier identifies at least one of: a PDU session, a QoS flow, and a bearer.
The method of claim 29, wherein the cache related information comprises information about a third identifier of a PDU session, a QoS flow, or a bearer which needs to be supported by the local cache.
A wireless communication node configured to carry out the method of any one of claims 1 through 32.
A non-transitory computer-readable medium having stored thereon computer-executable instructions for carrying out the method of any one of claims 1 through 32.