CN112703766A

CN112703766A - Method performed by wireless communication node, and wireless communication node

Info

Publication number: CN112703766A
Application number: CN201880096452.0A
Authority: CN
Inventors: 戴谦; 艾建勋; 黄河
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2018-08-09
Filing date: 2018-08-09
Publication date: 2021-04-23
Anticipated expiration: 2038-08-09
Also published as: WO2020029167A1; CN112703766B

Abstract

The invention discloses a method executed by a wireless communication node and the wireless communication node. In one embodiment, a method performed by a first wireless communication node is disclosed. The method comprises the following steps: transmitting first cache related information to a second wireless communication node, wherein the first cache related information comprises: information of a first local cache associated with the first wireless communication node, the first local cache to support at least one service in the first wireless communication node.

Description

Method performed by wireless communication node, and wireless communication node

Technical Field

The present disclosure relates generally to wireless communications, and more particularly to methods performed by a wireless communication node, a wireless communication node.

Background

The fourth generation mobile communication technology (4G) Long-Term Evolution (LTE) or LTE-advanced (LTE-a) and the fifth generation mobile communication technology (5G) face increasing demands. Based on the current development trend, 4G and 5G systems are developing support for enhanced mobile broadband (eMBB), ultra-reliable low-latency Communication (URLLC) and large-scale Machine Type Communication (mtc) functions.

To support the features of ultra-high reliability and ultra-low latency transmission, it is desirable to transmit low-latency and high-reliability traffic with short transmission times. The cache may store traffic data that many users often need or access to provide low latency services to the users. When a conventional cache is located at a Core Network (CN) end of a wireless communication system, a local cache is introduced into an Evolved Packet Core (EPC) Network structure as a Radio Access Network (RAN) element, and is used for caching traffic data having the same content but required by a large number of users. Deploying local caching at the RAN level may reduce latency and reduce CN overhead. The local cache may be connected to or collocated with the associated RAN node.

However, not all RAN nodes will be deployed with local caches. In addition, different local caches may support caching content for different applications. As such, local cache deployment will affect resource management of the RAN node, especially in at least one of User Equipment (UE) mobility and multi-connection scenarios. Although the RAN node may need locally cached deployment and/or functionality information to help improve UE mobility and multi-connection performance, existing approaches fail to address this need through local cache management. Local caching is not entirely satisfactory.

Disclosure of Invention

The exemplary embodiments disclosed herein are intended to solve the problems associated with one or more of the problems presented in the prior art, and to provide additional features that will be readily understood by reference to the following detailed description when taken in conjunction with the accompanying drawings. In accordance with various embodiments, exemplary systems, methods, devices, and computer program products are disclosed herein. It is to be understood, however, that these embodiments are given by way of illustration and not of limitation, and that various modifications to the disclosed embodiments may be apparent to those skilled in the art upon reading this disclosure 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 the following steps: transmitting first cache related information to a second wireless communication node, wherein the first cache related information comprises: information of a first local cache associated with the first wireless communication node, wherein the first local cache is to support 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 the following steps: transmitting cache related information to a second wireless communication node, wherein the cache related information comprises: information of a local cache associated with the second wireless communication node, wherein the local cache is to support 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 the following steps: cache related information is received 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 used to support at least one service in the wireless communication node.

In various embodiments, a wireless communication node is disclosed for performing the disclosed methods in some embodiments.

In yet another embodiment, a non-transitory computer-readable medium having stored thereon computer-executable instructions for performing the methods disclosed in some embodiments is disclosed.

Drawings

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

Fig. 1 illustrates an exemplary 5G Radio Access Network (RAN) in which the techniques disclosed herein may be implemented, in accordance with embodiments of the present disclosure;

fig. 2 illustrates an exemplary Dual Connectivity (DC) system in which the techniques disclosed herein may be implemented, in accordance with embodiments 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 diagram of 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 diagram of a method performed by a UE to assist in 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 diagram 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 diagram of exchanging local cache related information between wireless communication nodes for handover, in accordance with some embodiments of the present disclosure;

fig. 10 illustrates an exemplary process diagram of exchanging local cache related information between wireless communication nodes for secondary node addition in accordance with some embodiments of the present disclosure;

fig. 11 illustrates an exemplary process diagram of exchanging local cache related information between wireless communication nodes for handover of a primary node having a secondary node in accordance with some embodiments of the present disclosure;

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

Detailed Description

Various exemplary embodiments of the disclosure are described below with reference to the drawings to enable one of ordinary skill in the art to make and use the disclosure. It will be apparent to those of ordinary skill in the art upon reading this disclosure that various changes or modifications can be made to the examples described herein without departing from the scope of the disclosure. Accordingly, the present disclosure is not limited to the exemplary embodiments and applications described and illustrated herein. Additionally, the particular order or hierarchy of steps in the methods disclosed herein is merely exemplary. Based upon design preferences, the specific order or hierarchy of steps in the methods or processes disclosed may be rearranged while remaining within the scope of the present disclosure. Accordingly, one of ordinary skill in the art will understand that the methods and/or techniques disclosed herein present the various steps or actions in a sample order, and the disclosure is not limited to the particular order or hierarchy presented unless specifically indicated otherwise.

A typical wireless communication network includes one or more Base Stations (BSs), each providing geographic radio coverage, and one or more wireless User Equipments (UEs) that can transmit and receive data within the radio coverage. In a wireless communication network, a BS and a UE may communicate with each other via a communication link, e.g., via downlink radio frames from the BS to the UE, or via uplink radio frames from the UE to the BS.

The present disclosure provides methods, devices and systems for managing a local cache of a wireless communication node to ensure smooth communication for a UE, particularly during handover and secondary node addition procedures. During the handover, the data session of the UE is transferred from the source BS to the target BS without disconnecting the session. Because the source BS may have a local cache that stores information related to the current data session to ensure seamless handover of the UE, the source BS may send local cache related information associated with (e.g., connected to or collocated with) the source BS to the target BS. The source BS may also receive information from the target BS regarding a local cache associated with the target BS. In establishing, for example, a Dual-Connectivity (DC) to Multi-Connectivity (MC), secondary nodes may be added or modified to serve the same UE with multiple BSs. Since the original BS, referred to as the primary node, may have a local cache storing information about the current data session, the primary node may send local cache related information associated with the primary node to the secondary node in order to ensure a smooth process of addition or modification by the secondary node. The primary node may also receive information from the secondary node regarding a local cache associated with the secondary node.

In one embodiment, a Radio Access Network (RAN) node may receive information from a Core Network (Core Network, CN) node regarding a local cache associated with the RAN node. In another embodiment, the UE may send local buffer related information to the BS to inform the BS that certain data transmissions of the UE may be delayed or sent again.

In various embodiments, a BS may be referred to as a network-side node, and may include or be implemented as: next Generation node B (gNB), E-UTRAN node B (eNB), Transmission Reception Point (TRP), Access Point (Access Point, AP), Downlink Node (DN), relay node, Core Network (CN) node, RAN node, master node, slave node, Distributed Unit (DU), Centralized Unit (CU), etc. the UE in this disclosure may be referred to as a terminal and may include or be implemented as a Mobile Station (MS), Station (STA), etc. the BS and UE may be described herein as non-limiting examples of "wireless communication nodes", and the UE and UE may be described herein as non-limiting examples of "wireless communication devices", according to various embodiments of the present disclosure, the BS and the UE may practice the methods disclosed herein and may be capable of wireless and/or wired communication.

Fig. 1 illustrates an exemplary 5G Radio Access Network (RAN)100 in which the techniques disclosed herein may be implemented, according to an embodiment of the disclosure. In fig. 1, the 5GC 110 refers to a core network of a 5G network. The lower half of fig. 1 shows a 5G Radio Access network (NG-RAN)120, which is referred to as a 5G new Radio Access Technology (RAT) Radio Access network. In this example, the NG-RAN 120 includes a set of one or more gnbs 121, 122 connected to the 5GC 110 through NG interfaces. Each gNB is a base station of a 5G RAN. The gNB may support operation in a Frequency Division Duplex (FDD) mode, a Time Division Duplex (TDD) mode, and/or a dual connectivity mode. A group of gnbs may be interconnected by an Xn interface. The gNB may include a gNB-CU (Generation node-Central unit) and one or more gNB-DUs (Generation node-Distributed units). the gNB-CU and the gNB-DUs are connected via an F1 interface.

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

In fig. 1, gNB 121 is not split into CU and DU, while gNB 122 is split into CU and DU. The decision whether to split the gNB depends on the operator's network deployment requirements. Examples of the division of the CU and DU functions in the Protocol stack are that a CU may include a Radio Resource Control (RRC) and a Packet Data Convergence Protocol (PDCP) function, and a DU may include a Radio Link Control (RLC), a Media Access Control (MAC) and a Physical (PHY) function.

