Devices and methods for controlling data flow in wireless communication systems

Abstract

This disclosure relates to quasi-5G or 5G communication systems that provide higher data rates than 4G+ communication systems such as LTE. This disclosure provides apparatus and methods for controlling data flows in a wireless communication system. According to various embodiments of this disclosure, a method for managing data flows in a wireless communication system includes controlling the transfer of Quality of Service (QoS) flows from a first Data Radio Bearer (DRB) to a second DRB. Here, the QoS flow is a data flow carried via a DRB between a terminal and at least one network entity.

Description

Technical Field

[0001] This disclosure relates to wireless communication systems, and more specifically, to apparatus and methods for controlling data flow in wireless communication systems. Background Technology

[0002] To meet the increased demand for wireless data traffic since the deployment of fourth-generation (4G) communication systems, efforts have been made to develop improved fifth-generation (5G) or pre-5G communication systems. Therefore, 5G or pre-5G communication systems are also referred to as "beyond 4G networks" or "post-Long Term Evolution (LTE) systems."

[0003] 5G communication systems are considered to be implemented in higher frequency (millimeter wave) bands (e.g., the 60 GHz band) to achieve higher data rates. To reduce radio wave propagation loss and increase transmission distance, beamforming, massive MIMO (multiple-input multiple-output), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive MIMO technologies are discussed in 5G communication systems.

[0004] In addition, in 5G communication systems, system network improvements are being developed based on advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, coordinated multi-points (CoMP), and receiver interference cancellation.

[0005] In 5G systems, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) have been developed as advanced coding and modulation (ACM), as well as filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access technologies.

[0006] With the rapid increase in demand for data transmission, multiple data streams can be configured in wireless communication networks. Therefore, it is necessary to manage and control the data streams in wireless communication networks. Summary of the Invention

[0007] Technical issues

[0008] One aspect of this disclosure is aimed at managing and / or controlling data flows in wireless communication networks.

[0009] Technical solution

[0010] According to this disclosure, apparatus and methods as set forth in the appended claims are provided. Other features of the invention will be apparent from the dependent claims and the description below.

[0011] According to a first aspect of this disclosure, a method for managing QoS flows in a communication system is provided, wherein the QoS flow is a data flow carried by a data radio bearer DRB between a mobile device and a radio network via one or more network entities, the method including the step of moving the QoS flow from a first DRB to a second DRB.

[0012] In this implementation, multiple QoS flows of a particular mobile device are routed sequentially, simultaneously, or in a combination of sequential and simultaneous routing via at least two network entities. Here, "sequentially" refers to handover; "simultaneously" refers to dual connectivity; and "a combination of sequential and simultaneous routing" means handover is performed when dual connectivity is present.

[0013] In one implementation, only some of the multiple QoS flows for a particular mobile device are transmitted from the first network entity to the second network entity.

[0014] In this implementation, the QoS flow is moved individually, without moving any other QoS flows carried by the same DRB.

[0015] In this implementation, the QoS flow moves from the source DRB to the target DRB.

[0016] In this implementation, the QoS flow moves along with any other QoS flow carried by the same DRB.

[0017] In the implementation, QoS streams and any other QoS streams are included:

[0018] Move from the source MN or source cell to the target MN or target cell;

[0019] Move between MN or cell and SN or cell;

[0020] Move from MCG type bearer to MCG segmented type bearer; or

[0021] To enable mobile compatibility with LTE+LTE NR.

[0022] In an implementation involving a handover from a source eNB to a target eNB, the handover is either a normal handover or a full configuration handover. In a normal handover, the target eNB understands the configuration in the source eNB and continues to use that configuration, which may be updated. In a full configuration handover, the target eNB configures a new access stratum configuration.

[0023] In the implementation, the mapping of QoS flows to DRB is maintained to ensure lossless and sequential delivery.

[0024] In implementations, if lossless and sequential delivery is not required, the mapping of QoS flows to DRBs can be changed.

[0025] In an implementation where the MCG is LTE and the SCG is NR, the MN is operable to determine whether to offload the QoS flow to the SCG / SN.

[0026] In this implementation, MN sends such a request to CN.

[0027] In the implementation, for all or part of the QoS flow of a PDU session, some services may terminate at MN while other services may terminate at SN.

[0028] In implementation, this is possible for all QoS flows mapped to a specific DRB.

[0029] In the implementation, MN determines the DRB to be configured and the mapping of QoS flows to the DRB.

[0030] According to a second aspect of this disclosure, a method for managing QoS flows in a communication network that operates in a dual-connectivity configuration to enable communication between a user equipment and a core network at a first node and a second node is provided. The method includes the steps of the core network establishing a second backhaul tunnel between itself and the second node and establishing a first backhaul tunnel between itself and the first node, wherein the first backhaul tunnel and the second backhaul tunnel are used for the same PDU session.

[0031] According to a third aspect of this disclosure, a method for forwarding data packets during handover is provided. The method also relates to forwarding data packets when the termination point of a QoS flow in a DC changes.

[0032] In the implementation, for packets assigned to a DRB and packets designated for QoS mobility, tunnels are used for each DRB and each PDU session, respectively.

[0033] In the implementation, each packet assigned to a DRB has a PDCP SN set in the packet header.

[0034] In this implementation, packets allocated for QoS mobility have a QoS flow ID set in the packet header.

[0035] In the implementation, the target node configures or determines whether to perform forwarding for each QoS flow or request.

[0036] In this implementation, each QoS flow is provided with an end marker.

[0037] While some preferred embodiments of this disclosure have been shown and described, those skilled in the art will understand that various changes and modifications may be made without departing from the scope of the invention as defined in the appended claims.

[0038] Beneficial effects of the invention

[0039] According to various embodiments of this disclosure, data flow in a wireless communication network can be effectively controlled and / or managed. Attached Figure Description

[0040] To better understand the present invention, and to illustrate how embodiments of the invention can be implemented, reference will now be made by way of example only to the accompanying schematic diagrams, in which:

[0041] Figure 1 A wireless communication system according to various embodiments of the present disclosure is shown;

[0042] Figure 2 Network devices in wireless communication systems according to various embodiments of the present disclosure are shown;

[0043] Figure 3 A terminal in a wireless communication system according to various embodiments of the present disclosure is shown;

[0044] Figure 4 A communication interface in a wireless communication system according to various embodiments of the present disclosure is shown;

[0045] Figure 5 (a) and Figure 5 (b) Network configurations with 1:1 bearer mapping (as in the case of connecting the LTE RAN to the EPC) and QoS flow-based schemes (as in the case of connecting the NR RAN to the 5G CN) are shown respectively;

[0046] Figure 6 It shows Figure 5 A more detailed view of (a);

[0047] Figure 7 An LTE QoS architecture in a dual connectivity (DC) configuration according to an embodiment of the present invention is illustrated;

[0048] Figure 8 A signaling diagram according to an embodiment of the present invention is shown, which illustrates the message sequence for configuring a first SCG cell to a UE (i.e., a process referred to as SCG establishment or SN addition);

[0049] Figure 9An NR QoS architecture in a non-DC configuration according to an embodiment of the present invention is illustrated;

[0050] Figure 10 A representation of Level 1 mobility according to an embodiment of the present invention is shown (i.e., involving the case of changing the mapping of QoS flows to DRBs for a given DRB);

[0051] Figure 11 A representation of Level 2 mobility according to an embodiment of the present invention is shown;

[0052] Figure 12 This illustration shows a handover scenario in which level 1 mobility and level 2 mobility are combined, according to an embodiment of the present invention.

[0053] Figure 13 A representation of handover in the case of Level 1 mobility (i.e., DRB where the mapping of QoS flow to DRB remains unchanged) according to an embodiment of the present invention is shown.

