CN110351890B

CN110351890B - Communication method and communication equipment under centralized unit-distributed unit architecture

Info

Publication number: CN110351890B
Application number: CN201810299692.2A
Authority: CN
Inventors: 晋英豪; 韩锋; 谭巍
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2018-04-04
Filing date: 2018-04-04
Publication date: 2023-05-09
Anticipated expiration: 2038-04-04
Also published as: CN110351890A

Abstract

The application provides a communication method, a communication device and a chip under a centralized unit-distributed unit architecture. The method comprises the following steps: the control plane entity CU-CP of the centralized unit of the access network sends a request message to the user plane entity CU-UP of the centralized unit of the access network, wherein the request message is used for requesting to establish or modify a bearer, the request message comprises an identification of the bearer and indication information, and the indication information is used for indicating the CU-UP to allocate at least two port addresses for the bearer. And the CU-CP receives a response message sent by the CU-UP, wherein the response message comprises at least two port addresses allocated to the bearing by the CU-UP.

Description

Communication method and communication equipment under centralized unit-distributed unit architecture

Technical Field

The present disclosure relates to the field of communications technologies, and in particular, to a communication method and a communication device.

Background

With the development of communication technology, a new network architecture is proposed to split the functions of the base stations in the access network. Part of the functions of the base station are deployed in a Centralized Unit (CU), and the other functions are deployed in a Distributed Unit (DU). In some cases, the CU may be split further. For example, a CU may include a control plane CU (CU-CP) and a user plane CU (CU-UP). Under such a network architecture, how to ensure that communication is performed normally is a considerable problem.

Disclosure of Invention

The application provides a communication method and communication equipment, which are used for guaranteeing normal communication under the network architecture.

In a first aspect, a communication method is provided, including: the control plane entity CU-CP of the centralized unit of the access network sends a request message to the user plane entity CU-UP of the centralized unit of the access network, wherein the request message is used for requesting to establish or modify a bearer, the request message comprises an identification of the bearer and indication information, and the indication information is used for indicating the CU-UP to allocate at least two port addresses for the bearer. And the CU-CP receives a response message sent by the CU-UP, wherein the response message comprises at least two port addresses allocated to the bearing by the CU-UP.

The scenario diversity that the request to establish or modify the bearer occurs, some scenarios only need one port address, and some scenarios use one port address to cause transmission errors. The request message carries indication information, and the indication information is used for indicating the CU-UP to allocate at least two port addresses for the bearer, so that the CU-UP can be ensured to correctly allocate the required port addresses, and normal communication is ensured.

In a second aspect, a communication method is provided, including: a user plane entity CU-UP of a centralized unit of an access network receives a request message from a control plane entity CU-CP of the centralized unit of the access network, where the request message is used to request to establish or modify a bearer, the request message includes an identifier of the bearer and indication information, and the indication information is used to instruct the CU-UP to allocate at least two port addresses for the bearer. The CU-UP sends a response message to the CU-CP, wherein the response message comprises at least two port addresses allocated to the bearer by the CU-UP.

In a third aspect, a communication device is provided. The communication device is a central unit control plane entity CU-CP of the access network. The communication device includes: a transmitter and a receiver. The transmitter is configured to send a request message to a user plane entity CU-UP of a centralized unit of the access network, where the request message is configured to request establishment or modification of a bearer, and the request message includes an identifier of the bearer and indication information, where the indication information is configured to instruct the CU-UP to allocate at least two port addresses to the bearer. The receiver is configured to receive a response message sent by the CU-UP, where the response message includes at least two port addresses allocated by the CU-UP for the bearer.

In a fourth aspect, a communication device is provided. The communication device is a user plane entity CU-UP of a centralized unit of the access network. The communication device includes: a transmitter and a receiver. The receiver is configured to receive a request message from a control plane entity CU-CP of the centralized unit of the access network, where the request message is configured to request establishment or modification of a bearer, and the request message includes an identifier of the bearer and indication information, where the indication information is configured to instruct the CU-UP to allocate at least two port addresses for the bearer. The transmitter is configured to send a response message to the CU-CP, where the response message includes at least two port addresses allocated by the CU-UP for the bearer.

With reference to any one of the above aspects or any one of the designs, in one possible design, the indication information is one or more of: double connection indication information, repeated transmission indication information, switching indication information, data transfer indication information, address allocation indication mark and address number indication information. The specific indication information indicates that the CU-UP allocates at least two port addresses for the bearer, so that the CU-UP can be ensured to correctly allocate the required port addresses, and the communication is ensured to be normally carried out.

With reference to any one of the above aspects or any one of the designs, in one possible design, the request message further includes an identifier of a session corresponding to the bearer. By carrying the identifier of the session corresponding to the bearer, the CU-UP can know which SDAP protocol stack should be used for processing the mapping between the flow and the bearer, and the normal operation of communication is ensured. Further, by carrying the identifier of the session corresponding to the bearer, confusion of the CU-UP to the data flow in the bearer can be avoided, and normal communication is further ensured.

With reference to any one of the above aspects or any one of the designs, in one possible design, the request message further includes priority information, where the priority information is priority information of the bearer, or priority information of a quality of service QoS flow included in the bearer, or priority information of a session corresponding to the bearer.

Carrying priority information can enable the CU-UP to select which session/bearer/stream to establish or release which established session/bearer/stream under the condition of heavy load, thereby ensuring that the service with high priority can be smoothly carried out. If traffic of such priority is not carried, then under high load conditions the CU-UP does not know which session/bearer/flow to release, and thus may delete traffic of high priority, while retaining traffic of low priority, reducing the benefit of the network.

In combination with any one of the above aspects or any one of the designs, in one possible design, the request message further includes an aggregate maximum bit rate of the session corresponding to the bearer on the CU-UP. By carrying the aggregate maximum bit rate of the session corresponding to the bearer on the CU-UP, the CU-UP can control the rate of the session, so that the maximum transmission rate of the session corresponding to the bearer is ensured not to exceed the aggregate maximum bit rate, and the overall normal operation of network communication is ensured.

In combination with any one of the above aspects or any one of the designs, in one possible design, the request message further includes location information of the terminal. Through the location information of the terminal, the CU-UP may determine whether the terminal or the bearer/session is within the service range of the CU-UP, and further decide whether to accept the bearer establishment request. That is, if the terminal or the bearer/session is not within the service range of the CU-UP, the CU-UP denies the bearer establishment request. This further ensures the normal progress of the communication.

In combination with any one of the above aspects or any one of the designs, in one possible design, the request message further includes QoS information of the bearer. The QoS information of the bearer is generated by the CU-CP according to the QoS information of the QoS flow included in the bearer obtained from the core network, and the CU-UP configures proper SDAP and PDCP configuration for the bearer through the QoS information of the bearer, thereby ensuring the normal transmission of data.

With reference to any one of the above aspects or any one of the designs, in one possible design, the request message further includes information of a network slice, where the network slice is a network slice corresponding to the bearer or a network slice corresponding to a session corresponding to the bearer. Through the network slice information, the CU-UP may determine whether the network slice corresponding to the bearer/session is supported by the CU-UP, and further determine whether to accept the bearer establishment request. That is, if the CU-UP does not support the network slice to which the bearer/session corresponds, the CU-UP denies the bearer establishment request. This further ensures the normal progress of the communication.

In a fifth aspect, a communication method is provided, including: an access network centralized unit control plane entity (CU-CP) receives an interface establishment request from a first access network centralized unit user plane entity (CU-UP), wherein the interface establishment request comprises identification information of a second CU-UP, and the second CU-UP is connected with the first CU-UP or the second CU-UP is connectable with but not yet connected with the first CU-UP; and after receiving the interface establishment request, the CU-CP sends an interface establishment response to the first CU-UP.

If the interface setup request does not include an identification of the second CU-UP, the CU-CP needs to send a configuration update request for the first CU-UP to each CU-UP in the network in an attempt to establish a direct interface for the first CU-UP with other CU-UPs in the network. And carrying the identifier of the second CU-UP, the CU-CP only needs to send a configuration update request to the second CU-UP, thereby reducing the signaling overhead and improving the communication efficiency.

In one possible design, when the second CU-UP is connectable to the first CU-UP but not yet connected, the CU-CP sends a configuration update request to the second CU-UP, the configuration update request including identification information of the first CU-UP.

An attempt is made to establish a connection for the first CU-UP and the second CU-UP by configuring an update request. Carrying the identity of the first CU-UP may let the second CU-UP know with whom a direct interface needs to be established. And provides guarantee for subsequent normal communication.

