Method and device for detecting network service

Abstract

A method performed by a user equipment (UE) in a wireless communication system is provided. The method may include receiving network traffic from a network; decomposing the network traffic into one or more data streams based on the source information and the destination information; the data stream is stored in a service mapping, and the service mapping comprises data stream identification information and service information of the data stream in the observation time window; filtering the stored data stream based on one or more traffic characteristics of traffic information of the data stream; and determining a service type for each of the filtered data streams using machine learning.

Description

Technical Field

[0001] The present disclosure generally relates to network services, and more particularly, to detecting network services or types of network services in a communication system, such as but not limited to, based on isolated network traffic. Background Art

[0002] Network technologies, including wireless technologies, have evolved towards increasing data rates and service types and have continued to grow over the years in various markets such as homes, enterprises, and hotspots. Service types include voice, data, and video. There is an increasing need to identify the type of service presented in network traffic flows.

[0003] The descriptions set forth in the background art section should not be regarded as prior art merely because they are set forth in the background art section. The background art section may describe aspects or embodiments of the present disclosure. Summary of the Invention

[0004] Technical Solution

[0005] According to an embodiment of the present disclosure, a method performed by a user equipment (UE) in a wireless communication system is provided. The method may include: receiving network traffic from a network; decomposing the network traffic into one or more data streams based on source information and destination information; storing the data streams in a traffic map, where the traffic map includes data stream identification information and traffic information of the data stream in an observation time window; filtering the stored data streams based on one or more traffic characteristics of the traffic information of the data streams; and using machine learning to determine the service type of each of the filtered data streams.

[0006] According to an embodiment of the present disclosure, a user equipment (UE) in a wireless communication system is provided. The UE may include: a transceiver; and at least one processor coupled to the transceiver and configured to: receive network traffic from a network via the transceiver; decompose the network traffic into one or more data streams based on source information and destination information; store the data streams in a traffic map, where the traffic map includes data stream identification information and traffic information of the data stream in an observation time window; filter the stored data streams based on one or more traffic characteristics of the traffic information of the data streams; and use machine learning to determine the service type of each of the filtered data streams. Brief Description of the Drawings

[0007] Figure 1 An example of a wireless network according to an embodiment is shown.

[0008] Figure 2 An example of an AP according to an embodiment is shown.

[0009] Figure 3Shows an example of a STA according to an embodiment.

[0010] Figure 4 Shows an example of a wireless network in which the present disclosure according to an embodiment may operate.

[0011] Figure 5A Shows an example of a high-level flowchart of a process for network service detection according to an embodiment.

[0012] Figure 5B Shows an example of a high-level diagram of a system for network service detection according to an embodiment.

[0013] Figure 5C Shows an example of a detailed diagram of a system for network service detection according to an embodiment.

[0014] Figure 6A Shows an example of a flowchart of a service decomposition process according to an embodiment.

[0015] Figure 6B Shows an example of a service mapping according to an embodiment.

[0016] Figure 6C Shows an example of a diagram of dialogue filtering according to an embodiment.

[0017] Figure 6D Shows an example of a diagram of another dialogue filtering according to an embodiment.

[0018] Figure 6E Shows an example of a high-level diagram of a service decomposition system according to an embodiment.

[0019] Figure 7 Shows an example of a flowchart of a throughput-based service filtering process according to an embodiment.

[0020] Figure 8 Shows an exemplary relationship between a short observation window and a long observation window according to an embodiment.

[0021] Figure 9 Shows a diagram of exemplary throughput-based service filtering and the resulting service mapping according to an embodiment.

[0022] Figure 10 Shows an example of a flowchart of an input processing process according to an embodiment.

[0023] Figure 11 Shows an example of buffer array cascading operation according to an embodiment.

[0024] Figure 12 Shows an example of the use of an autoencoder and a decoder according to an embodiment.

[0025] Figure 13 Shows an example of cache operation according to an embodiment.

[0026] Figure 14 Shows an example of cache reordering operation according to an embodiment.

[0027] Figure 15 Shows an example of an input processing system according to an embodiment.

[0028] Figure 16 Shows an example of the input formation of an ML model according to an embodiment.

[0029] Figure 17 Shows an example of the input and output of an ML model according to an embodiment.

[0030] Figure 18 Shows a diagram of an exemplary multi-layer architecture of an ML-based service detection module or unit according to an embodiment.

[0031] Figure 19 Shows a diagram of an exemplary two-layer architecture of an ML-based service detection module or unit according to an embodiment.

[0032] Figure 20 Shows an example prediction table according to an embodiment.

[0033] Figure 21 Shows a diagram of an exemplary majority voting scheme according to an embodiment.

[0034] Figure 22 Shows a diagram of an exemplary weighted voting scheme according to an embodiment.

[0035] Figure 23 Shows a diagram of an exemplary biased voting scheme according to an embodiment.

[0036] Figure 24 Shows a diagram of an exemplary enhanced biased voting scheme according to an embodiment.

[0037] In one or more embodiments, it may not be necessary to have all the components depicted in each figure, and one or more embodiments may include additional components not shown in the figures. Without departing from the scope of the present disclosure, changes may be made to the arrangement and type of components. Within the scope of the present disclosure, additional components, different components, or fewer components may be utilized. Detailed Description

[0038] The description with the accompanying drawings is intended as a description of various embodiments and is not intended to represent the only embodiments in which the subject technology can be practiced. Instead, for the purpose of providing a thorough understanding of the subject matter disclosed, the description includes specific details. As will be recognized by those skilled in the art, the described embodiments can be modified in various ways without departing from the scope of the disclosure. Accordingly, the drawings and description are to be regarded as illustrative in nature and not restrictive. Like reference numerals refer to like elements.

[0039] This disclosure relates to communication systems, including but not limited to wireless communication systems such as wireless local area network (WLAN) technology. WLAN allows devices to access the Internet within the 2.4 GHz, 5 GHz, 6 GHz, or 60 GHz frequency bands. WLAN is based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards. The IEEE 802.11 series of standards aims to increase speed and reliability and expand the operating range of wireless networks.

[0040] Although the examples and description below may depict wireless communication systems, this disclosure applies to both wired and wireless technologies. Accordingly, references to wireless devices, systems, and processes can equally apply to wired devices, systems, and processes.

[0041] This description is directed to certain embodiments and is intended to describe the innovative aspects of this disclosure. However, those of ordinary skill in the art will readily recognize that the teachings herein can be applied in many different ways. The described embodiments can be implemented in any device, system, or network capable of sending and receiving signals, such as radio frequency (RF) signals according to the IEEE 802.11 standards, Bluetooth standards, Global System for Mobile Communications (GSM), GSM / General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Terrestrial Trunked Radio (TETRA), Wideband CDMA (W-CDMA), Evolution-Data Optimized (EV-DO), 1xEV-DO, EV-DO Rev A, EV-DO Rev B, High-Speed Packet Access (HSPA), High-Speed Downlink Packet Access (HSDPA), High-Speed Uplink Packet Access (HSUPA), Evolved High-Speed Packet Access (HSPA+), Long-Term Evolution (LTE), 5G NR (New Radio), Advanced Mobile Phone System (AMPS), or other known signals for communication within wireless, cellular, or Internet of Things (IoT) networks (e.g., systems, technologies utilizing 3G, 4G, 5G, 6G, or other implementations thereof).

[0042] Depending on the network type, other well-known terms (e.g., "router" or "gateway") may be used instead of "access point" or "AP". For convenience, the term "AP" is used in this disclosure to refer to the network infrastructure component that provides wireless access to remote terminals. In a WLAN, since the AP also contends for the wireless channel, the AP can also be referred to as a STA. Additionally, depending on the network type, other well-known terms (e.g., "mobile station", "subscriber station", "remote terminal", "user equipment", "wireless terminal", or "user device") may be used instead of "station" or "STA". For convenience, the terms "station" and "STA" are used in this disclosure to refer to a remote wireless device that wirelessly accesses an AP or contends for the wireless channel in a WLAN, regardless of whether the STA is a mobile device (such as a mobile phone or a smart phone) or is typically regarded as a fixed device (such as a desktop computer, an AP, a media player, a fixed sensor, a TV, etc.).

[0043] The demand for data services continues to grow. For example, due to the increasing popularity of smart phones and other mobile data devices (e.g., tablet computers, "notebook" computers, netbooks, e-book readers, and machine-type devices) among consumers and enterprises, the demand for wireless data services is growing rapidly. With this growth, it is thus desirable to identify the types of services presented in network traffic flows. The ability to detect the service type of a traffic flow is crucial for a wide range of applications (e.g., traffic prioritization, controlling the 802.11ax target wake time function, dynamic scheduling, quality of service assurance, anomaly detection, etc.). Since modern network traffic is typically encrypted, the early methods that rely on DPI (Deep Packet Inspection) and packet port numbers become less feasible. This has led to a need to isolate traffic based on, for example, conversations between endpoints, then extract features from the packet information, and use machine learning algorithms to map the traffic patterns to the correct service categories.

[0044] Generally, this disclosure can implement reliable methods and systems to identify multiple types of services presented in a traffic flow. Network traffic flows can sometimes contain not only one type of service but multiple types of services. For example, given a scenario where a user interacts with his / her mobile device, he / she may be downloading a large file and making a VoIP call simultaneously. In this scenario, the network flow contains two types of services. When it is necessary to identify these service types, the current methods are unable to identify multiple service types in a traffic flow. This disclosure supports the detection of multiple services.

[0045] Being able to do so can also support more applications and / or functions such as service prioritization, traffic throttling, and power management. The ability to automatically analyze network traffic to identify services can be very valuable for a wide range of functions including network resource management, quality of service, dynamic access control, energy conservation, etc. These capabilities in turn facilitate efficient communication and reliable data transmission, which may open the door to further technologies to be developed.

[0046] One embodiment of the present disclosure may provide a network connection device. The network connection device may include: a transceiver configured to receive network traffic from a network; a memory coupled to the transceiver; and a processor coupled to the memory and the transceiver, the processor being configured to: decompose the network traffic into one or more data streams based on source information and destination information; store the data streams in a traffic map, each entry of the traffic map including a data stream identifier and traffic information of the data stream in an observation time window; filter the stored data streams based on one or more traffic characteristics of the traffic information of the data streams; and use machine learning to determine the service type of each of the filtered data streams.

[0047] In some embodiments, the source information may be a source Internet Protocol (IP) address or a source port, and the destination information may be a destination IP address or a destination port.

[0048] In some embodiments, the processor may be configured to filter the stored data streams based on the number of packets or the number of bytes in each of the stored data streams.

[0049] In some embodiments, the processor may be configured to filter the stored data streams based on the traffic throughput in each of the stored data streams.