Fig. 2 illustrates an exemplary Dual Connectivity (DC) system 200 in which the techniques disclosed herein may be implemented, in accordance with embodiments 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 (a first network node 222 and a second network node 224) that provide data connectivity to and from UEs (e.g., UE 230). For example, a network node may include a primary node and a secondary node. In another example, the network nodes in the DC system may include enbs and gnbs or other types of traffic network nodes that provide wireless connectivity to UEs.

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

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

Based on the Dual-Connectivity (DC) concept described above, multi-RAT Dual Connectivity refers to a Dual Connectivity architecture, where the primary and secondary nodes may be access points of different radio access technologies. For example, one access point may be an NR RAN node (e.g., a gNB); while another access point may be an LTE RAN node (eNB). In this example, the eNB and the gNB may be connected to the 5G core network simultaneously. In another example, a dual connectivity scenario may include both the primary node and the secondary node as NR RAN nodes (e.g., a gNB). Similar to dual connectivity, MC (multi-connectivity) may be implemented when the UE capabilities are up, where the UE may support more than two working radio interfaces simultaneously. When the MC is configured, the MN (Master Node) may configure more than one SN (secondary Node) to serve the UE and provide greater throughput than the DC architecture.

Fig. 3 illustrates a block diagram of a Base Station (BS)300 in accordance with some embodiments of the present disclosure. BS 300 is an example of a node that may be used 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 including a transmitter 312 and a 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, system clock 302 provides timing signals to processor 304 for controlling the timing of all operations of BS 300. Processor 304 controls the overall operation of BS 300 and may include one or more Processing circuits or modules, such as a Central Processing Unit (CPU) and/or general purpose microprocessor, a microcontroller, a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a state machine, gated logic, discrete hardware components, any combination of special purpose hardware finite state machines, or any other suitable circuit, device, and/or structure that may perform calculations or other manipulations of data.

Memory 306, which may include Read Only Memory (ROM) and Random Access Memory (RAM), may provide instructions and data to processor 304. A portion of the Memory 306 may 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. Instructions stored in memory 306 (also referred to as software) may be executed by processor 304 to perform the methods described herein. Together, processor 304 and memory 306 form a processing system that stores and executes software. As used herein, "software," whether referred to as software, firmware, middleware, microcode, etc., refers to any type of instructions that can configure a machine or device to perform one or more desired functions or processes. The instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable code format). 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 a transmitter 312 and a receiver 314, allows the BS 300 to transmit and receive data to and from a remote device (e.g., another BS or UE). Antenna 350 is typically attached to housing 340 and electrically coupled to transceiver 310. In various embodiments, BS 300 includes (not shown) multiple transmitters, multiple receivers, and multiple transceivers. In one embodiment, the antenna 350 is replaced by a multi-antenna array 350 (which may form multiple beams, each pointing in a different direction). The transmitter 312 may be used to wirelessly transmit packets having different packet types or functionalities, such packets being generated by the processor 304. Similarly, the receiver 314 is used to receive packets having different packet types or functionalities, and the processor 304 is used to process packets of a plurality of different packet types. For example, the processor 304 may be used to determine the type of packet and process the packet and/or fields of the packet accordingly.

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

In one embodiment, the BS 300 is a source Radio Access Network (RAN) node during handover of a given UE, and the second BS is a target RAN node during handover. In one embodiment, the BS 300 is a primary RAN node of a given UE in dual-connectivity or multi-connectivity, while a second BS is a secondary RAN node in dual-connectivity or multi-connectivity. In one embodiment, the BS 300 is a Distributed Unit (DU) and the second BS is a Centralized Unit (CU). In one embodiment, the BS 300 is a CU and the second BS is a DU. In one embodiment, the BS 300 is a Core Network (CN) node and the second BS is a RAN node.

In one embodiment, the first cache-related information comprises information about at least one of: an identifier of the first local cache; an indication indicating whether BS 300 has local cache support; an indication indicating 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: the method comprises the steps that a first local cache supports a classification mark of an upper level of each service; a Quality of Service (QoS) class classification identifier of each Service supported by a first local cache; a first local cache supported network slice identifier; and an application level classification identifier supported by the first local cache. According to various embodiments, the first buffer related information is carried by at least one of an interface setup request message and an interface setup response message in an inter-node interface setup procedure between the BS 300 and the second BS.

In this example, the user equipment traffic manager 322 may manage traffic of the UE and provide traffic information of the UE to the buffer-related information generator 320 for generating the first buffer-related information. In one embodiment, the first cache related information comprises information on at least one of: an indication indicating whether the first local cache supports the given UE; a first local cache supports a first identifier for each service of a given UE; a first data volume of traffic data associated with the given UE in a first local cache; application information corresponding to a given UE; giving information of first content data required by the UE and stored in a 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: protocol Data Unit (PDU) session, Quality of Service (QoS) flow and bearer. The first amount of data and the application information are indicated with at least one of the following granularities: per UE, per PDU session, per QoS flow and per bearer. The information of the first content data includes at least one of a characteristic and an address of the first content data, and is indicated with at least one of the following granularities: per UE, per PDU session, per QoS flow and per bearer.

In this example, when the BS 300 serves as a primary node of a secondary node in a DC or MC system, the secondary node manager 326 may manage the secondary node. The secondary node manager 326 may provide the secondary node(s) cache-related information 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 on at least one of: an indication indicating whether the given UE is supported by a second local cache of the secondary node; an indication indicating whether the secondary node has local cache support; a second local cache supports a second identifier for each service of the given UE; a second amount of traffic data associated with the given UE in a second local cache; giving information of second content data information required by the UE and stored in a second local cache; and a last transmission location of the second content data in the second local cache. A given UE may be configured with multiple connections by BS 300 and secondary nodes. The second identifier identifies at least one of: PDU session, QoS flow and bearer. The second amount of data is indicated with at least one of the following granularities: per UE, per PDU session, per QoS flow and per bearer. The information of the second content data includes at least one of a characteristic and an address of the second content data, and is indicated with at least one of the following granularities: per UE, per PDU session, per QoS flow and per bearer.

In this example, the buffer-related information analyzer 324 may receive and analyze the second buffer-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: a size of available space of the second local cache; a second locally cached data forwarding transmission address; a buffer size or an acceptable amount of data for data forwarding available to a given UE in the absence of a second local buffer associated with a second BS or the second local buffer cannot support traffic for the given UE moving from BS 300; an indication to indicate whether the second local cache already caches the same data for the given UE as the first local cache; and at least one indication of a reason for rejecting the request from BS 300. At least one reason may be one of the following: the second BS does not support local caching; the second local cache does not support the service requested by the BS 300; a second local cache congestion; a second local cache overload; or the second local cache does not have sufficient available space. At least one of the above reasons is indicated with at least one of the following granularities: per UE, per PDU session, per QoS flow and per bearer.

In another embodiment, the buffer-related information generator 320 may generate and transmit the buffer-related information to the second BS via the transmitter 312. The buffer-related information may include information about a local buffer associated with the second BS. The local cache may be used to support at least one service in the second BS. In one example, the BS 300 is a Core Network (CN) node and the second BS is a RAN node. In another example, the BS 300 is a Centralized Unit (CU), and the second BS is a Distributed Unit (DU). The cache-related information generated by the cache-related information generator 320 may be related to a given UE based on UE traffic information provided by the user equipment traffic manager 322 and include information regarding at least one of: a first indication for indicating whether the local cache supports the service of the given UE, a second indication for indicating whether the local cache of the neighbor node of the second BS supports the service of the given UE; it locally caches identifiers of neighbor nodes that support at least one service for the given UE, as well as application information corresponding to the given UE. The first indication, the second indication and/or the application information have at least one of the following granularity: per PDU session, per QoS flow, per bearer. In one example, the cache related information is related to a neighbor communication node of the second BS and comprises information on at least one of: a first list of identifiers indicating a first set of neighboring communication nodes (each associated with a local cache); and a second list of identifiers indicating a second set of neighboring communication nodes (each associated with a local cache that supports the same traffic as the local cache associated with the second BS).

In various embodiments, the buffer-related information analyzer 324 receives buffer-related information from UEs served by the BS 300 and analyzes the information. The buffer related information includes information about a local buffer associated with the BS 300. The local cache is used to support at least one service in the BS 300. In one example, the buffer-related information indicates that downlink data transmissions for the UE may be delayed or resent. In one example, the cache-related information comprises information about at least one of: an indication that transmission of pending data in the local cache may be delayed; an indication that transmission of data buffered in BS 300 may be delayed; a first identifier for each delayed service, the first identifier identifying at least one of: PDU session, QoS flow and bearer; and a delay time window during which the BS 300 may stop downlink data transmission to the UE. In another example, the cache related information further comprises information relating to at least one of: an indication that the transmission of the data to be processed in the local cache may be sent again; an indication indicating that transmission of data buffered in the BS 300 can be transmitted again; and re-transmitting the second identifier for each service, wherein the second identifier identifies at least one of: PDU session, QoS flow and bearer. In yet another example, the buffer related information further comprises information on a third identifier of the PDU session, QoS flow or bearer that needs to be supported by the local buffer.

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

