CN116260737A - New radio cellular quality of service enabling non-internet protocol data sessions - Google Patents

Abstract

Aspects of the present disclosure relate to New Radio (NR) cellular quality of service (QoS) for implementing non-Internet Protocol (IP) data sessions. In certain aspects of the present 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 the data packet is then filtered according to the packet filter.

Description

New radio cellular quality of service enabling non-internet protocol data sessions

The present application is a divisional application of patent application number 201880029793.6 with application date 2018, month 03, 07 entitled "new radio cellular quality of service for implementing non-internet protocol data sessions".

Cross Reference to Related Applications

The present application claims priority and benefit from provisional application No.62/502,692 filed 5/7/2017 to the U.S. patent and trademark office and non-provisional application No.15/913,745 filed 3/6/2018, which are incorporated herein by reference in their entireties for all purposes as if fully set forth herein below without losing their entirety.

Technical Field

The techniques discussed below relate generally to wireless communication systems, and in particular to implementing New Radio (NR) cellular quality of service (QoS) for non-Internet Protocol (IP) data sessions (e.g., ethernet, unstructured, etc.).

Background

In a wireless communication network, quality of service (QoS) may be provided to users of the network. QoS mechanisms generally control parameters of a wireless network such as its performance, its reliability, and its availability. These parameters may be determined based on certain metrics such as coverage and accessibility of the network, and its call quality (especially audio and video quality). In third generation partnership project (3 GPP) and fourth generation (4G) cellular networks, the network may configure User Equipment (UE) to filter Uplink (UL) user data packets in order to route them to different bearers receiving different QoS. This is typically done by assigning one or more "packet filters" to the bearer, where each packet filter has an associated evaluation priority index. Before transmitting UL user data packets, the UE checks whether the packet matches any of the network configured packet filters in ascending order of the evaluation priority index and transmits the packet on the bearer associated with the packet filter for which there is a match.

Since all data connections up to release 12,3GPP and 4G cellular networks are Internet Protocol (IP) based, the format of the packet filter (specified in 3gpp TS 24.008 sub-clause 10.5.6.12) depends on the content of the IP header of the data packet. Thus, the packet filter may include one or more of the following criteria: the source IP address matches a certain value; the destination IP address matches a certain value; the source port number matches a certain value; the destination port number is within a certain range; the source port range matches within a certain value; the protocol identifier/next header type field matches a certain value; the security parameter index type is matched with a certain value; the service type/traffic class type matches a certain value; and/or the stream marker type matches a certain value.

In the fifth generation (5G) networks, data connections of the "ethernet" and "unstructured" types (also referred to as Protocol Data Unit (PDU) sessions) are introduced (see e.g. 3gpp TS 23.501). However, since user data packets for these PDU session types do not necessarily have IP headers, the current format of the packet filter does not allow filtering of the corresponding packets to provide differential QoS. It would therefore be desirable to provide a solution for achieving QoS within a PDU session of the "ethernet" or "unstructured" type.

Furthermore, in 5G, the use of reflected QoS on cellular networks is introduced. When the reflective QoS is activated, the UE needs to self-construct an UL packet filter based on the received DL user data packets. To this end, although the mechanism by which the UE self-constructs UL packet filters for IP data is well known (see e.g. 3gpp TS 24.139 clauses 5.2.3 and 5.2.4), such procedures are not specified for PDU sessions of the "ethernet" or "unstructured" type. Thus, when reflected QoS is enabled, it would be desirable to provide a solution for self-configuring UL packet filters at the UE for PDU sessions of the "ethernet" or "unstructured" type.

Disclosure of Invention

The following presents a simplified summary of one or more aspects of the disclosure in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated features of the disclosure, nor is it intended to identify key or critical elements of all aspects of the disclosure or to delineate the scope of any or all aspects of the disclosure. Its sole purpose is to present some concepts of one or more aspects of the disclosure in a simplified form as a prelude to the more detailed description that is presented later.

In the examples below, the disclosed aspects relate to a New Radio (NR) cellular quality of service (QoS) that enables a non-Internet Protocol (IP) data session (e.g., ethernet, unstructured, etc.). For example, a solution is disclosed for how to extend the current packet filter format to achieve QoS within a Protocol Data Unit (PDU) session for non-IP based types (e.g., ethernet, unstructured, etc.). Solutions are also disclosed for self-constructing a packet filter at a User Equipment (UE) for a non-IP based PDU session when reflective QoS is enabled.

In one example, a method of wireless communication is disclosed. The method comprises the following steps: a non-IP based 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 method then further comprises: the transmission of the data packets is filtered according to the packet filter.

In a second example, a wireless communication device is disclosed. The wireless communication device includes: a processor communicatively coupled to the memory, the transceiver, the communication circuit, the selection circuit, and the filtering circuit. For this example, the communication circuit is configured to: a non-IP based PDU session is established and the selection circuit is configured to: 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. The filtering circuit is then configured to: the transmission of the data packets is filtered according to the packet filter.

In a third example, an apparatus for wireless communication is disclosed. The device comprises: the apparatus includes means for establishing a non-IP based PDU session, and means 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 comprises: and means for filtering the transmission of the data packets according to the packet filter.

In a fourth example, a non-transitory computer-readable medium storing computer-executable code includes code for causing a computer to perform various acts. 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.

These and other aspects of the invention will become more fully understood upon reading the following detailed description. Other aspects, features and embodiments of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific, exemplary embodiments of the invention in conjunction with the accompanying figures. Although features of the invention are discussed with respect to certain embodiments and figures 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 in accordance with various embodiments of the invention discussed herein. In a similar manner, while exemplary embodiments are discussed below as device, system, or method embodiments, it should be understood that these exemplary embodiments may be implemented with a variety of devices, systems, and methods.

Drawings

Fig. 1 is a schematic diagram of a wireless communication system.

Fig. 2 is a conceptual diagram of an example of a radio access network.

Fig. 3 is a block diagram illustrating certain aspects of the architecture of a next generation (e.g., fifth generation or 5G) wireless communication network.

Fig. 4 is a block diagram illustrating an exemplary system that facilitates filtering data packets in accordance with some aspects of the present disclosure.

Fig. 5 is a block diagram illustrating an example of a hardware implementation of a scheduling entity apparatus employing a processing system in accordance with some aspects of the present disclosure.

Fig. 6 is a block diagram illustrating exemplary sub-components of the selection circuits and software shown in fig. 5.

Fig. 7 is a flow chart illustrating an exemplary process for filtering downlink data packets in accordance with aspects of the present disclosure.

Fig. 8 is a flow chart illustrating an exemplary process for filtering ethernet type downlink data packets in accordance with aspects of the present disclosure.

Fig. 9 is a flow chart illustrating an exemplary process for filtering unstructured-type downlink data packets in accordance with aspects of the present disclosure.

Fig. 10 is a block diagram illustrating an example of a hardware implementation of a scheduled entity apparatus employing a processing system in accordance with some aspects of the present disclosure.

Fig. 11 is a block diagram illustrating exemplary subcomponents of the selection circuitry and software shown in fig. 10.

Fig. 12 is a flow chart illustrating an exemplary process for filtering uplink data packets in accordance with aspects of the present disclosure.

Fig. 13 is a flow chart illustrating an exemplary process for filtering ethernet type uplink data packets in accordance with aspects of the present disclosure.

Fig. 14 is a flow chart illustrating an exemplary process for filtering unstructured-type uplink data packets in accordance with aspects of the present disclosure.

Fig. 15 is a flow chart illustrating an exemplary process for filtering uplink data packets when reflected quality of service (QoS) is enabled, in accordance with aspects of the present disclosure.

Detailed Description

The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be implemented. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. It will be apparent, however, to one skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

As will be discussed in greater detail herein, the present disclosure includes aspects related to a solution for how to extend the current packet filter format to enable quality of service (QoS) within a Protocol Data Unit (PDU) session for non-Internet Protocol (IP) based types (e.g., ethernet, unstructured, etc.). For example, for an "ethernet" type PDU session, the intended filtering may be based on the content of the ethernet frame header, where any of a variety of parameters may be added to the packet filter. Aspects are also disclosed for how to prioritize matching of packet filters based on criteria including ethernet frame headers and/or IP frame headers (e.g., no priority, only evaluate the content of IP headers if there is no matching for ethernet frame headers, etc.). For "unstructured" type PDU sessions, it is disclosed that the mapping of user data packets to specific QoS treatments is not based on the content of the packet itself, but on aspects of the application that generated the packet, since the format of the packets exchanged during the PDU session is not standardized (i.e. it is not possible to define packet filter components based on header content).

