Method and apparatus for analysis-based user plane optimization

Abstract

Processes, methods, architectures, apparatuses, systems, apparatuses, and computer program products relating to analysis-based user plane optimization are provided. A first network entity (NE) may: receive information from a second NE indicating an analysis-based operation for access traffic steering, offloading, and handover (ATSSS) and a first weight and a first weighting factor for a plurality of access networks; transmitting information indicating the analysis-based operation to a third NE, the information including the first weight and the weighting factor; transmitting third information indicating a load metric to a fourth NE; receiving, from the fourth NE, information indicating a traffic-directed analysis for controlling a multiple access protocol data unit session, the information comprising second weights and / or second weighting factors of the plurality of access networks, wherein the analysis is based on the load metric and a criterion for dividing downlink traffic among the plurality of access networks; and transmitting information indicating the second weight and / or the second weighting factor to the third UE.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the benefit of U.S. Provisional Patent Application No. 63 / 324,457, filed on March 28, 2022, which is incorporated herein by reference. Background Art

[0003] The present application relates to wired and / or wireless communications, including, for example, performing any analysis-based user plane optimization, including, for example, analysis-based operations for access traffic steering, splitting and switching (ATSSS). BRIEF DESCRIPTION OF THE DRAWINGS

[0004] A more detailed understanding may be obtained from the following detailed description given by way of example in conjunction with the accompanying drawings. As with the detailed description, each of the figures in such drawings is exemplary. Therefore, each of the figures and detailed description should not be considered limiting, and other equally effective examples are possible and possible. In addition, the same reference numerals ("reference numerals") in the various figures ("Figures") indicate the same elements, and wherein:

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

[0006] 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 the communication system is shown;

[0007] Figure 1C is a diagram showing that according to an embodiment, Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within the illustrated communication system;

[0008] Figure 1D is a diagram showing that according to an embodiment, Figure 1A A system diagram of yet another example RAN and yet another example CN used within the communication system shown;

[0009] Figure 2 is a diagram illustrating an example of a wireless transmit receive unit and / or user plane function (WTRU / UPF) flexibly deciding a weight factor on a first access network and a second access network;

[0010] Figure 3 is a diagram illustrating an example for a WTRU / UPF to flexibly decide weighting factors on a first access network and a second access network, where there is a constraint on the maximum allowed weighting factor of the first network;

[0011] Figure 4is a system block diagram illustrating the interactions between access traffic steering, splitting and switching (ATSSS) related functions and / or entities according to an embodiment;

[0012] Figure 5 is a diagram illustrating an example of an embodiment that enables a WTRU / UPF to flexibly decide weight factors on a first access network and a second access network taking into account operator preferences;

[0013] Figure 6 is a signaling diagram illustrating example interactions between 5G Core (5GC) network functions and / or entities according to an embodiment;

[0014] Figure 7 is a signaling diagram illustrating the interaction between a Multiple Access Traffic Manager (MATM) and other components / modules of a WTRU according to an embodiment; and

[0015] Figures 8 to 10 is a flow chart illustrating an example process for performing analytics-based user plane optimization. DETAILED DESCRIPTION

[0016] In the following detailed description, many specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples can be practiced without some or all of the specific details set forth herein. In other cases, well-known methods, programs, components and circuits are not described in detail to avoid blurring the following description. In addition, the embodiments and examples not specifically described herein can replace the embodiments and other examples explicitly, implicitly and / or inherently described, disclosed or otherwise provided (collectively referred to as "providing") herein to practice or practice in combination with them. Although various embodiments in which equipment, systems, devices, etc. and / or any of its elements perform operations, processes, algorithms, functions, etc. and / or any part thereof are described and / or claimed herein, it should be understood that any embodiment described and / or claimed herein assumes that any equipment, systems, devices, etc. and / or any of its elements are configured to perform any operations, processes, algorithms, functions, etc. and / or any part thereof.

[0017] Example Communication System

[0018] Figure 1A1 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 broadband). 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-s 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, Internet 110 and other networks 112, but 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 (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, 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 an industrial and / or automated process chain), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.

[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, a master Node B, a master eNodeB, a gNB, an NR NodeB, 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] The base station 114a may be part of the 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), a relay node, etc. The base station 114a and / or the 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 a cell (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of a licensed spectrum and an unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographic area that may be relatively fixed or may vary over time. The cell may also be divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the 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, etc. 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 Radio Access (UTRA) which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0024] In an 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 establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0025] In an 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 an 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 (Wi-Fi), 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 location, 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 an 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-a Pro, NR, etc.) to establish a microcell or a femtocell. Figure 1A As shown, base station 114b may be directly connected to Internet 110. Therefore, base station 114b may not need to access 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 calls, 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 that 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 an NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi 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) in 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 use 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 example 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 source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination 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 the transceiver 120 are depicted as separate components, but it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0034] The transmit / receive element 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via an air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be appreciated that the transmit / receive element 122 may 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 the figure, 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 to 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 for enabling 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 may receive user input data from: a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a 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, etc. In other embodiments, the processor 118 may access information from and store data in a 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 the power to 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 the 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 gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0041] The WTRU 102 may include a full-duplex radio in which transmission and reception of some or all of the signals (e.g., associated with specific subframes for both uplink (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 139 to reduce and or substantially eliminate self-interference via hardware (e.g., chokes) 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 transmission and reception of some or all of the signals (e.g., associated with specific subframes for both uplink (e.g., for transmission) or ...

[0042] Figure 1C 1 is a system diagram showing the RAN 104 and the CN 106 in accordance with an embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 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 uplink (UL) and / or downlink (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 being 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, etc. The MME 162 may provide a control plane function for 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 DL 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) 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] Although 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 communications interface with a communications network.

[0051] In a representative embodiment, 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 (STA) associated with the AP. The AP may access a distribution system (DS) or another type of wired / wireless network that loads traffic into and / or out of the BSS or has an interface thereto. Traffic originating from outside the BSS to the STA may be reached by the AP and may be delivered to the STA. Traffic from the STA to a destination outside the BSS may be sent to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be sent by the AP, for example, where the source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be sent between the source STA and the destination STA using a direct link setup (DLS) (e.g., directly sent between them). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel 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 the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP can send beacons 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 an 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-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 particular STA and / or is determined to be busy, the particular STA can back off. One STA (e.g., only one station) can transmit in a given BSS at any given time.

[0054] A high throughput (HT) STA 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 the 40 MHz wide channel.

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

[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 channel operating channels and carriers used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz and 20MHz bandwidths in TV white space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support instrument type control / machine type communication, 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] A WLAN system that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) includes a channel that can be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, due to a STA (which only supports a 1MHz operating mode) transmitting to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

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

[0059] Figure 1D1 is a system diagram showing 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, 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, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 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 an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be located on an unlicensed spectrum, while the remaining component carriers may be located on a licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the 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 transmission 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 different numbers of OFDM symbols and / or lasting different lengths of 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 anchors. 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 WTRU 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 WTRU 102a, 102b, 102c may implement the DC principle 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 WTRU 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRU 102a, 102b, 102c.

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

[0064] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least two session management functions (SMFs) 183a, 183b, and possibly data networks (DNs) 185a, 185b. While each of the foregoing 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 the WTRU 102a, 102b, 102c is utilizing. For example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 182a, 182b 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-A Pro) and / or non-3GPP access technologies (such as Wi-Fi).

[0066] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected 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 the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating UE 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, etc.

[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) as an interface between the CN 115 and the PSTN 108. In addition, 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 be connected to local data networks (DNs) 185a, 185b via the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0069] Given that Figures 1A to 1D and Figures 1A to 1D In the embodiment of the present invention, one or more or all of the functions described herein for one or more of the following may be performed by one or more simulation devices (not shown): WTRU 102a to 102d, base station 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b and / or any other device described herein. The simulation device may be one or more devices configured to simulate one or more or all of the functions described herein. For example, the simulation device 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 fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more or all functions when temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled 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 implemented / deployed as 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 implement testing 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 circuits (e.g., which can include one or more antennas) to transmit and / or receive data.

[0072] introduce

[0073] Access Traffic Steering, Diversion and Switching (ATSSS)

[0074] The Access Traffic Steering, Diversion and Switching (ATSSS) framework enables the use of multiple access networks (e.g., 3GPP and non-3GPP access networks) in combination. It implements the access traffic steering / diversion / switching policy via the N4 rule to the UPF and via the ASSS rule to the WTRU. For example, a given traffic steering rule (steering rule terminology is used to represent the steering / diversion / switching pattern) may assign a portion of the ongoing traffic to a first (e.g., 3GPP) network and the rest of the traffic to a second (e.g., non-3GPP) network. Another example may be to assign a priority indicator to one of the access networks to consider it as the first choice for steering the traffic flow. ASSSS has been studied in Release 16 and Release 17 of 3GPP SA2. In addition, recently, Release 18 has accepted a Phase 3 ATSSS research project proposal.

[0075] According to the 3GPP specifications since Release 16 ATSSS [1], a total of four steering modes are defined, namely, (i) active-standby steering mode, (ii) minimum delay steering mode, (iii) static load balancing steering mode, and (iv) priority-based steering mode.

[0076] Active-standby steering mode is used to direct all traffic for a multiple access protocol data unit (MA-PDU) session to only one access, which is called the "active" access. The other access acts as a "standby" access and receives traffic only when the active access becomes unavailable. The term "packet data unit" and its abbreviation "PDU" may be referred to interchangeably with the term "protocol data unit" (e.g., according to the 3rd Generation Partnership Project ("3GPP"); Technical Specification Group Services and Systems Aspects; System Architecture for 5G System (5GS); Stage 2 (Release 17), 3GPP TS 23.501 v17.3.0.).

[0077] The minimum delay steering mode is used to steer traffic to a high priority access, which is an access that can provide the minimum round trip time (RTT) performance. The performance measurement function (PMF) can be used to determine the delay of each access link, or alternatively, the multipath transmission control protocol (MPTCP) can be used to obtain such delay measurements.

[0078] Static load balancing steering mode is used to split traffic between two access networks based on the ratio of how much traffic should be sent through 3GPP access and non-3GPP access. The weight information element is used to indicate the ratio of traffic to be forwarded to 3GPP and non-3GPP access networks. According to 3GPP specifications since Release 16, static load balancing steering mode is only applicable to non-guaranteed bit rate quality of service (non-GBR QoS) flows.

[0079] The priority-based steering mode is used to steer all traffic matching the rules published by the Policy Charging Control (PCC) network element to the high priority access network until this access network is determined to be congested. Both accesses are assigned priorities and all traffic for the MA-PDU session is sent to the high priority access. When congestion occurs on the high priority access, new data flows ("overflow" traffic) are sent to the low priority access. In addition, when the high priority access suddenly becomes unavailable, all traffic is forwarded to another access (low priority). It should be noted that the definition of a congested link is implementation specific.

[0080] Release 17 ATSSS [2] introduces a new steering mode called autonomous steering mode and describes features to be considered during the specification phase. According to the autonomous steering mode, when the load balancing steering mode is used, the WTRU and the UPF can freely and independently decide how to split the traffic on the two accesses. For all steering modes, the network may provide a WTRU assisted indication that indicates (a) the WTRU may decide how to allocate UL traffic based on its internal state (e.g., battery level), and (b) the WTRU may request the UPF to apply the same allocation to DL traffic and the UPF may consider the WTRU's request when deciding the DL transmission traffic allocation. For all steering modes, the WTRU requests the UPF to apply the same allocation to DL traffic by using the PMF protocol (if available) or another mechanism (if the PMF protocol is not available). The other mechanism will be determined during the specification phase of operation. For the load balancing steering mode with fixed weights and the priority-based steering mode, a threshold condition may be applied that indicates whether the measured parameter is above or below a threshold. The measurement parameters in the threshold conditions may include (a) RTT (e.g., derived from the packet delay budget (PDB)) and (b) packet loss rate (derived from the maximum packet loss rate (MPLR) or the packet error rate (PER)). In addition, since the QoS requirements are per service data flow (SDF) / service, the threshold conditions for both 3GPP access and non-3GPP access will be the same.

[0081] According to 3GPP starting from Release 18, ATSSS[3] will study the objectives of enhancing ASSSS features, such as (i) how to support redundant traffic steering by duplicating packets on two accesses (for both GBR traffic and non-GBR traffic), and (ii) study how to switch traffic of MA PDU sessions between two non-3GPP access paths in the same Public Land Mobile Network (PLMN).

