Wireless transmit / receive unit and method associated with steering mode restriction

Abstract

Systems, methods, and instrumentalities to support steering mode restrictions are disclosed herein. A wireless transmit / receive unit (WTRU) may receive a first message from a network device, wherein the first message may indicate at least a first rule and a second rule for performing an uplink transmission associated with a protocol data unit (PDU) session across a first network access branch and a second network access branch. The WTRU may perform a first uplink transmission associated with the PDU session via at least one of the first network access branch and the second network access branch according to a first rule. The WTRU may then determine that a condition for applying the second rule is satisfied, and in response to the determination, perform a second uplink transmission associated with the PDU session via at least one of the first network access branch and the second network access branch according to the second rule.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 444,490, filed on February 9, 2023, the disclosure of which is incorporated herein by reference in its entirety. Background Art

[0003] Wireless communication systems may support Access Traffic Steering, Switching, and Segmentation (ATSSS), but may lack flexibility in configuring ASSSS and / or allowing the use of restrictive ASSSS. Summary of the Invention

[0004] Described herein are systems, methods, and means associated with steering patterns and steering pattern restrictions (e.g., associated with splitting, switching, steering, and / or duplicating traffic across multiple access branches). According to an embodiment of the present disclosure, a wireless transmit / receive unit (WTRU) may receive a first message from a network device, wherein the first message may indicate at least a first rule and a second rule for performing an uplink transmission associated with a protocol data unit (PDU) session across a first network access branch and a second network access branch. The WTRU may perform a first uplink transmission associated with the PDU session via at least one of the first network access branch and the second network access branch according to the first rule. Subsequently, the WTRU may determine that a condition for applying the second rule is satisfied, and in response, perform a second uplink transmission associated with the PDU session via at least one of the first network access branch and the second network access branch according to the second rule.

[0005] In an example, a first rule may indicate a first manner for diverting, switching, splitting, or duplicating uplink transmissions associated with a PDU session across a first network access branch and a second network access branch, and wherein a second rule may indicate a second manner for diverting, switching, splitting, or duplicating uplink transmissions associated with a PDU session across a first network access branch and a second network access branch. In an example, the first rule may further indicate a validity condition of the first rule, the second rule may further indicate a validity condition of the second rule, and in response to determining that the validity condition of the second rule is satisfied, it may be deemed that a condition for applying the second rule is satisfied.

[0006] In an example, the validity condition for the first rule or the second rule may be associated with: the time at the WTRU, the location of the WTRU, the orientation of the WTRU, the power of the WTRU (e.g., power level or power state), the travel speed of the WTRU, a quality of experience (QoE) measurement associated with the WTRU, or the transmission mode of the WTRU.

[0007] In an example, the WTRU may send a second message to the network device, the second message may indicate that the WTRU is switching to applying the second rule. In an example, the WTRU may also send a session establishment request associated with the PDU session to the network device, and the first message may be received from the network device as part of a PDU session establishment response. The session establishment request may indicate the WTRU's preference for at least one of the first network access leg and the second network access leg.

[0008] In an example, a first network access leg described herein may be associated with a first cellular communication network, and a second network access leg described herein may be associated with a second cellular communication network. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.

[0010] Figure 1B is a diagram showing that according to an embodiment, Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown.

[0011] Figure 1C It is shown that according to the embodiment, Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) for use within a communication system is shown in FIG.

[0012] Figure 1D It is shown that according to the embodiment, Figure 1A A system diagram of another example RAN and another example CN used within the communication system shown in .

[0013] Figure 2 is a diagram illustrating an example of a service data flow (SDF) associated with multiple access branches.

[0014] Figure 3 is a diagram showing an example of a steering mode strategy.

[0015] Figure 4 is a diagram illustrating example operations that may be performed by a WTRU to support steering mode restriction.

[0016] Figure 5 is a diagram illustrating example operations that may be performed by a network device (eg, a user plane function) to support steering mode restriction.

[0017] Figure 6 is a diagram illustrating example operations associated with applying steering mode rules and steering mode restrictions. DETAILED DESCRIPTION

[0018] Figure 1A is a diagram illustrating an example 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, broadcast, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tail unique word DFT spread OFDM (ZT UW DTS-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0019] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive 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. However, it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (WTRUs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspot or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated process chains), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as WTRUs.

[0020] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode-B (eNB), a Home Node B, a Home eNode-B, a gNode-B (gNB), an NR Node B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0021] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage to a specific geographic area, which may be relatively fixed or may change over time. A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, one for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0022] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0023] More specifically, as described above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Air Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. 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 ​​Uplink (UL) Packet Access (HSUPA) communications.

[0024] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA) which may use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-APro) to establish the air interface 116.

[0025] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as New Radio (NR) to establish NR radio access over the air interface 116.

[0026] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may jointly implement LTE radio access and NR radio access, for example, using dual connectivity (DC) principles. Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0027] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM Evolution (GERAN), etc.

[0028] Figure 1A The base station 114b in the example may be, for example, a wireless router, a master Node B, a master eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-a, LTE-aPro, NR, etc.) to establish a microcell or a femtocell. Figure 1A As shown, base station 114b may be directly connected to the Internet 110. Thus, base station 114b may not need to access the Internet 110 via CN 106 / 115.

[0029] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although Figure 1ANot shown, but it will be appreciated, the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0030] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) of the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0031] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0032] Figure 1B is a system diagram illustrating an exemplary WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other elements / peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0033] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated 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 functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0034] The transmit / receive element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 can be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF signals and light signals. It will be appreciated that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0035] Although the transmit / receive element 122 is Figure 1B Although depicted as a single element in FIG1 , 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 wireless signals over the air interface 116.

[0036] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., such as NR and IEEE 802.11).

[0037] The processor 118 of the WTRU 102 may be coupled to and receive user input data from the speaker / microphone 124, keypad 126, and / or display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Additionally, the processor 118 may access information from and store data in any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. The 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. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0038] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 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.), solar cells, fuel cells, etc.

[0039] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of receiving signals from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0040] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, 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, etc. The peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geo-location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0041] The WTRU 102 may include a full-duplex radio in which some or all of the transmission and reception of signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio in which some or all of the transmission and reception of signals (e.g., associated with specific subframes for both uplink (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0042] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0043] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0044] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. Figure 1C As shown, eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0045] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0046] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for facilitating switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0047] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNode-B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0048] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0049] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0050] Even though the WTRU Figures 1A to 1D Although depicted as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may (eg, temporarily or permanently) employ a wired communication interface with a communication network.

[0051] In a representative embodiment, the other network 112 may be a WLAN.

[0052] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS and destined for a STA may reach the AP and may be delivered to the STA. Traffic from a STA destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within a BSS may be sent through the AP, for example, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be sent between a source STA and a destination STA using a direct link setup (DLS) (e.g., sent directly between them). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0053] When using 802.11ac infrastructure operation mode or a similar operation mode, the AP can transmit a beacon on a fixed channel (such as a primary channel). The primary channel can be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, STAs (e.g., each STA), including the AP, can sense the primary channel. If the primary signal is sensed / detected by a specific STA and / or is determined to be busy, the specific STA can back off. One STA (e.g., only one station) can transmit in a given BSS at any given time.

[0054] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0055] Very high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining 8 consecutive 20MHz channels, or by combining two discontinuous 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, data can be passed through a fragment parser after channel coding, which can separate the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed on each stream separately. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations of the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC) layer, entity, etc.

[0056] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication (MTC), such as MTC devices in macro coverage. MTC devices may have certain capabilities, for example, limited capabilities, including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0057] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for a STA that supports (e.g., only supports) a 1 MHz mode (e.g., an MTC-type device), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which only supports the 1 MHz operating mode) transmitting to the AP, the entire available frequency band can be considered busy even if most of the frequency band remains idle and available.

