Patent Description:
Embodiments herein generally relate to communications between devices in broadband wireless communications networks.

Mobile communication has evolved significantly from early voice systems to today's highly sophisticated integrated communication platform. The next generation wireless communication system, <NUM>, or new radio (NR) will provide access to information and sharing of data anywhere, anytime by various users and applications. NR is expected to be a unified network/system that targets to meet vastly different and sometimes conflicting performance dimensions and services. As the number and type of content communicated over wireless channels increases, the difficulty in handling the associated data and prioritizing the communication also increases.

<NPL> addresses a problem observed during performance testing for conversational video over LTE.

<NPL> discusses issue <NUM> by providing an impact analysis of issue <NUM> and addressing potential solutions.

<CIT> discloses a method executed by a base station comprising the steps of: transmitting an uplink grant to a first terminal; transmitting a fast uplink grant related to emergency message transmission to at least one of the first terminal or a second terminal; and receiving the emergency message from the second terminal through a uplink resource assigned by the fast uplink grant, wherein the uplink resource assigned by the fast uplink grant is a resource in which a resource assigned to the first terminal by the uplink grant is withdrawn.

<NPL>reviews and analyzes the potential UL scheduling in both LTE and NR.

Examples or embodiments that do not fall within the scope of the appended claims, are non-claimed embodiments and are presented only as information.

A user equipment (UE) communicates with a node (or nodes) in a radio access network (RAN) cell. The present disclosure provides that the UE can notify the node when uplink (UL) critical data is stored within a given data radio bearer (DRB) to alert the node that this UE may benefit from different scheduling or handling. For example, the UE may benefit from having more and/or larger grants, from having additional protection for the UL grant (e.g. lower modulation coding scheme (MCS), additional redundancy, different maximum number of retransmission or increase the number of repetitions required when operating in coverage enhancement (CE) mode), or the like.

In general, the present disclosure provides a UE that is aware of the uplink (UL) critical data within the DRB of a user. For example, the UE access stratum (AS) can be aware of the UL critical data with the DRB. The UE can provide different handling and/or prioritization of the UL critical data within DRB.

The present disclosure further provides a RAN cell node that is aware of UL critical data within DRB of the user to prioritize scheduling and/or handling of the data within the DRB of the user. As such, degradation of the communication (e.g., conversational video, or the like) of the UE can be minimized.

Various embodiments may comprise one or more elements. An element may comprise any structure arranged to perform certain operations. Each element may be implemented as hardware, software, or any combination thereof, as desired for a given set of design parameters or performance constraints. Although an embodiment may be described with a limited number of elements in a certain topology by way of example, the embodiment may include more or less elements in alternate topologies as desired for a given implementation. It is worthy to note that any reference to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrases "in one embodiment," "in some embodiments," and "in various embodiments" in various places in the specification are not necessarily all referring to the same embodiment.

The techniques disclosed herein may involve transmission of data over one or more wireless connections using one or more wireless mobile broadband technologies. For example, various embodiments may involve transmissions over one or more wireless connections according to one or more 3rd Generation Partnership Project (3GPP), 3GPP Long Term Evolution (LTE), 3GPP LTE-Advanced (LTE-A), 3GPP LTE-Advanced Pro, and/or 3GPP fifth generation (<NUM>)/new radio (NR) technologies and/or standards, including their revisions, progeny and variants. Various embodiments may additionally or alternatively involve transmissions according to one or more Global System for Mobile Communications (GSM)/Enhanced Data Rates for GSM Evolution (EDGE), Universal Mobile Telecommunications System (UMTS)/High Speed Packet Access (HSPA), and/or GSM with General Packet Radio Service (GPRS) system (GSM/GPRS) technologies and/or standards, including their revisions, progeny and variants.

Examples of wireless mobile broadband technologies and/or standards may also include, without limitation, any of the Institute of Electrical and Electronics Engineers (IEEE) <NUM> wireless broadband standards such as IEEE <NUM> and/or <NUM>. 16p, International Mobile Telecommunications Advanced (IMT-ADV), Worldwide Interoperability for Microwave Access (WiMAX) and/or WiMAX II, Code Division Multiple Access (CDMA) <NUM> (e.g., CDMA2000 1xRTT, CDMA2000 EV-DO, CDMA EV-DV, and so forth), High Performance Radio Metropolitan Area Network (HIPERMAN), Wireless Broadband (WiBro), High Speed Downlink Packet Access (HSDPA), High Speed Orthogonal Frequency-Division Multiplexing (OFDM) Packet Access (HSOPA), High-Speed Uplink Packet Access (HSUPA) technologies and/or standards, including their revisions, progeny and variants.

Some embodiments may additionally or alternatively involve wireless communications according to other wireless communications technologies and/or standards. Examples of other wireless communications technologies and/or standards that may be used in various embodiments may include, without limitation, other IEEE wireless communication standards such as the IEEE <NUM>, IEEE <NUM>. 11a, IEEE <NUM>. 11b, IEEE <NUM>, IEEE <NUM>. 11n, IEEE <NUM>. 11u, IEEE <NUM>. 11ac, IEEE <NUM>. 11ad, IEEE <NUM>. 11af, IEEE <NUM>. 11ah, IEEE <NUM>. 11ax, IEEE <NUM>. 11ay, and/or IEEE <NUM>. 11y standards, High-Efficiency Wi-Fi standards developed by the IEEE <NUM> High Efficiency WLAN (HEW) Study Group, Wi-Fi Alliance (WFA) wireless communication standards such as Wi-Fi, Wi-Fi Direct, Wi-Fi Direct Services, Wireless Gigabit (WiGig), WiGig Display Extension (WDE), WiGig Bus Extension (WBE), WiGig Serial Extension (WSE) standards and/or standards developed by the WFA Neighbor Awareness Networking (NAN) Task Group, machine-type communications (MTC) standards, and/or near-field communication (NFC) standards such as standards developed by the NFC Forum, including any revisions, progeny, and/or variants of any of the above. The embodiments are not limited to these examples.