[0054] Figure 14 An NR QoS architecture with one tunnel for each PDU session according to an embodiment of the present invention is shown, wherein all QoS flows of PDU session 2 are offloaded to SN / moved to SN;

[0055] Figure 15 An NR QoS architecture with multiple tunnels for each PDU session according to an embodiment of the present invention is illustrated;

[0056] Figure 16 An NR QoS architecture with segmented bearers according to an embodiment of the present invention is shown;

[0057] Figure 17 An NR QoS architecture including an ASML layer according to an embodiment of the present invention is shown;

[0058] Figure 18 A message flow diagram related to the MeNB offloading services by moving the entire DRB (DRB2) to the SeNB, according to an embodiment of the present invention, is shown.

[0059] Figure 19 A message flow diagram related to the offloading of an additional QoS flow (QoS flow 2) according to an embodiment of the present invention is shown; and

[0060] Figure 20 A message flow diagram related to the initiation of an additional QoS flow (QoS flow 3) is shown according to an embodiment of the present invention. Detailed Implementation

[0061] In the following description of various embodiments of this disclosure, hardware methods will be used as examples. However, various embodiments of this disclosure include techniques using both hardware and software, and therefore, software aspects are not excluded from the various embodiments of this disclosure.

[0062] In the following, this disclosure describes techniques for controlling data flow in wireless communication systems.

[0063] The terms used in the following description relating to signals, channels, control information, network entities, and elements of a device are for ease of description only. Therefore, this disclosure is not limited to the terms used below, and other terms with the same technical meaning may be used.

[0064] Furthermore, while this disclosure describes various embodiments based on terminology used in some communication standards (e.g., the 3rd Generation Partnership Project, 3GPP), these are merely illustrative examples. The various embodiments of this disclosure can be readily modified and applied to other communication systems.

[0065] Figure 1 Wireless communication systems according to various embodiments of the present disclosure are shown. Figure 1 In the diagram, base station (BS) 110, terminal 120, and terminal 130 are shown as part of a node using a wireless channel in a wireless communication system. Figure 1 Only one BS is shown, but another BS that is the same as or similar to BS 110 may also be included.

[0066] BS 110 is the network infrastructure that provides wireless access to terminals 120 and 130. BS 110 has a coverage area limited to a predetermined geographical region based on the distance over which the signal can be transmitted. BS 110 may be referred to as an "Access Point (AP)," "eNodeB (eNB)," "5th Generation (5G) Node," "Radio Point," "Transmit / Receive Point (TRP)," and "Base Station."

[0067] Each of terminals 120 and 130 is a device used by a user and performs communication with BS 110 via a wireless channel. Depending on the circumstances, at least one of terminals 120 and 130 can operate without user intervention. That is, at least one of terminals 120 and 130 is a device performing machine-type communication (MTC) and can be carried by no user. Each of terminals 120 and 130 may be referred to as a "User Equipment (UE)," "Mobile Station," "User Service Station," "Remote Terminal," "Wireless Terminal," or "User Equipment" and "Terminal."

[0068] BS 110, Terminal 120, and Terminal 130 can transmit and receive wireless signals in millimeter-wave (mmWave) frequency bands (e.g., 28 GHz, 30 GHz, 38 GHz, and 60 GHz). In this case, to improve channel gain, BS 110, Terminal 120, and Terminal 130 can perform beamforming. Beamforming can include transmit beamforming and receive beamforming. That is, BS 110, Terminal 120, and Terminal 130 can perform directional allocation of transmit and receive signals. To this end, BS 110, as well as Terminals 120 and 130, can select serving beams 112, 113, 121, and 131 through a beam search process or a beam management process. Thereafter, communication can be performed using resources that have a quasi-co-located relationship with the resources carrying serving beams 112, 113, 121, and 131.

[0069] If the large-scale properties of the channel transmitting symbols at the first antenna port can be inferred from the channel transmitting symbols at the second antenna port, then the first and second antenna ports are considered quasi-co-located. Large-scale properties may include one or more of delay spread, Doppler spread, Doppler shift, average gain, average delay, and spatial Rx parameters.

[0070] Figure 2 A network device 200 in a wireless communication system according to various embodiments of the present disclosure is shown. Figure 2 The structures illustrated herein can be understood as the structures of network device 200, which may include at least one of a BS 110, a serving gateway (S-GW), a mobility management entity (MME), or other network entities included in the core network. According to various embodiments of this disclosure, the BS 110 may be a primary eNB (MeNB) or a secondary eNB (SeNB). The terms “-module,” “-unit,” or “-device” as used herein may refer to a unit for processing at least one function or operation, and may be implemented in hardware, software, or a combination of hardware and software.

[0071] Reference Figure 2 The network device may include a wireless communication interface 210, a backhaul communication interface 220, a storage unit 230, and a controller 240.

[0072] The wireless communication interface 210 performs functions for transmitting and receiving signals via a wireless channel. For example, the wireless communication interface 210 may perform functions for converting between baseband signals and bitstreams according to the system's physical layer standard. For example, in data transmission, the wireless communication interface 210 generates complex symbols by encoding and modulating the transmitted bitstream. Furthermore, in data reception, the wireless communication interface 210 reconstructs the received bitstream by demodulating and decoding the baseband signal.

[0073] Furthermore, the wireless communication interface 210 up-converts the baseband signal into a radio frequency (RF) band signal, transmits the converted signal through an antenna, and subsequently down-converts the RF band signal received through the antenna back into a baseband signal. For this purpose, the wireless communication interface 210 may include a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a digital-to-analog converter (DAC), an analog-to-digital converter (ADC), etc. Additionally, the wireless communication interface 210 may include multiple transmit / receive paths. Furthermore, the wireless communication interface 210 may include at least one antenna array composed of multiple antenna elements.

[0074] In terms of hardware, the wireless communication interface 210 may include digital units and analog units, and the analog units may include multiple sub-units depending on the operating power, operating frequency, etc. The digital units may be implemented as at least one processor (e.g., a digital signal processor (DSP)).

[0075] As described above, the wireless communication interface 210 transmits and receives signals. Therefore, the wireless communication interface 210 may be referred to as a "transmitter," a "receiver," or a "transceiver." Furthermore, in the following description, the transmission and reception performed via a wireless channel can be used to mean having the meaning of including the processes performed via the wireless communication interface 210 as described above.

[0076] According to various embodiments of this disclosure, the wireless communication interface 210 may be omitted for some network entities. For example, the S-GW, MME, or other network entities in the core network may not include a wireless communication interface.

[0077] The backhaul communication interface 220 provides an interface for communicating with other nodes within the network. That is, the backhaul communication interface 220 converts bit streams sent to another node (e.g., another access node, another BS, a higher node, or the core network) into physical signals from the BS and converts physical signals received from another node into bit streams.

[0078] Storage unit 230 stores basic programs, applications, and data, such as configuration information for the operation of network device 200. Storage unit 230 may include volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. Furthermore, storage unit 230 provides stored data in response to requests from controller 240.

[0079] Controller 240 controls the general operation of network device 200. For example, controller 240 sends and receives signals via wireless communication interface 210 or backhaul communication interface 220. Furthermore, controller 240 records data in storage unit 230 and reads the recorded data. Controller 240 can perform the functions of the protocol stack required by the communication standard. According to another embodiment, the protocol stack may be included in wireless communication interface 210. For this purpose, controller 240 may include at least one processor.

[0080] According to an exemplary embodiment of this disclosure, controller 240 may control and / or manage data flows in a wireless communication network. According to an exemplary embodiment of this disclosure, for example, controller 240 may control network device 200 to perform operations.