[0058] In the United States, the available frequency bands for 802.11ah are 902 MHz to 928 MHz. In South Korea, the available frequency bands are 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz, depending on the country code.

[0059] Figure 1D1 is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As described above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0060] The RAN 113 may include gNBs 180a, 180b, and 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be located in the unlicensed spectrum, while the remaining component carriers may be located in the licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0061] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmit spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of varying or scalable lengths (e.g., containing a different number of OFDM symbols and / or lasting a different absolute time).

[0062] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as the eNode Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may serve as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRUs 102a, 102b, 102c.

[0063] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle air interface resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0064] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 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 depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0065] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of service being utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low-latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine-type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-APro) and / or non-3GPP access technologies (such as WiFi).

[0066] The SMF 183a, 183b may connect to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also connect to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0067] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0068] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. Additionally, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may connect to local data networks (DNs) 185a, 185b through UPFs 184a, 184b via the N3 interface to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the local data networks (DNs) 185a, 185b.

[0069] Given that Figures 1A to 1D and Figures 1A to 1D

[0015] As described above, one or more or all of the functions described herein with respect to one or more of the following may be performed by one or more simulation devices (not shown) . The simulation devices may be one or more devices configured to simulate one or more or all of the functions described herein. For example, the simulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

[0070] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more simulation devices can perform one or more or all functions when being implemented and / or deployed in whole or in part as a part of a wired and / or wireless communication network to test other devices in the communication network. One or more simulation devices can perform one or more or all functions when being temporarily implemented / deployed as a part of a wired and / or wireless communication network. The simulation device can be directly connected to another device for testing purposes and / or can use over-the-air wireless communication to perform testing.

[0071] One or more simulation devices can perform one or more (including all) functions when not being implemented / deployed as a part of a wired and / or wireless communication network. For example, the simulation device can be used for testing scenarios in a test laboratory and / or a wired and / or wireless communication network that is not deployed (e.g., testing) to achieve the test of one or more components. One or more simulation devices can be test equipment. The simulation device can use direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) to transmit and / or receive data.

[0072] A WTRU may provide its session management (SM) and / or mobility management (MM) related capabilities to a network device (e.g., a core network device). For example, the WTRU may send its MM core network capability information to an access and mobility management function (AMF) during a registration procedure (e.g., an initial registration procedure) and / or a mobility registration update procedure, for example, via a non-access stratum (NAS) message. The WTRU may indicate its SM-related core network capability information via a PDU session establishment or modification request or message. The capability information may include the WTRU's access traffic steering, switching, and splitting (ATSSS) capability and / or the WTRU's DualSteer capability.

[0073] If a WTRU wants to access services provided by a network that may require registration, the WTRU may register with the network. The WTRU may perform a series of operations associated with registration. For example, the WTRU may select a mobile network (e.g., via a public land mobile network (PLMN) selection process or a standalone non-public network (SNPN) selection process). The network may be a public network or a non-public network. The WTRU may follow rules to determine how to select from the available networks at a given location, and / or when to look for a higher priority network. The WTRU may select a cell (e.g., the best cell) on the selected network via a cell selection process, and the WTRU may occupy the selected cell. The WTRU may (e.g., continuously) evaluate the cell quality and, if necessary, may switch to (e.g., camp on) a different cell, for example, via a cell reselection process. The WTRU may notify the network about the WTRU's presence and / or provide coarse location information to the network, for example, during the registration process.

[0074] A WTRU may support carrier aggregation (CA), which may be provided on a single cellular (e.g., 3rd Generation Partnership Project (3GPP)) access branch (e.g., New Radio (NR) or Long Term Evolution (LTE) access branch) and / or allow the WTRU to transmit and / or receive data on two or more cells. The cells may be associated with different frequency carriers. The use of the cells may be managed (e.g., entirely) by a radio access network (RAN).

[0075] A WTRU may support dual connectivity (DC), which may allow the WTRU to receive and / or send data over two cellular (e.g., 3GPP) access legs. Access may be based on NR (e.g., via a base station such as a gNB) and / or LTE (e.g., via a base station such as an eNB). In some examples (e.g., in 5G / NR), a deployment (e.g., an initial deployment) may include a first access leg on a first RAT such as LTE and a second access leg on a second RAT such as NR. In some examples, the two access legs may be on the same RAT, such as on NR, and the two access legs may be on different frequency bands (e.g., frequency range 1 (FR1) and frequency range 2 (FR2), respectively). The WTRU may use a radio frequency (RF) front end to support the two access legs. One of the access legs may be a primary leg (e.g., as part of a primary cell group (MCG)) and the other may be a secondary leg (e.g., as part of a secondary cell group (SCG)).

[0076] The term "access leg" may be used herein interchangeably with the term "network access leg" or "communication network access leg".

[0077] The WTRU may support communication over a satellite link, which may allow the WTRU to communicate over a transparent satellite and / or transponder (e.g., the satellite and / or transponder may be in different orbits, such as geosynchronous earth orbit (GEO), medium earth orbit (MEO), low earth orbit (LEO), or high altitude platform station (HAPS)). The WTRU may use an RF front end to communicate over the transparent satellite or transponder.

[0078] The WTRU may support various combinations of dual connectivity and carrier aggregation. For example, the WTRU may use dual connectivity in two cellular (e.g., 3GPP) access branches and in either or both of these access branches, the WTRU may use carrier aggregation. A collection of cells on an access branch may be referred to as a cell group. The WTRU may support dual connectivity on one or more access branches on a transparent satellite or repeater link. For example, the WTRU may support one or more of the following scenarios. In a first scenario, the first access branch may be on NR and the second access branch may be on a GEO satellite. In a second scenario, the first access branch may be on NR and the second access branch may be on a LEO or MEO satellite. In a third scenario, the first access branch may be on a GEO satellite and the second access branch may be on a LEO or MEO satellite.

[0079] A WTRU operating under DC may be subject to certain restrictions, such as how data radio bearers (DRBs) are mapped on two access branches. For example, an MCG bearer may be configured as a data bearer that can operate on a primary branch, an SCG bearer may be configured as a data bearer that can operate on a secondary branch, and a split bearer may be configured as a data bearer that can split its operation between the primary branch and the secondary branch (for example, processing tasks above the radio link control (RLC) layer may be performed in the primary branch, and processing tasks below the packet data convergence layer (PDCP) may be performed in the secondary branch). In one or more (for example, each) of these configurations, over-the-air transmission of the data bearer may be performed on a single access branch.

[0080] Figure 2Figure 1 shows how a downlink (DL) service data flow (SDF) can travel on a communication network (e.g., a 5G network) and / or on a data radio bearer. As shown, at an entry point such as a user plane function (UPF), the SDF can be mapped to a QoS flow. Traffic associated with these QoS flows can be received by a RAN (e.g., a base station), where the traffic can be mapped to one or more DRBs and sent over a wireless interface. In some examples, the SDF can be mapped to a QoS flow (e.g., a single QoS flow), the QoS flow can be mapped to a DRB (e.g., a single DRB), and the DRB can be transmitted over the air via an access branch (e.g., a single 3GPP radio access branch). In these examples, different SDFs can be dependent on a DC and can be sent on different cellular (e.g., 3GPP) access branches, but a single SDF flow can not be split, switched, diverted, or replicated on different access branches (e.g., on two 3GPP access branches). In other words, traffic associated with the SDF may be carried on a single cellular (e.g., 3GPP) access leg, which may be changed via RAN layer configuration or reconfiguration (e.g., a process that may be slower than dynamic configuration achieved via downlink control transmission (DCI)).