<FIG> and <FIG> illustrate examples of operating environments <NUM> and <NUM>, respectively. Operating environments <NUM> and <NUM> may be representative of various embodiments. In <FIG>, operating environment <NUM> depicts an evolved node B (eNB) <NUM> that serves an LTE (LTE) radio access network (RAN) cell <NUM>. LTE-RAN cell <NUM> may generally be representative of a radio access network cell within which wireless communications are performed in accordance with 3rd Generation Partnership Project (3GPP) Long-Term Evolution (LTE) radio interface protocols.

In <FIG>, operating environment <NUM> depicts a next generation node B (gNB) <NUM>, which serves a next generation RAN (NG-RAN) cell <NUM>. NG-RAN cell <NUM> may generally be representative of a radio access network cell within which wireless communications are performed in accordance with 3rd Generation Partnership Project (3GPP) fifth generation (<NUM>) new radio (NR) radio interface protocols. In some examples, the NG-RAN cell <NUM> may be a small cell within the LTE-RAN cell <NUM>. Examples are not limited in this context.

Operating environments <NUM> and <NUM> each depict user equipment (UE) <NUM> located within LTE-RAN cell <NUM> and NG-RAN cell <NUM>, respectively. In either of operating environments <NUM> or <NUM>, UE <NUM> may wirelessly communicate with eNB <NUM> or gNB <NUM> according to such protocols in conjunction with establishing and utilizing wireless data connectivity via either eNB <NUM> or gNB <NUM>. Wireless communication between UE <NUM> and eNB <NUM> or gNB <NUM> can be established via an RRC framework.

During operation, UE <NUM> can determine whether critical data exists and provide different handling and/or prioritization for the determined critical data. Furthermore, the UE <NUM> can alert the eNB <NUM> or gNB <NUM> of the determined critical data. The eNB <NUM> or gNB <NUM> can prioritize scheduling and/or handling of the critical data. Thus, degradation of UE <NUM> communication can be minimized.

The disclosure now turns to providing a number of examples of information that can be carried, provided, or otherwise made available for UE <NUM> to indicate critical data. Such indications can be provided to the network (e.g., to eNB <NUM>, to gNB <NUM>, or the like) or utilized by UE <NUM>. These indications can be used to enhance the handling of the critical data (e.g., change handling and/or scheduling, or the like) to minimize or reduce degradation of communication associated with the critical data. It is important to highlight that there are multiple reason why data may be categorized as critical. For example, some packets within video over LTE (ViLTE) traffic can be designated as critical. As another example, some packets within voice over LTE (VoLTE) traffic can be designated as critical, such as, packets carrying uncompressed headers for robust header compression (ROHC) data. As a further example, signaling message sent by upper layers can be designated as critical.

It is important to note, that the information used to indicate critical data can be provided using a number of different mechanisms. Such mechanisms can depend upon where the data originates. As another example, such mechanisms can depend upon which entity within the UE (e.g., MAC layer, PDCP layer, RLC layer, SDAP layer, or the like) is providing the information. Example of such mechanisms are provided below, following the examples of illustrative information that can be categorized as critical.

As noted, critical data can be determined based on a number of factors. Examples of information that can be provided to allow UE <NUM>, eNB <NUM>, or gNB <NUM> to determine whether data is critical are provided here.

As a first example, provided information could indicate that a critical packet data convergence protocol (PDCP) service data unit (SDU) is present in the PDCP buffer queue, that critical data is in the buffer, or that this packet included critical data. With some examples, this information can be indicated with <NUM> bit (e.g., <NUM> - no critical data, <NUM> - critical data, or the like).

As a second example, provided information could indicate that under the latest UL grant allocation and periodicity, critical PDCP SDUs will be discarded before being transmitted, or that critical data stored in a buffer of UE <NUM> would be discarded before being transmitted. With some examples, this information can be indicated with <NUM> bit (e.g., <NUM> - critical data not discarded, <NUM> - critical data discarded, or the like).

As a third example, provided information could indicate that a non-critical PDCP SDU preceding the <NUM>st critical PDCP SDU has been flushed, or that non-critical data preceding the <NUM>st critical data has been flushed or discarded. With some examples, this information can be indicated with <NUM> bit (e.g., <NUM> - non-critical data prior to critical data discarded, <NUM> - non-critical data prior to critical data not discarded, or the like). In some examples, this information can be indicated with n >= <NUM> bits, where the indication can include the size of the non-critical data preceding the <NUM>st critical PDCP SDU that has been flushed.

As a fourth example, provided information could indicate that critical PDCP SDUs are not present in the PDCP buffer queue, or that critical data is not in the buffer, or that this packet is not critical. With some examples, this information can be indicated with <NUM> bit (e.g., <NUM> - critical data not present, <NUM> - critical data present, or the like).

As a fifth example, provided information could indicate the characteristics of the data stored in the buffer, or characteristics of every packet associated with the corresponding information. With some embodiments, this information can be indicated with <NUM> bits. For example:.

As a sixth example, provided information could indicate a logical channel ID (LCID) of the video bearer, another bearer, or a flow that may be carrying critical data. Note that it is possible that all data sent is critical, as well as, that only some of the data sent may be critical data. With some embodiments, this information can be indicated with <NUM> bits, or with n >= <NUM> bit.

As a seventh example, provided information could indicate the size of the buffer of the number of critical packets, which could have only the critical data, or could include both critical and non-critical data. The value indicating the size of the buffer could represent the actual size, or a range (e.g. the size of the buffer is below "X" and above "Y", similar to the ranges defined for the buffer status report (BSR) in 3GPP technical specification <NUM>). With some embodiments, this information can be indicated with <NUM> bits, or with n >= <NUM> bit.

