Coping with dynamic changes in traffic patterns in DL

Abstract

Systems and methods are described herein for coping with dynamic changes in traffic patterns in the downlink (DL). A network device can cope with dynamic changes in traffic patterns. The network device can provide a means for detecting or learning when a traffic burst can start. Based on the detection or learning of when a traffic burst can start, the network device can activate resources for delivering traffic, for example, to minimize jitter and / or delay.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application 63 / 541,172, filed on September 28, 2023, the contents of which are incorporated herein by reference in their entirety. Background Technology

[0002] Mobile communication using wireless communication continues to evolve. The fifth generation can be called 5G. The previous generation (traditional) mobile communication can be, for example, the fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] This paper describes systems and methods for responding to dynamic changes in traffic patterns in the downlink (DL). Network devices can respond to dynamic changes in traffic patterns. Network devices can provide means for detecting or knowing when a traffic burst may begin. Based on the detection or knowing when a traffic burst may begin, the network device can activate resources used to deliver traffic, for example, to minimize jitter and / or latency.

[0004] A first network device (e.g., a User Plane Function (UPF) node) can respond to dynamic changes in traffic patterns. The first network device can receive configuration messages (e.g., from a second network device, such as a Session Management Function (SMF) node). Configuration messages can be received via an interface (e.g., an N4 interface). Configuration messages can instruct the transmission of information associated with upcoming data traffic bursts. Configuration messages can include traffic pattern configuration rule information. Configuration messages can instruct traffic pattern detection configuration information. Traffic pattern detection configuration information can be associated with detecting traffic bursts. Traffic pattern configuration rule information can include one or more of Quality of Service Enforcement (QER) rules or Packet Detection (PDR) rules. The first network device can receive downlink data. The first network device can detect at least one upcoming data traffic burst based on configuration messages and / or based on downlink data. The first network device can, for example, determine the burst size associated with at least one upcoming data traffic burst based on configuration messages and / or based on downlink data. The first network device can, for example, determine the expected start time associated with at least one upcoming data traffic burst based on configuration messages and / or based on downlink data. The first network device can send notification of the upcoming data traffic burst to a third network device. The third network device may include a Radio Access Network (RAN) node or a second network device. Notification of an upcoming data traffic burst can be sent using General Packet Radio Service Tunneling Protocol User Plane (GTP-U) messages. Information associated with the upcoming data traffic burst can be indicated in the GTP-U message header. The notification of the upcoming data traffic burst may indicate the determined burst size and / or the determined expected start time. Attached Figure Description

[0005] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented; Figure 1B The illustration shows that, according to one embodiment, it is possible to Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system. Figure 1C The illustration shows that, according to one embodiment, it is possible to Figure 1A The diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system. Figure 1D The illustration shows that, according to one embodiment, it is possible to Figure 1A The system diagram shown in the figure illustrates a further example RAN and a further example CN used within the communication system. Figure 2 This is a block diagram of an example multiplexed data stream.

[0006] Figure 3 It is a signal diagram depicting the dynamic detection and response to data traffic patterns according to one embodiment.

[0007] Figure 4 It is a signal diagram depicting the dynamic detection of changes in data traffic patterns according to one embodiment and reporting them to the user equipment. Technical Field

[0008] This disclosure addresses the adaptation of data traffic pattern detection and reporting in 5G systems. Detailed Implementation

[0009] In the following detailed description, numerous 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 may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, processes, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, the embodiments and other examples expressly, implicitly, and / or inherently described, disclosed, or otherwise provided (collectively, the “Provided”) herein.

[0010] This article can describe an example communication system.

[0011] Figure 1A This diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and the like.

[0012] like Figure 1AAs 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. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRUs 102a, 102b, 102c, and 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), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

[0014] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In embodiments, 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.

[0015] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0016] More specifically, as noted above, communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can 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).

[0017] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

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

[0019] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for example, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0020] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0021] Figure 1ABase station 114b can be, for example, a wireless router, a home Node-B, a home eNode-B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, and the like. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0022] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but to be understood, RAN104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0023] CN 106 / 115 can also be used as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0025] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1B As shown, among other things, WTRU 102 may also include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the foregoing elements.

[0026] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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, and the like. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmit / receive element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

[0028] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmit / receive elements 122. More specifically, WTRU 102 may employ MIMO technology. Thus, in one embodiment, WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0029] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via various RATs, such as NR and IEEE 802.11.

[0030] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from the speaker / microphone 124, keypad 126, and / or display / touchpad 128. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 can access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any type of suitable memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, memory stick, secure digital storage (SD) card, and the like. In other embodiments, processor 118 may access memory information that is never physically located on WTRU 102 (such as on a server or home computer (not shown)) and store the data in that memory.

[0031] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0032] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable location determination method.

[0033] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, and the like. Peripheral devices 138 may include one or more sensors. These sensors may be one or more of the following: 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.

[0034] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all 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 for reducing and / or substantially eliminating self-interference through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for either uplink (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0035] Figure 1C The diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0036] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. Each of eNode-Bs 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, eNode-B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0037] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to respond to radio resource management decisions, handover decisions, user scheduling in the uplink (UL) and / or downlink (DL), and the like. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0038] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the foregoing elements is depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0039] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, and the like. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0040] The SGW 164 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-eNode-B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, and so on.

[0041] The SGW 164 can connect to the PGW 166, which can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0042] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or can communicate with such an IP gateway. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0043] Despite WTRU in Figure 1A-1D While described as a wireless terminal, in some representative embodiments such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

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

[0045] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneling DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode in this document.

[0046] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz wide bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, STAs including the AP (e.g., each STA) can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit in a given BSS at any given time.

[0047] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0048] The Very High Throughput (VHT) STA can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels (which can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be split into two streams by a segment parser. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing are performed separately on each stream. The streams can be mapped onto two 80 MHz channels, and data can be transmitted via the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0049] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support instrument-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., for maintaining very long battery life).

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

[0051] In the United States, the available frequency band for 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. Depending on the country code, the total bandwidth available for 802.11ah ranges from 6 MHz to 26 MHz.

[0052] Figure 1D The diagram illustrates a system diagram of RAN 113 and CN 115 according to an embodiment. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0053] RAN 113 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from WTRUs 102a, 102b, and 102c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement cooperative multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0054] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable numerology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0055] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate with / be connected to gNBs 180a, 180b, and 180c, and also communicate with / be connected to another RAN (such as eNode-B 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-B 160a, 160b, and 160c can be used as mobility anchors for WTRU 102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRU 102a, 102b, and 102c.

[0056] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to respond to radio resource management decisions, handover decisions, user scheduling in the uplink (UL) and / or downlink (DL), network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, and the like. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0057] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly one Data Network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0058] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and the like. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of services utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra-Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, and / or the like. AMF 182a and 182b can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0059] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure the routing of traffic passing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and so on. PDU session types can be IP-based, non-IP-based, Ethernet-based, and so on.

[0060] UPF 184a and 184b can be connected via an N3 interface to one or more gNBs 180a, 180b, and 180c in RAN 113. This N3 interface can provide WTRU 102a, 102b, and 102c with access to a packet-switched network (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and so on.

[0061] CN 115 can facilitate communication with other networks. For example, CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 115 and PSTN 108, or may communicate with such an IP gateway. Additionally, CN 115 can provide WTRUs 102a, 102b, and 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, WTRUs 102a, 102b, and 102c can be connected to local data networks (DNs) 185a and 185b via UPFs 184a and 184b through their N3 interfaces and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0062] Given Figure 1A-1D as well as Figure 1A-1D The functions described herein with reference to any of the following can be performed by one or more emulation components / devices (not shown): WTRU102a-d, base station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other devices described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0063] Simulation devices can be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, one or more simulation devices can perform one or more or all functions while being 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 while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing purposes and / or can be used to perform tests via over-the-air wireless communication.

[0064] One or more emulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices can be used in test scenarios within test laboratories and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices can be test rigs. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) can be used by the emulation devices to transmit and / or receive data.

[0065] The examples provided in this article do not limit the applicability of this topic to other wireless technologies, such as other wireless technologies using the same or different principles that may be applicable.

[0066] As explained herein, a wireless transmit / receive unit (WTRU) can be an example of a user equipment (UE). Therefore, the terms UE and WTRU can be used in the same context.

[0067] This paper describes systems and methods for responding to dynamic changes in traffic patterns in the downlink (DL). Network devices can respond to dynamic changes in traffic patterns. Network devices can provide means for detecting or knowing when a traffic burst may begin. Based on the detection or knowing when a traffic burst may begin, the network device can activate resources used to deliver traffic, for example, to minimize jitter and / or latency.