[0082] Network enabling automation (eNA) and network data analysis function (NWDAF)

[0083] 3GPP studied eNA only for 5G Core (5GC) Network Function (NF) in Release 16 and Release 17. In Release 17, there are use cases and key issues around real-time data collection and analysis delivery, NWDAF-assisted user plane optimization, NWDAF-assisted user plane performance, and user plane optimization at the edge. In general, NWDAF is used for data collection and data analysis. Certain analyses can be performed independently by 5GC NF; therefore, an NWDAF instance specific to that analysis can be collocated with the 5GC NF. Data used as analysis input by the 5GCNF can also be used to allow a centralized NWDAF deployment option. The 5GC NF and Operations Administration and Management (OAM) decide how to use the data analysis provided by the NWDAF to improve network performance.

[0084] NWDAF uses the existing service-based interface (SBI) to communicate with other 5GC NFs and OAM. 5GC NF can use SBI to expose the results of data analysis to any consumer NF[4]. For example, for NWDAF-assisted user plane optimization: (i) collect service experience / quality of experience (QoE) data from application function / network exposure function (AF / NEF); (ii) collect QoS flow-level network data from AMF (e.g., location / area of ​​interest), SMF (e.g., QoS flow identifier (QFI), single network slice selection assistance information (S-NSSAI), UPF information, data network name (DNN), WTRU ID), UPF (e.g., bit rate, packet delay, packet (re)transmission), policy control function / session management function (PCF / SMF) (e.g., application ID); (iii) collect per-access network performance data from UPF, such as access type (3GPP or non-3GPP) and DL round-trip time; and (iv) collect WTRU-level network data from OAM, such as per-WTRU measurements of reference signal received power (RSRP), reference signal received quality (RSRQ), signal-to-interference and noise ratio (SINR), and cell energy saving state.

[0085] Based on the collected input data, NWDAF provides service experience statistics / predictions for each UP (user plane) path, including the service experience for the RAT type or the network performance level for the access type, its spatial effectiveness, validity period and prediction confidence. Although it is assumed that how NWDAF collects data from UPF is not defined in Release 17, there is a new research project in SA2 Release 18, called UPF Exposure Enhancement and SBA (FS_UPEAS) [5], and there is also a Phase 3 research project for eNA, which also focuses on supporting UPF data reporting for analysis [6].

[0086] AI / ML-based services (AIMLsys)

[0087] The use cases and potential performance requirements for 5G system support for artificial intelligence (AI) / machine learning (ML) model distribution and transmission (e.g., download, upload, update, etc.) are studied in 3GPP as AI / ML Model Transmission (AMMT) and studied as a study item in 3GPP SA1 Release 18 [7]. The study item also identifies the traffic characteristics of AI / ML model distribution, transmission and training for various applications (e.g., video / speech recognition, robotic control, automotive, other vertical industries, etc.). Aspects related to AI / ML operation partitioning between AI / ML endpoints, AI / ML model / data distribution and sharing on 5G systems, and distributed / federated learning on 5G systems are addressed. Some requirements in the AMMT study assume that AI / ML service support at the application client is running on the WTRU. As mentioned above, for the purpose of network automation, analysis and / or prediction within the 5GC has been performed by the NWDAF. In SA2 Release 18, the evolution of 5GS for supporting device-based application AI / ML training or inference services under the AIMLsys study item is proposed [8]. More specifically, the Release 18 AIMLsys study focuses on [8]: (i) extensions to 5GS information exposure for 5GCNF to expose WTRU and / or network conditions and performance predictions (e.g., location, QoS, load, congestion, etc.) and whether and how such information should be exposed to the WTRU and / or authorized third parties to assist in application AI / ML operations; (ii) enhancements to external parameter provisioning to 5GC based on application AI / ML operations (e.g., expected WTRU activity behavior, expected WTRU mobility, etc.); (iii) investigation of enhancements to other 5GC features that can be used to assist in AI / ML operations (e.g., assist in application layer reasoning feedback); (iv) study of possible QoS policy enhancements to support application AI / ML operation traffic while supporting regular (non-application AI / ML) 5GS user traffic; and (v) study of whether and how 5GS can provide assistance to AF and WTRU so that AF and WTRU can manage “just in time” federated learning (FL) operations and model distribution / redistribution.

[0088] Private Network

[0089] The basic functionality of non-public networks (NPNs), in other words, private networks, was introduced in Release 16 and further enhanced in Release 17 to enable broader collaboration between different networks / different entities to support the use case of NPNs providing access to WTRUs. Private networks can be completely separate from the network of a mobile network operator (MNO), such as a standalone non-public network (SNPN), or partially integrated with a public network, such as a public network integrated non-public network (PNI-NPN). In Release 18, NPNs will be further studied to (i) support direct connectivity of non-3GPP access networks to the 5GC of the SNPN and (ii) support localized services such as high-resolution video services in venues / stadiums via locally hosted NPNs[9]. There are already non-3GPP access technologies in use in various locations such as enterprises and campuses, and it is expected that such non-3GPP access technologies will continue to evolve. Integrating these existing assets in SNPNs will increase flexibility for SNPN operators.

[0090] Problems with legacy systems

[0091] The current working principle of version 16ATSSS can be described as follows:

[0092] i. PCF defines ATSSS policies and sends these policies to SMF.

[0093] ii. The SMF generates ATSSS rules based on the policy information received from the PCF, and the WTRU / UPF receives ATSSS / N4 rules from the SMF. These rules include the steering mode and the priority index, weight factor, etc. depending on the selected steering mode to indicate how uplink / downlink traffic should be routed on 3GPP access and non-3GPP access.

[0094] iii. The WTRU / UPF performs measurements and compares them with the configured reporting thresholds.

[0095] iv. The WTRU / UPF compares the measurements with the corresponding measurement thresholds configured by the operator to determine how to steer the traffic.

[0096] In this workflow, the WTRU and UPF cannot flexibly allocate traffic on 3GPP and non-3GPP accesses based on the real-time link status. In other words, the traffic allocation is based on a predetermined weight factor provided by the network operator as a PCF rule. As mentioned above, in Release 17, a new steering mode named autonomous steering mode is proposed as a solution to the above problem. Therefore, the working principle of this mode is as follows:

[0097] i. The PCF / SMF does not send a predetermined weighting factor, or sends an initial weighting factor (for Release 16 WTRUs, the PCF / SMF will send a predetermined weighting factor), and

[0098] ii. The WTRU and UPF dynamically adjust the weighting factor for each access on the uplink and downlink respectively (for Release 16 WTRUs, the WTRU and UPF do not adjust the weighting factor).

[0099] This procedure has the following disadvantages:

[0100] a. First, network operators cannot simultaneously incorporate preferences that reflect their charging policies or service level agreements (SLAs) and achieve user plane optimization that the self-directed model can achieve;

[0101] b. Second, since the WTRU and UPF use performance measurements to dynamically adjust the weighting factors, the performance measurements may vary from one time period to another due to the increase / decrease in traffic load on the two accesses. Therefore, there may be a situation where the weighting factors of different accesses change frequently for similar values, like a ping-pong effect, thereby increasing the weighting factor in one time period and decreasing the weighting factor in the next time period;

[0102] c. Third, since the network may provide a WTRU assisted indication indicating that the WTRU may decide how to allocate UL traffic based on its internal state (e.g., battery level) and may request the UPF to apply the same allocation to DL traffic, the WTRU's request will be based on a selfish decision and may be detrimental to the overall network performance (i.e., the network and other WTRUs that are using the network). Currently, the ability of the UPF to have such a decision mechanism and how the UPF takes into account each WTRU's request when deciding on the DL transmission traffic allocation is not defined.

[0103] A solution to overcome the first and third disadvantages may first consider adjusting the weight factor (gradually increasing / decreasing) by an implementation-specific amount when one of the access links is considered broken (i.e., not within the configured threshold). Then, after both accesses are considered valid (i.e., within the configured threshold), the weight factor may be readjusted to the weight factor indicated by the PCF. While this solution may prevent deviations from the rules indicated by the PCF, it does not mean that it guarantees convergence to the PCF rules / weight factors. In addition, the proposed gradual increase / decrease method: (i) does not provide complete flexibility for the WTRU and UPF, as it considers the case where only one access is valid; or (ii) will suffer from the mentioned ping-pong effect.

[0104] As mentioned in the second shortcoming, the WTRU and UPF determine the weight factors based on a combination of the current (real-time) link status and RTT threshold, UL / DL maximum packet loss rate, UL / DI maximum jitter, and the WTRU's internal state (e.g., battery power), and do not define a mechanism for the WTRU and UPF to improve the overall network performance in the local area of ​​interest or to make proactive / predictive decisions rather than reactive decisions.

[0105] To illustrate the shortcomings mentioned, Figure 2 An example is shown in which the WTRU / UPF can flexibly determine the load balancing weight factor. Figure 2 , lines 200A and 200B represent operator preferences (Op.pref.) for 3GPP and non-3GPP access technologies, respectively, and lines 202A and 202B represent instantaneous averages (Avg.) of weight factor assignments on 3GPP and non-3GPP networks, respectively. Time period t1 to t15 is a function of time and is defined by a fixed time interval.

[0106] In autonomous steering mode, the network may assign initial weights, but these weights may be overridden by the WTRU and UPF. Therefore, when the WTRU and UPF flexibly assign weight factors, neither of them is aware of or takes into account the operator's preferred weight factors. In the example considered, until time period t7, the operator preference was indicated as 80% on 3GPP and 20% on non-3GPP access networks, and then as 70% on 3GPP and 30% on non-3GPP access networks. Since the weight factor assignment is based on instantaneous link conditions and thresholds, it is assumed that when the weight factor assignment is less than or equal to 10% for any of the access networks, the access network will be considered to be underperforming / congested / link unreliable, etc. For example, on the one hand, during time periods t5, t6 and t9, the non-3GPP access network performs poorly, and on the other hand, during time period t7, the 3GPP access network performs poorly. When an access network such as Figure 2 When behaving as depicted, it may happen that the operator preference and the average weight factor assignments deviate from each other or are not close to each other. In addition, as mentioned previously, the weight factor assignments based on instantaneous link conditions may lead to a ping-pong effect. Figure 2 This effect is depicted in Figure 1 from t11 to t14.

[0107] In another example, during the assignment of weight factors onto 3GPP access networks, operator preferences are considered as a hard cap. This case is similar to the autonomous steered mode, but this is an example of a specific case with an upper limit when the WTRU and UPF perform their own weight factor assignments based on network / link conditions. Therefore, the WTRU and UPF can assign factors flexibly in situations where there are constraints on specific ratios on 3GPP access that the WTRU and UPE cannot exceed. The intent of this specific case is that even though the autonomous mode takes such an upper limit into account, it does not mean that the long-term (which may be configurable by the network) average of the weight factors will converge to the operator's preference. Figure 3 This example case is shown, where considering Figure 2 The assumptions of the previous examples shown. Figure 3 In FIG. 1 , lines 300A and 300B represent operator preferences (Op.pref.) for 3GPP and non-3GPP access technologies, respectively, and lines 302A and 302B represent the instantaneous average values ​​(Avg.) of weight factor assignments on 3GPP and non-3GPP networks, respectively. Figure 2 In , the time periods t1 to t15 are functions of time and are defined by fixed time intervals. Figure 3 , regions 304, 306, and 308 represent the additional load that may be placed on the non-3GPP access network due to weight factor limitations on the 3GPP access network.

[0108] Assumptions Figure 2 and Figure 3 The access network performance of the two examples shown is the same, but Figure 3 The weight factor assignment in has operator-configured constraints on the 3GPP access network. For this case, although the 3GPP access network can deliver more than the given constraint, the WTRU / UPF cannot exceed the constraint. Therefore, a larger deviation between the operator-preferred weight factor and the average distribution can be expected. In addition, it is assumed that when the non-3GPP access network performs poorly during time periods t5, t6 and t9, a higher weight factor will be assigned to the non-3GPP access network due to the configuration constraints on the weight factor of the 3GPP access network.