[0081] The embodiments of the present disclosure contemplate that Figure 2 Unlike the examples shown, data or traffic associated with the SDF can be split, switched, redirected, and / or replicated across multiple (e.g., two) network access branches (e.g., the splitting, switching, redirecting, or replication can be performed at upper layers, associated with the same data session and / or with a single subscription to a PLMN). The splitting, switching, redirecting, or replication can be implemented in one or more of the following scenarios. The first scenario can involve a single PLMN, a PLMN plus a non-public network (NPN) such as a standalone non-public network (SNPN), or two PLMNs. The second scenario can involve networks of the same RAT or networks of different RATs. For example, in the second scenario, the first network can be an NR network or a non-terrestrial network (NTN), and the second network can be an NR network, an NTN (e.g., a non-cellular network), or an LTE network. In the PLMN plus PLMN or PLMN plus NPN scenario, the two networks can be managed by the same operator or different operators.

[0082] A steering pattern may be configured for a service data flow. As used herein, the term "steering pattern" may include a manner for steering, splitting, switching, and / or duplicating traffic or data across multiple access legs. A network device or function, such as a policy control function (PCF), may provide a steering pattern configuration to a WTRU (e.g., in the form of one or more ATSSS rules) and / or a UPF (e.g., in the form of one or more N4 rules). The PCF may determine the configuration based on one or more QoS requirements (e.g., provided by an application function (AF)) and / or the capabilities of the WTRU. The PCF may change the steering pattern configuration for a service data flow, for example, based on a change in QoS requirements.

[0083] ATSSS may allow a WTRU to split, steer, switch and / or replicate traffic associated with a service data flow (SDF) on a cellular (e.g., 3GPP) access branch and / or a non-cellular (e.g., non-3GPP) access branch. In contrast, DC may allow a WTRU to send or receive a first SDF and a second SDF on a first cellular access branch and a second cellular access, respectively, but DC may not allow the WTRU to split, steer, switch or replicate traffic associated with a first SDF or a second SDF on multiple (e.g., two) cellular access branches (e.g., with DC, the splitting, steering, switching or replication of traffic may be done at the data radio bearer level, not at the SDF level). The access branches supported by DC may be terrestrial or non-terrestrial, and the access branches may be implemented on one or more PLMNs or one or more SNPNs.

[0084] As described herein, it may be desirable to enable ATSSS functionality, such as splitting, steering, switching, and / or duplicating traffic associated with an SDF (e.g., for a PDU session) across multiple (e.g., two) access legs (e.g., including a non-terrestrial 3GPP access leg and / or an SNPN access leg). Such ATSSS functionality may include a DualSteer functionality, which may allow a WTRU to split, steering, switching, and / or duplicating traffic associated with a service data flow (SDF) across a first cellular (e.g., 3GPP) access leg and / or a second cellular (e.g., 3GPP) access leg (e.g., DualSteer may be based on ATSSS). The multiple access legs used by ATSSS or DualSteer may be associated with the same RAT (e.g., two cellular access legs such as two NR access legs), with different RATs (e.g., an LTE access leg and an NR access leg), with different RAT types (e.g., terrestrial access and satellite access), with different PLMNs, or with different PLMN types (e.g., HPLMN, NPN, and VPLMN). For example, with ATSSS, the first access leg can be a cellular (e.g., 3GPP) access leg, the second access leg can be a non-cellular (e.g., non-3GPP) access leg, and the decision to switch, divert, split, and / or copy traffic can be made at the SDF level (e.g., the network can control when this happens through the diversion pattern rules described herein). For DualSteer, the first access leg can be a cellular (e.g., 3GPP) access leg, the second access leg can also be a cellular (e.g., 3GPP) access leg, and the decision to switch, divert, split, and / or copy traffic can also be made at the SDF level (e.g., the network can control when this happens through the diversion pattern rules described herein). For DC, the first access leg can be a cellular (e.g., 3GPP) access leg, the second access leg can also be a cellular (e.g., 3GPP) access leg, and the decision to switch, divert, split, and / or copy traffic can be made at the data radio bearer (DRB) level (e.g., the network may have little control over when this happens). Restrictions can be imposed on how traffic is split, diverted, switched, and / or copied across multiple access legs. These limits may allow the WTRU and / or network equipment (eg, UPF) to dynamically and / or autonomously change how traffic is split, steered, switched, and / or replicated across multiple access legs.

[0085] In some implementations of ATSSS, the configuration associated with splitting, steering, switching, and / or duplicating traffic may be static (e.g., the configuration may be accomplished via RRC messages). In these implementations, although the network device may implement ATSSS restrictions by modifying the configuration or changing ATSSS from a first type (e.g., splitting traffic on two access legs) to a second type (e.g., duplicating traffic on two access legs), the process may be slower (e.g., compared to allowing the WTRU to locally decide when to apply ATSSS restrictions) because session management-related signaling may be involved. In some implementations of ATSSS, the network may not be allowed to configure ATSSS restrictions (e.g., how traffic may be split, steered, switched, or duplicated, and under what conditions). For example, in these implementations of ATSSS, the network may not be allowed to configure the WTRU to use only redundant steering mode when the WTRU's battery power is above a certain level (e.g., when the WTRU's battery power is deemed sufficient).

[0086] Multiple steering modes may be defined in the context of ATSSS or DualSteer. These steering models may include, but are not limited to, active-standby mode, load balancing mode, priority mode, minimum delay mode, and / or redundant steering mode. As used herein, a steering mode rule or restriction may indicate the steering mode to be used, the configuration of the steering mode, the validity conditions or restrictions of the steering mode, the measurement configuration associated with the steering mode, the priority of the steering mode rule, whether the steering mode rule is an initial rule, whether the steering mode rule is a default rule, etc. The steering mode rule or restriction may allow the WTRU and / or network equipment (e.g., UPF) to switch (e.g., dynamically) from one steering mode to another steering mode if certain conditions are met.

[0087] As used herein, a steering mode policy may indicate a list of steering mode rules, a steering mode capability may indicate support for one or more steering modes or steering mode restrictions, and a transmission mode may indicate how traffic may be transmitted. A transmission mode may be defined for an uplink or a downlink. For example, a transmission mode for an uplink may be associated with one or more of GEO, MEO, LEO, uncertified aircraft (UAV), relay WTRU, frequency band, licensed band, unlicensed band, NR, and / or LTE. For a downlink, a transmission mode may be associated with one or more of GEO, MEO, LEO, UAV, relay WTRU, frequency band, licensed band, unlicensed band, NR, LTE, multicast, broadcast, and / or unicast.

[0088] It should be noted here that the examples described here can be applicable to: DualSteer, which can use two cellular (e.g., 3GPP) access branches, and ATSSS, which can use two cellular access branches or one cellular access branch and one non-cellular (e.g., non-3GPP) access branch.

[0089] One or more steering pattern policies may be defined to enable the application of steering pattern restrictions. The steering pattern restrictions may be included in a steering pattern policy, which may be defined by a network entity such as a PCF. The WTRU and / or a network function (such as a UPF) may implement processes that facilitate the application of these steering pattern restrictions. For example, the WTRU and / or the UPF may change (e.g., dynamically) the steering pattern when conditions at the WTRU and / or the UPF change. As another example, after the WTRU establishes a multi-access PDU (MA-PDU) session with the DualSteer function, the WTRU may have preferences regarding how to use two cellular access legs based on the WTRU's power state, roaming state, orientation, etc., and the techniques described herein may allow the WTRU to implement these preferences by dynamically determining how to use the two access legs.

