Enabling New Radio Cellular Quality of Service for Non-Internet Protocol Data Sessions

Abstract

Various aspects of this disclosure relate to achieving New Radio (NR) cellular Quality of Service (QoS) for non-Internet Protocol (IP) data sessions. In certain aspects of this disclosure, a non-IP-based Protocol Data Unit (PDU) session is established, and a packet filter is selected based on at least one aspect of data packets formatted in a non-IP format associated with the non-IP PDU session. The transmission of these data packets is then filtered according to this packet filter.

Description

[0001] This application is a divisional application of patent application No. 201880029793.6, entitled "A New Radio Cellular Service Quality for Non-Internet Protocol Data Sessions", filed on March 7, 2018.

[0002] Cross-reference to related applications

[0003] This application claims priority and benefit to provisional application No. 62 / 502,692 filed with the U.S. Patent and Trademark Office on May 7, 2017, and non-provisional application No. 15 / 913,745 filed with the U.S. Patent and Trademark Office on March 6, 2018, the entire contents of which are incorporated herein by reference and are to be described in their entirety below for any purpose of application. Technical Field

[0004] In general, the technologies discussed below relate to wireless communication systems, and more specifically, to New Radio (NR) cellular Quality of Service (QoS) for non-Internet Protocol (IP) data sessions (e.g., Ethernet, unstructured, etc.). Background Technology

[0005] In wireless communication networks, Quality of Service (QoS) can be provided to network users. QoS mechanisms typically control parameters of a wireless network, such as its performance, reliability, and availability. These parameters can be determined based on certain metrics, such as network coverage and accessibility, and its call quality (especially audio and video quality). In 3GPP and 4G cellular networks, the network can configure User Equipment (UE) to filter uplink (UL) user data packets to route them to different bearers receiving different QoS levels. This is typically done by assigning one or more “packet filters” to the bearers, where each packet filter has an associated evaluation priority index. Before sending an UL user data packet, the UE checks whether the packet matches any of the packet filters configured by the network, in ascending order of the evaluation priority index, and sends the packet on the bearer associated with the packet filter for which a match exists.

[0006] Because all data connections in 3GPP and 4G cellular networks were based on the Internet Protocol (IP) until version 12, the format of packet filters (as specified in sub-clause 10.5.6.12 of 3GPP TS 24.008) depended on the content of the IP header of the data packets. Therefore, packet filters could include one or more of the following criteria: source IP address matches a certain value; destination IP address matches a certain value; source port number matches a certain value; destination port number is within a certain range; source port range matches a certain value; protocol identifier / next header type field matches a certain value; security parameter index type matches a certain value; service type / service category type matches a certain value; and / or flow tag type matches a certain value.

[0007] In fifth-generation (5G) networks, “Ethernet” and “unstructured” types of data connections (also known as Protocol Data Unit (PDU) sessions) have been introduced (see, for example, 3GPP TS 23.501). However, since user data packets for these PDU session types are not required to have IP headers, the current format of packet filters does not allow filtering of the corresponding packets to provide differentiated QoS. Therefore, providing solutions for implementing QoS within “Ethernet” or “unstructured” type PDU sessions would be desirable.

[0008] Furthermore, 5G introduces the use of reactive QoS on cellular networks. When reactive QoS is activated, the UE needs to construct its own UL packet filter based on the received DL user data packets. While the mechanism for the UE to construct its own UL packet filter for IP data is well-known (see, for example, 3GPP TS 24.139 subclauses 5.2.3 and 5.2.4), no such procedure is specified for “Ethernet” or “unstructured” PDU sessions. Therefore, when reactive QoS is enabled, providing a solution for constructing the UL packet filter at the UE for “Ethernet” or “unstructured” PDU sessions would be desirable. Summary of the Invention

[0009] To provide a basic understanding of one or more aspects of this disclosure, a brief overview of those aspects is given below. This overview is not an exhaustive summary of all anticipated features of this disclosure, nor is it intended to identify key or essential elements of all aspects of this disclosure or to describe the scope of any or all aspects of this disclosure. Its sole purpose is to present some concepts of one or more aspects of this disclosure in a simple form as a prelude to the detailed description that follows.

[0010] In the examples below, the disclosed aspects relate to implementing New Radio (NR) cellular Quality of Service (QoS) for non-Internet Protocol (IP) data sessions (e.g., Ethernet, unstructured, etc.). For example, solutions are disclosed for how to extend current packet filter formats to implement QoS within Protocol Data Unit (PDU) sessions for non-IP-based types (e.g., Ethernet, unstructured, etc.). Solutions are also disclosed for constructing packet filters at the User Equipment (UE) for non-IP-based PDU sessions when reflective QoS is enabled.

[0011] In one example, a method for wireless communication is disclosed. The method includes: establishing a non-IP-based PDU session, and selecting a packet filter based on at least one aspect of data packets formatted in a non-IP format associated with the non-IP PDU session. The method then further includes: filtering the transmission of the data packets according to the packet filter.

[0012] In a second example, a wireless communication device is disclosed. The wireless communication device includes a processor communicatively coupled to a memory, a transceiver, communication circuitry, selection circuitry, and filtering circuitry. In this example, the communication circuitry is configured to establish a non-IP-based PDU session, and the selection circuitry is configured to select a packet filter based on at least one aspect of data packets formatted in a non-IP format associated with the non-IP-based PDU session. The filtering circuitry is then configured to filter the transmission of the data packets according to the packet filter.

[0013] In a third example, an apparatus for wireless communication is disclosed. The apparatus includes: a unit for establishing a non-IP-based PDU session, and a unit for selecting a packet filter based on at least one aspect of data packets formatted in a non-IP format associated with the non-IP-based PDU session. The apparatus further includes: a unit for filtering the transmission of the data packets according to the packet filter.

[0014] In the fourth example, the non-transitory computer-readable medium storing computer-executable code includes code for causing the computer to perform various actions. For this example, such code includes: code for causing the computer to establish a non-IP-based PDU session, and code for causing the computer to select a packet filter based on at least one aspect of data packets formatted in a non-IP format associated with the non-IP-based PDU session. The code may further include: code for causing the computer to filter the transmission of the data packets according to the packet filter.

[0015] These and other aspects of the invention will become more fully understood after reading the following detailed description. Other aspects, features, and embodiments of the invention will become apparent to those skilled in the art after reading the following description of specific, exemplary embodiments of the invention in conjunction with the accompanying drawings. While features of the invention are discussed with respect to certain embodiments and the drawings below, all embodiments of the invention may include one or more of the advantageous features discussed herein. In other words, while one or more embodiments are discussed as having certain advantageous features, one or more of these features may also be used according to the various embodiments of the invention discussed herein. Similarly, while exemplary embodiments are discussed below as device, system, or method embodiments, it should be understood that these exemplary embodiments can be implemented with various devices, systems, and methods. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of a wireless communication system.

[0017] Figure 2 This is a conceptual diagram of an example of a wireless access network.

[0018] Figure 3 It is a block diagram illustrating some aspects of the architecture of next-generation (e.g., fifth-generation or 5G) wireless communication networks.

[0019] Figure 4 This is a block diagram illustrating an exemplary system for facilitating the filtering of data groups in accordance with some aspects of this disclosure.

[0020] Figure 5 This is a block diagram illustrating an example of a hardware implementation of a scheduling entity device employing a processing system, according to some aspects of this disclosure.

[0021] Figure 6 It is shown in Figure 5 The block diagrams shown here are exemplary sub-components of these selection circuits and software.

[0022] Figure 7 This is a flowchart illustrating an exemplary process for filtering downlink data packets according to some aspects of this disclosure.

[0023] Figure 8 This is a flowchart illustrating an exemplary process for filtering Ethernet-type downlink data packets, according to some aspects of this disclosure.

[0024] Figure 9 This is a flowchart illustrating an exemplary process for filtering unstructured downlink data packets, according to some aspects of this disclosure.

[0025] Figure 10 This is a block diagram illustrating an example of a hardware implementation of a scheduled entity device employing a processing system, according to some aspects of this disclosure.

[0026] Figure 11 It is shown in Figure 10 The diagram shows an exemplary sub-component of the selection circuit and software.

[0027] Figure 12 This is a flowchart illustrating an exemplary process for filtering uplink data packets according to some aspects of this disclosure.

[0028] Figure 13 This is a flowchart illustrating an exemplary process for filtering Ethernet-type uplink data packets, according to some aspects of this disclosure.

[0029] Figure 14 This is a flowchart illustrating an exemplary process for filtering unstructured uplink data packets, according to some aspects of this disclosure.

[0030] Figure 15 This is a flowchart illustrating an exemplary process for filtering uplink data packets when Reactive Quality of Service (QoS) is enabled, according to some aspects of this disclosure. Detailed Implementation

[0031] The specific embodiments described below with reference to the accompanying drawings are intended to describe various configurations, and not to represent only configurations that can implement the concepts described herein. Specific details are included in the specific embodiments to provide a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts can be implemented without using these specific details. In some instances, well-known structures and components are given in block diagram form to avoid obscuring these concepts.

[0032] As will be discussed in more detail herein, this disclosure includes aspects relating to solutions for extending current packet filter formats to achieve Quality of Service (QoS) within Protocol Data Unit (PDU) sessions for non-Internet Protocol (IP) types (e.g., Ethernet, unstructured, etc.). For example, for an “Ethernet” type PDU session, filtering is expected to be based on the content of the Ethernet frame header, where any of various parameters can be added to the packet filter. Aspects regarding how to prioritize packet filter matches based on standards including Ethernet frame headers and / or IP frame headers are also disclosed (e.g., no priority, evaluating only the IP header content if no match for the Ethernet frame header exists, etc.). For an “unstructured” type PDU session, since the format of packets exchanged during a PDU session is not standardized (i.e., it is impossible to define packet filter components based on header content), it is disclosed that the mapping of user data packets to specific QoS processing is not based on the content of the packet itself, but on aspects of the application that generated the packet.