[0081] Figure 3 A terminal in a wireless communication system according to various embodiments of the present disclosure is shown. Figure 3 The structures exemplified herein can be understood as the structures of terminal 120 or terminal 130. The terms “-module,” “-unit,” or “-device” used below may refer to a unit for processing at least one function or operation, and may be implemented in hardware, software, or a combination of hardware and software.

[0082] Reference Figure 3 The terminal 120 includes a communication interface 310, a storage unit 320, and a controller 330.

[0083] Communication interface 310 performs functions for transmitting / receiving signals via a wireless channel. For example, communication interface 310 performs conversion between baseband signals and bitstreams according to the system's physical layer standard. For instance, in data transmission, communication interface 310 generates complex symbols by encoding and modulating the transmitted bitstream. Furthermore, in data reception, communication interface 310 reconstructs the received bitstream by demodulating and decoding the baseband signal. Additionally, communication interface 310 up-converts the baseband signal to an RF band signal, transmits the converted signal through an antenna, and subsequently down-converts the RF band signal received through the antenna back to a baseband signal. For example, communication interface 310 may include a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a DAC, and an ADC.

[0084] Furthermore, the communication interface 310 may include multiple transmit / receive paths. Additionally, the communication interface 310 may include at least one antenna array consisting of multiple antenna elements. In terms of hardware, the wireless communication interface 210 may include digital and analog circuitry (e.g., a radio frequency integrated circuit (RFIC)). The digital and analog circuitry may be implemented in a single package. The digital circuitry may be implemented as at least one processor (e.g., a DSP). The communication interface 310 may include multiple RF chains. The communication interface 310 may perform beamforming.

[0085] As described above, communication interface 310 transmits and receives signals. Therefore, communication interface 310 may be referred to as a "transmitter," a "receiver," or a "transceiver." Furthermore, in the following description, transmission and reception performed via a wireless channel are used to mean having the meaning of including the processes performed via communication interface 310 as described above.

[0086] Storage unit 320 stores basic programs, applications, and data, such as settings information for the operation of terminal 120. Storage unit 320 may include volatile memory, non-volatile memory, or a combination of volatile and non-volatile memory. Furthermore, storage unit 320 provides stored data in response to requests from controller 330.

[0087] Controller 330 controls the general operation of terminal 120. For example, controller 330 sends and receives signals through communication interface 310. Furthermore, controller 330 records data in storage unit 320 and reads the recorded data. Controller 330 can perform the functions of the protocol stack required by the communication standard. According to another embodiment, the protocol stack may be included in communication interface 310. For this purpose, controller 330 may include at least one processor or microprocessor, or may be used as part of a processor. Furthermore, communication interface 310 or a part of controller 330 may be referred to as a communication processor (CP).

[0088] According to an exemplary embodiment of this disclosure, controller 330 may perform operations related to controlling and / or managing data flows via network device 200. According to an exemplary embodiment of this disclosure, for example, controller 330 may control a terminal to perform operations.

[0089] Figure 4 A communication interface in a wireless communication system according to various embodiments of the present disclosure is shown. Figure 4 It shows the use of Figure 2 Communication interface 210 or Figure 3 A detailed configuration example of the communication interface 310. More specifically, Figure 4 It was shown as Figure 2 Communication interface 210 or Figure 3 The communication interface 310 is a component used to perform beamforming.

[0090] Reference Figure 4 The communication interface 210 or communication interface 310 includes encoding and modulation circuitry 402, digital circuitry 404, multiple transmission paths 406-1 to 406-N, and analog circuitry 408.

[0091] The encoding and modulation circuit 402 performs channel coding. For channel coding, at least one of low-density parity-check (LDPC) codes, convolutional codes, and polar codes can be used. The encoding and modulation circuit 402 generates modulation symbols by performing constellation mapping.

[0092] Digital circuit 404 performs beamforming on a digital signal (e.g., a modulation symbol). To do this, digital circuit 404 multiplies the modulation symbol using beamforming weights. These beamforming weights can be used to change the magnitude and phase of the signal and can be referred to as a "precoding matrix" or "precoder." Digital circuit 404 outputs the digitally beamformed modulation symbol to multiple transmission paths 406-1 to 406-N. At this point, according to a multiple-input multiple-output (MIMO) transmission scheme, the modulation symbol can be multiplexed, or the same modulation symbol can be provided to multiple transmission paths 406-1 to 406-N.

[0093] Multiple transmission paths 406-1 to 406-N convert digitally beamformed signals into analog signals. To this end, each of the multiple transmission paths 406-1 to 406-N may include an Inverse Fast Fourier Transform (IFFT) calculation unit, a Cyclic Prefix (CP) insertion unit, a DAC, and an up-conversion unit. The CP insertion unit is used for Orthogonal Frequency Division Multiplexing (OFDM) schemes, and the CP insertion unit can be omitted when applying another physical layer scheme (e.g., Filter Bank Multicarrier: FBMC). That is, the multiple transmission paths 406-1 to 406-N provide independent signal processing for multiple streams generated by digital beamforming. However, depending on the implementation, some components of the multiple transmission paths 406-1 to 406-N may be used together.

[0094] Analog circuit 408 performs beamforming on the analog signal. To do this, digital circuit 404 multiplies the analog signal using beamforming weights. These weights are used to change the magnitude and phase of the signal. More specifically, analog circuit 408 can be configured in various ways depending on the connection structure between the multiple transmission paths 406-1 to 406-N and the antenna. For example, each of the multiple transmission paths 406-1 to 406-N can be connected to an antenna array. In another example, the multiple transmission paths 406-1 to 406-N can be connected to a single antenna array. In yet another example, the multiple transmission paths 406-1 to 406-N can be adaptively connected to a single antenna array, or they can be connected to two or more antenna arrays.

[0095] In Long Term Evolution (LTE) systems, a bearer called the Evolved Packetswitched System (EPS) bearer is provided, which, through the Data Radio Bearer (DRB), provides a 1:1 mapping between User Equipment (UE) or mobile device and the Evolved Packet Core (EPC) located in the network core. This... Figure 5 As shown in (a), it illustrates a 1:1 mapping between EPS bearers and the DRBs involved.

[0096] In new radio (NR) systems, the 1:1 mapping has been replaced by a Quality of Service (QoS) flow-based model, where QoS flows are part of a Protocol Data Unit (PDU) session. The Radio Access Network (RAN) is responsible for managing the mapping of QoS flows to the DRB as needed. This scheme... Figure 5 As shown in (b), it illustrates the concept of QoS flow between the UE and the 5G core network via NR RAN.

[0097] Figure 6 It shows the relationship with Figure 5 (a) is a slightly more detailed representation of a 4G implementation similar to the one shown in (a). Here, the relationship between the UE, LTE RAN, and EPC is illustrated. There is a dedicated DRB for each EPS bearer between the UE and the LTE RAN, and subsequently a dedicated GTP tunnel for each EPS bearer between the LTE RAN and the EPC.

[0098] This configuration is suitable for non-dual-connection scenarios.

[0099] Figure 7The diagram illustrates a configuration according to an embodiment of the invention in the case of dual connectivity (DC). In the DC case, the radio connection between the UE and the RAN involves multiple cells (i.e., in the form of carrier aggregation), and some of these cells are controlled by a master node (MN or MeNB in ​​the case of LTE), while others are controlled by a secondary node (SN or SeNB in ​​the case of LTE). The cells controlled by the MN are called the Master Cell Group (MCG), and the cells controlled by the SN are called the Secondary Cell Group (SCG).

[0100] In this scenario, the UE communicates with both the LTE MeNB and LTE SeNB via the DRB of each EPS bearer in each case. Data services move between the MeNB and SeNB in ​​this situation. As illustrated, when the EPS bearer moves from the MeNB to the SeNB, the MeNB requests a different IP address / DLGTP Tunnel Endpoint Identifier (TEID) from the Mobility Management Entity (MME). The EPC is unaware that this IP address / DLGTP TEID corresponds to a different eNB. Furthermore, an eNB can use different IP addresses.