The present disclosure also includes aspects related to a solution for self-building a packet filter at a UE for a non-IP based PDU session when reflective QoS is enabled. For example, for "ethernet" and "unstructured" type PDU sessions, embodiments are disclosed in which the UE self-constructs an Uplink (UL) packet filter based on received Downlink (DL) packets.

Definition of the definition

RAT: radio access technology. A technology type or communication standard for wireless access and communication over a wireless air interface. Only a few examples of RATs include GSM, UTRA, E-UTRA (LTE), bluetooth and Wi-Fi.

NR: new radio. Generally referred to as 5G technology and new radio access technology, which have undergone the definition and standardization by 3GPP in release 15.

RAB: a radio access bearer. The access layer provides services to the non-access layers for transmitting user information between the UE and the core network.

QoS: quality of service. A collective effect of service performance of user satisfaction with the service is determined. QoS is characterized by a combined aspect 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.

The various concepts presented throughout this disclosure may be implemented in a wide variety of telecommunication systems, network architectures, and communication standards. Referring now to fig. 1, by way of example and not limitation, various aspects of the present disclosure are illustrated 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 may be implemented to perform data communication with an external data network 110, such as, but not limited to, the internet.

RAN 104 may implement any one or more suitable wireless communication techniques or technologies to provide wireless access to UE 106. As one example, RAN 104 may operate in accordance with the third generation partnership project (3 GPP) New Radio (NR) specification (often referred to as 5G). As another example, the RAN 104 may operate in accordance with a mix of 5G NR and evolved universal terrestrial radio access network (eUTRAN) standards (often referred to as LTE). The 3GPP refers to this hybrid RAN as the next generation RAN or NG-RAN. Of course, many other examples may be utilized within the scope of the present disclosure.

As shown, RAN 104 includes a plurality of base stations 108. In a broad sense, 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, a base station may also be referred to variously by those skilled in the art as a Base Transceiver Station (BTS), a radio base station, a radio transceiver, a transceiver function, a Basic Service Set (BSS), an Extended Service Set (ESS), an Access Point (AP), a node B, an evolved node B (eNB), a gndeb (gNB), or some other suitable terminology.

The radio access network 104 is also shown to support wireless communications for a plurality of mobile devices. In the 3GPP standard, a mobile device may be referred to as a User Equipment (UE), but may also be referred to by those skilled in the art as a Mobile Station (MS), a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless communication device, a remote device, a mobile subscriber station, an Access Terminal (AT), a mobile terminal, a wireless terminal, a remote terminal, a handset, a terminal, a user agent, a mobile client, a client, or some other suitable terminology. The UE may be a device that provides access to network services to the user.

In this document, a "mobile" device need not necessarily have the capability to move, but may be stationary. The term mobile device or mobile equipment refers broadly to a wide variety of devices and technologies. For example, some non-limiting examples of mobile devices include mobile stations, cellular (cell) phones, smart phones, session Initiation Protocol (SIP) phones, laptops, personal Computers (PCs), notebooks, netbooks, smartbooks, tablet devices, personal Digital Assistants (PDAs), and a wide range of embedded systems, e.g., corresponding to the "internet of things" (IoT). In addition, the mobile device may be a consumer device and/or a wearable device such as an automobile or other transportation vehicle, a remote sensor or actuator, a robot or robotic device, a satellite radio, a Global Positioning System (GPS) device, an object tracking device, an unmanned aerial vehicle, a multi-purpose helicopter, a four-axis aircraft, a remote control device, a device such as glasses, a wearable camera, a virtual reality device, a smart watch, a health or fitness tracker, a digital audio player (e.g., MP3 player), a camera, a game console, and so forth. In addition, the mobile device may also be a digital home or smart home device such as a home audio, video and/or multimedia device, appliance, vending machine, smart lighting, home security system, smart meter, etc. In addition, the mobile device may also be a smart energy device, a security device, a solar panel or solar array, municipal infrastructure equipment to control power (e.g., smart grid), lighting, water, etc.; industrial automation and enterprise equipment; a logistics controller; agricultural equipment; military defenses, vehicles, aircraft, watercraft, weapons, and the like. In addition, the mobile device may provide connected medical or telemedicine support (i.e., telemedicine). The telemedicine devices may include telemedicine monitoring devices and telemedicine management devices whose communications may be prioritized or accessed relative to other types of information, such as, for example, prioritized access with respect to transmission of critical service data, and/or associated QoS for transmission of critical service data.

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

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

The base station 108 is not the only entity that can act as a scheduling entity. That is, in some examples, a UE may act as a scheduling entity scheduling resources for one or more scheduled entities (e.g., one or more other UEs).

As shown in fig. 1, scheduling entity 108 may broadcast downlink traffic 112 to one or more scheduled entities 106. In broad terms, the scheduling entity 108 is a node or device responsible for scheduling traffic (including downlink traffic 112, and in some examples, uplink traffic 116 from one or more scheduled entities 106 to the scheduling entity 108) in a wireless communication network. In another aspect, the scheduled entity 106 is a node or device that receives downlink control information 114 (including but not limited to scheduling information (e.g., grants), synchronization or timing information, or other control information) from another entity in the wireless communication network, such as scheduling entity 108.

In general, the base station 108 may include a backhaul interface for communicating with a backhaul portion 120 of a wireless communication system. Backhaul 120 may provide a link between base station 108 and core network 102. Further, in some examples, the backhaul network may provide interconnection between respective base stations 108. Various types of backhaul interfaces may be used, such as direct physical connections, virtual networks, or backhaul interfaces using any suitable transport network.

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

Referring now to fig. 2, by way of example and not limitation, a schematic diagram of a RAN 200 is provided. In some examples, RAN 200 may be the same as RAN 104 described above and shown in fig. 1. The geographical area covered by the RAN 200 may be divided into a plurality of cellular areas (cells) that may be uniquely identified by a User Equipment (UE) based on an identification broadcast from one access point or base station. Fig. 2 shows macro cells 202, 204, and 206, and small cell 208, each of which may include one or more sectors (not shown). A sector is a sub-region of a cell. All sectors in a cell are served by the same base station. The radio links in a sector can be identified by a single logical identification belonging to the sector. In a cell divided into multiple sectors, the multiple sectors in a cell may be formed by groups of antennas, where each antenna is responsible for communication with UEs in a portion of the cell.

In fig. 2, two base stations 210 and 212 are shown in cells 202 and 204; and a third base station 214 is shown for controlling a Remote Radio Head (RRH) 216 in the cell 206. That is, the base station may have an integrated antenna or may be connected to an antenna or RRH through a feeder cable. In the illustrated example, cells 202, 204, and 126 may be referred to as macro cells because base stations 210, 212, and 214 support cells having a larger size. Further, the base station 218 is shown in a small cell 208 (e.g., a micro cell, pico cell, femto cell, home base station, home node B, home eNodeB, etc.), where the small cell 208 may overlap with one or more macro cells. In this example, cell 208 may be referred to as a small cell because base station 218 supports cells having a relatively small size. Cell size settings may be made according to system design and component constraints.

It should be appreciated that the radio access network 200 may include any number of radio base stations and cells. Furthermore, relay nodes may be deployed to extend the size or coverage area of a given cell. The base stations 210, 212, 214, 218 provide wireless access points for the core network for any number of mobile devices. In some examples, base stations 210, 212, 214, and/or 218 may be the same as base station/scheduling entity 108 described above and shown in fig. 1.

Fig. 2 also includes a four-axis aerial vehicle or drone 220, which may be configured to act as a base station. That is, in some examples, the cells may not need to be stationary, and the geographic area of the cells may move according to the location of the mobile base station (e.g., the four-axis aircraft 220).

In RAN 200, a cell may include UEs that may communicate with one or more sectors of each cell. Further, each base station 210, 212, 214, 218, and 220 may be configured to provide an access point for the core network 102 (see fig. 1) for all UEs in the respective cell. For example, UEs 222 and 224 may communicate with base station 210; UEs 226 and 228 may communicate with base station 212; UEs 230 and 232 may communicate with base station 214 by way of RRH 216; UE 234 may communicate with base station 218; and UE 236 may communicate with mobile base station 220. In some examples, UEs 222, 224, 226, 228, 230, 232, 234, 236, 238, 240, and/or 242 may be the same as UE/scheduled entity 106 described above and shown in fig. 1.