As an eighth example, provided information could indicate a logical channel group (LCG) ID that carries the critical data or that carries any data (including both critical and non-critical data). With some embodiments, this information can be indicated n >= <NUM> bit.

As a ninth example, provided information could indicate a certain categorization of the data (e.g., type of service where data has a categorization with a value between <NUM> and n), which could help to enable prioritization schemes. With some embodiments, this information can be indicated n >= <NUM> bit.

As a tenth example, provided information could indicate that the current data or packet is the last critical data stored in the buffer. With some embodiments, this information can be indicated n >= <NUM> bit.

As an eleventh example, provided information could indicate a request of an expected change on the network side or a request indicating what is expected to change due to the critical data. Such requests may correspond to getting different scheduling handling (e.g., having more and/or larger grants, or the like), having additional protection for the UL grant (e.g., lower the modulation coding scheme (MCS), additional redundancy, different maximum number of retransmission, increase the number of repetitions required when operating in coverage enhancement (CE) mode). With some embodiments, this information can be indicated with <NUM> bits. For example:.

As a twelfth example, provided information could indicate the absence of critical data. Such an indication could be used by the network (e.g., eNB <NUM>, gNB <NUM>, or the like) to revert back to a normal confirmation (e.g. increasing MCS, reducing redundancy, or the like). With some embodiments, this information can be indicated n >= <NUM> bit.

It is important to note, that any scheme for providing information can include indications that can be reserved for future usage. Furthermore, as noted above, the example information that can be provided may be included in any of a number or mechanisms, such as, for example, those described below. Furthermore, the information from the above examples, can be sent individually (e.g., in their own respective containers) or in any combination within the same container. In some examples, information from ones of the above examples can be designated as mandatory while information from other ones of the above examples can be designated as optional. Also, of note, the above examples are not intended to be an exhaustive list of all information that can be provided to indicate critical data but are instead provided for purposes of clarity and understanding.

As noted, some of the information from the examples listed above may be combined to provide multiple indications at once. For example, the first and second example could be combined with the information from the eleventh example as depicted in Table <NUM> shown below.

The disclosure now turns to describing various mechanisms for providing information indicating critical data. Such mechanisms are described with respect to various layers of the control plane protocol stack. Said differently, various layers of the control plane protocol stack (e.g., the media access control (MAC) layer, the PDCP layer, the radio link control (RLC) layer, the service data adaptation protocol (SDAP) layer, or the like) can communicate (e.g., send or receive) information indicating critical data. As another example, various packets or portions of packets (e.g., headers, or the like) can be augmented to provide informing indicating critical data.

It is noted, the various mechanisms or solutions described herein to communicate information indicating critical data can be used to convey information like any of the examples (e.g., example <NUM> to example <NUM>) discussed above, or any combination of the above examples. However, for purposes of brevity, only a few of the above described examples are referenced below when discussing the mechanisms to communicate the information. This is not intended to be limiting. Furthermore, it is to be appreciated the present disclosure can be applied to communicating information indicating critical data for both the upload or download of data. Also, it is noted that although the examples herein discuss information conveyed between the UE (e.g., UE <NUM>) and a node (e.g., eNB <NUM>, gNB <NUM>, or the like), the information conveyed can be used by the RAN (e.g., LTE-RAN <NUM>, NG-RAN <NUM>, or the like) or even core network (CN) nodes to optimize scheduling, prioritization, decisions on discarding, routing, etc. for traffic within the CN.

With some examples, the UE (e.g., UE <NUM>) can notify the node (e.g., eNB <NUM>, gNB <NUM>, or the like) using a MAC sub-header, using an extension of the buffer status report (BSR), using data volume indication, or using an existing or new MAC control element. Using such mechanisms or "containers," UE <NUM> can notify eNB <NUM> of the size of the key frame to assist eNB <NUM> in allocating the appropriate resource. As another example, UE <NUM> can set a flag to indicate whether the next grant should be provided with additional robustness. As a further example, the flag can be maintained while key frames are still buffered.

<FIG> illustrates a MAC sub-header <NUM> that may be representative of an implementation of a MAC sub-header that can include information regarding critical data as discussed herein. As shown, the MAC sub-header <NUM> includes one or more reserved bits <NUM> (e.g., two reserved bit fields, or two reserved bits, are depicted in this figure). Mac-sub-header further includes an extension field <NUM>, which defined one or more fields included in the MAC header; a logical channel ID (LCID) field <NUM> that defines the identity of the logical channel, type of MAC control element or padding; a length field <NUM> that defines the size of the MAC SDU; and an optical format bit <NUM> that defines the size of the length field.

In some examples, one or more of the reserved bits of a MAC sub-header (e.g., MAC protocol data unit (PDU) sub-header, MAC service data unit (SDU) sub-header, or the like) can be used, or defined, to indicate critical data. For example, reserved bits <NUM> could be defined to correspond to critical data fields <NUM>-<NUM> and <NUM>-<NUM> of MAC sub-header <NUM>, which may indicate information based on any one or example <NUM> to example <NUM> discussed above, or any combination of example <NUM> to example <NUM> discussed above. It is noted, that sub-header <NUM> could include any number of reserved bits. Furthermore, any one or more of these reserved bits could be defined to indicate critical data. For example, a single one of the two reserved bits depicted could be defined to indicate critical data.

With some examples, a new value for the LCID field <NUM> of the MAC sub-header <NUM> could be defined to convey critical data, such as, on a per channel group basis. For example, many definitions for the LCID values include reserved values. One or more of these reserved values could be defined to convey information indicating critical data as discussed above.