[0101] Figure 8 The signal flow between the UE, MeNB, SeNB, S-GW, and MME is illustrated. This is known in existing LTE DC operation, but is still included in this document.

[0102] Figure 9 The non-DC scenario in 5G is illustrated. Here, the GTP tunnels for each PDU session 510 and 520 between NR RAN 600 and 5GCN 500 are shown. As indicated by the dotted / dashed lines, each PDU session 510 and 520 handles multiple QoS flows. Between NR RAN600 and UE 700, there are DRBs 610, 611, and 612 that handle multiple QoS flows for one PDU session.

[0103] This indicates that the QoS flow from PDU session 1 510 is mapped by the RAN to two DRBs, DRB 610 and DRB 611.

[0104] Specifically, embodiments of the present invention relate to the processing of QoS flows when the MN (handover) is changed and when the SN is added or changed (i.e., when changes are made to the network nodes involved), which can also be considered as mobility scenarios. However, some aspects of these aspects are equally applicable to non-mobility scenarios, such as changes related to offloading in the case of a DC.

[0105] In these cases, it's important to note the mapping of QoS flows to the DRB, a function controlled by the RAN nodes (MN and SN). Specifically, different scenarios are distinguished—hereinafter referred to as Level 1 mobility and Level 2 mobility. It should be noted that these mobility levels involve the mapping of QoS flows to the DRB; that is, QoS flow mobility levels can occur without any changes to actual UE mobility or the network nodes controlling the UE's radio connections.

[0106] In this scenario, the RAN 600 maps different QoS flows for a specific PDU session to one or more DRBs. In some implementations, the RAN maps similar flows together onto the DRB. Similar flows in this document can, for example, refer to data flows with similar QoS requirements, such as data flows with similar latency requirements. Other grouping methods can be implemented as needed.

[0107] For each UE, the 5GCN 500 establishes one or more PDU sessions, and for each UE, the RAN 600 establishes one or more DRBs for each PDU session. The RAN 600 maps packets belonging to different PDU sessions to different DRBs. Therefore, the RAN 600 establishes at least one default DRB for each PDU session. Non-Access Stratum (NAS) level packet filters in the UE and 5GCN associate UL and DL packets with QoS flows. AS level mapping rules in the UE and RAN associate UL and DL QoS flows with DRBs.

[0108] At the NAS level, QoS flows represent the finest QoS differentiation granularity within a PDU session. QoS flows within a PDU session are identified by the QoS Flow ID (QFI) carried in the encapsulation header on the NG-U.

[0109] RAN and 5GCN ensure quality of service (e.g., reliability and target latency) by mapping packets to appropriate QoS flows and DRBs. Therefore, there are two mapping steps: mapping IP flows to QoS flows (NAS) and mapping from QoS flows to DRBs (access stratum).

[0110] At the NAS level, QoS flows are characterized by QoS profiles provided by the 5GCN to the RAN and QoS rules provided by the 5GCN to the UE. The QoS profiles are used by the RAN to determine the processing of the radio interface, while the QoS rules specify the mapping between uplink user plane services and QoS flows to the UE. Depending on its profile, a QoS flow can be Guaranteed Bitrate (GBR) or non-GBR. The QoS profile of a QoS flow contains QoS parameters, such as:

[0111] For each QoS flow, it includes:

[0112] - 5G QoS identifier (5QI); and

[0113] - Allocation and Retention Priority (ARP).

[0114] In the case of GBR QoS-only flow, it includes:

[0115] -Guaranteed Stream Bit Rate (GFBR) for both uplink and downlink;

[0116] - Maximum Stream Bit Rate (MFBR) for both uplink and downlink.

[0117] In the case of non-GBR QoS only, it includes:

[0118] - Reflection QoS Attribute (RQA): RQA (when included) indicates that some services (not necessarily all services) carried on this QoS flow are affected by Reflection Quality of Service (RQoS) at the NAS.

[0119] At the access layer, the Data Radio Bearer (DRB) defines packet processing on the radio interface (Uu). A DRB serves multiple packets with the same packet forwarding processing. Different DRBs can be established for QoS flows that require different packet forwarding processing. In the downlink, the RAN maps QoS flows to DRBs based on NG-U marking (QFI) and the associated QoS profile. In the uplink, the UE uses the QFI to mark uplink packets on the Uu to label forwarded packets to the CN.

[0120] In the uplink, the RAN can control the mapping of QoS flows to the DRB in two different ways:

[0121] - Reflection Mapping: For each DRB, the UE monitors the QFI of downlink packets and applies the same mapping in the uplink; that is, for each DRB, the UE maps uplink packets that belong to the PDU session and the QoS flow corresponding to the QFI observed in the downlink packets for that DRB. To achieve this reflection mapping, the RAN uses the QFI to tag downlink packets on Uu.

[0122] - Explicit configuration: In addition to reflection mapping, the RAN can also configure the uplink "QoS flow to DRB mapping" via RRC.

[0123] Regardless of whether the mapping rules are executed via reflection mapping or explicit configuration, the UE should always apply the latest updates to the mapping rules.

[0124] Configure a default DRB for each PDU session. If an incoming UL packet does not match either the configured RRC or the reflected "QoS Flow ID to DRB mapping", the UE should map the packet to the default DRB for the PDU session.

[0125] Within each PDU session, the NG-RAN determines how multiple QoS flows are mapped to DRBs. The RAN can map GBR flows and non-GBR flows, or more than one GBR flow, to the same DRB. The timing of establishing a non-default DRB between the RAN and the UE for QoS flows configured during PDU session establishment may differ from the PDU session establishment time. The timing of establishing the non-default DRB is determined by the RAN.

[0126] In a DC, QoS flows belonging to the same PDU session can be mapped to different bearer types, and this allows two different SDAP entities to be configured for the same PDU session: one for MCG and the other for SCG (e.g., when an MCG bearer and an SCG bearer are used for two different QoS flows).

[0127] In embodiments of the present invention, QoS flow mobility is used to describe any mobility of a QoS flow, such as moving a QoS flow to another DRB and / or DRB type and / or another eNB.

[0128] Several alternatives exist for managing this QoS flow mobility. In the first alternative, QoS flow mobility is only implemented at one level (i.e., a single QoS flow mobility level), meaning that QoS flows can only move from one DRB to another.

[0129] This is Figure 10 As shown in, Figure 10In this configuration, DRB1 620 handles two QoS flows. QoS flow 2 can be moved to the new DRB2 621, while QoS flow 1 remains on DRB1 620. Moving individual QoS flows means updating the mapping of individual QoS flows from the source DRB to the target DRB. The source and target DRBs can be of any type, such as MCG, SCG, separate, or may belong to different eNBs.

[0130] A source DRB can be released while a QoS flow is moving (if no other QoS flow remains on that DRB), and a target DRB can be established while a QoS flow is moving (if no other QoS flow is using that target DRB).

[0131] In this specific example, the DRB is not moved and the bearer type is not changed. In other words, bearers (of a specific type) are established and released, and the bearers have QoS flows mapped to them.

[0132] In the second alternative, QoS flow mobility can be achieved at two levels:

[0133] A DRB can be moved from one DRB type or eNB to another DRB type or eNB (Level 1).

[0134] As described in the first alternative above, QoS flows can be moved from one DRB to another (Level 2).

[0135] This is Figure 11 As shown in the figure, Figure 11 This illustrates the movement of QoS flows 1 and QoS flows 2 from DRB1 630 on MeNB1 to DRB1 631 on a new MeNB (MeNB2). This is the case where the mapping between QoS flows and DRBs remains unchanged. It also illustrates a handover scenario (i.e., a radio connection change from the first MeNB to the second MeNB).