In some examples, a mobile network node (e.g., a four-axis vehicle 220) may be configured to act as a UE. For example, the four-axis aircraft 220 may operate in the cell 202 by communicating with the base station 210.

In further aspects of the RAN 200, side link signals may be used between UEs without relying on scheduling or control information from the base stations. For example, two or more UEs (e.g., UEs 226 and 228) may communicate with each other using peer-to-peer (P2P) or side link signals 227 without the need to relay the communication through a base station (e.g., base station 212). In further examples, UE 238 is shown in communication with UEs 240 and 242. Here, UE 238 may act as a scheduling entity or primary side link device, and UEs 240 and 242 may act as scheduled entities or non-primary (e.g., secondary) side link devices. In another example, the UE may 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 may optionally communicate directly with each other in addition to communicating with scheduling entity 238. Thus, in a wireless communication system having scheduled access to time-frequency resources and having a cellular, P2P, or grid configuration, a scheduling entity and one or more scheduled entities may utilize the scheduled resources to communicate.

In the radio access network 200, the ability of a UE to communicate (independent of its location) while moving is referred to as mobility. The various physical channels between the UE and the radio access network are typically established, maintained and released under control of an access and mobility management function (AMF, not shown, part of the core network 102 in fig. 1), which may include a Security Context Management Function (SCMF) that manages security contexts for both control plane and user plane functions, and a security anchoring function (SEAF) that performs authentication.

In various aspects of the present disclosure, wireless access network 200 may use DL-based mobility or UL-based mobility to effect mobility and handover (i.e., a connection of a UE transitions from one radio channel to another). In a network configured for DL-based mobility, the UE may monitor various parameters of signals from its serving cell and various parameters of neighboring cells during a call with a scheduling entity, or at any other time. Depending 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 cell, or if the signal quality from the neighboring cell exceeds the signal quality from the serving cell for a given amount of time, the UE may perform a handover or handoff 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 region corresponding to its serving cell 202 to a geographic region corresponding to neighbor cell 206. When the signal strength or quality from neighbor cell 206 exceeds the signal strength or quality of its serving cell 202 for a given amount of time, UE 224 may send a report message to its serving base station 210 indicating the condition. In response, UE 224 may receive a handover command and the UE may proceed with the handover to cell 206.

In a network configured for UL-based mobility, the network may 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 may broadcast a unified synchronization signal (e.g., unified Primary Synchronization Signal (PSS), unified Secondary Synchronization Signal (SSS), and unified Physical Broadcast Channel (PBCH)). The UEs 222, 224, 226, 228, 230, and 232 may receive these unified synchronization signals, derive carrier frequencies and slot timings from these synchronization signals, and transmit uplink pilot or reference signals in response to the derived timings. Uplink pilot signals transmitted by a UE (e.g., UE 224) may be received simultaneously by two or more cells (e.g., base stations 210 and 214/216) in wireless access network 200. Each of these cells may measure the strength of the pilot signal and the radio access network (e.g., one or more of base stations 210 and 214/216 and/or a central node in the core network) may determine a serving cell for UE 224. As UE 224 moves through radio access network 200, the network may continue to monitor the uplink pilot signals transmitted by UE 224. When the signal strength or quality of the pilot signal measured by the neighbor cell exceeds the signal strength or quality measured by the serving cell, the network 200 may switch the UE 224 from the serving cell to the neighbor cell, either with or without informing the UE 224.

Although the synchronization signals transmitted by base stations 210, 212, and 214/216 may be uniform, the synchronization signals may not identify a particular cell, but may identify areas of multiple cells operating on the same frequency and/or using the same timing. Using areas in a 5G network or other next generation communication network, an uplink-based mobile framework is implemented and efficiency of both the UE and the network is improved, since it can reduce the number of mobile messages that need to be exchanged between the UE and the network.

In various implementations, the air interface in the wireless access network 200 may use licensed spectrum, unlicensed spectrum, or shared spectrum. Licensed spectrum is typically purchased by a mobile network operator from a government regulatory agency, providing exclusive use of a portion of the spectrum. Unlicensed spectrum provides shared use of a portion of spectrum without the need for government-authorized licenses. There is still generally some need to adhere to technical rules to access unlicensed spectrum, but in general, any operator or device may gain access. The shared spectrum may fall between a licensed spectrum and an unlicensed spectrum, where some technical rules or restrictions for accessing the spectrum may be required, but the spectrum may still be shared by multiple operators and/or multiple RATs. For example, a license holder of a portion of a licensed spectrum may provide License Sharing Access (LSA) to share the spectrum with other parties (e.g., with appropriate licensee-determined conditions to gain access).

In some examples, the scheduled entity (such as the first scheduled entity 204a and the second scheduled entity 204 b) may utilize the side link signals for direct D2D communication. The side link signals may include side link traffic 214 and side link traffic 216. In some examples, the side link control information 216 may include request signals, such as Request To Send (RTS), source Transmit Signals (STS), and/or Direction Select Signals (DSS). The request signal may enable the scheduled entity 204 to request the duration of the sidelink channel remaining available for the sidelink signal. The side link control information 216 may also include response signals such as Clear To Send (CTS) and/or Destination Receive Signals (DRS). The response signal may enable the scheduled entity 204 to indicate the availability of the side link channel, e.g., for the requested duration. The exchange of request signals and response signals (e.g., handshakes) may enable different scheduled entities performing side link communications to negotiate the availability of side link channels prior to communication of side link traffic information 214.

The air interface in radio access network 200 may use one or more duplexing algorithms. Duplex refers to a point-to-point communication link in which two endpoints can communicate with each other in two directions. Full duplex means that two endpoints can communicate with each other simultaneously. Half duplex means that only one endpoint can send information to the other endpoint at one time. In wireless links, full duplex channels typically rely on physical isolation of the transmitter and receiver and appropriate interference cancellation techniques. Full duplex emulation is often implemented for wireless links by utilizing Frequency Division Duplexing (FDD) or Time Division Duplexing (TDD). In FDD, transmissions in different directions operate at 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 transmissions in one direction, and at other times, the channel is dedicated to transmissions in another direction, where the direction may change very rapidly (e.g., several times per subframe).

In order to achieve a low block error rate (BLER) for transmissions on the radio access network 200, while still achieving a very high data rate, channel coding may be used. That is, in general, wireless communication may utilize an appropriate error correction block code. In a typical block code, an information message or sequence is split into Code Blocks (CBs), and then an encoder (e.g., CODEC) at the transmitting device mathematically adds redundancy to the information message. Exploiting this redundancy in the encoded information message may improve the reliability of the message, thereby enabling correction of any bit errors that may occur due to noise.

In the 5G NR specification, user data is encoded using quasi-cyclic Low Density Parity Check (LDPC) with two different base patterns: one base map for large code blocks and/or high code rates and another base map for other cases. The control information and Physical Broadcast Channel (PBCH) are encoded using polarization coding based on the nested sequence. For these channels puncturing, shortening and repetition are used for rate matching.

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

The air interface in wireless access network 200 may use one or more multiplexing and multiple access algorithms to enable simultaneous communication of the various devices. For example, the 5G NR specification provides multiple access for UL transmissions from UEs 222 and 224 to base station 210 and multiplexing with Orthogonal Frequency Division Multiplexing (OFDM) with Cyclic Prefix (CP) for DL transmissions from base station 210 to one or more UEs 222 and 224. In addition, for UL transmissions, the 5G NR specification provides support for discrete fourier transform spread-spectrum OFDM with CP (DFT-s-OFDM), also known as single carrier FDMA (SC-FDMA). However, it is within the scope of the present disclosure that multiplexing and multiple access are not limited to the above schemes and may 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. Further, multiplexed DL transmissions from base station 210 to UEs 222 and 224 may be provided using Time Division Multiplexing (TDM), code Division Multiplexing (CDM), frequency Division Multiplexing (FDM), orthogonal Frequency Division Multiplexing (OFDM), sparse Code Multiplexing (SCM), or other suitable multiplexing schemes.