<FIG> illustrates an extended buffer status report (BSR) <NUM> that may be representative of implementations of a BSR that can include information regarding critical data as discussed herein. As shown, the BSR <NUM> includes conventional BSR fields <NUM> and an extended BSR field <NUM>. The conventional BSR fields <NUM> could include any number of fields corresponding to a BSR (e.g., a truncated BSR, a long BSR, or the like). For example, in the case of a truncated BSR, conventional fields <NUM> could include a logical channel group (LCG) ID field <NUM> indicating the buffer for which status is being reported and the buffer size field <NUM> indicating the size of the buffer.

The extended BSR field <NUM> could be any number of bits long. In some examples extended BSR field <NUM> could be an octet (<NUM> bits), multiple octets, or the like. Extended BSR field <NUM> could convey information indicating critical data, for example, as discussed with respect to example <NUM> to example <NUM> above. As a specific example, the extended BSR field <NUM> could be used to indicate the size of the critical data (e.g., as discussed in example <NUM> above, or the like). Additionally, or alternatively information from example <NUM> to example <NUM> or example <NUM> to example <NUM> could be indicated by the additional bits in the extended BSR. With some embodiments, the size of the extended BSR <NUM> could depend upon whether the BSR <NUM> is a truncated BSR or a long BSR. For example, a truncated BSR <NUM> could be <NUM> octets long while a long BSR <NUM> could be <NUM> octets long.

In some embodiments, the reserved bit (e.g., reserved bit <NUM>-<NUM>, reserved bit <NUM>-<NUM>, or the like) in the MAC sub-header (e.g., MAC sub-header <NUM>, or the like) could indicate that the extended BSR <NUM> is used as opposed to a conventional BSR (e.g., one without extended BSR field <NUM>, or the like).

It is noted, that with some examples, an extended BSR, such as the extended BSR <NUM> could be implemented to report only the amount of critical data. For example, the extended BSR could include fields extended BSR field <NUM> only.

<FIG> illustrates a combined data volume and power headroom report (DPR) MAC control element <NUM> that may be representative of implementations of a DPR MAC control element that can include information regarding critical data as discussed herein. As shown, the DPR MAC control element <NUM> includes critical data bits <NUM>-<NUM> and <NUM>-<NUM>, a power headroom field <NUM>, and a data volume field <NUM>. The power headroom field <NUM> and data volume field <NUM> could be used to report data volumes and power used, respectively, relative to available data volumes and available power for the UE. The critical data bits <NUM>-<NUM> and <NUM>-<NUM> could be used to convey information (e.g., such as example <NUM> to example <NUM>) indicating critical data.

<FIG> illustrates a format for a MAC sub-header <NUM> that may be representative of implementations of a MAC sub-header that can include information regarding critical data as discussed herein. As shown, the MAC sub-header <NUM> includes critical data fields <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> as well as an LCID field <NUM>. It is noted that a MAC sub-header like MAC sub-header <NUM> could be formatted to include more or less critical data fields <NUM> than depicted in this figure. For example, a MAC sub-header could be provided with <NUM> critical data fields <NUM>, <NUM> critical data fields <NUM>, <NUM> critical data fields <NUM>, etc. The LCID field <NUM> could define the logical channel for which the critical data is associated. In some examples, the LCID field <NUM> could include values and associated definitions as provided in Table <NUM> shown below.

With some examples, the MAC sub-header <NUM> may not have any associated MAC PDUs.

<FIG> illustrates a format for a MAC control element <NUM> that may be representative of implementations of a MAC control element that can include information regarding critical data as discussed herein. In some embodiments, the MAC control element <NUM> can be associated with the LCID <NUM> from MAC sub-header <NUM>, and particularly the LCID field <NUM> values described with reference to Table <NUM>. As shown, the MAC control element <NUM> includes critical data fields <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> as well as an LCID field <NUM>. It is noted that the information indicating critical data (e.g. example one, example <NUM>, example, three, etc.) can be provided per logical channel, the MAC control element <NUM> might be larger than <NUM> octet. For example, the MAC control element <NUM> could provide information for any combination of the examples given above, which might necessitate the size of the MAC control element to be greater than one octet. As another example, the MAC control element <NUM> could provide informatio0n for more than one logical channel. As such, MAC control element <NUM> might include more fields than depicted in <FIG>, such as, for example, fields to indicate the size or one (or more) extension bit(s) may indicate the extension of additional fields, or one header bitmaps may be defined to indicate how many logical channels are reported.

<FIG> illustrates a format for a MAC control element <NUM> that may be representative of implementations of a MAC control element that can include information regarding critical data as discussed herein. In some embodiments, the MAC control element <NUM> can be associated with the LCID <NUM> from MAC sub-header <NUM>, and particularly the LCID field <NUM> values described with reference to Table <NUM>. As shown, the MAC control element <NUM> includes critical data fields <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> as well as one or more reserved bits <NUM>.

With some embodiments, a MAC control element could be defined to provide an indication of the buffer size in addition to one or more indications of critical data, such as, for example, indications of critical data like the seventh example given above. With some examples, the MAC control element can have a similar structure to MAC control elements conveying BSR information. With some examples, the MAC control element could be specified with a defined size. In other examples, the MAC control element could have a variable size. Furthermore, the MAC control element could convey indications of critical data information corresponding to any one or more combinations of the examples given above, not limited to the seventh example.

<FIG> illustrates a format for a MAC control element <NUM> that may be representative of implementations of a MAC control element that can include information regarding critical data as discussed herein. As shown, the MAC control element <NUM> includes an LCG ID field <NUM> indicating the buffer for which status is being reported as well as a buffer size field <NUM>. Additionally, MAC control element <NUM> includes critical data fields <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> as well as one or more reserved bits <NUM>.