[0068] A first network device (e.g., a User Plane Function (UPF) node) can respond to dynamic changes in traffic patterns. The first network device can receive configuration messages (e.g., from a second network device, such as a Session Management Function (SMF) node). Configuration messages can be received via an interface (e.g., an N4 interface). Configuration messages can instruct the transmission of information associated with upcoming data traffic bursts. Configuration messages can include traffic pattern configuration rule information. Configuration messages can instruct traffic pattern detection configuration information. Traffic pattern detection configuration information can be associated with detecting traffic bursts. Traffic pattern configuration rule information can include one or more of Quality of Service Enforcement (QER) rules or Packet Detection (PDR) rules. The first network device can receive downlink data. The first network device can detect at least one upcoming data traffic burst based on configuration messages and / or based on downlink data. The first network device can, for example, determine the burst size associated with at least one upcoming data traffic burst based on configuration messages and / or based on downlink data. The first network device can, for example, determine the expected start time associated with at least one upcoming data traffic burst based on configuration messages and / or based on downlink data. The first network device can send notification of the upcoming data traffic burst to a third network device. The third network device may include a Radio Access Network (RAN) node or a second network device. Notification of an upcoming data traffic burst can be sent using General Packet Radio Service Tunneling Protocol User Plane (GTP-U) messages. Information associated with the upcoming data traffic burst can be indicated in the GTP-U message header. The notification of the upcoming data traffic burst may indicate the determined burst size and / or the determined expected start time.

[0069] This article may describe session management parameters (e.g., N4 session management parameters).

[0070] For example, the Session Management Function (SMF) can use parameters to control the functionality of the User Plane Function (UPF) and / or notify the SMF of events occurring at the UPF.

[0071] Parameters provided from the SMF to the UPF (e.g., via the N4 reference point) may include a session ID (e.g., N4 session ID) and may also include one or more of the following: Packet Detection Rules (PDRs), which may include information classifying traffic ((multiple) PDUs) arriving at the UPF; Forwarding Action Rules (FARs), which may include information about whether forwarding, dropping, or buffering should be applied to traffic identified by (multiple) PDRs; Multi-Access Rules (MARs), which may include information about how to handle traffic steering, switching, and splitting of MA PDU sessions; Usage Reporting Rules (URRs), which may include information indicating (e.g., defining) how traffic identified by (multiple) PDRs should be considered and how a measurement should be reported; QoS Enforcement Rules (QERs), which may include, for example, information related to QoS enforcement of traffic identified by (multiple) PDRs; Session Reporting Rules (SRRs), which may include information for requesting UP functionality to detect and report events of PDU sessions that are unrelated to a specific PDR of the PDU session or unrelated to traffic usage measurements; tracing requests; port management information containers (e.g., in 5GS); bridge / router information; and so on.

[0072] A session ID (e.g., an N4 session ID) can be assigned by the SMF. The N4 session ID can identify (e.g., uniquely identify) an N4 session.

[0073] This article may use and / or describe PDU collection header fields.

[0074] The header field can be associated with a PDU set. The PDU Set Sequence Number (PSSN) can include a header field that encodes the sequence number of the PDU set to which the current PDU belongs, which acts as a 10-bit numeric identifier for that PDU set.

[0075] The use of PDU set features can be negotiated.

[0076] For example, application servers (AS) and / or applications hosted in WTRU can use Session Description Protocol (SDP) signaling to negotiate the use of PDU set tags. Negotiating the use of PDU set tags can include the sending application (e.g., an AS or WTRU-hosted application) instructing the receiving application (e.g., another AS or WTRU-hosted application) whether the sender supports adding a PDU set header extension. This instruction can be included in and sent within an SDP message.

[0077] This article can describe flow patterns.

[0078] Traffic flow can be analogous to various patterns that change over time. Some patterns may be more common and known in advance than others.

[0079] Metadata types can be carried as RTP payloads for augmented reality real-time communication services. When data is delivered continuously, reliability can be assumed to be less critical. Older values ​​may lose importance with delays. Continuous bit streams can be sent at a fixed sampling rate. Burst traffic can be triggered, for example, sending a motion signal when motion is detected. Direction can be determined based on whether the WTRU is sending data, receiving data, or both (e.g., sendrecv).

[0080] Table 1: Types of Metadata In the example, the application can contain audio, video, and haptic streams. The traffic pattern can also vary based on modality. For example, video can have frames that may be shifted in time due to clock shifts or network usage. Audio can have periodic samples, but may have silent periods with no traffic.

[0081] This article may consider and / or describe the end of the outbreak.

[0082] Indications for the end of a data burst can be provided to the NG-RAN via the UPF, for example, to configure a WTRU power management scheme (e.g., Connected Mode Discontinuous Receive (DRX)).

[0083] The Policy Control Function (PCF) can specify the protocol description within the Policy and Charging Control (PCC) rules based on information provided by the AF and / or local operator policies.

[0084] For example, based on PCC rules and / or local operator policies, the SMF may request the UPF to detect the last PDU of a data burst and mark the end of the data burst in the General Packet Radio Service Tunneling Protocol User Plane (GTP-U) header of the last PDU in the downlink.

[0085] Based on the request and information from the SMF, the UPF can identify the last PDU of the data burst in the DL traffic based on the end indication according to the protocol header as defined in the protocol description or UPF implementation, and provide the data burst end indication to the NG-RAN through the GTP-U of the last PDU of the data burst.

[0086] Following a PDU with a data burst end indication, there may be some packets from the data burst received by the NG-RAN (e.g., if the packets were not received in order).

[0087] System design (e.g., 5G systems) may not provide a means for RAN nodes to detect or know when a burst is about to begin. The time interval between two consecutive bursts may be similar for multiple consecutive bursts, but it can also vary. Therefore, RAN nodes may not anticipate that the time interval between two consecutive bursts will be similar. If RAN nodes can detect when a burst is about to begin, they may be able to activate the user plane resources necessary to deliver traffic to the WTRU. By ensuring faster activation of user plane resources for bursts, jitter and latency can be minimized.

[0088] Data traffic generated by an application may resemble certain traffic patterns. Data traffic can vary over time and based on the modality of the data (e.g., video, audio, haptic). For example, a traffic pattern may be valid for a period of time (e.g., valid only for a period of time).

[0089] For example, downlink data traffic associated with extended reality, augmented reality, or general media streaming traffic may be characterized by the fact that it is received by the UPF in a regular pattern. This pattern may be characterized by the fact that data traffic is received in bursts. A burst may include one or more PDUs (e.g., where the time between each PDU is relatively short). For example, if the time between bursts is relatively long compared to the time between PDUs within a burst, the next traffic burst may arrive after a certain period.

[0090] (For example, sometimes) the pattern associated with downlink traffic can change. A change in the pattern can mean that the time intervals between consecutive bursts can be similar for many consecutive bursts before transitioning to the second time interval.

[0091] The system (e.g., a 5G system) may include designs that enable the UPF to detect (e.g., sometimes detect) the end of a burst. For example, the UPF may detect that a PDU is the last PDU in the PDU set, for instance, based on information in the PDU's header. When the UPF sends a PDU to the RAN node, it may indicate that the PDU is the last PDU in the burst. The RAN may use the burst end information to trigger a change in the WTRU's power management settings. Connection mode DRX settings and time (e.g., via a timer) may be example power management settings.

[0092] 5G system design may impede support for RAN node detection or awareness of when a burst is about to begin. The time interval between two consecutive bursts can be similar for multiple consecutive bursts, but it can also vary. Therefore, the RAN node may not be able to anticipate that the time interval between two consecutive bursts will be similar. If the RAN node is able to detect when a burst is about to begin, it may be able to activate (e.g., necessary) user plane resources for delivering traffic to the WTRU. By ensuring faster activation of user plane resources for bursts, jitter and latency can be minimized.

[0093] Multiple Service Data Streams (SDFs) can be multiplexed onto the same QoS stream (e.g., such as...). Figure 2 As shown in the diagram, this can be a challenge in detecting the start of a burst. SDFs can be associated with different burst patterns. If multiple SDFs are multiplexed onto the same QoS flow, the data bursts associated with each QoS flow can follow different patterns. RAN nodes can detect when a burst is about to begin for each SDF of a QoS flow.

[0094] The WTRU may not be able to detect an impending burst and / or determine the time between the current burst and the next. If the WTRU could detect when a burst is about to begin, it could potentially begin preparing resources for the approaching data burst. For example, if the data burst is to be forwarded to a tethered device on a network, the WTRU could activate (e.g., begin activating) the network-shared connection. This can reduce (e.g., help reduce) perceived jitter. Therefore, allowing the WTRU to detect when a burst is about to begin enables it to prepare resources to handle the traffic before it receives it.