Referring next to fig. 3, a block diagram illustrating aspects of the architecture of a Core Network (CN) in a next generation (e.g., fifth generation or 5G) wireless communication network is provided. As shown, the features may include a UE 302 communicating with a core network 306 by way of an access network 304. In this illustration, it is assumed that the access network routes any signal paths between these entities between the UE and the CN, as represented by the illustrated signal paths on the access network. Here, the access network 304 may be the access network 200 described above and shown in fig. 2. In another example, the 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 performed or action of 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 one non-limiting example, such reference to AN may be understood to refer to a base station for clarity of description. However, those skilled in the art will appreciate that this is not always the case, e.g., as in some 3G RANs, the base station is under the control or direction of a centralized radio network controller within its AN.

The UE 302 has both User Plane (UP) and Control Plane (CP) functions (and may have UE features as generally discussed herein). In fig. 3, CP signaling is indicated by a dotted line, and UP signaling is indicated by a solid line. The Access Network (AN) 304 also includes some CP functionality (shown with CP block 303 at AN 304), but most CP functionality is at CN 306. Specifically, the CN 306 includes a control plane mobility management function (CP-MM) 308 and a control plane session management function (CP-SM) 310.

The CP-MM 308 establishes and maintains mobility management contexts for devices (e.g., UE 302) attached to the CN 306 through one or more access technologies. CP-SM 310 establishes, maintains, and terminates Data Network (DN) sessions and data sessions in the next generation system architecture, including establishing these sessions on demand. CP-SM 310 also decides a quality of service (QoS) for the UE for the DN session and/or the data session.

An authentication, authorization, and accounting (AAA) server/Policy Function (PF) block 312 serves as a profile repository and authentication server. AAA/policy function 312 may store user profiles and user credentials and may store and make decisions regarding policies (e.g., qoS policies) to be applied to the UE for DN sessions and/or data sessions.

The User Plane (UP) infrastructure entity 314 represents any suitable communication infrastructure in the CN 306 that delivers data between the AN 304, a user plane gateway (UP-GW) 316, and AN external data network 318. The UP-GW 316 may be communicatively coupled with the CP-SM 310 to configure the UP connection on the CN 306. The external data network may be any suitable data network including, but not limited to, the internet, an IP Multimedia Subsystem (IMS) network, and the like.

In the present disclosure, when reference is made to a core network or CN, it may be assumed that such reference is intended to mean any of the nodes within the CN, unless a specific reference is made to a particular node.

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

A Data Network (DN) session is a logical context or collection of context information in various entities that provides a framework for connection between a local endpoint (e.g., a web browser) in the UE 302 and a remote endpoint (e.g., an IMS network, the internet, a private network, a web server in a remote host, etc.) in the external data network 318. The DN session contains state information related to various entities such as UEs, ANs, CNs, gateways, etc., and may be served by multiple UP-GWs in one or more CNs. The DN session may comprise one or more data sessions.

A data session (also referred to as a PDU session, data stream, or stream) is a logical context in the UE that enables communication between a local endpoint (e.g., a web browser) in the UE and a remote endpoint (e.g., a web server in a remote host) in the external data network 318. The data session may be an IP session or a non-IP session (e.g., ethernet traffic). Within this disclosure, any reference to a packet or PDU (protocol data unit) is interchangeable and is intended to refer to an IP packet or a non-IP PDU.

Referring next to fig. 4, a block diagram illustrating an exemplary system that facilitates filtering data packets in accordance with some aspects of the present disclosure is provided. As shown, a User Equipment (UE) 400 is communicatively coupled to a Core Network (CN) 440 via a plurality of PDU sessions (e.g., PDU sessions 480, 490), wherein packet filters (e.g., packet filters 420, 422, 460, 462) are associated with a particular PDU session (e.g., PDU sessions 480, 490). To facilitate filtering Uplink (UL) data packets 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 session 480, 490) is established, or the UE 400 may be configured to self-construct the packet filters 420, 422 (e.g., in the case of a reflective QoS). As shown, it is generally assumed that UL data packets are received from the application layer 430 of the UE 400, as shown. The UE 400 then utilizes aspects of UL packets to match particular packet filters to corresponding PDU sessions (e.g., packet filter 420 to PDU session 490, or packet filter 422 to PDU session 480), where the packet filters (e.g., packet filters 420 or 422) filter UL packets in a manner that is transparent to the PDU session handling unit 410.

Similar procedures are expected to be used when filtering Downlink (DL) data packets on the CN 440. Here, however, unlike receiving UL data packets from the application layer 430, it is assumed that DL data packets are received from the external internet/intranet 470, as shown. The CN 440 then utilizes aspects of the DL packets to match particular packet filters to corresponding PDU sessions (e.g., packet filter 460 to PDU session 480, or packet filter 462 to PDU session 490), wherein the packet filters (e.g., packet filters 460 or 462) filter the DL packets in a manner that is transparent to the PDU session processing unit 450.

Extension of packet filters for "Ethernet" PDU session types

As previously discussed, aspects disclosed herein include a solution for how to extend the current packet filter format to achieve quality of service (QoS) within a Protocol Data Unit (PDU) session of the "ethernet" type. Here, since ethernet frames may carry Internet Protocol (IP) data, it is contemplated that existing packet filter components specified in TS 24.008 sub-clause 10.5.6.12 may be included in packet filters (e.g., packet filters 420, 422, 460, 462) for PDU sessions of the "ethernet" type. Thus, it is also contemplated that the filtering may be based on the content of the ethernet frame header, wherein any of a variety of parameters may be added to the packet filter (e.g., packet filters 420, 422, 460, 462). For example, the packet filters (e.g., packet filters 420, 422, 460, 462) may be configured to include any of the following parameters: a destination MAC address; a source MAC address; VLAN Identifier (VID); 802.1Q PCP (indicating packet priority); and/or an ethertype.

In certain aspects disclosed herein, it is therefore contemplated that content included in both the ethernet frame header and the IP header may be used to select a corresponding packet filter. For example, an example is disclosed in which content inferred from an ethernet frame header and content inferred from an IP header each have the same level of priority. Further, for this particular example, to announce a match, the criteria in the filter corresponding to content inferred from both the ethernet frame header and the IP header would need to be met (priority ranking is not sequential).

In another example, a two-level hierarchy is used in which criteria in a filter corresponding to content derived from an ethernet frame header are evaluated before evaluating criteria corresponding to content derived from an IP header. That is, it is contemplated that a UE (e.g., UE 400) and a CN (e.g., CN 440) may be configured to: the contents of the IP header are evaluated only if the contents of the ethernet frame header match the filter.

Extension of packet filters to "unstructured" PDU session types

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

One possible solution disclosed herein is to implement mapping of user data packets to specific QoS treatments based on the application generating the packets, rather than based on the content of the packets themselves. In this case, the packet filter (e.g., packet filters 420, 422, 460, 462) may include one or more application identifiers (e.g., OS id+os App Id). Within such embodiments, a modem in a UE (e.g., UE 400) may be configured to: based on information provided by the high-level operating system (HLOS), a tag with an application identifier is added to each user data packet received from the application layer (e.g., application layer 430). Alternatively, the HLOS may be configured to tag each user data packet passed to the modem for transmission with an application identifier. Similarly, on a CN (e.g., CN 440), such marking may be performed by both: 1) A network layer that routes downlink data packets based on information provided by the application layer, or 2) an application layer, wherein filtering comprises: the downlink data packet marked with the application identifier is sent from the application layer to the network layer routing the downlink data packet.

In another disclosed solution, instead of using a packet filter, a particular Access Point Name (APN), also called Data Network Name (DNN) in a 5G system, is requested to be used when setting up a data connection for a particular service or application. Then, in such an example, all user data packets for a particular service or application would be sent on a data connection for a particular APN, and then the network applies a particular QoS treatment based on the APN associated with that data connection.

Reflective QoS for PDU sessions of the "ethernet" type

Aspects of implementing reflected quality of service (QoS) for Protocol Data Unit (PDU) sessions of the "ethernet" type are also disclosed. In one particular embodiment, if reflected QoS is implemented in an "ethernet" type PDU session, the proposal UE (e.g., UE 400) is to construct a packet filter (e.g., packet filters 420, 422) based on received Downlink (DL) data packets. For example, when a 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, it is contemplated that such components (components) may include: a destination MAC address component set as a source MAC address of the received DL packet; a source MAC address component set as a destination MAC address of the received DL packet; a VID component configured to be a VID of the received DL packet if the received DL packet includes an 802.1Q tag therein; an 802.1Q priority component configured to set an 802.1Q priority of the received DL packet if the 802.1Q tag is included in the received DL packet; if the ethertype field of the received DL packet is set to a value of 1536 or more, it is set to an ethertype component of the ethertype of the received DL packet; and/or if the ethertype 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 content of the DL user data IP header as specified in TS 24.139 sub-clause 5.2.4.