<FIG> illustrates a format for a MAC control element <NUM> that may be representative of implementations of a MAC control element that can include information regarding critical data as discussed herein. As shown, the MAC control element <NUM> includes a number of buffer size fields <NUM> as well as critical data fields <NUM>. With one or more critical data fields <NUM> corresponding to each buffer specified in the buffer size fields <NUM>. For example, MAC control element <NUM> depicts buffer size fields <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM>. Furthermore, two critical data fields <NUM> are defined for each of the buffers corresponding to buffer size fields <NUM>-<NUM> to <NUM>-<NUM>. For example, critical data fields <NUM>-<NUM> and <NUM>-<NUM> indicate critical data information for the buffer corresponding to buffer size field <NUM>-<NUM>, critical data fields <NUM>-<NUM> and <NUM>-<NUM> indicate critical data information for the buffer corresponding to buffer size field <NUM>-<NUM>, critical data fields <NUM>-<NUM> and <NUM>-<NUM> indicate critical data information for the buffer corresponding to buffer size field <NUM>-<NUM>, and critical data fields <NUM>-<NUM> and <NUM>-<NUM> indicate critical data information for the buffer corresponding to buffer size field <NUM>-<NUM>.

<FIG> illustrates a format for a PDCP header and data PDU <NUM> that may be representative of implementations of a PDCP header that can include information regarding critical data as discussed herein. As shown, the PDCP header and data PDU <NUM> includes a data/control (D/C) bit <NUM> indicative of whether the packet carrier data or control information. Additionally, the PDCP header and data PDU <NUM> includes a PDCP sequence number (SN) field <NUM> indicative of an order of the packet relative to other packets. Additionally, the PDCP header and data PDU <NUM> includes a number of reserved bits <NUM>, one of which has been defined to indicate critical data. For example, reserved bit <NUM> are depicted as well as critical data field <NUM>. Thus, leaving reserved bits <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM> available for future use.

PDCP header and data PDU <NUM> is further depicted including a data field <NUM> as well as MAC information fields <NUM>.

With some examples, the PDCP header and data PDU <NUM> can also be used in the sender UE (e.g., UE <NUM>) to notify lower layers of the presence of critical data. The lower layers can then prioritize resources to better service (or protect) this packet and potentially notify the network.

With some embodiments, any combination of the information described above (e.g., the examples given above) can be included in the reserved bits <NUM>. For example, any number of the reserved bits <NUM> in the PDCP header could be used to convey the size of the critical data that is still stored in the buffer. Another example, any number of the reserved bits <NUM> could be used to convey the type of service or priority associated with the data.

<FIG> illustrates a format for an RLC header <NUM>, which may correspond to a UMD PDU, an AMD PDU, or the like and can include information regarding critical data as discussed herein. As shown, the RLC header <NUM> includes a number of reserved bits <NUM>, which have been defined to indicate critical data. For example, reserved bit <NUM> are depicted as critical data fields <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM>. It is noted, that with some embodiments, not all reserved bits <NUM> need be defined to indicate critical data. The RLC header further incudes a framing information bit <NUM>, which indicates whether the associated RLC SDU is segmented or not; an extension field <NUM> that indicates whether data or a set of extension fields and LI fields follows; and an SN field <NUM> indicative of an order of the packet relative to other packets.

With some embodiments, any combination of the information described above (e.g., the examples given above) can be included in the critical data fields <NUM>-<NUM> to <NUM>-<NUM>.

<FIG> illustrates a format for an SDAP header <NUM>, which may correspond to an SDAP PDU, or the like and can include information regarding critical data as discussed herein. As shown, the SDAP header <NUM> includes a number of critical data fields <NUM>-<NUM> and <NUM>-<NUM>. With some embodiments, any combination of the information described above (e.g., the examples given above) can be included in the critical data fields <NUM>-<NUM> and <NUM>-<NUM>.

In some examples, SDAP header <NUM> can include a single (<NUM> bit) critical data field <NUM>, which can be used to convey the presence of critical data. On sender side, this information can be used to inform lower layer(s) (PDCP, etc.) of the presence of critical data in order for lower layer(s) to prioritize or better protect this packet and potentially notify the network. On the receiver side this information can be used to notify upper layer(s) (e.g., RLC, MAC, etc.) of the presence of critical data. The upper layer(s) can then prioritize the processing if this packet.

<FIG> and <FIG> illustrate examples of logic flows that may be representative of notifying entities of critical data. For example, <FIG> depicts a logic flow <NUM> that may be representative of a UE notifying a node of critical data while <FIG> depicts a method <NUM> that may be representative of a node receiving notification of critical data from a UE.

Turning to <FIG>, logic flow <NUM> may begin at block <NUM> "identify critical data" where a UE can identify critical data in a packet or buffer to be transmitted to a node. For example, UE <NUM> can identify critical data to be transmitted to either eNB <NUM> or gNB <NUM>. Continuing to decision block <NUM> "critical data identified" a determination can be as to whether critical data is identified. For example, UE <NUM> can determine whether critical data was identified as block <NUM>. Based on the determination as decision block <NUM>, logic flow <NUM> can continue to either block <NUM> or block <NUM>. Specifically, logic flow <NUM> can continue from decision block <NUM> to block <NUM> based on a determination that critical data was identified while logic flow <NUM> can continue from decision block <NUM> to block <NUM> based on a determination that critical data was not identified.

At block <NUM> "format a container to include an indication of critical data" a UE can format a container to include an indication of critical data. For example, UE <NUM> can format a container (e.g., header, sub-header, PDU, or the like) to include an indication of critical data. Various specific examples of indications of critical data and mechanisms for formatting a container to include an indication of the critical data are provided above. Continuing to block <NUM> "send the container to a node to notify the node of the identified critical data" the UE can send the formatted container to a node to notify the node of the identified critical data. For example, UE <NUM> can send the container (e.g., header, sub-header, PDU, or the like) to eNB <NUM>, gNB <NUM>, or the like to notify the node of the identified critical data.