The various modules discussed above are coupled together by a bus system 330. For example, the bus system 330 may include a data bus, as well as a power bus, a control signal bus, and/or a status signal bus, in addition to the data bus. It should be appreciated that the modules of BS 300 may be operatively coupled to each other using any suitable techniques and media.

Although a number of separate modules or components are shown in fig. 3, one of ordinary skill in the art will appreciate that one or more of the modules may be combined or implemented collectively. For example, the processor 304 may implement not only the functionality described above with respect to the processor 304, but also the functionality described above with respect to the cache-related information generator 320. Rather, each of the modules shown in FIG. 3 may be implemented using a plurality of separate components or elements.

Fig. 4 illustrates a flow diagram of a method 400 performed by a BS (e.g., BS 300 in fig. 3) for managing local caches in accordance with some embodiments of the present disclosure. In operation 402, the BS obtains service information related to the user equipment. Optionally, in operation 404, the BS obtains cache related information about the associated secondary node. In operation 406, the BS generates buffered correlation information for handover or secondary node addition. In operation 408, the BS transmits the generated buffered correlation information to the receiving node. In operation 410, the BS receives and analyzes the buffered correlation 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. UE 500 is an example of a device that may be used 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 including a transmitter 512 and a receiver 514, a power module 508, a buffer-related information generator 520, and a data prioritizer 522.

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

In the communication system, the UE 500 may be associated with a BS. For example, the UE 500 may be served by a BS with a local buffer connected to or collocated with the BS. In one embodiment, the buffer-related information generator 520 may generate and transmit the buffer-related information to the BS via the transmitter 512. The buffer related information may include information about a local buffer connected to or collocated with the BS. The local cache may be used to support at least one service in the BS. The buffer-related information may indicate that downlink data transmission for the UE may be delayed or resent.

In this example, the data prioritizer 522 may determine priority information for data transmission related to the UE 500, identify data and traffic based on the priority information, and provide the identified information to the cache related information generator 520 to generate cache related information. In one example, the cache-related information comprises information about at least one of: an indication that transmission of pending data in the local cache may be delayed; an indication indicating that transmission of data buffered in the BS may be delayed; a first identifier for each delayed service, the first identifier identifying at least one of: PDU session, QoS flow and bearer; and a delay time window during which the BS may stop data transmission to the UE. In another example, the cache related information comprises information relating to at least one of: an indication that the transmission of the data to be processed in the local cache may be sent again; an indication indicating that transmission of data buffered in the BS can be sent again; and re-transmitting the second identifier for each service, wherein the second identifier identifies at least one of: PDU session, QoS flow and bearer. In yet another example, the buffer-related information includes information regarding a third identifier of a PDU session, QoS flow or bearer that needs to be supported by the local buffer.

The various modules discussed above are coupled together by a bus system 530. For example, the bus system 530 may include a data bus, a power bus in addition to the data bus, a control signal bus, and/or a status signal bus. It should be appreciated that the modules of UE 500 may be operatively coupled to each other using any suitable techniques and media.

Although many separate modules or components are shown in fig. 5, one of ordinary skill in the art will appreciate that one or more modules may be combined or jointly implemented. For example, the processor 504 may implement not only the functionality described above with respect to the processor 504, but also the functionality described above with respect to the cache-related information generator 520. Rather, each of the modules shown in FIG. 5 may be implemented using a plurality of separate components or elements.

Fig. 6 illustrates a flow diagram of a method 600 performed by a UE (e.g., UE 500 in fig. 5) to facilitate managing a local cache, in accordance with some embodiments of the present disclosure. In operation 602, the UE determines priority information for data transmission related to the UE. In operation 604, the UE identifies data and traffic based on the priority information. In operation 606, the UE generates buffered correlation information based on the identified data and traffic. In operation 608, the UE transmits the generated buffered related information to a node associated with the UE, e.g., a BS.

Various embodiments of the present disclosure will now be described in detail below. Note that the features of the embodiments and examples in the present disclosure may be combined with each other in any manner without conflict.

Local caching is introduced as a deployment implemented by enbs in a Packet Switched Core (EPC) network architecture to cache traffic data having the same content but required by many users. Deploying local caching at the RAN level may reduce latency and reduce CN overhead.

Fig. 7A illustrates an exemplary deployment 710 of a local cache 716 associated with a BS 715 according to some embodiments of the disclosure. In the exemplary deployment 710, the local cache 716 is directly connected or coupled to the eNB 715, and the eNB 715 communicates with the UE 711 and a 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 the first case, the source network node needs to know the local cache deployment of the neighbor network nodes in advance before triggering Handover (HO) or Secondary Node (SN) addition, and if a given UE needs to add HO or SN, the source network node can be helped to select a more appropriate target node.

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

The local cache assistance information may include an identifier of the local cache. After receiving it, the second network node may use it, e.g. check if the second network node shares the same local cache as the first network node. For example, in some deployments, one local cache server may be connected to more than one network node.

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. The indication may be provided if the first network node has previously received the local cache identifier of the second network node.

The local caching assistance information may also include an indication of whether the first network node has local caching support (e.g., at least one local caching server is directly or indirectly connected to or collocated with the first network node). The indication may be a simple indication, such as a 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 management. The service information may be constructed of one of the following types: upper-level classification identifiers of supported services, such as signaling, data, MT (Mobile Terminal), emergency, high-priority access; QoS level classification identifications that may be used, for example, QoS classifications defined by the third Generation Partnership Project (3rd Generation Partnership Project, 3GPP for short), such as QCI defined in TS23.401 or 5QI defined in TS 23.501; locally caching supported network slice identifiers; the application level classification identifies, for example, an identifier or a Name of an application, or an identifier or a Name of an application (or service) provider, or an address of an application (or service) provider (Uniform Resource Locator, abbreviated as URL or IP address), or an application server address (URL or IP address), or a content server address (URL or IP address), a content address (URL or IP address), or an Access Point Name (abbreviated as APN) or APN address, or a URL (or IP) address of a list of applications supported by a local cache.

The local cache assist information may be carried in an inter-node interface establishment process. For example, it may be carried in an inter-node interface (e.g. X2 or Xn interface), in an establishment procedure between the first network node and the second network node, in an X2 or Xn interface establishment request message or in an X2 or Xn interface establishment response message. In the case of two LTE RAN nodes or one LTE RAN node and one nr (new rat) RAN node, both connected to the EPC core network, the inter-node interface may be referred to as the X2 interface; in the case of two NR RAN nodes, both connected to the NGC core network, or one LTE RAN node and one NR (new rat) RAN node, the inter-node interface may be referred to as an Xn interface.

Based on the first exemplary solution, the network node will know whether another network node has local cache support and, in addition, which services the local cache can support, through which the network node can know whether another node is suitable as target node if the UE satisfies the HO condition or needs to establish dual connectivity. For example, if the local cache of the source network node supports the running traffic of the UE, then it is preferable to select a target node that also has a local cache, and if the UE needs a handover, this cache also supports the traffic of the UE.

In the second case, the traffic node decides to establish dual connectivity to serve the UE when a handover of a given UE is triggered (e.g., when the UE moves out of the current traffic network node), or an addition, modification or change procedure of SNs (secondary nodes) is triggered for a given UE (e.g., when the traffic of the UE requires high throughput but the current traffic network node cannot meet QoS).

In one exemplary solution, a first network node sends local cache assistance information to a second network node, the local cache assistance information comprising at least one of the following if the first network node has a local cache and the local cache supports at least one of the UE's traffic.

The local caching assistance information may include: an indication indicating whether the UE is supported by a local cache of a first network node, and optionally an indication indicating whether the UE is supported by a local cache of a SN (secondary node) in case the first network node configures an MC (multi-connectivity) for the UE and the SN also has a local cache. DC (dual connectivity) is a sub-case of MC (multi connectivity).

The local caching assistance information may further include: the local caching of the first network node may support identifiers of PDU sessions or QoS flows or bearers of said UE and optionally comprises identifiers of PDU sessions or QoS flows or bearers of said UE which the local caching of the SN may support if the UE is configured with MC by the first network node and the SN also has a local caching.

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

The local caching assistance information may further include: application information corresponding to the UE that can be represented in per PDU session, or per QoS flow or per bearer granularity. The application information refers to an application level classification identification, for example, an identifier or name of an application, or an identifier or name of an application (or service) provider, or an address (URL or IP address) of an application (or service) provider, or an application server address (URL or IP address), or a content server address (URL or IP address), a content address (URL or IP address), or an APN name or APN address, or a URL (or IP) address of an application. The application information may be carried in the message by using an explicit IE (information element) or may be contained in a container that is transparent to the network node.

In one example, the local cache assistance information relates to a neighboring communication node of the second network node and comprises information on at least one of: a first list of identifiers indicating a first set of neighboring communication nodes (each associated with a local cache); and a second list of identifiers indicating a second set of neighboring communication nodes (each associated with a local cache that supports the same traffic as the local cache associated with the second network node).