[0090] A Steering Mode Policy (SMP) may be provided to a WTRU and / or a network function (such as a UPF). The SMP may include a list of steering mode rules. The steering mode rules may include one or more of a traffic descriptor, a steering mode descriptor, a steering mode priority, a configuration of a steering mode, or a validity constraint (e.g., also referred to herein as a validity condition) of a steering mode. The SMP may be provided to the WTRU in one or more of the following ways. The SMP may be provided via a PDU Session Establishment procedure. The SMP may be provided via a PDU Session Modification procedure. The SMP may be provided via a WTRU Configuration Update procedure. The SMP may be provided via a Registration procedure (e.g., in a Registration Accept message).

[0091] A steering mode policy may allow a network device or entity (e.g., a PCF) to configure one or more steering modes for a WTRU or another network device (e.g., a UPF). A steering mode policy may allow a WTRU (or UPF) to determine which steering mode to use (e.g., among multiple configured steering modes) based on certain conditions (e.g., dynamically).

[0092] Figure 3 An example of a steering mode strategy is shown. Figure 3As shown, a steering pattern policy may include one or more steering pattern rules, and multiple (e.g., all) steering pattern rules associated with the same traffic descriptor may be applied to the same service data flow (e.g., steering pattern rules 1-4 associated with traffic descriptor 1 may belong to the same service data flow, as shown in FIG. Figure 3 As shown). Figure 3 As shown, a steering pattern rule may be set as a default steering pattern rule (e.g., to be used when no other steering pattern rule is provided or valid). The steering pattern policy may indicate which steering pattern rule is the default steering pattern rule. In an example, the default steering pattern rule may have the lowest priority and / or may not have a validity limit (e.g., the default steering pattern rule may always be valid). The indication that a steering pattern rule is a default steering pattern rule may be implicitly provided, for example, based on the fact that there is no validity limit for the steering pattern rule or that the steering pattern rule is associated with the lowest steering pattern priority. The steering pattern rule may be set as the initial steering pattern rule to be used (e.g., when DualSteer is first enabled at the WTRU or UPF). Such an initial steering pattern rule may be indicated in the steering pattern policy.

[0093] One or more of the following validity constraints (also referred to herein as validity conditions) may be provided or configured for a steering pattern rule. A validity constraint may indicate the conditions under which a steering pattern rule may be valid or applicable. As an example, the validity constraint may be based on a time or schedule associated with the WTRU. For example, a steering pattern rule may specify a time period during which the rule may be considered valid for the WTRU (e.g., outside of the time period, the rule may be considered invalid). As another example, a validity constraint may be based on a location associated with the WTRU. For example, a steering pattern rule may specify a geo-fence location, a list of cell IDs, a list of tracking area IDs, a country, a proximity to a cell, a proximity to a UAV, a proximity to another WTRU, etc., for which the rule may be considered valid for the WTRU. As yet another example, a validity constraint may be based on the power of the WTRU. For example, a steering pattern rule may indicate whether the rule is valid when the WTRU is operating on battery power or when the WTRU is operating on mains power. A steering pattern rule may indicate a battery level (or state) at which the rule may be considered valid for the WTRU. The battery level or status may be defined in relative terms, such as "poor," "average," or "good." The battery level or status may be defined as a percentage, such as "less than 35%," "between 35% and 70%," "greater than 70%," and so on. As another example, the validity limit may be based on the orientation of the WTRU. For example, a turning mode rule may indicate whether the rule is valid when the WTRU is in portrait mode or when the WTRU is in landscape mode.

[0094] The validity limit may be based on a transmission mode, such as the UL transmission mode of the WTRU. Such a transmission mode may determine how the WTRU sends information (e.g., UL traffic) on an access branch. For example, a steering mode rule may indicate whether the rule is valid when a transmission (e.g., communication over an access branch) is performed via a specific device or a specific medium, such as, for example, via a terrestrial device (e.g., via a gNB or eNB), via a geostationary satellite, via a MEO satellite, via a LEO satellite, via a UAV, or via a ProSe WTRU. As another example, the steering mode rule may indicate whether the rule is valid when the transmission is performed on a specific RAT type, such as NR, LTE, a non-3GPP RAT, and / or the like. As yet another example, the steering mode rule may indicate whether the rule is valid when the transmission is performed on a specific type of frequency band, such as, for example, an unlicensed band, a licensed band, etc. As yet another example, the steering mode rule may indicate whether the rule is valid when the transmission is performed on one frequency band or multiple frequency bands.

[0095] Validity restrictions may be based on a transmission mode, such as a DL transmission mode. Such a DL transmission mode may determine how the WTRU receives information (e.g., downlink traffic) on an access branch. For example, a steering pattern rule may indicate whether the rule is valid when a downlink transmission (e.g., a DL transmission on an access branch) is performed via a specific device or a specific medium (e.g., a terrestrial device (e.g., a gNB or eNB), a geostationary satellite, a MEO satellite, a LEO satellite, a UAV, a relay WTRU, etc.). As another example, a steering pattern rule may indicate whether the rule is valid when a downlink transmission is performed on a specific RAT type, such as NR, LTE, a non-3GPP RAT, etc. As yet another example, a steering pattern rule may indicate whether the rule is valid when a downlink transmission is performed on a specific type of frequency band, such as, for example, an unlicensed band, a licensed band, etc. As yet another example, a steering pattern rule may indicate whether the rule is valid when a downlink transmission is performed on one frequency band or multiple frequency bands. As yet another example, a steering pattern rule may indicate whether the rule is valid when a downlink transmission is performed using multicast, broadcast, or unicast.

[0096] The effectiveness limit can be based on the cost associated with implementing the steering pattern or steering pattern rule. The effectiveness limit can be based on the performance of the transmission link, such as the UL performance or DL ​​performance on the access branch. For example, the steering pattern rule can indicate a minimum performance requirement (e.g., UL or DL ​​performance on the access branch) for the rule to be effective. If this performance requirement is not met, the rule can be considered invalid. For example, the steering pattern rule can indicate that the rule can be applied when the UL or DL ​​quality is poor.

[0097] The validity limit may be based on the Quality of Experience (QoE). QoE measurements may be provided by applications installed and running on the WTRU, such as reported by an application server, a network function, etc. Based on the QoE measurements, the WTRU may select one steering pattern rule over another.

[0098] Although validity restrictions may have been described individually herein, they may also be combined. In a first example combination, a steering pattern rule may be restricted to apply only at specific locations and specific times of the day. In this combination, a steering pattern rule may have a time-based restriction and a location-based restriction. For example, a steering pattern rule may indicate that the rule may be used between "8am and 9am" and "within 500 meters of geographic location (X,Y)." In a second example combination, a steering pattern rule may be restricted to apply only when the WTRU is connected via a relay WTRU and / or is moving slowly. In this combination, a steering pattern rule may have a UL transmission mode restriction and a speed restriction. For example, a steering pattern rule may indicate that the rule may be used when the UL transmission mode is "relay WTRU" and the speed of the WTRU (e.g., travel speed) is "<50kph."

[0099] A steering pattern policy may include multiple steering pattern rules associated with the same steering pattern. Figure 3 As shown, steering pattern rules 1, 2, and 3 can all be associated with steering pattern 1 (e.g., load balancing) with different configurations. Examples of these different configurations for (e.g., each) steering mode may include one or more of the following. For example, if the steering mode is set to load balancing, different configurations may have different percentage splits across multiple access legs, different steering pattern indicators, different measurement configurations for determining round-trip time (RTT) or packet loss rate (PLR), and / or different thresholds. If the steering mode is set to active-standby, different configurations may have different active legs and / or standby legs. If the steering mode is set to minimum delay, different configurations may have different measurement configurations for determining RTT. If the steering mode is set to priority-based, different configurations may have different priorities for different access legs, different measurement configurations for determining RTT, different measurement configurations for determining PLR, and / or different thresholds. If the steering mode is set to redundant steering mode, different configurations may have different primary access, different measurement configurations for determining RTT or PLR, or different thresholds.