[0109] In Release 17eNA, several user plane optimization oriented analyses are defined as previously described herein. Thus, the NWDAF provides statistics / predictions and their spatial validity, validity period, and prediction confidence. However, the currently defined user plane optimization oriented analyses focus on the following specific cases / outputs: If the steering mode is load balanced, then no cases / outputs are defined for the statistics / predictions of the ATSSS steering mode and weight factors, and the WTRU and UPF may make their own decisions on the UL and DL traffic weights, respectively.

[0110] Solutions regarding “per access network performance” only provide network performance levels for access types from 1 to 10, where higher values ​​indicate better performance. Therefore, such statistics / predictions will not be sufficient for access traffic weight factor assignment. Therefore, an enhanced analysis method is needed to incorporate some intelligence in order to predict the steering mode and weight factors based not only on the access network performance indicated in the current solution [4] which takes into account the average usage of the assigned resources (CPU, memory, disk), the average number of WTRUs observed in a subset of regions, the average successful setup rate of PDU sessions, but also based on the access link performance, the internal state of the WTRU and the WTRU's own preferences. This enhanced analysis can then be used proactively by the WTRU, UPF and / or SMF to improve the overall access network performance and take into account long-term network operator preferences.

[0111] Based on the above, intelligent traffic steering functionality can be implemented within the WTRU to handle / allocate WTRU uplink traffic on 3GPP and non-3GPP access links, particularly with almost no signaling delay. The WTRU can also participate in managing DL traffic steering at the UPF. The 3GPP system (3GS) currently does not have any defined mechanism / component / logic function to perform such intelligent traffic steering functionality at the WTRU, even though the WTRU is the best positioned entity in the 3GS that can access all the required data / information to make such intelligent traffic steering decisions. That is, the new intelligent components at the WTRU should also interact directly with the 5GCNF (e.g., SMF, NWDAF, and UPF), in particular to exchange other information such as statistics and analysis, ATSSS rule assignments and weight factors, ML-related updates (neural network (NN) model building and weights), etc. This interaction is beneficial when the WTRU helps the UPF manage DL traffic on MA-PDU sessions and resource optimization of the 3GPP network. For example, when the WTRU decides to move all traffic away from 3GPP access, it is not efficient to retain the 3GPP access resources when the WTRU does not intend to use the 3GPP access resources in the foreseeable future.

[0112] As previously described, 3GPP supports ATSSS. ATSSS has been studied in Release 16 and Release 17 and is currently being studied in Release 18. With respect to updates during Release 17, an autonomous steering mode is proposed to enable the WTRU and UPF to determine weight factors based on a combination of current (real-time) link status and thresholds for RTT, UL / DL maximum packet loss rate, UL / DI maximum jitter, and WTRU internal status (e.g., battery power). As mentioned, for the described autonomous steering mode, no mechanism is defined for enabling the WTRU and UPF to improve the overall network performance of the local area of ​​interest or to make proactive / predictive decisions. For specific types of traffic approved / provided by the network for the WTRU and UPF to decide autonomously, the WTRU and UPF determine the weight factors based on the comparison of the measurements performed and the thresholds provided by the network. Therefore, the decision on the weight factors is reactive. Additionally, when the WTRU and UPF autonomously decide how to direct traffic to 3GPP and non-3GPP access networks, the goal becomes the optimization of instantaneous link performance focusing only on path performance measurements. This autonomous decision introduced in Release 17 does not provide any kind of operator influence and is therefore only considered for specific types of traffic that have been approved in advance by the operator.

[0113] The issues addressed may include: (i) For any type of data traffic including AI / ML operated traffic, how can PCC / ATSSS / N4 rules be enhanced to support WTRU and UPF to flexibly allocate traffic on 3GPP and non-3GPP access networks without violating mobile network operator policies / SLAs?; (ii) How can WTRU and UPF use AI / ML based traffic steering methods individually or collaboratively?; and (iii) How will the 3GPP network function and WTRU interact to enforce traffic steering rules / policies and / or dynamically manage 3GPP network resources when ATSSS rules and / or weighting factors change?

[0114] Overview

[0115] Disclosed herein are processes, methods, architectures, devices, systems, apparatuses, and computer program products that relate to and / or incorporate analysis-assisted and / or analysis-based user plane optimization. For example, such methods, devices, systems, etc. can address the analysis-based user plane optimization involved (methods and techniques configured, implemented, and / or performed therein), including, for example, analysis-based operations for access traffic steering, splitting, and switching (ATSSS).

[0116] For simplicity of exposition, the following disclosure is made in part from the perspective of a network element and / or a network function. One of ordinary skill in the art will recognize that much of such disclosure may also apply to a WTRU, another network element (e.g., a base station or other RAN element), and / or another network function, and therefore, such modifications and variations are intended to fall within the scope of the present disclosure and the appended claims.

[0117] In the process, method, architecture, device, system, apparatus and computer program product, the first method can be implemented in a first network entity and can include any of the following items: receiving first information from a second network entity, the first information indicating (i) analysis-based operations for access traffic steering, splitting and switching, (ii) a first weight for each of a plurality of access networks, and (iii) at least one first weighting factor for each of the plurality of access networks; transmitting second information to a third network entity, the second information indicating analysis-based operations for access traffic steering, splitting and switching, the second information including the first weight and the first weighting factor; transmitting third information to a fourth network entity, the third information indicating one or more load metrics, wherein the one or more load metrics are based on the first weight and a first weighting factor; receiving fourth information from a fourth network entity, the fourth information indicating an analysis for controlling traffic steering of a multiple access protocol data unit session, the fourth information comprising one or more of the following: (i) a second weight for at least one access network among the multiple access networks and (ii) a second weighting factor for at least one access network among the multiple access networks, wherein the analysis is based on: (a) third information transmitted to the fourth network entity; and (b) fifth information from the third network entity, the fifth information indicating a criterion for dividing downlink traffic among the multiple access networks; and sending sixth information to the third network entity and at least one of the WTRUs, the sixth information indicating one or more of the following: (i) the second weight and (ii) the second weighting factor.

[0118] In various embodiments, the method may include transmitting seventh information to the WTRU, the seventh information indicating analysis-based operations for access traffic steering, splitting, and switching, wherein the analysis is (e.g., further) based on eighth information from the WTRU, the eighth information indicating one or more criteria for dividing uplink traffic between multiple access networks. In various embodiments, the method may include receiving the eighth information from the WTRU.

[0119] In the process, method, architecture, device, system, apparatus and computer program product, a first network entity may include a circuit system including a transmitter, a receiver, a processor and a memory, and the circuit system may be configured to: receive first information from a second network entity, the first information indicating (i) analysis-based operations for access traffic steering, splitting and switching, (ii) a first weight for each of a plurality of access networks, and (iii) at least one first weighting factor for each of the plurality of access networks; transmit second information to a third network entity, the second information indicating analysis-based operations for access traffic steering, splitting and switching, the second information including the first weight and the first weighting factor; transmit third information to a fourth network entity, the third information indicating one or more load metrics, one or more of which are The load measurement is based on a first weight and a first weighting factor; receiving fourth information from a fourth network entity, the fourth information indicating an analysis for controlling traffic steering of a multiple access protocol data unit session, the fourth information comprising one or more of the following: (i) a second weight of at least one access network among the multiple access networks and (ii) a second weighting factor of at least one access network among the multiple access networks, wherein the analysis is based on: (a) third information transmitted to the fourth network entity; and (b) fifth information from the third network entity, the fifth information indicating a criterion for dividing downlink traffic between the multiple access networks; and / or sending sixth information to the third network entity and at least one of the WTRUs, the sixth information indicating one or more of the following: (i) the second weight and (ii) the second weighting factor.

[0120] In various embodiments, the circuit system may be configured to transmit seventh information to the WTRU, the seventh information indicating analysis-based operations for access traffic steering, splitting, and switching, wherein the analysis is further based on eighth information from the WTRU, the eighth information indicating one or more criteria for dividing uplink traffic between multiple access networks. In various embodiments, the circuit system may be configured to receive the eighth information from the WTRU.

[0121] In various embodiments of the first method and the first network entity, the first network entity may be and / or may include an SMF. In various embodiments of the method and the first network entity, the second network entity may be and / or may include a PCF. In various embodiments of the method and the first network entity, the third network entity may be and / or may include a UPF. In various embodiments of the method and the first network entity, the fourth network entity may be and / or may include an NWDAF.

[0122] In the process, method, architecture, device, system, apparatus and computer program product, the second method can be implemented in a first network entity and can include any of the following items: receiving first information from a second network entity and at least one of the WTRUs, the first information indicating one or more load metrics, wherein the one or more load metrics are based on: (i) a first weight for each of a plurality of access networks and (ii) at least one first weighting factor for each of the plurality of access networks; receiving second information from the second network entity, the second information indicating a criterion for dividing downlink traffic between the plurality of access networks; determining an analysis for controlling traffic steering of a multiple access protocol data unit session, wherein the analysis is determined based on the one or more load metrics and the criterion for dividing downlink traffic between the plurality of access networks, and wherein the analysis includes one or more of the following items: (i) a second weight for at least one of the plurality of access networks and (ii) a second weighting factor for at least one of the plurality of access networks; and transmitting third information to a third network entity, the third information indicating the analysis.

[0123] In the process, method, architecture, device, system, apparatus and computer program product, a first network entity may include a circuit system including a transmitter, a receiver, a processor and a memory, and the circuit system may be configured to: receive first information from a second network entity and at least one of the WTRU, the first information indicating one or more load metrics, wherein the one or more load metrics are based on: (i) a first weight of each of a plurality of access networks and (ii) at least one first weighting factor of each of the plurality of access networks; receive second information from the second network entity, the second information indicating a criterion for dividing downlink traffic between the plurality of access networks; determine an analysis for controlling traffic steering of a multiple access protocol data unit session, wherein the analysis is determined based on the one or more load metrics and the criterion for dividing downlink traffic between the plurality of access networks, and wherein the analysis includes one or more of the following items: (i) a second weight of at least one of the plurality of access networks and (ii) a second weighting factor of at least one of the plurality of access networks; and / or transmit third information to a third network entity, the third information indicating the analysis.

[0124] In various embodiments of the second method and the (second) first network entity, at least some of the first information may be received from the WTRU via the second network entity. In various embodiments of the second method and the (second) first network entity, the first information may be received via the second network entity. In various embodiments of the second method and the (second) first network entity, the second information may be received via the second network entity.

[0125] In various embodiments of the second method and the (second) first network entity, the first network entity may be and / or may include a NWDAF. In various embodiments of the second method and the (second) first network entity, the second network entity may be and / or may include a UPF. In various embodiments of the second method and the (second) first network entity, the third network entity may be and / or may include an SMF. In various embodiments of the first method and the second method and the first network entity, the analysis may be based on a prediction of the time when the guide will be deployed. In various embodiments of the first method and the second method and the first network entity, the analysis may be either predictive or proactive.

[0126] In various embodiments of the first method and the second method and the first network entity, the analysis may be based on (e.g., also based on) ninth information from the fifth network entity, the ninth information indicating a (e.g., expected) behavior of the WTRU. In various embodiments of the first method and the second method and the first network entity, the fifth network entity may be and / or may include an AMF.

[0127] In various embodiments of the first method and the (first) first network entity, the analysis-based operation may be and / or may include an analysis-based load balancing operation for ATSSS.

[0128] In various embodiments of the first method and the second method and the first network entity, any of the second weight and the second weighting factor may be based on any of one or more performance measurements, one or more operator preferences, and one or more preferences of the WTRU. In various embodiments of the first method and the second method and the first network entity, the performance measurement may be received from the OAM entity. In various embodiments of the first method and the second method and the first network entity, the operator preference may be received from the second network entity. In various embodiments of the second method and the (second) first network entity, one or more operator preferences are received from a third network entity. In various embodiments of the first method and the second method and the first network entity, the second weight may be and / or may include a revision of one of the first weights. In various embodiments of the first method and the second method and the first network entity, the second weighting factor may be and / or may include a revision of one of the first weighting factors.

[0129] In various embodiments, a method may be implemented in a WTRU and may include any of the following: receiving one or more load balancing rules from a network, wherein the one or more load balancing rules may be based on one or more performance measurements, one or more operator preferences regarding load assignment on a first network and a second network, and one or more WTRU preferences regarding load assignment on the first network and the second network; and directing, by the WTRU, traffic to the first network and the second network based at least in part on the load balancing rules.