[0095] A RAN node may include (for example, refer to) a base station or a network node that controls one or more base stations. The terms RAN node, NG-RAN, and NG-RAN node may be used interchangeably. Details and / or characteristics applied to a RAN node may be applied to other nodes whose interfaces are connected to the access network, such as, for example, Non-3GPP Interoperability Function (N3IWF) or Trusted Non-3GPP Gateway Function (TNGF).

[0096] N6 may include (for example, referring to) a UPF interface that can be used to send and receive PDUs. For example, PDUs can be sent to and received from an application server. PDUs can be in IP or Ethernet format. An N6 traffic stream may include a series of PDUs matching the same PDR or SDF.

[0097] This document describes Packet Detection Rules (PDRs). A PDR may include information used (e.g., as required) to classify uplink or downlink packets arriving at the UPF. Information used for packet detection may include one or more of the following: source interface, WTRU IP address, network instance, core network tunnel information, packet filter set, application identifier, QoS flow identifier, Ethernet PDU session information, framing routing information, FQDN filters for DNS queries, or protocol descriptions. The application identifier in the PDR may identify the Packet Flow Description (PFD). The PDR may also include which QoS enforcement rules should be applied to the detected traffic.

[0098] This document describes QoS Enforcement Rules (QERs). A QER may include a QoS Flow ID that can be applied to associated traffic. A QER may indicate to the UPF whether PDU set information associated with downlink packets should be inserted into the GTP-U header.

[0099] Detection and dynamic reporting of traffic pattern changes for RANs can be enabled. Detection and dynamic reporting of traffic pattern changes for WTRUs can also be enabled. This document describes the impact on traffic patterns when multiple data streams / SDFs are multiplexed into the same QoS stream. Regarding the embodiments described herein, one or more of the following parameters may be included in the traffic pattern report: early indication of burst approach; duration of the burst; how long until the next packet or the next burst (e.g., in milliseconds); how many times or for how long the pattern may repeat; dependencies between data streams, between QoS streams, and between PDU sessions / devices / users (e.g., header fields may indicate that the next burst may occur in another QoS stream, or that the burst may occur in multiple QoS streams at similar times; header fields may specify whether the same burst pattern experienced at the current QoS stream is likely to be experienced in another QoS stream within 2 ms); traffic graph. The start and end of the case; any changes to the current pattern (e.g., any changes that may occur if the interval between bursts can change from 2 ms to 1 ms, which may be indicated in the header fields of the (multiple) groups); the importance of the flow pattern or a portion thereof (e.g., such that a notified entity can decide whether to use the notification), which may be a priority indicator; the flow model used to predict subsequent flow patterns; the mean and variance of the burst period / length / size; the number of sub-flows present in the flow; the codecs being used and their settings (e.g., an indication of the size of the burst, which may be expressed in bytes or as a relative measure such as “small,” “medium,” “large”); and so on.

[0100] A protection time parameter can be used in or when sending traffic pattern notifications. This can mitigate erroneous detection / prediction, such as the RAN prematurely waking the WTRU from sleep mode, using more energy than optimally, or the RAN responding too late, causing delays. When deciding when to report or when reporting traffic pattern timing (e.g., burst start time), the detection / prediction time minus the protection time can be adjusted based on a preference between the two effects (e.g., too early vs. too late).

[0101] Changes in the flow pattern can be detected and dynamically reported to the RAN.

[0102] Figure 3 The illustration shows an example of the process for enabling the detection of flow pattern changes and dynamic reporting to the RAN.

[0103] like Figure 3 As shown at point 1, flow pattern detection can be triggered at the RAN.

[0104] like Figure 3 As shown in section 2, the WTRU application and AS can negotiate to support indicating burst arrival time information in the header.

[0105] like Figure 3 As shown in section 3, the SMF can receive a message from the RAN node instructing the RAN node to support the reception of traffic pattern notifications.

[0106] like Figure 3 As shown in section 4, the application server / application function (AS / AF) can (e.g., via NEF) inform the PCF that it can tag downlink traffic with pattern-related information (e.g., burst arrival time information).

[0107] like Figure 3 As shown in section 5, the SMF can receive PCC rules from the PCF. The PCC rules inform the SMF that downlink traffic will include traffic pattern information (e.g., burst arrival time information).

[0108] like Figure 3 As shown at point 6, SMF can enable (e.g., decide whether to enable) traffic pattern detection and notification features.

[0109] like Figure 3 As shown at point 7, the UPF can be configured (e.g., by the SMF) to detect traffic pattern information based on the generated traffic pattern detection configuration. The PDR and / or QER can be enhanced to specify that the header field in the received packet can indicate that a traffic burst is about to follow, and when this field is read, the UPF can notify the RAN of the approaching traffic burst.

[0110] like Figure 3 As shown at point 8, the SMF can be configured with the RAN to receive dynamic traffic pattern information.

[0111] like Figure 3 As shown in point 9, UPF can detect specific traffic patterns / traffic bursts.

[0112] like Figure 3 As shown at point 10, the UPF can send a notification to the RAN via GTP-U that it expects a specific traffic pattern (e.g., burst).

[0113] like Figure 3 As shown at 11, the UPF can (e.g., via the SMF) send a notification message to the RAN that can expect a specific traffic pattern (e.g., burst).

[0114] like Figure 3 As shown at 12, the RAN node can prepare user plane resources for it, for example, before the arrival of the second traffic pattern (e.g., burst).

[0115] like Figure 3 As shown at point 1, traffic pattern detection can be triggered at the RAN. For example, this can be triggered by processes such as PDU session establishment / modification or switching.

[0116] Alternatively, traffic pattern detection can be triggered at the core network. For example, an SMF can be triggered to detect traffic patterns, and the SMF can be configured with a UPF to detect specific traffic patterns.

[0117] like Figure 3 As shown at point 2, the RAN node can send messages to the SMF, for example, instructing the RAN node to support the reception of traffic pattern notifications. Such notifications could be about upcoming bursts. The RAN node can specify its capabilities regarding traffic pattern detection / identification. Examples of such capabilities may include, but are not limited to, the following: whether the RAN node supports receiving updates / changes to the traffic pattern identification configuration; whether the RAN node supports receiving traffic pattern detection / notifications using header information; what types of headers the RAN node can read (e.g., GTP-U, IP); the RAN node's deep packet inspection capabilities; the size of patterns it can detect, identify, or monitor (e.g., the RAN can indicate the maximum size of patterns it supports (e.g., the maximum size of a 2-second long pattern repeating every 5 seconds), as this may be limited by the RAN node's buffer resources); support for inter-flow, inter-PDU session, and inter-user traffic pattern detection (e.g., support for traffic patterns occurring across QoS flows); traffic frequency indicators (e.g., indicating that only high-priority traffic bursts should be reported); and so on.

[0118] like Figure 3As shown in section 3, the WTRU application and AS can negotiate to support, for example, indicating burst arrival time information in the header. The application can negotiate how (e.g., via SDP) flow pattern information can be added to the header field.

[0119] The WTRU can instruct the AS / AF to enable traffic pattern indicator marking on the downlink (e.g., at the AS), for example, for use by the 5GC for network optimization. In scenarios where traffic pattern information may not be included (e.g., not included) in the header field, the WTRU can instruct that traffic pattern detection / identification can be enabled at the 5G system (e.g., at the UPF) (e.g., the AF / AS can request it from the 5G system later).

[0120] like Figure 3 As shown in section 4, the AS / AF can (e.g., via the NEF) inform the PCF that it can use pattern-related information (e.g., burst arrival time information) to mark (e.g., possibly marking) downlink traffic. Alternatively, the AS / AF can request the network (e.g., the UPF) to predict (e.g., independently predict) the start of a burst (e.g., a new burst). Independent prediction can be applied in the UPF if the UPF is unable to extract information from the traffic header to help predict the start of the next traffic burst.

[0121] In scenarios where 5GC predicts and detects traffic patterns (e.g., using AI / ML techniques), AS / AF can specify that traffic can exhibit certain traffic patterns. For example, AS / AF can indicate that traffic may contain bursts.

[0122] like Figure 3 As shown at point 5, the PCF can send a rule (e.g., a PCC rule) to the SMF. This rule (e.g., a PCC rule) can inform the SMF that downlink traffic may include traffic pattern information (e.g., burst arrival time information). The indication in this rule (e.g., the PCC rule) can be in accordance with the SDF. The PCC rule can indicate whether traffic pattern information will be included in the header of the traffic associated with (e.g., each) service data stream.

[0123] like Figure 3 As shown in point 6, SMF can decide whether to enable traffic pattern detection and notification features.

[0124] The Service Flow Detection (SF) can make this decision based on the PCC rules from the Service Flow Detection (PCF). For example, when selecting an appropriate Service Flow Detection (UPF), the UPF can use flow pattern detection criteria (e.g., requirements). The SF can inform the UPF whether to enable the feature based on service requests received from the Service Flow Detection (AF).