[0100] The measurement configurations described herein may indicate what metric to measure (e.g., PLR and / or RTT) and / or when to measure the metric. For example, the measurement may be periodic based on the configuration (e.g., the measurement configuration may indicate that a measurement is performed every T milliseconds). As another example, the measurement may be aperiodic based on a detected event. For example, the measurement configuration may indicate that the measurement is performed after a cell change on an access branch or after an inter-RAT cell change on an access branch. The measurement configuration may indicate what information to send to the peer entity (e.g., for PLR or RTT measurements) and how often the information is sent.

[0101] A steering pattern rule may be augmented (eg, each) by adding a list of preferred access types that may be used to determine the access network to look up and / or connect to. For example, a steering pattern rule may indicate to the WTRU that the preferred access type is GEO.

[0102] The WTRU may take actions to enable or apply diversion mode (eg, including split, handover, diversion, and / or duplication) rules or restrictions. Figure 4 Example actions that may be performed by a WTRU to support steering pattern rules and / or dynamically and autonomously change steering patterns are shown. Figure 4 At 1, the WTRU may send a PDU session establishment message (e.g., a PDU session establishment request) to the network (e.g., to the AMF or SMF) to request establishment of a multiple access PDU (MA-PDU) session. The message may include an indication that the WTRU supports steering pattern rules and restrictions. The message may include an indication of the WTRU's preference regarding one or more access branches. As an example, such a preference may be related to minimizing the use of one transmission mode relative to another transmission mode. For example, the WTRU may indicate a preferred granularity (e.g., an expected granularity) and a preference for minimizing the use of NR relative to LTE. The preferred granularity may indicate the number of steering pattern rules expected by the WTRU. For example, the preferred granularity may indicate a preference for having at least three steering pattern rules associated with the transmission mode preference to minimize the use of NR relative to LTE. As another example, the preference may be related to maximizing the use of one transmission mode relative to another transmission mode. For example, the WTRU may indicate a preferred granularity (e.g., an expected granularity) and a preference for maximizing the use of operating band 1 relative to operating band 2, and the preferred granularity may indicate the number of steering pattern rules expected by the WTRU. For example, the preferred granularity may indicate a preference for having at least three steering pattern rules associated with the transmission mode preference to maximize the usage of operating band 1 relative to operating band 2.

[0103] As another example, the preference may be related to minimizing the use of roaming. For example, the WTRU may request to have a restriction on an access branch based on whether the access branch is in a VPLMN (e.g., the WTRU may prefer to limit the traffic associated with the access branch of the VPLMN to 25%). As another example, the preference may be related to time. For example, the WTRU may prefer to use certain accesses at certain times of the day, and the WTRU may provide an indication of the specific time and the preferred access. As another example, the preference may be related to the orientation of the WTRU. For example, the WTRU may request to have a restriction on an access branch based on the orientation of the WTRU (e.g., if the orientation of the WTRU is longitudinal, the WTRU may prefer to limit the traffic on the NR branch to 10%). As another example, the preference may be related to the power of the WTRU. For example, the WTRU may request to have a restriction on an access branch based on the power level or condition of the WTRU. The WTRU may provide an indication of the maximum traffic on the access branch and / or the corresponding power condition. For example, if the WTRU is battery powered, the WTRU may instruct the network to limit the traffic on the GEO leg to 10%, or if the WTRU is mains powered, the WTRU may instruct the network to split the traffic evenly across the two access legs.

[0104] As another example, the preference may be related to the speed of the WTRU (e.g., travel speed). For example, the WTRU may request to have an access leg restricted based on the WTRU's speed (e.g., if the WTRU's speed is greater than 50 mph, the WTRU may prefer to restrict the traffic on the access leg on the relay WTRU to 10%). As yet another example, the preference may be related to UL quality. For example, if the WTRU determines that the UL performance is below a certain threshold, the WTRU may request to have more measurement reports. As yet another example, the preference may be related to DL quality. For example, if the WTRU determines that the DL performance is below a certain threshold, the WTRU may request to have more measurement reports.

[0105] exist Figure 4 At 2, if the network accepts the WTRU's request to establish an MA-PDU session with steering mode restrictions, the network (e.g., SMF or PCF) may determine a steering mode policy for the WTRU (and / or for another network device such as a UPF), and the WTRU may receive the steering mode policy from the network (e.g., PCF), for example, via a PDU session establishment response. As described herein, the steering mode policy may include a list of steering mode rules and validity restrictions (e.g., validity conditions) for the steering mode rules.

[0106] exist Figure 4At 3, the WTRU may apply the initial steering pattern rules to split, switch, steer, and / or replicate traffic across multiple (e.g., two) access legs. The WTRU may follow the measurement configuration for the initial steering pattern rules (e.g., the WTRU may apply the measurement configuration as part of the initial steering pattern rules).

[0107] exist Figure 4 At 4, the WTRU may check one or more validity constraints or conditions for the steering mode rules configured for the WTRU. Such validity constraints or conditions may allow the WTRU to dynamically change the steering mode or switch to a different steering mode based on conditions at the WTRU (e.g., local conditions). The WTRU may traverse the configured steering mode rules (e.g., starting with the steering mode rule with the highest priority) and select a steering mode rule (e.g., a steering mode rule that is different from the initial steering mode rule) that may be considered valid (e.g., a steering mode rule may be considered valid if the validity constraints or conditions associated with the steering mode rule are met).

[0108] The WTRU may check the validity constraints for one or more steering pattern rules (e.g., for each steering pattern rule). For example, if the validity constraint is time-based, the WTRU may determine the current time and, if the time is considered valid according to the validity constraint, select the steering pattern rule. For example, if the validity constraint for applying the steering pattern rule is between 8 a.m. and 9 a.m., the WTRU may check to determine if the current time is between 8 a.m. and 9 a.m. As another example, if the validity constraint for the steering pattern rule is location-based, the WTRU may determine its current location and, if the location is considered valid according to the validity constraint, apply the steering pattern rule. The WTRU may determine the location based on the format of the validity constraint. For example, the validity constraint may specify the valid location as a geographic location, a list of cell IDs, a list of tracking areas, a list of IDs of nearby WTRUs, etc. Thus, if the validity constraint is related to a geo-fence, the WTRU may check to determine if its current geographic location is within the geo-fence. Similarly, if the validity constraint is related to a cell ID, the WTRU may check to determine if its current cell corresponds to that cell ID.

[0109] As another example, if the validity limit of the steering pattern rule is based on speed, the WTRU may determine its current speed (e.g., traveling speed) and select the steering pattern rule if the speed is valid according to the validity limit. The speed may be determined by an application in the WTRU, or it may be determined based on the number of cell selections over a period of time. As another example, if the validity limit of the steering pattern rule is based on power, the WTRU may determine its power state and select the steering pattern rule if the power state is valid according to the validity limit. For example, the WTRU may have 2 steering pattern rules, the first one having a validity limit set to "battery powered" and the second one having a validity limit set to "mains powered", and the WTRU may determine whether to apply the first steering pattern rule or the second steering pattern rule based on whether the WTRU is "battery powered" or "mains powered". The validity limit of the steering pattern rule may also be based on a battery state such as "good", "average", or "poor".