[0130] In various embodiments, the method may include any of the following: receiving, by the WTRU, an indication of an analysis-assisted (analysis-based) load balancing operation from the network; and sending, by the WTRU in response to the indication, to the network information relating to one or more WTRU preferences regarding load assignment on the first network and the second network.

[0131] In various embodiments, the load balancing rules may include one or more load balancing weight factors. In various embodiments, the load balancing weight factors may be based on performance measurements, operator preferences, and / or WTRU preferences.

[0132] In various embodiments, the method may include the WTRU receiving a load balancing rule from a network entity (element) of the network. In various embodiments, the network entity may be a network data analysis function (NWDAF) of the network. In various embodiments, the NWDAF may provide the load balancing rule to the WTRU and the user plane function (UPF). In various embodiments, both the WTRU and the UPF may receive the load balancing rule. In various embodiments, the NWDAF may provide the load balancing rule via a session management function (SMF).

[0133] In various embodiments, load balancing rules may be predictive and / or proactive.

[0134] In various embodiments, the load balancing rules may include multiple access traffic management (MATM) rules. In various embodiments, the MATM rules may and / or may be used to configure the WTRU to adjust (e.g., dynamically adjust) one or more load balancing weight factors in the load balancing traffic steering mode of operation. In various embodiments, the MATM rules may and / or may be used to configure the WTRU (e.g., further configure) to switch (e.g., dynamically switch) between traffic steering modes of operation.

[0135] In various embodiments, the method may include implementing, by the WTRU, the MATM rules as a machine learning (ML) component having a neural network (NN) model.

[0136] In various embodiments, the method may include training (e.g., dynamically training) and / or updating (e.g., dynamically updating) the NN model. In various embodiments, the method may include training (e.g., dynamically training) and / or updating (e.g., dynamically updating) the NN model based on one or more conditions of the WTRU and / or one or more conditions associated with the WTRU. In various embodiments, the conditions may include any of traffic patterns, mobility, available capacity, etc.

[0137] In various embodiments, the first network may be and / or may include a first access network. In various embodiments, the second network may be and / or may include a second access network. In various embodiments, the first network may be and / or may include a 3GPP network. In various embodiments, the second network may be and / or may include a non-3GPP network. In various embodiments, the 3GPP network may be and / or may include a 3GPP access network. In various embodiments, the non-3GPP network may be and / or may include a non-3GPP access network.

[0138] In various embodiments, a device that may include any one of a processor and a memory is configured to perform a method as in at least one of the aforementioned embodiments.

[0139] In various embodiments, the device may be, configured as, and / or configured with an element of a WTRU. In various embodiments, the device may be, configured as, and / or configured with an element of a network entity. In various embodiments, the device may be, configured as, and / or configured with an element of a base station or other network element (e.g., one or more RAN or CN elements).

[0140] Representative access traffic steering based on network analysis

[0141] In one embodiment, in case of load balancing steering, new analytical / predictive information is considered when deciding steering mode and weight factor assignment. Such analytical / predictive information may be provided by NWDAF.

[0142] As described above, current analytics-oriented user plane optimization solutions do not provide enhanced analytics to incorporate any intelligence in predicting operator preferences and network / link conditions for steering patterns and weight factors and load assignments to multiple access networks (e.g., one or more 3GPP access networks and one or more non-3GPP access networks). Therefore, in one embodiment, a new analytics ID named "Multiple Access Traffic Steering Control" is considered to be provided by the NWDAF. The terms "multiple access networks", "3GPP and non-3GPP access networks", and "first access network and second access network" may be used interchangeably and are interchangeable in the following disclosure.

[0143] Figure 4 The existing ATSSS process and the proposed analysis-assisted solution are depicted, along with the signaling considered. The terms "analysis-assisted" and "analysis-based" may be used interchangeably and are interchangeable in the following disclosure. Figure 4 In the NWDAF, "AT3SF" represents the ATSSS function of the relevant NF, "PMF" represents the performance measurement function, and "MATSC" in the NWDAF represents the multi-access traffic steering control analysis ID. Figure 4 The interactions between the WTRU 400, NWDAF 402, UPF 404, PCF 406 and SMF 408 are depicted.

[0144] In order for NWDAF to perform analysis and make predictions, NWDAF needs to collect telemetry data from various network nodes (including UPF, WTRU, PCF and SMF). In addition to this, NWDAF can also leverage existing analytics such as network performance analysis, WLAN performance analysis, redundant transmission experience-related analysis, WTRU-related analysis, and other analyses mentioned in Table 7.1.-2 of the 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 5G System (5GS) Architecture Enhancement (Release 17) for Supporting Network Data Analysis Services, 3GPP TS23.288v.17.4.0 (2022-03) for Multi-Access Traffic Steering Control Analysis (hereinafter referred to as "3GPP TS23.288v.17.4.0"). In addition, NWDAF can also leverage core network-assisted RAN parameters such as WTRU behavior statistics, expected WTRU behavior, and other available WTRU-related information for optimizing WTRU RRC and CM state transitions.

[0145] In order to indicate that the steering mode to be used will be the steering mode for which the NWDAF generates weight factors, in one embodiment, an indicator may be added to the Multiple Access Rules (MAR) which is part of the N4 rules provided by the SMF to the UPF. This indication may be named "Analysis Assisted Load Balancing Operation" and may be part of the existing Steering Mode Indicator attribute in the MAR. In another embodiment, the same indicator named "Analysis Assisted Load Balancing Operation" may also be included in the ATSSS rules sent to the WTRU (via the AMF). This indicator enables the WTRU to provide some additional information such as battery status, preferred access type, etc. to be considered as part of the NWDAF analysis generation / prediction process.

[0146] Since the NWDAF analysis and / or prediction will include operator preferences, the NWDAF may have information about operator preferences for load assignments on 3GPP and non-3GPP access networks. In one embodiment, the operator preferences may be provided directly by the PCF 406, as shown at 410. In another embodiment, when the SMF 408 receives the ATSSS policy from the PCF 406 and derives or otherwise determines the ATSSS and N4 rules accordingly, the operator preferences may be derived by the SMF 408 and provided to the NWDAF 402, as shown at 412. The terms "derive" and "determine" may be used interchangeably and are interchangeable in the following disclosure.

[0147] NWDAF 402 may utilize the existing related information provided in Table 6.2.4-1

[10] to correlate UPF, OAM, SMF, AMF and PCF data.

[0148] The NWDAF 402 may utilize path performance measurements made by the PMF. In one embodiment, the PMF may be located external to the UPF 404, and the PMF may provide path performance measurements directly to the NWDAF 402. In another embodiment, the PMF may be co-located with the UPF 404, and may provide path performance measurements along with UPF reports / telemetry data including usage / session reports, data rates, packet delays, packet transmissions, packet retransmissions, data volumes in UL and DL directions, etc., as shown at 414.

[0149] In order to have the UPF 404 provide a session report to be used by the NWDAF 402 to predict weight assignment when the steering mode is selected as load balancing and the steering mode indicator is selected as "analysis assisted load balancing operation" in the MAR, the UPF 404 may be notified by using an information element in the session reporting rule (SRR) named "Access Load Control Information" to indicate to the UPF 404 to report when the weight factor of the access type becomes higher or lower than the operator preferred weight. When the UPF 404 sends a session report to notify the detected event of the PDU session related to the SRR: (i) not only the SMF 408 but also the NWDAF 402 is notified, as shown at 414; or (ii) the SMF 408 will provide the report to the NWDAF 402 with an attribute named "Access Load Report" indicating the change of the 3GPP or non-3GPP access weight factor compared to the operator preferred weight, as shown at 416. The "Access Load Report" may be used by the NWDAF 402 to improve or trigger the analysis / prediction.

[0150] As mentioned previously in this document, Release 17 ATSSS considers WTRU assisted indicators so that the WTRU indicates its preference to the UPF on how to distribute UL traffic when the steering mode is selected as load balancing. When each WTRU performs some actions to indicate its preferences, these preferences will ultimately be selfish decisions of the WTRU and may not help improve the overall network performance (including energy efficiency, throughput, etc., network-wide or based on areas of interest). In one embodiment, the proposed "analysis-assisted load balancing operation" can utilize WTRU assisted indicators to take into account not only network conditions and operator preferences, but also WTRU preferences that may be based on the internal state of the WTRU. How the WTRU performs actions (and what actions) to decide its preferences for UL traffic and DL traffic will be discussed in detail later in this document. After the WTRU 400 determines its preference, on the one hand, the WTRU 400 may use existing procedures such as: (i) WTRU assisted operation defined in [11, Section 5.32.5.5] sending a PMF-UAD (WTRU Assistance Data) message to the UPF, as shown at 424; or (ii) using a WTRU application to provide WTRU data to the NWDAF 402 via the AF, as explained in [10, Section 6.2.8]. Alternatively, the WTRU 400 may provide its preference to the 5GC NF (e.g., SMF / PCF / UPF) via the control plane through the SMF / AMF. This embodiment will be discussed in detail later herein.

[0151] When NWDAF 402 performs prediction / analysis on a multi-access traffic steering analysis ID, a set of options for utilizing the analysis output may be described as follows:

[0152] Option A: The SMF 408 subscribes to the "Multiple Access Traffic Steering Control" analysis available in the NWDAF 402. The NWDAF 402 may provide the load balancing weight factor to the SMF 408, as shown at 418, and the SMF 408 may then inform the UPF 404 and the WTRU 400 of the analysis-assisted load balancing weights by using the modified N4 and ATSSS rules, respectively. The NWDAF 402 may also provide information about the updated rules to the PCF 406, as shown at 420.

[0153] Option B: Since the network can enable the WTRU 400 and UPF 404 to flexibly allocate UL and DL traffic when the autonomous steering mode is selected, the UPF 404 can subscribe to the NWDAF 402 to use the analysis-assisted load balancing weights. Since the proposed "multiple access traffic control" analysis can take into account operator preferences, the operator can enable the NWDAF 402 to apply the analysis-assisted load balancing weights not only for the traffic types allowed by the operator but also for any type of traffic. In one embodiment, for such operation, the operator can indicate the time window (e.g., for a specific event) and / or location (e.g., for a specific venue or a dedicated network environment) as one or more criteria for the NWDAF 402 to control the assignment of load balancing weights. The NWDAF 402 can then provide the load balancing weight factors to the UPF 404 (as shown at 422) and to the WTRU 400 via the UPF / SMF 404 / 408. The NWDAF 402 can also provide information about the updated rules to the PCF, as shown at 420.

[0154] Option C: An external AF (which may be a machine learning based AF) can also leverage the "Multiple Access Traffic Control" analysis by using the existing procedures defined in

[10] and the proposed indicators for analysis-assisted load balancing operations. After the AF makes a decision on the load balancing weight factor, the AF can use: (i) a method similar to Option A, where the AF notifies the SMF 408 of the assigned weight factor and the SMF 408 distributes the N4 and ATSSS rules to the UPF 404 and WTRU 400, respectively; or (ii) a method similar to Option B, where the AF directly notifies the UPF 404.

[0155] To illustrate possible outputs from an analytics-assisted load balancing operation, Figure 5 An example case where NWDAF determines the load balancing weight factor is shown.

[0156] exist Figure 5In FIG. 5 , lines 500A and 500B represent the operator preferences (Op.pref.) for 3GPP and non-3GPP access technologies, respectively, and lines 502A and 502B represent the instantaneous average values ​​(Avg.) of the weight factor assignments on 3GPP and non-3GPP networks, respectively. Figure 2 and Figure 3 In , the time periods t1 to t15 are functions of time and are defined by fixed time intervals. Figure 5 , areas 504 to 518 represent the additional load that may be placed on the non-3GPP access network to match the operator's preferences.

[0157] Similar to Figure 2 and Figure 3 :(i) Figure 5 The operator preferences in are indicated as 80% on 3GPP and 20% on non-3GPP access networks, as shown at 500A and 500B, respectively; and (ii) when the weight factor assignment of any of the access networks is less than or equal to 10%, the access network will be considered to be underperforming / congested / link unreliable. Since the weight factor assignment is based on the multi-access traffic steering control analysis / prediction taking into account the operator preferences as well as the network conditions, deviations from the operator preferences will only occur for a short period of time. In the long run, the analysis-assisted load balancing weights converge with the operator's preferences. In addition, the analysis-assisted weight factor assignment does not lead to a ping-pong effect, because such conditions can be foreseen and actively prevented by the embodiments disclosed herein.