The local caching assistance information may further include: and storing the information of the content data required by the UE in the local cache. The information indicates buffered data in a local cache of the first node and/or a local cache of the SN (in case the MC is configured and the SN also has a local cache), which data is associated with a PDU session or QoS flow or bearer of the UE and is currently or subsequently retrieved by the UE. The information may include at least one of: characteristics of the content data, such as name, size, format, date, author, owner, free or not, etc.; an address of the content data, such as a uniform address, e.g. a URL or a fixed IP address, or an address temporarily assigned by an operator or service provider. The information may be indicated at a granularity per UE or per PDU session, or per QoS flow or per bearer. The information may be provided by a local cache of the first network node and/or a local cache of the SN (in case the MC is configured and the SN also has a local cache). The information may be carried in the message by using an explicit IE (information element) or contained in a container that is transparent to the network node. From this information, the second network node may check whether its local cache already stores the same content data as the local cache of the first network node.

The local caching assistance information may further include: the UE caches the last transmission location of the required content data from the local. This information is used to ensure transmission continuity for the UE. The location also indicates which part of the content data has been successfully transmitted to the UE and which part has not yet been successfully transmitted. Based on this information, the second node cache knows from which location to send data continuously to the UE. The transmission location in the content may be retrieved from the first node local cache and/or the SN local cache (in case the MC is configured and the SN also has a local cache). It may be carried in the message by using an explicit Information element (IE for short) or contained in a container transparent to the network node.

The local caching assistance information may further include: an indication indicating whether the SN has local cache support in case the first network node configures the MC for said UE. The first network node needs to inform the second network node of the indication so that the second network node can know in advance how to manage the bearers in relation to the local caching of the SN for the given UE if the SN can be retained after the handover. The local cache assist information may be carried in a request message sent by the first network node, such as a handover request message, an SN addition request message, and an SN modification request message.

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

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

The local cache related information may further include: the size of the available space of the local cache of the second network node. The available space size may represent a total available space of the local cache, or may represent an available space size that the local cache may allocate to the UE, or may represent an available space size that the local cache may allocate for each PDU session or QoS flow or bearer of the UE.

If the second network node cannot accept requests from the first network node or only accepts partial requests from the first network node (i.e., the second node does not accept certain PDU sessions or QoS flows or bearers), the second network node indicates a reason in the local cache related information in the response to the first network node. The reason may include at least one of: "no local cache support": indicating that the second node does not have a local cache; "cache not supported or incompatible, or local cache not supported service": indicating that the second node has a local cache, but the cache does not support the traffic requested by the first node, which may be represented in per UE or per PDU session, or per QoS flow or per bearer granularity; "buffer congestion or overload or deficit": indicating that the second node has a local buffer, but the buffer is full or there is not enough available space, which can be expressed in per UE or per PDU session or per QoS flow or per bearer granularity.

The local cache related information may further include: and the data forwarding transmission address locally cached by the second node. This information is used for the first network node to directly forward data stored in the local cache to the second node local cache without passing through the second network node.

In the case where no local cache is connected or collocated with the second node, or the second local cache of the second network node cannot support the traffic of the given UE moving from the first network node to the second network node, the local cache related information may further include an available Packet Data Convergence Protocol (PDCP) buffer size or an acceptable Data forwarding Data amount of the given UE.

The response message containing the local cache related information may be carried in a request response message sent by the second network node, for example, a handover request confirmation message, a handover preparation failure message, an SN addition request confirmation or rejection message, and an SN modification request confirmation or rejection message.

According to various embodiments, the first and second network nodes may be respectively: (a) a source RAN node and a target RAN node in case of handover; (b) in case of dual connectivity, a primary RAN node and a secondary RAN node; (c) DU and CU; or (d) CU and DU.

In a third case, for a given UE connected to the network node, the network node should know which services established for the given UE are supported by the local cache. In an exemplary solution, a first network node obtains locally cached assistance information for a given UE from an assistance network node. The local cache assistance information may include at least one of the following.

The local caching assistance information may include: whether a local cache connected to a serving RAN node can support a running or to be established PDU session or QoS flow or bearer for a given UE may be indicated by the granularity of each PDU session or QoS flow or bearer.

The local caching assistance information may include: whether a local cache connected to a neighboring RAN node can support a running or to-be-established PDU session or QoS flow or bearer for a given UE. The local cache assistance information also includes an identifier of the corresponding neighbor RAN node if the local cache of the neighbor RAN node can support a PDU session or QoS flow or bearer for the given UE. If the local cache of a neighboring RAN node can support a PDU session or QoS flow or bearer for a given UE, the local cache assistance information also includes an application level classification identification associated with the PDU session or QoS flow or bearer.

The local caching assistance information may include: application information corresponding to PDU sessions or QoS flows or bearers of the UE, which may be indicated with a granularity per PDU session, or per QoS flow or per bearer. The application information refers to an application level classification identifier, for example, an identifier or Name of an application, or an identifier or Name of an application (or service) provider, or an address (URL or IP address) of an application (or service) provider, or an application server address (URL or IP address), or a content server address (URL or IP address), a content address (URL or IP address), or an Access Point Name (APN) or APN address, or a URL (or IP) address of an application. The application information may be carried by including it in a container that is transparent to the RAN node.

According to various embodiments, the first network node and the second network node may be: (a) the first network node is a RAN node and the second network node is a CN node; (b) the first network node is a DU and the second network node is a CU. The CN node may include a Mobility Management Entity (MME) for the EPC network, a Security GateWay (SGW), a Power Group Wire (PGW); and includes an Access Management Function (AMF) suitable for the 5G core network, a Service Management Function (SMF), an Application Function (AF), and a User Port Function (UPF).

The local caching assistance information for a given UE may be obtained from a CN node in the following process: bearer or PDU session establishment or modification procedures; or a path switching procedure during switching; or UE content establishment procedure.

In another case, the UE may provide assistance information to a network node (serving RAN node), which may delay or resend the UE's downlink data transmission. This requirement may come from the UE application layer. The assistance information includes at least one of: an indication to indicate that transmission of pending data in the local cache may be delayed or may be sent again; an indication indicating that the transmission of data buffered in the network node may be delayed or may be sent again. The assistance information may optionally include a PDU session ID or QoS flow ID or DRB-ID indicating data that is delayed or retransmitted. The assistance information may optionally include an identifier of the PDU session, or QoS flow, or bearer that the local cache needs to support. The assistance information may optionally include a delay time window or length in which the RAN may stop data transmission to the downlink of the UE. Based on the assistance information, the RAN node may know how long to delay the data transmission of the UE and whether the UE may be transferred to the RRC inactive state for energy saving purposes.

In a first embodiment, as shown in fig. 8, it is assumed that both eNB 1810 and eNB 2820 are connected to the EPC core network. The establishment of the inter-node interface (X2 interface) may be as follows. In step 1, in the X2 setup request message sent by eNB1 to eNB2, if eNB1 is already connected to the local cache, eNB1 may add local cache related information in the message. This may be helpful in case 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 may be a one bit indication.

Further, eNB1 may also give more detailed information, such as: locally cached identifiers, or a list of identifiers if the eNB1 connects multiple local caches. Further, the eNB1 may provide a traffic information list to indicate locally caching supported traffic, which may make the local cache of eNB2 or eNB2 aware of the differences in supported traffic. The service information list may be one of the following types: generic identification of the upper levels of supported services, such as signaling, data, MT (mobile terminal), emergency, high priority access; QoS level classification identifications that may be used, such as 3GPP defined QoS classifications; locally caching supported network slice identifiers; the application level classification identifies, for example, an identifier or name of an application, or an identifier or name of an application (or service) provider, or an address (URL or IP address) of an application (or service) provider, or an application server address (URL or IP address), or a content server address (URL or IP address), a content address (URL or IP address), or an APN name or APN address, or a URL (or IP) address of a list of locally cached supported applications. To carry the local cache related information, it may be explicitly added to the message as an IE (information element) or may be contained in a container transparent to the eNB.

In step 2, the eNB2 should send feedback after receiving the X2 setup request. If the eNB2 is also connected to the local cache, local cache related information is added to the X2 setup response. If the local cache of the eNB2 connection is the same as eNB1, eNB2 may simply add an indication, e.g., one bit, in the response message. Otherwise, the eNB2 may include the identifier of the local cache in the response message.

Similarly, eNB2 may also include further detailed information in the response message (e.g., the service information list in step 1) to indicate that the supported services are cached locally. In one example, the first network node is an eNB and the second network node is a gNB (NR-RAN node), and both are connected to the EPC. In this case, either eNB or gNB may initiate an EN-DC X2 interface establishment procedure, which further includes two steps: an EN-DC X2 interface setup request and an EN-DC X2 interface setup response. In this example, the above-described embodiments are also suitable for use.

In another example, the first network node is a gNB and the second network node is an eNB or a gNB, and both are connected to the NGC. In this case, the eNB or the gNB may both initiate an Xn interface establishment procedure, which further includes two steps: an Xn interface setup request and an Xn interface setup response. In this example, the above-described embodiments are also suitable for use.