In another aspect of the disclosure, it is contemplated that the UE may then be configured to associate the new UL packet filter with the timestamp. For example, if a matching UL filter is found, the UE may be configured to update the timestamp of the matching UL packet filter. The UE may also be configured to delete the packet filter based on its timestamp, where how long the packet filter should be kept may be UE-implementation specific.

As previously stated, the packet filter may be selected based on the contents of both the IP header and the ethernet frame header. In one particular example, these content have the same level of priority and are therefore all included in the same packet filter associated with a single evaluation priority index. Alternatively, a two-level hierarchy is contemplated in which a filter component based on the content of the ethernet frame header is included in a first packet filter having a certain evaluation priority index, and in which a filter component based on the content of the IP header is included in a second packet filter having a higher value of the evaluation priority index than the first filter (i.e., such that the UE only checks the content of the IP header if the content of the ethernet frame header matches the filter).

Reflective QoS for "unstructured" type PDU sessions

Aspects of implementing reflected quality of service (QoS) for a Protocol Data Unit (PDU) session of an "unstructured" type are also disclosed. In one particular embodiment, if reflected QoS is implemented in an "unstructured" type PDU session, the proposal UE (e.g., UE 400) is to self-construct a packet filter (e.g., packet filters 420, 422) based on received Downlink (DL) data packets. For example, when a 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 set to the application identifier of the application generating the DL data packet.

In another aspect of the disclosure, it is contemplated that the UE may then be configured to associate the new UL packet filter with the timestamp. For example, if a matching UL filter is found, the UE may be configured to update the timestamp of the matching UL packet filter. The UE may also be configured to delete the packet filter based on a timestamp of the packet filter, wherein a length of time the packet filter is maintained may be UE-specific.

In one particular example, the determination of the application generating the DL data packet is performed by a modem in the UE. Alternatively, the determination of the application generating the DL data packet is performed by a high-level operating system (HLOS) in the UE and indicated to the modem by HLOS.

Exemplary scheduling entity

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

The scheduling entity 500 may be implemented using a processing system 514 comprising one or more processors 504. Examples of processor 504 include microprocessors, microcontrollers, digital Signal Processors (DSPs), field Programmable Gate Arrays (FPGAs), programmable Logic Devices (PLDs), state machines, gate logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described throughout this disclosure. In various examples, scheduling entity 500 may be configured to perform any one or more of the functions described herein. That is, the processor 504 as used in the scheduling entity 500 may be used to implement any one or more of the processes and procedures disclosed herein.

In this example, the processing system 514 may be implemented using a bus architecture, represented generally by the bus 502. Bus 502 may include any number of interconnecting buses and bridges depending on the specific application of the processing system 514 and the overall design constraints. Bus 502 communicatively couples various circuitry including one or more processors (which is generally represented by processor 504), memory 505, and computer readable media (which is generally represented by computer readable media 506). The 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, will not be described any further. Bus interface 508 provides an interface between bus 502 and transceiver 510. The transceiver 510 provides a means for communicating with various other apparatus over 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.

In some aspects of the disclosure, the 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, the processor 504 may also include selection circuitry 542 configured for various functions. For example, the selection circuit 542 may be configured to: the packet filter is selected based on at least one aspect of a Downlink (DL) data packet formatted in a non-IP format associated with a non-IP based PDU session. The processor 504 may also include a filtering circuit 544 configured for various functions including, for example, filtering transmissions of DL data packets for scheduled entities (e.g., UE 400, scheduled entity 1000, etc.) according to a packet filter. To this end, it should be appreciated that the combination of communication circuit 540, selection circuit 542, and filtering circuit 544 may be configured to implement one or more of the functions described herein.

It should be appreciated that various other aspects of the scheduling entity 500 are also contemplated. For example, to facilitate selection of packet filters when the non-IP based PDU session is an ethernet based PDU session such that DL data packets to be filtered are formatted in ethernet format, it is contemplated that selection circuitry 542 may include an ethernet type sub-circuit 600, as shown in fig. 6. In this example, the ethernet type subcircuit 600 may be configured to: the packet filter is selected based on the content included in the ethernet frame header of the DL data packet. Further, since the ethernet-based PDU session may include IP data, it is also contemplated that the ethernet-type subcircuit 600 may also be configured to: the packet filter is selected based on content included in an IP header of the data packet. To this end, it should be appreciated that both the filter component based on the content of the IP header and the filter component based on the content of the ethernet frame header may have the same level of priority (i.e., all criteria in the filter will need to be met (priority ranking is not sequential) in order to declare a match). Alternatively, if the data packets associated with the ethernet-based PDU session include IP data, the ethernet type subcircuit 600 may be configured to: 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 matched packet filter.

Various aspects are also contemplated with respect to filtering DL data packets having unstructured formats during unstructured PDU-based sessions. For example, to facilitate selection of packet filters during such unstructured PDU-based sessions, it is contemplated that selection circuitry 542 may include unstructured-type subcircuit 610, as shown in fig. 6. In one particular example, unstructured-type subcircuit 610 is configured to: the packet filter is selected based on an identifier associated with an application generating DL data packets to be filtered. For example, unstructured-type subcircuit 610 may also be configured to: marking of DL data packets with such identifiers is facilitated, wherein marking may be performed by any of the various components. For example, unstructured type subcircuit 610 may be coupled to a modem configured to perform tagging based on information provided by a high-level operating system (HLOS). Alternatively, unstructured type subcircuit 610 may be coupled to a HLOS configured to perform tagging, wherein the HLOS is further configured to send tagged DL data packets to a modem.

In another example involving unstructured PDU sessions, it is contemplated that APNs may be used. In such examples, the filtering performed by filtering circuitry 544 includes: requesting an APN when establishing a data connection, wherein the APN corresponds to a specific service or application; and then transmitting DL data packets associated with a particular service or application for the APN.

Referring back to FIG. 5, the processor 504 is responsible for managing the bus 502 and general processing, including the execution of software stored on the computer-readable medium 506. The software, when executed by the processor 504, causes the processing system 514 to perform the various functions described infra for any particular apparatus. The computer-readable medium 506 and the memory 505 may also be used for storing data that is manipulated by the processor 504 when executing software.

One or more processors 504 in the processing system may execute the software. Software should be construed broadly to mean instructions, instruction sets, code segments, program code, programs, subroutines, software modules, applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, and the like, whether referred to as software, firmware, middleware, microcode, hardware description language, or other terminology. The software may be located in a computer readable medium 506. Computer-readable medium 506 may be a non-transitory computer-readable medium. By way of example, non-transitory computer-readable media include magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips), optical disks (e.g., compact Disk (CD) or Digital Versatile Disk (DVD)), smart cards, flash memory devices (e.g., card, stick, or key drive), random Access Memory (RAM), read Only Memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically Erasable PROM (EEPROM), registers, removable disk, and any other suitable media for storing software and/or instructions that can be accessed and read by a computer. The computer readable medium 506 may be located in the processing system 514, external to the processing system 514, or distributed among a plurality of entities including the processing system 514. The 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 encapsulating material. Those of ordinary skill in the art will recognize how best to implement the described functionality presented throughout this disclosure, depending on the particular application and design constraints imposed on the overall system.

In one or more examples, the computer-readable storage medium 506 can 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, the computer-readable storage medium 506 may also include selection software 554 configured for various functions. For example, the selection software 554 may be configured to: the packet filter is selected based on at least one aspect of DL data packets formatted in a non-IP format associated with a non-IP based PDU session. The 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.

It should be appreciated that various other aspects of the computer-readable storage medium 506 are also contemplated. For example, to facilitate selection of a packet filter when the non-IP based PDU session is an ethernet based PDU session such that 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, as shown in fig. 6. In this example, the ethernet type instructions 605 may include instructions for: the packet filter is selected based on the content included in the ethernet frame header of the DL data packet. Further, since the ethernet-based PDU session may include IP data, it is also contemplated that the ethernet type instructions 605 may also include instructions for: the packet filter is selected based on content included in an IP header of the data packet. To this end, it should be appreciated that both the filter component based on the content of the IP header and the filter component based on the content of the ethernet frame header may have the same level of priority (i.e., all criteria in the filter will need to be met (priority ranking is not sequential) in order to declare a match). Alternatively, if the data packets associated with the ethernet-based PDU session include IP data, the ethernet type instructions 605 may include instructions for: 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 matched packet filter.