[0158] Figure 6 is a message flow diagram showing an interaction example of NFs according to an embodiment. Figure 6 The exemplary illustration of the message flow shown may involve: SMF subscribing to NWDAF for multi-access traffic steering control analysis ID; NWDAF collecting data; NWDAF providing analysis / prediction to SMF; and NWDAF providing updates to PCF. The message flow is defined as Option A for utilizing multi-access traffic steering control analysis / prediction. SMF may distribute analysis-assisted load balancing weight factors to WTRU and UPF.

[0159] refer to Figure 6 , PCF may define ATSSS policy. PCF may define ATSSS policy and / or TSSS policy may be based on operator preference (WTRU policy subscription from UDM) (600-1).

[0160] The PCF may send the ATSSS policy to the SMF and / or to indicate that analysis-assisted load balancing operations may be applied (600-2).

[0161] The SMF may derive N4 rules based on the ATSSS policy (from the PCF) and / or may send the N4 rules to the UPF (600-3a). The N4 rules may indicate analysis-assisted load balancing operations (e.g., as part of a MAR) and / or may indicate access load control information (e.g., as part of an SRR). The SMF may derive ATSSS rules based on the ATSSS policy (from the PCF) and / or may send the ATSSS rules to the WTRU. The ATSSS rules may indicate analysis-assisted load balancing operations (600-3b).

[0162] The SMF may subscribe to the notification about the multi-access traffic steering control analysis ID from the NWDAF (600-4).

[0163] The NWDAF may collect historical data about access network performance and WTRU from the OAM system (600-5). The historical data may include WTRU measurements (e.g., RSRP, RSRQ, SNR, etc.), MDT measurements (e.g., WTRU speed, WTRU orientation, etc.), and / or RAN status (e.g., radio resource utilization, performance per cell ID, etc.). The NWDAF may collect information about operator preferences from the PCF (600-6a) and / or SMF (600-6b). The information about operator preferences may be used for weight factor assignment on a first (e.g., 3GPP) access network and a second (e.g., non-3GPP) access network.