In the second embodiment, as shown in fig. 9, it is assumed that the UE 910 sends a measurement report to a serving eNB (e.g., eNB 1920) connected with the EPC, and the eNB 1920 discovers that the UE 910 has satisfied the HO condition. The eNB 1920 selects a target RAN node (e.g., eNB 2930) based on the UE's measurement reports and initiates the HO procedure. In some cases, the source and target RAN nodes may also be gnbs connected to the EPC. For EPC networks, CN 940 may represent an MME and an SGW; for 5GC, CN 940 may represent AMF and SMF.

In step 1, the UE 910 performs measurements and sends the results to the serving eNB, eNB 1920. In step 2, the UE 910 decides to handover the UE to the eNB 1920 based on the measurement report received from the UE 910. The eNB 1910 transmits a HO request message to a target eNB (eNB 1920). The HO request message includes local cache assist information.

To assist the target eNB in making an appropriate decision whether the UE can be accepted and further which services of the UE can be accepted and which cannot, the local cache assistance information may comprise at least one of the following.

The local caching assistance information may include: an indication, e.g., a one-bit indication, indicating whether the local cache of the source eNB1 supports UEs may be used to indicate "with" or "without. The local caching assistance information may include: the local caching of the source eNB1 supports the UE's PDU session identifier or QoS flow or bearer. The local caching assistance information may include: the amount of data of the UE-related traffic data stored in the local cache of the source eNB1 may be indicated with a granularity per UE, or per PDU session, or per QoS flow or per bearer. The local caching assistance information may further include: application information corresponding to the UE that can be represented with a granularity per PDU session, or per QoS flow or per bearer. The application information refers to an application level classification identification, for example, an identifier or name of an application, or an identifier or name of an application (or service) provider, or an address (URL or IP address) of an application (or service) provider, or an application server address (URL or IP address), or a content server address (URL or IP address), a content address (URL or IP address), or an APN name or APN address, or a URL (or IP) address of an application. The application information may be carried in the message by using an explicit IE (information element) or may be contained in a container transparent to the RAN node.

In one example, the local cache assistance information relates to neighboring communication nodes of the target eNB2 and includes information regarding at least one of: a first list of identifiers indicating a first set of neighboring communication nodes (each associated with a local cache); and a second list of identifiers indicating a second set of neighboring communication nodes (each associated with a local cache that supports the same traffic as the local cache associated with the target eNB 2).

The local caching assistance information may include: and storing the information of the content data required by the UE in the local cache. The information indicates buffered data in the source node local buffer, which is associated with the UE's PDU session or QoS flow or bearer and is currently or subsequently retrieved by the UE. The information may include at least one of: characteristics of the content data, such as name, size, format, date, author, owner, free or not, etc.; an address of the content data, such as a uniform address, e.g. a URL or a fixed I P address, or an address temporarily assigned by an operator or service provider. The information may be indicated at a granularity per UE or per PDU session or per QoS flow or per bearer. The information may be provided by a local cache of the source eNB 1. The information may be carried in the message by using an explicit IE (information element) or including it in a container transparent to the eNB. From this information, the target eNB2 may check whether its local cache already stores the same content data as the local cache of the source eNB 1.

The local caching assistance information may include: the UE caches the last transmission location of the required content data from the local. This information is used to ensure transmission continuity for the UE. 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 local cache of the target eNB2 knows from which location to transmit data to the UE continuously after the handover of the UE from eNB1 to eNB 2. The transmission location in the content data may be retrieved from a local cache of the source eNB 1. It can be carried in the message by using an explicit IE (information element) or contained in a container transparent to the eNB.

In the case of an inter-MN HO with or without SN change, the local caching assistance information may include: an indication of whether the SN connected to source eNB1 has local caching support. In the case where the given UE satisfies the handover condition and the source eNB1 has configured dual connectivity for the given UE (i.e., the UE is simultaneously connected to 2 RAN nodes, e.g., eNB1 and a secondary eNB or gNB), then the indication is sent by the source eNB 1. The source eNB1 then needs to inform the target eNB2 of this target so that the target eNB2 can know in advance how to manage bearers related to the local caching of SNs for a given UE if the SNs can be retained after handover.

In step 3, based on the local cache related information sent from the source eNB 1920, the eNB 2930 may decide whether handover of the UE can be accepted. If so, it further decides to accept all or only a portion of the UE traffic, wherein the eNB2 may send a response message to the eNB1 with the decision to include the local cache-related response therein. eNB2 may also include radio configurations assigned to the UE for the UE to access the eNB if the eNB2 accepts the HO request of eNB 2. The local cache related response comprises at least one of: an indication to indicate whether the local cache of eNB2 has cached the same content or data as the indicated source network node; an available space size of a local cache of eNB2, the available space size may represent a total available space of the local cache, or may be an available space size that the local cache may allocate to the UE, or an available space size that the local cache may allocate for each PDU session or QoS flow or bearer of the UE; if the second network node cannot accept requests from the first network node, or only accepts partial requests from the first network node (i.e., the second node does not accept certain PDU sessions or QoS flows or bearers), the second network node indicates a reason in the response to the first network node, which may include at least one of: "no local cache support": indicating that the second eNB2 does not have a local cache, "cache not supported or incompatible, or local cache not supported traffic": indicating that eNB2 has local buffering, but the buffering does not support the traffic requested by eNB1, which makes it possible to express "buffer congestion or overload or deficit" in per UE or per PDU session, or per QoS flow or per bearer granularity: indicating that eNB2 has a local buffer, but the buffer is full or not enough available space, which can be expressed in per-UE or per-PDU session or per-QoS flow or per-bearer granularity; locally cached data forwarding transport address of eNB 2: this information is used for the eNB1 to forward data stored in the local cache directly to the local cache of eNB2 without going through eNB 2; and an available PDCP buffer size or an acceptable amount of data forwarding data for a given UE without a local cache connected or collocated with the second node or the second local cache of the second network node being unable to support traffic for the given UE moving from the first network node to the second network node.

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

In step 7, the eNB1 forwards the pending data for the UE in steps 5 and 6 (i.e. DL data not successfully sent to the UE and UL data received but not passed to the core network) to the eNB2, which includes not only the pending data in the buffer of the eNB1 but also the pending data in the local buffer of the eNB 1. eNB1 may only forward pending data in a local cache corresponding to bearers accepted by the local cache of eNB2 and may not forward cached pending data for bearers accepted by eNB2 but not accepted by the local cache of eNB 2.

In step 8, the eNB2 sends a path switch request message to the CN 940 (e.g., MME) to switch the user plane tunnel for the UE from eNB1 to eNB 2. In step 9, the MME 940 sends a path switch response to the eNB2, wherein the MME 940 may optionally include local cache related information including at least one of: whether a local cache connected to eNB2 can support a running or to be established PDU session or QoS flow or bearer of the UE; whether a local cache connected with a neighboring RAN node of eNB2 can support a PDU session or QoS flow or bearer that the UE is running or about to establish: the local cache assistance information further includes an identifier of a corresponding neighbor RAN node if a local cache of the neighbor RAN node can support a PDU session or QoS flow or bearer of the given UE, and an application level classification identification associated with the PDU session or QoS flow or bearer if the local cache of the neighbor RAN node can support the PDU session or QoS flow or bearer of the given UE; application information corresponding to PDU sessions or QoS flows or bearers of the UE, which may be indicated with a granularity per PDU session, or per QoS flow or per bearer. The application information refers to an application level classification identification, for example, an identifier or name of an application, or an identifier or name of an application (or service) provider, or an address (URL or IP address) of an application (or service) provider, or an application server address (URL or IP address), or a content server address (URL or IP address), a content address (URL or IP address), or an APN name or APN address, or a URL (or IP) address of an application. The application information may be carried by using an explicit IE (information element) or contained in a container that is transparent to eNB 2.

In the third embodiment, as shown in fig. 10, it is assumed that a UE 1010 connected to a traffic eNB 11020 connected to EPC is assumed, and eNB 11020 cannot bear QoS of UE1 due to radio interface congestion. The eNB1 then selects the target RAN node 1030 to offload all or part of the traffic of the UE1 to the target node. eNB1 initiates the SN addition procedure. In fig. 10, eNB1 is referred to as MN 1020 and the target RAN node is referred to as SN 1030. For EPC networks CN 1040 may represent MME and SGW, for 5G core networks CN 1040 may represent AMF and SMF. In this embodiment, it is assumed that the MN has a local cache, and the local cache can support traffic of the UE, and the SN also has a local cache.