[0136] In Level 1, DRBs can be moved. For example, a DRB can be moved from a MeNB to a SeNB (MCG->SCG bearer type change) or it can be any other bearer type change. Optionally, such as Figure 11 As shown, a DRB can be moved from one MeNB to another (e.g., during a handover).

[0137] Additionally, individual QoS flows can be moved from the source DRB to the target DRB (Level 2).

[0138] In fact, the second alternative mentioned above is preferred. This method includes DRB mobility at level 1 and QoS flow mobility at level 2.

[0139] Table 1 below illustrates specific features of the method and helps to fully understand these features.

[0140]

[0141]

[0142]

[0143] In LTE systems, two different handover types are supported:

[0144] 1) Normal – The target eNB understands the source eNB’s configuration and continues to use that configuration, which may be updated.

[0145] 2) Full Configuration Switchover – The target eNB does not fully understand the access stratum (AS) configuration in the source eNB. The target eNB is configured with a complete new access stratum configuration.

[0146] In the NR system, it is assumed that switching between these two existing technologies is also supported.

[0147] According to an embodiment of the invention, normal handover may involve a combination of Level 1 QoS flow mobility and Level 2 QoS flow mobility as described above. This in Figure 12 As shown in the diagram. Here, on MeNB1, DRB1 640 carries QoS stream 1 and QoS stream 2, and DRB2 641 carries QoS stream 3 and QoS stream 4. Upon handover to MeNB2, DRB1 640 moves to DRB1 642 to carry QoS stream 1 and QoS stream 2. DRB2 641 moves to carry QoS stream 3 and QoS stream 4. Then, QoS stream 4 moves to DRB3 644. The original two DRBs on MeNB1 have been moved to three DRBs on MeNB2.

[0148] According to another embodiment of the present invention, Figure 13 The diagram illustrates a full configuration handover. In this type of handover, the entire AS configuration is released. As a result, all DRBs and QoS flow -> DRB mappings are released. Consequently, the DRB in the target eNB is the new DRB (i.e., no continuation, no PDCP reconstruction). The target eNB then instructs how to map different QoS flows to the new DRB based solely on Level 1 QoS mobility flows.

[0149] exist Figure 13The diagram shows a MeNB1 with DRB1 650, DRB2 651, and DRB3 652. DRB1 650 carries QoS stream 1 and QoS stream 2; DRB2 651 carries QoS stream 3; and DRB3 652 carries QoS stream 4. Upon switching to MeNB2, the new DRB1 653 carries QoS stream 1, and the new DRB2 654 carries QoS stream 2, QoS stream 3, and QoS stream 4.

[0150] During handover, it is necessary to consider the issue of Xn forwarding. Specifically, it is beneficial to consider whether it makes sense to forward all data in a specific GTP tunnel within the DRB during handover, as is done in existing LTE systems.

[0151] a) Use drb-id tags (e.g., drb id or drb-specific tunnel) or at least use an identifier that the target eNB can derive from its drb-id to forward packets that have been assigned a PDCP SN and may need to be retransmitted in the target eNB.

[0152] This is only performed if the relevant DRB continues in the target eNB.

[0153] b) For DL ​​packets that have not yet been transmitted, it is sufficient to forward them using the QoS flow ID (i.e., without DRB-specific tags / tunnels): the target eNB can perform mapping to the DRB.

[0154] It should be noted that if each DRB tunnel / forward is valid, the packet of type b) above can be forwarded in the tunnel of DRB1, but in reality the target eNB quickly remaps the QoS flow and eventually makes it process on a different DRB2.

[0155] It also takes into account the implementation where each PDU session has a tunnel, which can also have a tunnel for each PDU session on Xn during handover.

[0156] For all the toggle options described in this article, follow these steps:

[0157] On Xn during handover, each PDU session has a tunnel.

[0158] For packets that have already been attempted to be transmitted at the source, if the relevant DRB continues at the destination eNB, the forwarded PDU will contain:

[0159] Format 1: GTP header (identifies PDU session), QoS flow ID, PDCP SN, and IP packet.

[0160] For packets that were not attempted to be transmitted at the source, the forwarded PDU will contain:

[0161] Format 2: GTP header (identifies PDU session), QoS flow ID, and IP packet

[0162] In LTE, the target eNB can configure each DRB regardless of whether the packet should be forwarded. In NR, this type of configuration can be performed for each QoS flow.

[0163] However, in the case of DRB with RLC-AM, since it is not desirable to have a hole in the PDCP SN, the relevant DL packets should be forwarded anyway.

[0164] As a result, the following forwarding behaviors are applied for normal (incomplete configuration) handover, as shown in Table 2:

[0165]

[0166]

[0167] In the case of a full configuration switchover, the following forwarding behaviors should be applied as shown in Table 3:

[0168]

[0169] Has the packet already been transmitted in the source? Is QoS flow forwarding requested? The group that was forwarded 1 yes It doesn't matter Not being forwarded 3 no yes Format 2 4 no no Not being forwarded

[0170] Table 4 below shows three different handover examples focusing on QoS flows. Examples 1 and 2 involve normal handover, while example 3 is a fully configured handover.

[0171]

[0172]

[0173] In LTE, each DRB from the CN has an end-of-line marker packet. In NR, because the CN is not aware of the QoS flow -> DRB mapping, each QoS flow has an end-of-line marker packet. This results in a slight update to the target eNB's behavior in NR; that is, when the target eNB receives an end-of-line marker packet for a specific QoS flow, it does not mean that all services received from the CN for that DRB can be transmitted. In other words, only DL services belonging to that QoS flow can be transmitted.

[0174] Figure 14 This illustrates a sample configuration where the MeNB decides to move a complete PDU session to the SeNB. This allows it to work in conjunction with the [previous configuration / design]... Figure 7 The method described is similar to moving a tunnel endpoint in a similar way. This is functionally similar to (or the same as) moving all EPS bearers connected to a PDU from the MeNB to the SeNB in ​​an EPC.

[0175] However, this method has some drawbacks because it doesn't allow the MeNB to move only some QoS flows to the SeNB. For example, suppose a PDU session is handling both voice calls and best-effort data. The MeNB might want to move the best-effort data to the SeNB while maintaining the voice calls on the MeNB. This is not possible with this method. In practice, this approach may have limited applicability.

[0176] Figure 15 An alternative configuration according to an embodiment of the present invention is shown. Here, the MeNB requests the 5G-CN to establish a second backhaul tunnel for the same PDU session. Here, only a portion of the QoS flow of the PDU session is offloaded to / terminated at the SN. That is, the CN separates the traffic related to the PDU session using a separate tunnel to each RAN node involved.

[0177] This is illustrated by PDU session 2-a and PDU session 2-b. This second tunnel has a different IP address / TEID corresponding to the SeNB. The other PDU session 2-a is still routed through the MeNB. In this way, two parallel tunnels are established for a single PDU session.

[0178] Next, the MeNB requests the 5G-CN to move a specific QoS flow from tunnel 2-a to tunnel 2-b. In this case, i.e., when the RAN is connected to the 5G-CN, the smallest granularity known to the RAN is the QoS flow. The signaling required to manage and coordinate this process can reside in the control plane or in the user plane.

[0179] and Figure 14 Unlike previous implementations, Figure 15 The implementation method represents a more practical solution in most cases.

[0180] Assuming the NR DC architecture is suitable for connecting the RAN DC to the 5G-CN. This is as follows: Figure 15 As shown in the diagram. The new QoS architecture is applicable to the following DC scenarios: MeNB NR+SeNB NR; MeNB eLTE+SeNB NR; MeNB NR+SeNB eLTE; and MeNB eLTE+SeNB eLTE.