[0050] In some embodiments, the processor may be configured to: calculate a first throughput in the observation time window for each filtered data stream; and store the filtered data streams with a throughput greater than the first throughput in the traffic map.

[0051] In some embodiments, the processor may be configured to: remove the stored filtered data stream with the minimum throughput based on determining that the number of stored filtered data streams is greater than a first throughput threshold.

[0052] In some embodiments, the processor may be configured to: calculate a second throughput in a second observation time window for each stored filtered data stream, wherein the second observation time window is longer than the observation time window; and remove the stored data stream from the traffic map based on determining that the second throughput of the stored filtered data stream is less than a second throughput threshold.

[0053] In some embodiments, the processor may be configured to receive information from one or more sensors of a network-connected device and filter a stored filtered data stream including information from the one or more sensors.

[0054] In some embodiments, the processor may be configured to use a multi-layer machine learning model having a first layer and a second layer, wherein the first layer of the multi-layer machine learning model determines a service type and the second layer of the multi-layer machine learning model further divides the service type into sub-categories.

[0055] In some embodiments, the processor may also be configured to receive current information from one or more sensors of a network-connected device and determine a service type including the current information from the one or more sensors.

[0056] Embodiments of the present disclosure may provide a method for detecting a network service type. The method may include: receiving network traffic from a transceiver; decomposing the network traffic into one or more data streams based on source information and destination information; storing the data streams in a traffic map in a memory, each entry of the traffic map including a data stream identifier and traffic information of the data stream in an observation time window; filtering the stored data streams based on one or more traffic characteristics of the traffic information of the data streams; and using machine learning to determine a service type for each of the filtered data streams.

[0057] In some embodiments, the source information may be a source Internet Protocol (IP) address or a source port, and the destination information may be a destination IP address or a destination port.

[0058] In some embodiments, filtering the stored data streams may be based on the number of packets or the number of bytes in each of the stored data streams.

[0059] In some embodiments, filtering the stored data streams may be based on the traffic throughput in each of the stored data streams.

[0060] In some embodiments, the method may include: calculating a first throughput in an observation time window for each filtered data stream; and storing the filtered data streams having a throughput greater than the first throughput in the traffic map.

[0061] In some embodiments, the method may include: removing the stored filtered data stream having the minimum throughput based on determining that the number of stored filtered data streams is greater than a first throughput threshold.

[0062] In some embodiments, the method may include: calculating, for each stored filtered data stream, a second throughput in a second observation time window, where the second observation time window is longer than the observation time window; and removing the stored data stream from the service mapping based on determining that the second throughput of the stored filtered data stream is less than a second throughput threshold.

[0063] In some embodiments, the method may include receiving information from one or more sensors of a network-connected device and filtering a stored filtered data stream that includes information from the one or more sensors.

[0064] In some embodiments, the method may include: using a multi-layer machine learning model having a first layer and a second layer, where the first layer of the multi-layer machine learning model determines a service type and the second layer of the multi-layer machine learning model further divides the service type into sub-categories.

[0065] In some embodiments, the method may include: receiving current information from one or more sensors of a network-connected device and determining a service type that includes the current information from the one or more sensors.

[0066] Figure 1 An example of a wireless network 100 in which the present disclosure may operate in accordance with some embodiments is shown. Figure 1 The illustrated embodiments of the wireless network 100 are for illustrative purposes only. Other embodiments of the wireless network 100 may be used without departing from the scope of the present disclosure.

[0067] As Figure 1 shown, the wireless network 100 may include a plurality of wireless communication devices. Each wireless communication device may include one or more stations (STAs). An STA may be a logical entity that is a separately addressable instance of the media access control (MAC) layer and the physical (PHY) layer interface of the wireless medium. STAs may be classified as access point (AP) STAs and non-access point (non-AP) STAs. An AP STA may be an entity that provides access to distributed system services via the wireless medium for associated STAs. A non-AP STA may be an STA that is not included within an AP STA. For simplicity of description, an AP STA may be referred to as an AP, and a non-AP STA may be referred to as an STA. In Figure 1 the example of, APs 101 and 103 are wireless communication devices, and each AP may include one or more AP STAs. In such an embodiment, APs 101 and 103 may be AP multi-link devices (MLDs). Similarly, STAs 111 to 114 are wireless communication devices, and each STA may include one or more non-AP STAs. In such an embodiment, STAs 111 to 114 may be non-AP MLDs.

[0068] APs 101 and 103 can communicate with at least one network 130 (e.g., the Internet, a proprietary Internet Protocol (IP) network, or other data network). AP 101 provides wireless access to network 130 for a plurality of stations (STAs) 111 to 114 using the coverage area 120 of AP 101. APs 101 and 103 can use Wi-Fi or other WLAN communication technologies to communicate with each other and with STAs.

[0069] In Figure 1 the figure, the dashed lines illustrate the approximate extents of the coverage areas 120 and 125 of APs 101 and 103, which are shown as being generally circular for purposes of illustration and explanation. It should be clearly understood that the coverage areas associated with an AP (e.g., coverage areas 120 and 125) can have other shapes, including irregular shapes, depending on the configuration of the AP.

[0070] As described in more detail below, one or more APs can include circuitry and / or programming for managing MU-MIMO and OFDMA channel sounding in a WLAN. Although Figure 1 illustrates one example of a wireless network 100, various changes can be made to Figure 1 it. For example, the wireless network 100 can include any number of APs and any number of STAs in any suitable arrangement. Additionally, AP 101 can communicate directly with any number of STAs and provide wireless broadband access to network 130 for those STAs. Similarly, each of APs 101 and 103 can communicate directly with network 130 and provide direct wireless broadband access to network 130 for STAs. Further, AP 101 and / or 103 can provide access to other or additional external networks (e.g., an external telephone network or other types of data networks).

[0071] Figure 2 illustrates an example of AP 101 according to some embodiments. Figure 2 The illustrated embodiment of AP 101 is for illustrative purposes only, and Figure 1 AP 103 can have the same or a similar configuration. However, APs have a wide variety of configurations, and Figure 2 do not limit the scope of the present disclosure to any particular implementation of an AP.

[0072] As Figure 2As shown, the AP 101 may include multiple antennas 204a to 204n, multiple radio frequency (RF) transceivers 209a to 209n, transmit (TX) processing circuitry 214, and receive (RX) processing circuitry 219. The AP 101 may also include a controller / processor 224, a memory 229, and a backhaul or network interface 234. The RF transceivers 209a to 209n receive incoming RF signals from the antennas 204a to 204n, such as signals transmitted by STAs in the network 100. The RF transceivers 209a to 209n down-convert the incoming RF signals to generate intermediate frequency (IF) or baseband signals. The IF or baseband signals are sent to the RX processing circuitry 219, which generates processed baseband signals by filtering, decoding, and / or digitizing the baseband or IF signals. The RX processing circuitry 219 sends the processed baseband signals to the controller / processor 224 for further processing.

[0073] The TX processing circuitry 214 receives analog or digital data (such as voice data, network data, e-mail, or interactive video game data) from the controller / processor 224. The TX processing circuitry 214 encodes, multiplexes, and / or digitizes the output baseband data to generate processed baseband or IF signals. The RF transceivers 209a to 209n receive the processed output baseband or IF signals from the TX processing circuitry 214 and up-convert the baseband or IF signals to RF signals transmitted via the antennas 204a to 204n.

[0074] The controller / processor 224 may include one or more processors or other processing devices that control the overall operation of the AP 101. For example, the controller / processor 224 may control the reception of uplink signals and the transmission of downlink signals by the RF transceivers 209a to 209n, the RX processing circuitry 219, and the TX processing circuitry 214 according to well-known principles. The controller / processor 224 may also support additional functions, such as more advanced wireless communication functions. For example, the controller / processor 224 may support beamforming or directional routing operations, in which the output signals from the multiple antennas 204a to 204n are weighted differently to effectively steer the output signals to a desired direction. The controller / processor 224 may also support OFDMA operations, in which the output signals are assigned to different subsets of subcarriers for different recipients (e.g., different STAs 111 to 114). The controller / processor 224 may support any of a variety of other functions in the AP 101, including combinations of DLMU-MIMO and OFDMA in the same transmission opportunity. In some embodiments, the controller / processor 224 may include at least one microprocessor or microcontroller. The controller / processor 224 may also be capable of executing programs and other processes residing in the memory 229, such as the OS. The controller / processor 224 may move data into or out of the memory 229 as needed for the execution of the processes.

[0075] The controller / processor 224 may also be coupled to a backhaul or network interface 234. The backhaul or network interface 234 may allow the AP 101 to communicate with other devices or systems via a backhaul connection or via a network. The interface 234 may support communication via any suitable wired or wireless connection. For example, the interface 234 may allow the AP 101 to communicate via a wired or wireless local area network or to communicate with a larger network, such as the Internet, via a wired or wireless connection. The interface 234 may include any suitable structure that supports communication via a wired or wireless connection, such as Ethernet or an RF transceiver. The memory 229 may be coupled to the controller / processor 224. A portion of the memory 229 may include RAM, and another portion of the memory 229 may include flash memory or other ROM.

[0076] As described in more detail below, the AP 101 may include circuitry and / or programming for managing the channel sounding process in a WLAN. Although Figure 2 one example of the AP 101 is shown, various changes may be made to Figure 2 it. For example, the AP 101 may include any number of Figure 2Each of the components shown. As a specific example, the AP may include multiple interfaces 234, and the controller / processor 224 may support routing functions to route data between different network addresses. As another example, although shown as including a single instance of the TX processing circuit 214 and a single instance of the RX processing circuit 219, the AP 101 may include multiple instances of each (such as one instance per RF transceiver). Alternatively, in a traditional AP for example, only one antenna and RF transceiver path may be included. Additionally, various components in Figure 2 may be combined, further subdivided, or omitted according to specific needs, and additional components may be added.

[0077] As Figure 2 shown, in some embodiments, the AP 101 may be an AP MLD including multiple APs 202a to 202n. Each of the APs 202a to 202n belongs to the AP MLD 101 and may include multiple antennas 204a to 204n, multiple radio frequency (RF) transceivers 209a to 209n, a transmit (TX) processing circuit 214, and a receive (RX) processing circuit 219. Each of the APs 202a to 202n may communicate independently with the controller / processor 224 and other components of the AP MLD 101. Figure 2 It is shown that each of the APs 202a to 202n has a separate multiple antennas, but each of the APs 202a to 202n may share the multiple antennas 204a to 204n without having a separate multiple antennas. Each of the APs 202a to 202n may represent the physical (PHY) layer and the lower media access control (MAC) layer.

[0078] Figure 3 An example of the STA 111 is shown according to some embodiments. Figure 3 The embodiment of the STA 111 shown is for illustrative purposes, and Figure 1 the STAs 111 to 114 Figure 3 may have the same or similar configurations. However, STAs have a wide variety of configurations, and