In step 1, the UE is currently connected with the MN. When the MN finds that the QoS of the UE cannot be satisfied due to, for example, radio resource congestion, the MN may attempt to add a SN to offload all or part of the traffic of the UE. The MN sends a SN addition request message to the SN, including information of the ERAB (in case the network is EPC) or PDU session or QoS flow (in case the network is 5 GC) that the MN attempts to offload to the SN. Optionally, the MN may include local cache assistance information if the MN has a local cache and at least one of the traffic of the UE is supported by the local cache. The local cache assist information may include at least one of: (a) an indication, e.g., a one-bit indication, indicating whether the UE is supported by the local cache of the MN may be used to indicate "with" or "without"; (b) locally caching identifiers of UE PDU sessions or QoS flows or bearers supported by the MN; (c) the amount of data of UE-related traffic data stored in the local cache of the MN, which may be indicated with per-UE, or per-PDU session, or per-QoS-flow or per-bearer granularity; (d) application information corresponding to the UE, which may be indicated by granularity per PDU session or per QoS flow or per bearer. The application information refers to an application level classification identification, for example, an identifier or name of an application, or an identifier or name of an application (or service) provider, or an address (URL or IP address) of an application (or service) provider, or an application server address (URL or IP address), or a content server address (URL or IP address), a content address (URL or IP address), or an APN name or APN address, or a URL (or IP) address of an application. The application information may be carried in the message by using an explicit IE (information element) or contained in a container that is transparent to the RAN node.

The local cache auxiliary information may further include information of content data required by the UE stored in the local cache. This information indicates the cached data in the MN's local cache that is associated with the UE's PDU session or QoS flow or bearer and is currently or subsequently retrieved by the UE. The information may include at least one of: characteristics of the content data, such as name, size, format, date, author, owner, free or charged, etc.; the address of the content data, for example a uniform address such as a URL or a fixed IP address, or an address temporarily assigned by the operator or service provider. The information may be indicated at a granularity per UE or per PDU session, or per QoS flow or per bearer. The information may be provided by the local cache of the MN. The information can be carried in the message by using an explicit IE (information element) or including it in a container that is transparent to the MN. Based on this information, the SN can check whether its local cache already stores the same content data as the local cache of the MN.

The local cache assistance information may also include a last transmission location of the content data that the UE needs from the local cache. This information is used to ensure transmission continuity for the UE. The location also indicates which part of the content data has been successfully transmitted to the UE and which part has not yet been successfully transmitted. Based on this information, the local cache of the SN knows from which location the data is continuously sent to the UE after the traffic of the UE is offloaded from the MN to the SN, the transmission location in the content data can be retrieved from the local cache of the source MN, which can be carried in a message by using an explicit IE (information element) or contained in a container transparent to the MN.

In step 2, the SN decides whether it can accept the traffic requested by the MN for a given UE and whether the local cache of SNs supports these traffic. Based on the SN's decision, the SN may send a response message to the MN including the accepted traffic and the corresponding radio configuration for the UE to access the SN, and may choose to include locally cached relevant information if the local cache of SNs can support some accepted traffic. The local cache related information comprises at least one of: (a) the indication indicating whether the local cache of SNs has cached the same content or data as the indicated MN may be indicated with per PDU session, or per QoS flow or per bearer granularity; (b) an available space size of a local cache of SNs, which may represent a total available space of the local cache, or may be an available space size that the local cache may allocate to the UE, or an available space size that the local cache may allocate to each PDU session or QoS flow or bearer of the UE; (c) if the SN fails to accept a request from the MN or accepts only a partial request from the MN (i.e., the second node does not accept certain PDU sessions or QoS flows or bearers), the SN indicates a cause in a response to the MN, which may include at least one of: "no local cache support": indicating that the SN has no local cache, "cache does not support or is not compatible, or the local cache does not support traffic": indicating that the SN has local buffering, but the buffering does not support the traffic requested by the MN, which can be expressed in per-UE or per-PDU session, or per-QoS flow or per-bearer granularity, "buffer congestion or overload or deficit": indicating that the SN has a local buffer, but the buffer is full or there is not enough available space, which makes it possible to represent with granularity per UE or per PDU session or per QoS flow or per bearer; (d) data forwarding transport address of local cache of SN: the MN directly forwards the data stored in the local cache to the local cache of the SN without passing through the SN; and an available PDCP buffer size or an acceptable amount of data forwarding data for a given UE without a local cache connected or collocated with the second node or the second local cache of the second network node being unable to support traffic for the given UE moving from the first network node to the second network node.

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

In step 8, the MN sends an ERAB or PDU session modification indication message to the CN to inform the CN about SN addition and traffic offloading of the UE so that the CN can adjust the indicated ERAB or PDU session to the UP downlink transport address of the SN. In step 9, the CN sends an ERAB or PDU session modification acknowledge message to the MN, wherein the CN may optionally include local cache related information, which includes at least one of: (a) whether local caching of the MN and/or SN can support a running or to-be-established PDU session or QoS flow or bearer of the UE; (b) whether the local caching of neighboring RAN nodes of the MN and/or SN can support a PDU session or QoS flow or bearer that is in operation or to be established by the UE. The local cache assistance information also includes an identifier of the corresponding neighbor RAN node if the local cache of the neighbor RAN node can support a PDU session or QoS flow or bearer for the given UE. If the local cache of a neighboring RAN node can support a PDU session or QoS flow or bearer for a given UE, the local cache assistance information also includes an application level classification identification associated with the PDU session or QoS flow or bearer. The local buffer related information may also include application information corresponding to PDU sessions or QoS flows or bearers of the UE, which may be indicated with a granularity per PDU session, or per QoS flow or per bearer. The application information refers to an application level classification identification, for example, an identifier or name of an application, or an identifier or name of an application (or service) provider, or an address (URL or IP address) of an application (or service) provider, or an application server address (URL or IP address), or a content server address (URL or IP address), a content address (URL or IP address), or an APN name or APN address, or a URL (or IP) address of an application. The application information can be carried by using an explicit IE (information element) or contained in a container transparent to the MN.

In the fourth embodiment, referring to inter-MN handoff without SN change, as shown in fig. 11, it is assumed that S-MN (source MN)1120, S-SN (source SN)1130, and T-MN (Target Master Node) 1140 all have local caches. Assume that UE 1110 is DC-configured by the source MN, i.e., UE 1110 is simultaneously connected to S-MN 1120 and S-SN 1130.

In step 1, the S-MN decides to handover the UE to the T-MN based on, for example, a measurement report received from the UE. The S-MN sends a HO request message to the T-MN, which includes local cache assistance information. To assist the T-MN in making appropriate decisions on whether and which traffic of the UE can be accepted and which cannot be accepted, the local cache assistance information may include at least one of: (a) an indication indicating whether the UE is supported by the local caching of the S-MN, and an optional indication indicating whether the UE is supported by the local caching of the S-SN, e.g., a one-bit indication may be used to indicate "with" or "without"; (b) the local cache of the source S-MN and/or the local cache of the S-SN supports the identifier of the UE PDU session or QoS flow or bearer; (c) the amount of data of UE-related traffic data stored in the local cache of the S-MN and/or the local cache of the S-SN, which may be indicated with a granularity per UE, or per PDU session, or per QoS flow or per bearer; (d) application information corresponding to the UE, which may be indicated by granularity per PDU session or per QoS flow or per bearer. The application information refers to an application level classification identification, for example, an identifier or name of an application, or an identifier or name of an application (or service) provider, or an address (URL or IP address) of an application (or service) provider, or an application server address (URL or IP address), or a content server address (URL or IP address), a content address (URL or IP address), or an APN name or APN address, or a URL (or IP) address of an application. The application information may be carried in the message by using an explicit IE (information element) or contained in a container that is transparent to the RAN node.

The local cache assistance information may also include information of content data required by the UE stored in the local cache. This information indicates the cached data in the local cache of the S-MN and/or the local cache of the S-SN, which is associated with the PDU session or QoS flow or bearer of the UE and is currently or subsequently retrieved by the UE. The information may include at least one of: characteristics of the content data, such as name, size, format, date, author, owner, free or charged, etc.; the address of the content data, for example a uniform address such as a URL or a fixed IP address, or an address temporarily assigned by the operator or service provider. The information may be indicated at a granularity per UE or per PDU session, or per QoS flow or per bearer. The information may be provided by a local cache of the S-MN and/or a local cache of the S-SN. The information may be carried in the message by using an explicit IE (information element) or including it in a container that is transparent to the S-MN. Based on this information, the T-MN can check whether its local cache already stores the same content data as the local cache of the S-MN.

The local cache assistance information may also include a last transmission location of the content data that the UE needs from the local cache. This information is used to ensure transmission continuity for the UE. The location also indicates which part of the content data has been successfully sent to the UE and which part has not, based on this information, the local cache of the T-MN knows from which location the data is continuously sent to the UE after the UE handover. The transmission location in the content data may be retrieved from the S-MN 'S local cache and/or the S-SN' S local cache, which may be carried in the message by using an explicit IE (information element) or contained in a container transparent to the S-MN. The local cache assistance information may also include an indication indicating whether the S-SN has local cache support.