[0033] This disclosure also includes aspects relating to a solution for self-constructing packet filters at the UE for non-IP-based PDU sessions when reactive QoS is enabled. For example, for “Ethernet” and “unstructured” type PDU sessions, embodiments are disclosed in which the UE constructs uplink (UL) packet filters based on received downlink (DL) packets.

[0034] definition

[0035] RAT: Radio Access Technology. A type of technology or communication standard used for wireless access and communication via a wireless air interface. A few examples of RATs include GSM, UTRA, E-UTRA (LTE), Bluetooth, and Wi-Fi.

[0036] NR: New Radio. This typically refers to 5G technology and new radio access technologies that have been defined and standardized by 3GPP in Release 15.

[0037] RAB: Radio Access Bearer. A service provided by the access layer to the non-access layer for transmitting user information between the UE and the core network.

[0038] QoS: Quality of Service. The collective effect of service performance on user satisfaction with a service. QoS is characterized by a combination of performance factors applicable to all services, such as: service operability performance; service accessibility performance; service maintainability performance; service integrity performance; and other factors specific to each service.

[0039] The various concepts presented throughout this disclosure can be implemented in a wide variety of telecommunications systems, network architectures, and communication standards. See also: Figure 1 To illustrate, and not to limit, various aspects of this disclosure are shown with reference to a wireless communication system 100. The wireless communication system 100 includes three interaction domains: a core network 102, a radio access network (RAN) 104, and a user equipment (UE) 106. With the aid of the wireless communication system 100, the UE 106 can be implemented to perform data communication with an external data network 110 (such as, but not limited to, the Internet).

[0040] RAN 104 can implement any one or more suitable wireless communication technologies or techniques to provide radio access to UE 106. As one example, RAN 104 can operate according to the 3GPP New Radio (NR) specification (often referred to as 5G). As another example, RAN 104 can operate according to a hybrid of 5G NR and the Evolved Universal Terrestrial Radio Access Network (eUTRAN) standard (often referred to as LTE). 3GPP refers to this hybrid RAN as Next Generation RAN or NG-RAN. Of course, many other examples can be utilized within the scope of this disclosure.

[0041] As shown in the figure, RAN 104 includes multiple base stations 108. Broadly speaking, a base station is a network element in a radio access network responsible for radio transmission and reception to or from a UE in one or more cells. In different technologies, standards, or contexts, those skilled in the art may also refer to a base station as a base transceiver station (BTS), radio base station, radio transceiver, transceiver function, basic service set (BSS), extended service set (ESS), access point (AP), Node B, evolved Node B (eNB), gNodeB (gNB), or some other suitable term.

[0042] The wireless access network 104 is also shown as supporting wireless communication for multiple mobile devices. In 3GPP standards, a mobile device may be referred to as a User Equipment (UE), but those skilled in the art may also refer to it as a Mobile Station (MS), User Station, Mobile Unit, User Unit, Radio Unit, Remote Unit, Mobile Device, Radio Equipment, Wireless Communication Equipment, Remote Equipment, Mobile Subscriber Station, Access Terminal (AT), Mobile Terminal, Radio Terminal, Remote Terminal, Handheld Device, Terminal, User Agent, Mobile Client, Client, or any other suitable term. The UE may be an access device that provides network services to users.

[0043] In this document, a “mobile” device does not necessarily have the ability to move; it can be stationary. The term mobile device or mobile device broadly refers to a wide variety of devices and technologies. For example, some non-limiting examples of mobile devices include mobile stations, cellular phones, smartphones, Session Initiation Protocol (SIP) phones, laptops, personal computers (PCs), notebooks, netbooks, smartbooks, tablets, personal digital assistants (PDAs), and a wide range of embedded systems, for example, corresponding to the “Internet of Things” (IoT). Additionally, a mobile device can be a consumer device and / or wearable device such as a car or other transport vehicle, a remote sensor or actuator, a robot or robotic device, satellite radio equipment, a Global Positioning System (GPS) device, an object tracking device, a drone, a multi-purpose helicopter, a quadcopter, a remote control device, such as glasses, wearable cameras, virtual reality devices, smartwatches, health or fitness trackers, digital audio players (e.g., MP3 players), cameras, game consoles, and so on. Furthermore, a mobile device can also be a digital home or smart home device such as home audio, video, and / or multimedia equipment, home appliances, vending machines, smart lighting, home security systems, smart meters, and so on. In addition, mobile devices can also be smart energy devices, security devices, solar panels or solar arrays, municipal infrastructure equipment for controlling electricity (e.g., smart grids), lighting, water, etc.; industrial automation and enterprise equipment; logistics controllers; agricultural equipment; military defense equipment, vehicles, aircraft, ships, weapons, etc. Furthermore, mobile devices can provide connected medical or telemedicine support (i.e., telehealth). Telemedicine devices can include telemedicine monitoring equipment and telemedicine management equipment, whose communications can be prioritized or given priority access relative to other types of information, such as priority access to the transmission of critical service data, and / or QoS related to the transmission of critical service data.

[0044] Wireless communication between RAN 104 and UE 106 can be described as utilizing an air interface. Transmissions via the air interface from a base station (e.g., base station 108) to one or more UEs (e.g., UE 106) can be referred to as downlink (DL) transmissions. According to certain aspects of this disclosure, the term downlink can refer to point-to-multipoint transmissions originating from a scheduling entity (further described below; e.g., base station 108). Another way to describe this scheme is to use the term broadcast channel multiplexing. Transmissions from a UE (e.g., UE 106) to a base station (e.g., base station 108) can be referred to as uplink (UL) transmissions. According to another aspect of this disclosure, the term uplink can refer to point-to-point transmissions originating from a scheduled entity (further described below; e.g., UE 106).

[0045] In some examples, access to the air interface can be scheduled, where a scheduling entity (e.g., base station 108) allocates resources for communication between some or all devices and equipment within its service area or cell. As further discussed below in this disclosure, the scheduling entity may be responsible for scheduling, assigning, reconfiguring, and releasing resources for one or more scheduled entities. That is, for scheduled communication, UE 106 (which may be a scheduled entity) can use the resources allocated by scheduling entity 108.

[0046] Base station 108 is not the only entity that can act as a scheduling entity. That is, in some examples, a UE can act as a scheduling entity to schedule resources for one or more scheduled entities (e.g., one or more other UEs).

[0047] like Figure 1 As shown, scheduling entity 108 can broadcast downlink service 112 to one or more scheduled entities 106. Broadly speaking, scheduling entity 108 is a node or device responsible for scheduling services (including downlink service 112, and in some examples, uplink service 116 from one or more scheduled entities 106 to scheduling entity 108) in a wireless communication network. On the other hand, scheduled entity 106 is a node or device that receives downlink control information 114 (including but not limited to scheduling information (e.g., authorization), synchronization or timing information, or other control information) from another entity in the wireless communication network (such as scheduling entity 108).

[0048] Typically, base station 108 may include a backhaul interface for communicating with the backhaul section 120 of a wireless communication system. Backhaul 120 can provide a link between base station 108 and core network 102. Furthermore, in some examples, the backhaul network can provide interconnection between corresponding base stations 108. Various types of backhaul interfaces can be used, such as direct physical connections, virtual networks, or backhaul interfaces using any suitable transport network.

[0049] Core network 102 may be part of wireless communication system 100 and may be independent of the radio access technology used in RAN 104. In some examples, core network 102 may be configured according to 5G standards (e.g., 5GC). In other examples, core network 102 may be configured according to 4G Evolved Packet Core (EPC) or any other suitable standard or configuration.

[0050] See now Figure 2 Instead of making limitations, a schematic diagram of RAN 200 is provided. In some examples, RAN 200 can be used in conjunction with those described above and... Figure 1The same as RAN 104 shown. The geographical area covered by RAN 200 can be divided into multiple cellular areas (cells), and user equipment (UE) can uniquely identify these cellular areas (cells) based on an identifier broadcast from an access point or base station. Figure 2 Macro cells 202, 204, and 206, and small cell 208 are shown, each of which may include one or more sectors (not shown). A sector is a sub-area of ​​a cell. All sectors in a cell are served by the same base station. Radio links within a sector can be identified by a single logical identifier belonging to that sector. In a cell divided into multiple sectors, multiple sectors within the cell can be formed using multiple sets of antennas, where each antenna is responsible for communicating with UEs in a portion of the cell.

[0051] exist Figure 2 In the illustration, two base stations 210 and 212 are shown in cells 202 and 204; and a third base station 214 is shown for controlling the Remote Radio Header (RRH) 216 in cell 206. That is, the base stations can have integrated antennas, or they can be connected to antennas or RRHs via feeder cables. In the illustrated example, cells 202, 204, and 216 can be referred to as macro cells because base stations 210, 212, and 214 support cells with larger sizes. Furthermore, a base station 218 is shown in small cell 208 (e.g., microcell, picocell, femtocell, home base station, home node B, home eNodeB, etc.), where small cell 208 may overlap with one or more macro cells. In this example, cell 208 can be referred to as a small cell because base station 218 supports cells with relatively small sizes. Cell size settings can be made according to system design and component constraints.

[0052] It should be understood that the wireless access network 200 may include any number of wireless base stations and cells. Furthermore, relay nodes may be deployed to extend the size or coverage area of ​​a given cell. Base stations 210, 212, 214, and 218 provide wireless access points to the core network for any number of mobile devices. In some examples, base stations 210, 212, 214, and / or 218 may be connected to those described above and... Figure 1 The base station / scheduling entity 108 shown is the same.

[0053] Figure 2 It also includes a quadcopter or drone 220, which can be configured to act as a base station. That is, in some examples, the cell does not need to be stationary, and the geographical area of ​​the cell can move depending on the location of the mobile base station (e.g., the quadcopter 220).

[0054] In RAN 200, a cell may include UEs capable of communicating with one or more sectors of each cell. Furthermore, each base station 210, 212, 214, 218, and 220 can be configured to provide access to the core network 102 (see [link to core network 102]) for all UEs in the respective cell. Figure 1 Access points. For example, UEs 222 and 224 can communicate with base station 210; UEs 226 and 228 can communicate with base station 212; UEs 230 and 232 can communicate with base station 214 via RRH 216; UE 234 can communicate with base station 218; and UE 236 can communicate with mobile base station 220. In some examples, UEs 222, 224, 226, 228, 230, 232, 234, 236, 238, 240 and / or 242 can communicate with the access points described above and... Figure 1 The UE / scheduled entity 106 shown is the same.