[0079] In Figure 3 the example, the STA may be an electronic device 301, such as a mobile device (such as a mobile phone, smartphone, etc.) or a fixed device (such as a desktop computer, AP, or media player, etc.). In an embodiment, the STA may include a user equipment (UE).

[0080] As Figure 3As shown, the electronic device 301 in the network environment 300 may communicate with the electronic device 302 via the first network 398 (e.g., a short-range wireless communication network), or communicate with the electronic device 304 or the server 308 via the second network 399 (e.g., a long-range wireless communication network). The first network 398 or the second network 399 may be, for example, a wireless local area network (WLAN) compliant with the IEEE 802.11be standard or any future revision of the IEEE 802.11 standard.

[0081] According to some embodiments, the electronic device 301 may communicate with the electronic device 304 via the server 308. According to some embodiments, the electronic device 301 may include a processor 320, a memory 330, an input module 350, a sound output module 355, a display module 360, an audio module 370, a sensor module 376, an interface 377, a connection terminal 378, a haptic module 379, a camera module 380, a power management module 388, a battery 389, a communication module 390, a subscriber identity module (SIM) 396, or an antenna module 397. In some embodiments, at least one of the above components (e.g., the connection terminal 378) may be omitted from the electronic device 301, or one or more other components may be added to the electronic device 301. In some embodiments, some of the above components (e.g., the sensor module 376, the camera module 380, or the antenna module 397) may be implemented as a single component (e.g., the display module 360).

[0082] The processor 320 may run software (e.g., program 340), for example, to control at least one other component (e.g., a hardware or software component) coupled to the processor 320 of the electronic device 301, and may perform various data processing or computations. According to some embodiments, as at least part of the data processing or computation, the processor 320 may store commands or data received from another component (e.g., the sensor module 376 or the communication module 390) in the volatile memory 332, process the commands or data stored in the volatile memory 332, and store the resulting data in the non-volatile memory 334. According to some embodiments, the processor 320 may include a main processor 321 (e.g., a central processing unit (CPU) or an application processor) or an auxiliary processor 323 (e.g., a graphics processing unit (GPU), a neural processing unit (NPU), an image signal processor (ISP), a sensor hub processor, or a communication processor (CP)) that is operationally independent of or combined with the main processor 321. For example, when the electronic device 301 includes the main processor 321 and the auxiliary processor 323, the auxiliary processor 323 may be adapted to consume less power than the main processor 321 or to be dedicated to a specific function. The auxiliary processor 323 may be implemented separately from the main processor 321 or as part of the main processor 121.

[0083] When the main processor 321 is in an inactive (e.g., sleep) state, the auxiliary processor 323 (instead of the main processor 321) can control at least some of the functions or states related to at least one of the components of the electronic device 301 (e.g., the display module 360, the sensor module 376, or the communication module 390), or when the main processor 321 is in an active state (e.g., running an application), the auxiliary processor 123 can control at least some of the functions or states related to at least one of the components of the electronic device 101 (e.g., the display module 360, the sensor module 376, or the communication module 390) together with the main processor 321. According to some embodiments, the auxiliary processor 323 (e.g., ISP or CP) can be implemented as part of another component (e.g., the camera module 380 or the communication module 390) that is functionally related to the auxiliary processor 323. According to some embodiments, the auxiliary processor 323 (e.g., NPU) can include a hardware structure dedicated to artificial intelligence model processing. An artificial intelligence model can be generated through machine learning. For example, such learning can be performed by the electronic device 301 where the artificial intelligence is executed or via a separate server (e.g., server 308). The learning algorithm can include, but is not limited to, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning. The artificial intelligence model can include multiple artificial neural network layers. The artificial neural network can be a deep neural network (DNN), a convolutional neural network (CNN), a recurrent neural network (RNN), a restricted Boltzmann machine (RBM), a deep belief network (DBN), a bidirectional recurrent deep neural network (BRDNN), a deep Q-network, or a combination of two or more of them, but is not limited thereto. The artificial intelligence model can additionally or alternatively include a software structure in addition to the hardware structure.

[0084] The memory 330 can store various data used by at least one component of the electronic device 301 (e.g., the processor 320 or the sensor module 376). For example, the various data can include software (e.g., the program 340) and input data or output data related to the commands thereof. The memory 330 can include a volatile memory 332 or a non-volatile memory 334.

[0085] The program 340 can be stored in the memory 330 as software, and for example, can include an operating system (OS) 342, middleware 344, or one or more applications 346.

[0086] The input module 350 can receive commands or data to be used by other components of the electronic device 301 (e.g., the processor 320) from the outside of the electronic device 301 (e.g., a user). The input module 350 can include, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus).

[0087] The sound output module 355 may output a sound signal to the outside of the electronic device 301. The sound output module 355 may include, for example, a speaker or a receiver. The speaker may be used for general purposes such as playing multimedia or playing recorded data. The receiver may be used to receive incoming calls. According to some embodiments, the receiver may be implemented separately from the speaker or as part of the speaker.

[0088] The display module 360 may visually provide information to the outside of the electronic device 301 (e.g., to a user). The display device 360 may include, for example, a display, a holographic device, or a projector, and a control circuit for controlling a corresponding one of the display, the holographic device, and the projector. According to some embodiments, the display module 360 may include a touch sensor adapted to detect a touch or a pressure sensor adapted to measure the intensity of a force caused by the touch.

[0089] The audio module 370 may convert sound into an electrical signal and vice versa. According to some embodiments, the audio module 370 may obtain sound via the input module 350, or output sound via the sound output module 355 or a headset of an external electronic device (e.g., electronic device 302) directly (e.g., wiredly) or wirelessly connected to the electronic device 301.

[0090] The sensor module 376 may detect an operating state of the electronic device 301 (e.g., power or temperature) or an environmental state outside the electronic device 301 (e.g., a state of a user), and then generate an electrical signal or a data value corresponding to the detected state. According to some embodiments, the sensor module 376 may include, for example, a gesture sensor, a gyro sensor, an atmospheric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an infrared (IR) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

[0091] The interface 377 may support one or more specific protocols for directly (e.g., wiredly) or wirelessly connecting the electronic device 301 to an external electronic device (e.g., electronic device 302). According to some embodiments, the interface 377 may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, a secure digital (SD) card interface, or an audio interface.

[0092] The connection terminal 378 may include a connector through which the electronic device 301 may be physically connected to an external electronic device (e.g., electronic device 302). According to some embodiments, the connection terminal 378 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0093] The haptic module 379 may convert an electrical signal into a mechanical stimulus (e.g., vibration or motion) or an electrical stimulus that can be recognized by the user via his sense of touch or kinesthesia. According to an embodiment, the haptic module 379 may include, for example, a motor, a piezoelectric element, or an electrical stimulator.

[0094] The camera module 380 may capture a still image or a moving image. According to some embodiments, the camera module 380 may include one or more lenses, an image sensor, an ISP, or a flash.

[0095] The power management module 388 may manage the power supplied to the electronic device 301. According to some embodiments, the power management module 388 may be implemented as at least a part of, for example, a power management integrated circuit (PMIC).

[0096] The battery 389 may supply power to at least one component of the electronic device 301. According to some embodiments, the battery 389 may include, for example, a primary non-rechargeable battery, a rechargeable battery, or a fuel cell.

[0097] The communication module 390 may support establishing a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device 301 and an external electronic device (e.g., the electronic device 302, the electronic device 304, or the server 308), and perform communication via the established communication channel. The communication module 390 may include one or more CPs that can operate independently of the processor 320 (e.g., an application processor), and support direct (e.g., wired) communication or wireless communication. According to some embodiments, the communication module 390 may include a wireless communication module 392 (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 394 (e.g., a local area network (LAN) communication module or a power line communication (PLC) module). The corresponding one of these communication modules may communicate with the external electronic device via a first network 398 (e.g., a short-range communication network, such as Bluetooth TM , Wi-Fi Direct, or the Infrared Data Association (IrDA)) or a second network 399 (e.g., a long-range communication network, such as a traditional cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a LAN or a wide area network (WAN))). These various types of communication modules may be implemented as a single component (e.g., a single chip), or these various types of communication modules may be implemented as multiple separate components (e.g., multiple chips). The wireless communication module 392 may identify and authenticate the electronic device 301 in a communication network (e.g., the first network 398 or the second network 399) using subscriber information (e.g., an international mobile subscriber identity (IMSI)) stored in the SIM 396.

[0098] The wireless communication module 392 may support 5G networks and next-generation communication technologies after 4G networks, such as New Radio (NR) access technology. The NR access technology may support enhanced mobile broadband (eMBB), massive machine type communication (mMTC), or ultra-reliable low-latency communication (URLLC). The wireless communication module 392 may support high frequency bands (e.g., millimeter wave bands) to achieve, for example, high data transfer rates. The wireless communication module 392 may support various technologies for ensuring performance in high frequency bands, such as beamforming, massive multiple-input multiple-output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, or massive antennas. The wireless communication module 392 may support various requirements specified in the electronic device 301, an external electronic device (e.g., the electronic device 304), or a network system (e.g., the second network 399). According to some embodiments, the wireless communication module 392 may support a peak data rate for implementing eMBB (e.g., 20 Gbps or higher), a loss coverage for implementing mMTC (e.g., 164 dB or lower), or a U-plane latency for implementing URLLC (e.g., 0.5 ms or less for each of downlink (DL) and uplink (UL), or a round-trip of 1 ms or less).

[0099] The antenna module 397 may transmit signals or power to the outside of the electronic device 301 (e.g., an external electronic device) or receive signals or power from the outside of the electronic device 301 (e.g., an external electronic device). According to an embodiment, the antenna module 397 may include an antenna, and the antenna may include a radiating element formed of a conductive material or a conductive pattern formed in a substrate (e.g., a printed circuit board (PCB)) or formed on the substrate. According to an embodiment, the antenna module 397 may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication scheme used in a communication network (such as the first network 398 or the second network 399) may be selected from the plurality of antennas by, for example, the communication module 390 (e.g., the wireless communication module 392). Subsequently, signals or power may be transmitted or received between the communication module 390 and an external electronic device via the selected at least one antenna. According to an embodiment, additional components (e.g., a radio frequency integrated circuit (RFIC)) other than the radiating element may be additionally formed as part of the antenna module 397.

[0100] According to various embodiments, the antenna module 397 may form a millimeter-wave antenna module. According to some embodiments, the millimeter-wave antenna module may include a PCB, an RFIC disposed on or adjacent to a first surface (e.g., a bottom surface) of the PCB and capable of supporting a specified high-frequency band (e.g., a millimeter-wave band), and a plurality of antennas (e.g., an array antenna) disposed on or adjacent to a second surface (e.g., a top surface or a side surface) of the PCB and capable of transmitting or receiving signals of the specified high-frequency band.