[0125] like Figure 3As shown at point 7, SMF can be configured with UPF for, for example, based on (e.g., as...) Figure 3 The flow pattern detection configuration (as shown in point 6) is used to detect flow pattern information.

[0126] The rules in this message (e.g., the N4 rule) can provide the UPF with a Packet Detection Rule (PDR). The UPF can use this rule to identify downlink traffic associated with the PDR. The PDR can then indicate the QoS Enforcement Rule (QER) associated with the traffic.

[0127] The PDR and / or QER can be enhanced to include information about traffic pattern detection / identification, and the actions to be taken when a traffic pattern is detected. For example, it can specify that a header field in a received packet can indicate an approaching traffic burst, and that the UPF can notify the RAN of the approaching traffic burst before the burst arrives at the UPF when that field is read.

[0128] like Figure 3 As shown at point 8, the SMF can configure the RAN. This message can indicate how traffic patterns can be notified to the RAN and the types of traffic patterns that can be notified to the RAN. The SMF can consider the RAN capabilities indicated to the SMF (e.g., such as...). Figure 3 (As shown in point 2).

[0129] This configuration information allows you to specify the granularity of the detected traffic pattern. For example, it can be specified to target service data streams, PDU sessions, QoS streams, or data streams.

[0130] The N2 message may include a QoS profile. This QoS profile may identify one or more SDFs associated with (e.g., each) the QoS flows included in the QoS profile. For (e.g., each) the identified SDF, the QoS profile may indicate whether traffic patterning (e.g., early burst) notification is enabled. For each identified SDF, the QoS profile may indicate how long is expected to elapse between early burst notification and the arrival of the burst.

[0131] The SMF can indicate to the RAN node whether the traffic pattern is reported via GTP-U or via the N2 interface by the SMF. This indication can also be part of the QoS profile.

[0132] This configuration information can specify whether multiple reports occurring in the same time frame can be bundled together into a single message (e.g., reports belonging to multiple traffic pattern detection tasks can be bundled together into one message to minimize signaling). For example, bundling can be performed if the delay or early delivery caused by the bundling of reports (e.g., any) does not reach a certain threshold (e.g., only under the conditions described above).

[0133] If an imminent handover is present and the RAN node is aware of the target base station, the request can instruct that a report should be sent to the specific target base station, for example, once the handover is complete.

[0134] This configuration information can indicate that a report can be sent to more than one RAN node. For example, if a report needs to be sent during an ongoing handover, this can be done, and the report can be sent to both the source and target base stations.

[0135] This configuration information can specify whether traffic pattern notifications must also be sent to (multiple) WTRUs. This can be useful, for example, in scenarios where there are long intervals between traffic bursts and WTRUs use this information to optimize computing resources (e.g., Dynamic Voltage and Frequency Scaling (DVF) – adjusting CPU frequency to reduce power consumption), resulting in reduced energy consumption. For instance, WTRUs might use this notification to determine when to begin waking from sleep mode or when to increase the energy and computing resources allocated to certain tasks.

[0136] like Figure 3 As shown at point 9, a traffic burst can reach the UPF.

[0137] like Figure 3 As shown at point 10, the UPF can detect specific traffic patterns / bursts. For example, the UPF can detect traffic patterns based on traffic tags or header fields or through traffic analysis (e.g., based on AI / ML traffic models received by the AF). It is possible to detect one or more of the following attributes of the traffic pattern: how long until the next packet or the next burst (e.g., in milliseconds); how many times or for how long the pattern can repeat; dependencies between traffic within a data stream, between data streams, between QoS streams, and between PDU sessions / devices / users (e.g., header fields can indicate that the next burst may occur in another QoS stream; this can specify whether the same burst pattern experienced at the current QoS stream is likely to be experienced in another QoS stream within 2 ms); the start and end of the traffic pattern; any changes to the current pattern (e.g., if only the interval between bursts can change from 2 ms to 1 ms, this can be indicated in the header fields of (multiple) packets); the average and variance of the burst period / length / size; the number of sub-streams present in the stream; the codecs being used and their settings; and the importance level of the traffic (e.g., if importance level information is available in the header at the PDU, it can be detected and used later).

[0138] like Figure 3As shown at 11, before a second flow pattern (e.g., burst) arrives or is detected, the UPF can send a notification to the RAN via GTP-U that a specific flow pattern (e.g., burst) is expected.

[0139] like Figure 3 As shown at point 12, the UPF can inform the SMF (which will be sent to the RAN) when the next traffic pattern (e.g., a burst) is expected. This can be sent along with the current burst or after the current burst has completed.

[0140] like Figure 3 As shown at point 13, the SMF can indicate to the RAN (e.g., send to the RAN) when the next traffic pattern (burst) is expected.

[0141] SMF can instruct RAN nodes whether to forward traffic pattern report messages to (multiple) WTRUs.

[0142] like Figure 3 As shown at 14, the RAN node can configure / activate user plane resources for it before the second traffic pattern (e.g., burst) arrives.

[0143] This article can perform and / or describe UPF actions.

[0144] The UPF can receive N4 rules from the SMF (e.g., as described herein). The N4 rules can provide the UPF with Packet Detection Rules (PDRs). The UPF uses the information in the PDRs to identify the downlink traffic associated with the PDRs. The PDRs can indicate the QoS Enforcement Rules (QERs) associated with the traffic. The QERs can be used to determine which QoS flow the downlink traffic should be assigned to.

[0145] QER and / or PDR can instruct UPF (e.g., be enhanced to instruct) that UPF should send a burst expectation notification to the RAN node.

[0146] QER or PDR can indicate (e.g., be enhanced to indicate) how the UPF should detect when a burst is expected. For example, QER or PDR can indicate the protocol type or header field type that can be included in the traffic and can be used to determine when a burst can be expected.

[0147] The QER or PDR can indicate (e.g., be enhanced to indicate) the time range until the next burst (e.g., the next burst is within less than 6 ms, 6 to 20 ms, or greater than 20 ms). The QER or PDR can indicate to the UPF (e.g., if traffic matching the information in the QER or PDR is detected) that the timing information provided in the QER or PDR can be used to estimate when the next data burst will arrive.

[0148] QER or PDR can indicate (e.g., be enhanced to indicate) the exact time of the next burst (e.g., the time to the next burst can be expressed in milliseconds or seconds). QER or PDR can indicate to UPF (e.g., if traffic matching the information in QER or PDR is detected) that the timing information provided in QER or PDR can be used to estimate when the next data burst will arrive.

[0149] The QER or PDR may include information about how to convert header values ​​into time values ​​(e.g., to enhance the data). For example, this information could be a time scale value that indicates the header field value should be multiplied (e.g., multiplied by 3 ms) to obtain the expected start time of the next burst.

[0150] QER or PDR may include information about how to predict traffic bursts in a data stream / SDF based on information from another data stream / SDF (PDU set, burst information) (e.g., to use that information for enhancement). For example, a burst in a data stream may be temporally related to one or more other data streams. For instance, it may be that a burst in one data stream / SDF may be followed by a burst in another data stream / SDF.

[0151] QER or PDR may include information about how to predict traffic bursts in a PDU session, device, or user's traffic based on traffic in another PDU session, device, or user's traffic (e.g., using that information for enhancement). For example, a burst in a PDU session may be temporally related to one or more other PDU sessions. For instance, in a multi-user gaming application, it might be that one user's actions affect the game state, which in turn affects the state of other users. Therefore, a burst in a PDU session may follow a burst in traffic from another PDU session or user.

[0152] For example, if (e.g., when) the UPF receives a PDU and that PDU includes a burst end indication, the PDU may include a Next Burst Time header field. The UPF can use the information in that Next Burst Time header field to determine when the next burst is expected to begin.

[0153] UPF can send the PDU to the RAN node in a GTP-U message. The GTP-U message may include information from the next burst time header, or it may include the amount of time expected to elapse before the start of the next burst.

[0154] The UPF can track time (e.g., via a configured timer). This time can be associated with a value equal to or less than the amount of time expected to elapse before the next burst begins (e.g., setting a timer to a value). The UPF can send a GTP-U message to the RAN node to indicate the expected burst start, for example, if (e.g., when) the time is about to expire or has already expired (e.g., the timer is about to expire or has already expired). For example, if no user plane packets are available for transmission between the UPF and the RAN node, the UPF can send an empty GTP-U PDU to the RAN node, or the UPF can send a virtual packet to the RAN node.

[0155] This document may perform and / or describe RAN actions.