[0181] If the RAN is connected to the EPC, then the traditional LTE DC architecture is assumed to be applicable. This is as follows: Figure 7 As shown in the diagram, the DC types applicable to the traditional QoS architecture are: MeNB LTE+SeNB LTE; and MeNB LTE+SeNB NR.

[0182] Based on the preceding description, it is reasonable to consider whether supporting split bearers in the NR+NR DC scenario is still beneficial, given that PDU sessions can be segmented at the CN level.

[0183] This is Figure 16 The figure illustrates an NR+NR DC with a DRB segmented as represented by the connection between the MeNB and SeNB. Here, the RAN node segments the traffic carried by the DRB between the MCG and SCG. That is, some packets use the MCG tributary, while other packets are carried by the SCG tributary. Furthermore, QoS flows are carried via both tributaries, meaning that RAN segmentation can be QoS flow-agnostic. The figure also shows that some QoS flows can only be mapped to the DRB using either the MCG tributary or the SCG tributary.

[0184] It should be understood that, due to the lack of a common SN, PDU session segmentation at the 5G-CN level, as described, does not allow lossless QoS migration from MeNB to SeNB; therefore, segmented bearers remain useful. Furthermore, it does not allow the aggregation of MeNB+SeNB resources for a single QoS flow. Therefore, segmented bearers are useful and can still play an important role in network planning and configuration.

[0185] Previously, Xn forwarding during handover was described using a PDU session tunnel with the following PDU format:

[0186] Format 1: GTP header (identifies PDU session), QoS flow ID, PDCP SN, and IP packet.

[0187] Format 2: There are two options for GTP header (identifying PDU session), QoS stream ID, and IP packet for handling split bearer transmissions in NR+NR DC:

[0188] Option 1: PDU Session Tunnel

[0189] In this case, there is also a tunnel for each PDU session, and a third format is specified:

[0190] Format 3:

[0191] GTP header (identifying PDU session), DRB-ID, PDCP SN, and compressed / encrypted IP packets.

[0192] QoS flows are not needed in DL (the mapping to DRB has already been completed).

[0193] QoS flows are not available in UL (PDCP in MeNB and higher layers).

[0194] Option 2: DRB-level tunnel

[0195] Optionally, DRB-specific tunnels can be provided only for this segmented bearer scenario (as in LTE):

[0196] Because PDCP packets are involved, the PDCP PDUs forwarded between eNBs are primarily part of the bearer. Therefore, each DRB can have a tunnel, as in LTE.

[0197] The problem addressed in the embodiments of this invention is the management of DRB / QoS flows. In LTE, each EPS bearer / E-RAB has a DRB. The MeNB is responsible for determining the type of DRB, establishing the DRB, and releasing the DRB. In other words, the MeNB decides which type of DRB to establish, and whether the DRB is of type MCG, SCG, or segmented. In the case of SCG or segmented, the MeNB requests the SeNB to support the establishment of the required DRB. In this case, the SeNB performs Call Admission Control (CAC). If the SeNB accepts, it provides the SeNB with the detailed radio configuration of SCG (RLC and lower), and the MeNB transmits this detailed radio configuration to the UE.

[0198] However, in NR systems, the RAN has greater flexibility and / or responsibility regarding DRB creation. In NR, the RAN can decide whether to multiplex flows of the same PDU session on a DRB. This type of decision is made by a new layer called the Access Stratum Mapping layer (ASML).

[0199] ASML can be configured as a separate protocol layer, or alternatively, ASML can be set as a sublayer portion of PDCP.

[0200] In the LTE+LTE DC scenario, the MeNB is responsible for DRB management (i.e., establishment and release). The same approach is used when implementing DRB mobility (such as moving a bearer from MCG type to SCG type).

[0201] In the NR+NR DC scenario, the MeNB is responsible for managing all DRBs to the UE (i.e., MCG bearers, MCG segmented bearers, and SCG bearers) (establishment / type change / release).

[0202] It is generally not expected that the ASML layer in the SeNB will be allowed to autonomously handle the mapping of QoS flows to DRBs. To ensure that QoS flows can be processed without loss when moving between the SeNB and MeNB, it is important that the same QoS flow -> DRB mapping exists in both the MeNB and SeNB. That is, in this case, DRB movement can be performed instead of separate QoS flow movement.

[0203] If two different entities begin to independently determine the mapping of QoS flow -> DRB, the likelihood of lossless mobility is reduced.

[0204] It should be noted that in NR+NR DC, the MeNB controls the mapping of QoS flows to DRBs in both the MeNB and SeNB, that is, to map to any DRB type.

[0205] Figure 17 An implementation of this disclosure is illustrated, highlighting the ASML layer, which specifically relates to mapping QoS flows to DRBs. Here, the Master ASML running in the NR MeNB can be seen. In the control plane, it is responsible for all DRB management in both the MeNB and SeNB. It is also responsible for controlling the mapping of all QoS flows to DRBs from both the Master ASML and the Slave ASML running in the MeNB and SeNB respectively.

[0206] In the user plane, it performs QoS flow mapping to DRB for MCG DRB and MCG segmented DRB.

[0207] In the user plane, the mapping of QoS flows from ASML to DRB is performed in the SeNB for the SCG DRB.

[0208] It should be noted that with the addition of the ASML layer, the responsibilities of the MeNB and SeNB related to DRB management in the LTE+LTE DC are the same as in the NR+NR DC.

[0209] Table 5 below summarizes this situation:

[0210] Table 5

[0211] MCG carrier MCG segmentation bearer SCG bearing 1. Responsible for DRB management (creation, release, modification) MeNB MeNB MeNB 2. Responsible for ASML mapping configuration (only for NR+NR DC) MeNB MeNB MeNB 3. Responsible for PDCP configuration MeNB MeNB SeNB* 4. Responsible for lower-level configurations (RLC, MAC, L1) MeNB MeNB+SeNB SeNB*

[0212] Note that for entries marked as SeNB*, SeNB no longer receives QCI from SCG DRBs, but instead receives a set of QoS profiles that the DRB must support (belonging to the QoS flows mapped to the DRB). SeNB considers these QoS profiles when configuring lower layers.

[0213] The mapping of QoS flows (i.e., indicating which DRB is used to transmit packets) can be explicitly notified by signaling, or it can be done by a “reflection” method, whereby the signaling header includes QoS flow information.

[0214] Figures 18 to 20 The signal flow associated with the various implementations and illustrative examples described above is shown.

[0215] Figure 18 The signal flow associated with the MCG bearer -> SCG bearer movement is shown when a SeNB is added. This is an example of Level 1 mobility.

[0216] Figure 19 An example of Level 2 mobility is shown, where additional QoS flows move to the SeNB.

[0217] Figure 20 An example of Level 2 mobility in the user plane is shown, where in-band UP handover can be used on the NG to enable fast QoS flow handover between MeNB and SeNB.

[0218] For example, it can be used in execution Figure 19 The signaling sequence shown is for the case where QoS flow 3 is moved back to after the MeNB.

[0219] For example, it can also be used in situations where a SeNB is prepared for multiple QoS flows (even if these flows have not yet been moved to the SeNB) at the SeNB addition step (e.g., pre-establishing a DRB).

[0220] A potential problem may arise if DL packets on the new DRB arrive at the UE before the last retransmitted packet on the old DRB. In this case, the UE can ping-pong back the QoS flow to the old DRB. This is due to reflective QoS, where the UE adjusts the mapping of QoS flows to DRBs for the uplink based on the packets it receives in the downlink. In other words, if the UE receives packets for a given QoS flow on a DRB other than the previously used one, it can update the QoS flow mapping to DRBs, meaning it can use the most recently used DRB in the downlink to transmit subsequent packets of the relevant QoS flow in the uplink.