In one possible design, the CU-CP receives a configuration update response from the second CU-UP, the configuration update response including at least one of: the first CU-UP is connected with the second CU-UP through the fifth indication information.

The method can inform the first CU-UP and the second CU-UP that the interfaces are successfully established, so that the CU-CP can judge that the first CU-UP and the second CU-UP can directly transfer data. Therefore, in the subsequent switching or CU-UP conversion process, the CU-CP can directly require the target CU-UP (e.g., CU-UP 2) to allocate the directly transferred address, thereby further ensuring the normal communication.

In one possible design, the interface setup response includes at least one of: the identification information of the first CU-UP, the fifth indication information and the identification information of the second CU-UP.

In a sixth aspect, a communication method is provided, including: a first access network centralized unit user plane entity (CU-UP) sends an interface establishment request to an access network centralized unit control plane entity (CU-CP), wherein the interface establishment request comprises identification information of a second CU-UP, and the second CU-UP is connected with the first CU-UP or the second CU-UP is connectable with but not yet connected with the first CU-UP; the first CU-UP receives an interface setup response from the CU-CP.

In a seventh aspect, a communication device is provided that includes a receiver and a transmitter. The receiver is configured to receive an interface establishment request from a user plane entity, CU-UP, of a first access network concentration unit, the interface establishment request comprising identification information of a second CU-UP, wherein the second CU-UP is connected to the first CU-UP or the second CU-UP is connectable to the first CU-UP but not yet connected. The transmitter is configured to send an interface setup response to the first CU-UP.

In one possible design, the transmitter is further configured to send a configuration update request, where the configuration update request includes identification information of the first CU-UP.

In one possible design, the receiver is further configured to receive a configuration update response from the second CU-UP, the configuration update response including at least one of: the first CU-UP is connected with the second CU-UP through the fifth indication information.

In an eighth aspect, a communication device is provided that includes a receiver and a transmitter. The transmitter is configured to send an interface establishment request to an access network central unit control plane entity CU-CP, where the interface establishment request includes identification information of a second CU-UP, where the second CU-UP is connected to the first CU-UP or the second CU-UP is connectable to the first CU-UP but not yet connected. The receiver is configured to receive an interface setup response.

In a ninth aspect, there is provided a communication method, comprising: the control plane entity CU-CP of the central unit of the access network sends a request for transferring the path to the core network. The request for transferring the path includes indication information, where the indication information is used to indicate that the core network is needed to assist in transferring the path, and the request for transferring the path further includes information of a first address, where the first address is allocated to data transfer by a user plane entity CU-UP of the target centralized unit. The CU-CP receives a response from the transfer path of the core network, the response of the transfer path including information of a second address for the source CU-UP to transfer data.

Through the process, when no direct interface exists between the source CU-UP and the target CU-UP, data transfer can be smoothly performed, so that data which is not successfully transmitted by the source CU-UP can be transferred to the target CU-UP for retransmission, data loss is avoided, and normal communication is ensured.

In one possible design, the CU-CP sends a notification message to the source CU-UP, the notification message including information of the second address.

Through the notification message, the source CU-UP can transfer the data to the core network, and then the core network sends the data to the target CU-UP, so that normal communication is ensured.

In one possible design, before the CU-CP sends a request for transferring a path to a core network, the method further includes:

and the CU-CP sends a bearer establishment request to the target CU-UP, wherein the bearer establishment request comprises identification information of the source CU-UP. The CU-CP receives a bearer establishment response from the target CU-UP, wherein the bearer establishment response comprises the indication information.

The target CU-UP judges whether an interface is needed or not through the identification information of the source CU-UP carried by the bearer establishment request, and informs the CU-CP of the judging result, for example, informs the CU-CP through indication information, and the CU-CP judges whether core network side assistance is needed or not according to the indication information. Further ensuring the normal operation of communication.

In one possible design, the indication information is used to indicate that the core network is required to assist in path transfer, including: the indication information is used for indicating that no interface exists between the target CU-UP and the CU-UP, or the interface is not available, or the data transfer cannot be directly carried out.

In a tenth aspect, there is provided a communication method comprising: the core network receives a request of a transfer path from a control plane entity CU-CP of a centralized unit of an access network, the request of the transfer path comprising indication information indicating that a core network is required to assist in a path transfer, the request of the transfer path further comprising information of a first address, the first address being allocated for a data transfer by a user plane entity CU-UP of the target centralized unit. The core network sends a response of a transfer path to the CU-CP, wherein the response of the transfer path comprises information of a second address, and the second address is used for transferring data by the source CU-UP.

In an eleventh aspect, there is provided a communication method comprising: the user plane entity CU-UP of the target concentration unit receives a bearer establishment request from the control plane entity CU-CP of the concentration unit of the access network, said bearer establishment request comprising identification information of said source CU-UP. The target CU-UP sends a bearing establishment response to the CU-CP, wherein the bearing establishment response comprises indication information, and the indication information is used for indicating that a core network is required to assist path transfer.

In a twelfth aspect, a communication device is provided that includes a receiver and a transmitter. The transmitter is configured to send a request for transferring a path to a core network. The request for transferring the path includes indication information, where the indication information is used to indicate that the core network is needed to assist in transferring the path, and the request for transferring the path further includes information of a first address, where the first address is allocated to data transfer by a user plane entity CU-UP of the target centralized unit. The receiver is configured to receive a response from a transfer path of the core network, where the response includes information of a second address for the source CU-UP to transfer data.

In one possible design, the transmitter is further configured to send a notification message to the source CU-UP, the notification message including information of the second address.

In one possible design, the transmitter is further configured to send a bearer establishment request to the target CU-UP, where the bearer establishment request includes identification information of the source CU-UP. The receiver is further configured to receive a bearer establishment response from the target CU-UP, where the bearer establishment response includes the indication information.

In a thirteenth aspect, a communication device is provided that includes a receiver and a transmitter. The receiver receives a request for a transfer path from a control plane entity CU-CP of a centralized unit of an access network, the request for the transfer path comprising indication information indicating that a core network is required to assist in path transfer, the request for the transfer path further comprising information of a first address, the first address being allocated for data transfer by a user plane entity CU-UP of the target centralized unit. The transmitter is configured to send a response of a transfer path to the CU-CP, where the response of the transfer path includes information of a second address, where the second address is used for the source CU-UP to transfer data.

In a fourteenth aspect, a communication device is provided that includes a receiver and a transmitter. The receiver is configured to receive a bearer establishment request from a control plane entity CU-CP of a centralized unit of an access network, where the bearer establishment request includes identification information of the source CU-UP. The transmitter is configured to send a bearer establishment response to the CU-CP, where the bearer establishment response includes indication information, where the indication information is used to indicate that a core network is required to assist in path transfer.

In a further aspect, a communication device is provided, where the communication device may implement a function performed by a CU-CP in a method according to the first, fifth, or ninth aspect, or implement a function performed by a CU-UP in a method according to the second, sixth, or eleventh aspect, or implement a function performed by a core network in a method according to the tenth aspect. The communication device comprises a processor and a communication interface, which is connected to the processor to perform the operations of the CU-CP or CU-UP or core network in the methods of the above aspects. In particular, the communication interface may perform operations of transmitting and/or receiving.

In one possible design, the communication device includes a memory having instructions stored therein that are executed by the processor. The instructions, when executed by the processor, control the communication interface to perform the operations of the CU-CP or CU-UP or core network in the methods of the above aspects.

In yet another aspect, a chip is provided, the chip comprising: the interface circuit is used for carrying out information interaction with the outside, and is connected with the processor to execute the operations of the CU-CP or the CU-UP or the core network in the methods in the aspects. In particular, the interface circuit may perform operations of transmitting and/or receiving.

In one possible design, the chip includes a memory having instructions stored therein that are executed by the processor. The instructions, when executed by the processor, control the interface circuit to perform the operations of the CU-CP or CU-UP or core network in the methods of the above aspects.

In yet another aspect, embodiments of the present application provide a computer-readable storage medium having instructions stored therein, which when run on a computer, cause the computer to perform the method of the above aspects.

In yet another aspect, embodiments of the present application provide a computer program product comprising instructions which, when run on a computer, cause the computer to perform the method of the above aspects.

Drawings

Fig. 1 is a schematic diagram of a network architecture of a communication system.

Fig. 2 is a schematic diagram of an architecture employing CU-DUs in a communication system.

Fig. 3 is a schematic diagram of an architecture of a CU.

Fig. 4 is a schematic diagram of a network architecture of another communication system.

Fig. 5 is a schematic diagram of a communication method according to a first embodiment of the present invention.