[0110] If the validity limit for the steering pattern rule is based on the WTRU's direction, the WTRU may determine its direction, and if the direction is valid according to the validity limit, the WTRU may select the steering pattern rule. If the validity limit for the steering pattern rule is based on the UL transmission mode, the WTRU may determine the UL transmission mode, and if the UL transmission mode is valid according to the validity limit, the WTRU selects the steering pattern rule. For example, the WTRU may determine the UL transmission mode based on information carried in the serving cell system information, which may include an indication of whether the cell is a terrestrial cell, a GEO cell, a LEO cell, or a MEO cell. The system information may also include an indication of the RAT type (e.g., NR versus LTE) or an indication of the PLMN of the serving cell. The WTRU may also determine the UL transmission mode based on dedicated RRC signaling with the serving cell, NAS signaling with the core network, discovery signaling exchanges with a UAV or relay WTRU, and / or a pre-configured mapping between UL frequencies and UL transmission modes. For example, the WTRU may be pre-configured with a mapping between UL frequencies and RAT types, or a mapping between UL frequencies and operating bands, or a mapping between UL frequencies and whether the frequency is in a licensed band or an unlicensed band.

[0111] If the validity limit for the steering mode is based on the DL transmission mode, the WTRU may determine the DL transmission mode, and if the DL transmission mode is valid according to the validity limit, the WTRU selects the steering mode rule. The WTRU may determine the DL transmission mode based on information carried in the serving cell system information. For example, the system information may include an indication of whether the cell is a terrestrial cell, a GEO cell, a LEO cell, or a MEO cell. The system information may also include an indication of the RAT type (e.g., NR versus LTE) or an indication of the PLMN of the serving cell. The WTRU may also determine the DL transmission mode based on dedicated RRC signaling with the serving cell, NAS signaling with the core network, discovery signaling exchanges with UAVs or relay WTRUs, and / or pre-configured mappings between DL frequencies and DL transmission modes. For example, the WTRU may be pre-configured with a mapping between DL frequencies and operating bands, or a mapping between DL frequencies and whether the frequency is a licensed band or an unlicensed band. As another example, the WTRU may determine whether the service data stream is provided via unicast transmission, broadcast transmission, or multicast transmission based on system information or dedicated signaling.

[0112] If the validity limit for the steering pattern rule is based on the UL quality on the access leg, the WTRU may determine the performance / quality of the UL on the access leg before applying the steering pattern rule. The UL performance may be based on UL statistics, such as HARQ feedback. Based on these statistics, the WTRU may use one or more thresholds to determine whether the UL quality is acceptable or poor. If the UL quality on the access leg is valid according to the validity limit, the WTRU may select the steering pattern rule.

[0113] If the validity limit of the steering pattern rule is based on the DL quality on the access leg, the WTRU may determine the performance / quality of the DL on the access leg. The DL performance may be based on DL measurements of the signal, channel, beam, carrier, link, etc. associated with the DL, such as RSRP, RSRQ, and RSSI. Based on these measurements, the WTRU may use one or more thresholds to determine whether the DL quality is acceptable or poor. If the DL quality on the access leg is valid according to the validity limit, the WTRU may select the steering pattern rule.

[0114] exist Figure 4At 5, if the WTRU dynamically changes the steering mode or switches to a different steering mode rule, the WTRU may notify the network (e.g., UPF) of the change or switch. This may be accomplished through a performance management function (PMF) message that may include one or more of the following: the steering mode rule the WTRU is using or will use, the WTRU's location, the WTRU's power state, the WTRU's direction, the WTRU's speed, the WTRU's trajectory, the WTRU's UL transmission mode, the WTRU's DL transmission mode, etc.

[0115] exist Figure 4 At step 6, the WTRU may apply the steering pattern rules that match the validity constraints or conditions to split, switch, steer, and / or replicate traffic on multiple (e.g., two) access legs. If necessary, the WTRU may follow the measurement configuration associated with the newly selected steering pattern rules.

[0116] exist Figure 4 7, the validity limit or condition may change, for example, due to a handover performed by the WTRU from a licensed band to an unlicensed band on access leg 2. As a result of the handover, a steering pattern rule with a higher priority may become valid, and in response, the WTRU may dynamically change its steering pattern to match the valid steering pattern rule.

[0117] exist Figure 4 At 8, the WTRU may notify the network (eg, such as a UPF) of the change, for example, via a PMF message.

[0118] exist Figure 4 At 9, the WTRU can operate according to the steering mode rules selected at 7.

[0119] Described here Figure 4 At 2, the network may decide to reject the PDU session establishment request from the WTRU. In this case, the network may configure the WTRU in single-steering mode, and the WTRU may accept the MA-PDU session established based on the single-steering mode, or the WTRU may reject the MA-PDU session established based on the single-steering mode and request a single access PDU (SA-PDU) session on a single access leg. In addition, Figure 4 The 5 associated operations can be done with Figure 4 6 related operations occur simultaneously, or in Figure 4 6 occurs after (e.g., immediately after). Figure 4 The 8 associated operations can be done with Figure 4 9 associated operations occur simultaneously with, or in conjunction with Figure 4 The operation associated with 9 occurs after (e.g., immediately after).

[0120] A WTRU may be configured with ATSSS (e.g., including DualSteer) capability and may perform one or more of the following operations associated with steering pattern restriction. The WTRU may send a PDU Session Establishment Request message to the network, which may indicate the WTRU's capability to support steering pattern restriction and / or the WTRU's preferences regarding the use of different access legs. The WTRU may receive a PDU Session Establishment Response (e.g., Accept) from the network, which may include a steering pattern policy (e.g., indicating a list of steering pattern rules). Based on the steering pattern policy, the WTRU may determine an initial steering pattern rule (e.g., based on validity limits associated with rules and conditions at the WTRU) and may follow the initial steering pattern rule to split, switch, steer, and / or replicate uplink traffic between multiple access legs (e.g., between two access legs under DualSteer) according to the rule. The WTRU may follow a measurement configuration associated with the initial steering pattern rule. Subsequently, the WTRU may determine that another steering pattern rule (e.g., a higher priority steering pattern rule) has become valid (e.g., applicable) based on the validity limits indicated in the steering pattern policy and / or conditions associated with the WTRU. In response, the WTRU may follow other (e.g., higher priority) steering pattern rules to split, switch, steer, and / or duplicate uplink traffic on the access leg. The WTRU may also follow measurement configurations associated with other steering pattern rules. Additionally, the WTRU may send a PMF message to the network (e.g., UPF) and may indicate in the PMF message the other steering pattern rules employed by the WTRU and / or their associated validity limits.

[0121] A network device or function (such as a UPF) may take action to enable diversion mode (eg, including split, switch, divert, and / or copy) rules or restrictions. Figure 5 Example operations of a network device (eg, such as a UPF) are shown, which may be associated with steering mode restrictions.

[0122] exist Figure 5 At 1, the network may accept a request from the WTRU to establish an MA-PDU session with one or more steering modes (e.g., dynamic steering mode) enabled, and the UPF of the network may receive a steering mode policy from another network device or function (e.g., PCF). The steering mode policy may include a steering mode rule list, which may also be indicated to the WTRU (e.g., via a PDU session establishment response indicating acceptance of the PDU session request).

[0123] exist Figure 52, the UPF may apply initial steering pattern rules to split, switch, redirect and / or copy traffic (e.g., downlink traffic) on multiple (e.g., two) access branches to the WTRU, and the WTRU may perform corresponding actions (e.g., follow certain measurement configurations) based on the initial steering pattern rules.