[0101] At least some of the above components may be coupled to each other and transmit signals (e.g., commands or data) therebetween via an inter-peripheral communication scheme (e.g., a bus, a general-purpose input and output (GPIO), a serial peripheral interface (SPI), or a mobile industry processor interface (MIPI)).

[0102] According to some embodiments, commands or data can be sent or received between the electronic device 301 and the external electronic device 304 via the server 308 coupled to the second network 399. Each of the electronic device 302 or the electronic device 304 can be a device of the same type as the electronic device 301 or a device of a different type from the electronic device 301. According to some embodiments, all or some of the operations running on the electronic device 301 can be run on one or more of the external electronic device 302, the external electronic device 304, or the server 308. For example, if the electronic device 301 is supposed to automatically execute a function or service or is supposed to execute a function or service in response to a request from a user or another device, the electronic device 301 can request one or more of the external electronic devices to execute at least part of the function or service instead of running the function or service, or in addition to running the function or service, the electronic device 101 can also request one or more of the external electronic devices to execute at least part of the function or service. The one or more external electronic devices that receive the request can execute the requested at least part of the function or service or execute additional functions or additional services related to the request and transmit the result of the execution to the electronic device 301. The electronic device 301 can provide the result, with or without further processing of the result, as at least part of the response to the request. For this purpose, for example, cloud computing technology, distributed computing technology, mobile edge computing (MEC) technology, or client-server computing technology can be used. The electronic device 301 can use, for example, distributed computing or MEC to provide ultra-low latency services. In another embodiment, the external electronic device 304 can include an Internet of Things (IoT) device. The server 308 can be an intelligent server using machine learning and / or neural networks. According to some embodiments, the external electronic device 304 or the server 308 can be included in the second network 399. The electronic device 301 can be applied to intelligent services (such as smart home, smart city, smart car, or healthcare) based on 5G communication technology or IoT-related technology.

[0103] As mentioned herein, a network flow can include various types of services. A service (or network service) can be a function provided through a network infrastructure that facilitates application-level interaction and data exchange between connected devices in a network data stream (or network flow). A network flow can include voice, video, and data traffic. Generally speaking, at a high-level description, the present disclosure provides a network detection service that can accurately identify different types of services in a network flow. In some embodiments, the network detection service can be implemented in a user device (such as the user device 300).

[0104] Figure 4FIG. 0 shows an example of a wireless network 400 in which the present disclosure according to some embodiments may operate. Figure 4 The illustrated embodiment of the wireless network 400 is for illustrative purposes only. Other embodiments of the wireless network 400 may be used without departing from the scope of the present disclosure. Although Figure 4 the examples in

[0105] as Figure 4 shown, the wireless network 400 may include a user device 401 (similar to the electronic device 301), which may be connected to the Internet 440 through an AP or a cellular device 430. In an embodiment, the user device 401 may include a user equipment (UE). In this example, the user device 401 is shown to have two running applications 412 and 414. The application 412 may perform a file download function, such as downloading a cloud storage file. The application 414 may be a voice call, such as an Internet Protocol voice (VOIP) call. For simplicity, the data traffic between the applications 412 and 414 and the upstream network device is shown in the network flow 420. Thus, the network flow 420 includes both the data traffic flow 422 of the application 412 and the data traffic flow 424 of the application 414. Using the data traffic flows 422 and 424, the network detection service 402 may detect or predict the service type of each data traffic flow. In this example, the network detection service 402 may predict that the service type regarding the data traffic flow 422 is a non-real-time type, and the service type regarding the data traffic flow 424 is a real-time type.

[0106] Figure 5A FIG. 13 shows an example of a high-level flowchart depicting a process 500 for network service detection (or NSD) according to some embodiments. In some embodiments, in order to detect the type of network service in a traffic flow, the process 500 may group applications having similar latency requirements as well as service and data characteristics together to form service types (such as video calls, audio calls, etc.). These service types may be predefined. Then, the process 500 may use a machine learning algorithm to detect the traffic patterns in the traffic flow, for example, by using the features extracted from the grouping information and optionally additional sensor information. Subsequently, the output of the machine learning algorithm may undergo a post-processing process, which may employ different techniques to make a final decision regarding the network service type using the current prediction and the past predictions. The post-processing process may be a logic-based post-processing process capable of using the current prediction and the past predictions.

[0107] In operation 502, the user device may receive a network traffic data stream, such as Figure 4 the traffic flow 420 shown.

[0108] In operation 504, the network traffic flow can be decomposed to generate multiple smaller traffic flows. In some embodiments, process 500 can track the packets in the flow (e.g., via a packet tracker module or unit), and then group them according to, for example, the five-tuple rule (e.g., source IP address, source port, destination IP address, destination port, and transport layer protocol), thereby splitting the flow into individual traffic flows, e.g., Figure 4 the traffic flows 422 and 424 shown. Each traffic flow can be referred to as a conversation. It should be noted that the decomposition process can be performed without interaction with or assistance from the ultimate destination of the packets (e.g., the application).

[0109] In operation 506, process 500 can include a pipeline with a caching mechanism that manages and maintains data for all active decomposed traffic flows. Optional sensor information 505 can be received for processing during operation 506. The sensor information can include, for example, camera usage, speaker usage, touchscreen interaction rate, presence of an active gaming application, etc.

[0110] In some embodiments, process 500 can extract features from the traffic flow. These features can include, for example, packet information (e.g., packet count, Transmission Control Protocol (TCP) packet count, User Datagram Protocol (UDP) packet count, average packet size, etc.) and packet timing information (e.g., inter-packet arrival time) in each predetermined observation time window.

[0111] For simplicity, the observation time window can be referred to herein as an observation window, observation time, time window, or window.

[0112] In operation 508, process 500 can classify the service type associated with each conversation. In some embodiments, process 500 can employ machine learning (ML) techniques on the network traffic statistics derived from the traffic flow of the conversation to accurately classify the service type associated with each conversation. Process 500 can perform a single or series of machine learning algorithms on the traffic features extracted from the isolated traffic flow and any additional sensor information.

[0113] In operation 510, process 500 can predict one or more service types presented in the composite traffic flow. In some embodiments, process 500 can include rule-based processing to examine and make decisions using the instantaneous detection types of the individual component flows, their historical prediction labels, and additional sensor information 505. The sensor information can include, for example, camera usage, speaker usage, touchscreen interaction rate, presence of an active gaming application, etc.

[0114] In operation 512, process 500 may generate a prediction generated by operation 510.

[0115] Figure 5B FIG. shows an example of a high-level diagram depicting a system 550 for network service detection according to some embodiments. In some embodiments, system 550 may include a service decomposition unit or module 554 that may receive a service flow 552 and perform operation 504 as described above. An input processing unit or module 556 may receive an input from the service decomposition unit or module 554 and perform operation 506 described above. The input processing unit or module 556 may also receive sensor information 505. A machine learning-based service detection unit or module 558 may receive an input from the input processing unit or module 556 and perform operation 508 as described above. A rule-based post-processing unit or module 560 may receive an input from the machine learning-based service detection unit or module 558 and perform operation 510 as described above to generate a prediction 562. The machine learning-based service detection unit or module 558 may also receive sensor information 505.

[0116] As used herein and in the figures, the terms input processing unit or module and input processor may be used interchangeably; the terms post-processing unit or module and post-processor may be used interchangeably; the terms service detection / detection module or unit and service detector may be used interchangeably. Also, as used herein, the terms feature and information may be used interchangeably.

[0117] Figure 5C FIG. shows an example of a diagram 570 depicting a detailed system 550 for network service detection according to some embodiments. Figure 5C Provided for convenience only. Details of each component will be described in further detail below. For example, details of the service decomposition unit or module 554 will be described in connection with Figures 6A to 9 Details of the service decomposition unit or module 554 will be further described. Details of the input unit or module 556 will be described in connection with Figures 10 to 17 Details of the input unit or module 556 will be further described. Details of the ML-based service detection module or unit 558 will be described in connection with Figures 17 to 19 Details of the ML-based service detection module or unit 558 will be further described. Details of the post-processing unit or module 560 will be described in connection with Figures 20 to 24 Details of the post-processing unit or module 560 will be further described.

[0118] Figure 6A FIG. shows an example of a flowchart depicting a service decomposition process 600 for network service detection according to some embodiments. Process 600 discloses further details of operation 504 as Figure 5A shown. In some embodiments, the service decomposition process 600 may separate (or decompose) a service flow into multiple smaller service flows for detecting network services in the service flow.

[0119] In operation 602, process 600 may receive a network traffic data stream, such as Figure 4 the traffic flow 420 shown.

[0120] In operation 604, process 600 may decompose the composite service data in the traffic flow. In some embodiments, process 600 may extract information from the original packet data in the flow and parse the packet header information to obtain the source address and the destination address. The flow may be separated into multiple flows, each flow including two endpoint addresses, such as (e.g., the source address) and (e.g., the destination address). Each flow may be referred to as a conversation, combining the addresses of the two endpoints . The addresses may include IP addresses, MAC addresses, or port numbers.

[0121] In operation 606, process 600 may group the packets belonging to a conversation together. In some embodiments, a service mapping may be used to match a service with its corresponding conversation within a time interval. This time interval may be referred to as a burst b or a time step, which may be preset with a predetermined value. This value may be within a range, e.g., within 300 to 700 ms. In some embodiments, the default value of b may be set to 500 ms. In some embodiments, the service mapping may be implemented using a data structure such as a hash map or a dictionary, but other data structures may also be used.

[0122] Figure 6B Shows an example of a service mapping 610. In some embodiments, the service mapping 610 may include a list of conversations 612 and their corresponding information (shown as features) 614. It should be noted that the conversation information may be referred to as features herein. These features may be used in machine learning models, as described in further detail below.

[0123] In some embodiments, for each burst b, e.g., every 500 ms, process 600 may parse the headers of the packets and group them into conversations 612. For example, in Figure 6B shown as Convo A, Convo M, Convo F, etc. At this time, for each conversation, features 614 may be calculated. For example, shown as feature A, feature M, feature F, corresponding to Convo A, Convo M, Convo F respectively. These features may be obtained from the packet information and the packet timing information. Examples of features may include but are not limited to:

[0124] - Uplink and downlink maximum arrival interval time: The maximum time difference between the arrival of one packet and the next packet within a burst (2 values, one value for the uplink and one value for the downlink).

[0125] - Uplink and downlink average inter - arrival time: The average time difference between the arrival of one packet and the next within a burst (2 values, one for the uplink and one for the downlink).

[0126] - Uplink and downlink packet counts: The number of uplink and downlink packets within a burst (2 values, one for the uplink and one for the downlink).