[0156] The SMF can configure the RAN to receive traffic pattern notifications (e.g., as described herein). The configuration message sent by the SMF can indicate how traffic patterns can be notified to the RAN, as well as information about the type of traffic pattern that will be notified to the RAN.

[0157] This configuration information can be sent from the SMF to the RAN in a message (e.g., an N2 message). The N2 configuration message may include a QoS profile. This QoS profile can indicate to the RAN whether it can enable the reception of traffic pattern detection or traffic pattern notifications at a specified granularity level (e.g., SDF, QoS flow).

[0158] Configuration messages sent from SMF to RAN may include one or more of the following information.

[0159] Configuration messages can instruct the RAN on how to detect traffic pattern notifications. For example, the message can indicate the header field type that will be included in the traffic and can be used to determine when a burst is expected and the length of the burst that will follow.

[0160] Configuration messages can indicate how header values ​​in a notification should be converted to time values. For example, this information could be a time scale value that indicates header field values ​​should be multiplied (e.g., multiplied by 3 ms) to obtain the expected start time of the next burst.

[0161] Configuration messages can instruct how to predict traffic bursts in a data stream / SDF based on information from another data stream / SDF (e.g., PDU set, burst). For example, a burst in a data stream may be temporally related to one or more other data streams. For instance, a burst in one data stream / SDF might be followed by a burst in another data stream / SDF.

[0162] Configuration messages can instruct how to predict traffic bursts within a PDU session, device, user, QoS stream, or data stream based on traffic from another PDU session, device, user, or data stream. For example, a burst in a PDU session might be temporally related to one or more other PDU sessions. In a multi-user gaming application, for instance, a user's actions might affect the game state, which in turn affects the state of other users. Therefore, a burst in a PDU session could follow a burst in traffic from another PDU session or user.

[0163] UPF can ensure that duplicate traffic pattern notifications are not sent (e.g., instructions on how to convert header values ​​in a notification to time values, or instructions on how to predict traffic bursts in a data stream / SDF based on information from another data stream / SDF). For example, if a traffic pattern in a stream is detected based on a notification received for another stream, a second notification is not needed.

[0164] Configurations similar to those sent from the SMF to the RAN can be sent to the WTRU (e.g., forwarded to the WTRU via the RAN node and / or sent directly to the WTRU from the core network via NAS messages). This allows the WTRU to detect XR traffic patterns in the uplink generated within the WTRU and notify the RAN node accordingly. For example, based on the messages received with the configuration, the WTRU can better time / adapt its resource requests to the RAN node. For instance, the WTRU can use information about the uplink traffic pattern to send Buffer Status Reports (BSRs) and / or pre-send BSRs at the correct time and using indexes in the BSR table indicating the correct amount of data.

[0165] RAN nodes can receive GTP-U packets from the UPF. GTP-U packets may or may not include PDUs. GTP-U messages may include information that the RAN node can use to predict when a data burst (e.g., a new data burst) will arrive at the RAN node. For example, the header of the GTP-U message may include a field indicating how much time is expected before the burst (e.g., a new burst) arrives. The RAN node can use configuration information received from the SMF to convert the header field values ​​into a duration. Based on the determined duration, the RAN node can determine when to activate the user plane resources required to send data to the WTRU.

[0166] In the example, a RAN node can generate and send traffic pattern reports to one or more other RAN nodes. For example, a RAN node can receive or detect traffic patterns that may be related to traffic belonging to another RAN node. Therefore, unlike the notifications sent by the SMF or UPF, the configured RAN node can send traffic pattern notifications to the affected / related RAN nodes. For example, if a traffic pattern is reported on GTP-U, the RAN node can begin reading the GTP-U packet headers for the specified traffic (e.g., a specific application).

[0167] Information in configuration messages (e.g., observable time intervals between traffic bursts) and dynamically received notifications can be used by the RAN for various optimization tasks. For example, the RAN can use traffic bursts and inactive periods for one or more of the following.

[0168] The RAN can use traffic bursts and inactive periods for power optimization processes (e.g., connection mode DRX settings and timing for power management settings, e.g., via timers). Information in configuration messages can allow RAN nodes to configure DRX cycles (e.g., the length of the onDuration timer within a DRX cycle and / or apply a time offset to the start of the DRX cycle and / or the start of the onDuration timer within a DRX cycle) to better align the DRX cycle with the arrival of downlink traffic.

[0169] RAN can utilize traffic bursts and inactive periods for better resource management at RAN nodes. For example, information in configuration messages can allow RAN nodes to configure semi-persistent scheduling (SPS) in WTRU accordingly (e.g., SPS license size, SPS license frequency).

[0170] The RAN can use traffic bursts and inactivity periods to ensure that the WTRU is woken up during an upcoming burst. For example, during the last CDRX cycle of the WTRU before the upcoming burst arrives, the RAN node can send DL traffic or virtual DL traffic to the WTRU. This can have the effect of triggering CDRX inactivity periods (e.g., via an inactivity timer), keeping the WTRU awake until the desired burst time. Alternatively, the RAN node can send an RRC message to the WTRU just before the upcoming burst, which, for example, configures the WTRU to be awake during the burst arrival.

[0171] The RAN can use flow bursts and inactivity periods to align measurement configurations (e.g., measurement gap patterns for performing intra-frequency and / or inter-frequency measurements in FR1 and FR2), for example, such that the timing in which the WTRU is configured to perform measurements (e.g., any timing) does not overlap with the timing of expected delivery of (e.g., new) flow (e.g., each new flow pattern). For example, such reconfiguration of (multiple) measurement patterns can be pre-done based on perception of new flow pattern attributes (e.g., the start / end of a new flow pattern).

[0172] During RAN-level congestion, it can be beneficial for RAN nodes to be aware of upcoming traffic that is a data burst of a certain size and expected duration. The RAN can use this notification (e.g., along with parameters such as the priority of the QoS flow to which the burst belongs) to preemptively drop packets belonging to other QoS flows or service data flows even before the burst begins to arrive at the RAN, thus leveraging the notification.

[0173] RAN can use traffic bursts and inactivity periods to predict uplink traffic. For example, there can be downlink bursts that follow uplink bursts in traffic patterns, and vice versa.

[0174] In the example, the RAN can request the SMF to change the settings / attributes of traffic pattern reports. This configuration can specify the desired frequency and interval of reports (e.g., only notifying high-importance bursts), and whether multiple reports occurring in the same time frame can be bundled into a single message (e.g., reports belonging to multiple traffic pattern detection tasks can be bundled into one message to minimize signaling). For example, in a scenario where too many reports are received at the RAN node, consuming excessive resources, the RAN node can request the SMF to bundle multiple reports (belonging to the same application or user) or stop notifying low-priority traffic bursts with backoff times (e.g., via timers).

[0175] In the example, the RAN can request the SMF to start and stop reporting. For instance, it can request to stop reporting when there are too many reports and they are consuming too many resources.

[0176] If there is an approaching or ongoing handover and the RAN node is aware of the target base station, the source RAN node can forward the early traffic pattern report received at the source RAN to the target RAN node until the handover is complete.

[0177] If there is an approaching or ongoing handover and the RAN node is aware of the target base station, the source RAN node can send traffic pattern detection or reporting information to the target RAN node before the handover is completed.

[0178] In some scenarios, the RAN can reconfigure or start / stop certain functionalities or configurations at the AS / WTRU based on traffic pattern reports. For example, the RAN can activate / deactivate one or more component carriers when the WTRU is configured with CA, enabling DL traffic to be transmitted at higher / lower bandwidths based on expected changes in the traffic pattern. In another example, the RAN can reconfigure the QoE reporting configuration in the WTRU (e.g., update application buffer thresholds, reporting periodicity) based on expected changes in the current traffic pattern and / or information about dependencies between flows.

[0179] This article can perform and / or describe burst prediction in networks.

[0180] This article can perform and / or describe UPF actions.

[0181] The UPF can receive N4 rules from the SMF. The QER or PDR in the N4 rules can indicate to the UPF (e.g., be enhanced to indicate) that the UPF can (e.g., should) send a burst expectation notification to the RAN node.

[0182] QER or PDR can indicate (e.g., be enhanced to indicate) how the UPF should detect when a burst can be expected. For example, QER or PDR can indicate the protocol type or header field type that will be included in the traffic and can be used to determine when a burst can be expected.

[0183] QER or PDR may include information about how to convert header values ​​into time values ​​(e.g., to enhance the data). For example, this information could be a time scale value that indicates whether header field values ​​can (e.g., should) be multiplied (e.g., multiplied by 3 ms) to obtain the expected start time of the next burst.

[0184] QER or PDR may include information about how to predict (e.g., use that information for enhancement) traffic bursts in a data stream / SDF based on information from another data stream / SDF (e.g., PDU set, burst). For example, a burst in a data stream may be temporally related to one or more other data streams. For instance, it may be a situation where a burst in one data stream / SDF may be followed by a burst in another data stream / SDF.