[0221] This could happen, for example, during a switchover. For instance, consider a source with 3 DRBs:

[0222] DRB1: QoS streams 1, 2, 3

[0223] DRB2: QoS streams 4 and 5

[0224] DRB3: QoS Stream 6

[0225] Suppose the target MeNB dislikes the mapping of QoS flows 1, 2, and 3 and wants to process QoS flow 3 at a separate DRB. Then, the target MeNB will signal with the following configuration:

[0226] Continue with DRB 1, 2, and 3 (if no other QoS flow migration is configured, the QoS flow will be migrated automatically along with it).

[0227] Establish DRB4

[0228] Move QoS flow 3 to DRB4

[0229] The target MeNB will receive packets for QoS flow 3 as part of a DRB1 forwarding (format 1 only for QoS flow 3) and as format 2 packets that should be transmitted on DRB2 in the target eNB. If the target eNB immediately begins sending packets on DRB2 while retransmissions on DRB1 are still in progress, the following may happen:

[0230] The UE receives packets for QoS flow 3 on DRB2. The UE updates its UL mapping and transmits UL packets for QoS flow 3 on DRB2.

[0231] Next, the UE receives packets (retransmitted) for QoS flow 3 on DRB1. The UE then updates its mapping again and sends UL packets for QoS flow 3 on DRB1.

[0232] Next, the UE receives DL packets for QoS flow 3 on DRB2, and so on.

[0233] It should be noted that even if we signal the QoS flow -> DRB mapping in the CP during handover, the same problem may still exist, namely, subsequent retransmissions may cause the UE to map the QoS flow back to the previous DRB (i.e., return (pong)):

[0234] The UE receives the updated mapping QOSflow3->DRB4 in the handover command.

[0235] Next, the UE receives DL packets for QoS flow 3 on DRB1, and the UE updates the mapping to DRB1 for QoS flow 3.

[0236] As can be seen from the following, synchronization errors and signaling problems may be spiral-shaped.

[0237] For networks, one solution to this problem is to ensure that it is not allowed to occur. This can be achieved in the following ways:

[0238] Intra-eNB: Waits for packets to be transmitted on the new DRB until the RLC confirms the sequential transmission of the relevant PDCP PDUs on the old DRB.

[0239] Handover: The behavior is the same as the Intra-eNB above, but the target eNB ensures this for Inter-MeNB / SeNB: This configuration makes it more difficult to guarantee. That is, the MeNB must stop DL transmissions on the MCG bearer, wait until delivery confirmation (assuming no forwarding, discarding all DL packets arriving at the same time), and only notify the CN to route via the SeNB after RLC confirmation.

[0240] Another solution is to use an in-band "Packets undergoing reflected QoS" tag. That is, this tag is set only for some packets on the new DRB, not for the last packets on the previous DRB. This may only result in some packets being delivered out of order to higher layers, but the UL QoS flow is not routed round-trip or back-and-forth.

[0241] The preferred option appears to be the second solution proposed above, which is also used in conjunction with CP signaling, for example:

[0242] The target eNB signal in the switching command stream must be moved from DRB1 to DRB2.

[0243] Immediately after switching:

[0244] UL: The UE routes packets only on DRB2.

[0245] DL: The UE can receive some packets (delayed retransmission) on DRB1 (without in-band indicator) (even in parallel) and be idle on DRB2 (with in-band indicator).

[0246] According to various embodiments of this disclosure, a method for managing data flows in a wireless communication system includes controlling the transmission of a Quality of Service (QoS) flow from a first Data Radio Bearer (DRB) to a second DRB. Here, the QoS flow is a data flow carried via a DRB between a terminal and at least one network entity.

[0247] According to various embodiments of this disclosure, multiple QoS flows of a terminal are routed sequentially, simultaneously, or in a combination of sequential and simultaneous routing via at least two network entities.

[0248] According to various embodiments of this disclosure, at least one QoS flow of a terminal is transmitted from a first network entity to a second network entity.

[0249] According to various embodiments of this disclosure, a QoS flow is transferred separately while at least one other QoS flow is maintained in the first DRB.

[0250] According to various embodiments of this disclosure, the first DRB is a source DRB, and the second DRB is a target DRB.

[0251] According to various embodiments of this disclosure, a QoS flow is transferred from a first DRB to a second DRB along with at least one other QoS flow.

[0252] According to various embodiments of this disclosure, a QoS flow and at least one other QoS flow:

[0253] Transfer from the source primary node (MN) or source cell to the target MN or target cell; transfer between the MN or cell and the secondary node (SN) or cell;

[0254] The bearer type was transferred from the primary cell set (MCG) type to the MCG segment type;

[0255] or

[0256] The transition will be made to comply with Long Term Evolution (LTE) and LTE-New Radio (NR).

[0257] According to various embodiments of this disclosure, the transfer of QoS flows is related to a handover from a source eNB to a target eNB. Here, the handover is either a normal handover or a fully configured handover. In a normal handover, the configuration in the source eNB can be used in the target eNB. In a fully configured handover, the target eNB is configured with a new access stratum configuration.

[0258] According to various embodiments of this disclosure, the target MN or cell determines whether to maintain the mapping of QoS flows to the DRB or to change the mapping of QoS flows to the DRB.

[0259] According to various embodiments of this disclosure, the MN determines whether to offload at least one QoS flow of a Packet Data Unit (PDU) session to the SN and requests the transfer of the QoS flow.

[0260] According to various embodiments of this disclosure, the MN offloads all QoS flows mapped to the relevant DRB to the SN.

[0261] According to various embodiments of this disclosure, when a QoS flow is transmitted from a first network entity to a second network entity, data packets are forwarded from the first network entity to the second network entity.

[0262] According to various embodiments of this disclosure, a method for managing data flows in a wireless communication network includes: generating a first backhaul tunnel between a network entity and a first node. Here, a second backhaul tunnel is established between the network entity and a second node, the first backhaul tunnel is associated with a Packet Data Unit (PDU) session, and the second backhaul tunnel is associated with a PDU session, and the network entity operates in a dual-connectivity configuration, in which communication between a terminal and the network entity is performed on the first node and the second node.

[0263] At least some of the example implementations described herein can be constructed, partially or entirely, using dedicated hardware. Terms such as “component,” “module,” or “unit” as used herein may include, but are not limited to, hardware devices that perform a particular task or provide related functionality, such as circuits, field-programmable gate arrays (FPGAs), or application-specific integrated circuits (ASICs) having discrete or integrated components. In some implementations, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to run on one or more processors. In some implementations, these functional elements may, by way of example, include components (e.g., software components, object-oriented software components, class components, and task components), processes, functions, attributes, procedures, subroutines, code snippets, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. While example implementations have been described with reference to the components, modules, and units discussed herein, these functional elements may be combined into fewer elements or divided into other elements. Various combinations of optional features have been described herein, and it should be understood that the described features can be combined in any suitable combination. Specifically, features of any exemplary embodiment may be suitably combined with features of any other embodiment, unless such combinations are mutually exclusive. Throughout the specification, the wording "comprising" or "including" is intended to include the specified components but does not exclude the presence of other components.

[0264] Furthermore, embodiments of the present invention may be limited in terms of methods, corresponding devices or apparatuses and programs used with computers.

[0265] It should be noted that all articles or documents submitted concurrently with or prior to this specification in connection with this application and publicly examined together with this specification, as well as the contents of all such articles or documents, are incorporated herein by reference.

[0266] All features disclosed in this specification (including any appended claims, abstracts and drawings) and / or all steps of any disclosed method or process may be combined in any combination unless such combination of at least some of these features and / or steps is mutually exclusive.