Fig. 6 is a schematic diagram of a communication method according to a second embodiment of the present invention.

Fig. 7 is a schematic diagram of a communication method according to a third embodiment of the present invention.

Fig. 8 is a schematic diagram of a communication method according to a fourth embodiment of the present invention.

Fig. 9 is a schematic diagram of a communication method according to a fifth embodiment of the present invention.

Fig. 10 is a schematic diagram of a communication method according to a sixth embodiment of the present invention.

Fig. 11 is a schematic diagram of a communication device according to a seventh embodiment of the present invention.

Fig. 12 is a schematic diagram of a communication device according to an eighth embodiment of the present invention.

Detailed Description

The network architecture and the service scenario described in the following description are for clearly explaining the technical solution of the present application, and do not constitute a limitation on the technical solution provided by the present application, and as a person of ordinary skill in the art can know, with evolution of the network architecture and appearance of a new service scenario, the technical solution provided by the present application is also applicable to similar technical problems.

It should be understood that the character "/" in this application indicates that the front and rear associated objects are an or relationship.

Fig. 1 is a schematic diagram of a network architecture of a communication system. The communication system comprises an access network and a core network. The access network may be a next generation radio access network (next generation radio access network, NG-RAN) and the core network may be a 5G core network (5G Core Network,5GC). The access network may include base stations (e.g., gNBs) that are connected by an interface (e.g., an Xn interface). The gNB and 5GC are connected by an interface (e.g., an Ng interface). The core network may include access and mobility management functions (access and mobility management function, AMF). The core network may also include user plane functions (user plane function, UPF). The core network may also include session management functions (session management function, SMF)

Fig. 2 is a schematic diagram of an architecture employing CU-DUs in a communication system. As shown in fig. 2, the base station may include a Centralized Unit (CU) and a Distributed Unit (DU). The functions of the base station are split, part of the functions of the base station are deployed on one CU, and the other part of the functions of the base station are deployed on DU. The number of DUs may be one or more. Multiple DUs may share one CU to save cost and facilitate network expansion. The CU and the DU are connected by an interface (e.g., F1 interface). CU represents the connection of a base station with the core network via an interface (e.g., ng interface). The functional partitioning of CUs and DUs may be performed in terms of protocol stacks. One possible way is to deploy a radio resource control (radio resource control, RRC) layer and a packet data convergence protocol (packet data convergence protocol, PDCP) layer and a service data adaptation (Service Data Adaptation Protocol, SDAP) layer at the CU. A radio link layer control protocol (Radio Link Control, RLC), medium access control (Media Access Control, MAC), physical layer (PHY) are deployed at the DUs. Accordingly, the CU has the processing capabilities of RRC, PDCP and SDAP. The DU has the processing power of RLC, MAC, and PHY. It should be noted that the above functional segmentation is only an example, and other segmentation manners are possible. For example, a CU includes RRC, PDCP, RLC and SDAP processing capabilities, and a DU has MAC and PHY processing capabilities. Also for example, a CU includes RRC, PDCP, RLC, SDAP and partial MAC (e.g., MAC header added) processing capabilities, and a DU has PHY and partial MAC (e.g., schedule) processing capabilities. The names of the CU and the DU may vary, so long as the access network node capable of implementing the above functions can be regarded as the CU and the DU in the present patent application.

Fig. 3 is a schematic diagram of an architecture of a CU. As shown in fig. 3, a CU includes a control plane CU (CU-CP) and a user plane CU (CU-UP). The CU-CP and CU-UP may be on different physical devices. The CU-CP and CU-UP may also be on the same physical device. The CU-CP and CU-UP are connected by an interface (e.g., E1 interface). CU-CP stands for base station connection with the core network through an interface (e.g., ng interface). CU-CP is connected with DU through interface (for example F1-C interface), CU-UP is connected with DU through interface (for example F1-U interface). The number of CU-CPs may be one, and the number of CU-UPs may be one or more. Multiple CUs-UPs may share one CU-CP. The CU-CP mainly has a control plane function. CU-UP mainly has user plane functions. One possible implementation is: for 5G base stations, the RRC layer may be deployed at the CU-CP, while the SDAP layer is not deployed at the CU-CP. The CU-CP may also have control plane part functions of the PDCP layer, e.g. processing of signaling radio bearers (signaling radio bearer, SRBs) may take place. The SDAP layer may be deployed at the CU-UP, but the RRC layer is not deployed at the CU-UP. The CU-UP may also have a user plane part function of the PDCP layer, for example, performing a Data Radio Bearer (DRB) process.

Fig. 4 is a schematic diagram of a network architecture of another communication system. The communication system comprises a network manager and a base station. The network management may be an operation and maintenance management (Operation Administration and Maintenance, OAM) entity. The base station is a CU-DU architecture. The CUs may include CU-CP and CU-UP. Reference is made in particular to the description of fig. 2, 3. The network manager is connected with the CU-CP so as to perform network configuration on the CU-CP. The network manager is connected with the DU, so that the network configuration can be performed on the DU. The network manager is connected with the CU-UP, so that the network configuration can be performed on the CU-UP. In some cases, there is no connection between the mesh tube and the CU-UP. And the network manager configures the CU-UP through the CU-CP.

With the development of communication technology, a concept of Network Slice (NS) is also proposed. The main types of network slices include: enhanced mobile broadband services (enhanced mobile broadband, eMBB), mass machine type connection services (massive machine type communication, mctc) and ultra-reliable low latency services (ultra-reliable and low latency communications, URLLC), wherein eMBB is mainly directed to terminals with higher demands for rate and mobility, such as cell phones, multimedia devices, etc., mctc is mainly directed to internet of things devices, with large-scale, low mobility and lower rate demands. The URLLC mainly refers to services and equipment types with severe requirements on time delay and reliability, such as internet of vehicles and security information. For example, a mobile phone user can access an eMBB type network slice to download at high speed or watch 4K high definition video, and a sensor device can access an mctc network slice to transmit small data packets and update system configuration. The user can access one or more or all network slices at the same time, thereby meeting the service requirement and achieving better user experience.

The CU-CP may request the CU-UP to set UP/modify a bearer in the case that 1) a terminal needs to be handed over from another base station, or from a source CU-UP to a target CU-UP, due to mobility of the terminal, i.e. a session established by the terminal at the source CU-UP (or source base station) or a bearer needs to be re-established at the target CU-UP (or target base station); 2) The terminal is transferred from an idle state to a connection state, data transmission is needed, and the CU-CP sends a request message to the CU-UP for establishing a bearer; 3) Due to the requirements of the service itself (e.g. the requirement of high reliability), or due to the channel conditions, a dual connection needs to be established for the terminal, the CU-CP will also request the CU-UP to establish a dual-connection bearer or modify the original single-link bearer into a dual-connection bearer. For the above case, CU-UP needs to perform address allocation according to a specific scenario, for example: 1) If the request to establish the bearer is due to handover and there is data at the source base station or the source CU-UP to be transferred to the target CU-UP, then the target CU-UP needs to allocate an address for the bearer with data transfer, and at the same time, needs to allocate an uplink transmission address for the bearer, where the uplink transmission address is used by the DU to transmit uplink data of the bearer to the CU-UP; 2) If the request to establish a bearer is due to a handover and there is no data to be transferred to the target CU-UP at the source base station or source CU-UP, no data transfer address needs to be allocated for the bearer; 3) If the request to establish the bearer is a transition from the idle state to the connected state due to the terminal to send data, no data transfer address needs to be allocated; 4) If the bearer establishment is a DC-based handover, which is a handover in a DU between CUs, then CU-UP needs to allocate two uplink transmission addresses for the bearer, and uplink data transmission is performed for the source DU node and the target DU node, respectively. The above scenarios are all performed with one request message, and if no bearer establishment/modification request is indicated in the message under what scenario, the CU-UP does not know how to allocate the address.

Fig. 5 is a communication method according to a first embodiment of the present invention. As shown in fig. 5, the method comprises the steps of:

501: the control plane entity CU-CP of the central unit of the access network sends a request message to the user plane entity CU-UP of the central unit of the access network. Accordingly, the CU-UP receives the request message from the CU-CP. The request message is used to request establishment or modification of a bearer. The request message includes an identification of the bearer. Specifically, the bearer that is requested to be established or modified is a data radio bearer (data radio bearer, DRB).