[0055] In some examples, a mobile network node (e.g., quadcopter 220) can be configured to act as a UE. For example, quadcopter 220 can operate in cell 202 by communicating with base station 210.

[0056] In another aspect of RAN 200, sidelink signaling can be used between UEs without relying on scheduling or control information from a base station. For example, two or more UEs (e.g., UEs 226 and 228) can communicate with each other using peer-to-peer (P2P) or sidelink signaling 227 without relaying the communication through a base station (e.g., base station 212). In another example, UE 238 is shown communicating with UEs 240 and 242. Here, UE 238 can act as a scheduling entity or a primary sidelink device, and UEs 240 and 242 can act as scheduled entities or non-primary (e.g., secondary) sidelink devices. In yet another example, a UE can act as a scheduling entity in a device-to-device (D2D), peer-to-peer (P2P), or vehicle-to-vehicle (V2V) network and / or mesh network. In the mesh network example, UEs 240 and 242 can optionally communicate directly with each other in addition to communicating with scheduling entity 238. Therefore, in a wireless communication system with scheduled access to time and frequency resources and with cellular, P2P, or mesh configurations, a scheduling entity and one or more scheduled entities can use the scheduled resources to communicate.

[0057] In a radio access network 200, the ability of a UE to communicate while moving (independent of its location) is referred to as mobility. This is typically addressed in the Access and Mobility Management Function Unit (AMF, not shown). Figure 1Under the control of the core network 102, the UE establishes, maintains and releases various physical channels between the UE and the radio access network, wherein the AMF may include a Security Context Management Function (SCMF) unit that manages the security context for both control plane and user plane functions, and a Security Anchoring Function (SEAF) unit that performs authentication.

[0058] In various aspects of this disclosure, the radio access network 200 may use DL-based mobility or UL-based mobility to enable movement and handover (i.e., the UE's connection switching from one radio channel to another). In a network configured for DL-based mobility, during a call with a scheduling entity, or at any other time, the UE may monitor various parameters of the signal from its serving cell and various parameters of neighboring cells. Based on the quality of these parameters, the UE may maintain communication with one or more of the neighboring cells. During this time, if the UE moves from one cell to another, or if the signal quality from a neighboring cell exceeds the signal quality from the serving cell for a given amount of time, the UE may perform a handover or handover from the serving cell to the neighboring (target) cell. For example, UE 224 (shown as a vehicle, although any suitable form of UE may be used) may move from a geographic area corresponding to its serving cell 202 to a geographic area corresponding to a neighboring cell 206. When the signal strength or quality from the neighboring cell 206 exceeds the signal strength or quality from its serving cell 202 for a given amount of time, UE 224 may send a report message to its serving base station 210 indicating this condition. In response, UE 224 can receive a handover command and can perform a handover to cell 206.

[0059] In a network configured for UL-based mobility, the network can use UL reference signals from each UE to select a serving cell for each UE. In some examples, base stations 210, 212, and 214 / 216 can broadcast uniform synchronization signals (e.g., a uniform primary synchronization signal (PSS), a uniform secondary synchronization signal (SSS), and a uniform physical broadcast channel (PBCH)). UEs 222, 224, 226, 228, 230, and 232 can receive these uniform synchronization signals, derive carrier frequencies and time slot timings based on these synchronization signals, and transmit uplink pilots or reference signals in response to the derived timings. The uplink pilot signal transmitted by a UE (e.g., UE 224) can be simultaneously received by two or more cells (e.g., base stations 210 and 214 / 216) in the radio access network 200. Each of these cells can measure the strength of the pilot signal, and the radio access network (e.g., one or more central nodes in base stations 210 and 214 / 216 and / or the core network) can determine the serving cell for UE 224. As UE 224 moves through radio access network 200, the network can continue to monitor the uplink pilot signal transmitted by UE 224. When the signal strength or quality of the pilot signal measured by a neighboring cell exceeds the signal strength or quality measured by the serving cell, network 200 can, with or without notifying UE 224, hand over UE 224 from the serving cell to that neighboring cell.

[0060] While the synchronization signals transmitted by base stations 210, 212, and 214 / 216 can be uniform, these signals may not identify a specific cell, but rather an area of ​​multiple cells operating on the same frequency and / or using the same timing. Using areas in 5G networks or other next-generation communication networks enables uplink-based mobile frameworks and improves efficiency for both the UE and the network because it reduces the number of mobile messages that need to be exchanged between the UE and the network.

[0061] In various implementations, the air interface in the radio access network 200 can use licensed spectrum, unlicensed spectrum, or shared spectrum. Licensed spectrum is typically licensed by mobile network operators from government regulatory agencies, providing exclusive use of a portion of the spectrum. Unlicensed spectrum provides shared use of a portion of the spectrum without requiring a government-authorized license. While some technical rules are usually still required to access unlicensed spectrum, generally any operator or device can obtain access. Shared spectrum can fall between licensed and unlicensed spectrum, where some technical rules or restrictions may be required for access, but the spectrum can still be shared by multiple operators and / or multiple RATs. For example, a licensee of a portion of licensed spectrum can provide Licensed Shared Access (LSA) to share the spectrum with other parties (e.g., with conditions determined by the appropriate licensee for access).

[0062] In some examples, scheduled entities (such as first scheduled entity 204a and second scheduled entity 204b) can utilize sidelink signals for direct D2D communication. Sidelink signals may include sidelink services 214 and 216. In some examples, sidelink control information 216 may include request signals such as Request to Send (RTS), Source Send Signal (STS), and / or Direction Selection Signal (DSS). The request signal enables scheduled entity 204 to request the duration for which a sidelink channel is available for sidelink signals. Sidelink control information 216 may also include response signals such as Allow to Send (CTS) and / or Destination Receive Signal (DRS). The response signal enables scheduled entity 204 to indicate the availability of the sidelink channel, for example, for the requested duration. The exchange of request and response signals (e.g., a handshake) allows different scheduled entities performing sidelink communication to negotiate the availability of the sidelink channel before the communication of sidelink service information 214.

[0063] The air interface in the wireless access network 200 can use one or more duplex algorithms. Duplex refers to a point-to-point communication link where two endpoints can communicate with each other in both directions. Full-duplex means that two endpoints can communicate with each other simultaneously. Half-duplex means that at any given time, only one endpoint can send information to the other. In wireless links, full-duplex channels typically rely on physical isolation between the transmitter and receiver and appropriate interference cancellation techniques. Full-duplex simulations for wireless links are often implemented using Frequency Division Duplex (FDD) or Time Division Duplex (TDD). In FDD, transmissions in different directions operate on different carrier frequencies. In TDD, transmissions in different directions on a given channel are separated from each other using time division multiplexing. That is, at some times, the channel is dedicated to transmission in one direction, and at other times, the channel is dedicated to transmission in the other direction, where the direction can change very quickly (e.g., several times per subframe).

[0064] To achieve a low block error rate (BLER) while still maintaining a very high data rate, channel coding can be used for transmissions on the wireless access network 200. That is, wireless communication typically utilizes appropriate error-correcting block codes. In a typical block code, an information message or sequence is broken down into code blocks (CBs), and subsequently, an encoder (e.g., a CODEC) at the transmitting device mathematically adds redundancy to the information message. Utilizing this redundancy in the encoded information message improves message reliability, thereby correcting for any bit errors that may occur due to noise.

[0065] In the 5G NR specification, quasi-cyclic low-density parity-check (LDPC) with two different base maps is used to encode user data: one base map for large code blocks and / or high code rates, and the other base map for other cases. Based on nested sequences, polar coding is used to encode control information and the physical broadcast channel (PBCH). For these channels, puncturing, shortening, and repetition are used for rate matching.

[0066] However, those skilled in the art will understand that aspects of this disclosure can be implemented using any suitable channel code. Various implementations of the scheduling entity 108 and the scheduled entity 106 may include appropriate hardware and capabilities (e.g., encoders, decoders, and / or CODECs) to utilize one or more of these channel codes for wireless communication.

[0067] The air interface in the wireless access network 200 can use one or more multiplexing and multiple access algorithms to enable simultaneous communication between devices. For example, the 5G NR specification provides multiple access for UL transmissions from UEs 222 and 224 to base station 210, and multiplexing using orthogonal frequency division multiplexing (OFDM) with a cyclic prefix (CP) for DL ​​transmissions from base station 210 to one or more UEs 222 and 224. Additionally, for UL transmissions, the 5G NR specification provides support for Discrete Fourier Transform Spread Spectrum OFDM (DFT-s-OFDM) with CP (also known as single-carrier FDMA (SC-FDMA)). However, within the scope of this disclosure, multiplexing and multiple access are not limited to the above schemes and can be provided using Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Sparse Code Multiple Access (SCMA), Resource Spread Multiple Access (RSMA), or other suitable multiple access schemes. In addition, time division multiplexing (TDM), code division multiplexing (CDM), frequency division multiplexing (FDM), orthogonal frequency division multiplexing (OFDM), sparse code multiplexing (SCM), or other appropriate multiplexing schemes can be used to provide multiplexed DL transmission from base station 210 to UEs 222 and 224.

[0068] Next, refer to Figure 3 This provides a block diagram illustrating various aspects of the architecture of a core network (CN) in a next-generation (e.g., fifth-generation or 5G) wireless communication network. As shown, features may include a UE 302 communicating with the core network 306 via an access network 304. In this illustration, it is assumed that the access network traverses any signal paths between these entities, such as those represented by the signal paths on the access network shown. Here, the access network 304 may be as described above and... Figure 2 The access network 200 is shown in the diagram. In another example, access network 304 may correspond to an LTE (eUTRAN) network, a wired access network, a combination of the above, or any one or more other suitable access networks. In the following description, when reference is made to an access network (AN) or an action performed by the AN, it is understood that such reference refers to one or more network nodes in the AN that are communicatively coupled to the CN (e.g., via a backhaul connection). As a non-limiting example, for clarity of description, such reference to the AN may be understood to refer to a base station. However, those skilled in the art will understand that this is not always the case; for example, as in some 3G RANs, the base station is under the control or guidance of a centralized radio network controller within its AN.

[0069] UE 302 has both user plane (UP) and control plane (CP) functions (and may have the UE features generally discussed herein). Figure 3 In the diagram, dashed lines indicate CP signaling, and solid lines indicate UP signaling. The access network (AN) 304 also includes some CP functionality (shown using CP block 303 at AN 304), but most CP functionality resides at CN 306. Specifically, CN 306 includes a control plane mobility management function unit (CP-MM) 308 and a control plane session management function unit (CP-SM) 310.

[0070] CP-MM 308 establishes and maintains mobility management contexts for devices (e.g., UE 302) attached to CN 306 via one or more access technologies. CP-SM 310 establishes, maintains, and terminates data network (DN) sessions and data sessions in next-generation system architectures, including establishing these sessions on demand. CP-SM 310 also determines the UE's Quality of Service (QoS) for DN sessions and / or data sessions.

[0071] The Authentication, Authorization, and Accounting (AAA) server / Policy Function (PF) block 312 acts as a profile repository and authentication server. The AAA / Policy Function block 312 can store user profiles and user credentials, and can store and make decisions regarding policies (e.g., QoS policies) to be applied to the UE for DN sessions and / or data sessions.

[0072] User plane (UP) infrastructure entity 314 represents any suitable communication infrastructure in CN 306 that delivers data between AN 304, User plane gateway (UP-GW) 316, and external data network 318. UP-GW 316 can be communicatively coupled to CP-SM 310 to configure UP connectivity on CN 306. The external data network can be any suitable data network, including but not limited to the Internet, IP Multimedia Subsystem (IMS) networks, etc.

[0073] In this disclosure, when referring to the core network or CN, it may be assumed that such reference is intended to refer to any node within the CN, unless a specific node is specifically referenced.

[0074] When UE 302 establishes a connection with CN 306, there are typically two different types of sessions that can be established: a data network session and a data session. In some examples, a data session can be referred to equivalently as a Packet Data Unit (PDU) session.

[0075] A Data Network (DN) session is a collection of logical context or context information for various entities, providing a framework for connectivity between local endpoints (e.g., web browsers) in the UE 302 and remote endpoints (e.g., IMS networks, the Internet, private networks, web servers in remote hosts, etc.) in an external data network 318. A DN session contains state information related to various entities (such as UE, AN, CN, gateway, etc.) and can be served by multiple UP-GWs in one or more CNs. A DN session can contain one or more data sessions.

[0076] A data session (also referred to as a PDU session, data stream, or stream) is a logical context within a UE that enables communication between a local endpoint within the UE (e.g., a web browser) and a remote endpoint in an external data network 318 (e.g., a web server in a remote host). A data session can be an IP session or a non-IP session (e.g., Ethernet service). Within this disclosure, any references to packets or PDUs (Protocol Data Units) are interchangeable and are intended to refer to IP packets or non-IP PDUs.

[0077] Next, refer to Figure 4 A block diagram illustrating an exemplary system for facilitating packet filtering according to some aspects of this disclosure is provided. As shown, a User Equipment (UE) 400 is communicatively coupled to a Core Network (CN) 440 via multiple PDU sessions (e.g., PDU sessions 480, 490), wherein packet filters (e.g., packet filters 420, 422, 460, 462) are associated with a specific PDU session (e.g., PDU sessions 480, 490). To facilitate uplink (UL) data packet filtering on the UE 400, the CN 400 may be configured to send a list of packet filters to the UE 400 when a PDU session (e.g., PDU sessions 480, 490) is established, or the UE 400 may be configured to self-build packet filters 420, 422 (e.g., in the case of reactive QoS). As shown, it is generally assumed that UL data packets are received from the application layer 430 of the UE 400, as illustrated. Subsequently, UE 400 uses various aspects of the UL packets to match specific packet filters with corresponding PDU sessions (e.g., packet filter 420 with PDU session 490, or packet filter 422 with PDU session 480), wherein the packet filters (e.g., packet filter 420 or 422) filter the UL packets in a manner that is transparent to PDU session processing unit 410.

[0078] A similar process is expected when filtering downlink (DL) data packets on CN 440. However, here, unlike receiving UL data packets from application layer 430, it is assumed that DL data packets are received from the external Internet / internal network 470, as shown. CN 440 then uses aspects of the DL packets to match specific packet filters with corresponding PDU sessions (e.g., packet filter 460 with PDU session 480, or packet filter 462 with PDU session 490), wherein the packet filters (e.g., packet filters 460 or 462) filter the DL packets in a manner transparent to the PDU session processing unit 450.

[0079] Packet filters for "Ethernet" PDU session types

[0080] As previously discussed, the aspects disclosed herein include solutions for how to extend current packet filter formats to achieve Quality of Service (QoS) within Protocol Data Unit (PDU) sessions of the “Ethernet” type. Here, since Ethernet frames can carry Internet Protocol (IP) data, it is contemplated that existing packet filter components specified in Subclause 10.5.6.12 of TS 24.008 can be included in packet filters (e.g., packet filters 420, 422, 460, 462) for PDU sessions of the “Ethernet” type. Therefore, it is also contemplated that filtering can be based on the content of the Ethernet frame header, where any of various parameters can be added to the packet filters (e.g., packet filters 420, 422, 460, 462). For example, packet filters (e.g., packet filters 420, 422, 460, 462) can be configured to include any of the following parameters: destination MAC address; source MAC address; VLAN identifier (VID); 802.1Q PCP (indicating packet priority); and / or Ethernet type.

[0081] In the specific aspects disclosed herein, it is therefore contemplated that the content included in both the Ethernet frame header and the IP header can be used to select the appropriate packet filter. For example, an example is disclosed where the content inferred from the Ethernet frame header and the content inferred from the IP header both have the same level of priority. Furthermore, for this particular example, in order to declare a match, it will be necessary to meet the criteria (in no particular order) in the filters corresponding to the content inferred from both the Ethernet frame header and the IP header.

[0082] In another example, a two-tiered system is used, where criteria in a filter corresponding to content inferred from the Ethernet frame header are evaluated before criteria corresponding to content inferred from the IP header are evaluated. That is, it is anticipated that the UE (e.g., UE 400) and CN (e.g., CN 440) can be configured to evaluate the IP header content only if the content of the Ethernet frame header matches a filter.

[0083] Extensions of the group filter for "unstructured" PDU session types

[0084] As previously discussed, aspects of how to extend the current packet filter format to achieve Quality of Service (QoS) within "unstructured" type Protocol Data Unit (PDU) sessions are also disclosed. Here, since the format of packets exchanged during "unstructured" type PDU sessions is not standardized, it should be noted that it is not possible to define packet filter components based on, for example, header content.

[0085] One possible solution disclosed herein is to map user data packets to specific QoS processing based on the application that generates the packets rather than on the content of the packets themselves. In this case, packet filters (e.g., packet filters 420, 422, 460, 462) may include one or more application identifiers (e.g., OS Id + OS App Id). In such an embodiment, the modem in the UE (e.g., UE 400) can be configured to add a tag with an application identifier to each user data packet received from the application layer (e.g., application layer 430) based on information provided by the High-Level Operating System (HLOS). Alternatively, the HLOS can be configured to use the application identifier to tag each user data packet passed to the modem for transmission. Similarly, on the CN (e.g., CN 440), such tagging can be performed by either: 1) a network layer that routes downlink data packets based on information provided by the application layer, or 2) the application layer, wherein filtering includes sending downlink data packets tagged with the application identifier from the application layer to the network layer that routes downlink data packets.