[0185] QER or PDR may include information about how to predict traffic bursts in a PDU session, device, or user's traffic based on traffic in another PDU session, device, or user's traffic (e.g., using that information for enhancement). For example, a burst in a PDU session may be temporally related to one or more other PDU sessions. For instance, in a multi-user gaming application, it might be that one user's actions affect the game state, which in turn affects the state of other users. Therefore, a burst in a PDU session may follow a burst in traffic from another PDU session or user.

[0186] UPF can, for example, detect impending bursts based on QER / PDR parameters.

[0187] UPF can send a GTP-U notification to the RAN to warn the RAN of an impending burst. The GTP-U message may include information from the next burst time header, or it may include the amount of time expected to elapse before the next burst begins.

[0188] This document may perform and / or describe RAN actions.

[0189] The RAN can receive traffic pattern configuration information from the SMF. This configuration information can be sent from the SMF to the RAN in an N2 message.

[0190] This configuration message can instruct the RAN on how to detect flow pattern notifications.

[0191] This configuration message can indicate how to convert header values ​​in a notification into time values.

[0192] This configuration message can indicate how to predict traffic bursts in a data stream / SDF based on the (PDU set, burst) information of another data stream / SDF.

[0193] Configuration messages can indicate how to predict traffic bursts in a PDU session, device, or user, or in a QoS stream or data stream, based on traffic from another PDU session, another device, another user, or traffic in a QoS stream or data stream.

[0194] The RAN can use the received configuration for various optimization tasks. For example, the RAN can use traffic bursts and inactive periods for power optimization processes (e.g., connection mode DRX settings and timers can be example power management settings).

[0195] In the example, a RAN node can generate a traffic pattern report and send it to one or more other RAN nodes (e.g., the same traffic is sent to another user connected to the application via another RAN node).

[0196] In the example, the RAN can request the SMF to change the settings / attributes of traffic pattern reporting. For instance, the RAN can request to stop reporting for low-priority traffic patterns using a backoff timer value.

[0197] If an imminent or ongoing handover exists, the source RAN node can forward early traffic pattern reports received at that source RAN node to the target RAN node until the handover is complete. The source RAN node can send traffic pattern detection or reporting information to the target RAN node before the handover is complete.

[0198] Changes in the flow pattern can be dynamically detected and / or reported to the WTRU.

[0199] Figure 4 The illustration shows an example of the process for enabling the detection of flow pattern changes and dynamic reporting to the WTRU.

[0200] like Figure 4 As shown at point 1, WTRU-hosted applications can receive SDP messages from the AS / AF. These SDP messages can instruct the AS / AF to support sending data with a PDU set header extension. The SDP messages can also instruct the AS to support receiving information about network-shared devices, and the AS / AF to support sending traffic pattern reports (e.g., early burst indicator reports), as well as traffic reports associated with traffic sent to or from WTRU-hosted applications or network-shared devices.

[0201] like Figure 4 As shown at point 2, WTRU-hosted applications can send SDP messages to the AS / AF. If the application server instructs the AS / AF to support dynamic traffic pattern reporting, this message can indicate that dynamic traffic patterns will be enabled for applications, PDU sessions, QoS flows, or data flows. This message can include reporting criteria (e.g., reporting when the interval between bursts exceeds 10 ms), frequency (e.g., reporting before each burst arrives at the WTRU), and reporting method (e.g., via traffic tagging).

[0202] like Figure 4 As shown in point 3, AS / AF can enable flow pattern reporting via flow markers.

[0203] like Figure 4As shown in section 4, the AS / AF can inform the PCF (e.g., via the NEF) that it may be marking downlink traffic with pattern-related information (e.g., burst arrival time information). This message can instruct the RAN to forward the traffic pattern information to the WTRU. This message can also indicate that dynamic traffic patterns can be enabled for specific applications, PDU sessions, QoS flows, or data flows. This message can include reporting criteria (e.g., reporting when the interval between bursts exceeds 10 ms), frequency (e.g., reporting before each burst arrives at the UE), and reporting method (e.g., via traffic marking).

[0204] like Figure 4 As shown in section 5, the PCF can generate PCC rules. The rules generated for the RAN can instruct that traffic pattern information can be sent to the WTRU, for example, according to the requested configuration (e.g., regarding...). Figure 4 As shown in 2).

[0205] like Figure 4 As shown at point 6, the PCF can send a PCC rule to the SMF. This PCC rule informs the SMF that downlink traffic can include traffic pattern information (e.g., burst arrival time information), and the RAN can be configured (e.g., via RRC) to send traffic pattern notifications to the WTRU. This message can include notification configuration information, such as reporting frequency and criteria.

[0206] like Figure 4 As shown in point 7, the SMF can determine whether to enable traffic pattern detection and notification features. The SMF can also determine where traffic pattern detection occurs, such as at the UPF or RAN.

[0207] like Figure 4 As shown at point 8, the SMF can send a configuration message to the RAN to enable traffic pattern reporting to the WTRU. This message can indicate how to receive traffic pattern indications / notifications (e.g., header field values) at the RAN.

[0208] This message can indicate whether the RAN can detect traffic patterns, (e.g., receive traffic pattern notifications from the UPF), or both.

[0209] This message can instruct the RAN what to do when it receives a traffic pattern notification or detects a traffic pattern (e.g., from the UPF via GTP-U). For example, it can instruct the RAN to send the received traffic pattern notification to the WTRU via RRC, or to create a traffic pattern notification based on the detected traffic pattern and send it to the WTRU.

[0210] like Figure 4 As shown at position 9, the RAN can enable flow pattern notification to the WTRU.

[0211] like Figure 4 As shown at point 10, the RAN can receive traffic pattern reports from the UPF or from the SMF (e.g., as described herein) via GTP-U.

[0212] like Figure 4 As shown at point 11, the RAN can send a flow pattern report to the WTRU containing received information about the flow pattern (e.g., burst information).

[0213] In the example, a RAN node can generate a traffic pattern report and send it to one or more WTRUs. For example, a traffic burst belonging to (e.g., one) WTRU may be associated with a traffic pattern of another WTRU (e.g., as described herein). A RAN node can receive traffic pattern notifications or detect (e.g., one) WTRU's traffic pattern, which may be associated with traffic belonging to a second WTRU. Therefore, the configured RAN node can send traffic pattern notifications to other affected / associated WTRUs instead of those notifications being sent by the AF or UPF.

[0214] Traffic pattern reports can be RRC messages that indicate to the RAN that downlink data for PDU sessions, QoS flows, or service data flows is expected soon. The report can also provide an indication of how much time has passed before a burst occurs. Alternatively, information / indications associated with traffic pattern reports can be provided to the WTRU via DL MAC CE or DCI.

[0215] like Figure 4 As shown at point 12, the WTRU can use information from the reports for various resource optimization tasks. For example, traffic burst information can be used to prepare network-sharing connectivity for devices connected to other networks. By activating the connection to the network-sharing device before receiving data, jitter can be reduced. Examples of network-sharing connections can include Bluetooth devices. This can be useful, for example, in scenarios where there are long intervals between traffic bursts and the WTRU uses this information to optimize computing resources (e.g., dynamic frequency scaling), thereby reducing energy consumption.

[0216] In the example, when the WTRU is configured for Mode 2 operation on the side link, the WTRU can trigger a resource (re)selection process to determine and / or reserve sufficient radio resources on the side link so that bursts received in the DL can be relayed with low latency to network-shared devices. This resource (re)selection can be triggered based on a traffic pattern report provided by the RAN node to the WTRU. For example, if the traffic pattern report indicates a long gap before the burst arrives, the WTRU can (e.g., alternatively) release either the selected or pre-configured resources on the side link.

[0217] This article can perform and / or describe burst prediction in WTRU.

[0218] This article can perform and / or describe WTRU actions.

[0219] WTRU-hosted applications can receive SDP messages from the AS / AF. These SDP messages can instruct the AS / AF to support sending data with a PDU set header extension.

[0220] Applications hosted by WTRU can send SDP messages to AS / AF to indicate that dynamic traffic patterns will be enabled for applications, PDU sessions, QoS flows, or data flows.

[0221] The WTRU can receive traffic pattern notification reports. These reports can be RRC messages, which indicate to the WTRU that downlink data for a PDU session, QoS flow, or service data flow is expected soon.

[0222] WTRU can use information from reports to make resource activation decisions. For example, traffic burst information can be used to prepare network sharing connectivity for devices on other network shares. By activating connections to network-shared devices before data is received, jitter can be reduced.

[0223] WTRU can use activated resources to receive and process data, or use activated network shared connections to send data.