[0127] - Uplink and downlink minimum packet sizes: The uplink and downlink minimum packet sizes within a burst (in megabytes (Mb)) (2 values, one for the uplink and one for the downlink).

[0128] - Uplink and downlink maximum packet sizes: The uplink and downlink maximum packet sizes within a burst (in Mb) (2 values, one for the uplink and one for the downlink).

[0129] - Uplink and downlink average packet sizes: The uplink and downlink average packet sizes within a burst (in Mb) (2 values, one for the uplink and one for the downlink).

[0130] - Uplink and downlink UDP packet counts: The number of User Datagram Protocol packets for the uplink and downlink within a burst (2 values, one for the uplink and one for the downlink).

[0131] - Uplink and downlink TCP packet counts: The number of Transmission Control Protocol packets for the uplink and downlink within a burst (2 values, one for the uplink and one for the downlink).

[0132] In some embodiments, process 600 may update service map 610 with the extracted features. In some embodiments, process 600 may use the conversation as a keyword, for example, in looking up information and managing the service map.

[0133] Return Figure 6A , in operation 608, process 600 may also use one or more of the following filtering mechanisms to remove a conversation from service map 610 or retain a conversation in service map 610. In some implementations, the following mechanisms may be used sequentially.

[0134] In some embodiments, broadcast or multicast conversations can be removed. These conversations can be determined to have little value for service type detection. A broadcast conversation can include, for example, a conversation where the last field of the Internet Protocol version 4 (IPv4) address equals 255. A multicast conversation can include, for example, a conversation where the IPv4 address is in the range of 244.0.0.0 to 239.255.255.255. In some embodiments, these conversations can be not used for service detection.

[0135] In some embodiments, conversations with values below a threshold can be removed. As Figure 6C shown, in some embodiments, process 600 can retain the top conversations in traffic map 610 for tracking, where is an integer greater than 0. Conversations not among the top conversations can be determined to be background conversations with low value in detecting service types. In some implementations, the criteria for picking the top conversations can include the total number of packets. In this example, the features in traffic map 610 include the number of packets of the corresponding conversations within a time interval. For example, conversation Convo A has 40 packets (pkts), conversation Convo J has 100 packets, and so on. Process 600 can sort traffic map 610 using the packet count as a key, resulting in a sorted traffic map 620. According to the sorted traffic map 620, process 600 can retain only the top (e.g., = 3) conversations, as shown in traffic map 622. Although a sorting algorithm is shown, other algorithms can also be used to select the top conversations.

[0136] In some embodiments, process 600 can filter out conversations without using a sorting process. Figure 6D An example of process 600 is shown that filters out conversations with a packet count less than 15 without going through a sorting operation. For example, traffic map 622 can be directly derived from traffic map 610 without Figure 6C sorting operation.

[0137] In some implementations, the criteria for picking the top conversations can include the total size of the data blocks calculated by summing the sizes of all packets of each conversation. The process using this criterion can be similar to the process described above using packet count. For example, the total sizes of the data blocks of the conversations can be sorted, and then process 600 can retain the top conversations with the largest sizes.

[0138] Other criteria for picking the top number of conversations may also be used.

[0139] Figure 6E An example of a high-level diagram depicting further details of a service breakdown module or unit (or, for simplicity, service breakdown unit) 554 as shown is presented. In some embodiments, the service breakdown unit 554 may perform Figure 5B the operations described in Figure 6A .

[0140] In some embodiments, the service breakdown unit 554 may include a packet tracker module or unit 652, which may perform operations 602 and 604 as described above, among others, where traffic data 651 may be received and processed. The service breakdown unit 554 may also include a conversation filter module or unit 654, which may perform operations 606 as described above, among others, where a service map 655 may be generated. The service breakdown unit 554 may also include a service filter module or unit 656, which may perform operations 608 as described above, among others, where an output 657 may be generated. The output 657 may be input into an input processor system described in more detail herein. In some embodiments, conversations may be filtered based on throughput.

[0141] Figure 7 An example flowchart depicting a throughput-based service filtering process 700 for network service detection according to some embodiments is presented. Process 700 may track a new conversation or filter out the conversation. At operation 702, a new conversation may be received, such as in Figure 6A operation 606 in

[0142] In some embodiments, two throughput metrics for a conversation may be defined, an instantaneous throughput TputInst and a long-term average throughput TputAvg. The instantaneous throughput may be calculated for a short and predetermined time window. The long-term average throughput may be calculated for a long window, which may be a multiple of the short time window.

[0143] In some embodiments, the instantaneous throughput TputInst may be defined as:

[0144] (1)

[0145] where represents the length of the short observation window, and represents the total number of bytes sent and received for the conversation within the observation window.

[0146] For example, at operation 704, the instantaneous throughput TputInst of a conversation may be calculated, for example, using equation (1) above, where is a predetermined short observation time window.

[0147] In some embodiments, criteria can be defined to determine when to start tracking a conversation. For example, when it is detected that the TputInst of the conversation exceeds a threshold tracking can be started. For example, tracking can be started when the TputInst is greater than N bytes per second, where N is the threshold and is an integer greater than 0.

[0148] In operation 706, if the instantaneous throughput TputInst has not exceeded a predetermined threshold, process 700 can determine not to track the conversation and return to operation 702 to receive another new conversation.

[0149] When it is detected that the TputInst of the conversation exceeds the threshold, process 700 can proceed to operation 708. For example, process 700 can proceed to operation 708 to track the conversation only when it is detected that the TputInst of the conversation is greater than N bytes per second, where N is an integer greater than 0.

[0150] In operation 708, in some embodiments, process 700 can determine whether the number of currently tracked conversations (e.g., including the new conversation) exceeds a predetermined number of conversations K. In operation 710, if the number of currently tracked conversations (e.g., including the new conversation) exceeds K, process 700 can delete the conversation with the current minimum TputInst, e.g., delete from the tracking service mapping.

[0151] If in operation 708, process 700 can determine that the number of currently tracked conversations (e.g., including the new conversation) does not exceed the predetermined number of conversations K, it can proceed to operation 712, where it can update the long-term observation time .

[0152] In some embodiments, the following equations (2) and (3) can be used to determine the length of the long-term observation window. Long observation window length can be defined as a multiple of the short observation window . For example:

[0153] (2)

[0154] In some embodiments, M can be a function of the instantaneous throughput TputInst. Thus, M can be expressed as:

[0155] (3)

[0156] where M can be positively correlated with the value of TputInst. For example, , wherein, and are greater than 0 and can represent two linear coefficients that define the relationship between M and TputInst.

[0157] In some embodiments, the long-term average throughput TputAvg can be defined as:

[0158] (4)

[0159] wherein, represents the total number of bytes transmitted and received in the conversations within the long observation window.

[0160] Figure 8 describes and the exemplary relationship 800 therebetween.

[0161] In operation 712, after updating the long observation window length , process 700 can start or continue to track the traffic data regarding the conversation.

[0162] In operation 714, as the observation (or tracking) time T progresses, process 700 continues to track the traffic data regarding the conversation.

[0163] In operation 716, when it is determined that the observation time T has not exceeded the long-term observation time , process 700 can return to operation 712, wherein it can update the long-term observation time , as discussed above.

[0164] When it is determined that the observation time T has exceeded the long-term observation time , in operation 718, process 700 can determine whether the calculated long-term average throughput TputAvg has decreased below a predetermined threshold . <s

[0165] If the long-term average throughput TputAvg is still greater than the threshold , then in operation 720, the running observation time T can be reset (reset to 0). Then, process 700 can return to operation 712. In some embodiments, T can be reset to restart accumulating traffic statistics for decision-making. This can provide up-to-date traffic statistics.

[0166] In some embodiments, conversations with throughput below a predetermined throughput threshold can be removed from the traffic mapping. For example, when TputAvg is less than N1 bytes per second, where N1 is an integer greater than 0. As shown in operation 718, if the long-term average throughput TputAvg is below (or has dropped below) the threshold , then in operation 722, the conversation can be removed from the traced traffic mapping.

[0167] In some embodiments, a throughput-based traffic tracking mechanism can be particularly useful for bursty traffic such as video streaming, where bursts of data can be periodically sent from a server to a client.

[0168] Figure 8 Shows and an exemplary relationship 800 between TputAvg and TputInst. As shown, the long observation window length 820 is a multiple (M) of the short observation window 810. Each short observation window 810 has a corresponding calculated instantaneous throughput TputInst 812 calculated using equation (1) above. Then the long-term average throughput TputAvg 822 is calculated using equation (4) above.

[0169] In some embodiments, the value of M in equation (3) can be dynamically updated based on the maximum value of TputInst observed in subsequent short observation windows. If a larger value of TputInst is detected in observation window i before the last short observation window M, then the value of M can be updated based on that larger TputInst value, and then the new value of M and equation (2) can be used to update .

[0170] Figure 9 Shows a diagram 900 depicting exemplary throughput-based traffic filtering and the resulting traffic mapping. For example, the traffic mapping 910 can have conversations Convo A, J, M, F, and D and corresponding calculated TputInsts of 40Bps, 100Bps, 5Bps, 150Bps, and 10Bps at a certain point in time. The traffic filtering process can determine to only track conversations with a throughput above a threshold of 2OBps (i.e., TputInst greater than 2OBps). This filtering results in a traffic mapping 910a that only has the sorted conversations Convo F, J, and A and corresponding calculated TputInsts of 150Bps, 100Bps, and 40Bps. These conversations are now further tracked for their throughput. During the time interval After that, the long-term average throughput TputAvg of each conversation is calculated and stored in the traffic map, which is now depicted as traffic map 910b. When the long-term average throughput TputAvg drops below a threshold the traffic filtering process can determine to remove the conversation or stop tracking the conversation. In this example, conversations with a long-term average throughput TputAvg that drops below 25 Bps can be removed, resulting in traffic map 910c.

[0171] Figure 10 An example of an input processing procedure 1000 for network service detection according to some embodiments is shown. Briefly returning Figure 5A , after operation 504 (where the network traffic flow has been decomposed to produce multiple smaller traffic flows), procedure 1000 discloses further details of operation 506 as Figure 5A shown. The input processing procedure 1000 can process the features extracted from the traffic decomposition process and prepare the features in an appropriate form for the next system component.

[0172] In operation 1002, procedure 1000 can receive input data, such as input data from a traffic data decomposition process or unit. In some embodiments, procedure 1000 can receive data 657 from a traffic filter module or unit 656, as Figure 6E shown.

[0173] In operation 1004, in some embodiments, procedure 1000 can extract features from the input data and fuse the features from the input data with the information 1003 of additional sensors. The additional sensor information 1003 can be optional because not all device types have all sensors. The additional sensor information can include but is not limited to the following items:

[0174] - List of running applications: IDs of running applications (multiple values; one value for each application).