In step 2, the T-MN may add the S-SN to attempt to reserve the S-SN for the UE. In the SN addition request message, the T-MN may decide whether to include local cache related information. If the T-MN decides to keep all UE traffic in the S-SN without any changes, the MN need not include local cache related information. If the T-MN decides to offload some UE traffic supported by the S-SN local cache back to the T-MN after HO, the MN may need to include local cache related information, which may include at least one of: (a) the T-MN decides the identifier of the PDU session or QoS flow or bearer of the UE moving back to the T-MN; (b) the indication indicating whether the local cache of the T-MN has cached the same content or data as the indicated S-MN may be indicated with per PDU session, or per QoS flow or per bearer granularity; (c) an available space size of a local cache of the T-MN, which may represent a total available space of the local cache, or may be an available space size that the local cache may allocate to the UE, or an available space size that the local cache may allocate to each PDU session or QoS flow or bearer of the UE; (d) the data forwarding transmission address of the local cache of the T-MN, and the information is used for the S-SN to directly forward the data stored in the local cache to the local cache of the T-MN without passing through the S-SN or the S-MN; (e) the available PDCP buffer size or acceptable amount of data forwarding for a given UE may be achieved without a local cache connected or collocated with the T-MN, or without the second local cache of the T-MN being able to support traffic for the given UE moving from the S-MN to the T-MN.

The local cache related information may optionally include an identifier of the PDU session or QoS flow or bearer that the T-MN decides to move to the UE of the S-SN. The local cache related information may comprise the amount of data of UE related traffic data stored in the S-MN local cache if the T-MN decides to move more traffic to the S-SN. The local cache related information may include application information corresponding to the UE if the T-MN decides to move more traffic to the S-SN. If the T-MN decides to move more traffic to the S-SN, the local cache related information may include information of content data required by the UE stored in the local cache of the S-MN.

In step 3, if the S-SN accepts the SN addition, it sends a response to the T-MN, the response including the radio configuration and optionally including local cache related information. If the T-MN decides not only to move traffic back to certain UEs, but also to offload traffic of certain other UEs to the S-SN, the S-SN may need to include local cache related information, which may include at least one of: (a) an indication indicating whether the local cache of S-SNs caches the same content or data as the indicated S-MN, which indication may be expressed in per PDU session or per QoS flow or per bearer granularity; (b) the size of available space of the local cache of the S-SN; (c) and the locally cached data forwarding transmission address of the S-SN.

In step 4, after receiving the SN addition request Ack from the S-SN, the T-MN may send a HO request Ack to the S-MN to accept the HO request, which may optionally include local cache related information, which may include at least one of: (a) an indication indicating whether the local cache of the T-MN already caches the same content or data as the indicated S-MN; the indication may be indicated with a granularity per PDU session, or per QoS flow or per bearer; (b) the size of available space of a local cache of the T-MN; (c) if the T-MN fails to accept some PDU session or QoS flow or bearer failure reason, such as one of: "no local cache support", "no cache support or incompatibility or traffic not supported by local cache", "cache congestion, overload or insufficiency"; and (d) a locally cached data forwarding transport address for the T-MN. Steps 5 and 6 are performed to release the connection between the S-MN and the S-SN. Steps 7 to 12 are for completing the UE access to the T-MN.

In the fifth embodiment, referring to the gNB composed of the CU and the DU, it is assumed that the local cache is directly connected to the DU. In one example, for a given UE connected to a gNB, the following steps are performed. In step 1, if the DU detects an Adaptive Iterative Learning Control (AILC) bit in the PDCP PDU, which indicates that the PDCP PDU should be delivered to the local buffer instead of the CU, the DU knows which bearer or QoS flow or PDU session the PDCP PDU containing the AILC corresponds to, and then the DU can inform the CU of the identifier of the bearer or QoS flow or PDU session to inform the local buffer which bearer or QoS flow or PDU session is supported. In step 2, depending on the information of which bearer or QoS flow or PDU session is supported by the local cache, the CU may use this information in HO algorithms and SN selection algorithms etc. to find a better target RAN node, e.g. a node that also has a local cache and can support the same service.

In another example, for a given UE connected to the gNB, the following steps are performed. In step 1, the DU may obtain information related to the local cache from the connected local cache by implementing the local cache. The local cache related information may comprise at least one of: (a) whether the DU has local cache support, which may be a simple indication, such as one bit; (b) an identifier of the local cache (if local caching is supported); (c) and indicating a service information list of which services are supported by the local cache. The service information may be constructed by one of the following types: an identifier of a PDU session or QoS flow or bearer for a given UE; generic identification of the upper levels of supported services, such as signaling, data, MT (mobile terminal), emergency, high priority access; QoS level class identifiers that may be used, for example, 3GPP defined QoS classes such as QCI defined in TS23.401 or 5QI defined in TS 23.501; locally caching supported network slice identifiers; the application level classification identifies, for example, an identifier or name of an application, or an identifier or name of an application (or service) provider, or an address (URL or IP address) of an application (or service) provider, or an application server address (URL or IP address), or a content server address (URL or IP address), a content address (URL or IP address), or an APN name or APN address, or a URL (or IP) address of a list of locally cached supported applications.

The local cache related information may include: and the data volume of the UE related service data stored in the local cache. The number may be indicated with a granularity per UE, or per PDU session, or per QoS flow or per bearer. The local cache related information may include: the information of the content data required by the UE, which is stored in the local cache, may include: characteristics of the content data, such as name, size, format, date, author, owner, free or charged, etc.; the address of the content data, for example a uniform address such as a URL or a fixed IP address, or an address temporarily assigned by the operator or service provider. The local cache related information may comprise at least one of: the size of the available space of the local cache; and a locally cached data forwarding transport address.

In step 2, based on the information, the CU can use this information in HO algorithms and SN selection algorithms etc. to find better target RAN nodes, e.g. nodes that also have local caches and can support the same traffic. In the above example of the fifth embodiment, the message sent by the DU to the CU may be: notification message, UE content establishment response message, UE content modification required message, and the like.

In the sixth embodiment, as shown in fig. 12, a separate gNB 1220 connected to a 5GC is provided for a UE1210 connected to the gNB 1220. In the case where the gNB 1220 is deployed with a local cache, the gNB 1220 may obtain local cache related information from the CN 1230.

As shown in fig. 12, in step 1, when the UE requests traffic, it sends a NAS message to the CN, which is transparently relayed by the gNB. In step 2, if the CN allows the UE to request the service, the CN sends a UE initial content establishment request message to the gNB to establish the UE content, wherein if the CN knows that the gNB deploys the local cache, the CN may optionally include local cache related information. The local cache related information may include at least one of: (a) an identifier of the local cache; (b) and indicating a service information list of which services are supported by the local cache. The service information may be constructed by one of the following types: an identifier of a PDU session or QoS flow or bearer for a given UE; generic identification of the upper levels of supported services, such as signaling, data, MT (mobile terminal), emergency, high priority access; QoS level class identifiers that may be used, for example, 3GPP defined QoS classes such as QCI defined in TS23.401 or 5QI defined in TS 23.501; locally caching supported network slice identifiers; the application level classification identifies, for example, an identifier or name of an application, or an identifier or name of an application (or service) provider, or an address (URL or IP address) of an application (or service) provider, or an application server address (URL or IP address), or a content server address (URL or IP address), a content address (URL or IP address), or an APN name or APN address, or a URL (or IP) address of a list of locally cached supported applications.

The local caching related information may include which PDU sessions or QoS flows or bearers of a given UE may be supported by the local caching of the neighbor RAN nodes. The local cache related information also includes an identifier of the corresponding neighbor RAN node if the local cache of the neighbor RAN node can support a PDU session or QoS flow or bearer of the given UE. If the local cache of a neighboring RAN node can support a PDU session or QoS flow or bearer for a given UE, the local cache related information also includes an application level classification identification associated with the PDU session or QoS flow or bearer.

In step 3, the gNB sends an RRC reconfiguration including configuration information of the established PDU session and bearer. In step 4, if the UE wants to trigger a new PDU session setup, it may send a PDU session setup request message to the CN. In step 5, upon UE request, the CN sends a PDU session setup request message to the gNB, in which message the CN may optionally include local cache related information if it has not previously sent it. In step 6, the gNB sends RRC reconfiguration including configuration information of the newly established PDU session and bearer.

In addition, the CN may also pass local cache related information to the gNB by using other messages between the CN and the gNB, such as: UE content modification request, PDU session resource modification request, handover command, handover request, path handover request acknowledgement, downlink RAN state transmission, NG establishment response, RAN configuration update acknowledgement, AMF configuration update, etc.