In a first case, the request message includes first indication information, where the first indication information is used to instruct the CU-UP to allocate at least two port addresses for one or more bearers of the bearers that are requested to be established or modified. The port address is used for data transmission between CU-UP and DU or between CU-UP and other CU-UP. The port address may also identify an interface transport layer bearer (transport bearer) for a certain DRB/PDU session between CU-UP and CU-UP, or between CU-UP and DU, or between CU-UP and UPF, or between CU-UP and CU-CP, e.g. an NG-U interface transport layer bearer, an Xn-U interface transport layer bearer, an E1-U transport layer bearer. The port address may be based on the general packet radio system tunneling protocol (general packet radio system (GPRS) tunneling protocol, GTP). For example, the port address may include a GTP tunnel endpoint identification (GTP Tunnel Endpoint Identifier), or may include a transport layer address that is an IP address, or both.

After receiving the first indication information, the CU-UP allocates at least two port addresses for one or more of the bearers requested to be established or modified. Alternatively, the first indication information may be carried specifically for a certain bearer, for example for a certain DRB ID. The CU-UP will assign at least two port addresses to the DRB.

The first indication information may be Dual Connection (DC) indication information or repetition (repetition) transmission indication information or handover indication information. The retransmission indication information may be based on carrier aggregation (carrier aggregation, CA) or based on dual connectivity. The handover instruction information may be a handover instruction based on dual connection, and the handover instruction information may be intra-CU, inter-DU handover, or inter-CU (NG-RAN) handover. Where dual connectivity refers to a terminal receiving or transmitting data at two nodes (e.g., two DUs of a base station, or two base stations) at the same time, carrier aggregation refers to a terminal receiving or transmitting data at two carriers at one node at the same time. Repeated transmission refers to a terminal transmitting the same data on at least two nodes or at least two carriers of one node at the same time. The handover based on dual connectivity means that the terminal can receive or transmit data at the source base station and the target base station at the same time during a period of time or during the whole process of performing the handover.

The first indication information may also indicate the number of addresses that the CU-UP needs to allocate, for example, two or three or … …, and then the CU-UP allocates corresponding address information according to the number of addresses.

The first indication information may also be an identification, for example an address allocation indication identification. After receiving the first indication information, the CU-UP allocates two or more port addresses for the bearer.

The first indication information may also indicate that the bearer needs to transfer data. The data may be uplink data or downlink data. Data transfer herein refers to transferring data from the CU-UP to another CU-UP, or other base station. And after the CU-UP receives the first indication information, at least one address is allocated for data transfer. It will be appreciated that the data transfer indication information may be indicated for a specific session/bearer or may be indicated for all sessions/bearers. If the data transfer indication information indicates that the data transfer is required for a specific session/bearer, the first indication information indicates that the data transfer is required for a specific session/bearer identification in the request message. For example, it may be in the form of:

Session/bearer identification information

First indication information (session/bearer corresponding to the session/bearer identification information needs to be transferred)

