CN112703766B

CN112703766B - Method performed by a wireless communication node, wireless communication node

Info

Publication number: CN112703766B
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: 2023-07-14
Anticipated expiration: 2038-08-09
Also published as: CN112703766A; WO2020029167A1

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 for supporting at least one service in the first wireless communication node.

Description

Method performed by a wireless communication node, wireless communication node

Technical Field

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

Background

Fourth generation mobile communication technology (4G) Long Term Evolution (LTE for short) or LTE-advanced (LTE-a) and fifth generation mobile communication technology (5G) are facing increasing demands. Based on current trends, 4G and 5G systems are developing support for enhanced mobile broadband (enhanced mobile broadband, eMBB for short), ultra-reliable low-latency communication (Super reliable low delay communication, URLLC for short), and large-scale machine type communication (Max Machine Type Communication, mctc for short) functions.

In order to support the characteristics 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 is often needed or accessed by many users to provide low latency services to the users. When the conventional cache is located at a Core Network (CN) end of a wireless communication system, the local cache is introduced as a radio access Network (Radio Access Network, RAN) element into an evolved packet Core (Packet Switched Core, EPC) Network structure, and is used for caching traffic data with the same content but required by a large number of users. Deploying local caches 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 the content of different applications. Thus, the 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. While the RAN node may require locally cached deployment and/or functional information to help improve UE mobility and multi-connection performance, existing approaches fail to meet this need through local cache management. Local caching is not entirely satisfactory.

Disclosure of Invention

The exemplary embodiments disclosed herein are directed to solving problems associated with one or more of the problems set forth in the prior art, and will provide additional features that are readily appreciated by reference to the following detailed description when taken in conjunction with the accompanying drawings. According to various embodiments, exemplary systems, methods, apparatus, and computer program products are disclosed herein. However, it should be understood that these embodiments are given by way of example and not limitation, and that various modifications of the disclosed embodiments may be made apparent to persons of ordinary skill 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 for supporting at least one service in the first wireless communication node.

In another embodiment, a method performed by a first wireless communication node is disclosed. The method comprises the following steps: transmitting cache-related information to the second wireless communication node, wherein the cache-related information comprises: and locally cached information associated with the second wireless communication node, wherein the local cache is for supporting at least one service in the second wireless communication node.

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

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

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 illustrative purposes only and depict only exemplary embodiments of the disclosure to facilitate the reader's understanding of the disclosure. Accordingly, the drawings should not be taken as limiting 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 made to scale.

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

FIG. 2 illustrates an exemplary Dual Connectivity (DC) system in which the techniques disclosed herein may be implemented, according to an embodiment of the present disclosure;

fig. 3 illustrates a block diagram of a Base Station (BS) according to some embodiments of the present disclosure;

fig. 4 illustrates a flowchart of a method performed by a BS for managing local caches, according to some embodiments of the present disclosure;

fig. 5 illustrates a block diagram of a User Equipment (UE) in accordance with some embodiments of the present disclosure;

fig. 6 illustrates a flow chart of a method performed by a UE to help manage local caching in accordance with some embodiments of the present disclosure;

fig. 7A illustrates an exemplary deployment of local caches associated with BSs according to some embodiments of the present disclosure;

fig. 7B illustrates another exemplary deployment of local caches associated with BSs according to some embodiments of the present disclosure;

fig. 8 illustrates an exemplary process diagram for exchanging local cache-related information between two wireless communication nodes according to some embodiments of the present disclosure;

fig. 9 illustrates an exemplary process diagram for exchanging local cache-related information between wireless communication nodes for handoff in accordance with some embodiments of the present disclosure;

fig. 10 illustrates an exemplary process diagram for 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 for exchanging local cache-related information between wireless communication nodes for a handoff of a primary node having a secondary node in accordance with some embodiments of the present disclosure;

fig. 12 illustrates another exemplary process diagram for exchanging local cache-related information between wireless communication nodes according to some embodiments of the present disclosure.

Detailed Description

Various exemplary embodiments of the present 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 after reading this disclosure that various changes or modifications can be made to the examples described herein without departing from the scope of the disclosure. Thus, the disclosure is not limited to the exemplary embodiments and applications described and illustrated herein. In addition, the particular order or hierarchy of steps in the methods disclosed herein is only an exemplary approach. Based on 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, those of ordinary skill in the art will understand that the methods and/or techniques disclosed herein present various steps or acts in an example order, and that the present disclosure is not limited to the particular order or hierarchy presented, unless specifically stated otherwise.

A typical wireless communication network includes one or more Base Stations (BSs) that each provide geographical 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 a downlink radio frame from the BS to the UE, or via an uplink radio frame from the UE to the BS.

The present disclosure provides methods, apparatus, and systems for managing local caches of wireless communication nodes to ensure smooth communication of UEs, 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 storing 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, dual-Connectivity (DC) to Multi-Connectivity (MC), secondary nodes may be added or modified to serve the same UE with multiple BSs. Because the original BS, referred to as the master node, may have a local cache storing information related to the current data session, the master node may send local cache related information associated with the master node to the slave node in order to ensure a smooth process of addition or modification by the slave 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 (Radio Access Network, RAN) node may receive information about a local cache associated with a Core Network (CN) node from the RAN node. In another embodiment, the UE may send local cache related information to the BS informing the BS that some data transmissions of the UE may be delayed or re-sent.

In various embodiments, a BS may be referred to as a network-side node, and may include or be implemented as: the UEs in the present disclosure may be referred to as terminals and may include or be implemented as Mobile Stations (MSs), stations (STAs), etc., BS and UEs may be described herein as non-limiting examples of "wireless communication nodes", and UEs may be described herein as non-limiting examples of "wireless communication devices".

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 present disclosure. In fig. 1, 5gc 110 refers to the core network of a 5G network. The lower part of fig. 1 shows a 5G radio access network (NG-RAN) 120, which is referred to as a 5G new radio access technology (Radio Access Technology, RAT for short) 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 an NG interface. Each gNB is a base station of a 5G RAN. The gNB may support frequency division duplexing (Frequency Division Duplex, abbreviated FDD) mode, time division duplexing (Time Division Duplex, abbreviated TDD) mode, and/or dual connectivity mode operation. A set 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 Unit), which are connected by an F1 interface.

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