Continuing to block <NUM> "update operating parameter(s) to prioritize handling of the critical data" the UE can update operating parameters to prioritize the handling of the critical data. For example, UE <NUM> can update one or more operating parameters (e.g., lower the MCS, change redundancy, change the maximum number of retransmission, increase the number of repetitions required when operating in CE mode, etc.).

At block <NUM> "return operating parameter(s) to normal" the UE can return operating parameters to normal (if needed) based on a determination that no critical data is identified. For example, UE <NUM> can return operating parameter(s) that may have been modified at block <NUM> (e.g., during a prior iteration of logic flow <NUM>, or the like) to normal.

Turning to <FIG>, logic flow <NUM> may begin at block <NUM> "receive a container from a UE" where a node can receive a container from a UE. For example, eNB <NUM>, gNB <NUM>, or the like can receive a container (e.g., header, sub-header, PDU, or the like) from UE <NUM>. Continuing to decision block <NUM> "does the container indicate critical data" a determination can be made as to whether the container includes an indication of critical data. For example, the node can determine whether the container includes an indication (e.g., as detailed above) of critical data. Based on the determination as decision block <NUM>, logic flow <NUM> can continue to either block <NUM> or block <NUM>. Specifically, logic flow <NUM> can continue from decision block <NUM> to block <NUM> based on a determination that container indicates critical data while logic flow <NUM> can continue from decision block <NUM> to block <NUM> based on a determination that the container does not indicate critical data.

At block <NUM> "update operating parameter(s) to prioritize handling of the critical data" the node can update operating parameters to prioritize the handling of the critical data. For example, eNB <NUM>, gNB <NUM>, or the like can update one or more operating parameters (e.g., lower the MCS, change redundancy, change the maximum number of retransmission, increase the number of repetitions required when operating in CE mode, etc.).

At block <NUM> "return operating parameter(s) to normal" the node can return operating parameters to normal (if needed) based on a determination that the container does not indicate critical data. For example, eNB <NUM>, gNB <NUM>, or the like can return operating parameter(s) that may have been modified at block <NUM> (e.g., during a prior iteration of logic flow <NUM>, or the like) to normal.

<FIG> illustrates an embodiment of a storage medium <NUM>. Storage medium <NUM> may comprise any non-transitory computer-readable storage medium or machine-readable storage medium, such as an optical, magnetic or semiconductor storage medium. In various embodiments, storage medium <NUM> may comprise an article of manufacture. In some embodiments, storage medium <NUM> may store computer-executable instructions, such as computer-executable instructions to implement one or more of logic flow <NUM> or logic flow <NUM>.

Examples of a computer-readable storage medium or machine-readable storage medium may include any tangible media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of computer-executable instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like.

<FIG> illustrates an architecture of a system <NUM> of a network in accordance with some embodiments. The system <NUM> is shown to include a user equipment (UE) <NUM> and a UE <NUM>. The UEs <NUM> and <NUM> are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks) but may also comprise any mobile or non-mobile computing device, such as Personal Data Assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device including a wireless communications interface.

In some embodiments, any of the UEs <NUM> and <NUM> can comprise an Internet of Things (IoT) UE, which can comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections. An IoT UE can utilize technologies such as machine-to-machine (M2M) or machine-type communications (MTC) for exchanging data with an MTC server or device via a public land mobile network (PLMN), Proximity-Based Service (ProSe) or device-to-device (D2D) communication, sensor networks, or IoT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An IoT network describes interconnecting IoT UEs, which may include uniquely identifiable embedded computing devices.

(within the Internet infrastructure), with short-lived connections. The IoT UEs may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connections of the IoT network.

The UEs <NUM> and <NUM> may be configured to connect, e.g., communicatively couple, with a radio access network (RAN) <NUM> - the RAN <NUM> may be, for example, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), a NextGen RAN (NG RAN), or some other type of RAN. The UEs <NUM> and <NUM> utilize connections <NUM> and <NUM>, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections <NUM> and <NUM> are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (<NUM>) protocol, a New Radio (NR) protocol, and the like.

Some embodiments may use concepts for resource allocation for control channel information that are an extension of the above-described concepts. For example, some embodiments may utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more enhanced the control channel elements (ECCEs). Similar to above, each ECCE may correspond to nine sets of four physical resource elements known as an enhanced resource element groups (EREGs). An ECCE may have other numbers of EREGs in some situations.

The RAN <NUM> is shown to be communicatively coupled to a core network (CN) <NUM> -via an S1 interface <NUM>. In embodiments, the CN <NUM> may be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, or some other type of CN. In this embodiment the S1 interface <NUM> is split into two parts: the S1-U interface <NUM>, which carries traffic data between the RAN nodes <NUM> and <NUM> and the serving gateway (S-GW) <NUM>, and the S1-mobility management entity (MME) interface <NUM>, which is a signaling interface between the RAN nodes <NUM> and <NUM> and MMEs <NUM>.

<FIG> illustrates example components of a device <NUM> in accordance with some embodiments. In some embodiments, the device <NUM> may include application circuitry <NUM>, baseband circuitry <NUM>, Radio Frequency (RF) circuitry <NUM>, front-end module (FEM) circuitry <NUM>, one or more antennas <NUM>, and power management circuitry (PMC) <NUM> coupled together at least as shown. The components of the illustrated device <NUM> may be included in a UE or a RAN node. In some embodiments, the device <NUM> may include less elements (e.g., a RAN node may not utilize application circuitry <NUM>, and instead include a processor/controller to process IP data received from an EPC). In some embodiments, the device <NUM> may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud-RAN (C-RAN) implementations).