[0164] The NWDAF may collect WTRU related data (600-7a) (e.g., WLAN usage experience, WTRU application status, WTRU status (including battery), etc.). The NWDAF may collect WTRU related data from the WTRU (e.g., from WTRU assistance data via the UPF, or from WTRU applications via the AF). The NWDAF may collect path performance measurement data from the UPF (600-7b). This data may include access load reports (e.g., as a session report or as part of a session report (optional, see 600-8).

[0165] The NWDAF may collect session-related data from the SMF. The data may include an access load report (eg, as a session report or as part of a session report) (600-8).

[0166] NWDAF may collect mobility management and / or core network assistance related data from AMF. The core network assistance data may include one or more expected WTRU behaviors.

[0167] The NWDAF may, for example, derive multiple access traffic steering control analysis and / or prediction based on and / or utilizing various collected information (600-8). The NWDAF may utilize other analyses to improve predictions for multiple access traffic steering control. The other analyses may be and / or may include existing WTRU-related analyses and other analyses mentioned in Table 7.1.-2 of 3GPP TS 23.288 v.17.4.0 reproduced below.

[0168]

[0169]

[0170]

[0171] Table 7.1-2: Statistics provided by NWDAF

[0172] 3GPP TS 23.288 v.17.4.0 is incorporated herein by reference in its entirety.

[0173] The NWDAF may provide input of the multi-access traffic steering control analysis and / or prediction to the SMF (SM-AT3SF to take action) and / or PCF (notification of weight factor assignment) (600-11).

[0174] The SMF may, for example, derive N4 rules and ASSSS rules based on and / or using multiple access traffic steering control analysis and / or prediction. The SMF may provide (e.g., transmit) N4 rules to the UPF, which may include updated analysis-assisted weighting factors for DL ​​traffic (600-12a). The SMF may provide (e.g., transmit) ATSSS rules to the WTRU, which may include updated analysis-assisted weighting factors for UL traffic (600-12b).

[0175] The SMF (or other network entity) may provide (e.g., transmit) multiple sets of ASSSS rules and / or ATSSS rule selection criteria to the WTRU. The ATSSS rule selection criteria may be used (e.g., by the WTRU) to determine (e.g., at any given time) which of the multiple sets of ASSSS rules to apply. The SMF may, for example, derive the ATSSS rule selection criteria based on and / or using multiple access traffic steering control analysis and / or prediction. The ATSSS rule selection criteria may be based on the location of the WTRU (e.g., a determined location), measurements of the WTRU, information received from the UPF (e.g., via PMF signaling), etc.

[0176] The SMF (or other network entity) may provide (e.g., transmit) multiple sets of N4 rules and / or N4 rule selection criteria to the UPF. The N4 rule selection criteria may be used (e.g., by the UPF) to determine (e.g., at any given time) which of the multiple sets of N4 rules to apply. The SMF may, for example, derive the N4 rule selection criteria based on and / or using multi-access traffic steering control analysis and / or prediction. The N4 rule selection criteria may be based on measurements of the UPF and / or measurements associated with the UPF, information received from the WTRU (e.g., via PMF signaling), etc.

[0177] Update of representative intelligent traffic steering rules

[0178] The above embodiments may help the UPF and WTRU to dynamically adjust their traffic steering modes for both downlink and uplink traffic based on the analysis and / or predictions provided by the NWDAF. The above disclosure is excellent for traffic steering at the UPF (i.e., for downlink traffic of the WTRU) as long as the NWDAF / SMF can notify (e.g., directly notify) the UPF of new traffic steering rules and / or weights and / or weighting factors (in the case of load balancing mode) via the 5G control plane, for example with minimal signaling delay. This capability may not be the case for uplink traffic of the WTRU, because the delivery of traffic steering decisions from the 5GC to the WTRU may incur some delays due to, for example, the steering decision (i.e., the transmission of the bearer and / or indication steering decision) that may be passed through one or more entities (such as the SMF, AMF, and NG-RAN). For delay-sensitive applications that can utilize separate first and second (e.g., 3GPP and non-3GPP) access links via ATSSS and MA-PDU sessions, such delays may be intolerable.

[0179] Another potential problem may arise with respect to the delivery of ATSSS rules from the 5GC to the WTRU. This problem is primarily related to situations where the connection between the WTRU and the RAN (e.g., a base station such as a gNB) is poor and / or unstable. In this case, the cellular link between the WTRU and the RAN may be unavailable. One consequence of the unavailability of the cellular link between the WTRU and the RAN is that the 5GC is unable to deliver any signaling (e.g., control messages and / or information) to the WTRU. Even if the connection between the WTRU and the RAN (e.g., cellular link and / or other connection) is available but poor, control messages and / or information may still be delivered to the WTRU after a long delay, for example, due to a backlog at the RLC buffer and / or multiple retransmissions at the MAC layer. Additionally, the delivery of control messages and / or information may be delayed when the RLC buffer at the base station (e.g., gNB) is congested due to downstream traffic from the WTRU.

[0180] The intelligent traffic steering function within the WTRU may handle and / or distribute the uplink traffic of the WTRU on the first and second (e.g., 3GPP and non-3GPP) access links with limited, minimized or no delay due to signaling. The WTRU may be the best positioned entity in the 3GPP system (3GS) because it may access and / or have access to the required data / information (e.g., all required data / information) to make intelligent traffic steering decisions in a timely manner (e.g., immediately). The WTRU may have access to various locally available information, such as any of the following: available capacity of the first and second (e.g., 3GPP and non-3GPP) access links, RTT between the WTRU and the RAN, RTT between the WTRU and the N3IWF (e.g., WiFi-AP), RLC buffer size of the first (e.g., cellular (3GPP)) access, number of backoffs in case of the second (e.g., Wi-Fi (non-3GPP)) access, number of retransmissions at the MAC layer of both the first (e.g., cellular) access and the second (e.g., WiFi) access, RSRP and RSRQ of some or all access types. The WTRU may have behavior and / or trend oriented information that may be extracted by applications in the WTRU and may help the WTRU perform intelligent oriented decisions.

[0181] A new machine learning (ML) based component may be integrated into the WTRU (e.g., into the WTRU-AT3SF) and may be referred to as Multi-Access Traffic Management (“MATM”). The WTRU-AT3SF may operate at the application layer and may interact with other ASSSS related components (such as the PMF) via HTTP / 2. For interaction with ATSSS-HL (MPTCP), the MATM may use an inter-process communication (IPC) interface such as the Linux Netlink Socket

[12] . The choice of the IPC interface may depend on the WTRU's operating system. During the MA-PDU session establishment process, the MATM may manage the UL and / or DL ​​traffic steering functions on all available access links (involved in the MA-PDU conversation) in conjunction with the PCF / SMF's indication of activating the ASSSS load balancing traffic steering mode and the ML-based WTRU-assisted load balancing mode.

[0182] When the ML-based steering mode indicator is provided, the MATM can be activated with other ASSSS steering modes. In this way, the MATM can switch (e.g., dynamically switch) the ASSSS steering mode of the application, for example, based on the predicted network conditions of the access link. In Release 17, the autonomous steering mode indicator is activated only when the steering mode is load balancing. The MATM can also be activated with the proposed steering mode indicator, which was previously referred to as analysis-assisted load balancing operation in this article.

[0183] The MATM may utilize ML techniques (e.g., reinforcement learning (RL), A3C

[13] , DDPG

[14] , etc.) that may dynamically train and / or update its neural network model (NN). Thus, each WTRU may make smarter decisions over time by continuously updating the initial training model provided to the MATM based on the WTRU's conditions (e.g., traffic patterns, mobility, available capacity, etc.). NWDAF (MTLF) may be used within the 5GC to periodically provide NN updates to the MATM via the AMF over the N1 interface (i.e., via NAS messages associated with ASSS signaling).

[0184] MATM can interact directly with 5GC via the control plane or the user plane (via AF). In the case of the control plane, MATM can use SM signaling to interact directly with SMF. SMF can also relay MATM messages to any other 5GCNF via API calls. If necessary (for example, if the MATM message is designated to the NWDAF instance), the SMF can use the additional information in the NAS message to forward the MATM message to its destination. If the WTRU intends to subscribe to NWDAF (MTLF) for event notifications, the SMF can save the mapping between the expected analysis Id and the PDU session Id.

[0185] Similar to NWDAF, in the case of load-balanced traffic steering mode, the MATM can predictively and proactively decide the traffic steering mode and / or the weight coefficient / factor of traffic steering based on the current network conditions of all available access links. It should be noted that the MATM can run multiple instances of the MATM to produce the desired predictions depending on how the ML algorithm of the MATM is formulated. In the case of a multi-instance MATM, the first instance can be used to select the traffic steering mode, and the second instance can be used to select the weight coefficient during the load-balancing mode.

[0186] For example, the MATM may completely move the WTRU's uplink traffic from the cellular link to the WiFi link when it predicts that the cellular connection will deteriorate soon (eg, within the next 100 ms).

[0187] Representative interactions between the MATM and other entities within the WTRU and 5GC

[0188] Figure 7 is a signaling diagram illustrating the interaction between a multiple access traffic manager (MATM) and other components / modules of a WTRU according to an embodiment. Figure 7As shown, the MATM can interact with the 5GC network functions, initially with the AMF / SMF via NAS signaling, and from the AMF / SMF to its destination NF (e.g., NWDAF) via API calls (or exactly via SBI). Figure 7 Examples are shown that highlight the interaction between the MATM and other WTRU components (eg, data providers such as PMF, radio protocol stack, etc.).

[0189] refer to Figure 7 , the MATM sends a subscription request message to a set of data providers (e.g., via a service operation similar to EventExposure_Subscribe commonly used in some 5GC NFs) to collect the required data (e.g., WTRU logs, predictions, measurements, and statistics) (700-1). Given the large amount of data readily available at the WTRU, the WTRU is the best positioned entity in the 3GPP system for hosting AI / ML components. An example of a data provider at the WTRU may be a PMF that provides RTT, packet error rate, and packet loss rate measurements between the WTRU and the UPF. Other components in the 3GS may also provide data to the MATM, such as third-party applications running at the WTRU or NFs in the 5GC (e.g., NWDAF and / or AF).

[0190] To interact with 5GC, MATM can utilize NAS signaling through AMF / SMF. In the case of interacting with UPF alone, MATA can utilize the PMF connection between WTRU and UPF (through the user plane).

[0191] If the data provider does not support RESTful API, the MATM can utilize other interfaces / APIs, such as sending regular (pull) request messages to collect data from specific components / applications within the WTRU. Once the requested data is available at the WTRU's data provider, it can be delivered to the MATM via an event notification message (e.g., a service operation similar to EventExposure_Notify commonly used in 5GC).

[0192] After the MATM receives its required state inputs, it can produce its desired results (700-1). It is worth emphasizing that in our use case, multiple instances of the MATM can be executed simultaneously. In this case, one instance can produce results about which ASSSS traffic steering mode should be selected for a particular application traffic. A second instance can be used to suggest new weight coefficients in the case of a load balancing traffic steering mode.

[0193] When the MATM decides to switch from active / standby to load balancing, another MATM instance may be instantiated / activated to generate a weight factor corresponding to each available access technology.

[0194] MATM can be instantiated at different granularities. For example, it can be instantiated on a per-application basis, where an instance of MATM can be used to manage per-application traffic or MA-PDU session basis.

[0195] The ML output of the MATM instance recommends an ASSSS traffic steering pattern for each ongoing application flow or MA-PDU session (700-3). Whether the steering pattern is recommended for a single application flow or PDU session depends on the operational granularity of the MATM.

[0196] The selected ATSSS rule assignment is delivered by the WTRU to the PCF via NAS messages (more precisely, via WTRU policy signaling) (700-4). The NAS container may initially be delivered to the AMF; thereafter, the NAS container may be delivered directly to the PCF via an API call. These rules may also be delivered to the UPF. In such a case, the AMF may also forward the NAS PDU received from the WTRU to the SMF via an API call. The NAS PDU may also be delivered from the SMF to the UPF via an N4 report. Alternatively, the ATSSS rules may be delivered to the SMF via SM signaling (step 4a). Then, it may be forwarded from the SMF to both the UPF and the PCF via the N4 interface and API calls, respectively.

[0197] In case of load balancing mode for both UL and DL directions, the MATM may suggest new weight coefficients (700-5). In case of UL, the MATM may push these weights to the MPTCP kernel module at the WTRU so that traffic is split between paths / links according to the supplied weights. In case of DL at the UPF, the MATM may first deliver these weights to the UPF, and then the UPF may decide whether to update these weights within the MPTCP kernel module.

[0198] The frequency of triggering weight updates can be set statistically or dynamically by the WTRU or 5GC (e.g., PCF / SMF) based on network conditions. The decision can be based on network conditions (e.g., whether the 5GC control plane has available bandwidth and / or is highly saturated) and the available computing resources of the WTRU (e.g., GPU / CPU). The latter may be useful in some cases (e.g., when computing resources at the WTRU are limited, the WTRU may not be able to execute its ML module frequently, or they are not intended to be used too quickly for energy saving). Alternatively, the WTRU may execute its ML module at fixed time intervals specified by the network or AF (particularly in the case of federated learning operations).

[0199] The MATM may be responsible for managing downlink traffic at the UPF and may also select a load balancing traffic steering mode (700-6) (with an ML-based WTRU-assisted load balancing indicator). In this case, weight coefficients for balancing downlink traffic may be delivered from the WTRU to the UPF. These weights may be transmitted to the UPF via the user plane (via the PMF) or the control plane (via NAS signaling). In the latter case, NAS messages may be used to transmit these weights to the SMF via NAS-SM signaling (within the ATSSS container IE or new IE). The SMF may then transmit the NAS payload to the UPF along with the additional information provided in the NAS message. If the UPF supports SBI, the last segment of transmission may be performed via an API call. For the former case (as shown in step 6a), the PMF may transmit the information. Transmitting messages via the PMF is completely secure and integrity protected because the PMF traffic is carried within the IPsec tunnel established during the MA-PDU session establishment. In this way, if additional information is included in the message, the UPF may also forward the message to other 5GC NFs.

[0200] When the ATSSS traffic steering mode changes (e.g., in the case of active-standby, 3GPP access becomes standby), the MATM may not see the benefit of retaining all 3GPP resources when not in use. Therefore, the MATM may request to deactivate and remove or otherwise adjust all or some of the user plane resources of the access network (700-7). This request can be performed because the MA-PDU session is formed over two separate N3 tunnels, so the adjustment of 3GPP network resources can be performed independently of non-3GPP network resources.

[0201] The MATM may initiate a PDU session modification procedure and request entities within the 3GPP system (including the RAN and 5GC) to adjust their allocated resources accordingly (700-8). The adjustment may be related to the deactivation of air interface resources (e.g., the SMF may interact with the NG-RAN via the N2 interface (via Namf_Communication N1N2 messaging (WTRU specific) service operation) and request temporary deactivation of the WTRU's air interface resources) and / or to a change in network slices. The MATM may receive all information about the established MA-PDU session (e.g., PDU session Id and new QFI).

[0202] In the case where the MATM wants to have regular updates of new ML models (both model building and / or NN weights), it can subscribe to the NWDAF (MTFL) (700-9). The subscription message can be transmitted to the NWDAF via a NAS message (i.e., over the N1 interface). Additional information can be incorporated into the ATSSS container IE or a new optional IE dedicated for this purpose to allow the SMF to subscribe to the NWDAF on behalf of the WTRU (MATM). In such cases, the SMF can save the mapping between the expected analysis Id and the PDU session Id so that when it receives a notification from the NWDAF (MTLF), it can correctly forward the notification to its consumer device (i.e., in this case, the WTRU).

[0203] After the NWDAF has trained its new ML model, it may notify the SMF via the Nnwdaf_EventExposure_notify service operation. The SMF may then relay the notification to the corresponding WTRU via a NAS message (either within an ATSSS container IE or within a new IE dedicated to NN model delivery) over the N1 interface. The NAS container may include the PDU Session Id, Analysis Id, Application Id, the new ML model, and / or a URI that may be used to retrieve the new ML model via user plane signaling.

[0204] For convenience and simplicity of explanation, the terms "3GPP network", "3GPP access network", "non-3GPP network" and "non-3GPP access network" are used to describe the disclosure herein. In addition to 3GPP networks and non-3GPP networks, the disclosure herein can be applicable to the first network and the second network (e.g., access network).

[0205] Figure 8 800 is a flow chart illustrating an example process 800 for performing analysis-based user plane optimization (e.g., analysis-based operation for ATSSS). The process 800 and the accompanying disclosure herein may be viewed as an example of a process 800 for performing analysis-based user plane optimization (e.g., analysis-based operation for ATSSS). Figures 4 to 6A summary of at least some of the accompanying disclosures, and is considered to cover and / or include various embodiments of the above disclosures, including for example Figures 4 to 6 The accompanying public content. Figures 1A to 1D The process 800 may be performed using the architecture of the communication system 100. Other architectures may also be used to perform the process 800.

[0206] refer to Figure 8 The WTRU may receive one or more load balancing rules from the network, such as one or more load balancing rules based on the analysis (806), and / or may direct traffic to the first network and the second network based at least in part on the load balancing rules (808). In various embodiments, the load balancing rules may be based on any of: one or more performance measurements, one or more operator preferences regarding load assignment on the first network and the second network, and one or more WTRU preferences regarding load assignment on the first network and the second network.

[0207] In various embodiments, the WTRU may receive information from a network indicating an analysis-assisted (and / or analysis-based) load balancing operation (e.g., an indication thereof) (802). In various embodiments, the WTRU may transmit to the network (e.g., in response to the information / indication) information relating to one or more WTRU preferences regarding load assignment on a first network and a second network (804).

[0208] In various embodiments, the load balancing rules may include one or more load balancing weight factors. In various embodiments, the load balancing weight factors may be based on any of performance measurements, operator preferences, and WTRU preferences.

[0209] In various embodiments, the WTRU may receive load balancing rules from the NWDAF. In various embodiments, the NWDAF may provide load balancing rules to the WTRU and the UPF. In various embodiments, both the WTRU and the UPF may receive load balancing rules. The NWDAF may provide load balancing rules via the SMF.

[0210] In various embodiments, the load balancing rules may be either predictive or proactive. In various embodiments, the load balancing rules may include MATM rules. In various embodiments, the MATM rules may and / or may be used to configure the WTRU to adjust (e.g., dynamically adjust) one or more load balancing weight factors in a load balancing traffic steering mode of operation. In various embodiments, the MATM rules may and / or may be used to configure the WTRU (e.g., further configure) to switch (e.g., dynamically switch) between traffic steering modes of operation.

[0211] In various embodiments, the WTRU may implement the MATM rules as an ML component with a NN model (not shown). In various embodiments, the WTRU may train (e.g., dynamically train) and / or update (e.g., dynamically update) the NN model. In various embodiments, the WTRU may train (e.g., dynamically train) and / or update (e.g., dynamically update) the NN model based on one or more conditions of the WTRU and / or one or more conditions associated with the WTRU. In various embodiments, the conditions of the WTRU and / or the conditions associated with the WTRU may include any of traffic patterns, mobility, available capacity, etc.

[0212] In various embodiments, the first network may be and / or may include a first access network. In various embodiments, the second network may be and / or may include a second access network. In various embodiments, the first network may be and / or may include a 3GPP network. In various embodiments, the second network may be and / or may include a non-3GPP network. In various embodiments, the 3GPP network may be and / or may include a 3GPP access network. In various embodiments, the non-3GPP network may be and / or may include a non-3GPP access network.

[0213] Fig. 9 is a flow chart illustrating an example process 900 for performing analysis-based user plane optimization (e.g., analysis-based operation for ATSSS). The process 900 and the accompanying disclosure herein may be viewed as an example of a process 900 for performing analysis-based user plane optimization (e.g., analysis-based operation for ATSSS). Figures 4 to 6 A summary of at least some of the accompanying disclosures, and is considered to cover and / or include various embodiments of the above disclosures, including for example Figures 4 to 6 The accompanying public content. Figures 1A to 1D The process 900 may be performed using the architecture of the communication system 100. Other architectures may also be used to perform the process 900.

[0214] refer to Fig. 9 , a first network entity may receive first information indicating: (i) analysis-based operations for ASSS; (ii) a first weight for each of a plurality of access networks; and (iii) at least one first weighting factor for each of the plurality of access networks (902). In various embodiments, the first network entity may receive the first information from a second network entity. In various embodiments, the second network entity may be and / or may include a PCF. In various embodiments, the first network entity may be and / or may include an SMF. In various embodiments, the analysis-based operations may be and / or may include analysis-based load balancing operations for ASSS.

[0215] The first network entity may transmit second information indicating an analysis-based operation of the user ASSS, the second information including a first weight and a first weighting factor (904). In various embodiments, the first network entity may transmit the second information to a third network entity. In various embodiments, the third network entity may be and / or may include a UPF.

[0216] The first network entity may transmit third information to the fourth network entity, the third information indicating one or more load metrics (906). In various embodiments, the first network entity may transmit the third information to the fourth network entity. In various embodiments, the third network entity may be and / or may include a NWDAF. In various embodiments, the load metric may be based on the first weight and the first weighting factor.

[0217] The first network entity may receive fourth information indicating an analysis for controlling traffic steering of a multiple access protocol data unit session, the fourth information including one or more of (i) a second weight for at least one of the plurality of access networks and (ii) a second weighting factor for at least one of the plurality of access networks (908). In various embodiments, the first network entity may receive the fourth information from a fourth network entity. In various embodiments, the analysis may be based on any of: (a) third information transmitted to the fourth network entity; and (b) fifth information from the third network entity indicating a criterion for dividing downlink traffic between the plurality of access networks.

[0218] The first network entity may transmit sixth information indicating a second weight and / or a second weighting factor for at least one of the plurality of access networks (910). In various embodiments, the first network entity may transmit the sixth information to at least one of the third network entity and the WTRU. The sixth information may be transmitted to the third network entity and the WTRU according to the same protocol and / or as one or more rules. Alternatively, the sixth information may be transmitted to the third network entity according to the first protocol (e.g., N4) and / or as one or more rules (e.g., N4 rules). Alternatively and / or additionally, the sixth information may be transmitted to the WTRU according to the second protocol (e.g., ASSS) and / or as one or more rules (e.g., one or more ASSS rules).

[0219] The first network entity may transmit seventh information to the WTRU, the seventh information indicating analysis-based operations for ATSSS (not shown). In various embodiments, the analysis may be based on (e.g., also based on) eighth information from the WTRU, the eighth information indicating one or more criteria for dividing uplink traffic between multiple access networks. In various embodiments, the first network entity may receive the eighth information from the WTRU (not shown).

[0220] In various embodiments, the analysis may be based on (e.g., also based on) a prediction of when the guide will be deployed. In various embodiments, the analysis may be based on (e.g., also based on) ninth information indicating one or more behaviors of the WTRU (e.g., one or more expected behaviors of the WTRU). In various embodiments, the first network entity may receive the ninth information from the fifth network entity. In various embodiments, the fifth network entity may be and / or may include an AMF. In various embodiments, the analysis may be any of predictive and proactive.

[0221] In various embodiments, the second weight may be and / or may include a revision of one of the first weights. In various embodiments, the second weighting factor may be and / or may include a revision of one of the first weighting factors. In various embodiments, any of the second weight and the second weighting factor may be based on any of one or more performance measurements, one or more operator preferences, and one or more preferences of the WTRU. In various embodiments, the first network entity may receive the performance measurements from the operations administration and management entity. In various embodiments, the first network entity may receive the operator preferences from the second network entity.

[0222] Fig.10 1 is a flow chart illustrating an example process 1000 for performing analysis-based user plane optimization (e.g., analysis-based operation for ATSSS). The process 1000 and the accompanying disclosure herein may be viewed as at least Figures 4 to 6 The disclosures included herein are summarized and are considered to cover and / or include various embodiments of the above disclosures, including for example Figures 4 to 6 The accompanying public content. Figures 1A to 1D The process 1000 may be performed using the architecture of the communication system 100. Other architectures may also be used to perform the process 1000.

[0223] refer to Fig.10, a first network entity may receive first information indicating one or more load metrics, which may be based on first weights and first weighting factors of a plurality of access networks (1002). For example, the load metrics may be based on: (i) a first weight of each of the plurality of access networks; and (ii) at least one first weighting factor of each of the plurality of access networks. In various embodiments, the first network entity may receive the first information from at least one of a second network entity and a WTRU. In various embodiments, the second network entity may be and / or may include a UPF. In various embodiments, the first network entity may receive at least some of the first information from the WTRU via at least one of the second network entity and a third network entity. In various embodiments, the first network entity may receive at least some of the first information from the second network entity and via the third network entity. In various embodiments, the third network entity may be and / or may include an SMF. In various embodiments, the first network entity may be and / or may include an NWDAF.

[0224] The first network entity may receive second information indicating criteria for dividing downlink traffic between the plurality of access networks (1004). In various embodiments, the first network entity may receive the second information from and / or via the second network entity. In various embodiments, the first network entity may receive the second information from and / or via the second network entity and via a third network entity.

[0225] The first network entity may derive or otherwise determine an analysis for controlling traffic steering of a multiple access protocol data unit session, wherein the analysis may be determined based on one or more load metrics and / or criteria for dividing downlink traffic between multiple access networks (1006). The analysis may be and / or may include one or more of: (i) a second weight of at least one of the multiple access networks, and (ii) a second weighting factor of at least one of the multiple access networks. The first network entity may transmit third information indicating the analysis (1008). In various embodiments, the first network entity may transmit the third information to the third network entity. In various embodiments, the third network entity may be and / or may include the SMF.

[0226] In various embodiments, the analysis may be based on a prediction of when the guide will be deployed. In various embodiments, the analysis may be based at least in part on ninth information indicating a (e.g., expected) behavior of the WTRU. In various embodiments, the first network entity may receive information indicating the behavior of the WTRU from a fourth network entity. In various embodiments, the fourth network entity may be and / or may include an AMF. In various embodiments, the analysis may be any of predictive and proactive.

[0227] In various embodiments, the second weight may be and / or may include a revision of one of the first weights. In various embodiments, the second weighting factor may be and / or may include a revision of one of the first weighting factors. In various embodiments, any of the second weight and the second weighting factor may be based on any of one or more performance measurements, one or more operator preferences, and one or more preferences of the WTRU. In various embodiments, the first network entity may receive the performance measurements from the operations administration and management entity. In various embodiments, the first network entity may receive the operator preferences from the third network entity.

[0228] References

[0229] The following references may have been cited above and are herein incorporated by reference in their entirety.

[0230] 3GPP TR 23.793 "Study on Access Traffic Steering, Switch and SplittingSupport in the 5G System Architecture (Release 16)".

[0231] 3GPP TR 23.700-93 "Study on access traffic steering, switch and splitting support in the 5G System(5GS)architecture; Phase 2(Release 17)".

[0232] 3GPP SP-211612 "Study on Access Traffic Steering, Switching and Splitting support in the 5G system architecture; Phase 3 (Release 18)".

[0233] 3GPP TR 23.700-91"Study on enablers for network automation for the 5GSystem(5GS); Phase 2(Release 17)".

[0234] 3GPP SP-211652"New SID on Study on UPF enhancement for Exposure andSBA(Release 18)".

[0235] 3GPP SP-211650"Study on Enablers for Network Automation for 5G-Phase3(Release 18)".

[0236] 3GPP TR 22.874"Study on traffic characteristics and performancerequirements for AI / ML model transfer(Release 18)".

[0237] 3GPP SP-211328"Study on 5G System Support for AI / ML-based Services(Release 18)".

[0238] 3GPP SP-211568"Study on enhanced support of Non-Public Networks phase2(Release 18)".

[0239] 3GPP TS23.288"Architecture enhancements for 5G System(5GS)to supportnetwork data analytics services(Release 17)".

[0240] Salim,J.,Khosravi,H.,Kleen,A.and Kuznetsov,A.,2003.RFC3549:Linuxnetlink as an IP services protocol.

[0241] V.Mnih,A.P.Badia,M.Mirza,A.Graves,T.Lillicrap,and et al.,"Asynchronous methods for deep reinforcement learning,"in ICML'16.

[0242] TPLillicrap,JJHunt,A.Pritzel,and et al.,"Continuous control with deep reinforcement learning," arXiv preprint arXiv:1509.02971,2015.

[0243] in conclusion

[0244] Although features and elements are provided above in specific combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited in terms of the specific embodiments described in the present application, which are intended to be illustrations of various aspects. Without departing from its spirit and scope, many modifications and changes can be made, as will be apparent to those skilled in the art. Any element, action or instruction used in the description of the present application should not be interpreted as being critical or necessary to the present invention unless explicitly provided as such. In addition to those listed herein, functionally equivalent methods and devices within the scope of the present disclosure are apparent to those skilled in the art from the foregoing description. Such modifications and changes are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims and the full scope of equivalents given by such claims. It should be understood that the present disclosure is not limited to specific methods or systems herein.

[0245] For simplicity, the foregoing embodiments are discussed with respect to terminology and structure of devices with infrared capabilities (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems using other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0246] It will also be understood that the terms used herein are used only for the purpose of describing specific embodiments and are not intended to be limiting. As used herein, the term "video" or the term "image" may mean any of a snapshot, a single image, and / or a plurality of images displayed over a certain time basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of many embodiments of a WTRU; (iii) a device with wireless capabilities and / or wired capabilities (e.g., wearable) that is configured with some or all of the structure and functionality of a WTRU; (iii) a device with wireless capabilities and / or wired capabilities that is configured with less than all of the structure and functionality of a WTRU; or (iv) a similar device. References herein to Figures 1A to 1DDetails of an example WTRU are provided, which may be representative of any WTRU set forth herein. As another example, various disclosed embodiments herein are described above and below as utilizing a head mounted display. Those skilled in the art will recognize that devices other than a head mounted display may be utilized, and some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted reality experience.

[0247] In addition, the methods provided herein can be implemented in a computer program, software or firmware that is incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of non-temporary computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, MME, EPC, AMF or any host computer.

[0248] Variations of the methods, devices, and systems provided above are possible without departing from the scope of the present invention. In view of the various embodiments that may be applied, it should be understood that the embodiments shown are merely examples and should not be considered to limit the scope of the appended claims. For example, the embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery, etc.) that provides any suitable voltage.

[0249] In addition, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices including processors are mentioned. These devices may include at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, references to actions and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as "execution," "computer execution," or "CPU execution."

[0250] Those of ordinary skill in the art will appreciate that the actions and symbolic representations of operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits, which may cause the final conversion or reduction of electrical signals and maintain the data bits in memory locations in the storage system, thereby reconfiguring or otherwise changing the operation of the CPU and other processing of signals. The memory locations where the data bits are maintained are physical locations having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs, and other platforms and CPUs may support the provided methods.

[0251] The data bits may also be maintained on a computer-readable medium, including a magnetic disk, an optical disk, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system readable by a CPU. The computer-readable medium may include cooperating or interconnected computer-readable media that reside only on a processing system or distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories, and other platforms and memories may support the provided methods.

[0252] In an illustrative embodiment, any operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0253] There is little difference between hardware and software implementations of various aspects of the system. The use of hardware or software is usually (but not always, as in some cases, the choice of hardware or software may become important) a design choice that represents a cost-efficiency trade-off. There may be various vehicles (e.g., hardware, software, and / or firmware) with which the processes and / or systems and / or other technologies described herein can be implemented, and the preferred vehicle may change with the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are most important, then the implementer may select a primary hardware and / or firmware vehicle. If flexibility is most important, then the implementer may select a primary software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0254] The foregoing detailed description has been described various embodiments of the apparatus and / or process by using block diagrams, flow charts and / or examples. Insofar as such block diagrams, flow charts and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation within such block diagrams, flow charts or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware or indeed any combination thereof. In an embodiment, several parts of the subject matter described herein may be implemented via an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP) and / or other integrated formats. However, those skilled in the art will recognize that all or part of some aspects of the embodiments disclosed herein may be equivalently implemented in an integrated circuit, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware or almost as any combination thereof, and according to the present disclosure, designing circuit systems and / or writing codes for software and / or firmware will be completely within the skill range of those skilled in the art. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein can be distributed as a program product in a variety of forms, and that the illustrative examples of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually carry out the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc.; and transmission media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0255] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner set forth herein, and thereafter use engineering practices to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system by a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system can typically include a system unit housing, a video display device, a memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, a driver, a graphical user interface, and an application, one or more interactive devices such as a touch pad or screen, and / or a control system including a feedback loop and a control motor (e.g., feedback for sensing position and / or velocity; a control motor for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components, such as components typically found in data computing / communication and / or network computing / communication systems.

[0256] The subject matter described herein sometimes illustrates different parts that are included in different other parts or connected with different other parts.It should be understood that the architecture of such description is only an example, and many other architectures that realize the same function can actually be implemented.In a conceptual sense, any arrangement of parts for realizing the same function is effectively "associated" so that the desired function can be realized.Therefore, any two parts that are combined to realize a specific function in this article can be regarded as "associated" with each other so that no matter how the architecture or intermediate parts realize the desired function.Similarly, any two parts that are so associated can also be regarded as "operably connected" or "operably coupled" to realize the desired function, and any two parts that can be so associated can also be regarded as "operably coupled" to realize the desired function.The specific example of operable coupling includes (but is not limited to) parts that can be matched physically and / or physically interact, and / or parts that can be wirelessly interacted and / or wirelessly interacted, and / or parts that can be logically interacted and / or parts that can be logically interacted.

[0257] With respect to the use of substantially any plural and / or singular terms herein, those skilled in the art can translate from the plural to the singular and / or from the singular to the plural where appropriate to the context and / or application. For clarity, the various singular / plural arrangements may be expressly set forth herein.

[0258] Those skilled in the art will understand that, in general, the terms used herein and particularly in the appended claims (e.g., the bodies of the appended claims) are generally intended to be "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "including but not limited to," etc.). Those skilled in the art will further understand that if a specific number of an introduced claim statement is intended, such intent will be expressly stated in the claim, and in the absence of such a statement, such intent is not present. For example, where only one item is intended, the term "single" or similar language may be used. To aid understanding, the following appended claims and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce multiple claim statements. However, the use of such phrases should not be interpreted as implying that a claim recitation introduced by the indefinite article "a" or "an" will limit any particular claim including such introduced claim recitation to embodiments including only one such recitation, even if the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same is true for the use of definite articles to introduce claim recitations. In addition, even if a specific number of introduced claim recitations is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted as meaning at least the recited number (e.g., merely reciting "two recitations" without other modifiers means at least two recitations or two or more recitations). Furthermore, in those cases where a convention similar to “at least one of A, B, and C, etc.” is used, generally, such construction is intended to represent the convention that one skilled in the art would understand (e.g., “a system having at least one of A, B, and C” would include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). In those cases where a convention similar to “at least one of A, B, or C, etc.” is used, generally, such meaning is intended in the sense that one skilled in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C, etc.). One skilled in the art would further understand that any transitional words and / or phrases (whether in the specification, claims, or drawings) that actually give two or more alternatives should be understood to contemplate the possibility of including one of the items, either of the items, or both of the items.For example, the phrase "A or B" will be understood to include the possibility of "A" or "B" or "A and B." In addition, the term "any" as used herein followed by a list of multiple items and / or categories of items is intended to include "any," "any combination," "any multiple," and / or "any combination of multiples," either alone or in combination with other items and / or other categories of items. Furthermore, the term "set," as used herein, is intended to include any number of items, including zero. Additionally, the term "number," as used herein, is intended to include any number, including zero. And the term "plurality," as used herein, is intended to be synonymous with "multiple."

[0259] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0260] As will be understood by those skilled in the art, for any and all purposes, such as in providing a written description, all ranges disclosed herein also encompass any and all possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be easily identified as fully describing and capable of decomposing the same range into at least equal halves, one-third, one-quarter, one-fifth, one-tenth, etc. As a non-limiting example, each range discussed herein can be easily decomposed into a lower third, a middle third, and an upper third, etc. As will be understood by those skilled in the art, all languages ​​such as "at most", "at least", "greater than", "less than", etc. include the enumerated numbers, and refer to the ranges that can be subsequently subdivided into sub-ranges as discussed above. Finally, as will be understood by those skilled in the art, the range includes each individual member. Therefore, for example, a group with 1 to 3 units refers to a group with 1, 2 or 3 units. Similarly, a group with 1 to 5 units refers to a group with 1, 2, 3, 4 or 5 units, and so on.