[0224] This document may perform and / or describe RAN actions.

[0225] The RAN can receive a configuration message from the SMF requesting that traffic pattern reception be enabled at the RAN. This message can indicate how to receive traffic pattern indications / notifications at the RAN (e.g., header field values). This message can also indicate what the RAN can do when it receives a traffic pattern notification or detects a traffic pattern (e.g., from the UPF via GTP-U). For example, it can instruct the RAN to send the received traffic pattern notification to the WTRU via RRC, or to create and send a traffic pattern notification based on a detected traffic pattern to the WTRU.

[0226] The RAN can enable flow pattern notification to the WTRU.

[0227] The RAN can (e.g., via GTP-U) receive traffic pattern reports from the UPF or can detect traffic patterns.

[0228] The RAN can send a traffic pattern report to the WTRU containing information about the received traffic pattern (e.g., burst information). This report can indicate the QoS flow, PDU session, or SDF associated with the expected burst.

[0229] This article can execute and / or describe multiplexed data streams.

[0230] Traffic pattern notifications can be sent for specific applications, PDU sessions, QoS flows, or data flows. Depending on the specified notification level, the RAN or WTRU can derive the traffic pattern associated with the corresponding QoS flow or PDU session. For example, a traffic pattern notification can specify (e.g., only) a traffic pattern associated with a data flow or SDF. However, in cases where multiple data flows or SDFs are multiplexed, further processing may be performed (e.g., required) to derive the traffic pattern for the QoS flow. For example, the RAN or WTRU can determine the start of the next burst of the QoS flow as the shortest time to the next burst among all data flows or SDFs in the QoS flow.

[0231] This article describes the interaction between NWDAF and UPF.

[0232] UPF can obtain burst forecast information from NWDAF. This forecast information can indicate when a burst is expected to arrive.

[0233] For example, a UPF can invoke a service from an NWDAF. During the service invocation, the UPF can provide the NWDAF with statistics or information about the QoS flow or SDF. This information may include a protocol description received from the SMF in the N4 rule. This information may indicate the identity of the RAN node servicing the QoS flow or SDF. The statistics may include information about the burst size and burst arrival time associated with the QoS flow or SDF. During the service invocation, the UPF can instruct the NWDAF to request a prediction of the burst arrival time on the QoS flow or SDF. The type of prediction can be indicated by providing an AnalyticsID value when the service is invoked.

[0234] UPF can periodically provide statistical data to NWDAF.

[0235] NWDAF can use statistics and information to determine burst time predictions, which represent the expected arrival time of a burst for a QoS flow or SDF.

[0236] NWDAF can send prediction information to UPF, enabling UPF to send burst notifications to RAN nodes.

[0237] Alternatively, NWDAF can send forecast information to the RAN node to notify the RAN that a burst has been anticipated.

[0238] Predictive information may include burst time value, burst size value, and associated QoS flow ID or SDF ID.

[0239] This article describes the interaction between NWDAF and RAN nodes.

[0240] RAN nodes can obtain burst prediction information from NWDAF. This prediction information can indicate when a burst is expected to arrive.

[0241] For example, a RAN node can invoke NWDAF services. During the service invocation, the RAN node can provide NWDAF with statistics or information about the QoS flow. This information may include QoS profile information received from the SMF and the PDU session ID in the N2 message. Information may indicate the identity of the UPF serving the QoS flow. Statistics may include information about the burst size and burst arrival time associated with the QoS flow. During the service invocation, the RAN node can instruct NWDAF to request a prediction of the burst arrival time on the QoS flow. The type of prediction can be indicated by providing an Analytics ID value when the service is invoked.

[0242] RAN nodes can periodically provide statistical data to NWDAF.

[0243] The NWDAF can also collect statistics about QoS flows from the UPF. The NWDAF can use the UPF ID, QoS flow ID, and PDU session ID received from the RAN node to indicate to the UPF which flows it wants to collect statistics about. The UPF can then periodically provide the statistics to the NWDAF.

[0244] NWDAF can use statistics and information from RAN nodes and UPF to determine burst time predictions, which represent the expected arrival time of bursts for QoS flows.

[0245] NWDAF can send prediction information to RAN nodes, enabling RAN nodes to begin activating user plane resources associated with QoS flows before bursts arrive at RAN nodes.

[0246] Predictive information may include burst time value, burst size value, and associated QoS flow ID.

[0247] Non-3GPP access could be considered.

[0248] The RAN node described in this document can be an N3IWF or a TNGF. The N3IWF or TNGF can send downlink data to the WTRU via a Wi-Fi connection. If the N3IWF or TNGF receives a GTP-U message from the UPF indicating that a data burst for the WTRU will arrive soon, the N3IWF or TNGF can choose not to grant a transmission opportunity to a station in the Wi-Fi network (e.g., the WTRU) until the burst arrives and is transmitted. The Hybrid Coordination Function (HCF) associated with the N3IWF or TNGF can choose not to grant transmission opportunities (TXOPs) that overlap with the expected data burst.

[0249] Although features and elements are provided above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. This disclosure is not limited to aspects of the specific embodiments described in this application, which are intended as illustrative of various aspects. Many modifications and variations can be made without departing from its spirit and scope, as will be apparent to those skilled in the art. Unless expressly provided so, no element, action, or instruction used in the specification of this application should be construed as critical or essential to the invention. Based on the foregoing description, functionally equivalent methods and apparatus within the scope of this disclosure, other than those listed herein, will be apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the terms of the appended claims and the full scope of equivalents conferred by such claims. It is to be understood that this disclosure is not limited to specific methods or systems.

[0250] For simplicity, the foregoing embodiments will be discussed in terms of the terminology and structure of infrared-capable devices (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0251] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is 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 multiple images displayed on a time-based 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 the various embodiments of a WTRU; (iii) in particular a device configured with some or all of the structure and functions of a WTRU and having wireless and / or wired capabilities (e.g., tetherable); (iv) a device configured with less than all the structure and functions of a WTRU and having wireless and / or wired capabilities; or (iv) the like. Figure 1A-1DDetails of an example WTRU, which may represent any WTRU described herein, are provided. As another example, various disclosed embodiments herein are described using a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be utilized, and some or all of the embodiments disclosed herein and the various disclosures can be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information for providing an adapted, realistic experience.

[0252] Furthermore, the methods described herein can be implemented in computer programs, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROMs and Digital Universal Discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, MME, EPC, AMF, or any host computer.

[0253] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the following claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery and the like) that provides any suitable voltage.

[0254] Furthermore, in the embodiments provided above, references to 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 can be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as being “executed,” “computer-executed,” or “CPU-executed.”

[0255] Those skilled in the art will understand that the actions and symbols representing operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits that can cause a transformation or reduction of electrical signals and the maintenance of data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the operation of the CPU and other signal processing. The memory location where the data bits are maintained is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the platforms or CPUs mentioned above, and other platforms and CPUs may support the provided methods.

[0256] Data bits can also be stored on a computer-readable medium, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system. The computer-readable medium can include cooperative or interconnected computer-readable media that are uniquely present on the processing system or distributed across multiple interconnected processing systems that may be local to the processing system or remotely. It should be understood that the embodiments are not limited to the memories mentioned above, and other platforms and memories may support the provided methods.

[0257] In illustrative embodiments, any of the operations, processes, etc., described herein can be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions can be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0258] There is little difference between the hardware and software implementations of various aspects of the system. The use of hardware or software typically (but not always, as the choice between hardware and software may become important in certain contexts) represents a design choice that represents a cost-efficiency trade-off. Various carriers (e.g., hardware, software, and / or firmware) may exist through which the processes and / or systems and / or other technologies described herein can be implemented, and the preferred carrier may vary depending on 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 of paramount importance, the implementer may choose a primarily hardware and / or firmware carrier. If flexibility is of paramount importance, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0259] The foregoing detailed description has illustrated various embodiments of the apparatus and / or processes using block diagrams, flowcharts, and / or examples. Where such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide variety of hardware, software, firmware, or virtually any combination thereof. In embodiments, several portions of the subject matter described herein can be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other forms of integration. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be implemented, in whole or in part, equivalently in an integrated circuit as one or more computer programs running on one or more computers (e.g., implemented as one or more programs running on one or more computer systems), implemented as one or more programs running on one or more processors (e.g., implemented as one or more programs running on one or more microprocessors), implemented as firmware, or implemented as virtually any combination thereof, and that designing circuitry and / or writing code for software and / or firmware in accordance with this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein can be distributed as a variety of program products, and the illustrative embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media, such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic 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.).