[0124] exist Figure 5 At 3, the UPF may check one or more validity constraints associated with the steering mode rule. This may allow the UPF to dynamically change the steering mode (e.g., DL steering mode) or switch to a different steering mode (e.g., a different DL steering mode) based on conditions at the WTRU (e.g., remote conditions) or conditions at the UPF (e.g., local conditions). The UPF may iterate through the steering mode rules (e.g., starting with the steering mode rule with the highest priority) and select an effective steering mode rule (e.g., a first steering mode rule) based on validity constraints (e.g., a steering mode rule may be considered effective if one or more validity constraints of the steering mode are satisfied). For example, the UPF may check the validity constraints associated with one or more configured steering mode rules (e.g., each configured steering mode rule) and determine which steering mode rule is applicable based on the constraints and / or the aforementioned conditions. If the validity constraints associated with the steering mode rule are based on time, the UPF may determine the current time and, if the time is considered effective according to the steering mode constraints, select a steering mode rule. For example, if the validity constraint is between 8:00 AM and 9:00 AM, the UPF may check to determine whether the current time is between 8:00 AM and 9:00 AM before selecting the corresponding steering mode rule. If the validity limit associated with the steering pattern rule is location-based, the UPF may determine the location information associated with the WTRU, and if the location information satisfies the steering pattern limit, the UPF may select the steering pattern rule. The location information may include a geographic location, a list of cell IDs, a list of tracking areas, a list of IDs of nearby WTRUs, etc. The UPF may determine the location information associated with the WTRU from a location management function (LMF) based on the WTRU's context for the N3 or N9 interface (e.g., cell ID), based on an indication received from the WTRU (e.g., via a PMF message), etc. For example, if the validity limit is associated with a geo-fence, the UPF may determine whether the WTRU's current geographic location is within the geo-fence. As another example, if the validity limit is associated with a cell ID, the UPF may determine whether the WTRU's current serving cell corresponds to the cell ID.

[0125] If the validity constraint associated with the steering pattern rule is speed-based, the UPF may determine the current speed of the WTRU (e.g., travel speed), and if the speed is considered valid according to the steering pattern constraint, the UPF selects the steering pattern rule. The UPF may determine the speed of the WTRU based on an indication received from the WTRU (e.g., via a PMF message) or from the LMF. If the validity constraint associated with the steering pattern rule is power-based, the UPF may determine the power level or power state of the WTRU, and if the power level or state is considered valid according to the steering pattern constraint, the UPF selects the steering pattern rule. The UPF may determine the power level or state of the WTRU based on an indication received from the WTRU (e.g., via a PMF message). If the validity constraint associated with the steering pattern rule is direction-based, the UPF may determine the direction of the WTRU, and if the direction is considered valid according to the steering pattern constraint, the UPF selects the steering pattern rule. The UPF may determine the direction of the WTRU based on an indication received from the WTRU (e.g., via a PMF message).

[0126] If the validity limit associated with the steering mode rule is based on the UL transmission mode, the UPF may determine the UL transmission mode and select the steering mode rule if the UL transmission mode is considered valid according to the steering mode limit. For example, the UPF may determine the UL transmission mode based on information provided by the serving cell. Such information may indicate whether the serving cell is a terrestrial cell, a GEO cell, a LEO cell, or a MEO cell. The information may also indicate the RAT type associated with the serving cell (e.g., NR or LTE), the frequency of the serving cell, the frequency band of the serving cell, whether the serving cell is licensed or unlicensed, whether the WTRU is connected via a UAV or a relay WTRU, etc.

[0127] If the validity restriction associated with the steering pattern rule is based on the DL transmission mode, the UPF may determine the DL transmission mode, and if the DL transmission mode is considered valid according to the steering pattern rule, the UPF selects the steering pattern rule. For example, the UPF may determine the DL transmission mode based on information provided by the serving cell. Such information may indicate whether the serving cell is a terrestrial cell, a GEO cell, a LEO cell, or a MEO cell. The information may also indicate the RAT type associated with the serving cell (e.g., NR or LTE), the frequency of the serving cell, the frequency band of the serving cell, whether the serving cell is licensed or unlicensed, whether the WTRU is connected via a UAV or a relay WTRU, etc. The information may also indicate whether the service data flow is provided via unicast transmission, multicast transmission, or broadcast transmission.

[0128] If the validity limit associated with the steering pattern rule is based on the UL quality on the access leg, the UPF may determine the UL performance on the access leg based on an indication received from the WTRU (e.g., via a PMF message) or an indication received from the access node. If the validity limit associated with the steering pattern rule is based on the DL quality on the access leg, the UPF may determine the DL performance on the access leg based on an indication received from the WTRU (e.g., via a PMF message) or an indication received from the access node.

[0129] exist Figure 5 At 4a, the UPF may notify another network device or function (e.g., SMF or AMF) of the change in the steering pattern rules and / or a set of changed criteria associated with the steering pattern rules.

[0130] exist Figure 5 At 4b, the UPF may notify the WTRU of the change in the steering pattern rules (e.g., from the initial steering pattern rules to the first steering pattern rules). This may be achieved through a PMF message, which may include information about the steering pattern rules to be applied by the UPF.

[0131] exist Figure 5 At 5, the UPF may apply a first steering pattern rule to split, switch, steer, and / or replicate traffic (e.g., downlink traffic) on multiple (e.g., two) access legs. As part of applying the first steering pattern rule, the UPF may follow a measurement configuration of the first steering pattern rule.

[0132] exist Figure 5 In accordance with 6a, the WTRU may (e.g., dynamically) change a steering mode (e.g., UL steering mode) and may send an indication of the change to the UPF. The indication may be sent via a PMF message, which may indicate a steering mode rule (e.g., UL steering mode rule) used by the WTRU or a set of changed criteria (e.g., validity limits) applied by the WTRU.

[0133] exist Figure 5 At step 6b, the access node (e.g., a RAN node such as a base station) may also send an indication to the UPF that the DL transmission mode (e.g., from RAN to WTRU) has changed. For example, the RAN node may indicate to the UPF that a service data flow provided via unicast transmission is now provided via multicast transmission.

[0134] exist Figure 5 At 7, the UPF may select / apply a matching steering pattern rule (e.g., a second steering pattern rule) based on the indication received at 6a and / or 6b to split, switch, steer, and / or replicate traffic (e.g., downlink traffic) on multiple (e.g., two) access branches, and the UPF may Figure 5 8 to notify another network function (e.g., SMF or AMF) of the change in the steering mode rules.

[0135] exist Figure 5 At 9, the UPF may notify the WTRU of the change in the steering pattern rules. This may be achieved through a PMF message, which may include information about the steering pattern rules that the UPF has applied or will apply. Figure 5 At 10, the UPF can apply the steering mode rules and operate accordingly.

[0136] Described in this article Figure 5 The operations associated with 6a can be done with Figure 5 5 associated operations occur simultaneously, or in conjunction with Figure 5 The operation associated with 5 occurs after Figure 5 The operations associated with 9 can be done with Figure 5 The 10 associated operations occur simultaneously, or in conjunction with Figure 5 The 10 associated operations occur afterwards.

[0137] A network device or function, such as a UPF, may be configured with ATSSS (e.g., including DualSteer) capabilities and may perform one or more of the following operations associated with steering pattern restrictions. The UPF may receive a session establishment request, such as an N4 session establishment request, that may include a steering pattern policy (e.g., including a steering pattern rule list). Based on the steering pattern policy, the UPF may check one or more validity conditions or restrictions associated with the steering pattern rules to determine an initial steering pattern rule. The UPF may follow the initial steering pattern rule to split, switch, steer, and / or replicate traffic (e.g., downlink traffic) across multiple access legs (e.g., two access legs under DualSteer). The UPF may follow the measurement configuration associated with the initial steering pattern rule. The UPF may use the validity conditions to determine that another (e.g., higher priority) steering pattern rule has become valid and may follow (e.g., switch to) the other (e.g., higher priority) steering pattern rule to split, switch, steer, and / or replicate traffic (e.g., downlink traffic) across the multiple access legs. The UPF may follow the measurement configuration associated with the other (e.g., higher priority) steering pattern rule. The UPF may send a PMF message to the WTRU and may include information about other (eg, higher priority) steering pattern rules in the message.