In fig. 1, the gNB 121 is not split into CUs and DUs, while the gNB 122 is split into CUs and DUs. The decision whether to split the gNB depends on the network deployment requirements of the operator. Examples of the partitioning of CU and DU functions in the protocol stack are that a CU may include radio resource control (Radio Resource Control, abbreviated RRC) and packet data convergence protocol layer (Packet Data Convergence Protocol, abbreviated PDCP) functions, while a DU may include radio link control (Radio Link Control, abbreviated RLC), medium access control (Media Access Control, abbreviated MAC) and Physical (PHY) functions.

Fig. 2 illustrates an exemplary Dual Connectivity (DC) system 200 in which the techniques disclosed herein may be implemented, according to an embodiment of the present disclosure. The DC architecture 200 may be part of an NR system. As shown in fig. 2, DC system 200 may include two (or more) network-side nodes (first network node 222 and second network node 224) that provide data connections to and from a UE (e.g., UE 230). For example, the 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 current serving base station of the UE in the ng-RAN (e.g., the first network node 222 in fig. 2) 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, e.g. 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. Furthermore, for a wired interface, a first NG control plane (NG-C) may be established between the first Network node 222 and the Next Generation-Core Network (NG-CN) 210, and for the UE 230, NG-U may be established between the second Network node 224 and the NG-CN 210 at most. The first network node (First Network Node, abbreviated FNN) 222 and the second network node 224 may be connected by an ideal or non-ideal interface called an Xn interface.

In terms of the wireless interface, the first network node 222 and the second network node 224 may provide the same or different radio access technologies (Radio Access Technology, abbreviated RATs) 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 a user plane connection even though in some cases there may be no user plane connection with 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 referred to as secondary nodes.

Based on the Dual-Connectivity (DC) concept described above, the multi-RAT Dual-Connectivity refers to a Dual-Connectivity architecture, in which the primary node and the secondary node 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 the other 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 at the same time. In another example, the dual connectivity scenario may include both the primary node and the secondary node as NR RAN nodes (e.g., gnbs). Similar to dual connectivity, MC (multi-connectivity) may be implemented when the capability of the UE meets the requirements, 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 structure.

Fig. 3 illustrates a block diagram of a Base Station (BS) 300, according to 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, 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, the system clock 302 provides a timing signal to the processor 304 for controlling the timing of all operations of the BS 300. The processor 304 controls the overall operation of the BS 300 and may include one or more processing circuits or modules, such as a central processing unit (Central Processing Unit, abbreviated as CPU) and/or general purpose microprocessor, microcontroller, digital signal processor (Digital Signal Processor, abbreviated as DSP), field programmable gate array (Field Programable Gate Array, abbreviated as FPGA), programmable logic device (Programmable logic device, abbreviated as PLD), controller, state machine, gating logic, discrete hardware components, any combination of special-purpose hardware finite state machines, or any other suitable circuit, device, and/or structure that can perform computation or other manipulation of data.