The reason for the data transfer may be a handover, or a bearer corresponding CU-UP change. It will be appreciated that the first indication information may contain both handover indication information and data transfer indication information, and that the CU-UP may learn, via the first indication information, that the terminal is to be handed over from another CU-UP (referred to herein as CU-up#1) to the CU-UP, i.e. that a PDU session/bearer established by the CU-up#1 for the terminal needs to be handed over to the CU-UP, and that the PDU session/bearer has data to be transferred from the CU-up#1 to the CU-UP.

The name of the request message in 501 may be a bearer context setup request or a bearer context modification request. Of course, the name of the request message may also be other, as long as the message can be used to request establishment or modification of a bearer. The first indication information may be an individual cell or a cause value (cause value).

In a second scenario, the request message may include an identification of the session for which the bearer is requested to be established or modified. The session to which the bearer corresponds may be a session to which the bearer belongs. The session may be a protocol data unit (protocol data unit, PDU) session. The identification of the session may be an identification of a PDU session.

CU-UP needs to configure one SDAP protocol stack for each session, and if the session includes multiple data flows (e.g., qoS flows), the SDAP protocol stack maps the multiple data flows to one or more bearers. If the CU-UP establishes multiple PDU sessions for the UE, multiple SDAP protocol stacks are established. In this scenario, the CU-CP requests to the CU-UP to establish a new bearer, and if there is no identity of the session to which the bearer corresponds, the CU-UP does not know at which SDAP the mapping of the bearer to the data stream needs to be performed. I.e. whether a re-establishment of an SDAP is required to perform the mapping function between data flows and bearers for the bearer or which of the already established SDAP protocol stacks is employed for the mapping function between data flows and bearers. The request carries the PDU session identification information corresponding to the bearer, so that the CU-UP can place the mapping between the bearer and the stream contained in the bearer in the accurate SDAP protocol stack for execution. On the other hand, the identification of the data stream is performed for each session, that is, each session may perform independent identification on the data stream, and if the session identification is not carried, the CU-UP may confuse the data stream in the DRB. For example, two PDU sessions are established in the CU-UP, for which there may be data flows identifying the same, e.g. there is a data flow identifying 1 in both sessions, and both data flows identifying 1 are mapped to the same bearer identification, e.g. to a bearer identifying a, in both sessions, then if a modification is made for a bearer identifying a, the CU-UP does not know which bearer a within the session is modified if the PDU session identification is not carried.

In a third scenario, the request message may include an aggregate maximum bit rate (session-AMBR) of the session corresponding to the bearer that the request established or modified.

The message may also include information of session-AMBR of a session to be established or a session to be established for the bearer. The session-AMBR is less than or equal to a subscribed (subscribed) session-AMBR. This information indicates the aggregate maximum bit rate of the session at CU-UP.

One session may be established on multiple CUs-UP, in which case the session-AMBR in the request message is the aggregate maximum bit rate of the session on that CU-UP. The session-AMBR on the plurality of CU-UPs does not exceed the session-AMBR transmitted to the CU-CP by the core network.

In a fourth scenario, the request message may also be included in the CU-UP for an AMBR (UE-AMBR) of a User Equipment (UE), the information indicating a maximum value at which bit rates of all sessions of the UE are aggregated together on the CU-UP. It is thereby ensured that the user equipment does not exceed the maximum value of the rate of the limit on CU-UP.

If multiple sessions of one user equipment are established on multiple CU-UPs, the UE-AMBR herein refers to the aggregate maximum bit rate on the CU-UP. The UE-AMBR of one user equipment on all CU-UP does not exceed the UE-AMBR transmitted by the core network to the CU-CP.

In a fifth scenario, the request message may also include location information of the user equipment. The location information of the user equipment may be current location information of the terminal. For example, information of a current cell identifier of the terminal, and an identifier of a service area in which the terminal is located. The CU-UP can judge whether the user equipment is currently in the service range of the user equipment or whether the service corresponding to the bearer to be established is in the service range through the position information of the user equipment. If not, the establishment of the bearer is denied.

In a sixth scenario, the request message further includes QoS information of the bearer or QoS information of a QoS flow included in a session corresponding to the bearer.

The QoS information may include priority information. The priority information is the priority information of the bearer, or the priority information of the QoS flow included in the bearer, or the priority information of the session corresponding to the bearer. The priority information may be QoS flow specific, DRB specific, or PDU session specific. After the CU-UP obtains the priority information, it can decide which QoS flow/DRB/PDU session is not established, which QoS flow/DRB/PDU session is established, and which QoS flow/DRB/PDU session is released according to the load condition. It will be appreciated that if it is DRB based, the priority is determined by the CU-CP, which, when delivered to the CU-UP, may cause the CU-UP to decide which bearer to set UP preferentially or to delete or release that bearer preferentially in certain scenarios (e.g. in case of heavier load), where the CU-CP may be determined based on QoS information of the data flow obtained from the core network side and the priority.

The QoS information may also include averaging window information, e.g., AMBR averaging window information. The AMBR average window information may include Session AMBR average window information and/or UE AMBR average window information. After receiving the AMBR average window information, the CU-UP averages the AMBR for a certain period of time to obtain an average value of the AMBR. For comparison with session-AMBR or UE-AMBR. If the average value of the AMBR is larger than the session-AMBR or the UE-AMBR, the RAN side may reduce the transmission speed for the session. Of course, the average window information may also be Packet Delay (Packet Delay) average window information or Packet error rate (Packet Error Rate) average window information.

In a seventh scenario, the request message further includes information of a network slice, where the network slice is a network slice corresponding to a bearer or a session corresponding to the bearer that is requested to be established or modified.

After the CU-UP acquires the information of the network slice, and finds that it does not support the network slice, the CU-UP refuses to build or modify the DRB. If the CU-UP does not know the information of the network slice, a DRB setup error may occur, i.e., the CU-UP sets UP a DRB of a network slice that is not supported by itself, thereby causing a transmission error. By carrying the information of the network slice, transmission errors can be avoided, and normal transmission is ensured.

In an eighth scenario, the request information further includes indication information of a default DRB, where the indication information is used to indicate which bearer corresponds to the default bearer in a certain PDU session. For example, if the CU-CP requests the CU-UP to establish drb#1 and DRB2 and the two bearers belong to the same session, the CU-CP needs to indicate which of drb#1 and drb#2 is the default bearer. Thus, when a new data flow arrives, before the CU-CP does not tell which bearer the new data flow is mapped to, the new data flow may be mapped to the default bearer first, then wait until the CU-CP indicates which bearer the new data flow is mapped to, and then remap to the new bearer or keep mapping on the default bearer.

It is noted that the first to eighth cases described above may be independent of each other or superimposed on each other. For example, the request message may include any one or more of first indication information, an identification of a session, session-AMBR, UE-AMBR, location information of a user equipment, qoS information, information of a network slice.

502: the CU-UP sends a response message to the CU-CP. Correspondingly, the CU-CP receives the response message sent by the CU-UP.

In a first case, if the request message includes first indication information, the response message includes at least two port addresses allocated by the CU-UP for the bearer.

After receiving the request message including the first indication information, the CU-UP allocates at least two port addresses for the bearer corresponding to the first indication information.

If the first indication information indicates repeated transmission or DC, the port addresses allocated by the CU-UP at least comprise two port addresses for the DU to send uplink data to the CU-UP. The CU-UP sends the at least two port addresses to the CU-CP. The CU-CP may send the at least two port addresses to one or more DUs. The transmission address of the corresponding carried data on the CU-U can be known from different DUs or from different carriers on one DU.

If the first indication information is not present in the request message, the CU-UP allocates an address for the bearer. For example, in a DC or repeated transmission scenario, data streams on different DUs or data streams on different carriers on one DU can only be transmitted to one address, thereby causing processing errors of the PDCP layer on the CU-UP side. For example, for the uplink transmission scenario of DC, two DUs use the same number for different PDCP packets, if they transmit two PDCP packets of the same number to one address, then CU-UP would consider that this numbered PDCP packet was retransmitted and need to delete one of them. However, if two addresses are allocated for the above scenario, two PDCP packets with the same number are transmitted to the CU-UP through the two addresses, and the CU-UP can distinguish that these are two different data, and thus are not discarded. And the CU-UP cannot allocate an address for data transfer, so that the data transfer between the CU-UPs or between other base stations and the CU-UP cannot be performed under the scene of switching or conversion of the CU-UP, and system packet loss is avoided.

It is noted that, if the first indication information included in the request message indicates that the bearer needs to be transferred from data, the port address allocated by the CU-UP for the bearer includes at least one port address for transferring data.

Fig. 6 is a communication method according to a second embodiment of the present invention. As shown in fig. 6, the method includes the steps of:

601: the control plane entity CU-CP of the central unit of the access network sends a request for transferring the path to the core network. Accordingly, the core network receives the request for the transfer path.

The request for a transfer path may inform the core network that the path of one or more PDU sessions or bearers for a certain user changes from a source CU-UP to a target CU-UP. This may occur in a handover scenario or a CU-UP transition scenario.

In step 601, the message name of the request for transferring the path may be the path update request (path update request) or the path transfer request (path switch request), or may be other, as long as the message can request the path transfer.

The request for a transfer path comprises second indication information indicating a capability (Direct Forwarding Path Availability) of a direct transfer path between a target user plane entity (target CU-UP) of the concentration unit and a source user plane entity (source CU-UP) of the concentration unit. For example, whether there is an interface between the source CU-UP and the target CU-UP, or whether an interface is available (unavailable), or whether the target CU-UP and the source CU-UP can directly transfer data. It will be appreciated that the second indication information may also indicate, for a certain PDU session or bearer (or all PDU sessions or bearers), whether the data of the PDU session or bearer may be transferred directly between the source CU-UP and the target CU-UP, i.e. whether the data of the PDU session or bearer may be transferred directly from the source CU-UP to the target CU-UP.

After the core network receives the request of transferring the path, it is known whether the core network needs to assist in transferring the data for a certain PDU session or bearer (or all PDU sessions or bearers) according to the second indication information.

The core network may include an AMF and a UPF. The request to receive the transfer path may be an AMF. When transferring data, the UPF can be used as a transfer station of the data surface of the core network.

602: the core network sends a response of the transfer path to the CU-CP. The CU-CP receives a response from the transfer path of the core network. The response of the transfer path includes information of a second address for the source CU-UP to transfer data. The second address is assigned by the core network.

The message name of the response of the transfer path may be a path update response (path update response) or a request reply of the transfer path (path switch request Ack).

603: the CU-CP sends a notification message to the source CU-UP. The source CU-UP receives the notification message from the CU-CP. The notification message includes information of the second address. The notification message may be an address notification message.

The communication method may further include:

604: the CU-CP sends a bearer establishment request to the target CU-UP. The target CU-UP receives a bearer establishment request from the CU-CP. The bearer establishment request may carry an identification of the bearer.

Optionally, the bearer establishment request includes identification information of the source CU-UP. The identification information can uniquely identify the CU-UP within a certain range. The range may be an NG-RAN range, or tracking area range, or PLMN range, or full network range. The identification information may be ID information, or may be address information, for example, an IP address, and the identification information may further indicate the PLMN corresponding to the CU-UP. After receiving the identification information of the source CU-UP, the target CU-UP can determine whether an interface exists between the target CU-UP and the source CU-UP or whether an interface between the target CU-UP and the source CU-UP is available or whether the target CU-UP and the source CU-UP can directly transfer data or not according to the identification information.

605: the target CU-UP sends a bearer establishment response to the CU-CP. Accordingly, the CU-CP receives a bearer establishment response from the target CU-UP.

If the target CU-UP determines that there is no interface, or that an interface is not available, or that no data transfer can be directly performed with the source CU-UP, the bearer setup response in step 605 may include second indication information. The target CU-UP may also assign a first address for data transfer (used for data forwarding). Accordingly, the bearer establishment response may include the first address. The core network knows by means of the first address which address of the target CU-UP the transferred data should be sent to. After the CU-CP acquires the second indication information, the core network can be utilized for forwarding data.

If the target CU-UP determines that an interface exists between it and the source CU-UP, or that an interface is available, or that data transfer can be performed directly, the bearer setup response in step 605 does not include the second indication information.

Steps 604 and 605 may occur before steps 601 and 602. Notably, steps 604 and 605 may be performed separately. After steps 604 and 605 occur, steps 601 and 602 do not have to occur.

In the embodiment shown in fig. 6, the target CU-UP and the source CU-UP belong to the same CU-CP.

Fig. 7 is a communication method according to a third embodiment of the present invention. As shown in fig. 7, the method includes the steps of:

701: the source CU-CP sends a Handover (HO) request to the target CU-CP. Accordingly, the target CU-CP receives the handover request from the source CU-CP. The handover request is used to request handover of a session/bearer established by the source base station for the terminal from the source base station to the target base station

The handover request may include identification information of the source CU-UP. The identification information can uniquely identify the CU-UP within a certain range. The range may be an NG-RAN range, or tracking area range, or PLMN range, or full network range. The identification information may be ID information or address information, such as an IP address. After receiving the identification information of the source CU-UP, the target CU-UP can determine whether an interface exists between the target CU-UP and the source CU-UP or whether an interface between the target CU-UP and the source CU-UP is available according to the identification information. It should be noted that the identification information of the source CU-UP may also be an identification of the source CU-UP to which each PDU session belongs. I.e. further indicates on which CU-UP the PDU session requesting the handover is established.

Step 702: the target CU-CP sends a HO request reply message to the source CU-CP.

The request reply message may include the first indication information if there is no interface or no interface available (unavailable) between the target user plane entity (target CU-UP) and the source user plane entity (source CU-UP) of the central unit or the target CU-UP and the source CU-UP cannot directly transfer data. Further, the first indication information may be for one or more of the sessions that require handover. The first indication information may be for one or more bearers included in one or more of the sessions requiring handover. If there is an available interface between the target user plane entity (target CU-UP) and the source user plane entity (source CU-UP) of the centralized unit, or the target CU-UP and the source CU-UP can directly transfer data, the request reply message may include data forwarding address information allocated by the target base station.

Optionally, the message may also include an UP identity corresponding to the switched session, i.e. indicating on which UP the session is established.

The communication method may further include the steps of:

703: the target CU-CP sends a bearer establishment request to the target CU-UP. The target CU-UP receives a bearer establishment request from the target CU-CP. The bearer establishment request includes an identification of the bearer.

Optionally, the bearer establishment request includes identification information of the source CU-UP. The identification information can uniquely identify the CU-UP within a certain range. The range may be an NG-RAN range, or tracking area range, or PLMN range, or full network range. The identification information may be ID information or address information, such as an IP address. After receiving the identification information of the source CU-UP, the target CU-UP can determine whether an interface exists between the target CU-UP and the source CU-UP or whether an interface between the target CU-UP and the source CU-UP is available according to the identification information.

The bearer establishment request in step 703 may further comprise third indication information. The third indication information is used to indicate whether data forwarding is required. After receiving the third indication information, the target CU-UP can perform address allocation. Specifically, a first address for data forwarding may be allocated. The data transfer instruction information may be an instruction for a specific session/bearer, or may be an instruction for all sessions/bearers, whether or not data transfer is required. If the data transfer indication information indicates for a specific session/bearer, the third indication information indicates for a specific session/bearer identification in the request message.

The bearer establishment request in step 703 may further comprise fourth indication information. The fourth indication information is used for informing the target CU-UP: the bearer establishment request is triggered by a handover. It will be appreciated that if the bearer establishment request includes fourth indication information without third indication information, the target CU-UP allocates a data forwarding address for each bearer or session. If the bearer establishment request third indication message is included without the fourth indication message, the target CU-UP allocates a data forwarding address for the session or bearer indicated by the third indication message.

704: the target CU-UP sends a bearer establishment response to the target CU-CP. Accordingly, the target CU-CP receives a bearer establishment response from the target CU-UP.

If the target CU-UP determines that there is no interface between it and the source CU-UP, or that the interface is not available, or that data transfer cannot be performed directly, the bearer setup response in step 705 may include second indication information. The target CU-UP may also assign a first address for data transfer (used for data forwarding). Accordingly, the bearer establishment response may include the first address. After the CU-CP acquires the second indication information, the core network can be utilized for forwarding data.

If the target CU-UP determines that an interface exists between it and the source CU-UP, or that an interface is available, or that data transfer can be performed directly, the bearer setup response in step 705 does not include the second indication information.

The communication method may further include the steps of:

705: the control plane entity CU-CP of the central unit of the access network sends a request for transferring the path to the core network device. Accordingly, the core network device receives the request for the transfer path. The CU-CP in step 705 is the target CU-CP. Reference is made to step 601 for a specific description of step 705.

706: the core network device sends a response of the transfer path to the CU-CP. The CU-CP receives a response from the transfer path of the core network device. The CU-CP in step 706 is the target CU-CP. Reference may be made to step 602 for a specific description of step 706.

707: the target CU-CP sends a notification message to the source CU-CP. The source CU-CP receives the notification message from the CU-CP. The notification message includes information of the second address. The notification message may be an address notification message. The notification message may also be a UE uplink release message (UE Context Release).

In the embodiment shown in fig. 7, the target CU-UP and the source CU-UP belong to different CU-CPs. The target CU-UP belongs to the target CU-CP. The source CU-UP belongs to the source CU-CP.

From the above embodiments, it can be seen that it is important that the CU-CP knows the connection situation between the CUs-UP, and can also be identified through the procedure established by the interface, in addition to identifying during the handover or DC.

Fig. 8 is a communication method according to a fourth embodiment of the present invention. As shown in fig. 8, the method includes the steps of:

801: the first CU-UP sends an interface establishment request to the CU-CP. The CU-CP receives an interface establishment request from the first CU-UP. The interface establishment request is for requesting establishment of an interface. The interface may specifically be an E1 interface.

In the first case, the interface establishment request includes identification information of the second CU-UP. The second CU-UP interfaces with the first CU-UP. If there are a plurality of second CU-UPs, the interface setup request may include identification information of some or all of the CU-UPs that have interfaces with the first CU-UP. In this case, network operation management and maintenance (and maintenance OAM) configures the first CU-UP with information of other CUs-UPs that can be connected.

In a second case, the interface establishment request may include identification information of an area in which the CU-UP is located, in which all the CU-UP have interfaces between each other.

In a third scenario, the interface establishment request includes an identification of the second CU-UP. The second CU-UP is connectable to the first CU-UP but not yet connected. If there are a plurality of second CU-UPs, the interface setup request may include identification information of part or all of the CU-UPs that can establish an interface with the first CU-UP but have not established an interface yet. Accordingly, the CU-CP may assist the first CU-UP in interfacing with the second CU-UP.

802: the CU-CP sends an interface setup response to the CU-UP. The CU-UP receives an interface setup response from the CU-CP.

The communication method may further include:

803: the CU-CP sends a configuration update request to the second CU-UP. The second CU-UP receives a configuration update request from the CU-CP. The configuration update request includes an identification of the first CU-UP. By configuring an update request, the second CU-UP knows that the first CU-UP can establish an interface with the second CU-UP. If the first CU-UP in step 801 is more than two, then in step 803 the configuration update request includes an identification of the more than two first CU-UP. Optionally, the message may also include address information of the first CU-UP, such as IP address information.

804: the second CU-UP sends a configuration update response to the CU-CP. The CU-CP receives a configuration update response from the second CU-UP.

If the second CU-UP successfully establishes an interface with the first CU-UP, the configuration update response comprises identification information and/or fifth indication information of the first CU-UP. Specifically, the form of the configuration update response may be as follows:

1) The configuration update response contains fifth indication information. The fifth indication information is used to indicate that the first CU-UP included in step 803 has successfully established an interface with the second CU-UP. Or the fifth indication information is used to indicate that none of the first CU-UP included in step 803 successfully establishes an interface with the second CU-UP. This may be predefined.