[0138] A network device or function, such as a PCF, may take action to enable or support steering mode restrictions. The PCF may provide a steering mode policy (e.g., including a set of steering mode rules) to another network device or function, such as an SMF. The PCF may determine the steering mode policy based on one or more of the following inputs. A first input may include requirements associated with the service data flow. For example, these requirements may be received from an application function (AF). A second input may include the steering mode capabilities of the WTRU, a third input may include the steering mode capabilities of the network device, and a fourth input may include one or more preferences of the network operator. For example, a network operator may have certain agreements with other operators and may support the use of specific access legs from those other operators. As another example, the network operator may want to push more traffic on an access leg that may be using unlicensed spectrum. As yet another example, the network operator may want to push more traffic on an access leg that may be associated with a GEO or on an access leg during certain times of the day. The inputs used by the PCF to determine the steering mode policy may also include one or more preferences of the WTRU, which may be provided by the WTRU during a PDU session establishment procedure or a PDU session modification procedure. These preferences may relate to preferred RAT, non-preferred RAT, preferred frequency band, non-preferred frequency band, preferred PLMN, non-preferred PLMN, capping or limiting of traffic on a particular access leg based on the WTRU's power, direction, speed, etc.

[0139] A network device or function, such as a PCF, may perform one or more of the following to determine a steering mode policy. The PCF may receive a requirement for a service data flow from the AF. The PCF may determine the steering mode capabilities of the WTRU. The PCF may receive preferences from a network operator regarding conditions under which the operator may prefer one access branch over another. The PCF may receive a PDU session establishment request that may indicate a preference of the WTRU for one access branch over another. The PCF may determine a steering mode policy for the service data flow and provide the steering mode policy to another network function, such as an SMF.

[0140] Figure 6 Examples of operations that may be performed by a WTRU and / or network device with respect to steering pattern rules and restrictions are shown. Figure 6As shown, the WTRU may send a PDU (e.g., MA-PDU) session establishment request to the network (e.g., an SMF associated with the network) at 1, and the network (e.g., a PCF associated with the network) may determine a steering mode policy at 2, which may include a set of steering mode rules and / or their associated validity limits or conditions. At 3, the network (e.g., PCF) may send the steering mode policy to the SMF (e.g., as part of a Policy and Charging Control (PCC) rule), which may forward the steering mode policy to the WTRU at 4 (e.g., in a PDU Session Establishment Response that accepts the PDU Session Establishment Request).

[0141] exist Figure 6 At 5, the WTRU may apply an initial or default steering pattern rule (e.g., associated with steering pattern 1) to split, switch, steer, and / or duplicate traffic (e.g., uplink traffic) on at least one of the plurality of access legs. Subsequently, at 6, the WTRU may check one or more validity constraints associated with the steering pattern policy and select a different steering pattern rule (e.g., associated with steering pattern 2) based on the validity constraints and / or conditions at the WTRU. The WTRU may notify the network (e.g., a UPF associated with the network) of the newly selected steering pattern rule, for example, by sending a PMF message to the UPF at 7, and may apply the newly selected rule at 8 to split, switch, steer, and / or duplicate traffic on at least one of the plurality of access legs (e.g., the PMF message may be sent before or during application of the newly selected steering pattern rule).

[0142] Although the above features and elements are described in specific combinations, each feature or element can be used alone without the other features and elements of the preferred embodiment, or in various combinations with or without the other features and elements. And although the implementation described herein may consider 3GPP specific protocols, it should be understood that the embodiments described herein are not limited to such scenarios and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it should be understood that the solutions described herein are not limited to such scenarios and may also be applied to other wireless systems.

[0143] The above process may be implemented in a computer program, software, and / or firmware that is incorporated into a computer-readable medium for execution 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, but not limited to, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as compact disc (CD)-ROMs and / or digital versatile discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver used in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), the WTRU comprising: A processor configured to: receiving a first message from a network device, wherein the first message indicates at least first and second rules for performing uplink transmission associated with a protocol data unit (PDU) session across a first network access leg and a second network access leg; performing a first uplink transmission associated with the PDU session via at least one of the first network access branch and the second network access branch according to the first rule determining that a condition for applying the second rule is satisfied; as well as Based on determining that a condition for applying the second rule is satisfied, performing a second uplink transmission associated with the PDU session via at least one of the first network access branch and the second network access branch according to the second rule.

2. The WTRU of claim 1 , wherein: The first rule indicates a first manner, which is used to divert, switch, split or copy the uplink transmission associated with the PDU session across the first network access branch and the second network access branch, and wherein the second rule indicates a second manner, which is used to divert, switch, split or copy the uplink transmission associated with the PDU session across the first network access branch and the second network access branch.

3. The WTRU of claim 1 or claim 2, wherein: The first rule further indicates a validity condition for the first rule, and wherein the second rule further indicates a validity condition for the second rule.

4. The WTRU of claim 3 , wherein: The processor being configured to determine that a condition for applying the second rule is satisfied includes the processor being configured to determine that a validity condition for the second rule is satisfied.

5. The WTRU of claim 3 , wherein: The validity condition for the first rule or the second rule is associated with the time at the WTRU, the location of the WTRU, the orientation of the WTRU, the power of the WTRU, the travel speed of the WTRU, a quality of experience (QoE) measurement associated with the WTRU, or the transmission mode of the WTRU.

6. The WTRU of any one of claims 1 to 5, wherein: The processor is further configured to send a second message to the network device, the second message indicating that the WTRU is switching to the second rules.

7. The WTRU of any one of claims 1 to 6, wherein: The processor is further configured to send a session establishment request associated with the PDU session to the network device, wherein the session establishment request indicates the WTRU's preference for at least one of the first network access branch and the second network access branch, and wherein the first message is received from the network device as part of a PDU session establishment response.

8. The WTRU of any one of claims 1 to 7, wherein: The first network access branch is associated with a first cellular communication network, and the second network access branch is associated with a second cellular communication network.

9. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: receiving a first message from a network device, wherein the first message indicates at least first and second rules for performing uplink transmission associated with a protocol data unit (PDU) session across a first network access leg and a second network access leg; performing, according to the first rule, a first uplink transmission associated with the PDU session via at least one of the first network access branch and the second network access branch; determining that a condition for applying the second rule is satisfied; as well as In response to determining that a condition for applying the second rule is satisfied, performing a second uplink transmission associated with the PDU session via at least one of the first network access branch and the second network access branch according to the second rule.

10. The method according to claim 9, wherein: The first rule indicates a first manner for diverting, switching, splitting, or duplicating uplink transmissions associated with the PDU session across the first network access branch and the second network access branch, and wherein the second rule indicates a second manner for diverting, switching, splitting, or duplicating uplink transmissions associated with the PDU session across the first network access branch and the second network access branch.

11. The method of claim 9 or claim 10, wherein the first rule further indicates a validity condition for the first rule, wherein the second rule further indicates a validity condition for the second rule, and wherein determining that a condition for applying the second rule is satisfied comprises: It is determined that the validity condition of the second rule is satisfied.

12. The method according to claim 11, wherein The validity condition for the first rule or the second rule is associated with the time at the WTRU, the location of the WTRU, the orientation of the WTRU, the power of the WTRU, the travel speed of the WTRU, a quality of experience (QoE) measurement associated with the WTRU, or the transmission mode of the WTRU.

13. The method of any one of claims 9 to 12, further comprising sending a second message to the network device, the second message indicating that the WTRU is switching to apply the second rule.

14. The method according to any one of claims 9 to 13, the method further comprising transmitting a session establishment request associated with the PDU session to the network device, wherein the session establishment request indicates the WTRU's preference for at least one of the first network access branch and the second network access branch, and wherein the first message is received from the network device as part of a PDU session establishment response.

15. The method according to any one of claims 9 to 14, wherein The first network access branch is associated with a first cellular communication network, and wherein the second network access branch is associated with a second cellular communication network.

Images