[0086] In another publicly available solution, when establishing a data connection for a specific service or application, a specific Access Point Name (APN) (also known as a Data Network Name (DNN) in 5G systems) is requested instead of using packet filters. In such an example, all user data packets for a specific service or application will be sent over a data connection with that specific APN, and subsequently, the network applies specific QoS processing based on the APN associated with that data connection.

[0087] Reactive QoS for PDU sessions of type "Ethernet"

[0088] Various aspects of implementing reflective Quality of Service (QoS) for Protocol Data Unit (PDU) sessions of the “Ethernet” type are also disclosed. In one particular embodiment, if reflective QoS is implemented in an “Ethernet” type PDU session, it is proposed that the UE (e.g., UE 400) construct packet filters (e.g., packet filters 420, 422) based on received downlink (DL) data packets. For example, when the UE receives a DL data packet, it is expected that the UE should check whether the packet is mapped to an existing uplink (UL) packet filter (e.g., packet filters 420, 422). If no matching UL packet filter is found, the UE should create a new packet filter with any of the various components. For example, such components are expected to include: a destination MAC address component set to the source MAC address of the received DL packet; a source MAC address component set to the destination MAC address of the received DL packet; a VID component set to the VID of the received DL packet if the received DL packet includes an 802.1Q tag; an 802.1Q priority component set to the 802.1Q priority of the received DL packet if the received DL packet includes an 802.1Q tag; an Ethernet type component set to the Ethernet type of the received DL packet if the Ethernet type field of the received DL packet is set to a value of 1536 or higher; and / or if the Ethernet type field of the Ethernet frame header indicates that the data carried in the Ethernet frame is IP data, the UE should also add IP-specific components to the UL packet filter based on the contents of the DL User Data IP header as specified in Subclause 5.2.4 of TS 24.139.

[0089] In another aspect of this disclosure, it is contemplated that the UE can thus be configured to associate a new UL group filter with a timestamp. For example, if a matching UL filter is found, the UE can be configured to update the timestamp of the matching UL group filter. The UE can also be configured to delete a group filter based on its timestamp, wherein how long the group filter should be retained can be UE-specific.