2) The configuration update response contains identification information of the first CU-UP. And the number of the identification information of the first CU-UP contained in the configuration update response is smaller than or equal to the number of the identification information of the first CU-UP contained in the configuration update request. In this case, the identity of the first CU-UP carried by the configuration update response may be considered to be successfully interfaced with the second CU-UP, or the identity of the first CU-UP carried by the configuration update response may be considered to be unsuccessfully interfaced with the second CU-UP. This may be predefined.

3) The configuration update response contains the identity of the CU-UP and fifth indication information. The configuration update response may take the form of either a) or b) as follows:

a) Fifth indication information (indicating successful interface establishment)

> CU-UP identification information (this part of the identification information indicates successful establishment of an interface with the second CU-UP)

b) Fifth indication information (indicating that the interface was not successfully established)

> CU-UP identification information (this part of the identification information indicates failure to establish an interface with the second CU-UP)

Optionally, in case of successful interface establishment, the configuration update response further includes IP address information of the second CU-UP. The IP address information is used by the first CU-UP to further identify the second CU-UP. So that the first CU-UP knows exactly the IP address of the second CU-UP. After the IP address of the second CU-UP is prevented from being updated, the first CU-UP still uses the wrong IP address, and transmission errors are avoided.

If step 804 occurs, the interface setup response in step 802 may also include an identification of the first CU-UP and/or fifth indication information. Optionally, identification information of the second CU-UP that has been interfaced with the first CU-UP may also be included. In this embodiment, steps 803 and 804 may occur for the second CU-UP.

A case of the present embodiment will be described below with a specific example. The CU-UP #1 sends an interface setup request message to the CU-CP (step 801), which contains identification information of the CU-UP #2 and the CU-UP #3, and the CU-CP considers that the CU-UP #1 can establish a direct data plane interface with the CU-UP #2 and the CU-UP #3 (i.e. the CU-UP #1 can directly transmit data with the CU-UP #2 and the CU-UP # 3), and then the CU-CP sends a configuration update message to the CU-UP #2 and the CU-UP #3, respectively, which carries the identification of the CU-UP #1, indicating that it can establish a direct data plane interface with the CU-UP #1 (step 803). After receiving the message, the CU-up#2 carries fifth indication information or identification information of the CU-up#1 in the configuration update response message (step 804), indicating whether the direct interface between the CU-up#2 and the CU-up#1 is successfully established. After receiving the message, the CU-up#3 carries fifth indication information or identification information of the CU-up#1 in a configuration update response message (step 804), indicating whether the direct interface between the CU-up#3 and the CU-up#1 is successfully established. After receiving the interface setup feedback message of the CU-up#2 (and/or the CU-up#3), the CU-CP informs the CU-up#1 whether it successfully establishes a direct data plane interface with the CU-up#2 (and/or the CU-up#3) in an interface setup request response message (step 802) sent by the CU-up#1, for example, by fifth carrying indication information and/or identification information of the CU-up#2 and the CU-up#3.