Various aspects are also contemplated with respect to filtering DL data packets having unstructured formats during unstructured PDU-based sessions. For example, to facilitate selection of packet filters during such unstructured PDU-based sessions, it is contemplated that the selection software 554 may include unstructured type instructions 615, as shown in fig. 6. In one particular example, unstructured type instructions 615 include instructions for: the packet filter is selected based on an identifier associated with an application generating DL data packets to be filtered. For example, unstructured type instructions 615 may include instructions for: marking of DL data packets with such identifiers is facilitated, wherein marking may be performed by any of the various components. For example, unstructured type instructions 615 may include instructions for: the modem is configured to perform marking based on information provided by a High Level Operating System (HLOS). Alternatively, unstructured type instructions 615 may include instructions for: the HLOS is configured to perform tagging, wherein the HLOS is further configured to send tagged DL data packets to the modem.

In another example involving unstructured PDU sessions, it is contemplated that APNs may be used. In such examples, filtering facilitated by the filtering software 556 includes: requesting an APN when establishing a data connection, wherein the APN corresponds to a specific service or application; and then transmitting DL data packets associated with a particular service or application for the APN.

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

Of course, in the above examples, the circuitry included in processor 504 is provided by way of example only, and other elements for performing the described functions, including but not limited to instructions stored in computer-readable storage medium 506, or any other suitable device or element described herein and utilizing, for example, the processes and/or algorithms described with respect to fig. 7-9, may be included within aspects of the present disclosure.

In fig. 7, a flow chart is provided that illustrates an exemplary process for filtering DL data packets in accordance with aspects of the present disclosure. As described below, some or all of the illustrated features may be omitted in certain implementations of the scope of the present disclosure, and some of the illustrated features may not be required for implementation of all embodiments. In some examples, process 700 may be performed by scheduling entity 500 shown in fig. 5. In some examples, process 700 may be performed by any suitable means or unit for performing the functions or algorithms described below.

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

Referring next to fig. 8, a flow chart illustrating an exemplary process for filtering ethernet type DL data packets in accordance with aspects of the present disclosure is provided. Similar to process 700, it should be appreciated that process 800 may be performed by scheduling entity 500 shown in fig. 5, and/or process 800 may be performed by any suitable means or unit for performing the functions or algorithms described below.

At block 802, the process 800 begins with the following operations: the scheduling entity 500 establishes an ethernet type based PDU session with a scheduled entity (e.g., UE 400, scheduled entity 1000, etc.). Process 800 then proceeds to block 804 where scheduling entity 500 evaluates the ethernet frame header of the ethernet formatted DL data packet, and process 800 then proceeds to block 806 where a determination is made as to whether the DL data packet includes IP data.

If the DL data packet does include IP data, the process 800 proceeds to block 808, where the scheduling entity 500 selects a packet filter based on the contents of the ethernet frame header and the IP header. Otherwise, if the DL data packet does not include IP data, the process 800 proceeds to block 807, where the scheduling entity 500 selects a packet filter based on the content of the ethernet frame header. Process 800 then ends with the following operations: the scheduling entity 500 filters transmission of DL data packets for scheduled entities (e.g., UE 400, scheduled entity 1000, etc.) according to a packet filter.

Referring next to fig. 9, a flow chart illustrating an exemplary process for filtering unstructured type DL data packets in accordance with aspects of the present disclosure is provided. Similar to processes 700 and 800, it should be appreciated that process 900 may be performed by scheduling entity 500 shown in fig. 5, and/or process 900 may be performed by any suitable means or unit for performing the functions or algorithms described below.

At block 902, process 900 begins with the following operations: the scheduling entity 500 establishes an unstructured type based PDU session with a scheduled entity (e.g., UE 400, scheduled entity 1000, etc.). Process 900 then continues to block 904 where scheduling entity 500 marks the DL data packet in unstructured format with an identifier associated with the application generating the DL data packet. Then, at block 906, the scheduling entity 500 selects a packet filter based on the application identifier, and then, at block 908, the process 900 ends with: the scheduling entity 500 filters transmission of DL data packets for scheduled entities (e.g., UE 400, scheduled entity 1000, etc.) according to a packet filter.

Exemplary scheduled entity

Fig. 10 is a conceptual diagram illustrating an example of a hardware implementation of an exemplary scheduled entity 1000 employing a processing system 1014. According to various aspects of the disclosure, elements or any portion of elements or any combination of elements may be implemented with a processing system 1014 including one or more processors 1004. For example, the scheduled entity 1000 may be a User Equipment (UE) as shown in any one or more of the figures included herein.

The processing system 1014 may be substantially the same as the processing system 514 shown in fig. 5, including a bus interface 1008, a bus 1002, a memory 1005, a processor 1004, and a computer readable medium 1006. Further, the scheduled entity 1000 may include a user interface 1012 and a transceiver 1010 that are substantially similar to those described above in fig. 5. That is, the processor 1004 as used in the scheduled entity 1000 may be used to implement any one or more of the processes and procedures disclosed herein.

In some aspects of the disclosure, the processor 1004 may include a communication circuit 1040 configured for various functions including, for example, establishing a non-Internet Protocol (IP) based Protocol Data Unit (PDU) session with a scheduling entity (e.g., core network 440, scheduling entity 500, etc.). As shown, the processor 1004 may also include a selection circuit 1042 configured for various functions. For example, the selection circuit 1042 may be configured to: the packet filter is selected based on at least one aspect of uplink (DL) data packets formatted in a non-IP format associated with a non-IP based PDU session. The processor 1004 may also include a filtering circuit 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 a packet filter. To this end, it should be appreciated that the combination of communication circuit 1040, selection circuit 1042, and filter circuit 1044 may be configured to implement one or more of the functions described herein.

It should be appreciated that various other aspects of the scheduled entity 1000 are also contemplated. For example, to facilitate selection of a packet filter when the non-IP based PDU session is an ethernet based PDU session such that DL data packets to be filtered are formatted in ethernet format, it is contemplated that the selection circuit 1042 may comprise an ethernet type sub-circuit 1100, as shown in fig. 11. In this example, the ethernet type subcircuit 1100 may be configured to: the packet filter is selected based on content included in an ethernet frame header of the UL data packet. Further, since the ethernet-based PDU session may include IP data, it is also contemplated that the ethernet-type subcircuit 1100 may also be configured to: the packet filter is selected based on content included in the IP header of the UL data packet. To this end, it should be appreciated that both the filter component based on the content of the IP header and the filter component based on the content of the ethernet frame header may have the same level of priority (i.e., all criteria in the filter should be met (priority ranking is not sequential) in order to declare a match). Alternatively, if UL data packets associated with the ethernet-based PDU session include IP data, the ethernet type subcircuit 1100 may be configured to: the content included in the IP header of the UL data packet is evaluated only when at least a portion of the content included in the ethernet frame header of the UL data packet corresponds to a matched packet filter.

Various aspects are also contemplated with respect to filtering UL data packets having unstructured formats during unstructured PDU-based sessions. For example, to facilitate selection of packet filters during such unstructured-based PDU sessions, it is contemplated that selection circuit 1042 may include an unstructured-type subcircuit 1110, as depicted in FIG. 11. In one particular example, unstructured-type subcircuit 1110 is configured to: the packet filter is selected based on an identifier associated with an application generating UL data packets to be filtered. For example, unstructured-type subcircuit 1110 may also be configured to: marking of UL data packets with such identifiers is facilitated, wherein marking may be performed by any of the various components. For example, unstructured type subcircuit 1110 may be coupled to a modem configured to perform tagging based on information provided by a high-level operating system (HLOS). Alternatively, unstructured type subcircuit 1110 may be coupled to a HLOS configured to perform tagging, wherein the HLOS is further configured to send tagged UL data packets to a modem.

In another example involving unstructured PDU sessions, it is contemplated that APNs may be used. In such examples, the filtering performed by the filtering circuit 1044 includes: requesting an APN when establishing a data connection, wherein the APN corresponds to a specific service or application; and then transmitting UL data packets associated with the particular service or application for the APN.