Memory 306, which may include Read Only Memory (ROM) and random access Memory (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 (Non-Volatile Random Access Memory, simply referred to as NVRAM). The processor 304 typically performs logical and arithmetic operations based on program instructions stored within the memory 306. The instructions (also referred to as software) stored in memory 306 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, whether referred to as software, firmware, middleware, microcode, etc., the "software" refers to any type of instructions that can configure a machine or device to perform one or more desired functions or procedures. The instructions may include code (e.g., in a source code format, a binary code format, an 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.

Transceiver 310, which includes transmitter 312 and receiver 314, allows BS 300 to transmit data to and receive data from a remote device (e.g., another BS or UE). An antenna 350 is typically attached to the housing 340 and electrically coupled to the transceiver 310. In various embodiments, BS 300 includes (not shown) a plurality of transmitters, a plurality of receivers, and a plurality of transceivers. In one embodiment, antenna 350 is replaced with a multi-antenna array 350 (which may form multiple beams, each beam pointing in a different direction). Transmitter 312 may be used to wirelessly transmit packets having different packet types or functions, such packets being generated by processor 304. Similarly, receiver 314 is configured to receive packets having different packet types or functions and processor 304 is configured 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 a BS 300 serving a UE, the BS 300 may provide information about its local cache in order to ensure seamless handover or secondary node addition. In one embodiment, the cache related information generator 320 may generate and transmit the first cache 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 the BS 300.

In one embodiment, during a handover of a given UE, BS 300 is a source Radio Access Network (RAN) node, and during the handover, the second BS is a target RAN node. In one embodiment, BS 300 is the primary RAN node for a given UE in a dual or multiple connection, while the second BS is the secondary RAN node in a dual or multiple connection. In one embodiment, BS 300 is a Distributed Unit (DU) and the second BS is a Centralized Unit (CU). In one embodiment, 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 includes 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 upper classification identifier of each service supported by the first local cache; a quality of service (Quality of Service, abbreviated QoS) level class classification identifier for each service supported by the first local cache; a network slice identifier supported by the first local cache; and an application level class identification supported by the first local cache. According to various embodiments, in the inter-node interface establishment procedure between the BS 300 and the second BS, the first cache related information is carried by at least one of the interface establishment request message and the interface establishment response message.

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 includes information about at least one of: an indication indicating whether the first local cache supports a given UE; a first identifier for each service of a given UE supported by a first local cache; a first amount of traffic data associated with a given UE in a first local cache; application information corresponding to a given UE; information of first content data required by a given 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 (Protocol data unit, abbreviated PDU) session, quality of service (Quality of Service, abbreviated QoS) flow and bearer. The first data amount and the application information are indicated with at least one of the following granularity: each UE, each PDU session, each QoS flow, and each 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 granularity of: each UE, each PDU session, each QoS flow, and each bearer.

In this example, when the BS 300 serves as a master node for 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 includes information about at least one of: an indication to indicate whether a given UE is supported by a second local cache of the secondary node; an indication to indicate whether the secondary node has local cache support; a second identifier for each service of a given UE supported by a second local cache; a second amount of traffic data associated with the given UE in a second local cache; information of second content data information required by the given UE and stored in the second local cache; and a last transmission location of the second content data in the second local cache. 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 flows and bearers. The second amount of data is indicated with at least one of the following granularity: each UE, each PDU session, each QoS flow, and each 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 granularity of: each UE, each PDU session, each QoS flow, and each bearer.

In this example, the cache related information analyzer 324 may receive and analyze the second cache related information from the second BS. In one embodiment, the second cache related information includes information about a second local cache associated with the second BS. In one embodiment, the second cache-related information includes information about at least one of: the size of the available space of the second local cache; the second locally cached data forwarding transport address; in the absence of a second local buffer associated with the second BS or the inability of the second local buffer to support traffic for a given UE moving from BS 300, the buffer size available for the given UE or the acceptable amount of data for data forwarding; an indication to indicate whether the second local buffer has buffered the same data as the first local buffer for a given UE; and at least one indication of a reason for rejecting the request from the BS 300. At least one reason may be one of: the second BS does not support local caching; the second local cache does not support the service requested by BS 300; second local cache congestion; the second local buffer is overloaded; or the second local cache does not have enough space available. At least one of the above reasons is indicated by at least one of the following particle sizes: each UE, each PDU session, each QoS flow, and each bearer.

In another embodiment, the cache related information generator 320 may generate and transmit the cache related information to the second BS via the transmitter 312. The cache related information may include information about a local cache associated with the second BS. The local buffer 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, BS 300 is a Centralized Unit (CU) and the second BS is a Distributed Unit (DU). Based on the UE traffic information provided by the user equipment traffic manager 322, the cache related information generated by the cache related information generator 320 may be related to a given UE and include information regarding at least one of: a first indication for indicating whether the local cache supports traffic of the given UE, a second indication for indicating whether the local cache of the neighbor node of the second BS supports traffic of the given UE; the identifier of a neighbor node whose local cache supports at least one service of the given UE, and application information corresponding to the given UE. The first indication, the second indication and/or the application information have at least one granularity of: each PDU session, each QoS flow, each bearer. In one example, the cache-related information relates to a neighbor communication node of the second BS and includes information about at least one of: a first list of identifiers indicating a first set of neighbor communication nodes (each associated with a local cache); and a second list of identifiers indicating a second set of neighbor communication nodes (each associated with a local cache supporting the same traffic as the local cache associated with the second BS).

In various embodiments, the cache-related information analyzer 324 receives cache-related information from UEs served by the BS 300 and analyzes the information. The cache-related information includes information about a local cache associated with BS 300. The local buffer 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 re-sent. In one example, the cache-related information includes information about at least one of: an indication that transmission of data to be processed in the local cache may be delayed; an indication indicating 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 flows and bearers; 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 includes information related 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 the data buffered in the BS 300 can be retransmitted; and resending a second identifier for each service, wherein the second identifier identifies at least one of: PDU session, qoS flows and bearers. In yet another example, the cache related information further includes information about a third identifier of a PDU session, qoS flow, or bearer that needs to be supported by the local cache.

The power module 308 may include a power source, such as one or more batteries, and a power source regulator to provide regulated power to each of the above-described 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, bus system 330 may include a data bus, as well as a power bus, control signal bus, and/or status signal bus other than 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 plurality 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 implemented in combination or jointly. For example, the processor 304 may implement not only the functions described above with respect to the processor 304, but also the functions 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 chart of a method 400 performed by a BS (e.g., BS 300 in fig. 3) for managing local caches, according to some embodiments of the present disclosure. In operation 402, the bs obtains service information related to the user equipment. Optionally, the bs obtains cache-related information about the associated secondary node in operation 404. In operation 406, the bs generates relevant information for handover or secondary node added buffering. In operation 408, the bs transmits the generated cached related information to the receiving node. In operation 410, the bs receives and analyzes the buffered related information from the receiving node.

Fig. 5 illustrates a block diagram of a User Equipment (UE) 500 according to 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 cache related information generator 520, and a data priority determiner 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. The antenna 550 or multiple antenna array 550 is typically attached to the housing 440 and electrically coupled to the transceiver 510.

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

In this example, the data priority determiner 522 may determine priority information of 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 the cache related information. In one example, the cache-related information includes information about at least one of: an indication that transmission of data to be processed 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 flows and bearers; and a delay time window during which the BS may stop data transmission to the UE. In another example, the cache-related information includes information related 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 retransmitted; and resending a second identifier for each service, wherein the second identifier identifies at least one of: PDU session, qoS flows and bearers. In yet another example, the cache related information includes information about a third identifier of a PDU session, qoS flow, or bearer that needs to be supported by the local cache.

The various modules discussed above are coupled together by a bus system 530. For example, bus system 530 may include a data bus, such 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 the UE 500 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. 5, one of ordinary skill in the art will appreciate that one or more of the modules may be implemented in combination or jointly. For example, the processor 504 may implement not only the functions described above with respect to the processor 504, but also the functions 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 chart of a method 600 performed by a UE (e.g., UE 500 in fig. 5) to facilitate managing local caches, according to some embodiments of the present disclosure. In operation 602, the UE determines priority information of 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 cached related information based on the identified data and traffic. In operation 608, the UE transmits the generated cached 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 features of the embodiments and examples in this 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 network (Packet Switched Core, abbreviated EPC) network architecture to cache traffic data of the same content but required by many users. Deploying local caches at the RAN level may reduce latency and reduce CN overhead.

Fig. 7A illustrates an exemplary deployment 710 of local caches 716 associated with BSs 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 local cache 726 associated with BS 725, according to some embodiments of the disclosure. In the exemplary deployment 720, the local buffer 726 is indirectly connected to the eNB 725, and the eNB 725 communicates with the UE 721 and the SGW 728.

In the first case, before triggering Handover (HO) or Secondary Node (SN) addition, the source network node needs to know about the local cache deployment of the neighbor network node in advance, and if a given UE needs to add HO or SN, the source network node can be assisted in selecting a more appropriate target node.

In a first exemplary solution, a first network node provides a second network node with local cache of connections (i.e., local cache connected to or collocated with the first network node) assistance information. The local cache assistance 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, for example to check if the second network node shares the same local cache with 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 further comprise an indication of whether the first network node shares the same local cache as 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 cache assistance information may also include an indication of whether the first network node has local cache support (e.g., at least one local cache server is directly or indirectly connected to or collocated with the first network node). The indication may be a simple indication, e.g. a bit.

The local cache assistance information may also include a list of traffic information to indicate which traffic is 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 traffic information may be constructed from one of the following types: the upper classification identifiers of the supported services, such as signaling, data, MT (Mobile Terminal), emergency, high priority access; qoS class identification that may be used, e.g., a QoS class defined by the third generation partnership project (3 rd Generation Partnership Project, abbreviated as 3 GPP), such as QCI defined in TS23.401 or 5QI defined in TS 23.501; locally caching supported network slice identifiers; application level class identification, for example, an identifier or name of an application, or an identifier or 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 (Access Point Name, abbreviated as APN) or APN address, or a URL (or IP) address of a list of locally cached supported applications.

The local cache auxiliary information may be carried in an inter-node interface establishment procedure. For example, it may be carried in an X2 or Xn interface setup request message or in an X2 or Xn interface setup response message during the setup procedure between the first network node and the second network node. 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 an X2 interface; in the case of two NR RAN nodes, or one LTE RAN node and one NR (New RAT) RAN node, both connected to the NGC core network, the inter-node interface may be referred to as an Xn interface.

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

In the second case, the service node decides to establish a dual connection to serve the UE when a handover of a given UE is triggered (e.g., when the UE moves out of the current service network node), or when an addition, modification or change procedure of SN (secondary node) is triggered for a given UE (e.g., when the UE's traffic requires a large throughput, while the current service network node cannot meet QoS).

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

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

The local cache auxiliary information may further include: the local cache of the first network node may support an identifier of a PDU session or QoS flow or bearer of said UE and optionally including an identifier of a PDU session or QoS flow or bearer of said UE that the local cache of the SN may support in case the UE is configured with the MC by the first network node and the SN also has a local cache.

The local cache auxiliary information may further include: the first network node locally caches a data amount of UE-associated traffic data stored in the first network node, and optionally includes a data amount of UE-associated traffic data stored in the local cache of the SN in case the UE is configured with the MC by the first network node and the SN also has 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 auxiliary information may further include: application information corresponding to the UE that may be represented with granularity per PDU session, or per QoS flow, or per bearer. Application information refers to an application level class 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 it may be contained in a container transparent to the network node.

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

The local cache auxiliary information may further include: information of content data required for the UE stored in the local cache. This information indicates cached data in the local cache of the first node and/or the local cache of the SN (in case the MC is configured and the SN also has a local cache), which data is associated with the PDU session or QoS flow or bearer of the UE and is currently or subsequently acquired by the UE. The information may include at least one of: characteristics of the content data such as name, size, format, date, author, owner, whether free or not, 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 carrier or service provider. The information may be indicated at a granularity of per UE or per PDU session, or per QoS flow or per bearer. The information may be provided by the first network node local cache and/or the 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 transparent to the network node. Based on this information, the second network node may check whether its local cache has already stored the same content data as the local cache of the first network node.

The local cache auxiliary information may further include: the UE is from the last transmission location of the content data needed in the local cache. This information is used to ensure the transmission continuity of the UE. The location also indicates which part of the content data has been successfully transmitted to the UE and which part has not been successfully transmitted. Based on this information, the second node cache knows from which location data is continuously sent to the UE. The transmission location in the content may be obtained from the first node's local cache and/or the SN's 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 (Information element, abbreviated IE) or contained in a container transparent to the network node.

The local cache auxiliary information may further include: an indication indicating whether the SN has local cache support in case the first network node configures the MC for the 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 related to the SN local buffering of the given UE if the SN can be reserved after the handover. The local cache auxiliary information may be carried in a request message sent by the first network node, for example, 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 including the 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 the 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 available space size of the local cache of the second network node. The available space size may represent the total available space of the local buffer, or may represent the available space size that the local buffer may allocate to the UE, or may represent the available space size that the local buffer may allocate for each PDU session or QoS flow or bearer of the UE.

If the second network node cannot accept the request from the first network node or only part of the request 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 in the response to the first network node the reason in the local cache related information. The reasons may include at least one of: "no local cache support": indicating that the second node has no local cache; "cache not supported or incompatible, or local cache not supporting traffic": 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 indicated in granularity per UE or per PDU session, or per QoS flow or per bearer; "cache congestion or overload or shortage": the second node is instructed to have a local buffer, but the buffer is full or there is insufficient space available, which can be expressed in terms of granularity per UE or per PDU session or per QoS flow or per bearer.

The local cache related information may further include: the data of the local buffer storage of the second node is forwarded to the transmission address. This information is used by the first network node to forward data stored in the local cache directly 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 is unable to support traffic for a given UE moving from the first network node to the second network node, the local cache related information may also include the available packet data convergence protocol Packet Data Convergence Protocol, (abbreviated PDCP) buffer size or acceptable data forwarding data volume for 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 acknowledgement message, a handover preparation failure message, an SN addition request acknowledgement or rejection message, and an SN modification request acknowledgement or rejection message.

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

In the 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 local cache assistance information for a given UE from an auxiliary network node. The local cache assistance information may include at least one of the following.

The local cache auxiliary information may include: whether a local buffer connected to a serving RAN node can support a PDU session or QoS flow or bearer that a given UE is running or is about to establish may be indicated with the granularity of each PDU session or QoS flow or bearer.

The local cache auxiliary information may include: whether a local buffer connected to a neighbor RAN node can support a PDU session or QoS flow or bearer that a given UE is running or is about to establish. The local buffer assistance information further includes an identifier of the corresponding neighbor RAN node if the local buffer 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 neighbor RAN node can support a PDU session or QoS flow or bearer for a given UE, the local cache assistance information further includes an application level classification identification associated with the PDU session or QoS flow or bearer.

The local cache auxiliary information may include: application information corresponding to a PDU session or QoS flow or bearer of the UE, which may be indicated with granularity per PDU session, or per QoS flow or per bearer. Application information refers to an application level class 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 access point name (Access Point Name, abbreviated 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 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 (Mobile Management Entity, abbreviated MME) for the EPC network, a Security GateWay (SGW), an overhead ground wire composite cable (Power Ground Wire, abbreviated PGW); and includes an access management function (Access Management Function, abbreviated as AMF), a service management function (Service Management Function, abbreviated as SMF), an application function (Application Function, abbreviated as AF), a user interface function (User Port Function, abbreviated as UPF) adapted to the 5G core network.

The local cache assistance information for a given UE may be obtained from the CN node in the following procedure: bearer or PDU session establishment or modification procedures; or a path switching program at the time of switching; or a UE content setup procedure.

In another case, the UE may provide assistance information to the network node (serving RAN node), which may delay or resend the downlink data transmission of the UE. This requirement may come from the UE application layer. The auxiliary information includes at least one of: an indication indicating that the transmission of the data to be processed in the local cache may be delayed or may be resent; an indication for indicating the transmission of data that may be delayed or may be resent buffered in the network node. 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 needs to be supported by the local buffer. 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 the first embodiment, as shown in fig. 8, it is assumed that both eNB1 and

eNB2

810 and 820 are connected to the EPC core network. The setup procedure 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 the eNB2 wants to find the target RAN node for the UE handover. The local cache related information added in the X2 setup request may simply comprise an indication of whether the eNB1 has local cache support or not, for example it may be a one-bit indication.

In addition, the eNB1 may also give more detailed information, such as: locally cached identifiers, or if the eNB1 is connected to a plurality of locally cached identifier lists. Furthermore, eNB1 may provide a service information list to indicate the services supported by the local caches, which may make eNB2 or the local caches of eNB2 aware of the differences in the supported services. The service information list may be one of the following types: the upper classification identification of the supported services, such as signaling, data, MT (mobile terminal), emergency, high priority access; qoS class identification that may be used, such as 3GPP defined QoS class; locally caching supported network slice identifiers; application level class identification, for example, an identifier or name of an application, or an identifier or name of an application (or service) provider, or an address of an application (or service) provider (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 APN name or APN address, or a URL (or IP) address of a list of locally cached supported applications. In order 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 buffer to which eNB2 is connected is the same as eNB1, eNB2 may simply add an indication of, for example, one bit in the response message. Otherwise, the eNB2 may include the locally cached identifier in the response message.

Similarly, eNB2 may further include more detailed information (e.g., the service information list in step 1) in the response message to indicate the services supported by the local cache. 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 the eNB or the gNB may initiate an EN-DC X2 interface setup procedure, which further comprises two steps: an EN-DC X2 interface setup request and an EN-DC X2 interface setup response. In this example, it is also suitable to use the above-described embodiment.

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, either the eNB or the gNB may 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 a second embodiment, as shown in fig. 9, it is assumed that the UE 910 transmits a measurement report to a service eNB (e.g., eNB1 920) connected to the EPC, and the eNB1 920 finds that the UE 910 has satisfied the HO condition. The eNB1 920 selects a target RAN node (e.g., eNB2 930) based on the measurement report of the UE and initiates the HO procedure. In some cases, the source and target RAN nodes may also be a gNB connected to the EPC. For EPC networks, CN 940 may represent MME and SGW; for 5gc, cn 940 may represent AMF and SMF.

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

To assist the target eNB in making appropriate decisions as to whether the UE may be accepted and further which traffic and which may not be accepted by the UE, the local cache assistance information may include at least one of the following.

The local cache auxiliary information may include: an indication indicating whether the local buffer of the source eNB1 supports UEs, e.g. a one bit indication may be used to indicate "there is" or "there is". The local cache auxiliary information may include: the local buffer of the source eNB1 supports PDU session identifiers or QoS flows or bearers of the UE. The local cache auxiliary information may include: the amount of UE-related traffic data stored in the local buffer 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 cache auxiliary information may further include: application information corresponding to UEs that may be represented with granularity per PDU session, or per QoS flow, or per bearer. Application information refers to an application level class 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 it may be contained in a container transparent to the RAN node.

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

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

The local cache auxiliary information may include: the UE is from the last transmission location of the content data needed in the local cache. This information is used to ensure the transmission continuity of the UE. The location also indicates which parts of the content data have been successfully transmitted to the UE and which parts have not been successfully transmitted, based on which information the local cache of the target eNB2 knows from which location to continuously transmit data to the UE after the UE has switched from eNB1 to eNB 2. The transmission location in the content data may be obtained from a local cache of the source eNB 1. It may be carried in the message by using an explicit IE (information element) or contained in a container transparent to the eNB.

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

In step 3, based on the local cache related information sent from the source eNB1 920, the eNB2 930 may decide whether handover of the UE may be accepted. If so, it is further decided to accept all or only a part of the UE traffic, wherein eNB2 may send a response message to eNB1 by including the decision of the local buffer related response therein. If eNB2 accepts the HO request of eNB2, eNB2 can also include a radio configuration for UE access to eNB allocated to the UE. The response associated with the local cache includes at least one of: an indication for indicating whether the local cache of the eNB2 has cached the same content or data as the indicated source network node; the available space size of the local buffer of the eNB2 may represent the total available space of the local buffer, or may be the available space size that the local buffer may allocate to the UE, or the available space size that the local buffer may allocate for each PDU session or QoS flow or bearer of the UE; if the second network node cannot accept the request from the first network node, or only a portion of the request 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 cause 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 does not support or is incompatible, or local cache does not support traffic": indicating that eNB2 has a local buffer, but the buffer does not support the traffic requested by eNB1, this allows to indicate with granularity per UE or per PDU session, or per QoS flow or per bearer, "buffer congestion or overload or starvation": indicating that the eNB2 has a local buffer, but that the buffer is full or there is insufficient space available, which makes it possible to represent with granularity per UE or per PDU session or per QoS flow or per bearer; locally cached data forwarding transport address of eNB 2: this information is used by eNB1 to forward the data stored in the local cache directly to the local cache of eNB2 without passing through eNB2; and in the absence of a local cache being connected or collocated with the second node, or the second local cache of the second network node being unable to support traffic for a given UE moving from the first network node to the second network node, the available PDCP buffer size or acceptable data forwarding data volume for the given UE.

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

In step 7, eNB1 forwards the pending data of the UE in step 5 and step 6 (i.e. DL data was not successfully transmitted to the UE and UL data received but not delivered to the core network) to eNB2, which data includes not only the pending data in the buffer of eNB1 but also the pending data in the local buffer of eNB 1. eNB1 can only forward the data to be processed in the local buffer corresponding to the bearer accepted by the local buffer of eNB2, and may not forward the buffered data to be processed of the bearer accepted by eNB2 but not accepted by the local buffer of eNB2.

In step 8, eNB2 sends a path switch request message to CN 940 (e.g., MME) to switch the UE's user plane tunnel from eNB1 to eNB2. 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 buffer connected to the eNB2 can support a PDU session or QoS flow or bearer that the UE is running or is about to establish; whether a local buffer connected to a neighboring RAN node of eNB2 can support a PDU session or QoS flow or bearer that is running or is to be established by the UE: the local buffer assistance information further comprises an identifier of the corresponding neighbor RAN node if the local buffer of the neighbor RAN node can support a PDU session or QoS flow or bearer for the given UE, and further comprises an application level classification identity related to the PDU session or QoS flow or bearer if the local buffer of the neighbor RAN node can support the PDU session or QoS flow or bearer for the given UE; application information corresponding to a PDU session or QoS flow or bearer of the UE, which may be indicated with granularity per PDU session, or per QoS flow or per bearer. Application information refers to an application level class 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 transparent to the eNB2.

In the third embodiment, as shown in fig. 10, it is assumed that a UE 1010 connected to a service eNB1 1020 connected to EPC, and the eNB1 1020 cannot withstand QoS of the UE1 due to radio interface congestion. The eNB1 then selects a target RAN node 1030 to offload all or part of the traffic of UE1 to the target node. The 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, and 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 that the local cache can support the traffic of the UE, while the SN also has a local cache.

In step 1, the UE is currently connected to the MN. When the MN finds that the QoS of the UE cannot be met due to e.g. radio resource congestion, the MN may try to add SN to offload all or part of the traffic of the UE. The MN sends an 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) the MN tries to offload to the SN. Alternatively, if the MN has a local cache and at least one of the traffic of the UE is supported by the local cache, the MN may include local cache assistance information. The local cache assistance 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 represent "there is" or; (b) The local cache of the MN supports identifiers of UE PDU sessions or QoS flows or bearers; (c) The amount of UE-related traffic data stored in the MN's local cache, which may be indicated with 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. Application information refers to an application level class 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 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 cached data in the MN's local cache, which is associated with the UE's PDU session or QoS flow or bearer, and is currently or subsequently acquired 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 fee, 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 carrier or service provider. The information may be indicated at a granularity of per UE or per PDU session, or per QoS flow or per bearer. The information may be provided by the MN's local cache. The information may be carried in the message by using an explicit IE (information element) or by including it in a container transparent to the MN. Based on this information, the SN can check whether its home cache has already stored the same content data as the MN's home cache.

The local cache assistance information may further include a last transmission position of the content data required by the UE from the local cache. This information is used to ensure the transmission continuity of the UE. The location also indicates which part of the content data has been successfully transmitted to the UE and which part has not been successfully transmitted. Based on this information, the local cache of the SN knows from which location to send data continuously 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 obtained 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 the traffic of a given UE requested by the MN can be accepted, and whether the local caching of the SN supports these traffic. Based on the SN's decision, the SN may send a response message to the MN that includes the accepted traffic and the corresponding radio configuration for the UE to access the SN, and may choose to include relevant information of the local cache if the local cache of the SN may support some accepted traffic. The local cache related information includes at least one of: (a) An indication of whether the local cache of SN 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) The available space size of the local buffer of the SN, which may represent the total available space of the local buffer, or may be the available space size that the local buffer may allocate to the UE, or the available space size of each PDU session or QoS flow or bearer that the local buffer may allocate to the UE; (c) If the SN cannot accept the request from the MN or only part of the 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 the response to the MN, which may include at least one of: "no local cache support": meaning that the SN has no local cache, "cache does not support or is incompatible, or local cache does not support traffic": meaning that the SN has a local cache, but the cache does not support the traffic requested by the MN, this can be expressed in terms of granularity per UE or per PDU session, or per QoS flow or per bearer, "cache congestion or overload or shortfall": indicating that the SN has a local buffer, but the buffer is full or there is insufficient space available, which makes it possible to represent with granularity per UE or per PDU session or per QoS flow or per bearer; (d) locally cached data forwarding transport address of SN: it is used for the MN to forward the data stored in the local cache to the local cache of the SN directly, without passing through the SN; and in the absence of a local cache being connected or collocated with the second node, or the second local cache of the second network node being unable to support traffic for a given UE moving from the first network node to the second network node, the available PDCP buffer size or acceptable data forwarding data volume for the given UE.

In step 3, if the response from the SN indicates that the SN addition of the UE can be accepted, the MN sends an RRC reconfiguration message to the UE, including the radio configuration sent from the SN. In step 4, if the RRC connection setup 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 instruct the UE to accept the radio configuration of the SN 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 the pending data of the offloaded traffic of the UE, including not only the pending data in the MN's buffer, but also the pending data in the MN's local cache. In one embodiment, the MN can only forward the pending data in the local buffer corresponding to the bearer (or PDU session or QoS flow) accepted by the SN's local buffer, and should not forward the buffered pending data for the bearer accepted by the SN but not accepted by the SN's local buffer.

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 acknowledgement message to the MN, wherein the CN may optionally include local cache related information including at least one of: (a) Whether the local cache of MN and/or SN can support PDU sessions or QoS flows or bearers that the UE is running or is about to establish; (b) Whether the local cache of the MN and/or neighboring RAN nodes of the SN can support a PDU session or QoS flow or bearer in operation or to be established by the UE. The local buffer assistance information further includes an identifier of the corresponding neighbor RAN node if the local buffer 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 neighbor RAN node can support a PDU session or QoS flow or bearer for a given UE, the local cache assistance information further 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 a PDU session or QoS flow or bearer of the UE, which may be indicated with granularity per PDU session, or per QoS flow or per bearer. Application information refers to an application level class 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 transparent to the MN.

In the fourth embodiment, referring to inter-MN handover without SN change, as shown in fig. 11, it is assumed that S-MN (source MN) 1120, S-SN (source secondary Node, source SN) 1130 and T-MN (Target Master Node, target MN) 1140 all have local caches. Suppose that UE 1110 is configured with DC by the source MN, i.e., UE 1110 connects to both 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, measurement reports 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 as to 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 of whether the UE is supported by the local cache of the S-MN, and an optional indication of whether the UE is supported by the local cache of the S-SN, e.g., a one bit indication may be used to indicate "there is" or "there is" no; (b) Identifiers of UE PDU sessions or QoS flows or bearers supported by the local cache of the source S-MN and/or the local cache of the S-SN; (c) The amount of data of UE-related traffic data stored in the local buffer of the S-MN and/or the local buffer of the S-SN, which may be indicated with 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. Application information refers to an application level class 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 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 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 acquired 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 fee, 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 carrier or service provider. The information may be indicated at a granularity of 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 by including it in a container transparent to the S-MN. Based on this information, the T-MN can check whether its home cache has already stored the same content data as the home cache of the S-MN.

The local cache assistance information may further include a last transmission position of the content data required by the UE from the local cache. This information is used to ensure the transmission continuity of the UE. The location also indicates which part of the content data has been successfully transmitted to the UE and which part has not been successfully transmitted, based on which information the local cache of the T-MN knows from which location to continuously transmit data to the UE after the UE has switched. The transmission location in the content data may be obtained from the local cache of the S-MN and/or the local cache of the S-SN, 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 of whether the S-SN has local cache support.

In step 2, the T-MN may add the S-SN to try whether the S-SN can be reserved 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 traffic for all UEs in the S-SN without any change, the MN need not include local cache related information. If after the HO the T-MN decides to offload certain UE traffic supported by the S-SN local cache back to the T-MN, the MN may need to include local cache related information, which may include at least one of: (a) The T-MN decides to move back to the PDU session or QoS flow or bearer identifier of the UE of the T-MN; (b) An indication of whether the local cache of the T-MN has cached the same content or data as the indicated S-MN may be indicated with a granularity per PDU session, or per QoS flow or per bearer; (c) An available space size of a local buffer of the T-MN, which may represent a total available space of the local buffer, or may be an available space size that the local buffer may allocate to the UE, or an available space size that the local buffer may allocate to each PDU session or QoS flow or bearer of the UE; (d) A data forwarding transport address of a local cache of the T-MN, the information for the S-SN to directly forward 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) In the absence of a local cache connected or collocated with the T-MN, or the inability of the second local cache of the T-MN to support traffic for a given UE moving from the S-MN to the T-MN, the available PDCP buffer size or acceptable data size for data forwarding for the given UE.

The local cache related information may optionally include an identifier of a PDU session or QoS flow or bearer of the UE the T-MN decides to move to the S-SN. The local cache related information may include the data amount 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. 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, the local cache related information may include information of content data required for 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 the local cache related information. If the T-MN decides not only to move back traffic for some UEs but also to offload traffic for some 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 of whether the local cache of the S-SN has cached the same content or data as the indicated S-MN, which may be expressed in terms of granularity per PDU session or per QoS flow or per bearer; (b) an available space size of a local cache of the S-SN; (c) data forwarding transport address of local buffer of 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 of whether the local cache of the T-MN has cached 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 available space size of the local cache of the T-MN; (c) If the T-MN cannot accept some PDU session or QoS flows or bearer failure reasons, such as one of the following: "no local buffer support", "no buffer support or incompatibility or service not supported by local buffer", "buffer congestion, overload or shortage"; 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 to complete the access of the UE to the T-MN.

In the fifth embodiment, referring to the gNB composed of CU and DU, it is assumed that the local cache is directly connected to the DU. In one example, for a given UE connected to the gNB, the following steps are performed. In step 1, if the DU detects an adaptive iterative learning control (Adaptive iterative learning control, abbreviated as 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 of which bearer or QoS flow or PDU session is supported. In step 2, the CU may use this information in the HO algorithm and SN selection algorithm etc. to find a better target RAN node, e.g. a node that also has a local cache and can support the same traffic, depending on which bearer or QoS flow or PDU session is supported by the local cache.

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 buffer from the connected local buffer through implementation. The local cache-related information may include at least one of: (a) Whether the DU has local cache support, which may be a simple indication, such as a bit; (b) An identifier of the local cache (if a local cache is supported); (c) A list of service information indicating which services are supported by the local cache. The traffic 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; the upper classification identification of the supported services, such as signaling, data, MT (mobile terminal), emergency, high priority access; qoS class identification that may be used, e.g., 3GPP defined QoS class, such as QCI defined in TS23.401 or 5QI defined in TS 23.501; locally caching supported network slice identifiers; application level class identification, for example, an identifier or name of an application, or an identifier or name of an application (or service) provider, or an address of an application (or service) provider (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 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 quantity of the UE associated 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: information of the UE-required content data stored in the local cache may include: characteristics of the content data, such as name, size, format, date, author, owner, free or fee, 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 carrier or service provider. The local cache-related information may include at least one of: the available space size of the local cache; and a locally cached data forwarding transport address.

In step 2, based on the information, the CU may use this information in HO algorithm and SN selection algorithm etc. to find a better target RAN node, e.g. a node that also has local buffering 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 setup response message, UE content modification need message, etc.

In a sixth embodiment, as shown in fig. 12, a UE1210 connected to the gNB 1220 is provided with a separate gNB 1220 connected to a 5 GC. 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 a service, it transmits a NAS message to the CN, which is transparently relayed by the gNB. In step 2, if the CN allows the UE to request a service, the CN sends a UE initial content setup request message to the gNB to set up UE content, where 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) a locally cached identifier; (b) A list of service information indicating which services are supported by the local cache. The traffic 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; the upper classification identification of the supported services, such as signaling, data, MT (mobile terminal), emergency, high priority access; qoS class identification that may be used, e.g., 3GPP defined QoS class, such as QCI defined in TS23.401 or 5QI defined in TS 23.501; locally caching supported network slice identifiers; application level class identification, for example, an identifier or name of an application, or an identifier or name of an application (or service) provider, or an address of an application (or service) provider (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 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 which PDU sessions or QoS flows or bearers of a given UE may be supported by the local cache of the neighbor RAN node. The local buffer related information further includes an identifier of the corresponding neighbor RAN node if the local buffer 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 neighbor RAN node can support a PDU session or QoS flow or bearer for a given UE, the local cache related information further 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 for the established PDU session and bearers. In step 4, if the UE wants to trigger a new PDU session establishment, it may send a PDU session establishment request message to the CN. In step 5, based on the UE request, the CN sends a PDU session establishment request message to the gNB, in which the CN may optionally include local cache related information if it has not been sent before. In step 6, the gNB sends an RRC reconfiguration including configuration information for the newly established PDU session and bearers.

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

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

The auxiliary information may include at least one of: (a) An indication indicating that data stored in the local cache may be delayed or may be resent; (b) a PDU session ID or QoS flow ID or DRB-ID of the delay data; (c) The PDU session that needs to be locally cached for support, or the identifier of the QoS flow or bearer; (d) Delay time window or length in which the RAN may 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 of the RAN node (e.g. PDCP buffers). 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 retransmitted. 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 those of ordinary skill in the art to understand the example features and functions of the 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, one or more features of one embodiment may be combined with one or more features of another embodiment described herein, as will be appreciated by those of ordinary skill in the art. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments.

It should also be appreciated that any reference herein to an element using a designation such as "first," "second," etc. generally does not limit the number or order of those elements. Rather, these designations 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 mean that only two elements can be employed, or that the first element must somehow precede 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, for example, 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 in the art will 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 with electronic hardware (e.g., digital, analog, or a combination of both), firmware, various forms of program or design code containing instructions (which may be referred to herein as "software" or "software modules" for convenience) or any combination of these techniques.

To clearly illustrate this interchangeability of hardware, firmware, and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware, or software, or a combination of such techniques 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, processors, devices, components, circuits, structures, machines, modules, etc. may be configured to perform one or more of the functions described herein. The term "configured to" or "configured for" as used herein with respect to a particular operation or function refers to a processor, device, component, circuit, structure, machine, module, etc. that is physically constructed, programmed and/or arranged to perform the specified operation or function.

Furthermore, 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 within or performed by an integrated circuit (Integrated Circuit, abbreviated as IC), a Digital Signal Processor (DSP), an application specific integrated circuit (Application Specific Integrated Circuit, abbreviated as ASIC), a field programmable gate array (Field Programable Gate Array, abbreviated as FPGA) or other programmable logic device, or any combination thereof, comprising a general purpose processor. The logic, modules, and circuitry may further include an antenna and/or transceiver 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 on a computer-readable medium as one or more instructions or code. 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 enables transmission of a computer program or code 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, and 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 one of ordinary skill in the art that two or more modules may be combined to form a single module that performs the relevant functions in accordance with embodiments of the present disclosure.

Additionally, memory or other storage and communication components may be employed in embodiments of the present disclosure. It should be appreciated that for clarity, the above description 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 detracting from the disclosure. For example, functions illustrated as being 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 references to suitable devices 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 present 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 as 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 used for supporting at least one service in the first wireless communication node;

wherein the first wireless communication node comprises at least one of: a source radio access network, RAN, node for a given wireless communication device during a handover procedure, wherein the second wireless communication node is a target RAN node during the handover procedure; a primary RAN node in a dual-connection or multi-connection for the given wireless communication device, wherein the second wireless communication node is a secondary RAN node in the dual-connection or multi-connection; a distributed unit DU, wherein the second wireless communication node is a centralized unit CU; and a CU, wherein the second wireless communication node is a DU;

Wherein the first locally cached information associated with the first wireless communication node comprises: the first local cache supports the information of a service information list of which services;

wherein the service information list is described by one of the following types: the upper classification identifier of each service supported by the first local cache; a QoS class classification identifier of each service supported by the first local cache; network slice identifiers supported by the first local cache; and the application program level classification identifier supported by the first local cache.

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 cache 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 is carried by at least one of: an interface setup request message and an interface setup response message.

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

an indication to indicate 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 as a multi-connection by the first wireless communication node and the secondary node; and

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

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

a first identifier for each service of a given wireless communication device supported by the first local cache, 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 service of the given wireless communication device supported by a second local cache associated with the second wireless communication node, wherein the second identifier identifies at least one of: PDU session, qoS flows and bearers.

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

a first amount 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 granularity: each user equipment UE, each PDU session, each QoS flow, and each bearer; and

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

8. 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 granularity: each UE, each PDU session, each QoS flow, and each bearer.

9. The method of claim 1, wherein the first cache-related information includes 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 based on at least one granularity of: each UE, each PDU session, each QoS flow, and each bearer; and

information of second content data information required by the given wireless communication device and stored in a second local cache associated with the second wireless communication node, wherein the information of the second content data comprises: at least one of a characteristic and an address of the second content data, and based on at least one granularity of: each UE, each PDU session, each QoS flow, and each bearer.

10. The method of claim 9, 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.

11. The method according to claim 1, wherein the method further comprises:

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

12. The method of claim 11, wherein the second cache-related information includes information of at least one of:

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

13. The method of claim 11, wherein the second cache-related information includes indication information indicating whether the second local cache has cached the same data as the first local cache for a given communication device.

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

15. The method of claim 14, wherein the at least one reason comprises one of:

the second wireless communication node has no local cache support;

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

the second local cache congestion;

the second local buffer is overloaded;

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

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

17. A non-transitory computer readable medium having stored thereon computer executable instructions for performing the method according to any of claims 1 to 15.