The embodiment shown in fig. 8 may also be used in a CU-CP configuration update procedure. Accordingly, in step 801, the first CU-UP sends a configuration update request to the CU-CP, where the content included in the configuration update request may refer to the interface setup request. In step 802, the CU-CP sends a configuration update response to the first CU-UP, where the configuration update response includes a content that may reference the interface setup response.

Fig. 9 is a communication method according to a fifth embodiment of the present invention. The embodiment of fig. 9 is similar to the embodiment of fig. 8, except that: the embodiment shown in fig. 8 is initiated by CU-UP and the embodiment shown in fig. 9 is initiated by CU-CP. As shown in fig. 9, the method includes the steps of:

901: the first CU-CP sends an interface establishment request to the CU-UP. The first CU-UP receives an interface setup request from the CU-CP. The interface establishment request is for requesting establishment of an interface. The interface update request is used to update the interface. The interface may specifically be an E1 interface.

Optionally, the interface establishment request includes: and the identification of a second CU-UP, wherein the second CU-UP has a direct data surface interface with the first CU-UP. That is, direct data transfer is possible. The request message may also include IP address information of the second CU-UP. This applies to OAM configuring the first CU-UP directly to the first CU-CP with other CU-UPs, e.g. the second CU-UP, to which the first CU-UP may or may already be connected.

902: the first CU-UP sends an interface establishment response to the CU-CP. The CU-CP receives an interface setup response from the CU-UP.

Optionally, the interface setup response includes: a third CU-UP identity having a direct data plane interface with said CU-UP. That is, direct data transfer is possible. This applies to OAM configuration of the first CU-UP directly to other CU-UPs to which the first CU-UP may or may already be connected, e.g. to the second CU-UP.

If the interface establishment request includes an identification of the second CU-UP, the interface establishment response may not include the third CU-UP identification. If the interface establishment request does not include an identification of the second CU-UP, the interface establishment response may include the third CU-UP identification.

It may be understood that the interface establishment request message in step 901 may be a CU-CP configuration update request message, and the corresponding step 902 is a CU-CP configuration update request response message.

Fig. 10 is a communication method according to a sixth embodiment of the present invention. In this embodiment, as shown in fig. 10, the method includes the steps of:

1001: the first CU-CP sends an interface establishment request to the second CU-CP. The second CU-CP receives an interface setup request from the first CU-CP. The interface setup request is used to request setup of an interface, e.g. a first CU-CP first deployment. The interface update request is used to update the interface, e.g. one CU-UP is newly deployed and has an interface with the first CU-CP. The interface may in particular be an Xn interface.

The interface establishment request includes first CU-UP identification information, and the first CU-UP is connected with the first CU-CP in an interfacing way. Optionally, the interface setup request may further include second CU-UP identification information, where the second CU-UP has a direct interface with the first CU-UP, or may be connected but not yet connected. Optionally, the request message may further include address information (e.g., IP address information) of the first CU-UP.

If the request message includes the second CU-UP identification information, the second CU-CP may determine that it needs to send a request message to the second CU-UP to assist the first CU-UP to establish a direct interface with the second CU-UP after receiving the information. If the second CU-UP identification information is not included, the second CU-CP needs to send a request message to all CU-UPs that have an interface with the second CU-CP to attempt to establish a direct interface with the first CU-UP.

For example, CU-CP1 includes CU-UP1, CU-CP2 includes CU-UP2 and CU-UP3, OAM configuration CU-UP1 can establish a direct interface with CU-UP2 directly but not with CU-UP3, then in step 1001, if CU-CP1 tells CU-CP2: CU-UP1 can only establish interface with CU-UP2 (CU-UP 2 identification information is carried in step 1001 and CU-UP3 identification information is not carried), then CU-CP2 sends update request message to CU-UP2 only; conversely if CU-CP1 does not tell CU-CP2: CU-UP1 can only interface with CU-UP2 (does not carry CU-UP2 identification information nor CU-UP3 identification information), then CU-CP2 needs to send update request messages to CU-UP2 and CU-UP3 simultaneously to try if CU-UP2 and CU-UP3 can establish a direct interface with CU-UP 1. Therefore, carrying CU-UP2 identification information can save the number of attempts, thereby reducing signaling overhead

1002: the second CU-CP sends an interface setup response to the first CU-CP. The first CU-CP receives an interface setup response from the second CU-CP.

The interface setup response message includes a second CU-UP identity that has a direct interface with the first CU-UP. The second identity may be used to indicate that the second CU-UP successfully established a direct interface with the first CU-UP. Alternatively, the second CU-UP may also indicate that the first CU-UP successfully establishes a direct interface with the second CU-UP by carrying indication information.

Optionally, the message may also carry third CU-UP identification information, which has no direct interface with the first CU-UP.

It may be understood that the interface establishment request message in step 1001 may be a base station configuration update request message, and the corresponding step 1002 is a base station configuration update request response message

Fig. 11 is a schematic diagram of a communication device according to a seventh embodiment of the present invention. Fig. 11 shows a possible structural schematic of CU-CP or CU-UP involved in the above embodiment.

In the first case, when the communication device 1100 is a central unit user plane entity CU-CP of an access network, the communication device 1100 comprises: a transmitter 113 for transmitting a request message to a user plane entity CU-UP of a centralized unit of the access network, the request message being for requesting to set UP or modify a bearer. The request message includes an identifier of the bearer and indication information, where the indication information is used to instruct the CU-UP to allocate at least two port addresses for the bearer. The communication device 1100 further comprises: and a receiver 111, configured to receive a response message sent by the CU-UP, where the response message includes at least two port addresses allocated by the CU-UP for the bearer.

In the second case, when the communication device 1100 is a centralized unit user plane entity CU-CP of an access network, the communication device 1100 comprises: a transmitter 113 for transmitting a request message to a user plane entity CU-UP of a centralized unit of the access network, the request message being for requesting to set UP or modify a bearer. The request message includes an identifier of the bearer and indication information, where the indication information is used to instruct the CU-UP to allocate at least two port addresses for the bearer. The communication device 1100 further comprises: and a receiver 111, configured to receive a response message sent by the CU-UP, where the response message includes at least two port addresses allocated by the CU-UP for the bearer.

Fig. 12 is a schematic diagram of a communication device according to an eighth embodiment of the present invention. As shown in fig. 12, the communication device 1200 may perform the operations of CU-CP or CU-UP described in any of the embodiments methods shown in fig. 5-10 above. The communication device 1200 comprises a processor and a communication interface 1203, the communication interface 1203 being connected to the processor for performing the operations of the CU-CP or CU-UP in the method of the above aspects. In particular, the communication interface 1203 may perform operations of transmitting and/or receiving.

Optionally, the communication device 1200 further comprises a memory 1205, wherein the memory 1205 stores instructions for execution by the processor. The instructions, when executed by the processor, control the communication interface 1203 to perform the operations of the CU-CP or CU-UP in the methods of the above aspects.

Various embodiments of the present invention may be combined with each other. For example, the interface establishment may occur before the bearer establishment, update.

In this application, the information of the network slice may be characterized by at least one of the following parameters:

1. network slice identification. The network slice identifier may be specifically one or more of the following information listed in 1.1-1.7:

network slice type information may be used to indicate network slice types for enhanced mobile broadband services (enhanced mobile broadband, emmbb), ultra-reliable low latency communications (ultra-reliable low latency communications, URLLC), and mass machine type communications (massive machine type communication, mctc). Optionally, the network slice type information may also indicate AN end-to-end network slice type, including a RAN-to-CN network slice type, or may also refer to AN (R) AN side network slice type, or a CN side network slice type;

And 1.2, service type information, which is related to specific services. The service type information can indicate service characteristics such as video service, internet of vehicles service, voice service and the like or information of specific service;

1.3, tenant (tenant) information for indicating customer information for creating or renting the network slice, such as a customer vacation, a national grid, etc.;

user group information indicating grouping information for grouping users according to a certain feature, for example, according to the user level or the like;

1.5. slice group information indicating that according to a certain feature, for example, all network slices that the UE can access may be taken as one slice group, or groups of network slices may be divided according to other criteria;

1.6, network slice example information, which is used for indicating an example identifier created for the network slice and characteristic information, for example, an identifier can be allocated to the network slice example, which is used for indicating the network slice example, a new identifier can be mapped on the basis of the network slice example identifier, the network slice example is associated, and a receiver can identify a specific network slice example indicated by the identifier according to the identifier;

a private core network (dedicated core network, DCN) identity for uniquely indicating a private core network in an LTE system or an LTE system, such as an internet of things private core network. Optionally, the DCN identifier may be mapped with a network slice identifier, where the DCN identifier may be mapped to a network slice identifier, and the DCN identifier may also be mapped to a network slice identifier.