[0090] As previously stated, packet filters can be selected based on the content of both the IP header and the Ethernet frame header. In a particular example, these contents have the same level of priority and are therefore both included in the same packet filter associated with a single evaluation priority index. Alternatively, a two-tiered approach is anticipated, where filter components based on the Ethernet frame header content are included in a first packet filter with a certain evaluation priority index, and filter components based on the IP header content are included in a second packet filter with a higher evaluation priority index value than the first filter (i.e., such that the UE only checks the IP header content if the Ethernet frame header content matches the filter).

[0091] Reactive QoS for "unstructured" PDU sessions

[0092] Various aspects of implementing reflective Quality of Service (QoS) for “unstructured” type Protocol Data Unit (PDU) sessions are also disclosed. In one particular embodiment, if reflective QoS is implemented in an “unstructured” type PDU session, the UE (e.g., UE 400) is proposed to construct packet filters (e.g., packet filters 420, 422) based on received downlink (DL) data packets. For example, when the UE receives a DL data packet, it is expected that the UE should check whether the packet is mapped to an existing uplink (UL) packet filter (e.g., packet filters 420, 422). If no matching UL packet filter is found, the UE should create a new packet filter with an application identifier that is set to the application identifier of the application that generated the DL data packet.

[0093] In another aspect of this disclosure, it is contemplated that the UE can thus be configured to associate a new UL group filter with a timestamp. For example, if a matching UL filter is found, the UE can be configured to update the timestamp of the matching UL group filter. The UE can also be configured to delete a group filter based on its timestamp, wherein the duration for which the group filter is retained can be UE-specific.

[0094] In one particular example, the determination of the application for generating DL data packets is performed by the modem in the UE. Alternatively, the determination of the application for generating DL data packets is performed by the High-Level Operating System (HLOS) in the UE, and is instructed to the modem by the HLOS.

[0095] Exemplary scheduling entity

[0096] Figure 5This is a block diagram illustrating an example hardware implementation of a scheduling entity 500 employing a processing system 514. For example, the scheduling entity 500 may be a user equipment (UE) as shown in any one or more of the figures included herein. In another example, the scheduling entity 500 may be a base station as shown in any one or more of the figures included herein.

[0097] The scheduling entity 500 may be implemented using a processing system 514 including one or more processors 504. Examples of processors 504 include microprocessors, microcontrollers, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gate logic, discrete hardware circuitry, and other suitable hardware configured to perform the various functions described throughout this disclosure. In various examples, the scheduling entity 500 may be configured to perform any one or more of the functions described herein. That is, the processor 504 used in the scheduling entity 500 may be used to implement any one or more processes and procedures disclosed herein.

[0098] In this example, the processing system 514 can be implemented using a bus architecture, typically represented by bus 502. Depending on the specific application and overall design constraints of the processing system 514, bus 502 may include any number of interconnected buses and bridges. Bus 502 communicatively couples together various circuits including one or more processors (typically represented by processor 504), memory 505, and computer-readable media (typically represented by computer-readable media 506). Bus 502 may also link various other circuits such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art and therefore not described further. Bus interface 508 provides an interface between bus 502 and transceiver 510. Transceiver 510 provides units for communicating with various other devices via a transmission medium. Depending on the nature of the device, a user interface 512 (e.g., keyboard, display, speaker, microphone, joystick) may also be provided.

[0099] In some aspects of this disclosure, processor 504 may include communication circuitry 540 configured for various functions, including, for example, establishing a non-Internet Protocol (IP) based Protocol Data Unit (PDU) session with a scheduled entity (e.g., UE 400, scheduled entity 1000, etc.). As shown, processor 504 may also include selection circuitry 542 configured for various functions. For example, selection circuitry 542 may be configured to select a packet filter based on at least one aspect of downlink (DL) data packets formatted in a non-IP format associated with the non-IP based PDU session. Processor 504 may also include filtering circuitry 544 configured for various functions, including, for example, filtering transmissions of DL data packets to a scheduled entity (e.g., UE 400, scheduled entity 1000, etc.) according to a packet filter. Therefore, it should be appreciated that combinations of communication circuitry 540, selection circuitry 542, and filtering circuitry 544 may be configured to implement one or more of the functions described herein.

[0100] It should be recognized that various other aspects of the scheduling entity 500 are also contemplated. For example, to facilitate the selection of packet filters in non-IP-based PDU sessions versus Ethernet-based PDU sessions, such that the DL data packets to be filtered are formatted in Ethernet format, it is contemplated that the selection circuit 542 may include an Ethernet type sub-circuit 600, such as... Figure 6 As shown. In this example, the Ethernet type subcircuit 600 can be configured to select packet filters based on the content included in the Ethernet frame header of the DL data packet. Furthermore, since Ethernet-based PDU sessions can include IP data, it is also contemplated that the Ethernet type subcircuit 600 can be configured to select packet filters based on the content included in the IP header of the data packet. For this purpose, it should be understood that both the IP header-based filter component and the Ethernet frame header-based filter component can have the same level of priority (i.e., all criteria in the filter (in no particular order) must be met to declare a match). Alternatively, if the data packet associated with the Ethernet-based PDU session includes IP data, the Ethernet type subcircuit 600 can be configured to evaluate the content included in the IP header of the data packet only if at least a portion of the content included in the Ethernet frame header of the data packet corresponds to a matching packet filter.

[0101] Various aspects are also anticipated regarding filtering DL data packets with unstructured formats during unstructured PDU-based sessions. For example, to facilitate the selection of packet filters during such unstructured PDU-based sessions, selection circuitry 542 is expected to include unstructured type sub-circuit 610, such as... Figure 6 As shown. In a particular example, the unstructured type subcircuit 610 is configured to select a packet filter based on an identifier associated with the application that generates the DL data packets to be filtered. For example, the unstructured type subcircuit 610 may also be configured to facilitate the marking of DL data packets using such an identifier, wherein the marking can be performed by any of the various components. For example, the unstructured type subcircuit 610 may be coupled to a modem configured to perform marking based on information provided by an Advanced Operating System (HLOS). Alternatively, the unstructured type subcircuit 610 may be coupled to an HLOS configured to perform marking, wherein the HLOS is also configured to send the marked DL data packets to the modem.

[0102] In another example involving unstructured PDU sessions, it is anticipated that an APN can be used. In such an example, the filtering performed by the filtering circuit 544 includes: requesting an APN when a data connection is established, wherein the APN corresponds to a specific service or application; and subsequently sending DL data packets associated with the specific service or application for that APN.

[0103] Return to reference Figure 5 The processor 504 is responsible for managing the bus 502 and general-purpose processing, including executing software stored on the computer-readable medium 506. When the software is executed by the processor 504, it causes the processing system 514 to perform the various functions described below for any particular device. The computer-readable medium 506 and the memory 505 can also be used to store data manipulated when the processor 504 executes the software.

[0104] One or more processors 504 in the processing system can execute software. Software should be broadly interpreted as instructions, instruction sets, code, code segments, program code, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, etc., regardless of whether it is referred to as software, firmware, middleware, microcode, hardware description languages, or other terms. The software may reside in a computer-readable medium 506. The computer-readable medium 506 may be a non-transitory computer-readable medium. For example, non-transitory computer-readable media include magnetic storage devices (e.g., hard disks, floppy disks, magnetic tapes), optical disks (e.g., compressed optical discs (CDs) or digital versatile optical discs (DVDs)), smart cards, flash memory devices (e.g., card, stick, or key drives), random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), registers, removable disks, and any other suitable medium for storing software and / or instructions that can be accessed and read by a computer. Computer-readable medium 506 may be located within processing system 514, outside of processing system 514, or distributed among multiple entities including processing system 514. Computer-readable medium 506 may be embodied in a computer program product. For example, a computer program product may include a computer-readable medium having encapsulation material. Those skilled in the art will recognize that how best to implement the functionality described throughout this disclosure depends on the specific application and the design constraints imposed on the system as a whole.

[0105] In one or more examples, computer-readable storage medium 506 may include communication software 552 configured for various functions, including, for example, establishing a non-IP-based PDU session with a scheduled entity (e.g., UE 400, scheduled entity 1000, etc.). As shown, computer-readable storage medium 506 may also include selection software 554 configured for various functions. For example, selection software 554 may be configured to select a packet filter based on at least one aspect of DL data packets formatted in a non-IP format associated with the non-IP-based PDU session. Computer-readable storage medium 506 may also include filtering software 556 configured for various functions, including, for example, filtering transmissions of DL data packets for a scheduled entity (e.g., UE 400, scheduled entity 1000, etc.) according to a packet filter.

[0106] It should be recognized that various other aspects of the computer-readable storage medium 506 are also contemplated. For example, in order to facilitate the selection of packet filters in non-IP-based PDU sessions versus Ethernet-based PDU sessions, such that the DL data packets to be filtered are formatted in Ethernet format, it is contemplated that the selection software 554 may include Ethernet type instructions 605, such as... Figure 6 As shown. In this example, Ethernet type instruction 605 may include instructions for selecting packet filters based on the content included in the Ethernet frame header of the DL data packet. Furthermore, since Ethernet-based PDU sessions may include IP data, it is also contemplated that Ethernet type instruction 605 may include instructions for selecting packet filters based on the content included in the IP header of the data packet. For this purpose, it should be understood that both the IP header-based filter component and the Ethernet frame header-based filter component can have the same level of priority (i.e., all criteria in the filter (in no particular order) must be met to declare a match). Alternatively, if the data packet associated with the Ethernet-based PDU session includes IP data, Ethernet type instruction 605 may include instructions for evaluating the content included in the IP header of the data packet only if at least a portion of the content included in the Ethernet frame header of the data packet corresponds to a matching packet filter.

[0107] Various aspects are also anticipated regarding filtering DL data packets with unstructured formats during unstructured PDU-based sessions. For example, to facilitate the selection of packet filters during such unstructured PDU-based sessions, it is anticipated that the selection software 554 may include unstructured type instructions 615, such as... Figure 6 As shown. In a particular example, unstructured type instruction 615 includes instructions for selecting a packet filter based on an identifier associated with the application that generates the DL data packets to be filtered. For example, unstructured type instruction 615 may include instructions for facilitating the marking of DL data packets using such an identifier, wherein the marking can be performed by any of the various components. For example, unstructured type instruction 615 may include instructions for configuring a modem to perform marking based on information provided by an Advanced Operating System (HLOS). Alternatively, unstructured type instruction 615 may include instructions for configuring an HLOS to perform marking, wherein the HLOS is also configured to send the marked DL data packets to the modem.