[0261] Furthermore, the claims should not be read as limited to the order or elements provided unless otherwise stated. In addition, the use of the term "means for..." in any claim is intended to invoke 35 U.S.C. § 112, or means-plus-function claim format, and any claim without the term "means for..." is not intended to be so.

[0262] By way of example, suitable processors include a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), an application specific standard product (ASSP); a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or state machine.

[0263] The WTRU may be used in conjunction with modules implemented in hardware and / or software, including software defined radio (SDR), and other components such as cameras, video camera modules, video phones, speaker phones, vibrating devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, module, a frequency modulation (FM) radio unit, a near field communication (NFC) module, a liquid crystal display (LCD) display unit, an organic light emitting diode (OLED) display unit, a digital music player, a media player, a video game console module, an internet browser, and / or any wireless local area network (WLAN) or ultra-wideband (UWB) module.

[0264] Although various embodiments have been described in terms of a communication system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In certain embodiments, one or more functions of the various components may be implemented in software controlling a general purpose computer.

[0265] Furthermore, while the invention has been shown and described herein with reference to particular embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the range and range of equivalents of the claims and without departing from the invention.

Claims

1. A method implemented in a first network entity, the method comprising: receiving first information from a second network entity, the first information indicating: (i) analysis-based operations for access traffic steering, offloading, and switching, (ii) a first weight for each of a plurality of access networks, and (iii) at least one first weighting factor for each of the plurality of access networks; transmitting second information to a third network entity, the second information indicating the analysis-based operation for access traffic steering, splitting, and switching, the second information including the first weight and the first weighting factor; transmitting third information to a fourth network entity, the third information indicating one or more load metrics, wherein the one or more load metrics are based on the first weight and the first weighting factor; receiving fourth information from the fourth network entity, the fourth information indicating an analysis for controlling traffic steering of a multiple access protocol data unit session, the fourth information comprising one or more of: (i) a second weight of at least one access network of the plurality of access networks and (ii) a second weighting factor of at least one access network of the plurality of access networks, wherein the analysis is based on: (a) transmitting the third information to the fourth network entity; as well as (b) fifth information from the third network entity, the fifth information indicating a criterion for dividing downlink traffic between the plurality of access networks; and Sixth information is transmitted to at least one of the third network entity and a wireless transmit / receive unit (WTRU), the sixth information indicating one or more of: (i) a second weight and (ii) a second weighting factor.