It should be understood that if the network side allows the UE to access multiple network slices in the registration area (registration area) or tracking area (tracking area) to which the source cell belongs, or allows the UE to access multiple network slices in the registration area or tracking area to which the source cell belongs for a certain public land mobile network PLMN (pubic land mobile network, PLMN), the allowed network slice indication contains multiple allowed (allowed) network slice identities.

2. Single-network slice selection assistance information (S-nsai) containing at least slice/service type (SST) information, and optionally slice distinction information (slice differentiator, SD). The SST information is used to indicate the behavior of the network slice, such as the characteristics of the network slice and the type of service. The SD information is complementary to the SST, and if the SST is implemented to multiple network slices, the SD may correspond to a unique one of the network slice instances.

It should be understood that if the network side allows the UE to access multiple network slices in the registration area (registration area) or tracking area (tracking area) to which the source cell belongs, or in the registration area or tracking area to which the source cell belongs for a certain public land mobile network PLMN (pubic land mobile network, PLMN), the allowed network slice indication contains multiple allowed (allowed) S-NSSAIs.

3. S-NSSAI group information indicating that all network slices of a certain common AMF, which the UE device can access, are grouped according to a certain characteristic, for example, may be regarded as one S-NSSAI group. NSSAI comprises a plurality of S-NSSAI.

4. Temporary identification (Temporary ID): the Temporary identification information is allocated to the UE that has been registered on the CN side by the AMF, and the Temporary ID may uniquely point to a certain AMF.

5. (radio) access network slice selection assistance information ((R) AN-nsai, R-nsai): represents a specific set of S-NSSAIs, i.e., a specific set of S-NSSAIs. It should be appreciated that if the network side allows the UE to access multiple network slices in a registration area (registration area) or tracking area (tracking area) to which the source cell belongs, or in a registration area or tracking area to which the source cell belongs for a certain public land mobile network PLMN (pubic land mobile network, PLMN), the allowed network slice indication may contain an identification of a set of multiple allowed R-NSSAIs.

6. Allowed NSSAI. The allowed nsai indicates an nsai that the network allows the terminal device to access within the current registration area.

It should be appreciated that the particular encoding form of the network slice information that is allowed is not limited. Of course, the network slice information may be other identifiers besides the above-mentioned identifiers, which are not limited herein. If the network side allows the UE to access multiple network slices, the allowed network slice indication may be in the form of a list of allowed network slice indications, e.g., an allowed network slice selection support information list (allowed Network Slice Selection Assistance Information list, allowed NSSAI list), or an allowed single network slice selection support information list (allowed Single Network Slice Selection Assistance Information list, allowed S-nsai list).

In this embodiment of the present application, the network slice may use at least one of the above parameters to characterize the network slice information, for example, the network slice information may be characterized by a network slice type, or may also be characterized by a network slice type and a service type, or may also be characterized by a service type and a tenant information, which is not limited in this embodiment of the present application, and how to characterize the network slice information of the network slice is not described in detail. It should be understood that if the terminal device, the access network device or the core network device supports a plurality of network slices, the indication information of the network slices supported by the terminal device, the access network device or the core network device may be embodied in the form of a list of at least one identifier as described above.

The technical scheme of the application can be applied to a fifth generation mobile communication (the 5th Generation mobile communication technology,5G) system or a further developed mobile communication system, and can also be applied to various forms of systems comprising partial function separation of a base station.

In the embodiments of the present application, the sequence number of each process does not mean that the execution sequence of each process should be determined by the function and the internal logic of each process, and should not constitute any limitation on the implementation process of the embodiments of the present application.

In addition, the term "and/or" herein is merely an association relationship describing an association object, and means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present invention, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another, for example, by wired (e.g., coaxial cable, optical fiber, digital Subscriber Line (DSL)), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk (SSD)), etc.

The foregoing embodiments have been provided for the purpose of illustrating the technical solution and advantageous effects of the present application in further detail, and it should be understood that the foregoing embodiments are merely illustrative of the present application and are not intended to limit the scope of the present application, and any modifications, equivalents, improvements, etc. made on the basis of the technical solution of the present application should be included in the scope of the present application.

Claims

1. A method of communication, comprising:

a control plane entity CU-CP of a centralized unit of an access network sends a request message to a user plane entity CU-UP of the centralized unit of the access network, wherein the request message is used for requesting to establish or modify a bearer, the request message comprises an identifier of the bearer and indication information, the indication information is used for indicating the CU-UP to allocate at least two port addresses for the bearer, the indication information is also used for indicating the number of addresses allocated by the CU-UP for the bearer, and the number of addresses is determined by a scene of requesting to establish or modify the bearer;

and the CU-CP receives a response message sent by the CU-UP, wherein the response message comprises at least two port addresses allocated to the bearing by the CU-UP.

2. A method of communication, comprising:

a user plane entity (CU-UP) of a centralized unit of an access network receives a request message from a control plane entity (CU-CP) of the centralized unit of the access network, wherein the request message is used for requesting to establish or modify a bearer, the request message comprises an identification of the bearer and indication information, the indication information is used for indicating the CU-UP to allocate at least two port addresses for the bearer, the indication information is also used for indicating the number of addresses allocated by the CU-UP for the bearer, and the number of the addresses is determined by a scene for requesting to establish or modify the bearer;

the CU-UP sends a response message to the CU-CP, wherein the response message comprises at least two port addresses allocated to the bearer by the CU-UP.

3. A communication method according to claim 1 or 2, characterized in that:

the indication information further includes one or more of the following: dual connection indication information, repeated transmission indication information, handover indication information, data transfer indication information, or an address allocation indication flag.

4. A communication method according to claim 1 or 2, characterized in that: the request message also includes an identification of the session to which the bearer corresponds.

5. A communication method according to claim 1 or 2, characterized in that: the request message further includes priority information, where the priority information is priority information of the bearer, or priority information of a quality of service QoS flow included in the bearer, or priority information of a session corresponding to the bearer.

6. A communication method according to claim 1 or 2, characterized in that: the request message further includes an aggregate maximum bit rate of the session corresponding to the bearer on the CU-UP.

7. A communication device being a central unit control plane entity, CU-CP, of an access network, characterized by: the communication device includes:

a transmitter, configured to send a request message to a user plane entity CU-UP of a centralized unit of the access network, where the request message is used to request to establish or modify a bearer, where the request message includes an identifier of the bearer and indication information, where the indication information is used to indicate the CU-UP to allocate at least two port addresses for the bearer, and the indication information is further used to indicate a number of addresses allocated by the CU-UP for the bearer, where the number of addresses is determined by a scenario requesting to establish or modify the bearer;

And the receiver is used for receiving a response message sent by the CU-UP, wherein the response message comprises at least two port addresses allocated to the bearer by the CU-UP.

8. A communication device being a user plane entity CU-UP of a centralized unit of an access network, characterized by: the communication device includes:

a receiver, configured to receive a request message from a control plane entity CU-CP of a centralized unit of the access network, where the request message is used to request establishment or modification of a bearer, the request message includes an identifier of the bearer and indication information, where the indication information is used to instruct the CU-UP to allocate at least two port addresses for the bearer, and the indication information is further used to instruct the CU-UP to allocate a number of addresses for the bearer, where the number of addresses is determined by a scenario requesting establishment or modification of the bearer;

and the sender is used for sending a response message to the CU-CP, wherein the response message comprises at least two port addresses allocated to the bearer by the CU-UP.

9. A communication device as claimed in claim 7 or 8, characterized in that:

10. A communication device as claimed in claim 7 or 8, characterized in that: the request message also includes an identification of the session to which the bearer corresponds.

11. A communication device as claimed in claim 7 or 8, characterized in that: the request message further includes priority information, where the priority information is priority information of the bearer, or priority information of a quality of service QoS flow included in the bearer, or priority information of a session corresponding to the bearer.

12. A communication device as claimed in claim 7 or 8, characterized in that: the request message further includes an aggregate maximum bit rate of the session corresponding to the bearer on the CU-UP.

13. A communication device comprising a processor and a communication interface, the communication interface being coupled to the processor, the communication interface performing operations of transmitting and/or receiving, the processor, when executing instructions, controlling the communication interface to perform the method of any of claims 1-6.

14. A chip, comprising: a processor and an interface circuit for exchanging information with the outside, the interface circuit being connected to the processor, which when executing instructions, controls the interface circuit to perform the method according to any one of claims 1-6.

15. A computer readable storage medium having instructions stored therein which, when run on a computer, cause the computer to perform the method of any of claims 1-6.