[0108] In another example involving unstructured PDU sessions, it is anticipated that an APN can be used. In such an example, filtering facilitated by the filtering software 556 includes: requesting an APN when a data connection is established, wherein the APN corresponds to a specific service or application; and subsequently sending DL data packets associated with that specific service or application for that APN.

[0109] In one particular configuration, it is also contemplated that the scheduling entity 500 includes: a unit for establishing a non-IP-based PDU session with a scheduled entity (e.g., UE 400, scheduled entity 1000, etc.); a unit for selecting a packet filter based on at least one aspect of DL data packets formatted in a non-IP format associated with the non-IP-based PDU session; and a unit for filtering transmissions of DL data packets for the scheduled entity (e.g., UE 400, scheduled entity 1000, etc.) according to the packet filter. In one aspect, the aforementioned unit may be a processor 504 configured to perform the functions described therein. In another aspect, the aforementioned unit may be a circuit or any means configured to perform the functions described therein.

[0110] Of course, in the example above, the circuitry included in processor 504 is provided merely as an example, and within various aspects of this disclosure, other units for performing the described functions may be included, including but not limited to instructions stored in computer-readable storage medium 506, or instructions described herein and utilizing, for example, those related to… Figure 7-9 Any other suitable device or unit for the described process and / or algorithm.

[0111] exist Figure 7 The present disclosure provides a flowchart illustrating an exemplary process for filtering DL data groups according to some aspects of this disclosure. As described below, in specific implementations within the scope of this disclosure, some or all of the illustrated features may be omitted, and some illustrated features may not be required in all implementations of all embodiments. In some examples, process 700 may be... Figure 5 The process is executed by the scheduling entity 500 shown. In some examples, the process 700 may be executed by any suitable means or unit for performing the functions or algorithms described below.

[0112] At block 710, process 700 begins with the following operation: scheduling entity 500 establishes a non-IP-based PDU session with the scheduled entity (e.g., UE 400, scheduled entity 1000, etc.). Then, process 700 proceeds to block 720, where scheduling entity 500 selects a packet filter based on at least one aspect of the DL data packets of the non-IP PDU session formatted in non-IP format. Then, at block 730, process 700 ends with the following operation: scheduling entity 500 filters the transmission of DL data packets for the scheduled entity (e.g., UE 400, scheduled entity 1000, etc.) according to the packet filter.

[0113] Next, refer to Figure 8 A flowchart is provided illustrating an exemplary process for filtering Ethernet type DL data packets according to some aspects of this disclosure. Similar to process 700, it should be appreciated that process 800 can be... Figure 5 The scheduling entity 500 shown is used to execute, and / or the process 800 can be executed by any suitable means or unit for performing the functions or algorithms described below.

[0114] At box 802, process 800 begins with the following operation: scheduling entity 500 establishes an Ethernet-type PDU session with the scheduled entity (e.g., UE400, scheduled entity 1000, etc.). Then, process 800 proceeds to box 804, where scheduling entity 500 evaluates the Ethernet frame header of the DL data packet formatted in Ethernet format. Then, process 800 proceeds to box 806, where a determination is made regarding whether the DL data packet includes IP data.

[0115] If the DL data packet does indeed include IP data, process 800 continues to box 808, where scheduling entity 500 selects a packet filter based on the contents of the Ethernet frame header and IP header. Otherwise, if the DL data packet does not include IP data, process 800 continues to box 807, where scheduling entity 500 selects a packet filter based on the contents of the Ethernet frame header. Then, process 800 ends with scheduling entity 500 filtering the transmission of DL data packets for scheduled entities (e.g., UE 400, scheduled entity 1000, etc.) according to the packet filter.

[0116] Next, refer to Figure 9 A flowchart is provided illustrating an exemplary process for filtering groups of unstructured DL data according to some aspects of this disclosure. Similar to processes 700 and 800, it should be appreciated that process 900 can be... Figure 5 The scheduling entity 500 shown is used to execute, and / or the process 900 can be executed by any suitable means or unit for performing the functions or algorithms described below.

[0117] At box 902, process 900 begins with the following operation: scheduling entity 500 establishes a PDU session based on an unstructured type with the scheduled entity (e.g., UE 400, scheduled entity 1000, etc.). Then, process 900 continues to box 904, where scheduling entity 500 marks the unstructured DL data packets using an identifier associated with the application that generated the DL data packets. Then, at box 906, scheduling entity 500 selects a packet filter based on the application identifier, and then, at box 908, process 900 ends with the following operation: scheduling entity 500 filters the transmission of DL data packets for the scheduled entity (e.g., UE 400, scheduled entity 1000, etc.) according to the packet filter.

[0118] Exemplary scheduled entity

[0119] Figure 10 This is a conceptual diagram illustrating an example hardware implementation of an exemplary scheduled entity 1000 employing a processing system 1014. According to various aspects of this disclosure, the processing system 1014, including one or more processors 1004, can be used to implement elements, any portion of elements, or any combination of elements. For example, the scheduled entity 1000 may be a user equipment (UE) as shown in any one or more of the figures included herein.

[0120] Processing system 1014 can be used with Figure 5 The processing system 514 shown is largely the same, including a bus interface 1008, a bus 1002, a memory 1005, a processor 1004, and a computer-readable medium 1006. Furthermore, the scheduled entity 1000 may include a user interface 1012 and a transceiver 1010, which are largely similar to those described above. Figure 5 The user interfaces and transceivers described herein. That is, the processor 1004 used in the scheduled entity 1000 can be used to implement any one or more of the processes and procedures disclosed herein.

[0121] In some aspects of this disclosure, processor 1004 may include communication circuitry 1040 configured for various functions, including, for example, establishing non-Internet Protocol (IP) Protocol Data Unit (PDU) sessions with scheduling entities (e.g., core network 440, scheduling entity 500, etc.). As shown, processor 1004 may also include selection circuitry 1042 configured for various functions. For example, selection circuitry 1042 may be configured to select a packet filter based on at least one aspect of uplink (DL) data packets formatted in a non-IP format associated with the non-IP-based PDU session. Processor 1004 may also include filtering circuitry 1044 configured for various functions, including, for example, filtering transmissions of DL data packets for scheduling entities (e.g., core network 440, scheduling entity 500, etc.) according to packet filters. Therefore, it should be appreciated that combinations of communication circuitry 1040, selection circuitry 1042, and filtering circuitry 1044 may be configured to implement one or more of the functions described herein.

[0122] It should be recognized that various other aspects of the scheduled entity 1000 are also contemplated. For example, in order to facilitate the selection of packet filters in non-IP-based PDU sessions versus Ethernet-based PDU sessions, such that the DL data packets to be filtered are formatted in Ethernet format, it is contemplated that the selection circuit 1042 may include an Ethernet type sub-circuit 1100, such as... Figure 11 As shown. In this example, the Ethernet type subcircuit 1100 can be configured to select a packet filter based on the content included in the Ethernet frame header of the UL data packet. Furthermore, since an Ethernet-based PDU session may include IP data, it is also contemplated that the Ethernet type subcircuit 1100 can be configured to select a packet filter based on the content included in the IP header of the UL data packet. For this purpose, it should be understood that both the IP header-based filter component and the Ethernet frame header-based filter component can have the same level of priority (i.e., all criteria in the filter should be met (priority is not ranked) in order to declare a match). Alternatively, if the UL data packet associated with the Ethernet-based PDU session includes IP data, the Ethernet type subcircuit 1100 can be configured to evaluate the content included in the IP header of the UL data packet only if at least a portion of the content included in the Ethernet frame header of the UL data packet corresponds to a matching packet filter.

[0123] Various aspects are also anticipated regarding filtering UL data packets with unstructured formats during unstructured PDU-based sessions. For example, to facilitate the selection of packet filters during such unstructured PDU-based sessions, it is anticipated that selection circuitry 1042 may include unstructured type sub-circuit 1110, such as... Figure 11 As shown. In a particular example, the unstructured type subcircuit 1110 is configured to select a packet filter based on an identifier associated with the application that generates the UL data packets to be filtered. For example, the unstructured type subcircuit 1110 may also be configured to facilitate the marking of UL data packets using such an identifier, wherein the marking can be performed by any of the various components. For example, the unstructured type subcircuit 1110 may be coupled to a modem configured to perform marking based on information provided by an Advanced Operating System (HLOS). Alternatively, the unstructured type subcircuit 1110 may be coupled to an HLOS configured to perform marking, wherein the HLOS is also configured to send the marked UL data packets to the modem.

[0124] In another example involving unstructured PDU sessions, it is anticipated that an APN can be used. In such an example, the filtering performed by the filtering circuit 1044 includes: requesting an APN when a data connection is established, wherein the APN corresponds to a specific service or application; and subsequently sending UL data packets associated with the specific service or application for that APN.

[0125] Various aspects related to filtering UL data packets when reactive QoS is enabled are also anticipated. For example, to facilitate the selection of packet filters when reactive QoS is enabled, selection circuitry 1042 is expected to include reactive sub-circuitry 1120, such as... Figure 11 As shown. In a specific example, the reactive subcircuit 1120 is configured to evaluate downlink (DL) data packets received from the network when reactive QoS is enabled. Furthermore, it is anticipated that the reactive subcircuit 1120 can be configured to determine whether the content of the DL data packets matches a corresponding packet filter in the scheduled entity 1000. For this example, the reactive subcircuit 1120 can also be configured to create a new packet filter at the scheduled entity 1000 based on the content of the downlink data packets when no matching packet filter is found; or to utilize the existing packet filter at the scheduled entity 1000 when the content of an existing packet filter matches the content of the DL data packets. The reactive subcircuit 1120 can also be configured to timestamp one of the new or existing packet filters, and is further configured to delete the packet filter based on the corresponding timestamp.