2. The method according to claim 1, comprising: Seventh information is transmitted to the WTRU, wherein the seventh information indicates the analysis-based operation for access traffic steering, diversion and switching, wherein the analysis is also based on eighth information from the WTRU, wherein the eighth information indicates one or more criteria for dividing uplink traffic between the multiple access networks.

3. The method according to at least one of claims 1 to 2, comprising receiving the eighth information from the WTRU.

4. A first network entity comprising a circuit system, the circuit system comprising a transmitter, a receiver, a processor and a memory, the circuit system being configured to: receiving first information from a second network entity, the first information indicating: (i) analysis-based operations for access traffic steering, offloading, and switching, (ii) a first weight for each of a plurality of access networks, and (iii) at least one first weighting factor for each of the plurality of access networks; transmitting second information to a third network entity, the second information indicating the analysis-based operation for access traffic steering, splitting, and switching, the second information including the first weight and the first weighting factor; transmitting third information to a fourth network entity, the third information indicating one or more load metrics, wherein the one or more load metrics are based on the first weight and the first weighting factor; receiving fourth information from the fourth network entity, the fourth information indicating an analysis for controlling traffic steering of a multiple access protocol data unit session, the fourth information comprising one or more of: (i) a second weight of at least one access network of the plurality of access networks and (ii) a second weighting factor of at least one access network of the plurality of access networks, wherein the analysis is based on: (a) transmitting the third information to the fourth network entity; as well as (b) fifth information from the third network entity, the fifth information indicating a criterion for dividing downlink traffic between the plurality of access networks; and Sixth information is transmitted to at least one of the third network entity and a wireless transmit / receive unit (WTRU), the sixth information indicating one or more of: (i) a second weight and (ii) a second weighting factor.

5. The first network entity according to claim 4, wherein: The circuit system is configured to: Seventh information is transmitted to the WTRU, wherein the seventh information indicates the analysis-based operation for access traffic steering, diversion and switching, wherein the analysis is also based on eighth information from the WTRU, wherein the eighth information indicates one or more criteria for dividing uplink traffic between the multiple access networks.

6. The first network entity according to at least one of claims 4 to 5, wherein: The circuit system is configured to receive the eighth information from the WTRU.

7. The method according to at least one of claims 1 to 3 or the first network entity according to at least one of claims 4 to 6, wherein: At least one of the following: The first network entity includes a session management function; The second network entity includes a policy control function; The third network entity comprises a user plane function; and The fourth network entity includes a network data analysis function.

8. A method implemented in a first network entity, the method comprising: receiving first information from at least one of a second network entity and a wireless transmit / receive unit (WTRU), the first information indicating one or more load metrics, wherein the one or more load metrics are based on: (i) a first weight for each of a plurality of access networks and (ii) at least one first weighting factor for each of the plurality of access networks; receiving second information from the second network entity, the second information indicating a criterion for dividing downlink traffic between the plurality of access networks; determining an analysis for controlling traffic steering of a multiple access protocol data unit session, wherein the analysis is determined based on the one or more load metrics and a criterion for dividing downlink traffic among the plurality of access networks, and wherein the analysis includes one or more of: (i) a second weight for at least one of the plurality of access networks and (ii) a second weighting factor for at least one of the plurality of access networks; as well as Third information is transmitted to a third network entity, the third information indicating the analysis.

9. A first network entity comprising a circuit system, the circuit system comprising a transmitter, a receiver, a processor and a memory, the circuit system being configured to: receiving first information from at least one of a second network entity and a wireless transmit / receive unit (WTRU), the first information indicating one or more load metrics, wherein the one or more load metrics are based on: (i) a first weight for each of a plurality of access networks and (ii) at least one first weighting factor for each of the plurality of access networks; receiving second information from the second network entity, the second information indicating a criterion for dividing downlink traffic between the plurality of access networks; determining an analysis for controlling traffic steering of a multiple access protocol data unit session, wherein the analysis is determined based on the one or more load metrics and a criterion for dividing downlink traffic among the plurality of access networks, and wherein the analysis includes one or more of: (i) a second weight for at least one of the plurality of access networks and (ii) a second weighting factor for at least one of the plurality of access networks; as well as Third information is transmitted to a third network entity, the third information indicating the analysis.

10. The method according to claim 8 or the first network entity according to claim 9, wherein: At least one of the following: receiving, via the second network entity, at least some of the first information from the WTRU; receiving the first information via the third network entity; and The second information is received via the third network entity.

11. The method according to at least one of claims 8 and 10 or the first network entity according to at least one of claims 9 to 10, wherein: At least one of the following: The first network entity includes a network data analysis function; The second network entity comprises a user plane function; and The third network entity comprises a session management function.

12. The method according to at least one of claims 1 to 3 and 7, the first network entity according to at least one of claims 4 to 7, the method according to at least one of claims 8 and 10 to 11 or the first network entity according to at least one of claims 9 to 11, wherein The analysis is based on a prediction of when the guide will be deployed.

13. The method according to at least one of claims 1 to 3, 7 and 12, the first network entity according to at least one of claims 4 to 7 and 12, the method according to at least one of claims 8 and 10 to 12 or the first network entity according to at least one of claims 9 to 12, wherein: The analysis is also based on ninth information from a fifth network entity, the ninth information indicating an expected behavior of the WTRU.

14. The method according to at least one of claims 1 to 3, 7 and 12, the first network entity according to at least one of claims 4 to 7 and 12, the method according to at least one of claims 8 and 10 to 12 or the first network entity according to at least one of claims 9 to 12, wherein: The analysis is also based on ninth information from a fifth network entity, the ninth information indicating an expected behavior of the WTRU, and wherein the fifth network entity includes access and mobility management functionality.

15. The method according to at least one of claims 1 to 3, 7 and 12 to 14, the first network entity according to at least one of claims 4 to 7 and 12 to 14, wherein: The analysis-based operations include analysis-based load balancing operations for the access traffic steering, diversion and switching.

16. The method according to at least one of claims 1 to 3, 7 and 12 to 15, the first network entity according to at least one of claims 4 to 7 and 12 to 15, the method according to at least one of claims 8 and 10 to 15 or the first network entity according to at least one of claims 9 to 15, wherein The analysis is predictive and proactive.

17. The method of at least one of claims 1 to 3, 7 and 12 to 16, the first network entity of at least one of claims 4 to 7 and 12 to 16, the method of at least one of claims 8 and 10 to 16, or the first network entity of at least one of claims 9 to 16, wherein the one or more of the second weight and the second weighting factor are based on any one of one or more performance measurements, one or more operator preferences, and one or more preferences of the WTRU.

18. The method according to at least one of claims 1 to 3, 7 and 12 to 16 or the first network entity according to at least one of claims 4 to 7 and 12 to 16, the method according to at least one of claims 8 and 10 to 16 or the first network entity according to at least one of claims 9 to 16, wherein Any of the second weight and the second weighting factor is based on any of one or more performance measurements, one or more operator preferences, and one or more preferences of the WTRU, and wherein the one or more performance measurements are received from an operations administration and management entity.

19. The method according to at least one of claims 1 to 3, 7 and 12 to 16 or the first network entity according to at least one of claims 4 to 7 and 12 to 16, wherein: Any of the second weight and the second weighting factor is based on any of one or more performance measurements, one or more operator preferences, and one or more preferences of the WTRU, and wherein the one or more operator preferences are received from the second network entity.

20. The method according to at least one of claims 8 and 10 to 16 or the first network entity according to at least one of claims 9 to 16, wherein: Any of the second weight and the second weighting factor is based on any of one or more performance measurements, one or more operator preferences, and one or more preferences of the WTRU, and wherein the one or more operator preferences are received from the third network entity.

21. The method according to at least one of claims 1 to 3, 7 and 12 to 20, the first network entity according to at least one of claims 4 to 7 and 12 to 20, the method according to at least one of claims 8 and 10 to 20 or the first network entity according to at least one of claims 9 to 20, wherein The second weight comprises a revised version of one of the first weights, and wherein the second weighting factor comprises a revised version of one of the first weighting factors.

Images