[0175] - Application power consumption: Power consumption of running applications (multiple values; one value for each running application).

[0176] - Touchscreen interaction: Count of the user's touchscreen interactions during a burst (one value).

[0177] - Camera usage: A value indicating whether the camera is being used (one value; e.g., 1 = the camera is being used, 0 = the camera is not being used).

[0178] - Speaker usage: A value indicating whether the speaker is being used (one value; e.g., 1 = the speaker is being used, 0 = the speaker is not being used).

[0179] - Microphone Usage: A value indicating whether the microphone is in use (a value; e.g., 1 = microphone is in use, 0 = microphone is not in use).

[0180] In some embodiments, additional sensor information can be used to improve the performance of service type detection. For example, in a scenario where the user is making a video call (real-time service), it is likely that the microphone, speaker, and / or camera are enabled on the device. This information can be very helpful in separating real-time services from non-real-time services.

[0181] In some embodiments, a fused feature ( ) can be defined as follows:

[0182]

[0183] where, is a service feature, is an additional sensor feature, and F() is a fusion operation.

[0184] Figure 11 and Figure 12 provide further details of the operation F() for generating the fused feature.

[0185] Return Figure 10 , process 1000 can feed the prepared features (e.g., the fused feature ) from operation 1004 to operation 1006.

[0186] In operation 1006, process 1000 can store and manage conversations and their corresponding features in a cache (e.g., a least recently used (LRU) cache). The LRU cache can aggregate data for the corresponding conversations it is saving.

[0187] In some embodiments, the LRU cache can be an ordered hash map. Each entry in the LRU cache has a key (e.g., a conversation), and can be linked to a value that holds the features for each time step. The features for each time step can be stored in a first-in-first-out buffer. The buffer can have a capacity of n elements. In some embodiments, n can have a default value of 6. However, other default values can also be considered.

[0188] In some embodiments, the fusion operation F() can be a simple array concatenation operation as shown in Figure 11 . For example, conversation 1100 can include n service features (0 to n - 1) captured at time t. These service features are shown in array 1102, with service feature elements to . Array 1104 shows m exemplary sensor information (or features) captured at the corresponding time t to . In some embodiments, the fusion operation 1000 may concatenate the service feature elements in the array 1102 to with the sensor information in the array 1104 to . The array 1106 shows the concatenated array resulting from the concatenation operation, including the fused feature ( ) elements.

[0189] In some embodiments, the process 1000 may include extracting embedded features from the service features and sensor features using a neural network. In some embodiments, a neural network autoencoder may be used.

[0190] Figure 12 Shows an example autoencoder 1210 for generating fused features. The service feature 1202 and the sensor feature 1204 may be fed into the autoencoder 1210. The autoencoder 1210 may use an encoding function to convert the service feature 1202 and the sensor feature 1204 into a fused feature 1212. In some embodiments, the fused feature 1212 may have a size smaller than the combination of the service feature 1202 and the sensor feature .

[0191] It should be noted that this method requires training the model of the autoencoder. In some embodiments, existing data may be used to train the autoencoder. Training the autoencoder does not require any labels other than the input itself, because the goal of training is to encode and reconstruct the input. For example, during training, the fused feature 1212 may be reconstructed into the service feature 1222 and the sensor feature 1224. Thus, the training process can produce an effective model of the autoencoder.