[0260] Those skilled in the art will recognize that it is common practice in the art to describe devices and / or processes in the manner set forth herein, and subsequently to integrate such described devices and / or processes into data processing systems through engineering practice. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable number of experiments. Those skilled in the art will recognize that a typical data processing system typically includes one or more of the following: a system unit housing, a video display device, memory (such as volatile and non-volatile memory), a processor (such as a microprocessor and a digital signal processor), computing entities (such as an operating system, drivers, a graphical user interface, and applications), one or more interactive devices (such as a touchpad or touchscreen), and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or speed, control motors 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 those commonly found in data computing / communication and / or network computing / communication systems.

[0261] The topics described herein sometimes refer to different components included within or connected to different other components. It should be understood that such depicted architectures are merely examples, and many other architectures can indeed achieve the same functionality. Conceptually, any arrangement of components that achieve the same functionality is effectively “associated” to enable the desired functionality. Therefore, any two components combined in this document to achieve a particular function can be considered “associated” with each other to enable the desired functionality, regardless of the architecture or intermediate components. Similarly, any two components so associating can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be so associating can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of operational coupling include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or logically interact and / or logically interact.

[0262] Regarding the use of virtually any plural and / or singular terms in this document, those skilled in the art can appropriately convert from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural permutations may be explicitly described herein.

[0263] Those skilled in the art will understand that, in general, the terminology used herein, and particularly in the appended claims (e.g., the body of the appended claims), is intended to be “open-ended” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will further understand that if it is intended to introduce a specific number of claim statements, such an intention will be explicitly stated in the claims, and without such a statement, such an intention does not exist. For example, the term “single” or similar language may be used where only one item is intended. To aid understanding, the appended claims and / or the description herein may include the use of the introductory phrases “at least one” and “one or more” to introduce claim statements. However, the use of such phrases should not be construed as implying that a claim statement introduced by the indefinite article “a” or “an” will limit any particular claim that includes such an introduced claim statement to only one embodiment of such a statement, even when the same claim includes the introductory phrase “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 applies to the use of definite articles used to introduce claim statements. Furthermore, even if a specific number of introduced claim statements are explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the number stated (e.g., in the absence of other modifiers, a bare statement of “two statements” means at least two statements, or two or more statements). Furthermore, in instances where the convention of "at least one of A, B, and C" is used, generally, in the sense that a person skilled in the art would understand, the intended construction is such that (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C, etc.). In instances where the convention of "at least one of A, B, or C" is used, generally, in the sense that a person skilled in the art would understand, the intended construction is such that (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C, etc.). Those skilled in the art will further understand that, in fact, any extractive terms and / or phrases presenting two or more alternative terms in the specification, claims, or drawings should be understood to include the possibility of including one term, any one of the terms, or both terms.For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”. Furthermore, as used herein, the term “any one of…” followed by a list of multiple items and / or categories of multiple items is intended to include items alone or in combination with other items and / or categories of items, “any one of,” “any combination,” “any multiple,” and / or “any combination of multiples of.” Additionally, as used herein, the term “set” is intended to include any number of items, including zero. Furthermore, as used herein, the term “quantity” is intended to include any quantity, including zero. And as used herein, the term “many” is intended to be synonymous with “multiple.”

[0264] Furthermore, where features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member or subgroup of the Markush Group.

[0265] As those skilled in the art will understand, for any and all purposes (such as for providing a written description), all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily identified as sufficiently descriptive and such that the same scope can be divided into at least two equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily divided into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, all language such as “up to,” “at least,” “greater than,” “less than,” and the like includes the stated number and refers to a scope that can subsequently be divided into subscopes as discussed above. Finally, as those skilled in the art will understand, a scope includes each individual number. Thus, for example, a group having 1-3 units means a group having 1, 2, or 3 units. Similarly, a group having 1-5 units means a group having 1, 2, 3, 4, or 5 units, and so on.

[0266] Furthermore, unless otherwise stated, the claims should not be construed as limited to the order or elements provided. Additionally, the use of the term "means for..." in any claim is intended to invoke the claim format of 35 USC §112, ¶6 or means plus function, and any claim without the term "means for..." is not intended to be so.

[0267] By way of example, suitable processors include general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs); field-programmable gate array (FPGA) circuits, any other type of integrated circuit (IC) and / or state machine.

[0268] WTRU can be used in conjunction with hardware and / or software-implemented modules, including software-defined radio (SDR) and other components such as cameras, video camera modules, videophones, speakerphones, vibration devices, speakers, microphones, TV transceivers, hands-free headsets, keyboards, Bluetooth® modules, FM radio units, near field communication (NFC) modules, liquid crystal display (LCD) units, organic light-emitting diode (OLED) display units, digital music players, media players, video game console modules, internet browsers, and / or any wireless local area network (WLAN) or ultra-wideband (UWB) modules.

[0269] Although various embodiments of the communication system have been described, it is foreseeable that the system can be implemented using software on a microprocessor / general-purpose computer (not shown). In some embodiments, one or more functions of various components can be implemented using software that controls the general-purpose computer.

[0270] Furthermore, although the invention has been illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications to the details may be made within the scope and equivalents of the claims without departing from the invention.

Claims

1. A first network device, the first network device comprising: The processor is configured as follows: Receive a configuration message from a second network device that includes traffic pattern configuration rule information, wherein the traffic pattern configuration rule information includes at least one of Quality of Service Enforcement (QER) rules or Packet Detection (PDR) rules; Receive downlink data; Based on the configuration message and the downlink data, at least one upcoming data traffic burst is detected; as well as Send a notification of the upcoming data traffic surge to a third network device.

2. The first network device according to claim 1, wherein the first network device is a User Plane Function (UPF) node, and wherein the second network device is a Session Management Function (SMF) node.

3. The first network device of claim 1, wherein the third network device is a radio access network (RAN) node, and wherein notification of the upcoming data traffic burst is sent using General Packet Radio Service Tunneling Protocol User Plane (GTP-U) messages.

4. The first network device of claim 1, wherein the header of the GTP-U message indicates information associated with the upcoming data traffic burst.

5. The first network device according to claim 1, wherein the first network device is a User Plane Function (UPF) node, wherein the second network device is a Session Management Function (SMF) node, and wherein the third network device is the second network device.

6. The first network device according to claim 1, wherein the processor is further configured to: Based on the configuration message and the downlink data, a burst size associated with the at least one upcoming data traffic burst is determined, wherein the notification of the upcoming data traffic burst indicates the determined burst size.

7. The first network device according to claim 1, wherein the processor is further configured to: Based on the configuration message and the downlink data, an expected start time associated with the at least one upcoming data traffic burst is determined, wherein the notification of the upcoming data traffic burst indicates the determined expected start time.

8. The first network device according to claim 1, wherein the configuration message indicates traffic pattern detection configuration information, wherein the traffic pattern detection configuration information is associated with detecting traffic bursts.

9. The first network device according to claim 1, wherein the configuration message is received via the N4 interface.

10. The first network device of claim 1, wherein the configuration message indicates the transmission of information associated with the upcoming data traffic burst.

11. A method performed by a first network device, the method comprising: Receive a configuration message from a second network device that includes traffic pattern configuration rule information, wherein the traffic pattern configuration rule information includes at least one of Quality of Service Enforcement (QER) rules or Packet Detection (PDR) rules; Receive downlink data; Based on the configuration message and the downlink data, at least one upcoming data traffic burst is detected; as well as Send a notification of the upcoming data traffic surge to a third network device.

12. The method of claim 11, wherein the first network device is a User Plane Function (UPF) node, and wherein the second network device is a Session Management Function (SMF) node.

13. The method of claim 11, wherein the third network device is a radio access network (RAN) node, and wherein notification of the upcoming data traffic burst is sent using General Packet Radio Service Tunneling Protocol User Plane (GTP-U) messages.

14. The method of claim 11, wherein the header of the GTP-U message indicates information associated with the upcoming data traffic burst.

15. The method of claim 11, wherein the first network device is a User Plane Function (UPF) node, wherein the second network device is a Session Management Function (SMF) node, and wherein the third network device is the second network device.

16. The method of claim 11, wherein the method further comprises: Based on the configuration message and the downlink data, a burst size associated with the at least one upcoming data traffic burst is determined, wherein the notification of the upcoming data traffic burst indicates the determined burst size.

17. The method of claim 11, wherein the method further comprises: Based on the configuration message and the downlink data, an expected start time associated with the at least one upcoming data traffic burst is determined, wherein the notification of the upcoming data traffic burst indicates the determined expected start time.

18. The method of claim 11, wherein the configuration message indicates traffic pattern detection configuration information, wherein the traffic pattern detection configuration information is associated with detecting traffic bursts.

19. The method of claim 11, wherein the configuration message is received via the N4 interface.

20. The method of claim 11, wherein the configuration message indicates the sending of information associated with the upcoming data traffic burst.

Images