[0267] Unless otherwise expressly stated, each feature disclosed in this specification (including any appended claims, abstract, and drawings) may be replaced by an alternative feature for the same, equivalent, or similar purpose. Therefore, unless otherwise expressly stated, each disclosed feature is merely one example of a series of equivalent or similar features.

[0268] This invention is not limited to the details of the foregoing embodiments. The invention extends to any novel feature or any novel combination thereof disclosed in this specification (including any appended claims, abstract, and drawings), or to any novel step or any novel combination thereof in any of the steps of any disclosed method or process.

[0269] The methods according to the embodiments set forth in the claims and / or specification of this disclosure can be implemented in hardware, software, or a combination of hardware and software.

[0270] When these methods are implemented in software, a computer-readable storage medium may be provided for storing one or more programs (software modules). One or more programs stored in the computer-readable storage medium may be configured to be executed by one or more processors within an electronic device. At least one program may include instructions causing the electronic device to perform methods according to various embodiments of this disclosure as defined by the appended claims and / or disclosed herein.

[0271] The program (software module or software) may be stored in non-volatile memory, including random access memory and flash memory, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk storage devices, optical disc-ROM (CD-ROM), digital versatile disc (DVD) or other types of optical storage devices, or magnetic tape cassettes. Optionally, some or any combination of these may form a memory storing the program. Furthermore, multiple such memories may be included in an electronic device.

[0272] Furthermore, the program can be stored in an attachable storage device that can be accessed via a communication network such as the Internet, intranet, local area network (LAN), wide area network (WAN), and storage area network (SAN), or a combination thereof. This storage device can access electronic devices via an external port. Additionally, a separate storage device on the communication network can access portable electronic devices.

[0273] In the specific embodiments described above, the components included in this disclosure are represented in a singular or plural form, depending on the presented embodiments. However, the singular or plural form is chosen for ease of description suitable to the presented situation, and the various embodiments of this disclosure are not limited to a single element or multiple elements. Furthermore, multiple elements described in the description may be configured as a single element, or a single element in the description may be configured as multiple elements.

[0274] While this disclosure has been shown and described with reference to specific embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made in this disclosure without departing from its scope. Therefore, the scope of this disclosure should not be limited to these embodiments, but rather should be defined by the appended claims and their equivalents.

[0275] While this disclosure has been described using exemplary embodiments, various changes and modifications may be suggested to those skilled in the art. This disclosure is intended to include such changes and modifications that fall within the scope of the appended claims.

Claims

1. A method performed by a core network entity, the method comprising: Receive a session modification message from the master node MN, the session modification message being used to transfer at least one Quality of Service (QoS) flow of a Protocol Data Unit (PDU) session from the master node to the slave node SN, wherein the PDU session includes multiple QoS flows of the PDU session; and Send a response message to the MN. The session modification message includes information about the at least one QoS flow. The MN is configured with a first layer for mapping between QoS flows and data radio bearers (DRBs). The SN is configured with a second layer for mapping between QoS flows and DRBs, and The first layer and the second layer are configured for the PDU session to transfer at least one QoS flow of the PDU session between the MN and the SN.

2. The method according to claim 1, wherein, One or more of the multiple QoS flows are mapped to a segmented bearer in the SN.

3. The method according to claim 1, in, The QoS flow of the terminal is transferred from the MN to the SN, and The MN and the SN are connected to the fifth-generation core network 5GC.

4. The method according to claim 1, wherein, The session modification message includes information related to the tunnel of the SN, which is associated with the at least one QoS flow.

5. The method according to claim 1, further comprising: Receive another session modification message from the MN, the other session modification message being used to transfer at least one other QoS flow of the PDU session from the SN to the MN.

6. A method performed by a secondary node SN for dual connectivity in a wireless communication system, the method comprising: Receive additional request messages associated with at least one Quality of Service (QoS) flow of a Protocol Data Unit (PDU) session from the master node MN, in order to transfer the at least one QoS flow of the PDU session; In response to the additional request message, send an additional request confirmation message to the MN; as well as Receive the Radio Resource Control (RRC) reconfiguration complete message from the MN. The MN is configured with a first layer for mapping between QoS flows and data radio bearers (DRBs). The SN is configured with a second layer for mapping between QoS flows and DRBs, and The first layer and the second layer are configured for the PDU session to transfer at least one QoS flow of the PDU session between the MN and the SN.

7. The method according to claim 6, in, The additional request message includes uplink tunnel information used at the MN, and The additional request confirmation message includes downlink tunnel information used at the SN.

8. The method according to claim 6, further comprising: Perform a random access procedure with the user equipment (UE) to deliver packets of the at least one QoS flow of the PDU session.

9. The method according to claim 6, further comprising: If the additional QoS stream of the PDU session needs to be transferred, a modification request message associated with the additional QoS stream is received; as well as In response to the modification request message, a modification request confirmation message is sent.

10. The method according to claim 6, wherein, The at least one QoS flow that transfers the PDU session is determined by the MN, and the MN and the SN are connected to the fifth-generation core network 5GC.

11. A core network entity, comprising: At least one transceiver; as well as At least one processor is coupled to the at least one transceiver and configured to: Receive a session modification message from the master node MN, the session modification message being used to transfer at least one Quality of Service (QoS) flow of a Protocol Data Unit (PDU) session from the master node to the slave node SN, wherein the PDU session includes multiple QoS flows of the PDU session; and Send a response message to the MN. The session modification message includes information about the at least one QoS flow. The MN is configured with a first layer for mapping between QoS flows and data radio bearers (DRBs). The SN is configured with a second layer for mapping between QoS flows and DRBs, and The first layer and the second layer are configured for the PDU session to transfer at least one QoS flow of the PDU session between the MN and the SN.

12. The core network entity according to claim 11, wherein, One or more of the multiple QoS flows are mapped to a segmented bearer in the SN.

13. The core network entity according to claim 11, in, The QoS flow of the terminal is transferred from the MN to the SN, and The MN and the SN are connected to the fifth-generation core network 5GC.

14. The core network entity according to claim 11, wherein, The session modification message includes information related to the tunnel of the SN, which is associated with the at least one QoS flow.

15. The core network entity of claim 11, wherein the at least one processor is further configured to: Receive another session modification message from the MN, the other session modification message being used to transfer at least one other QoS flow of the PDU session from the SN to the MN.

16. A secondary node SN for dual connectivity in a wireless communication system, the SN comprising: At least one transceiver; as well as At least one processor is operatively coupled to the at least one transceiver and configured to: Receive additional request messages associated with at least one Quality of Service (QoS) flow of a Protocol Data Unit (PDU) session from the master node MN, in order to transfer the at least one QoS flow of the PDU session; In response to the additional request message, send an additional request confirmation message to the MN; as well as Receive the Radio Resource Control (RRC) reconfiguration complete message from the MN. The MN is configured with a first layer for mapping between QoS flows and data radio bearers (DRBs). The SN is configured with a second layer for mapping between QoS flows and DRBs, and The first layer and the second layer are configured for the PDU session to transfer at least one QoS flow of the PDU session between the MN and the SN.

17. The SN according to claim 16, in, The additional request message includes uplink tunnel information used at the MN, and The additional request confirmation message includes downlink tunnel information used at the SN.

18. The SN according to claim 16, wherein, The at least one processor is further configured to: Perform a random access procedure with the user equipment (UE) to deliver packets of the at least one QoS flow of the PDU session.

19. The SN according to claim 16, wherein, The at least one processor is further configured to: If the additional QoS stream of the PDU session needs to be transferred, a modification request message associated with the additional QoS stream is received; and In response to the modification request message, a modification request confirmation message is sent.

20. The SN according to claim 16, wherein, The at least one QoS flow that transfers the PDU session is determined by the MN, and the MN and the SN are connected to the fifth-generation core network 5GC.

Images