Aspects related to filtering UL data packets when reflective QoS is enabled are also contemplated. For example, to facilitate selection of a packet filter when reflective QoS is enabled, it is contemplated that selection circuit 1042 may include reflective sub-circuit 1120, as shown in fig. 11. In one particular example, reflective sub-circuit 1120 is configured to: when reflected QoS is enabled, downlink (DL) data packets received from the network are evaluated. Further, it is contemplated that the reflective sub-circuit 1120 may be configured to: it is determined whether the content of the DL data packet matches the corresponding packet filter in the scheduled entity 1000. Then for this example, reflective sub-circuit 1120 may be further configured to: when no matching packet filter is found, creating a new packet filter at the scheduled entity 1000 based on the content of the downlink data packet; or utilize existing packet filters at the scheduled entity 1000 when the contents of the existing packet filters match the contents of the DL data packets. The reflective sub-circuit 1120 may also be configured to: timestamp one of the new packet filter or the existing packet filter, and is further configured to: the packet filters are deleted based on the corresponding timestamps.

Referring back to fig. 10, similar to the processor 504, the processor 1004 is responsible for managing the bus 1002 and general processing, including the execution of software stored on the computer-readable medium 1006. The software, when executed by the processor 1004, causes the processing system 1014 to perform the various functions described infra for any particular apparatus. The computer-readable medium 1006 and the memory 1005 may also be used for storing data that is manipulated by the processor 1004 when executing software.

One or more processors 1004 in the processing system may execute software. Software should be construed broadly to mean instructions, instruction sets, code segments, program code, programs, subroutines, software modules, applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, and the like, whether referred to as software, firmware, middleware, microcode, hardware description language, or other terminology. 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 comprising substantially similar characteristics. The computer-readable medium 1006 may be located in the processing system 1014, external to the processing system 1014, or distributed among multiple entities including the processing system 1014. It should also be appreciated that, similar to computer-readable medium 506, computer-readable medium 1006 may be embodied in a computer program product that includes substantially similar features.

In one or more examples, the computer-readable storage medium 1006 can include communication software 1052 configured for various functions including, for example, establishing a non-IP based PDU session with a scheduling entity (e.g., core network 440, scheduling entity 500, etc.). As shown, the computer-readable storage medium 1006 may also include selection software 1054 configured for various functions. For example, the selection software 1054 may be configured to: the packet filter is selected based on at least one aspect of UL data packets formatted in a non-IP format associated with a non-IP based PDU session. The 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 a packet filter.

It should be appreciated that various other aspects of the computer-readable storage medium 1006 are also contemplated. For example, to facilitate selection of a packet filter when the non-IP based PDU session is an ethernet based PDU session such that UL data packets to be filtered are formatted in ethernet format, it is contemplated that selection software 1054 may include ethernet type instructions 1105, as shown in fig. 11. In this example, the ethernet type instructions 1105 may include instructions for: the packet filter is selected based on content included in an ethernet frame header of the UL data packet. Further, since the ethernet-based PDU session may include IP data, it is also contemplated that the ethernet type instructions 1105 may also include instructions for: the packet filter is selected based on content included in the IP header of the UL data packet. To this end, it should be appreciated that both the filter component based on the content of the IP header and the filter component based on the content of the ethernet frame header may have the same level of priority (i.e., all criteria in the filter will need to be met (priority ranking is not sequential) in order to declare a match). Alternatively, if UL data packets associated with an ethernet-based PDU session include IP data, the ethernet type instructions 1105 may include instructions for: the content included in the IP header of the UL data packet is evaluated only if at least a portion of the content included in the ethernet frame header of the UL data packet corresponds to a matched packet filter.

Various aspects are also contemplated with respect to filtering DL data packets having unstructured formats during unstructured PDU-based sessions. For example, to facilitate selection of packet filters during such unstructured PDU-based sessions, it is contemplated that selection software 1054 may include unstructured-type instructions 1115, as shown in fig. 11. In one particular example, unstructured type instructions 1115 include instructions for: the packet filter is selected based on an identifier associated with an application generating UL data packets to be filtered. For example, unstructured type instructions 1115 may include instructions for: marking of UL data packets with such identifiers is facilitated, wherein marking may be performed by any of the various components. For example, unstructured type instructions 1115 may include instructions for: the modem is configured to perform marking based on information provided by a High Level Operating System (HLOS). Alternatively, unstructured-type instructions 1115 may include instructions for: the HLOS is configured to perform tagging, wherein the HLOS is further configured to send tagged UL data packets to the modem.

In another example involving unstructured PDU sessions, it is contemplated that APNs may be used. In such examples, the filtering facilitated by the filtering software 1056 includes: requesting an APN when establishing a data connection, wherein the APN corresponds to a specific service or application; and then transmitting UL data packets associated with the particular service or application for the APN.

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 a scheduling entity (e.g., core network 440, scheduling entity 500, etc.); means for selecting a packet filter based on at least one aspect of UL data packets formatted in a non-IP format associated with a non-IP based PDU session; and means for filtering transmissions of UL data packets for scheduling entities (e.g., core network 440, scheduling entity 500, etc.) according to a packet filter. In one aspect, the foregoing elements may be processors 1004 configured to perform the functions recited by the foregoing elements. In another aspect, the foregoing elements may be circuitry or any device configured to perform the functions recited by the foregoing elements.

Of course, in the above examples, the circuitry included in processor 1004 is provided by way of example only, and other elements for performing the described functions, including but not limited to instructions stored in computer-readable storage medium 1006, or any other suitable device or element described herein and utilizing, for example, the processes and/or algorithms described with respect to fig. 12-15, may be included within aspects of the present disclosure.

In fig. 12, a flow chart is provided that illustrates an exemplary process for filtering UL data packets in accordance with aspects of the present disclosure. As described below, some or all of the illustrated features may be omitted in certain implementations of the scope of the present disclosure, and some of the illustrated features may not be required for implementation of all embodiments. In some examples, process 1200 may be performed by scheduled entity 1000 shown in fig. 10. In some examples, process 1200 may be performed by any suitable means or unit for performing the functions or algorithms described below.

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

Referring next to fig. 13, a flow chart illustrating an exemplary process for filtering ethernet type UL data packets in accordance with aspects of the present disclosure is provided. Similar to process 1200, it should be appreciated that process 1300 may be performed by scheduled entity 1000 shown in fig. 10, and/or process 1300 may be performed by any suitable means or unit for performing the functions or algorithms described below.

At block 1302, process 1300 begins with the following operations: the scheduled entity 1000 establishes an ethernet type based PDU session with a scheduling entity (e.g., core network 440, scheduling entity 500, etc.). Process 1300 then proceeds to block 1304 where, at block 1304, the scheduled entity 1000 evaluates the ethernet frame header of the ethernet formatted UL data packet, and then process 1300 proceeds to block 1306 where, at block 1306, a determination is made as to whether the UL data packet includes IP data.

If the UL data packet does include IP data, process 1300 proceeds to block 1308 where, at block 1308, 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, the process 1300 proceeds to block 1307 where the scheduled entity 1000 selects a packet filter based on the content of the ethernet frame header. Process 1300 then ends with the following operations: the scheduled entity 1000 filters transmissions of UL data packets for scheduling entities (e.g., core network 440, scheduling entity 500, etc.) according to a packet filter.

Referring next to fig. 14, a flow chart illustrating an exemplary process for filtering unstructured type UL data packets in accordance with aspects of the present disclosure is provided. Similar to processes 1200 and 1300, it should be appreciated that process 1400 may be performed by scheduled entity 1000 shown in fig. 10, and/or process 1400 may be performed by any suitable device or unit for performing the functions or algorithms described below.

At block 1402, process 1400 begins with the following operations: the scheduled entity 1000 establishes an unstructured type based PDU session with a scheduling entity (e.g., core network 440, scheduling entity 500, etc.). Process 1400 then proceeds to block 1404, where, at block 1404, scheduled entity 1000 marks the UL data packet in unstructured format with an identifier associated with the application generating the UL data packet. Then, at block 1406, the scheduled entity 1000 selects a packet filter based on the application identifier, and then, at block 1408, the process 1400 ends with: the scheduled entity 1000 filters transmissions of UL data packets for scheduling entities (e.g., core network 440, scheduling entity 500, etc.) according to a packet filter.

Referring next to fig. 15, a flow chart illustrating an exemplary process for filtering UL data packets when QoS is enabled in accordance with aspects of the present disclosure is provided. Similar to processes 1200, 1300, and 1400, it should be appreciated that process 1500 may be performed by scheduled entity 1000 shown in fig. 10, and/or process 1500 may be performed by any suitable means or unit for performing the functions or algorithms described below.

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