[0126] Return to reference Figure 10 Similar to processor 504, processor 1004 is responsible for managing bus 1002 and general-purpose processing, including executing software stored on computer-readable medium 1006. When the software is executed by processor 1004, it causes processing system 1014 to perform the various functions described below for any particular device. Computer-readable medium 1006 and memory 1005 can also be used to store data manipulated when processor 1004 executes the software.

[0127] One or more processors 1004 in the processing system can execute software. Software should be broadly interpreted as meaning instructions, instruction sets, code, code segments, program code, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, etc., regardless of whether it is referred to as software, firmware, middleware, microcode, hardware description languages, or other terms. The software may reside in a computer-readable medium 1006. Similar to computer-readable medium 506, computer-readable medium 1006 may be a non-transitory computer-readable medium including substantially similar characteristics. Computer-readable medium 1006 may reside in, outside of, or be distributed among multiple entities including processing system 1014. It should also be recognized that, similar to computer-readable medium 506, computer-readable medium 1006 may be embodied in a computer program product including substantially similar characteristics.

[0128] In one or more examples, computer-readable storage medium 1006 may include communication software 1052 configured for various functions, including, for example, establishing non-IP-based PDU sessions with scheduling entities (e.g., core network 440, scheduling entity 500, etc.). As shown, computer-readable storage medium 1006 may also include selection software 1054 configured for various functions. For example, selection software 1054 may be configured to select a packet filter based on at least one aspect of UL data packets formatted in a non-IP format associated with the non-IP-based PDU session. Computer-readable storage medium 1006 may also include filtering software 1056 configured for various functions, including, for example, filtering transmissions of UL data packets for scheduling entities (e.g., core network 440, scheduling entity 500, etc.) according to packet filters.

[0129] It should be recognized that various other aspects of the computer-readable storage medium 1006 are also contemplated. For example, in order to facilitate the selection of packet filters in a non-IP-based PDU session versus an Ethernet-based PDU session, such that the UL data packets to be filtered are formatted in Ethernet format, it is contemplated that the selection software 1054 may include Ethernet type instructions 1105, such as... Figure 11 As shown. In this example, Ethernet type instruction 1105 may include instructions for selecting a packet filter based on the content included in the Ethernet frame header of the UL data packet. Furthermore, since Ethernet-based PDU sessions may include IP data, it is also contemplated that Ethernet type instruction 1105 may include instructions for selecting a packet filter based on the content included in the IP header of the UL data packet. For this purpose, it should be understood that both the IP header-based filter component and the Ethernet frame header-based filter component can have the same level of priority (i.e., all criteria in the filter (in no particular order) must be met to declare a match). Alternatively, if the UL data packet associated with the Ethernet-based PDU session includes IP data, Ethernet type instruction 1105 may include instructions for evaluating the content included in the IP header of the UL data packet only if at least a portion of the content included in the Ethernet frame header of the UL data packet corresponds to a matching packet filter.

[0130] Various aspects are also anticipated regarding filtering DL data packets with unstructured formats during unstructured PDU-based sessions. For example, to facilitate the selection of packet filters during such unstructured PDU-based sessions, it is anticipated that the selection software 1054 may include unstructured type instructions 1115, such as... Figure 11 As shown. In a particular example, unstructured type instruction 1115 includes instructions for selecting a packet filter based on an identifier associated with the application that generates the UL data packets to be filtered. For example, unstructured type instruction 1115 may include instructions for facilitating the marking of UL data packets using such an identifier, wherein the marking can be performed by any of the various components. For example, unstructured type instruction 1115 may include instructions for configuring a modem to perform marking based on information provided by an Advanced Operating System (HLOS). Alternatively, unstructured type instruction 1115 may include instructions for configuring an HLOS to perform marking, wherein the HLOS is also configured to send the marked UL data packets to the modem.

[0131] In another example involving unstructured PDU sessions, it is anticipated that an APN can be used. In such an example, filtering facilitated by the filtering software 1056 includes: requesting an APN when a data connection is established, wherein the APN corresponds to a specific service or application; and subsequently sending UL data packets associated with the specific service or application for that APN.

[0132] In one particular configuration, it is also contemplated that the scheduled entity 1000 includes: a unit for establishing a non-IP-based PDU session with the scheduling entity (e.g., core network 440, scheduling entity 500, etc.); a unit for selecting a packet filter based on at least one aspect of UL data packets formatted in a non-IP format associated with the non-IP-based PDU session; and a unit for filtering transmissions of UL data packets for the scheduling entity (e.g., core network 440, scheduling entity 500, etc.) according to the packet filter. In one aspect, the aforementioned unit may be a processor 1004 configured to perform the functions described by the aforementioned unit. In another aspect, the aforementioned unit may be a circuit or any means configured to perform the functions described by the aforementioned unit.

[0133] Of course, in the example above, the circuitry included in processor 1004 is provided merely as an example, and within various aspects of this disclosure, other units for performing the described functions may be included, including but not limited to instructions stored in computer-readable storage medium 1006, or instructions described herein and utilizing, for example, those related to… Figure 12-15 Any other suitable device or unit for the described process and / or algorithm.

[0134] exist Figure 12 The present disclosure provides a flowchart illustrating an exemplary process for filtering UL data groups according to some aspects of this disclosure. As described below, some or all of the illustrated features may be omitted in specific implementations within the scope of this disclosure, and some illustrated features may not be required for all implementations of all embodiments. In some examples, process 1200 may be... Figure 10 The scheduled entity 1000 shown is responsible for execution. In some examples, process 1200 may be executed by any suitable means or unit for performing the functions or algorithms described below.

[0135] At box 1210, process 1200 begins with the following operation: the scheduled entity 1000 establishes a non-IP-based PDU session with the scheduling entity (e.g., core network 440, scheduling entity 500, etc.). Then, process 1200 proceeds to box 1220, where the scheduled entity 1000 selects a packet filter based on at least one aspect of the UL data packets of the non-IP PDU session formatted in non-IP format. Then, at box 1230, process 1200 ends with the following operation: the scheduled entity 1000 filters the transmission of UL data packets for the scheduling entity (e.g., core network 440, scheduling entity 500, etc.) according to the packet filter.

[0136] Next, refer to Figure 13 A flowchart is provided illustrating an exemplary process for filtering Ethernet-type UL data packets according to some aspects of this disclosure. Similar to process 1200, it should be appreciated that process 1300 can be... Figure 10 The scheduled entity 1000 shown is to perform, and / or the process 1300 can be performed by any suitable means or unit for performing the functions or algorithms described below.

[0137] At box 1302, process 1300 begins with the following operation: the scheduled entity 1000 establishes an Ethernet-based PDU session with the scheduling entity (e.g., core network 440, scheduling entity 500, etc.). Then, process 1300 proceeds to box 1304, where the scheduled entity 1000 evaluates the Ethernet frame header of the UL data packet formatted in Ethernet format. Then, process 1300 proceeds to box 1306, where a determination is made regarding whether the UL data packet includes IP data.

[0138] If the UL data packet does indeed include IP data, process 1300 proceeds to box 1308, where the scheduled entity 1000 selects a packet filter based on the contents of the Ethernet frame header and the IP header. Otherwise, if the UL data packet does not include IP data, process 1300 proceeds to box 1307, where the scheduled entity 1000 selects a packet filter based on the contents of the Ethernet frame header. Process 1300 then terminates with the scheduled entity 1000 filtering the transmission of UL data packets for the scheduling entity (e.g., core network 440, scheduling entity 500, etc.) according to the packet filter.

[0139] Next, refer to Figure 14A flowchart is provided illustrating an exemplary process for filtering unstructured UL data groups according to some aspects of this disclosure. Similar to processes 1200 and 1300, it should be appreciated that process 1400 can be... Figure 10 The scheduled entity 1000 shown is to perform, and / or the process 1400 can be performed by any suitable means or unit for performing the functions or algorithms described below.

[0140] At box 1402, process 1400 begins with the following operation: the scheduled entity 1000 establishes a PDU session based on an unstructured type with the scheduling entity (e.g., core network 440, scheduling entity 500, etc.). Then, process 1400 continues to box 1404, where the scheduled entity 1000 marks the unstructured UL data packets using an identifier associated with the application that generated the UL data packets. Then, at box 1406, the scheduled entity 1000 selects a packet filter based on the application identifier, and then, at box 1408, process 1400 ends with the following operation: the scheduled entity 1000 filters the transmission of UL data packets for the scheduling entity (e.g., core network 440, scheduling entity 500, etc.) according to the packet filter.

[0141] Next, refer to Figure 15 A flowchart is provided illustrating an exemplary process for filtering UL data packets when QoS is enabled, according to some aspects of this disclosure. Similar to processes 1200, 1300, and 1400, it should be appreciated that process 1500 can be... Figure 10 The scheduled entity 1000 shown is to perform, and / or the process 1500 can be performed by any suitable means or unit for performing the functions or algorithms described below.

[0142] At box 1502, process 1500 begins with the following operations: the scheduled entity 1000 enables reactive QoS, and then, at box 1504, establishes a non-IP-based PDU session with the scheduling entity (e.g., core network 440, scheduling entity 500, etc.). Process 1500 then continues to box 1506, where the scheduled entity 1000 evaluates DL data packets received from the scheduling entity (e.g., core network 440, scheduling entity 500, etc.).

[0143] Then, at box 1508, scheduling entity 1000 determines whether the content of the DL data packets matches an existing packet filter that can be retrieved by the scheduled entity 1000. If a matching packet filter is found, process 1500 proceeds to box 1510, where the scheduled entity 1000 utilizes the existing packet filter. Otherwise, if no matching packet filter is found, process 1500 proceeds to box 1509, where the scheduled entity 1000 creates a new packet filter based on the DL data packets. Then, process 1500 proceeds to box 1512, where the scheduled entity 1000 timestamps the new / existing packet filter, and then, at box 1514, process 1500 terminates with the scheduled entity 1000 filtering the transmission of UL data packets for scheduling entities (e.g., core network 440, scheduling entity 500, etc.) according to the new / existing packet filter.

