Guaranteed bitrate QoS flow for guiding, switching, and segmenting access traffic
The system optimizes GBR flows by managing transitions and adjusting bitrate conditions across multiple access nodes, enhancing QoS assurance in mobile communication systems.
Patent Information
- Application Number
- JP2026507721
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-08-10
- Filing Date
- 2024-08-09
- Publication Date
- 2026-08-25
AI Technical Summary
Existing mobile communication systems face challenges in efficiently managing guaranteed bitrate (GBR) flows across multiple access nodes, leading to inefficiencies in traffic handling and quality of service (QoS) assurance.
The system employs network nodes to manage transitions between redundant inductive modes, adjust guaranteed bitrate conditions, and apply scaling factors based on overlap information to optimize GBR flows across primary and secondary access nodes.
This approach enhances the management of GBR flows, ensuring consistent QoS by dynamically adjusting bitrate conditions and optimizing resource allocation across multiple access points.
Smart Images

Figure 2026528814000001_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to guaranteed bit rate type QoS flows for guiding, switching, and splitting access traffic.
Background Art
[0002] This application claims priority to U.S. Provisional Application No. 63 / 531,878, filed on August 10, 2023, the content of which is incorporated herein by reference.
[0003] Mobile communications using wireless communications are continuing to evolve. The fifth generation of mobile communication radio access technology (RAT) may be referred to as 5G New Radio (NR). Examples of previous (legacy) generations of mobile communication RATs include, for example, the fourth generation (4G) Long Term Evolution (LTE).
Brief Description of the Drawings
[0004] [Figure 1A] It is a system diagram showing an exemplary communication system in which one or more disclosed embodiments can be implemented. [Figure 1B] It is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that can be used within the communication system shown in FIG. 1A according to one embodiment. [Figure 1C] It is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that can be used within the communication system shown in FIG. 1A according to one embodiment. [Figure 1D] It is a system diagram showing a further exemplary radio access network (RAN) and a further exemplary core network (CN) that can be used within the communication system shown in FIG. 1A according to one embodiment. [Figure 2] It is a diagram showing an exemplary WTRU with multiple simultaneous access methods. [Figure 3] It is a diagram showing an exemplary WTRU with multiple simultaneous access methods. [Figure 4] This figure shows an example of a gap in transmission under the first access method. [Figure 5] This figure illustrates an exemplary technique for configuring a Multi-Access Protocol Data Unit (MA-PDU) session for a Guaranteed Bitrate (GBR) Quality Assurance (QoS) flow. [Modes for carrying out the invention]
[0005] This specification discloses systems, methods, and means for guiding, switching, and segmenting access traffic of guaranteed bitrate (GBR) flows.
[0006] An exemplary network node may receive a first message from a device. The first message may indicate a transition from a first to a second state of redundant inductive mode (RSM), and the duration for which the RSM intends to remain in the second state. In the first state, the device may transmit through the first and second access nodes. In the second state, the device may transmit through the first access node only. The network node may decide to change the guaranteed bitrate conditions of the second access node. In response to the first message, the network node may send a second message to the second access node. The second message may indicate a change in the guaranteed bitrate conditions of the second access node.
[0007] The lifetime may be a first lifetime. The change may be a first change. The network node may receive a third message from the device. The third message may indicate that the RSM is transitioning from a second state to a first state, and a second lifetime during which the RSM intends to remain in the first state. The network node may decide on a second change to the guaranteed bitrate condition of the second access node. In response to the third message, the network node may send a fourth message to the second access node. The fourth message may indicate at least one of the transition of the RSM from a second state to a first state, a second change to the guaranteed bitrate condition of the second access node, or a second lifetime.
[0008] In the first state, the network node may receive overlap information from the device, which indicates the proportion of the total amount of overlapping traffic between the first and second access nodes.
[0009] The network node may determine a guaranteed bitrate scaling factor based on a percentage and then decide to change the guaranteed bitrate conditions of the second access node by sending the guaranteed bitrate scaling factor to the second access node.
[0010] The network node may determine a guaranteed bitrate scaling factor based on the transition from the first state to the second state, and then determine a change to the guaranteed bitrate condition of the second access node by scaling the guaranteed bitrate condition based on the guaranteed bitrate scaling factor.
[0011] The second message may indicate that the RSM has transitioned from the first state to the second state, or at least one of the durations.
[0012] The guaranteed bitrate condition may be associated with at least one of the overlap rate at the second access node, the overlap state at the second access node, or the bitrate measurement at the second access node.
[0013] The first access node may be the primary access node. The second access node may be a secondary access node. The network node may decide to change the second access node to the primary access node and the first access node to a secondary access node.
[0014] The network node may decide to change the second access node to the primary access node and the first access node to the secondary access node based on the fact that the first access node does not meet the guaranteed bitrate threshold.
[0015] An exemplary device may receive a Multi-Access Protocol Data Unit (MA-PDU) session establishment request from a Wireless Transceiver Unit (WTRU). The MA-PDU session establishment request may indicate that the WTRU supports Guaranteed Bitrate (GBR) support information. The device may select a static redundancy induction mode for the MA-PDU session with the primary access node. Based on the static redundancy induction mode and the indication that the WTRU supports GBR support information, the device may determine GBR processing information. The device may transmit a Quality of Service (QoS) profile to the primary and secondary access nodes. The QoS profile may include GBR processing information. Based on the satisfaction of certain conditions, the device may determine updated GBR parameters (e.g., requirements) and updated GBR processing information for the secondary access node. The device may transmit an updated QoS profile showing the updated GBR parameters (e.g., requirements) and updated GBR processing information to the secondary access node.
[0016] GBR support information may include measurements for GBR optimization on secondary access nodes. GBR processing information may indicate one or more of the following: primary or secondary states of primary and secondary access nodes, GBR scaling factors, or user plane security policies. Conditions may be associated with the overlap rate on secondary access nodes, the overlap state on secondary access nodes, or bitrate measurements on secondary access nodes.
[0017] Figure 1A is a system diagram showing a typical communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), quadrature FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tail unique word DFT spread OFDM (ZT UW DTSs-s OFDM), unique word OFDM (UW-OFDM), resource block filtering OFDM, filter bank multicarrier (FBMC), etc.
[0018] As shown in Figure 1A, the communication system 100 may include radio transceiver units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments assume any number of WTRUs, base stations, networks, and / or network elements. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d (all sometimes referred to as “stations” and / or “STAs”) are configured to transmit and / or receive radio signals and may include user equipment (UEs), mobile stations, fixed or mobile subscriber equipment, subscriber-based equipment, pagers, mobile phones, PDAs (personal digital assistants), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches and other wearables, HMDs (head-mounted displays), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronic devices, and devices operating on commercial and / or industrial wireless networks. Any WTRU102a, 102b, 102c, or 102d may be referred to interchangeably with UEs.
[0019] The communication system 100 may include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be a device for facilitating access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112, of any type configured to wirelessly interface with at least one WTRU 102a, 102b, 102c, 102d. As an example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B, eNode B, Home Node B, Home eNode B, gNB, NR Node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are shown as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.
[0020] Base station 114a may be part of a radio access network (RAN) 104 / 113 and may include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), and relay nodes. Base stations 114a and / or base stations 114b may be configured to transmit and receive radio signals on one or more carrier frequencies (which may be called cells (not shown)). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a particular geographic area that may be relatively fixed or change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers (i.e., one for each sector of the cell). In one embodiment, base station 114a may employ multi-input multi-output (MIMO) technology and utilize multiple transceivers for each sector of the cell or any sector. For example, beamforming can be used to transmit and receive signals in a desired spatial direction.
[0021] Base stations 114a, 114b may communicate with one or more WTRUs 102a, 102b, 102c, 102d via an airborne interface 116. The airborne interface 116 may be any suitable radio communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The airborne interface 116 may be established using any suitable radio access technology (RAT).
[0022] More specifically, as described above, the communication system 100 is a multiple access system and may employ one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and WTRUs 102a, 102b, 102c within RAN104 / 113 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) that can establish air interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed Downlink (DL) Packet Access (HSDPA) and / or High Speed UL Packet Access (HSUPA).
[0023] In one embodiment, the base stations 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA) and may establish air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).
[0024] In one embodiment, the base stations 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as NR radio access and may establish air interface 116 using New Radio (NR).
[0025] In one embodiment, the base stations 114a and WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base stations 114a and WTRUs 102a, 102b, 102c may implement both LTE radio access and NR radio access using, for example, the Dual Connectivity (DC) principle. Thus, the air interfaces utilized by WTRUs 102a, 102b, 102c may be characterized by transmissions that are sent and received between multiple types of radio access technologies and / or multiple types of base stations (e.g., eNB and gNB).
[0026] In another embodiment, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), and GSM EDGE (GERAN).
[0027] The base station 114b shown in Figure 1A is, for example, a wireless router, Home Node-B, Home eNode-B, or access point, and may utilize any suitable radio access technology (RAT) to facilitate wireless connectivity in local areas such as businesses, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drones), and roads. In one embodiment, the base station 114b and WTRU 102c, 102d may implement radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d may implement radio technology (e.g., IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d can establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.
[0028] A Radio Access Network (RAN) 104 / 113 may communicate with a Core Network (CN) 106 / 115 and may be any type of network configured to provide voice, data, applications, and / or voice over the Internet Protocol (VoIP) services to one or more Wireless Terminal Units (WTRUs) 102a, 102b, 102c, and 102d. The data may have various Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN 106 / 115 may provide call control, billing services, mobile location services, prepaid calls, internet connectivity, video streaming, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it is understood that RAN 104 / 113 and / or CN 106 / 115 may communicate directly or indirectly with another RAN employing the same Radio Access Technology (RAT) as RAN 104 / 113 or a different RAT. For example, in addition to being connected to RAN104 / 113 which may be using NR radio technology, CN106 / 115 may also communicate with other RANs (not shown) employing GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi radio technology.
[0029] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or another network 112. PSTN108 may include a circuit-switched telephone network providing conventional telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless networks owned and / or operated by another service provider. For example, network 112 may include another CN connected to one or more RANs, which may employ the same or different radio access technology (RAT) as RAN104 / 113.
[0030] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode functionality (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a which may employ cellular-based radio technology and base station 114b which may employ IEEE 802 radio technology.
[0031] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transceiver element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripherals 138, etc. It will be understood that the WTRU 102 may include any combination of the aforementioned elements, while maintaining consistency with the embodiment.
[0032] The processor 118 could be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors working with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be connected to a transceiver 120 which may be connected to a transceiver element 122. Although the processor 118 and the transceiver 120 are shown as separate components in Figure 1B, it will be understood that the processor 118 and the transceiver 120 may be integrated, for example, within an electronic package or chip.
[0033] The transmitting / receiving element 122 may be configured to transmit signals to a base station (e.g., base station 114a) or to receive signals from a base station via the radio interface 116. For example, in one embodiment, the transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmitting / receiving element 122 may be a light-emitting / photo-receiving element configured to transmit and / or receive, for example, infrared, ultraviolet, or visible light signals. In yet another embodiment, the transmitting / receiving element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmitting / receiving element 122 may be configured to transmit and / or receive any combination of radio signals.
[0034] In Figure 1B, the transmit / receive element 122 is shown as a single element, but the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals via the radio interface 116.
[0035] The transceiver 120 may be configured to modulate the signal transmitted by the transceiver element 122 and demodulate the signal received by the transceiver element 122. As mentioned above, the WTRU 102 may have multimode capabilities. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR or IEEE 802.11.
[0036] The processor 118 of the WTRU102 is connected to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from them. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 can access information and store data from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identification module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In another embodiment, the processor 118 may access information and store data from memory that is not physically located on the WTRU 102 (for example, on a server or home computer (not shown)).
[0037] The processor 118 may be configured to receive power from the power supply 134 and to distribute and / or control power to other components within the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), a solar cell, a fuel cell, etc.
[0038] The processor 118 may also be connected to a GPS chipset 136 which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or alternative to the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the radio interface 116 and / or determine its position based on the timing of signals received from two or more neighboring base stations. It will be understood that the WTRU 102 may acquire location information by any suitable positioning method while remaining consistent with this embodiment.
[0039] The processor 118 may be connected to other peripherals 138 and may further include one or more software and / or hardware modules that provide additional functions, performance, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. Peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a compass sensor, a proximity sensor, a temperature sensor, a time sensor, a position sensor, an altimeter, a light sensor, a touch sensor, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.
[0040] WTRU102 may include a full-duplex radio in which some or all of the signals (e.g., signals associated with specific subframes in both UL (e.g., for transmission) and downlink (e.g., for reception)) are transmitted and / or received in parallel. This full-duplex radio includes an interference management unit that reduces and / or substantially eliminates self-interference through signal processing by hardware (e.g., chokes) or a processor (e.g., a separate processing unit (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio in which some or all of the signals (e.g., signals associated with specific subframes in either UL (e.g., for transmission) or downlink (e.g., for reception)) are transmitted and received.
[0041] Figure 1C is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 may employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via the radio interface 116. RAN104 may also communicate with CN106.
[0042] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that it may include any number of eNode-B while maintaining consistency with the embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, for example, eNode-B160a may use multiple antennas for transmitting radio signals to and / or receiving radio signals from WTRU102a.
[0043] Each eNode-B160a, 160b, and 160c may be associated with a specific cell (not shown) and configured to handle decisions regarding radio resource management, handover decisions, and user scheduling on the uplink (UL) and / or downlink (DL). As shown in Figure 1C, the eNode-B160a, 160b, and 160 can communicate with each other via the X2 interface.
[0044] The CN106 shown in Figure 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although each of the aforementioned elements is shown as part of CN106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.
[0045] The MME162 can be connected to each eNode-B162a, 162b, and 162c within RAN104 via the S1 interface and function as a control node. For example, the MME162 may be responsible for user authentication of WTRU102a, 102b, and 102c, enabling / disabling bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may also provide control surface functions for switching between RAN104 and another RAN (not shown) employing other radio technologies such as GSM and / or WCDMA.
[0046] The SGW164 can be connected to each eNode-B160a, 160b, and 160c within RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions, such as anchoring the user plane during eNode-B handovers, triggering pazing when DL data becomes available for WTRU102a, 102b, and 102c, and managing and saving the context of WTRU102a, 102b, and 102c.
[0047] SGW164 is connected to PGW166, and PGW166 may provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, in order to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.
[0048] CN106 may facilitate communication with other networks. For example, CN106 may provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional fixed communication equipment. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 may provide WTRU102a, 102b, and 102c with access to another network 112, which may include another wired and / or wireless network owned and / or operated by another service provider.
[0049] Although the WTRU is described as a wireless terminal in Figure 1A-1D, in certain representative embodiments, such a terminal may use a wired communication interface with a communication network (e.g., temporarily or permanently).
[0050] In a typical embodiment, the other network 112 may be a WLAN.
[0051] A wireless LAN (WLAN) in Infrastructure Basic Service Set (BSS) mode may have access points (APs) for the BSS and one or more stations (STAs) associated with those APs. The APs may have access to or interfaces with a distributed system (DS) or another type of wired / wireless network responsible for sending and receiving traffic to and from the BSS. Traffic sent from outside the BSS to an STA may arrive via the AP and be transmitted to the STA. Traffic sent from an STA to outside the BSS may be transmitted to the AP and then to its respective destination. Inter-STA traffic within the BSS may be transmitted via the AP, for example, with the source STA sending traffic to the AP, and the AP sending traffic to the destination STA. Inter-STA traffic within the BSS may be considered, or referred to as, peer-to-peer traffic, which may be transmitted between the source STA and the destination STA (e.g., directly) using a Direct Link Setup (DLS). In certain representative embodiments, the DLS may be an 802.11e DLS or an 802.11z Tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have access points (APs), and STAs within or utilizing IBSS (e.g., all STAs) communicate directly with each other. In this specification, the IBSS communication mode is sometimes referred to as the "ad-hoc" communication mode.
[0052] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be of a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS, and an STA may be used to establish a connection with the AP. In a typical embodiment, for example, in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented. In CSMA / CA, STAs, including the AP (e.g., all STAs), may sense the primary channel. If a particular STA senses / detects or determines that the primary channel is occupied, that STA may backoff. In a particular BSS, only one STA (e.g., only one station) may transmit at any given time.
[0053] A high-throughput (HT) STA can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.
[0054] Ultra-high-throughput (VHT) STAs may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. 160 MHz channels can be formed by combining eight consecutive 20 MHz channels, or by combining two discontinuous 80 MHz channels, the latter sometimes referred to as an 80+80 configuration. In an 80+80 configuration, channel-encoded data may pass through a segment parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) and time-domain processing may be performed individually for each stream. The streams may be mapped to two 80 MHz channels, and data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the processing of the 80+80 configuration described above may be performed in reverse order, and the combined data may be sent to Media Access Control (MAC).
[0055] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. 802.11af and 802.11ah reduce the channel operating bandwidth and carrier compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5MHz, 10MHz, and 20MHz in the TV white space (TVWS) spectrum, while 802.11ah supports bandwidths of 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices in a macro coverage area. MTC devices may have limited functionality, including support for specific bandwidths and / or limited bandwidths (e.g., only support for those). MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).
[0056] A WLAN system that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) may include a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs in operation within the BSS. In the 802.11ah example, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or their other channel bandwidth operating modes, the primary channel may be 1MHz wide for an STA that supports only 1MHz mode (e.g., an MTC type device). Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. For example, if the primary channel is occupied because an STA that supports only 1MHz operating mode is transmitting to an AP, the entire potentially available frequency band may be considered occupied, even if a large portion of the available frequency band is available in an idle state.
[0057] In the United States, the available frequency band that can be used by 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is from 6 MHz to 26 MHz, depending on the country code.
[0058] Figure 1D is a system diagram showing RAN113 and CN115 according to one embodiment. As described above, RAN113 may employ NR radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN113 may also communicate with CN115.
[0059] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs to the extent that it maintains consistency with the embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a, 180b, and 180c may utilize beamforming to transmit signals to and / or receive signals from gNB180a, 180b, and 180c. Thus, for example, gNB180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple constituent carriers to WTRU102a (not shown). A subset of these constituent carriers may be on the unlicensed spectrum, while the remaining constituent carriers may be on the licensed spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multipoint (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).
[0060] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerical systems. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTI) of varying or scalable lengths (e.g., those containing a variable number of OFDM symbols and / or those continuing absolute time of a variable length).
[0061] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with NB180a, 180b, and 180c without accessing another radio access network (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can use one or more gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in an unlicensed bandwidth. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with / connect to gNB180a, 180b, and 180c while simultaneously communicating with / connecting to other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles and communicate substantially simultaneously with one or more gNB180a, 180b, and 180c and one or more eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c function as mobility anchors for WTRU102a, 102b, and 102c, while gNB180a, 180b, and 180c may provide additional coverage and / or throughput in servicing WTRU102a, 102b, and 102c.
[0062] Each gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plan Functions (UPFs) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, and the like. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.
[0063] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and possibly a Data Network (DN)185a, 185b. While each of the aforementioned elements is shown as part of the CN115, it should be noted that any of these elements may be owned and / or operated by entities other than the CN operator.
[0064] AMF182a and 182b may be connected to one or more of gNB180a, 180b, and 180c within RAN113 via the N2 interface and may function as control nodes. For example, AMF182a and 182b may be responsible for user authentication of WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slicing may be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the types of services used by WTRU102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on ultra-reliable low-latency communication (URLLC) access, services that rely on enhanced large-scale mobile broadband (eMBB) access, and services for machine-type communication (MTC) access. The AMF162 may provide control plane functions for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and non-3GPP access technologies such as Wi-Fi.
[0065] SMF183a and 183b may be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b may also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b may select and control UPF184a and 184b and configure the routing of traffic passing through UPF184a and 184b. SMF183a and 183b may perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, enforcing policies and controlling QoS, and providing downlink data notifications. PDU session types may be IP-based, non-IP-based, Ethernet-based, etc.
[0066] UPF184a, 184b may be connected to one or more gNB180a, 180b, 180c in RAN113 via the N3 interface, for example, to provide WTRU102a, 102b, 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, 102c and IP-enabled devices. UPF184a, 184b may perform other functions such as packet routing and forwarding, application of user plane policies, support for multi-homed PDU sessions, processing of user plane QoS, buffering of downlink packets, and provision of mobility anchors.
[0067] CN115 can facilitate communication with other networks. For example, CN115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN115 and PSTN108. In addition, CN115 may provide WTRU102a, 102b, 102c with access to another network 112, including another wired and / or wireless network owned and / or operated by another service provider. In one embodiment, WTRU102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b via an N3 interface to UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.
[0068] Referring to Figures 1A-1D and the corresponding description, for WTRU102a-d, base stations 114a-b, eNode-B160a-c, MME162, SGW164, PGW166, gNB180a-c, AMF182a-b, UPF184a-b, SMF183a-b, DN185a-b, and / or any of its other devices described herein, one or more, or all, of the functions described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate some or all of the functions described herein. For example, an emulation device may be used to test another device and / or to simulate network and / or WTRU functions.
[0069] Emulation devices may be designed to implement one or more tests against another device in an experimental environment and / or a telecommunications carrier network environment. For example, one or more emulation devices may perform one or more functions, or all of them, to test another device in a communication network while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network. One or more emulation devices may perform one or more functions, or all of them, while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Emulation devices may be directly connected to another device for testing purposes, and tests may be performed using wireless airborne communications.
[0070] One or more emulation devices may perform one or more functions (including all of them) in a state where they are not implemented / deployed, for example, as part of a wired and / or wireless communication network. For example, emulation devices may be used to implement testing of one or more components in a test scenario in a test laboratory or in a non-deployed (e.g., for testing) wired and / or wireless communication network. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by emulation devices to transmit and / or receive data.
[0071] In this specification, the term "timer" may mean time, period, measurement of time, measurement of a period, combination thereof, and / or similar. In this specification, the term "timer expires" may mean determining that the time has arrived or that the period has expired.
[0072] Guaranteed Bitrate (GBR) parameters (e.g., specifications or requirements) may be set. GBR parameters may be maintained.
[0073] The Session Management Function (SMF) may support Multi-Access Protocol Data Unit (MA-PDU) sessions.
[0074] The SMF may receive an MA-PDU session establishment request from the WTRU. The MA-PDU session establishment request may include information indicating that the WTRU supports GBR (e.g., GBR optimization).
[0075] SMF may decide to use static redundancy induction mode (e.g., with primary access) for MA-PDU sessions.
[0076] SMF can determine GBR processing (GBRH) information (for example, based on the selected induction mode or suggestion that WTRU supports information to assist in GBR optimization).
[0077] SMF can provide access traffic routing, switching, and partitioning (ATSSS) rules to WTRUs. SMF can provide N4 rules to User Plane Functions (UPF). SMF can provide QoS profiles to Radio Access Network (RAN) nodes. QoS profiles may include GBRH information.
[0078] SMF can determine GBR parameters (e.g., new GBR specifications or requirements) for secondary access RAN nodes. For example, SMF can determine GBR parameters (e.g., new GBR specifications or requirements) for secondary access RAN nodes based on a GBR parameter change trigger. SMF can provide updated QoS profiles to RAN nodes.
[0079] Supporting information for GBR optimization may include measurements specific to GBR optimization (e.g., measurements via secondary access nodes).
[0080] GBRH information may include indications of whether a RAN node is a secondary access node, GBR scaling factors, user plane (UP) security policies, and / or similar information.
[0081] Triggers for changes in GBR parameters (e.g., specifications or requirements) may include monitored duplication rates on secondary access nodes, duplication status on secondary access nodes, bitrate measurements on secondary access, and / or similar factors.
[0082] ATSSS may be used (for example, in 3GPP).
[0083] A WTRU may support one or more types of access (e.g., both 3GPP and non-3GPP access). This capability can provide network operators with flexibility (e.g., when deciding which access to use for service data flows). In some embodiments (e.g., Release 15), if a WTRU uses multiple (e.g., both) access methods, the WTRU may (e.g., be required to) establish a separate Single Access (SA) PDU session for each access method.
[0084] Figure 2 shows an exemplary WTRU with multiple access methods (e.g., simultaneous 3GPP and non-3GPP access in Release 15).
[0085] This architecture may lack flexibility (for example, it may not be able to fully utilize its flexibility). In some examples (e.g., Release 16), MA-PDU sessions may be used. MA-PDUs make it easier to route, switch, or split uplink and downlink traffic of service data flows between access types (for example, as shown in Figure 3). An MA-PDU session may refer to a PDU session with traffic that can be transmitted through multiple access types (e.g., 3GPP access, non-3GPP access, or both access types).
[0086] Figure 3 shows an exemplary WTRU with multiple access methods (for example, simultaneous use of 3GPP and non-3GPP access in Release 16).
[0087] This architecture (for example, introduced in release 16 and further enhanced in release 17) is shown in Figure 3. This architecture can enable the following ATSSS functions:
[0088] The functions of ATSSS may include access traffic guidance. Access traffic guidance may include selecting an access network for a data flow (e.g., a new data flow). Access traffic guidance may include forwarding the traffic of the data flow through the selected access network. Access traffic guidance may be applicable between different access types (e.g., 3GPP and non-3GPP access types).
[0089] ATSSS functionality may include access traffic switching. Access traffic switching may involve moving the traffic of an ongoing data flow (e.g., all traffic) from one access type (e.g., one access network) to another access type (e.g., another access network). The data flow may be migrated while maintaining its continuity. Access traffic switching may be applicable to different access types (e.g., 3GPP and non-3GPP access types).
[0090] ATSSS functionality may include access traffic segmentation. Access traffic segmentation may involve dividing the traffic of a data flow across multiple access networks. When traffic segmentation is applied to a data flow, some of the traffic in that data flow may be forwarded through a specific access type (e.g., one access type), while other traffic in the same data flow may be forwarded through a different access type. Access traffic segmentation may be applicable between different access types (e.g., 3GPP and non-3GPP access types).
[0091] In ATSSS-enabled WTRUs, the guidance function can guide, switch, and / or split MA-PDU session traffic between multiple access methods (e.g., 3GPP access and non-3GPP access). One or more (e.g., two) guidance functions may be used (e.g., as standardized in Release 17). A first example of a guidance function may be a high-level guidance function. A high-level guidance function may operate above the Internet Protocol (IP) layer. A guidance function may be based on the Multipath Transmission Control Protocol (MPTCP) (e.g., sometimes referred to as an "MPTCP function"). An MPTCP function may be applicable to TCP traffic (e.g., applicable only to TCP traffic). A second example of a guidance function is a low-level guidance function that operates below the IP layer. One type of low-level guidance function may be used (e.g., in Release 17). A low-level function may be referred to as an "ATSSS low-level function" (ATSSS-LL function). An ATSSS-LL function may be applicable to Ethernet and / or IP (e.g., TCP and UDP). Induction functionality may be present in multiple devices (e.g., endpoints of a PDU session, specifically both WTRU and UPF).
[0092] One or more guidance modes may be permitted (e.g., using the guidance functions described above). The guidance mode may determine how traffic for a matched service data flow is distributed (e.g., between different access types, e.g., between 3GPP and non-3GPP access types). Supported guidance modes (e.g., as of release 16) may include one or more of the following:
[0093] The induction mode can be based on the active-standby mode. Active-standby mode can be used, for example, to direct traffic to a certain access type (e.g., active access) when that access type is available. Active-standby mode can also be used to switch traffic to another access type (e.g., standby access) when, for example, active access becomes unavailable.
[0094] The guidance mode may be based on delay (e.g., minimum delay). Delay may be used to guide traffic to the access with the minimum round-trip time (RTT) (e.g., determined to be the minimum). WTRU and UPF may be used to measure RTT (e.g., to determine which access has the lowest RTT). Access may be used for non-GBR service data flows (SDFs) (e.g., only for non-GBR service data flows).
[0095] The induction mode may be based on load balancing. Load balancing can be used to split traffic into access types (e.g., both access types). For example, load balancing can be used to split traffic between access methods based on the proportion of traffic sent through a first access method (e.g., 3GPP access) and the proportion of traffic sent through a second access method (e.g., non-3GPP access). Load balancing may be applicable to non-GBR SDF (e.g., applicable only to non-GBR SDF).
[0096] The guidance mode can be priority-based. In this case, the guidance mode can guide traffic (e.g., all traffic) that matches policies, billing, and control (PCC) parameters (e.g., specifications, requirements, PCC rules, etc.) to a high-priority access type (e.g., until it is determined that the high-priority access is congested). If the high-priority access type is congested, the traffic is sent to a lower-priority access type (e.g., the traffic is split into two access types). Priority-based guidance modes can be used for non-GBR SDFs (e.g., exclusively).
[0097] The guidance mode may be enhanced (e.g., in Release 17). For load balancing guidance mode, a guidance mode indicator may be added (e.g., in 3GPP). The guidance mode indicator may indicate that the WTRU can change the default guidance parameters (e.g., those provided by the guidance mode component) and / or adjust traffic guidance (e.g., based on the WTRU's own decisions). A guidance mode indicator (e.g., one of the steering mode indicators below) may be provided.
[0098] Inductive mode indicators may include autonomous load balancing indicators. If autonomous load balancing indicators are provided, the WTRU may ignore the proportion within the inductive mode component (e.g., the default proportion provided by the network). In this case, the WTRU may (e.g., autonomously) determine the proportion for traffic splitting (e.g., in a way that maximizes total bandwidth in the uplink direction).
[0099] Induction mode indicators may include WTRU-assisted indicators. If WTRU-assisted indicators are provided (e.g., by the network), the WTRU may determine how to distribute traffic (e.g., uplink traffic for matching SDFs). For example, the WTRU may determine how to distribute traffic based on its internal state. For example, if the WTRU is in a certain internal state (e.g., low battery), the WTRU may determine how to distribute traffic. The WTRU may indicate (e.g., to the UPF) how it has decided to distribute the uplink traffic for matching SDFs. In some cases (e.g., even if WTRU-assisted indicators are provided), the WTRU may still distribute uplink traffic as indicated by the network.
[0100] For load balancing induction modes, thresholds may be provided (e.g., according to 3GPP). These thresholds may be RTT values and / or packet loss rate (PLR) values. Thresholds may apply to multiple access types (e.g., both access types). Thresholds may be applied by WTRU and / or UPF. If a metric parameter (e.g., at least one metric parameter, e.g., RTT and / or PLR) in an access type (e.g., one access) exceeds a set threshold, the WTRU and / or UPF may stop transmitting traffic in that access type. If a metric parameter (e.g., at least one metric parameter, e.g., RTT or PLR) in an access type exceeds a predetermined threshold, the WTRU and / or UPF may continue transmitting traffic in that access type and reduce the traffic in that access type (e.g., by an implementation-specific amount). The WTRU and / or UPF may send the reduced amount of traffic (e.g., the remaining traffic after traffic reduction in the determined access type) to another access type. If the measurement parameters for one or more (e.g., both) access types (e.g., all measurement parameters, e.g., RTT and / or PLR) do not exceed a predetermined threshold, then a fixed split ratio may be applied to WTRU and / or UPF.
[0101] In priority-based guidance modes, thresholds may be provided (e.g., according to 3GPP). The thresholds may be RTT values and / or PLR values. These thresholds may apply to multiple access types (e.g., both access types). Thresholds may be applicable by WTRU and / or UPF. Thresholds may be considered by WTRU and / or UPF to determine whether an access has become confused. For example, if a metric parameter (e.g., RTT or PLR) for a certain access type (e.g., one access) exceeds a given threshold, WTRU and / or UPF may consider that access type to be confused. In this case, WTRU and / or UPF may send traffic (e.g., remaining traffic) to a lower priority access type.
[0102] Rules (e.g., ATSSS rules) may be configured (pre-configured) in the WTRU and / or UPF (e.g., to enable inductive mode for inductive functions). Rules may be generated by the Session Management Function (SMF) (e.g., based on information held by the Policy Control Function (PCF)). Rules may be sent to the WTRU. The WTRU may use these rules to determine the switching function and / or switching mode to apply to traffic (e.g., uplink traffic). Rules (e.g., N4 rules) may be sent to the UPF. The UPF may use these rules to determine the switching function and / or switching mode to apply to traffic (e.g., downlink traffic).
[0103] Performance Measurement Function (PMF) protocols may be used (for example, in WTRU and / or UPF). For example, the PMF protocol may be used to support one or more inductive modes. The PMF protocol may instruct the WTRU and / or UPF to perform measurements used to determine the switching mode. Measurements may include RTT measurements, access availability / non-availability reports, and / or PLR.
[0104] In some embodiments (e.g., Release 18), redundant inductive modes may be used. In redundant inductive modes, traffic may overlap with multiple access types (e.g., both access types). Traffic may overlap with multiple access types (e.g., both access types) to better satisfy the parameters (e.g., specifications or requirements) of the SDF. One or more (e.g., two) types of redundant inductive modes may be used. The type of redundant inductive mode may provide dynamism to the overlap. For example, the types of redundant inductive modes may be classified as described herein.
[0105] The redundant induction mode can be static. In this case, the network may configure the WTRU and / or UPF with information about which access type is the primary access type (e.g., which access type all packets are sent over). The network may configure the WTRU and / or UPF with information about which access types are secondary access types. If no primary access type is configured, the UPF and / or WTRU may duplicate packets between different access types (e.g., always using both access types, i.e., 100% duplication). If the network has configured a primary access type, the UPF and / or WTRU may send traffic (e.g., all traffic) over the primary access. The UPF and / or WTRU may determine whether to duplicate over secondary access types (e.g., using a non-standardized algorithm).
[0106] The redundancy induction mode can be dynamic. In this case, the decision on redundancy can be made on a per-packet basis (e.g., for each packet in a flow). The decision can be based on measurements and / or parameters (e.g., specifications, requirements, criteria, etc.). Dynamic redundancy induction mode can be used for non-GBR SDF (e.g., only for non-GBR SDF).
[0107] In some embodiments (e.g., Release 18), the UPF may be permitted to suspend and / or resume traffic duplication (e.g., based on the load on the UPF). The UPF may make such a decision and notify the WTRU (e.g., via PMF exchange).
[0108] Dynamic redundancy induction mode may be used for non-GBR traffic (e.g., targeting only non-GBR traffic). Other induction modes (e.g., minimum latency, load balancing, and / or priority-based induction modes) may be used for non-GBR traffic (e.g., targeting only non-GBR traffic). Two (e.g., only two) induction modes may target GBR traffic and non-GBR traffic (e.g., static redundancy induction mode and active-standby induction mode). In these induction modes, traffic may switch from one access type (e.g., one access) to another access type (e.g., based on underlying conditions). Figure 4 shows an example of redundant steering mode with dynamic redundancy. In Figure 4, the SDF PDUs are numbered. As shown in Figure 4, a gap may occur in transmission via the first access method (e.g., 3GPP access). In this case, SDF PDUs 7, 8, and 9 may not be transmitted via the first access method (e.g., 3GPP access). Transmission gaps can be long and may affect one or more PDUs (e.g., a large number of PDUs).
[0109] Figure 4 shows the transmission gap in the first access method (e.g., 3GPP access).
[0110] Gaps in transmission may not be a problem for non-GBR traffic. For GBR traffic, gaps in transmission can lead to scheduling inefficiencies at RAN nodes.
[0111] In the static redundant inductance mode (e.g., static redundant inductance mode only), among the inductance modes supported by GBR traffic, gaps may occur in transmissions on an access. A RAN node may attempt to maintain the GBR parameters (e.g., specifications or requirements) configured on the access. In active-standby mode, if the access type is active access and there is a gap in transmissions on the active access, the network may decide to move (e.g., attempt to move) the GBR parameters (e.g., specifications or requirements) to another access (e.g., use this as an indicator). The network may not intend to maintain the GBR parameters (e.g., specifications or requirements) while the transmission is interrupted.
[0112] A gap in transmissions on the first access path can occur for one or more reasons. For example, a gap may occur if the UPF decides to suspend duplication and the primary access type is configured as the second access path.
[0113] In WTRUs and / or UPFs, a gap can occur if the primary access type is configured as a second access path. In this case, the WTRU and / or UPF may transmit data packets (e.g., all data packets of the SDF) over the second access path. The WTRU and / or UPF may duplicate SDF data packets over the first access path.
[0114] Gaps in access paths (e.g., 3GPP paths) can lead to scheduling inefficiencies at network nodes (e.g., 3GPP RAN nodes).
[0115] If a RAN node obtains a QoS profile and recognizes that the traffic is GBR traffic for a QoS flow, the RAN node may perform one or more actions (for example, based on its recognition that the traffic is GBR traffic). For example, the RAN node may decide whether to accept the QoS flow and / or whether to accept future QoS flows.
[0116] The RAN node may determine whether the target cell can accept the QoS flow during handover.
[0117] RAN nodes can configure grants for uplink transmission. These grants can be reserved for uplink transmission. Grants may be based on uplink GBRs.
[0118] Setting the GBR too high may result in QoS flows being denied or handover denials increasing, potentially leading to configured grants being wasted (unused, etc.). Setting the GBR too low may prevent the application from meeting its minimum parameters (specifications, requirements, etc.).
[0119] One or more of the techniques described herein can be used to resolve transmission gaps (e.g., transmission gaps over 3GPP access).
[0120] WTRUs and / or networks may manage access types if a certain access type (e.g., 3GPP access) is defined as a secondary access and no traffic is being sent through that access type (e.g., to avoid wasting 3GPP resources that are not currently used / needed but may be needed in the future). RAN nodes may be configured to handle traffic with a specific GBR. Some traffic in this flow may not be sent by the RAN nodes.
[0121] The network can determine GBR parameters (e.g., specifications and requirements) for secondary access RAN nodes (e.g., if sexual redundancy mode is configured with primary access).
[0122] One or more conditions may cause the network to change (for example, dynamically) the GBR parameters (such as specifications or requirements) of secondary access RAN nodes.
[0123] The network may perform one or more actions for GBR QoS flows using static redundancy induction mode, for example, if there are primary access RAN nodes that may not be able to meet the configured GBR parameters (such as specifications or requirements) as a result of a high-priority GBR QoS flow.
[0124] In this specification, the term “transmission gap” may refer to a period during which the SDF’s PDU is not transmitted over an access path (e.g., due to the determination of the induction mode). The PDU may be transmitted over a different access type.
[0125] In this specification, the term "support information for GBR optimization" may refer to measurements specifically for GBR optimization on secondary access nodes.
[0126] In this specification, the term “GBRH information” may refer to information (e.g., information provided from the SMF to the RAN node) that enables a RAN node to manage GBR traffic via secondary access (e.g., manage it more efficiently). For example, GBRH information may include an indication of whether a RAN node is a secondary access node, GBR scaling factors, uplink security policies, and / or similar information.
[0127] In this specification, the term “GBR requirement change trigger” (also called a GBR parameter change trigger) may refer to any trigger (e.g., one applied to the SMF) that may lead to a change in the GBR parameters (such as specifications or requirements) of a secondary node. Examples of triggers (e.g., GBR conditions) include monitored duplication rates in secondary access, duplication status on secondary access, bitrate measurements in secondary access, and / or similar.
[0128] The features described herein enable support for GBR QoS flows using static redundant induction mode (e.g., efficient support). For example, features for establishing MA-PDU sessions for GBR QoS flows using static redundant induction mode are provided herein.
[0129] For example, features related to changing (e.g., dynamically changing) the GBR parameters (specifications or requirements) of sub-legs (e.g., in the case of an MA-PDU session using static redundant induction mode). GBR parameters (e.g., specifications, requirements) may be changed based on monitored performance in the WTRU and / or UPF.
[0130] For example, in a GBR QoS flow (e.g., an MA-PDU session using static redundancy induction mode), the primary and secondary access types can be swapped.
[0131] The features described herein may enable the network to avoid over-allocating GBR parameters (e.g., specifications or requirements) to secondary access. This may allow RAN nodes to schedule (e.g., appropriately schedule) configured grants for WTRUs, providing greater QoS and / or avoiding unnecessary handover denials.
[0132] You can configure MA-PDU sessions for GBR QoS flows.
[0133] Figure 5 shows an exemplary method for configuring an MA-PDU session using GBR traffic (e.g., an MA-PDU session for GBR QoS flows). The induction mode selected for the MA-PDU session may be (e.g., it may be assumed) a static redundant induction mode. The SMF may constitute the primary access RAN node for the MA-PDU session (e.g., it may be assumed).
[0134] In step 1, the WTRU application may initiate (for example, decide to initiate) communication with the application server (AS). The WTRU may decide to use an MA-PDU session.
[0135] In step 2, the WTRU may send a PDU session establishment / modification request. The request may include information indicating that the WTRU supports support information for GBR optimization in secondary access.
[0136] In step 3, the SMF may decide to use static redundancy induction mode for the MA-PDU session (e.g., based on configuration or PCC rules). The SMF may decide on one or more ATSSS rules for WTRU and / or N4 rules for UPF. The SMF may decide to bind the service data flow to a QoS flow with uplink and / or downlink GBRs. The SMF may decide on GBRH information (e.g., based on WTRU support for GBR optimization). Based on the GBRH information, the SMF may decide on the UP security policy for the MA-PDU session.
[0137] In step 4, the SMF may send an N4 session establishment / modification request (e.g., including one or more N4 rules) to the UPF. The UPF may constitute the ATSSS layer. The UPF may allocate a tunnel for the MA-PDU session.
[0138] In step 5, the SMF may send a message to the RAN node that received the PDU session establishment / modification request. The message may include a PDU session establishment / modification acceptance message that is forwarded to the WTRU. The message may include N2 SM information. The N2 SM information may include the QoS profile of the GBR QoS flow.
[0139] The SMF may provide GBRH information. GBRH information may include an indication of whether a RAN node is a primary access RAN node or a secondary access RAN node. GBRH information may include an indication of an initial scaling factor (e.g., alpha). RAN nodes can use alpha to scale GBR specifications (e.g., requirements). For example, if alpha is 0.5, a RAN node may decide that it only needs to satisfy half (e.g., only half) of the GBR parameters (e.g., specifications or requirements). GBRH information may include updated UP security policies (e.g., integrity / confidentiality requirements, recommendations, or not required). The updated UP security policy may be based on the SMF's decision in step 3.
[0140] The SMF may decide to use different GBR parameters (e.g., specifications or requirements) for the primary access RAN node and / or secondary access RAN nodes (e.g., using access node-specific GBR specifications). For example, if the GBR for a QoS flow is kbits per second (bps), the SMF may configure a GBR parameter (e.g., a specification or requirement) of kbps for the primary access RAN node and a fixed percentage of kbps (e.g., a fixed percentage) for the secondary access RAN nodes. The SMF may determine this percentage based on (pre-)configuration. The SMF may monitor historical QoS flows and determine the percentage (e.g., an acceptable percentage based on historical QoS flows).
[0141] In step 6, the RAN node may forward a PDU session establishment / modification acceptance message to the WTRU. This PDU session establishment / modification acceptance message may include an ATSSS rule for static redundancy induction mode. The ATSSS rule may provide a designation of the primary access in static redundancy induction mode. The ATSSS rule may also provide measurement configuration information to assist in GBR optimization for secondary access.
[0142] In step 7, if the SMF is aware that a WTRU has been registered on a second access path (for example, is already registered), the SMF may send N2 SM information to the second access path. The N2 SM information may include the QoS profile for the GBR QoS flow. The SMF may also provide GBRH information.
[0143] A RAN node may use (e.g., subsequently use) the provided QoS profile (e.g., in scheduling traffic to and from WTRUs, making handover decisions for future QoS flows, making tolerance control decisions for future QoS flows, and / or similar processes). If a RAN node decides to function as a secondary access node, it may scale the GBR specification (e.g., requirements). For example, a RAN node may scale the GBR parameters (e.g., specifications or requirements) based on the scaling factor provided in the QoS profile.
[0144] Application traffic (e.g., all downlink and uplink application traffic) can be transmitted via the MA-PDU session between the WTRU and UPF.
[0145] GBR parameters (e.g., specifications or requirements) for secondary access RAN nodes may be changed (e.g., dynamically).
[0146] When using a MA-PDU session configured for downlink and uplink traffic, the GBR specifications (e.g., requirements) of the secondary access node may change (e.g., dynamically) (e.g., triggered by any of the following changes to the GBR parameters (e.g., requirements)).
[0147] WTRU can operate in a first state where transmissions occur via both the first and second access nodes. WTRU can also operate in a second state where transmissions occur only via the first access node. For example, WTRU (and / or UPF) can monitor the amount of transmission (e.g., traffic) that is duplicated through secondary access nodes (e.g., transmitted via both the first and second access nodes). Traffic volume can be expressed as a percentage (e.g., 40% of the traffic in a QoS flow is duplicated through secondary access nodes).
[0148] Duplicate monitoring information (e.g., duplicate rate) may be reported to the SMF. This information may be monitored by the WTRU's PMF and / or the UPF's PMF. The UPF may provide this information via N4 session-level reports. The WTRU may send information to the UPF in PMF measurements. The UPF may then forward the information to the SMF (e.g., in N4 session-level reports). The WTRU may provide measurement information to the UPF via NAS SM messages. Information may be provided periodically. Information may be provided when the duplicate rate changes by a certain threshold. Information may be provided when the duplicate rate exceeds a threshold.
[0149] SMF can determine a GBR scaling factor (e.g., alpha) for secondary access nodes (for example, based on the proportion of total traffic that overlaps between the first and second access nodes).
[0150] The SMF can scale the guaranteed bitrate conditions based on the guaranteed bitrate scaling factor. The SMF can send / provide the GBR scaling factor to the secondary access RAN node. The secondary access RAN node then performs GBR on the QoS flow. Parameters (e.g., specifications or requirements) can be scaled (e.g., reduced according to a scaling factor). The SMF can notify the primary access RAN node that the GBR on secondary access may be scaled. This information may be provided as part of a modified QoS profile (e.g., included in N2 SM information). The information may be included in Time-Sensitive Communication Assistance Information (TSCAI) (e.g., forwarded to the RAN node).
[0151] For example, a WTRU (and / or UPF) may monitor whether traffic is overlapping through secondary access nodes. The WTRU (and / or UPF) may send a notification to the SMF if the traffic overlap status changes from "active" to "inactive" and / or vice versa. For example, the WTRU may send a message (e.g., to a network node, e.g., an SMF) indicating that the RSM has transitioned from a first state (e.g., transmissions are made via both the first and second access nodes) to a second state (e.g., transmissions are made via only the first access node). Similarly, the WTRU may send a message indicating that the RSM has transitioned from a second state to a first state.
[0152] The WTRU and / or UPF may provide information indicating the duration for which the RSM will maintain a first or second state (e.g., how long the current state, such as transmitting only through the first access node, will persist). For example, the UPF may decide to pause the duplication for K seconds. The duration (K) may be provided to the SMF (e.g., so that it can be forwarded to a secondary access RAN node). The UPF may provide this information via an N4 session-level report. The WTRU may transmit this information to the UPF in a PMF measurement. The UPF may (e.g., then) forward this information to the SMF (e.g., in an N4 session-level report). The WTRU may provide measurement information to the UPF via a NAS SM message.
[0153] A network node (e.g., an SMF) may decide to change the guaranteed bitrate conditions for a second access node. For example, the SMF may use its instructions (e.g., messages from a WTRU indicating a state transition) to determine the GBR scaling factor for a secondary access node. The SMF may use its instructions to determine new GBR parameters (e.g., specifications or requirements) for secondary access. The SMF may use its instructions to indicate to a secondary access RAN node whether traffic overlap in the QoS flow is transitioning to an active or inactive state. The SMF may indicate the length of time an RSM is expected to remain in a first or second state (e.g., how long the transition is expected to last, e.g., K seconds). This information may be provided as part of a modified QoS profile (e.g., included in N2 SM information). This information may be included in TSCAI (e.g., forwarded to the RAN node).
[0154] RAN nodes can use the provided information. For example, a RAN node may decide whether to apply GBR parameters (e.g., specifications or requirements) to QoS flows passing through a secondary access RAN node.
[0155] The guaranteed bitrate condition may be associated with at least one of the following: the overlap rate at the second access node, the overlap status at the second access node, or a bitrate measurement at the second access node. For example, WTRU (and / or UPF) may monitor the bitrate on an access (e.g., each access). If the average bitrate on the primary access falls below the GBR, the network may consider this an indicator that the GBR parameters (e.g., specifications or requirements) on the primary access are over-allocated (e.g., the GBR parameters (e.g., specifications or requirements) on secondary accesses may be reduced).
[0156] The SMF may use this instruction to determine the GBR scaling factor for secondary access. The SMF may use this instruction to determine a new GBR specification (e.g., requirements) for secondary access. The SMF may provide this information to the RAN node. For example, the SMF may provide the information as part of a modified QoS profile (e.g., included in N2 SM information). The SMF may provide the values of the GBR parameters (e.g., specifications or requirements) via the secondary access RAN node.
[0157] Secondary access RAN nodes may use the provided information. For example, a secondary access node may scale GBR parameters (e.g., specifications or requirements) for QoS flows (e.g., reduce GBR specifications according to a scaling factor).
[0158] Duplicate information may be sent to the SMF. The SMF may forward the information to the RAN node. Information may be provided to the RAN node from the WTRU and / or UPF (e.g., directly). The WTRU may use the RRC measurement report. The UPF may provide its information in the GTP-U header of the DL PDU or in the GTP control plane PDU.
[0159] The primary access can be changed. For example, if the first access node is the primary access node and the second access node is a secondary access node, the network node (e.g., SMF) may decide to change the second access node to the primary access node and the first access node to the secondary access node.
[0160] A RAN node may determine that GBR parameters (e.g., specifications or requirements) are not being met. For example, the SMF may enable QoS Notification Control (QNC) for a GBR QoS flow (e.g., based on PCC rules from the SMF). The operation of QNC may allow the RAN node to send an asynchronous QoS NotificationControl (non-fulfilled event) to the Access and Mobility Management Function (AMF) (e.g., if the RAN node can no longer guarantee the QoS parameters or specifications of a GBR QoS flow). A network node may decide to change the primary access node to a secondary access node and the second access node to a secondary access node based on the first access node failing to meet the guaranteed bitrate threshold. For example, the first node (e.g., the RAN node) may not be able to guarantee the QoS parameters (e.g., specifications or requirements) due to the resource capacity required by other higher-priority GBR QoS flows. The AMF may notify the SMF that the QoS parameters (e.g., specifications or requirements) are not being met. QNC may be used to swap primary and secondary access.
[0161] SMF can enable QNC for GBR QoS flows. QNC can be enabled for access RAN nodes, secondary access RAN nodes, or both primary and secondary access nodes.
[0162] If requested (for example, a request from SMF), a RAN node may monitor whether GBR parameters (e.g., specifications or requirements) are met. If the parameters (e.g., requirements or specifications) are not met, the RAN node may notify SMF.
[0163] SMF may swap primary and secondary access using QNC information from primary and / or secondary access. For example, if the primary access RAN node cannot meet the GBR parameters (specifications or requirements, etc.) of the QoS flow, SMF may swap access. If the secondary access RAN node can meet the GBR parameters (e.g., specifications or requirements) of the QoS flow, SMF may swap access. If the primary access cannot meet the GBR parameters (specifications or requirements, etc.) of the QoS flow, and the secondary access RAN node can meet the GBR parameters (specifications or requirements, etc.) of the QoS flow, SMF may swap access.
[0164] If the SMF decides to swap primary and secondary access, it may send the updated ATSSS rules to the WTRU and / or the updated N4 rules to the UPF. The SMF may also send the modified QoS profiles to the primary and secondary access RAN nodes.
[0165] Although the features and components described above are described in specific combinations, each feature or component may be used alone without other features or components of the preferred embodiment, or in various combinations, with or without other features or components.
[0166] While the embodiments described herein may assume 3GPP-specific protocols, it should be understood that the embodiments described herein are not limited to these scenarios and are applicable to other wireless systems. For example, while the solutions described herein assume LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to these scenarios and are applicable to other wireless systems.
[0167] The processes described above can be implemented as computer programs, software, and / or firmware embedded in computer-readable media to be executed by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM discs and digital versatile discs (DVDs). Processors in conjunction with software can be used to implement radio frequency transceivers used in WTRUs, terminals, base stations, RNCs, and / or any host computer.
[0168] It is understood that the entities performing the processes described herein may be logical entities implemented in the form of software (e.g., computer executable instructions) stored in the memory of a mobile device, network node, or computer system and executed on its processor. That is, these processes may be implemented in the form of software (e.g., computer executable instructions) stored in the memory of a mobile device and / or network node (such as a node or computer system). These computer executable instructions perform the processes discussed herein when executed by the node's processor. It is also understood that any transmit / receive processes shown in the diagrams may be performed by the node's communication circuitry, under the control of the node's processor and the computer executable instructions (e.g., software) executed by it.
[0169] The various technologies described herein may be implemented in relation to hardware or software, or, where appropriate, in a combination thereof. Accordingly, embodiments and apparatus of the subject matter described herein, or particular aspects or parts thereof, may take the form of program code (e.g., instructions), which is embodied in tangible media, including other machine-readable storage media, which, when loaded into a machine such as a computer and executed by it, makes the machine an apparatus for implementing the subject matter described herein. Where program code is stored in a medium, it may be stored in one or more media that collectively execute the operation; that is, one or more media together contain the code for executing the operation, but if there are multiple single media, particular parts of the code do not need to be stored in specific media. In the case of execution of program code on a programmable device, the computing device generally includes a processor, processor-readable storage media (including volatile and non-volatile memory and / or memory elements), at least one input device, and at least one output device. One or more programs (e.g., through the use of APIs) that implement or utilize the processes described in relation to the subject matter described herein are reusable.
[0170] In exemplary embodiments, aspects of the subject matter described herein may be referred to in the context of one or more independent computing systems, but the subject matter described herein is not limited thereto and can be implemented in any computing environment, including networks and distributed computing environments. Furthermore, aspects of the subject matter described herein can be implemented in or across multiple processing chips or devices, and similarly, storage devices can be configured across multiple devices. Such devices include personal computers, network servers, mobile terminals, supercomputers, or computers embedded in other systems such as automobiles and aircraft.
[0171] In describing preferred embodiments of the subject matter covered by this disclosure, as shown in the drawings, certain terms have been used for clarity. However, the subject matter described in the claims is not limited to the specific terms thus selected, and each particular component should be understood to include all technical equivalents that function in a similar manner to achieve a similar purpose.
Claims
1. Network node, The processor comprises, The device receives a first message, the first message indicating a transition from a first state to a second state of redundant inductive mode (RSM), and the duration for which the RSM intends to remain in the second state; in the first state, the device transmits via both the first and second access nodes; and in the second state, the device transmits only via the first access node. We decided to change the guaranteed bitrate conditions for the second access node, In response to the first message, a second message is sent to the second access node, the second message indicating a change in the second access node's guaranteed bitrate conditions. A network node configured in this way.
2. The said duration is the first duration, the said change is the first change, and the processor, The device receives a third message, the third message indicating the transition of the RSM from the second state to the first state, and the second lifetime for which the RSM intends to remain in the first state. Determine the second change in the guaranteed bitrate condition of the second access node, In response to the third message, a fourth message is sent to the second access node, the fourth message indicating at least one of the following: the transition of the RSM from the second state to the first state, the second change in the guaranteed bitrate condition of the second access node, or the second lifetime. The network node according to claim 1, further configured as follows.
3. The aforementioned processor, While in the first state, the device receives duplicate information indicating the percentage of the total amount of duplicated traffic on the first access node and the second access node. The network node according to claim 1, further configured as follows.
4. The network node according to claim 3, wherein the processor determining the change to the guaranteed bitrate condition of the second access node comprises a processor configured to determine a scaling factor for the guaranteed bitrate based on the percentage, and a processor further configured to transmit the scaling factor for the guaranteed bitrate to the second access node.
5. The processor, configured to determine the change to the guaranteed bitrate condition of the second access node, Based on the transition from the first state to the second state, the guaranteed bitrate scaling coefficient is determined. Based on the guaranteed bitrate scaling factor, the guaranteed bitrate condition is scaled. The network node according to claim 1, comprising the processor configured as described above.
6. The network node according to claim 1, wherein the second message further indicates the transition of the RSM from the first state to the second state, or the duration of the RSM.
7. The network node according to claim 1, wherein the guaranteed bitrate condition is associated with at least one of the overlap rate at the second access node, the overlap state at the second access node, or the bitrate measurement at the second access node.
8. The network node according to claim 1, wherein the first access node is a primary access node, the second access node is a secondary access node, and the processor is further configured to decide to change the second access node to a primary access node and the first access node to a secondary access node.
9. The network node according to claim 8, wherein the processor configured to decide to change the second access node to a primary access node and the first access node to a secondary access node is further configured to decide to change the second access node to a primary access node and the first access node to a secondary access node based on the first access node not meeting a guaranteed bitrate threshold.
10. A method performed by a network node, wherein the method is Receiving a first message from a device, the first message indicating a transition from a first state to a second state of redundant inductive mode (RSM), and the duration for which the RSM intends to remain in the second state, wherein in the first state, the device transmits via a first access node and a second access node, and in the second state, the device transmits only via the first access node. To decide on a change to the guaranteed bitrate condition for the second access node, In response to the first message, a second message is sent to the second access node, the second message indicating a change in the second access node's guaranteed bitrate conditions. A method that includes [a certain feature].
11. The duration is the first duration, the change is the first change, and the method is Receiving a third message from the device, wherein the third message indicates the transition of the RSM from the second state to the first state, and the second lifetime during which the RSM intends to remain in the first state. To determine a second change in the guaranteed bitrate condition of the second access node, In response to the third message, a fourth message is sent to the second access node, wherein the fourth message indicates at least one of the following: the transition of the RSM from the second state to the first state, the second change in the guaranteed bitrate condition of the second access node, or the second lifetime. The method according to claim 10, further comprising:
12. The aforementioned method, While in the first state, the device receives duplicate information indicating the percentage of the total amount of duplicated traffic on the first access node and the second access node. The method according to claim 10, further comprising:
13. The method according to claim 12, wherein determining the change to the guaranteed bitrate condition of the second access node comprises determining a scaling factor for the guaranteed bitrate based on the percentage, and the method further comprises transmitting the scaling factor for the guaranteed bitrate to the second access node.
14. Determining the change to the guaranteed bitrate condition of the second access node is: Based on the transition from the first state to the second state, the guaranteed bitrate scaling coefficient is determined, The guaranteed bitrate condition is scaled based on the guaranteed bitrate scaling factor, The method according to claim 10, comprising:
15. The method according to claim 10, wherein the second message further indicates at least one of the transition of the RSM from the first state to the second state, or the duration of the RSM.
16. The method according to claim 10, wherein the guaranteed bitrate condition is associated with at least one of the overlap rate at the second access node, the overlap state at the second access node, or the bitrate measurement at the second access node.
17. The method according to claim 10, wherein the first access node is a primary access node and the second access node is a secondary access node, and the method further comprises deciding to change the second access node to a primary access node and the first access node to a secondary access node.
18. The method according to claim 17, wherein the decision to change the second access node to a primary access node and the first access node to a secondary access node is made based on the fact that the first access node does not meet the guaranteed bitrate threshold.