Then, at block 1508, the scheduling entity 1000 determines whether the content of the DL data packet matches an existing packet filter that may be retrieved by the scheduled entity 1000. If a matching packet filter is indeed found, the process 1500 proceeds to block 1510, where the scheduled entity 1000 utilizes the existing packet filter. Otherwise, if no matching packet filter is found, the process 1500 proceeds to block 1509, where the scheduled entity 1000 creates a new packet filter based on the DL data packet at block 1509. Process 1500 then proceeds to block 1512 where, at block 1512, the scheduled entity 1000 time stamps the new/existing packet filters, and then, at block 1514, process 1500 ends with: the scheduled entity 1000 filters transmissions of UL data packets for scheduling entities (e.g., core network 440, scheduling entity 500, etc.) according to new/existing packet filters.

Aspects of a wireless communication network are presented with reference to an exemplary implementation. As will be readily appreciated by one of ordinary skill in the art, the various aspects described throughout this disclosure may be extended to other telecommunication systems, network architectures, and communication standards.

For example, aspects may 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). Various aspects may also be extended to systems specified by third generation partnership project 2 (3 GPP 2), such as CDMA2000 and/or evolution data optimized (EV-DO). Other examples may 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 architectures, and/or communication standards used depend on the particular application and all design constraints imposed on the system.

In the present disclosure, the term "exemplary" is used to mean "serving as an example, instance, or illustration. Any implementation or aspect described herein as "exemplary" should not be construed as preferred or advantageous over other aspects of the present disclosure. Likewise, the word "aspect" does not require that all aspects of the disclosure include the discussed feature, advantage or mode of operation. The term "coupled" is used herein to refer to either direct coupling or indirect coupling between two objects. For example, if object a physically contacts object B and object B contacts object C, then objects a and C may still be considered coupled to each other even though they are not in direct physical contact with each other. For example, a first object may be coupled to a second object even though the first object is never directly in physical contact with the second object. The terms "circuitry" and "electronic circuitry" are used broadly and are intended to encompass both hardware implementations of electronic devices and conductors, wherein, when such electronic devices and conductors are connected and configured, the implementations of the functions described in this disclosure are accomplished without being limiting as to the type of electronic circuitry), and software implementations of information and instructions that, when executed by a processor, accomplish the implementations of the functions described in this disclosure.

One or more of the components, steps, features and/or functions illustrated in fig. 1-14 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. The apparatus, devices, and/or components illustrated in fig. 1-14 may be configured to perform one or more of the methods, features, or steps described herein. The novel algorithms described herein may also be implemented efficiently in software and/or embedded in hardware.

It should be understood that the specific order or hierarchy of steps in the methods disclosed herein is just one illustration of exemplary processing. It should be appreciated that the particular order or hierarchy of steps in the methods may be rearranged based on design preferences. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented, unless expressly recited therein.

Other aspects, features and embodiments of the present invention will become apparent to those ordinarily skilled in the art upon review of the foregoing description of specific, exemplary embodiments of the invention in conjunction with the accompanying figures. Although features of the invention are discussed with respect to certain embodiments and figures 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 in accordance with the various embodiments of the invention discussed herein. In a similar manner, while exemplary embodiments may be discussed as device, system, or method embodiments, it should be understood that these exemplary embodiments may be implemented with a variety of devices, systems, and methods.

Claims (24)

1. A method of wireless communication, the method comprising:

establishing a non-Internet Protocol (IP) based Protocol Data Unit (PDU) session;

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, the data packets include IP data and are formatted in an ethernet format, and

wherein the selection of the packet filter is based on content included in an ethernet frame header of the data packet, and the selection further comprises:

evaluating content included in an 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 matched packet filter; and

the transmission of the data packets is filtered according to the packet filter.

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

3. The method of claim 1, wherein the selecting further comprises: when reflected QoS is enabled, evaluating a downlink data packet received from the network, and wherein the evaluating further comprises: it is determined whether the content of the downlink data packet matches a corresponding packet filter in a User Equipment (UE).

4. A method according to claim 3, wherein the selecting further comprises: 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 an existing packet filter at the UE when its content matches the content of the downlink data packet.

5. The method of claim 4, further comprising: one of the new packet filter or the existing packet filter is time stamped.

6. The method of claim 5, further comprising: the packet filter is deleted based on the corresponding timestamp.

7. A wireless communication device, comprising:

a processor;

a memory communicatively coupled to the processor;

A transceiver communicatively coupled to the processor;

a communication circuit communicatively coupled to the processor, wherein the communication circuit is configured to: establishing a non-Internet Protocol (IP) based Protocol Data Unit (PDU) session;

a selection circuit communicatively coupled to the processor, wherein the selection circuit is configured to: 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, the data packets include IP data and are formatted in an ethernet format, and

wherein the selection circuit comprises an ethernet type sub-circuit configured to: the packet filter is selected based on content included in an ethernet frame header of the data packet, and the ethernet type subcircuit is further configured to: evaluating content included in an 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 matched packet filter; and

A filtering circuit communicatively coupled to the processor, wherein the filtering circuit is configured to: the transmission of the data packets is filtered according to the packet filter.

8. The wireless communication device of claim 7, wherein the ethernet type subcircuit is further configured to: the packet filter is selected based on content included in an IP header of the data packet.

9. The wireless communication device of claim 7, wherein the selection circuit comprises a reflective sub-circuit configured to: when reflected QoS is enabled, evaluating a downlink data packet received from the network, and wherein the reflected sub-circuit is configured to: it is determined whether the content of the downlink data packet matches a corresponding packet filter in a User Equipment (UE).

10. The wireless communication device of claim 9, wherein the reflective sub-circuit is further configured to: 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 an existing packet filter at the UE when its content matches the content of the downlink data packet.

11. The wireless communication device of claim 10, wherein the reflective sub-circuit is further configured to: one of the new packet filter or the existing packet filter is time stamped.

12. The wireless communication device of claim 11, wherein the reflective sub-circuit is further configured to: the packet filter is deleted based on the corresponding timestamp.

13. An apparatus for wireless communication, comprising:

a unit for establishing a non-Internet Protocol (IP) based Protocol Data Unit (PDU) session;

means 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, the data packets include IP data and are formatted in an ethernet format, and

wherein the means for selecting is configured to select the packet filter based on content included in an ethernet frame header of the data packet, and the means for selecting further comprises: means for evaluating content included in an 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 matched packet filter; and

And means for filtering the transmission of the data packets according to the packet filter.

14. The apparatus of claim 13, wherein the means for selecting is further configured to select the packet filter based on content included in an IP header of the data packet.

15. The apparatus of claim 13, wherein the means for selecting is configured to: when reflected QoS is enabled, evaluating a downlink data packet received from the network, and wherein the evaluating further comprises: it is determined whether the content of the downlink data packet matches a corresponding packet filter in a User Equipment (UE).

16. The apparatus of claim 15, wherein the means for selecting is configured to: 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 an existing packet filter at the UE when its content matches the content of the downlink data packet.

17. The apparatus of claim 16, further comprising means for time stamping one of the new packet filter or the existing packet filter.

18. The apparatus of claim 17, further comprising means for deleting a packet filter based on a corresponding timestamp.

19. A non-transitory computer-readable medium storing computer-executable code, comprising code for causing a computer to:

establishing a non-Internet Protocol (IP) based Protocol Data Unit (PDU) session;

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, the data packets include IP data and are formatted in an ethernet format, and

wherein the selection of the packet filter is based on content included in an ethernet frame header of the data packet, and the selection further comprises:

evaluating content included in an 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 matched packet filter; and

the transmission of the data packets is filtered according to the packet filter.

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

21. The non-transitory computer-readable medium of claim 19, further comprising:

reflected instructions for causing the computer to: when reflected QoS is enabled, evaluating a downlink data packet received from a network, wherein the reflected instructions cause the computer to: it is determined whether the content of the downlink data packet matches a corresponding packet filter in a User Equipment (UE).

22. The non-transitory computer-readable medium of claim 21, wherein the reflected instructions further cause the computer to: 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 an existing packet filter at the UE when its content 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: one of the new packet filter or the existing packet filter is time stamped.

24. The non-transitory computer-readable medium of claim 23, further comprising code for causing the computer to: the packet filter is deleted based on the corresponding timestamp.

Images