[0144] Some aspects of wireless communication networks are illustrated with reference to exemplary implementations. As will be readily understood by those skilled in the art, the various aspects described throughout this disclosure can be extended to other telecommunications systems, network architectures, and communication standards.

[0145] For example, these aspects can be implemented in other systems specified by 3GPP, such as Long Term Evolution (LTE), Evolved Packet System (EPS), Universal Mobile Telecommunications System (UMTS), and / or Global System for Mobile Communications (GSM). These aspects can also be extended to systems specified by 3GPP2, such as CDMA2000 and / or Evolved Data Optimized (EV-DO). Other examples can be implemented in systems using IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Ultra Wideband (UWB), Bluetooth, and / or other suitable systems. The actual telecommunications standards, network architecture, and / or communication standards used depend on the specific application and all design constraints imposed on the system.

[0146] In this disclosure, the term “exemplary” as used means “serving as an example, illustration, or description.” Any implementation or aspect described herein as “exemplary” should not be construed as superior or more advantageous than other aspects of this disclosure. Similarly, the term “aspect” does not require that all aspects of this disclosure include the features, advantages, or modes of operation discussed. The term “coupling” is used herein to refer to direct or indirect coupling between two objects. For example, if object A physically contacts object B, and object B contacts object C, objects A and C can still be considered coupled to each other, even if they are not in direct physical contact. For example, a first object can be coupled to a second object, even if the first object never physically contacts the second object. The terms “circuit” and “electronic circuit” are used broadly to include hardware implementations of electronic devices and conductors (whereby the execution of the functions described in this disclosure is achieved when these electronic devices and conductors are connected and configured, without being a limitation on the type of electronic circuit) and software implementations of information and instructions (whereby the execution of the functions described in this disclosure is achieved when these information and instructions are executed by a processor).

[0147] Can be Figure 1-14 One or more of the components, steps, features, and / or functions shown may be rearranged and / or combined into a single component, step, feature, or function, or embodied in several components, steps, or functions. Furthermore, additional elements, components, steps, and / or functions may be added without departing from the novel features disclosed herein. Figure 1-14 The apparatuses, devices, and / or components shown can be configured to perform one or more of the methods, features, or steps described herein. The novel algorithms described herein can also be efficiently implemented in software and / or embedded in hardware.

[0148] It should be understood that the specific order or hierarchy of steps in the methods disclosed herein is merely an illustrative example of the process. It should be understood that the specific order or hierarchy of steps in these methods may be rearranged based on design preferences. The appended method claims provide elements of various steps in a sample order, but are not intended to be limited to the given specific order or hierarchy unless expressly stated herein.

[0149] After reading the foregoing description of specific, exemplary embodiments of the invention in conjunction with the accompanying drawings, other aspects, features, and embodiments of the invention will become apparent to those skilled in the art. While features of the invention have been discussed with respect to certain embodiments and the drawings below, all embodiments of the invention may include one or more of the advantageous features discussed herein. In other words, while one or more embodiments are discussed as having certain advantageous features, one or more of these features may also be used according to the various embodiments of the invention discussed herein. Similarly, while exemplary embodiments may be discussed as embodiments of devices, systems, or methods, it should be understood that these exemplary embodiments can be implemented with various devices, systems, and methods.

Claims

1. A method for wireless communication, the method comprising: Establish Protocol Data Unit (PDU) sessions based on non-Internet Protocol (IP); A packet filter is selected based on at least one aspect of data packets formatted in a non-IP format associated with the non-IP-based PDU session, wherein the non-IP-based PDU session is an Ethernet-based PDU session, and the data packets include IP data and are formatted in an Ethernet format. The selection of the packet filter is based on the content included in the Ethernet frame header of the data packet, and the selection further includes: The content included in the IP header of the data packet is evaluated only if at least a portion of the content included in the Ethernet frame header of the data packet corresponds to a matching packet filter; and The transmission of the data packets is filtered according to the packet filter.

2. The method according to claim 1, wherein, The selection of the packet filter is still based on the content included in the IP header of the data packet.

3. The method according to claim 1, wherein, The selection further includes: when reactive QoS is enabled, evaluating downlink data packets received from the network, wherein the evaluation further includes: determining whether the content of the downlink data packets matches a corresponding packet filter in the user equipment (UE).

4. The method according to claim 3, wherein, The options also include: creating a new packet filter at the UE based on the content of the downlink data packet when no matching packet filter is found; or utilizing the existing packet filter at the UE when the content of an existing packet filter matches the content of the downlink data packet.

5. The method according to claim 4, further comprising: Timestamp either the new grouping filter or the existing grouping filter.

6. The method according to claim 5, further comprising: Deleting group filters based on corresponding timestamps.

7. A wireless communication device, comprising: processor; Memory communicatively coupled to the processor; A transceiver communicatively coupled to the processor; A communication circuitry communicatively coupled to the processor, wherein the communication circuitry is configured to: establish a Protocol Data Unit (PDU) session based on a non-Internet Protocol (IP); A selection circuit communicatively coupled to the processor, wherein the selection circuit is configured to select a packet filter based on at least one aspect of data packets formatted in a non-IP format associated with the non-IP-based PDU session, wherein the non-IP-based PDU session is an Ethernet-based PDU session, and the data packets include IP data and are formatted in an Ethernet format. The selection circuit includes an Ethernet type sub-circuit configured to select the packet filter based on the content included in the Ethernet frame header of the data packet, and further configured to evaluate the content included in the IP header of the data packet only if at least a portion of the content included in the Ethernet frame header of the data packet corresponds to a matching packet filter; and A filtering circuit communicatively coupled to the processor, wherein the filtering circuit is configured to filter the transmission of the data packets according to the packet filter.

8. The wireless communication device according to claim 7, wherein, The Ethernet type subcircuit is also configured to select the packet filter based on the content included in the IP header of the data packet.

9. The wireless communication device according to claim 7, wherein, The selection circuit includes a reactive sub-circuit configured to evaluate downlink data packets received from the network when reactive QoS is enabled, and wherein the reactive sub-circuit is configured to determine whether the content of the downlink data packets matches a corresponding packet filter in the user equipment (UE).

10. The wireless communication device according to claim 9, wherein, The reactive sub-circuit is also configured to: create a new packet filter at the UE based on the content of the downlink data packet when no matching packet filter is found; Alternatively, the existing packet filter may be used at the UE when the content of the existing packet filter matches the content of the downlink data packet.

11. The wireless communication device according to claim 10, wherein, The reactive subcircuit is also configured to timestamp either the new group filter or the existing group filter.

12. The wireless communication device according to claim 11, wherein, The reactive sub-circuit is also configured to delete the group filter based on the corresponding timestamp.

13. An apparatus for wireless communication, comprising: A unit used to establish Protocol Data Unit (PDU) sessions based on non-Internet Protocol (IP); A unit for selecting a packet filter based on at least one aspect of data packets formatted in a non-IP format associated with the non-IP-based PDU session, wherein the non-IP-based PDU session is an Ethernet-based PDU session, and the data packets include IP data and are formatted in an Ethernet format. The selection unit is configured to select the packet filter based on the content included in the Ethernet frame header of the data packet, and the selection unit further includes: a unit for evaluating the content included in the IP header of the data packet only if at least a portion of the content included in the Ethernet frame header of the data packet corresponds to a matching packet filter; and A unit for filtering the transmission of the data packets according to the packet filter.

14. The apparatus according to claim 13, wherein, The selection unit is also configured to select the packet filter based on the content included in the IP header of the data packet.

15. The apparatus according to claim 13, wherein, The selection unit is configured to: evaluate downlink data packets received from the network when reactive QoS is enabled, wherein the evaluation further includes: determining whether the content of the downlink data packets matches a corresponding packet filter in the user equipment (UE).

16. The apparatus according to claim 15, wherein, The selection unit is configured to: create a new packet filter at the UE based on the content of the downlink data packet when no matching packet filter is found; Alternatively, the existing packet filter may be used at the UE when the content of the existing packet filter matches the content of the downlink data packet.

17. The apparatus of claim 16, further comprising a unit for timestamping one of the new grouping filters or the existing grouping filters.

18. The apparatus of claim 17, further comprising a unit for deleting group filters based on corresponding timestamps.

19. A non-transitory computer-readable medium storing computer-executable code, comprising code for causing a computer to perform the following operations: Establish Protocol Data Unit (PDU) sessions based on non-Internet Protocol (IP); The packet filter is selected based on at least one aspect of data packets formatted in a non-IP format associated with the non-IP-based PDU session, wherein, The non-IP-based PDU session is an Ethernet-based PDU session, wherein the data packets include IP data and are formatted in Ethernet format. The selection of the packet filter is based on the content included in the Ethernet frame header of the data packet, and the selection further includes: The content included in the IP header of the data packet is evaluated only if at least a portion of the content included in the Ethernet frame header of the data packet corresponds to a matching packet filter; and The transmission of the data packets is filtered according to the packet filter.

20. The non-transitory computer-readable medium according to claim 19, wherein, The selection of the packet filter is still based on the content included in the IP header of the data packet.

21. The non-transitory computer-readable medium of claim 19, further comprising: A reactive instruction for causing the computer to perform the following operation: when reactive QoS is enabled, evaluate downlink data packets received from the network, wherein the reactive instruction causes the computer to perform the following operation: determine whether the content of the downlink data packets matches a corresponding packet filter in a user equipment (UE).

22. The non-transitory computer-readable medium according to claim 21, wherein, The reactive instruction also causes the computer to perform the following operation: when no matching packet filter is found, to create a new packet filter at the UE based on the content of the downlink data packet; Alternatively, the existing packet filter may be used at the UE when the content of the existing packet filter matches the content of the downlink data packet.

23. The non-transitory computer-readable medium of claim 22, further comprising code for causing the computer to timestamp one of the new grouping filter or the existing grouping filter.

24. The non-transitory computer-readable medium of claim 23, further comprising code for causing the computer to perform the following operation: deleting a group filter based on a corresponding timestamp.

Images