The baseband circuitry <NUM> may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry <NUM> and to generate baseband signals for a transmit signal path of the RF circuitry <NUM>. Baseband processing circuity <NUM> may interface with the application circuitry <NUM> for generation and processing of the baseband signals and for controlling operations of the RF circuitry <NUM>. For example, in some embodiments, the baseband circuitry <NUM> may include a third generation (<NUM>) baseband processor 1704A, a fourth generation (<NUM>) baseband processor 1704B, a fifth generation (<NUM>) baseband processor 1704C, or other baseband processor(s) 1704D for other existing generations, generations in development or to be developed in the future (e.g., second generation (<NUM>), sixth generation (<NUM>), etc.). The baseband circuitry <NUM> (e.g., one or more of baseband processors 1704A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry <NUM>. In other embodiments, some or all of the functionality of baseband processors 1704A-D may be included in modules stored in the memory <NUM> and executed via a Central Processing Unit (CPU) 1704E. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry <NUM> may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry <NUM> may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

In some embodiments, the baseband circuitry <NUM> may include one or more audio digital signal processor(s) (DSP) 1704F. The audio DSP(s) 1704F may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry <NUM> and the application circuitry <NUM> may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, the receive signal path of the RF circuitry <NUM> may include mixer circuitry 1706a, amplifier circuitry 1706b and filter circuitry 1706c. In some embodiments, the transmit signal path of the RF circuitry <NUM> may include filter circuitry 1706c and mixer circuitry 1706a. RF circuitry <NUM> may also include synthesizer circuitry 1706d for synthesizing a frequency for use by the mixer circuitry 1706a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 1706a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry <NUM> based on the synthesized frequency provided by synthesizer circuitry 1706d. The amplifier circuitry 1706b may be configured to amplify the down-converted signals and the filter circuitry 1706c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry <NUM> for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 1706a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 1706a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 1706d to generate RF output signals for the FEM circuitry <NUM>. The baseband signals may be provided by the baseband circuitry <NUM> and may be filtered by filter circuitry 1706c.

In some embodiments, the mixer circuitry 1706a of the receive signal path and the mixer circuitry 1706a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 1706a of the receive signal path and the mixer circuitry 1706a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 1706a of the receive signal path and the mixer circuitry 1706a may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 1706a of the receive signal path and the mixer circuitry 1706a of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the synthesizer circuitry 1706d may be a fractional-N synthesizer or a fractional N/N+<NUM> synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 1706d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 1706d may be configured to synthesize an output frequency for use by the mixer circuitry 1706a of the RF circuitry <NUM> based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 1706d may be a fractional N/N+<NUM> synthesizer.

Synthesizer circuitry 1706d of the RF circuitry <NUM> may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+<NUM> (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 1706d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry <NUM> may include an IQ/polar converter.

This figure shows the PMC <NUM> coupled only with the baseband circuitry <NUM>. However, in other embodiments, the PMC <NUM> may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry <NUM>, RF circuitry <NUM>, or FEM <NUM>.

If there is no data traffic activity for an extended period of time, then the device <NUM> may transition off to an RRC_Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device <NUM> goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device <NUM> may not receive data in this state, in order to receive data, it must transition back to RRC_Connected state.

<FIG> illustrates example interfaces of baseband circuitry in accordance with some embodiments. As discussed above, the baseband circuitry <NUM> of <FIG> may comprise processors 1704A-1704E and a memory <NUM> utilized by said processors. Each of the processors 1704A-1704E may include a memory interface, 1804A-1804E, respectively, to send/receive data to/from the memory <NUM>.

<FIG> is an illustration of a control plane protocol stack in accordance with some embodiments. In this embodiment, a control plane <NUM> is shown as a communications protocol stack between the UE <NUM> (or alternatively, the UE <NUM>), the RAN node <NUM> (or alternatively, the RAN node <NUM>), and the MME <NUM>.

The PHY layer <NUM> may transmit or receive information used by the MAC layer <NUM> over one or more air interfaces. The PHY layer <NUM> may further perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers, such as the RRC layer <NUM>. The PHY layer <NUM> may still further perform error detection on the transport channels, forward error correction (FEC) coding/decoding of the transport channels, modulation/demodulation of physical channels, interleaving, rate matching, mapping onto physical channels, and Multiple Input Multiple Output (MIMO) antenna processing.

The MAC layer <NUM> may perform mapping between logical channels and transport channels, multiplexing of MAC service data units (SDUs) from one or more logical channels onto transport blocks (TB) to be delivered to PHY via transport channels, de-multiplexing MAC SDUs to one or more logical channels from transport blocks (TB) delivered from the PHY via transport channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction through hybrid automatic repeat request (HARQ), and logical channel prioritization.

The RLC layer <NUM> may operate in a plurality of modes of operation, including: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). The RLC layer <NUM> may execute transfer of upper layer protocol data units (PDUs), error correction through automatic repeat request (ARQ) for AM data transfers, and concatenation, segmentation and reassembly of RLC SDUs for UM and AM data transfers. The RLC layer <NUM> may also execute re-segmentation of RLC data PDUs for AM data transfers, reorder RLC data PDUs for UM and AM data transfers, detect duplicate data for UM and AM data transfers, discard RLC SDUs for UM and AM data transfers, detect protocol errors for AM data transfers, and perform RLC re-establishment.

The PDCP layer <NUM> may execute header compression and decompression of IP data, maintain PDCP Sequence Numbers (SNs), perform in-sequence delivery of upper layer PDUs at re-establishment of lower layers, eliminate duplicates of lower layer SDUs at re-establishment of lower layers for radio bearers mapped on RLC AM, cipher and decipher control plane data, perform integrity protection and integrity verification of control plane data, control timer-based discard of data, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification, etc.).