[0192] Figure 13 Shows an example of a caching operation 1300 for operation 1006 according to some embodiments. In this example, for instance, the service map 1302 is received from operation 1004. In some embodiments, when there is data for a conversation (e.g., the features of conversation F , the features of conversation N When (), process 1300 can route the data to the corresponding buffer in the LRU cache 1320. In some embodiments, the cache manager 1310 can operate to execute process 1300.

[0193] In some embodiments, when an entry associated with a conversation is currently in the cache 1320 and there is no data for it in the service mapping, the cache manager 1310 can insert a blank feature set into its buffer. For example, conversation A is currently in the LRU cache 1320, but there is no data for it in the service mapping 1302. In operation 1312, the cache manager 1310 can insert the blank feature set 1314 into its buffer.

[0194] In some embodiments, when the number of blank feature sets in the buffer reaches the capacity of the buffer (i.e., the buffer now only has blank sets), the cache manager can signal the LRU cache 1320 to evict the entry.

[0195] In some embodiments, the LRU cache 1320 can also reorder its entries based on the recent usage of the entries. For example, the most recently accessed entry can be placed at the head, and the least recently accessed entry can be placed at the tail. If the LRU cache has reached its storage limit and there is a new entry to be added to the cache, the least recently accessed entry can be evicted (popped) to make room for the new entry. As an example, given that the LRU capacity is 7 (exemplary number) and all 7 slots are occupied, when a new entry is introduced, the oldest entry in the LRU cache can be evicted to make room for the new entry.

[0196] Figure 14 An example of a diagram depicting the reordering operation 1400 of the LRU cache according to some embodiments is shown. For example, if conversation N is the most recently accessed, it can be placed at the head 1402. If conversation F is the least recently accessed, it can be placed at the tail 1410. In some implementations, the cache can use the Get() and Put() functions to perform the reordering. If the LRU cache has reached its limit and there is a new entry to be added to the cache, conversation F located at the tail 1410 can be evicted. In some implementations, the cache can use the Pop() function to perform the eviction.

[0197] Figure 15 An example of a high-level diagram depicting an input processing module or unit (or input processing unit for brevity) 556 for network service detection according to some embodiments is shown. Figure 15 Disclosed Figure 5B and Figure 5CFurther details of the input processing unit 556 shown. In some embodiments, the input processing unit 556 may perform Figure 10 the process 1000 described in

[0198] In some embodiments, the input fusion module or unit 1510 may receive the service characteristics 1502 and the sensor characteristics 1504 and perform Figures 10 to 12 the operation 1004 described in, fusing the service characteristics and additional sensor characteristics. The cache manager module or unit (or may be used as a cache manager herein for simplicity and as shown) 1520 may receive the service mapping from the input fusion module or unit 1510. The cache manager module or unit 1520 may perform the operations of the cache manager 1310 described above and manage the LRU cache 1530. As described above, through the operation 1522, the cache manager module or unit 1520 may, for example, include evicting stale conversations and reordering the LRU cache 1530.

[0199] In some embodiments, the content of the LRU cache may be fed as an input 1540 to a machine learning (ML)-based network service detection module or unit, for example, as Figure 5B the ML-based service detection module or unit 558 shown. For example, the input to the ML model for each conversation may be its buffer in the LRU cache. As described in further detail below, the input processor may perform a buffer size check operation on the buffers stored in the LRU cache (see Figure 17 1708 in

[0200] Figure 16 FIG. 1600 shows an example of a diagram depicting the formation of the input to the ML model according to some embodiments. As Figure 16 shown, in some embodiments, the process 1600 for forming the input to the ML model for each conversation may include sliding a time window 1602 (e.g., of size w) over a series of features 1604 of that conversation. For example, at time t, the input 1604 may include a combination of multiple feature vectors, such as . In some implementations, w may have a default value of 6. In the example, a sequence of 3 seconds (3000 ms) may be used, where each time step (or the shown burst b) is 500 ms. Thus, the total number of time steps for each input is . In some implementations, the buffer size may have the same number of entries, for example, 6 in this example. Thus, the input at time t may be or may include the following feature vectors 。

[0201] In some embodiments, to improve the performance of the ML-based service detection module or unit, the service types can be predefined. In some examples, the services or applications within the same service may need to have similar requirements (such as latency requirements), making this classification meaningful. In other examples, the services or applications assigned to the same service type may need to have a distinct common signature, such that the detection accuracy can be high enough.

[0202] In some embodiments, three (3) service types can be defined. For example, these service types can include cloud gaming (CG) service, real-time (RT) service, and non-real-time (NRT) service. Although three service types are being described, the number of service types is not limited to three, but can be less than or more than three.

[0203] Cloud gaming applications (e.g., Xbox Cloud Gaming) typically can have very high and consistent downlink activity. The interaction between the uplink activity and the downlink activity of these cloud gaming applications can also be high. This information can be advantageously used to identify the cloud gaming category.

[0204] Real-time applications can include services with video calls and audio calls (e.g., WhatsApp, Zoom, Viber), and highly interactive mobile games (e.g., PUBG) will belong to this category. Similarly, this can be advantageously used to identify the real-time category.

[0205] The non-real-time category can include services that may not require real-time interaction. Examples of non-real-time applications can include video streaming (e.g., Netflix, Disney+), audio streaming (e.g., Pandora and Spotify), web browsing, file download (DL), file upload (UL), etc.

[0206] In some embodiments, when the buffer of the conversation in the LRU cache can be fed as input to the ML model, the size of the buffer can be checked.

[0207] Figure 17 An example of FIG. 1700 depicting exemplary inputs and outputs of the ML model according to some embodiments is shown. As Figure 17 shown, in some embodiments, at operation 1702, a request for service type prediction can be received. In some examples, an event listener process can receive this request. At operation 1706, the content from the LRU cache 1704 can be received (or obtained). In some embodiments, all the entries (or content) in the LRU can be obtained. Figure 17The example in Figure 17 shows that the content of the received LRU cache includes three conversations A, D, and N and their corresponding buffers A, D, and N. In this example, Convo A may include real-time traffic, Convo D may include non-real-time traffic, and Convo N may include cloud gaming traffic. In operation 1708, the sizes of each of the buffers A, D, and N can be checked. For example, it can be checked whether each buffer has reached its capacity. In the

[0208] example of Figure 17 , the buffer capacity is n entries, where n is a positive integer. As shown, both buffers A and D have reached their capacity of n buffer entries. Buffer N has only 1 entry and thus has not reached its capacity. In some embodiments, in operation 1710, only the entries of conversations A and D that pass the buffer size check (meet the size requirement) are passed to the network service detection module or unit 1712, which is ML-based service detection in this example. Buffers that have not reached capacity may take more time to fill up. In some examples, these buffers may hold low-capacity traffic and may not require service type detection.

[0209] In this example, two (2) conversation entries pass the buffer size check 1708 and are fed into the ML-based network service detection module or unit 1712, and there are two (2) corresponding output service type predictions 1720 (one for each input conversation), shown as one (1) real-time service type and one (1) non-real-time service type.

[0210] In some embodiments, the ML-based service detection module or unit 1712 may have only one classifier (e.g., only a coarse-grained classifier). In some embodiments, the ML-based service detection module or unit 1712 may have a multi-layer classifier (e.g., a coarse-grained classifier plus several fine-grained classifiers).

[0211] Figure 18 FIG. shows an exemplary multi - layer architecture 1800 depicting an ML - based service detection module or unit according to some embodiments. As Figure 18 shown, in some embodiments, a coarse - grained classifier 1802 may classify service types into multiple categories 1810. After the coarse - grained classifier 1802 classifies the service types into multiple categories 1810, a fine - grained classifier 1804 (which may include multiple sub - classifiers) may perform fine - grained classification on the results from the coarse - grained classifier 1802. In some embodiments, the fine - grained classifier 1804 may further divide the categories 1810 into sub - categories 1812. For example, in Figure 17 the example of, a second layer (L2) of the ML - based service detection module or unit may also be implemented, where real - time service categories and non - real - time service categories may be further divided into sub - service categories.

[0212] In some embodiments, the classifier may be implemented using any supervised ML techniques, including but not limited to traditional algorithms such as support vector machines (SVMs), K - nearest neighbors (KNNs), random forests, or state - of - the - art deep - learning neural networks.

[0213] Figure 19 FIG. shows an exemplary two - layer architecture 1900 depicting an ML - based service detection module or unit according to some embodiments. As described above, when a request for prediction is received, the conversation content may be received from the LRU cache 1902. A buffer check operation 1904 may be performed to feed only the conversations whose buffers have reached capacity to the first - layer (L1) service detection module or unit 1906.

[0214] In some embodiments, the L1 service detection module or unit 1906 may generate a first - layer (L1) prediction map 1908. For example, the L1 prediction map 1908 may include 3 service types (cloud gaming (CG), real - time (RT), and non - real - time (NRT)). Each service type may include one or more corresponding conversations. In some embodiments, the L1 prediction results may be organized into a hash map (L1 prediction map 1908), where each entry in the map may contain the service category as a key and a list of conversations belonging to that category as a value.

[0215] In some embodiments, an L1 post - processing module or unit (shown as L1 post - processing) 1933 may receive the L1 prediction map 1908 and perform a post - processing scheme described in further detail below to generate a decision table 1935 (e.g., similar to Figure 17 Table 1720 in).

[0216] In some embodiments, the input acquirer 1910 may receive conversations belonging to each category (e.g., real-time conversation set (shown as RT Convo set) 1914 and non-real-time conversation set (shown as NRT Convo set) 1916) from the L1 prediction mapping 1908. The input acquirer 1910 may also receive the current service input from the LRU cache 1902 and perform another buffer check 1912. In some embodiments, both L1 (see operation 1904) and the second layer (L2) have their own buffer size checks. In this case, the requirements for the buffer sizes of L1 and L2 may be different. For example, the L1 buffer requirement may have a default capacity of 6, while the L2 buffer requirement may have a default capacity of 12. The conversation sets passing through the buffer check 1912 may be fed as inputs (shown as NRT input 1918 and RT input 1920) to the L2 service detection module or unit 1922.

[0217] Then, the L2 service detection module or unit 1922 may further divide the NRT input 1918 and RT input 1920 into sub-service categories. The L2 service detection module or unit 1922 may generate L2 mappings 1924, 1926 for each service type. For example, the NRT L2 mapping (shown as L2 prediction NRT map) 1924 may include sub-categories file transfer (file download / upload FD), YouTube (YT), and video streaming (VS) and their corresponding conversations. The RT L2 mapping (shown as L2 prediction RT map) 1926 may include sub-categories mobile game (MG), audio call (AC), and video call (VC) and their corresponding conversations.

[0218] In some embodiments, the sub-service prediction outputs 1924 and 1926 from the L2 service detection module or unit 1922 may be passed to their corresponding L2 post-processing modules or units (e.g., shown as L2 RT post-processing 1932 and L2 NRT post-processing 1930). In some embodiments, as described in further detail below, the L2 post-processing module or unit may be implemented similarly to the L1 post-processing module or unit 1933. At this time, additional sensor information 1950 may also be used in the L2 post-processing modules or units 1930, 1932 to determine the final sub-service types l2_nrt 1940 and l2_rt 1942.

[0219] As Figure 5A and Figure 5B shown, in some embodiments, the post-processing module or unit 560 may receive the prediction from the service detection module or unit 558 and perform operation 510.

[0220] In some embodiments, the post-processing module or unit 560 may store the most recent n past multi-label predictions generated by the ML-based service detection module or unit (n may be dynamically determined to work with a specific application), and use this information to generate decisions accordingly. In some embodiments, n may have a default value of 5.

[0221] In some embodiments, the post-processing module or unit 560 may organize the predictions from the service detection module or unit 558 into a table, as Figure 20 shown in the exemplary Table 2000 in

[0222] As Figure 20 shown, each column of Table 2000 may be a separate buffer for a corresponding service, where n is the size of the buffer, and m is the number of service types s. In some embodiments, the buffer may be FIFO, where buffer slot t = 0 may have the most recent prediction p.

[0223] In some embodiments, the post-processing module or unit 560 may apply different voting schemes to determine the service type in the service flow. For example, in some embodiments, the post-processing module or unit 560 may perform a majority voting decision to adopt the class label with the most votes as the final decision. Generally, in majority voting, the predicted class label for a particular sample is the class label that represents the majority of the class labels predicted by each individual classifier. In some embodiments, the decision on whether each service exists may be determined as

[0224] (5)

[0225] where is the prediction shown above in Figure 20 where 0 indicates not activated, and 1 (non-zero) indicates activated. The Max function is used to determine activation. If it is activated, it can be predicted that the service exists in the service. Otherwise, it can be predicted that the service does not exist.

[0226] Figure 21 FIG. shows a diagram depicting an exemplary voting scheme 2100 according to some embodiments. For example, the prediction 2110 (e.g., outputs 1924 and 1926 (in Figure 19 ) can be processed by the majority voting scheme algorithm 2120 (e.g., Figure 19 the L2 NRT post-processing 1930 and L2 RT post-processing 1932 in Figure 19 ). The majority voting scheme algorithm 2120 may apply Equation (5) to the prediction 2110. The decision output 2122 from the majority voting scheme algorithm 2120 may be the prediction with the most votes (e.g.,

[0227] In some embodiments, the post - processing module or unit 560 may perform a weighted voting scheme. Different from the majority voting scheme described above, the weighted voting scheme may assign voting rights to each vote or raw prediction. The most recent raw prediction may be assigned the most voting rights , and the subsequent raw predictions at previous time steps may be decayed at a rate determined by a hyperparameter (which may have a default value of 0.1). In some embodiments, earlier raw predictions may have less voting rights compared to the most recent raw prediction.

[0228] Figure 22 FIG. shows a diagram depicting an exemplary weighted voting scheme 2200 according to some embodiments. For example, a prediction 2210 (e.g., outputs 1924 and 1926 (in Figure 19 )) may pass through a weighted voting scheme algorithm 2220 (e.g., in L2 NRT post - processing 1930 and L2 RT post - processing 1932 in Figure 19 ). Generally speaking, in weighted voting, each classifier may have a weight attached to its vote. In some embodiments, voting rights 2212 may be applied to the prediction 2210 before passing the prediction through the weighted voting scheme 2220. Figure 22 An exemplary equation for the voting rights 2212 of each prediction 2210 is shown in. The decision output 2222 from the weighted voting scheme algorithm 2220 may be the prediction with the most votes (e.g., Figure 19 the NRT decision 1940 and RT decision 1942 in).

[0229] In some embodiments, the post - processing module or unit 560 may perform a biased voting scheme. Figure 23 FIG. shows a diagram depicting an exemplary biased voting scheme 2300 according to some embodiments. In this scheme, a plurality of threshold filters may be defined corresponding to the number of defined service types. For example, as Figure 23 shown, three threshold filters 2312 to 2316 are defined for three defined service types (cloud gaming, real - time, and non - real - time). If the number of detections of the service type in the buffer slot 2310 (as shown in, for example Figure 20 ) exceeds the threshold, it is predicted that the service type 2322 to 2326 exists in the traffic.

[0230] In some embodiments, the decision can start from the service threshold that is the most strictly required in terms of latency requirements (e.g., cloud gaming services require stricter latency requirements than real-time services and non-real-time services because cloud gaming services require smaller latency than other service types), which may require a minimum threshold (e.g., the minimum number of detections in n buffer slots). The decision can continue through a multi-stack threshold system until it passes one of the thresholds, which means that the decision is the corresponding service type.

[0231] In some embodiments, the post-processing module or unit 560 can perform an enhanced bias voting scheme. Generally speaking, the enhanced bias voting scheme can be substantially similar to the bias voting scheme. The difference is that the enhanced bias voting scheme can utilize additional sensor information (such as the sensor information described previously herein).

[0232] Figure 24 A diagram depicting an exemplary enhanced bias voting scheme 2400 according to some embodiments is shown. For example, although Figure 24 other elements of Figure 23 are similar, additional sensor information 2410 can be used. For example, if the camera is enabled and the predicted buffer slot can contain a real-time (RT) prediction, the scheme 2400 can determine that the user is likely using a VOIP video call. In this case, another threshold for the RT service can be used, which is lower than the default RT threshold (described in the bias voting scheme). This strategy can effectively help detect the RT service faster and more easily.

[0233] In another example, the currently concerned application can be a game, and the system can detect this information and provide this information to the post-processing unit 560. In this case, the predicted buffer slot can currently contain a cloud gaming (CG) prediction. Then a lower CG threshold can be used to make a decision on whether the CG service type exists in the traffic flow.

[0234] In some embodiments, a machine learning model can be trained to predict the type of service. For example, a list of running applications / programs (packages) that generate network traffic can be obtained. This list can include information about the applications / programs, such as their process ID (PID). Other information related to the network traffic is also obtained. This information can include IP addresses, such as the server IP address of the active connection. A network analyzer tool can be used to track network system calls to obtain network and connection information. The traffic logs of the active connections can be retained. The information from the traffic logs can be cross-referenced with the server IP addresses collected from the network analysis tool to identify which data comes from which applications / programs. The data obtained can be used for training.

[0235] According to an embodiment of the present disclosure, a method performed by a user equipment (UE) in a wireless communication system is provided. The method may include: receiving network traffic from a network; decomposing the network traffic into one or more data streams based on source information and destination information; storing the data streams in a traffic map, where the traffic map includes data stream identification information and traffic information of the data streams in an observation time window; filtering the stored data streams based on one or more traffic characteristics of the traffic information of the data streams; and using machine learning to determine a service type for each of the filtered data streams. In an embodiment, the source information may include a source Internet Protocol (IP) address or a source port, and the destination information may include a destination IP address or a destination port.

[0236] In an embodiment, the stored data streams may be filtered based on the number of packets or the number of bytes in each of the stored data streams.

[0237] In an embodiment, the stored data streams may be filtered based on the traffic throughput in each of the stored data streams.

[0238] In an embodiment, the method may further include: calculating a first throughput in the observation time window for each filtered data stream; and storing the filtered data streams with a throughput greater than the first throughput in the traffic map.

[0239] In an embodiment, the method may further include: removing the stored filtered data stream with the minimum throughput based on determining that the number of stored filtered data streams is greater than a first throughput threshold.

[0240] In an embodiment, the method may further include: calculating a second throughput in a second observation time window for each stored filtered data stream, where the second observation time window is longer than the observation time window; and removing the stored data stream from the traffic map based on determining that the second throughput of the stored filtered data stream is less than a second throughput threshold.

[0241] In an embodiment, the method may further include: receiving information from one or more sensors of the UE, and performing a fusion operation based on the stored filtered data streams and the information from the one or more sensors.

[0242] In an embodiment, a multi-layer machine learning model having a first layer and a second layer may be used to determine the service type, and the first layer of the multi-layer machine learning model may determine the service type, and the second layer of the multi-layer machine learning model may further divide the service type into sub-categories.

[0243] In an embodiment, the method may further include: receiving current information from one or more sensors of the UE, and determining the service type based on the current information from the one or more sensors.

[0244] According to an embodiment of the present disclosure, a user equipment (UE) in a wireless communication system is provided. The UE may include: a transceiver; and at least one processor, coupled to the transceiver and configured to: receive network traffic from a network via the transceiver; decompose the network traffic into one or more data streams based on source information and destination information; store the data streams in a traffic map, where the traffic map includes data stream identification information and traffic information of the data streams in an observation time window; filter the stored data streams based on one or more traffic characteristics of the traffic information of the data streams; and use machine learning to determine a service type for each of the filtered data streams.

[0245] In an embodiment, the source information may include a source Internet Protocol (IP) address or a source port, and the destination information may include a destination IP address or a destination port.

[0246] In an embodiment, the at least one processor may be configured to: filter the stored data streams based on the number of packets or the number of bytes in each of the stored data streams.

[0247] In an embodiment, the at least one processor may be configured to: filter the stored data streams based on the traffic throughput in each of the stored data streams.

[0248] In an embodiment, the at least one processor may be configured to: calculate a first throughput in the observation time window for each filtered data stream; and store the filtered data streams with a throughput greater than the first throughput in the traffic map.

[0249] A method and apparatus for detecting a network service type by grouping applications having similar latency requirements and data characteristics together to form a service type. A machine learning algorithm may be used to detect a traffic pattern in a traffic flow by using features extracted from the grouping information and optionally additional sensor information. Subsequently, the output of the machine learning module may undergo a post-processing process, which may employ different techniques to make a final decision about the network service type using the current prediction and past predictions.

[0250] As used herein, unless otherwise specified, a reference to an element in the singular form is not intended to mean "one and only one", but rather "one or more". For example, "a" module may refer to one or more modules. Without further limitation, an element that begins with "a", "the", or "said" does not exclude the presence of additional identical elements.

[0251] The title and subtitle (if any) are for convenience only and do not limit the invention. The term "exemplary" is used to indicate being used as an example or illustration. With respect to the terms "comprising", "having", etc., such terms are intended to be inclusive in a manner similar to the term "including" and are construed as "including" when used as transitional terms in claims. Relative terms such as first and second can be used to distinguish one entity or action from another entity or action, and do not necessarily require or imply any such actual relationship or order between these entities or actions.

[0252] Phrases such as an aspect, the aspect, another aspect, some aspects, one or more aspects, an embodiment, the embodiment, another embodiment, some embodiments, one or more embodiments, an example, the example, another example, some examples, one or more examples, a configuration, the configuration, another configuration, some configurations, one or more configurations, the subject technology, the disclosure, the present disclosure, and other variations thereof are for convenience only and do not mean that the disclosure involving such phrases is essential to the subject technology or that such disclosure applies to all configurations of the subject technology. The disclosure involving such phrases may apply to all configurations, or one or more configurations. The disclosure involving such phrases may provide one or more examples. Phrases such as an aspect or some aspects may refer to one or more aspects, and vice versa, and the same applies to other aforementioned phrases.

[0253] The phrase "at least one" before a series of items and the terms "and" or "or" used to separate any items modify the entire list rather than each member of the list. The phrase "at least one" does not require the selection of at least one item; rather, this phrase allows for meanings including interpretations such as at least one in any one of the items, and / or at least one in any combination of the items, and / or at least one in each of the items. For example, each of the phrases "at least one of A, B, and C" or "at least one of A, B, or C" refers to only A, only B, or only C; any combination of A, B, and C; and / or at least one in each of A, B, and C.

[0254] As used herein, the term "coupled" and its derivatives refer to any direct or indirect communication between two or more elements, whether or not these elements are in physical contact with each other. The terms "send", "receive", and "communicate" and their derivatives can include both direct and indirect communication. The terms "comprise" and "include" and their derivatives mean inclusion without limitation. The phrase "associated with" and its derivatives mean including, being included within, interconnected with, containing, being contained within, connected to or coupled with, capable of communicating with, cooperating with, interlacing, juxtaposing, adjacent to, bound to or coupled to, having, having the attribute of, having a relationship to or with, etc. The term "controller" means any device, system, or portion thereof that controls at least one operation. Such a controller can be implemented in hardware or a combination of hardware and software and / or firmware. The functions associated with any particular controller can be centralized or distributed, whether local or remote.

[0255] The various functions described herein can be implemented or supported by one or more computer programs, each of which can be formed from computer-readable program code and implemented in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, related data, or portions thereof suitable for implementation in appropriate computer-readable program code. The phrase "computer-readable program code" can include any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" can include any type of medium that can be accessed by a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drive, compact disk (CD), digital video disk (DVD), or any other type of memory. A non-transitory computer-readable medium can include a medium in which data can be permanently stored and a medium in which data can be stored and subsequently rewritten, such as a rewritable optical disk or an erasable memory device.

[0256] It should be understood that the specific order or hierarchy of steps, operations, or processes disclosed is for illustrative methods only. Unless otherwise expressly stated, it should be understood that the specific order or hierarchy of steps, operations, or processes can be performed in a different order. Some steps, operations, or processes can be performed simultaneously, or can be performed as part of one or more other steps, operations, or processes. The appended method claims (if any) present the elements of the various steps, operations, or processes in an exemplary order, but are not meant to be limited to the specific order or hierarchy presented. These can be performed serially, linearly, in parallel, or in a different order. It should be understood that the described instructions, operations, and systems can generally be integrated together in a single software / hardware product or packaged into multiple software / hardware products.

[0257] This disclosure is provided to enable those skilled in the art to practice the various aspects described herein. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring the concepts of the subject technology. This disclosure provides various examples of the subject technology, but the subject technology is not limited to these examples. Various modifications to these aspects will be apparent to those skilled in the art, and the principles described herein can be applied to other aspects.

[0258] All structural and functional equivalents of the elements throughout the aspects described in this disclosure that are known or later become known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be covered by the claims.

[0259] The title, background, brief description of the drawings, abstract, and drawings are hereby incorporated into this disclosure and are provided as illustrative examples of the disclosure rather than as limiting descriptions. It should be understood that they are not intended to limit the scope or meaning of the claims. Additionally, in the detailed description, it can be seen that the description provides illustrative examples and, for the purpose of simplifying the disclosure, various features are grouped together in various embodiments. This method of disclosure should not be interpreted as reflecting an intention that the claimed subject matter requires more features than are expressly recited in each claim. On the contrary, as reflected in the following claims, the inventive subject matter has less features than all the features of the disclosed single configuration or operation. The following claims are hereby incorporated into the detailed description, where each claim stands on its own as a separately claimed subject matter.

[0260] The claims are not intended to limit the aspects described herein, but rather to conform to the full scope consistent with the claim language and cover all legal equivalents. Nevertheless, no claim is intended to cover subject matter that fails to meet the requirements of the applicable patent law, nor should it be construed in such a way.

Claims

1. A method performed by a user equipment (UE) in a wireless communication system, the method comprising: Receiving network traffic from a network; Decomposing the network traffic into one or more data streams based on source information and destination information; Storing the data streams in a traffic map, wherein the traffic map includes data stream identification information and traffic information of the data streams in an observation time window; Filtering the stored data streams based on one or more traffic characteristics of the traffic information of the data streams; and Using machine learning to determine a service type for each of the filtered data streams.

2. The method according to claim 1, wherein The source information includes a source Internet Protocol (IP) address or a source port, and the destination information includes a destination IP address or a destination port.

3. The method according to claim 1, wherein Filtering the stored data streams based on the number of packets or the number of bytes in each of the stored data streams.

4. The method according to claim 1, wherein, Filtering the stored data streams based on the traffic throughput in each of the stored data streams.

5. The method according to claim 4, further comprising: Calculating a first throughput in the observation time window for each filtered data stream; And Storing the filtered data streams with a throughput greater than the first throughput in the traffic map.

6. The method according to claim 5, further comprising: Removing the stored filtered data stream with the minimum throughput based on determining that the number of stored filtered data streams is greater than a first throughput threshold.

7. The method according to claim 6, further comprising: Calculating a second throughput in a second observation time window for each stored filtered data stream, wherein the second observation time window is longer than the observation time window; and Removing the stored data stream from the traffic map based on determining that the second throughput of the stored filtered data stream is less than a second throughput threshold.

8. The method according to claim 1, further comprising: Receiving information from one or more sensors of the UE, and performing a fusion operation based on the stored filtered data streams and the information from the one or more sensors.

9. The method according to claim 1, wherein Using a multi-layer machine learning model having a first layer and a second layer to determine the service type, and wherein the first layer of the multi-layer machine learning model determines the service type, and the second layer of the multi-layer machine learning model further divides the service type into sub-categories.

10. The method according to claim 1, further comprising: Receiving current information from one or more sensors of the UE, and determining the service type based on the current information from the one or more sensors.

11. A user equipment (UE) in a wireless communication system, the UE comprising: A transceiver; And At least one processor, coupled to the transceiver and configured to: Receive network traffic from a network via the transceiver; Decompose the network traffic into one or more data streams based on source information and destination information; Store the data streams in a traffic map, wherein the traffic map includes data stream identification information and traffic information of the data streams in an observation time window; Filter the stored data streams based on one or more service characteristics of the service information based on the data streams; and Use machine learning to determine the service type for each of the filtered data streams.

12. The UE according to claim 11, wherein, The source information includes a source Internet Protocol (IP) address or a source port, and the destination information includes a destination IP address or a destination port.

13. The UE according to claim 11, wherein, The at least one processor is configured to: filter the stored data streams based on the number of packets or the number of bytes in each of the stored data streams.

14. The UE according to claim 11, wherein, The at least one processor is configured to: filter the stored data streams based on the service throughput in each of the stored data streams.

15. The UE according to claim 14, wherein, The at least one processor is configured to: Calculate a first throughput in the observation time window for each filtered data stream; and Store the filtered data streams with a throughput greater than the first throughput in the service map.

Images