In a seventh embodiment, in case the UE knows that the traffic gNB or the local cache of the eNB supports some ongoing traffic, and that the cached data is not delay sensitive and not needed by the user now, the UE may choose to send assistance information to the traffic RAN node, so that the downlink data transmission of the data stored in the local cache for the UE may be delayed or re-sent.

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

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 limitation. Likewise, the various figures may depict example architectures or configurations provided to enable one of ordinary skill in the art to understand the example features and functionality of the present disclosure. However, those skilled in the art will appreciate that the present disclosure is not limited to the example architectures or configurations shown, but may be implemented using a variety of alternative architectures and configurations. In addition, as one of ordinary skill in the art will appreciate, one or more features of one embodiment may 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 will also be understood that any reference herein to elements using a name such as "first," "second," etc., does not generally limit the number or order of those elements. Rather, these names may be used herein as a convenient means of distinguishing between two or more elements or instances of an element. Thus, reference to first and second elements does not imply that only two elements can be used or that the first element must somehow be positioned before the second element.

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

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

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 as a combination of such technologies, depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure. According to various embodiments, a processor, device, component, circuit, structure, machine, module, etc. may be configured to perform one or more of the functions described herein. The terms "configured to" or "configured to" as used herein with respect to a particular operation or function refer 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, those of ordinary skill in the art will appreciate that the various illustrative logical blocks, modules, devices, components, and circuits described herein may be implemented or performed with Integrated Circuits (ICs) including general purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or other programmable logic devices, or any combination thereof. The logic blocks, modules and circuits may further include antennas and/or transceivers to communicate with various components within the network or within the device. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller or state machine. A processor may 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 may be stored as one or more instructions or code on a computer-readable medium. Thus, the steps of a method or algorithm disclosed herein may 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 cause a computer program or code to be transferred from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise 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.

As used herein, the term "module" refers to software, firmware, hardware, and any combination of these elements to perform the relevant functions described herein. In addition, for purposes of discussion, the various modules are described as discrete modules; however, it will be apparent to those of ordinary skill in the art that two or more modules may be combined to form a single module that performs the relevant functions according to embodiments of the present disclosure.

Additionally, memory or other storage and communication components may be employed in embodiments of the present disclosure. It will be appreciated that the above description for clarity has described embodiments of the 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 departing from the disclosure. For example, functionality illustrated to be performed by separate processing logic elements or controllers may be performed by the same processing logic elements or controllers. Thus, references to specific functional units are only to references to suitable means for providing the described functionality rather than indicative of a strict logical or physical structure or organization.

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

Claims

1. 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 of a first local cache associated with the first wireless communication node, wherein the first local cache is to support at least one service in the first wireless communication node.

2. The method of claim 1, wherein the first cache-related information comprises information of at least one of: an identifier of the first local cache; and indication information indicating whether the first wireless communication node has local caching support.

3. The method of claim 1, wherein the first cache-related information comprises: indication information indicating whether the first local cache is shared by the first wireless communication node and the second wireless communication node.

4. The method of claim 1, wherein the first cache-related information comprises: the first local cache stores information of a service information list of which services are supported.

5. The method according to claim 4, wherein the service information list is described by one of the following types:

the first local cache supports a classification identifier of an upper level of each service;

the QoS (quality of service) grade classification identifier of each service supported by the first local cache;

a network slice identifier supported by the first local cache;

the first local cache supports an application level classification identifier.

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

7. The method of claim 1, wherein the first wireless communication node comprises at least one of:

a source radio access network, RAN, node for use in a handover procedure of a given wireless communication device, wherein the second wireless communication node is a target RAN node in the handover procedure;

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

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.

8. The method of claim 1, wherein the first cache-related information comprises information of at least one of:

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

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

an indication indicating whether the secondary node has local cache support.

9. The method of claim 1, wherein the first cache-related information comprises information of at least one of:

the first local cache supports a first identifier for each service of a given wireless communication device, wherein the first identifier identifies at least one of: protocol data unit PDU session, quality of service QoS flow and bearer; and

a second identifier for each traffic of the given wireless communication device supported by the second local cache, wherein the second identifier identifies at least one of: PDU session, QoS flow and bearer.

10. The method of claim 1, wherein the first cache-related information comprises information of at least one of:

a first amount of data of traffic data associated with a given wireless communication device in the first local cache, wherein the first amount of data is indicated based on at least one of the following granularities: each user equipment UE, each PDU session, each QoS flow, and each bearer; and

a second amount of traffic data associated with the given wireless communication device in the second local cache, wherein the second amount of data is indicated based on at least one of the following granularities: per UE, per PDU session, per QoS flow, and per bearer.

11. The method of claim 1, wherein the first cache-related information comprises: application information corresponding to a given wireless communication device, wherein the application information is indicated based on at least one of the following granularities: per UE, per PDU session, per QoS flow, and per bearer.

12. The method of claim 1, wherein the first cache-related information comprises information of at least one of:

information of first content data required by a given wireless communication device and stored in the first local cache, wherein the information of the first content data comprises: at least one of a characteristic and an address of the first content data, and is indicated based on at least one of the following granularities: 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 a characteristic and an address of the second content data, and is indicated based on at least one of the following granularities: per UE, per PDU session, per QoS flow, and per bearer.

13. The method of claim 12, wherein the first cache-related information further comprises information of at least one of:

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.

14. The method of claim 1, further comprising:

second cache related information is received from the second wireless communication node, wherein the second cache related information comprises second locally cached information associated with the second wireless communication node.

15. The method of claim 14, wherein the second cache-related information comprises information of at least one of:

an available space size of the second local cache;

the data forwarding transmission address of the second local cache;

an available buffer size or an acceptable amount of data for data forwarding for a given communication device without a second local cache associated with the second wireless communication node or the second local cache being unable to support traffic for the given communication device.

16. The method of claim 14, wherein the second cache related information comprises indication information indicating whether the second local cache has cached the same data as the first local cache for a given communication device.

17. The method of claim 14, wherein the second cache-related information comprises: information for rejecting an indication of at least one reason for a request from the first wireless communication node.

18. The method of claim 17, wherein the at least one cause comprises one of:

the second wireless communication node has no local cache support;

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

the second local cache is congested;

the second local cache is overloaded;

the second local cache does not have sufficient available space, wherein at least one of the reasons is indicated with at least one of the following granularities: per UE, per PDU session, per QoS flow, and per bearer.

19. 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 of a local cache associated with the second wireless communication node, wherein the local cache is to support at least one service in the second wireless communication node.

20. The method of claim 19, wherein the first wireless communication node comprises 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 said second wireless communication node is a distributed unit DU.

21. The method of claim 19, wherein the cache related information relates to a given wireless communication device and comprises information relating to at least one of:

a first indication indicating whether the local cache supports traffic for the given wireless communication device, wherein the first indication is based on at least one of the following granularities: each protocol data unit PDU session, each quality of service QoS flow, each bearer;

a second indication indicating whether a local cache of a neighbor node of the second wireless communication node supports traffic for the given wireless communication device, wherein the second indication is based on at least one of the following granularities: per PDU session, per QoS flow, per bearer; and

locally caching identifiers of neighbor nodes that support at least one of the services of the given wireless communication device.

22. The method of claim 19, wherein the cache related information relates to a given wireless communication device and comprises application information corresponding to the given wireless communication device, wherein the application information is indicated based on at least one of the following granularities: per PDU session, per QoS flow and per bearer.

23. The method of claim 19, wherein the cache related information relates to neighboring communication nodes of the second wireless communication node and comprises information of at least one of:

a first list of identifiers, wherein the first list of identifiers is to indicate a first set of neighboring communication nodes, and each neighboring communication node in the first set of neighboring communication nodes is associated with a local cache; and

a second list of identifiers, wherein the second list of identifiers is to indicate a second set of neighboring communication nodes, and each neighboring communication node in the second set of neighboring communication nodes is associated with a local cache that supports the same traffic as and associated with the second wireless communication node.

24. 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 buffer-related information indicates that downlink data transmission for the UE may be delayed.

25. The method of claim 24, wherein the cache-related information comprises information of at least one of:

an indication that transmission of pending data in the local cache may be delayed;

an indication that transmission of data buffered in the second wireless communication node may be delayed;

a first identifier for each delayed service, the first identifier identifying at least one of: PDU session, QoS flow and bearer; and

a delay time window during which the second wireless communication node may cease the downlink data transmission to the UE.

26. The method of claim 24, wherein the cache-related information comprises information of at least one of:

an indication that transmission of pending data in the local cache may be sent again;

an indication that a transmission of data buffered in the second wireless communication node may be sent again; and

retransmitting a second identifier for each service, wherein the second identifier identifies at least one of: PDU session, QoS flow and bearer.

27. The method of claim 24, wherein caching the relevant information comprises: information of a third identifier of a PDU session, QoS flow or bearer supported by the local cache is required.

28. 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 of a local cache associated with the wireless communication node, wherein the local cache is to support at least one service in the wireless communication node.

29. 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

30. The method of claim 29, wherein the cache-related information comprises information of at least one of:

an indication that transmission of data buffered in the wireless communication node may be delayed;

a delay time window during which the wireless communication node may cease the downlink data transmission to the UE.

31. The method of claim 29, wherein the cache-related information comprises information of at least one of:

an indication that a transmission of data buffered in the wireless communication node may be sent again; and

32. The method of claim 29, wherein caching the relevant information comprises: information of a third identifier of a PDU session, QoS flow or bearer supported by the local cache is required.

33. A wireless communication node, characterized in that the wireless communication node is configured to perform the method of any of claims 1 to 32.

34. A non-transitory computer readable medium having stored thereon computer executable instructions for performing the method of any one of claims 1 to 32.