The main services and functions of the RRC layer <NUM> may include broadcast of system information (e.g., included in Master Information Blocks (MIBs) or System Information Blocks (SIBs) related to the non-access stratum (NAS)), broadcast of system information related to the access stratum (AS), paging, establishment, maintenance and release of an RRC connection between the UE and E-UTRAN (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishment, configuration, maintenance and release of point to point Radio Bearers, security functions including key management, inter radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting. Said MIBs and SIBs may comprise one or more information elements (IEs), which may each comprise individual data fields or data structures.

The UE <NUM> and the RAN node <NUM> may utilize a Uu interface (e.g., an LTE-Uu interface) to exchange control plane data via a protocol stack comprising the PHY layer <NUM>, the MAC layer <NUM>, the RLC layer <NUM>, the PDCP layer <NUM>, and the RRC layer <NUM>.

The non-access stratum (NAS) protocols <NUM> form the highest stratum of the control plane between the UE <NUM> and the MME <NUM>. The NAS protocols <NUM> support the mobility of the UE <NUM> and the session management procedures to establish and maintain IP connectivity between the UE <NUM> and the P-GW <NUM>.

The S1 Application Protocol (S1-AP) layer <NUM> may support the functions of the S1 interface and comprise Elementary Procedures (EPs). An EP is a unit of interaction between the RAN node <NUM> and the CN <NUM>. The S1-AP layer services may comprise two groups: UE-associated services and non UE-associated services. These services perform functions including, but not limited to: E-UTRAN Radio Access Bearer (E-RAB) management, UE capability indication, mobility, NAS signaling transport, RAN Information Management (RIM), and configuration transfer.

The Stream Control Transmission Protocol (SCTP) layer (alternatively referred to as the SCTP/IP layer) <NUM> may ensure reliable delivery of signaling messages between the RAN node <NUM> and the MME <NUM> based, in part, on the IP protocol, supported by the IP layer <NUM>. The L2 layer <NUM> and the L1 layer <NUM> may refer to communication links (e.g., wired or wireless) used by the RAN node and the MME to exchange information.

The RAN node <NUM> and the MME <NUM> may utilize an S1-MME interface to exchange control plane data via a protocol stack comprising the L1 layer <NUM>, the L2 layer <NUM>, the IP layer <NUM>, the SCTP layer <NUM>, and the S1-AP layer <NUM>.

<FIG> is an illustration of a user plane protocol stack in accordance with some embodiments. In this embodiment, a user plane <NUM> is shown as a communications protocol stack between the UE <NUM> (or alternatively, the UE <NUM>), the RAN node <NUM> (or alternatively, the RAN node <NUM>), the S-GW <NUM>, and the P-GW <NUM>. The user plane <NUM> may utilize at least some of the same protocol layers as the control plane <NUM>. For example, the UE <NUM> and the RAN node <NUM> may utilize a Uu interface (e.g., an LTE-Uu interface) to exchange user plane data via a protocol stack comprising the PHY layer <NUM>, the MAC layer <NUM>, the RLC layer <NUM>, the PDCP layer <NUM>.

The General Packet Radio Service (GPRS) Tunneling Protocol for the user plane (GTP-U) layer <NUM> may be used for carrying user data within the GPRS core network and between the radio access network and the core network. The user data transported can be packets in any of IPv4, IPv6, or PPP formats, for example. The UDP and IP security (UDP/IP) layer <NUM> may provide checksums for data integrity, port numbers for addressing different functions at the source and destination, and encryption and authentication on the selected data flows. The RAN node <NUM> and the S-GW <NUM> may utilize an S1-U interface to exchange user plane data via a protocol stack comprising the L1 layer <NUM>, the L2 layer <NUM>, the UDP/IP layer <NUM>, and the GTP-U layer <NUM>. The S-GW <NUM> and the P-GW <NUM> may utilize an S5/S8a interface to exchange user plane data via a protocol stack comprising the L1 layer <NUM>, the L2 layer <NUM>, the UDP/IP layer <NUM>, and the GTP-U layer <NUM>. As discussed above with respect to <FIG>, NAS protocols support the mobility of the UE <NUM> and the session management procedures to establish and maintain IP connectivity between the UE <NUM> and the P-GW <NUM>.

<FIG> is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, <FIG> shows a diagrammatic representation of hardware resources <NUM> including one or more processors (or processor cores) <NUM>, one or more memory/storage devices <NUM>, and one or more communication resources <NUM>, each of which may be communicatively coupled via a bus <NUM>. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor <NUM> may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources <NUM>.

Instructions <NUM> may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors <NUM> to perform any one or more of the methodologies discussed herein. The instructions <NUM> may reside, completely or partially, within at least one of the processors <NUM> (e.g., within the processor's cache memory), the memory/storage devices <NUM>, or any suitable combination thereof. Furthermore, any portion of the instructions <NUM> may be transferred to the hardware resources <NUM> from any combination of the peripheral devices <NUM> or the databases <NUM>. Accordingly, the memory of processors <NUM>, the memory/storage devices <NUM>, the peripheral devices <NUM>, and the databases <NUM> are examples of computer-readable and machine-readable media.

Examples of hardware elements may include processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, ASICs, programmable logic devices (PLD), digital signal processors (DSP), field programmable gate array (FPGA), logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth.

It should be noted that the methods described herein do not necessarily have to be executed in the order described, or in any particular order.

Claim 1:
A user equipment, UE, (<NUM>), comprising:
means for storing a service data adaption protocol, SDAP, header (<NUM>), the SDAP header (<NUM>) including an information element comprising an indication (<NUM>) of the presence of critical data, and the indication (<NUM>) of the presence of critical data comprising an indication of a request to a node, NB, (<NUM>,<NUM>) to increase a redundancy for a subsequent uplink, UL, grant for the UE (<NUM>); and
means for sending the information element to a node, NB, (<NUM>, <NUM>) of a radio access network, RAN, (<NUM>, <NUM>) to request the NB (<NUM>, <NUM>) to modify one or more settings that effect at least one of the handling or scheduling of data communicated between the UE (<NUM>) and the NB (<NUM>, <NUM>).