DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3, 8-11, 14, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Mondet et al. (US 2025/0071751 A1), hereinafter referred to as D1, in view of Akl et al. (US 2022/0022214 A1), hereinafter referred to as D4.
Regarding claims 1, 14, and 18, D1 discloses UE suggested Uplink resource allocation, which comprises:
facilitating, by a radio access network node comprising a processor, receiving, from core network equipment of a core network, a traffic flow information message comprising traffic information corresponding to a traffic flow associated with a user equipment (Referring to Figures 1-3 and 7-10, The network may obtain information about each uplink flow from the QoS characteristics for the traffic. As an example, the base station 702 may receive the flow information 712. From the QoS characteristics of the uplink flow, e.g., as received from the core network 706 at 712, the base station 702 may determine timing attributes such as a period, delivery time, and/or jitter for data flow #1. The base station 702 may determine payload attributes, such as payload size and/or payload variation, from the QoS characteristics for flow #1. The base station 702 may determine latency requirements for the flow #1 from the QoS characteristics. At 714, the base station 702 may determine when the uplink transmissions are to take place, e.g., which may be determined to optimize the flow requirements of flow #1, the resource utilization for flow #1, among other examples. See paragraphs 0100-0103.);
based on the traffic information and a scheduling bias, determining, by the radio access network node, an uplink resource grant configuration comprising at least one resource grant of at least one uplink resource usable to transmit, to the radio access network node, uplink traffic corresponding to the traffic flow; facilitating, by the radio access network node, transmitting, to the user equipment, the uplink resource grant configuration (Referring to Figures 1-3 and 7-10, At 714, the base station 702 may determine when the uplink transmissions are to take place, e.g., which may be determined to optimize the flow requirements of flow #1, the resource utilization for flow #1, among other examples (interpreted scheduling bias per the flow information 712). The base station determines the CG configuration and transmits the CG configuration to the UE at 718. See paragraphs 0100-0103.); and
facilitating, by the radio access network node, receiving a first uplink traffic payload corresponding to the traffic flow according to the uplink resource grant configuration (Referring to Figures 1-3 and 7-10, at 718, the base station 702 may transmit a configured grant to the UE 704, e.g., a configured grant for uplink data flow #1. When data arrives for flow #1, e.g., at 726, 730, and 744, the UE may transmit the uplink data in a PUSCH transmission 728, 732, and 746 using the resources of the configured grant (e.g., which may be referred to as a CG-PUSCH transmission). See paragraphs 0100-0103.)
D1 does not disclose wherein the scheduling bias is used to adjust a scheduling of the at least one uplink resource, and wherein a scheduling of the at least one uplink resource corresponding to the at least one resource grant indicated by the uplink resource grant configuration, has been adjusted based on the scheduling bias.
D4 teaches the scheduling bias may facilitate an equal or substantially equal (e.g., uniform, fair, equitable) distribution of resources scheduled by a parent IAB node for a child IAB node and/or a UE (scheduling bias used to adjust a scheduling of the at least one uplink resource). The scheduling bias may be associated with a radio link control (RLC) channel (CH) established between the parent IAB node and a child IAB node. The scheduling bias may affect at least one of time resources or frequency resources scheduled for the RLC CH between the child IAB node and the parent IAB node. The at least one of time resources or frequency resources may be associated with one or more radio bearers established between the parent IAB node and the child IAB node, which are conveyed on the RLC CH. According to some aspects, the scheduling bias may be used by the parent IAB node at least in part to schedule at least one of time resources or frequency resources to transmit PDUs on the RLC CH to the at least one child IAB node. See paragraphs 0028-0030. A scheduling entity 108 may broadcast downlink traffic 112 to one or more scheduled entities (e.g., one or more UEs 106). Broadly, the scheduling entity 108 is a node or device responsible for scheduling traffic in a wireless communication network, including the downlink traffic 112 and, in some examples, uplink traffic 116 from one or more scheduled entities (e.g., one or more UEs 106) to the scheduling entity 108 (uplink resource). On the other hand, the scheduled entity (e.g., a UE 106) is a node or device that receives downlink control information 114, including but not limited to scheduling information (e.g., a grant) (corresponding to the at least one resource granted indicated by the uplink resource grant configuration), synchronization or timing information, or other control information from another entity in the wireless communication network such as the scheduling entity 108. See paragraphs 0038-0040. Scheduling bias may be used to equalize or substantially equalize the provisioning of resources (e.g., time resources and/or frequency resources) among all UEs in an IAB network. The scheduling bias may compensate for child IAB nodes with multiple bearers (e.g., DRBs, SRBs) mapped to a single RLC channel (a single logical channel). According to some aspects, the scheduling bias may be used by a parent IAB node at least in part to schedule at least one of time resources or frequency resources for transmission of PDUs on the RLC channel to the at least one child IAB node. According to some aspects, the scheduling bias may be indicative of at least one of: a number of bearers mapped to the RLC channel, or an average number of bearers mapped to the RLC channel (where the average may be taken over time and may be configured, for example, by a donor CU or specified, for example, in a specification). According to some aspects, the scheduling bias may be a factor that equalizes a distribution of at least one of time resources or frequency resources scheduled among a load of the at least one child IAB node scheduled by a parent IAB node. The load may be given, for example, as the number of bearers mapped to the RLC channel, or the average number of bearers mapped to the RLC channel (where the average may be taken over time). The preceding lists are illustrative and non-limiting. Any number of measures may give the load. See paragraphs 0138-0140.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the scheduling bias of D3 in the system of D1. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to balance loading between channels in a base station, thereby, improving system throughput. In so doing, unexpected results are not achieved.
Regarding claim 2, the primary reference further teaches wherein the traffic information comprises the scheduling bias (Referring to Figures 1-3 and 7-10, the base station 702 may receive the flow information 712. From the QoS characteristics (scheduling bias) of the uplink flow, e.g., as received from the core network 706 at 712, the base station 702 may determine timing attributes such as a period, delivery time, and/or jitter for data flow #1. The base station 702 may determine payload attributes, such as payload size and/or payload variation, from the QoS characteristics for flow #1. The base station 702 may determine latency requirements for the flow #1 from the QoS characteristics. See paragraphs 0100-0103.)
Regarding claim 3, the primary reference further teaches based on the traffic information, determining, by the radio access network node, the scheduling bias (Referring to Figures 1-3 and 7-10, the base station 702 may receive the flow information 712. From the QoS characteristics (scheduling bias) of the uplink flow, e.g., as received from the core network 706 at 712, the base station 702 may determine timing attributes such as a period, delivery time, and/or jitter for data flow #1. The base station 702 may determine payload attributes, such as payload size and/or payload variation, from the QoS characteristics for flow #1. The base station 702 may determine latency requirements for the flow #1 from the QoS characteristics. See paragraphs 0100-0103.)
Regarding claim 8, the primary reference further teaches wherein the uplink resource grant configuration comprises a resource sharing indication indicative of at least one sharable resource of the at least one uplink resource that is sharable, by the user equipment, to at least one extended reality appliance with respect to which the user equipment is facilitating an extended reality uplink traffic flow (Referring to Figures 4-6 and 7-10, the UE and the base station may be configured to provide an XR service or a cloud gaming service, and the associated traffic may be associated with a low latency. Accordingly, the uplink (UL) packet 510 may include input information such as a tracking information or user pose information for the XR service or inputs for the cloud gaming service. In some examples, the UL packet 510 may include data of 100 bytes every 2 ms (at 500 Hz). The cloud server 506 may receive the UL packet 510 and generate the downlink (DL) packet 512 based on the received UL packet 510. For example, the cloud server 506 may receive the UL packet 510 including the tracking/pose information for the XR service or inputs for the cloud gaming service, and generate the DL packet 512 based on the received UL packet 510 including the tracking/pose information for the XR service or inputs for the cloud gaming service. See paragraphs 0090-0093. When data arrives for flow #1, e.g., at 726, 730, and 744, the UE may transmit the uplink data in a PUSCH transmission 728, 732, and 746 using the resources of the configured grant (e.g., which may be referred to as a CG-PUSCH transmission) (a resource sharing indication indicative of at least one sharable resource of that at least one uplink resources that is sharable). The network may allocate resources in a configured grant of uplink resources for the UE without information provided by the UE. See paragraphs 0100-0102.)
Regarding claim 9, the primary reference further teaches wherein the uplink resource grant configuration comprises sharable resource information corresponding to the at least one sharable resource (Referring to Figures 4-6 and 7-10, the UE and the base station may be configured to provide an XR service or a cloud gaming service, and the associated traffic may be associated with a low latency. Accordingly, the uplink (UL) packet 510 may include input information such as a tracking information or user pose information for the XR service or inputs for the cloud gaming service. In some examples, the UL packet 510 may include data of 100 bytes every 2 ms (at 500 Hz). The cloud server 506 may receive the UL packet 510 and generate the downlink (DL) packet 512 based on the received UL packet 510. For example, the cloud server 506 may receive the UL packet 510 including the tracking/pose information for the XR service or inputs for the cloud gaming service, and generate the DL packet 512 based on the received UL packet 510 including the tracking/pose information for the XR service or inputs for the cloud gaming service. See paragraphs 0090-0093. When data arrives for flow #1, e.g., at 726, 730, and 744, the UE may transmit the uplink data in a PUSCH transmission 728, 732, and 746 using the resources of the configured grant (e.g., which may be referred to as a CG-PUSCH transmission) (uplink resource grant configuration comprises sharable resource information corresponding to the at least one sharable resource). The network may allocate resources in a configured grant of uplink resources for the UE without information provided by the UE. See paragraphs 0100-0102.)
Regarding claims 10 and 17, the primary reference further teaches wherein the sharable resource information comprises at least one device identifier corresponding to at least one extended reality appliance with respect to which the user equipment is facilitating an extended reality uplink traffic flow (Referring to Figures 4-6 and 7-10, the UE and the base station may be configured to provide an XR service or a cloud gaming service, and the associated traffic may be associated with a low latency. Accordingly, the uplink (UL) packet 510 may include input information such as a tracking information or user pose information for the XR service or inputs for the cloud gaming service. In some examples, the UL packet 510 may include data of 100 bytes every 2 ms (at 500 Hz). The cloud server 506 may receive the UL packet 510 and generate the downlink (DL) packet 512 based on the received UL packet 510. For example, the cloud server 506 may receive the UL packet 510 including the tracking/pose information for the XR service or inputs for the cloud gaming service, and generate the DL packet 512 based on the received UL packet 510 including the tracking/pose information for the XR service or inputs for the cloud gaming service. See paragraphs 0090-0093. When data arrives for flow #1, e.g., at 726, 730, and 744, the UE may transmit the uplink data in a PUSCH transmission 728, 732, and 746 using the resources of the configured grant (e.g., which may be referred to as a CG-PUSCH transmission) (comprising a device identifier). The network may allocate resources in a configured grant of uplink resources for the UE without information provided by the UE. See paragraphs 0100-0102.)
Regarding claim 11, the primary reference further teaches wherein the uplink resource grant configuration comprises uplink transmission information corresponding to the at least one extended reality appliance, and wherein the uplink transmission information comprises at least one of: an uplink modulation scheme or an uplink coding scheme (Referring to Figures 4-6 and 7-10, the UE and the base station may be configured to provide an XR service or a cloud gaming service, and the associated traffic may be associated with a low latency. Accordingly, the uplink (UL) packet 510 may include input information such as a tracking information or user pose information for the XR service or inputs for the cloud gaming service. In some examples, the UL packet 510 may include data of 100 bytes every 2 ms (at 500 Hz). The cloud server 506 may receive the UL packet 510 and generate the downlink (DL) packet 512 based on the received UL packet 510. For example, the cloud server 506 may receive the UL packet 510 including the tracking/pose information for the XR service or inputs for the cloud gaming service, and generate the DL packet 512 based on the received UL packet 510 including the tracking/pose information for the XR service or inputs for the cloud gaming service. See paragraphs 0090-0093. When data arrives for flow #1, e.g., at 726, 730, and 744, the UE may transmit the uplink data in a PUSCH transmission 728, 732, and 746 using the resources of the configured grant (e.g., which may be referred to as a CG-PUSCH transmission) (comprising a device identifier). The network may allocate resources in a configured grant of uplink resources for the UE without information provided by the UE. See paragraphs 0100-0102. When multiple spatial streams are destined for the UE 350, they may be combined by the RX processor 356 into a single OFDM symbol stream (uplink coding scheme). The RX processor 356 then converts the OFDM symbol stream from the time-domain to the frequency domain using a Fast Fourier Transform (FFT). The frequency domain signal includes a separate OFDM symbol stream for each subcarrier of the OFDM signal. See paragraphs 0074-0076.)
Claim(s) 4-7, 15, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over D1 in view of D4 in further view of 0Rossbach et al. (US 2023/0269620 A1), hereinafter referred to as D2.
Regarding claims 4, 15, and 16, D1 discloses facilitating, by the radio access network node, receiving a second uplink traffic payload corresponding to the traffic flow, wherein the second uplink traffic payload is received before the first uplink traffic payload (Referring to Figures 1-3 and 7-10, the base station 702 may receive the flow information 712. From the QoS characteristics (scheduling bias) of the uplink flow, e.g., as received from the core network 706 at 712, the base station 702 may determine timing attributes such as a period, delivery time, and/or jitter for data flow #1. The base station 702 may determine payload attributes, such as payload size and/or payload variation, from the QoS characteristics for flow #1. The base station 702 may determine latency requirements for the flow #1 from the QoS characteristics. See paragraphs 0100-0103.)
D1 does not disclose wherein the determining the scheduling bias comprises: determining a payload segmentation value corresponding to the second uplink traffic payload; analyzing the payload segmentation value with respect to a payload segmentation criterion, to result in an analyzed payload segmentation value; and based on the analyzed payload segmentation value satisfying the payload segmentation criterion, increasing a baseline scheduling bias by a scheduling bias adjustment value that corresponds to the analyzed payload segmentation value.
D2 teaches, referring to Figures 7-9, the UE may be configured with a secondary QoS profile or a secondary set of QoS parameters and/or QoS characteristics for the same QFI and/or 5G QoS Identifier (5QI). Moreover, according to some embodiments, the network or the UE itself may be able to introduce different QoS severity (e.g., significance/priority) levels within the same stream of a QoS flow such that the UE automatically switches to the next better QoS/QFI parameter (e.g., the next BLER, or the next periodicity) in a list of parameter values (based on the analyzed payload segmentation value satisfying the payload segmentation criterion, increasing a baseline scheduling bias by a scheduling bias adjustment value that corresponds to the analyzed payload segmentation value). Accordingly, there may be a number of methods or means of triggering a change in QoS or the QFI associated with a certain slice or ADU in a XR application data burst. In some embodiments, the network may be configured to switch the mapping of a QFI to a slice or ADU to a higher reliability or a secondary QoS based on sequence number (SN). For example, the mapping of a QFI may be characterized such that every N.sup.th RTP SN, N.sup.th PDCP SDU, N.sup.th application layer packet or N.sup.th IP packet may belongs to a certain QoS flow, according to some embodiments. Furthermore, in some embodiments, N may be characterized or determined by a statistical distribution function (e.g., a Pareto distribution or a truncated Gaussian distribution). In some embodiments, the phase of higher reliability or a secondary QoS may be characterized such that the QoS flow remains in that state for a configurable number of packets (e.g., 1...M). Additionally or alternatively, a switch to a higher reliability or a secondary QoS profile may be configured to occur at every N.sup.th ADU as a whole and/or for different slice types. In some embodiments, the application layer may identify the start packet and the end packet associated with a slice or ADU and indicate the same to the lower layers which may further identify and trigger a period of modified reliability or QoS for the associated traffic. See paragraphs 0146-0151. An XR application or related connection may have a set of secondary QoS characteristics with better reliability or augmented settings which may be automatically triggered based on error events, a history of earlier abnormal events, or a location (e.g., when it can be inferred from the history that another failure is likely to happen). The network or UE may be configured to enable or trigger a period of time with higher reliability automatically based on abnormal or error events in the UE (interpreted as the payload segmentation criterion comprises a latency-violating segment threshold, and wherein the payload segmentation criterion is satisfied by the segmentation count exceeding the latency-violating segment threshold). For example, the network may trigger a period of higher reliability based on feedback or radio conditions (e.g., below a certain RSRP/RSRQ) or the UE. Additionally or alternatively, a temporary modification of reliability may also be based on a timer such that a defined period (e.g., with start and stop times) with augmented QoS settings is specified. See paragraphs 0152-0154.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the QFI mapping of D2 in the system of D1 and D4. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to increase coverage and better serve the increasing demand and range of envisioned uses of wireless communication and comply with well-known standards.
Regarding claims 5 and 6, D1 does not disclose wherein the determining the payload segmentation value comprises: determining a segmentation count of at least one packet segment, corresponding to the second uplink traffic payload, associated with violating an uplink latency criterion; wherein the payload segmentation criterion comprises a latency-violating segment threshold, and wherein the payload segmentation criterion is satisfied by the segmentation count exceeding the latency-violating segment threshold/decreasing a baseline scheduling bias by a scheduling bias adjustment value that corresponds to the analyzed payload segmentation value.
D2 teaches, referring to Figures 7-9, mapping quality of service flow identifiers (QFIs) to data segments or portions of XR data bursts, according to some embodiments. More specifically, FIG. 8 details how a user equipment (UE) or, in some embodiments, a network side entity may assign or map certain QoS parameters to corresponding XR data slices or ADUs such that the XR data is transmitted and received more efficiently. For example, in 802, a UE may communicate with a network in order to establish a connection with the network. Once the connection has been established, the UE may be able to transmit or relay extended reality (XR) data bursts to the network regarding an XR application running on the UE. As described in regard to FIG. 6, the UE may accomplish this via the Uu interface between the UE and the network (e.g., a base station acting as part of the RAN). Accordingly, once the connection to the network has been established, the UE may begin to transmit the XR data bursts to the network through use of a configured grant (CG). Additionally or alternatively, 802 may be performed by a network entity (e.g, a base station and/or core network (CN). For example, the network may initiate communications with the UE in order to establish a connection to further facilitate XR data burst transmissions from the network to the UE. In 804, the UE may transmit a first data segment corresponding to a first QFI. In some embodiments, the UE may perform mapping operations such that certain QoS flows are assigned or mapped to corresponding data segments of the data bursts (e.g., slices and/or ADUs). For example, a data burst, which may be transmitted over the air in a dedicated configured grant (CG), may include data or information for an XR application in the form of one or more slices and/or ADUs. Accordingly, the UE may map a first data segment or data portion (e.g., a data slice or ADU) of the data burst to a first QoS flow. In doing so, the first data segment (mapped to a first QoS flow) may have a traffic forwarding treatment corresponding to the first QoS flow’s traffic pattern and QoS parameters (scheduling bias). Additionally or alternatively, 804 may be performed by a network entity such as a base station and/or core network. For example, in some embodiments, the network may be supporting an XR application running on the UE (e.g., by providing external computing resources) and further need to transmit related data bursts to the UE. Accordingly, the network may utilize a similar method in 804 to map a first data segment of the data burst to a first QoS flow. In doing so, the network may link or associate the first data segment (corresponding to the first QoS flow) such that it has a traffic forwarding treatment corresponding to the first QoS flow’s traffic pattern and QoS parameters (scheduling bias). In some embodiments, the exact mapping between QoS flows and data segments may be established by the network or defined based on predefined rules. In 806, the UE may further transmit a second data segment corresponding to a second QFI (payload segmentation value corresponding to the second uplink traffic payload). In some embodiments, the UE may map a different QoS flow (e.g., a second QFI) to a second data segment of the data burst (analyzing the payload segmentation value with respect to a payload segmentation criterion to result in an analyzed payload segmentation value) which may further be transmitted via a second configured grant (CG). In doing so, the second data segment (associated with a second QFI) may have different QoS forwarding treatment and QoS parameters (associated with latency, reliability, precedence, etc.) compared to that of the first data segment. Accordingly, the data segments (e.g., slices/ADUs) may have different or preferred treatment when being transmitted to the network for support of the XR application. Additionally or alternatively, 806 may be performed by a network entity such as a base station and/or core network. For example, in some embodiments similar to 806, the network may further map a different QoS flow (e.g., a second QFI) to a second data segment of the data burst which may have been transmitted via a second semi-periodic scheduling (SPS) transmission. In doing so, the network may configure a second data segment (associated with the second QFI) such that it has a traffic forwarding treatment corresponding to the second QFI parameters (different from the first QFI). These XR data bursts may be transmitted according to the QFIs that have been mapped to the corresponding data segments of the data bursts which further include the mappings of one or more QFIs to the one or more slices/ADUs of the data burst. Additionally, or alternatively the QFIs may be included in the transmission. Accordingly, the base station and/or the core network may be able to control how the data segments in the data bursts are to be treated when being transmitted to the UE for the XR application. As discussed above in regard to 804 and 806, this may allow for preferential treatment for certain slices or ADUs (e.g., data segments) which may require higher fidelity transmissions. In effect, the network’s mapping of certain QFIs to certain XR data segments may improve the performance of the XR application running on the UE through more efficient and higher fidelity transmissions. Accordingly, once the UE receives the XR data, it may further process and display the data according to the XR application running on the UE. For example, a XR data burst may include video and/or multimedia frames that require certain codecs to decode and the UE may display these video and/or multimedia frames once decoded. See paragraphs 0137-0141. The UE may be configured with a secondary QoS profile or a secondary set of QoS parameters and/or QoS characteristics for the same QFI and/or 5G QoS Identifier (5QI). Moreover, according to some embodiments, the network or the UE itself may be able to introduce different QoS severity (e.g., significance/priority) levels within the same stream of a QoS flow such that the UE automatically switches to the next better QoS/QFI parameter (e.g., the next BLER, or the next periodicity) in a list of parameter values (based on the analyzed payload segmentation value satisfying the payload segmentation criterion, increasing a baseline scheduling bias by a scheduling bias adjustment value that corresponds to the analyzed payload segmentation value). Accordingly, there may be a number of methods or means of triggering a change in QoS or the QFI associated with a certain slice or ADU in a XR application data burst. In some embodiments, the network may be configured to switch the mapping of a QFI to a slice or ADU to a higher reliability or a secondary QoS based on sequence number (SN). For example, the mapping of a QFI may be characterized such that every N.sup.th RTP SN, N.sup.th PDCP SDU, N.sup.th application layer packet or N.sup.th IP packet may belongs to a certain QoS flow, according to some embodiments. Furthermore, in some embodiments, N may be characterized or determined by a statistical distribution function (e.g., a Pareto distribution or a truncated Gaussian distribution). In some embodiments, the phase of higher reliability or a secondary QoS may be characterized such that the QoS flow remains in that state for a configurable number of packets (e.g., 1...M). Additionally or alternatively, a switch to a higher reliability or a secondary QoS profile may be configured to occur at every N.sup.th ADU as a whole and/or for different slice types (determining a segmentation count of at least one packet segment, corresponding to the second uplink traffic payload). In some embodiments, the application layer may identify the start packet and the end packet associated with a slice or ADU and indicate the same to the lower layers which may further identify and trigger a period of modified reliability or QoS for the associated traffic (switching between modification either resulting in increased or decreased scheduling bias adjustment value, latency-violating segment threshold and satisfied by the segmentation count exceeding the latency-violating segment threshold). See paragraphs 0146-0151.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the QFI mapping of D2 in the system of D1 and D4. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to increase coverage and better serve the increasing demand and range of envisioned uses of wireless communication and comply with well-known standards.
Regarding claim 7, D1 does not disclose wherein the payload segmentation criterion is satisfied by a segmentation count, corresponding to the payload segmentation value, being less than a latency-violating segment threshold.
The UE may be configured with a secondary QoS profile or a secondary set of QoS parameters and/or QoS characteristics for the same QFI and/or 5G QoS Identifier (5QI). Moreover, according to some embodiments, the network or the UE itself may be able to introduce different QoS severity (e.g., significance/priority) levels within the same stream of a QoS flow such that the UE automatically switches to the next better QoS/QFI parameter (e.g., the next BLER, or the next periodicity) in a list of parameter values (based on the analyzed payload segmentation value satisfying the payload segmentation criterion, increasing a baseline scheduling bias by a scheduling bias adjustment value that corresponds to the analyzed payload segmentation value). Accordingly, there may be a number of methods or means of triggering a change in QoS or the QFI associated with a certain slice or ADU in a XR application data burst. In some embodiments, the network may be configured to switch the mapping of a QFI to a slice or ADU to a higher reliability or a secondary QoS based on sequence number (SN). For example, the mapping of a QFI may be characterized such that every N.sup.th RTP SN, N.sup.th PDCP SDU, N.sup.th application layer packet or N.sup.th IP packet may belongs to a certain QoS flow, according to some embodiments. Furthermore, in some embodiments, N may be characterized or determined by a statistical distribution function (e.g., a Pareto distribution or a truncated Gaussian distribution). In some embodiments, the phase of higher reliability or a secondary QoS may be characterized such that the QoS flow remains in that state for a configurable number of packets (e.g., 1...M). Additionally or alternatively, a switch to a higher reliability or a secondary QoS profile may be configured to occur at every N.sup.th ADU as a whole and/or for different slice types (determining a segmentation count of at least one packet segment, corresponding to the second uplink traffic payload). In some embodiments, the application layer may identify the start packet and the end packet associated with a slice or ADU and indicate the same to the lower layers which may further identify and trigger a period of modified reliability or QoS for the associated traffic (switching between modification either resulting in increased, wherein the payload segmentation criterion is satisfied by a segmentation count being less than a latency-violating segment threshold, or decreased scheduling bias adjustment value). See paragraphs 0146-0151.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the QFI mapping of D2 in the system of D1 and D4. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to increase coverage and better serve the increasing demand and range of envisioned uses of wireless communication and comply with well-known standards.
Claim(s) 12, 13, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over D1 in view of D4 in further view of Elshafie et al. (US 2024/0236995 A1), hereinafter referred to as D3.
Regarding claims 12 and 19, D1 does not disclose facilitating, by the radio access network node, a blind decoding of the at least one sharable resource.
D3 teaches the network node can accordingly determine resources to schedule for the UE to transmit UL data. For DG-based PUSCH and/or physical downlink shared channel (PDSCH) scheduling, the UE can perform blind decoding for a physical downlink control channel (PDCCH) that indicates downlink control information (DCI) indicating resources scheduled for each transmission. See paragraphs 0022-0034.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the blind decoding of D3 in the system of D1 and D4. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to comply with well-known standards for uplink communication.
Regarding claims 13 and 20, D1 does not disclose facilitating, by the radio access network node, receiving, from the user equipment, an uplink resource sharing report comprising a shared resource indication indicative of the at least one of the at least one extended reality appliance using the at least one sharable resource to transmit the extended reality uplink traffic flow; facilitating, by the radio access network node, avoiding a blind decoding of the at least one sharable resource; and facilitating, by the radio access network node, a direct decoding of the at least one sharable resource based on transmission configuration information corresponding to the at least one extended reality appliance.
For CG-based PUSCH and/or PDSCH scheduling, the network node can assign resources for transmission in advance (e.g., using semi-static signaling, such as radio resource control (RRC) signaling). In CG-based scheduling, SR and/or BSR may not be required before PUSCH transmission, and the UE may not need to perform blind decoding for DCI for each transmission. However, the network node may not know the UL payload size and the number of practical resources to allocate for the UE to transmit PUSCH. In general, XR traffic, for an XR appliance, can be latency sensitive. See paragraphs 0022-0024. A device that receives control information indicating resources or related parameters for transmitting or receiving wireless communications can send a control information (uplink resource sharing report) response that can modify one or more of the received parameters to adapt the wireless communications for the device. For example, a UE receiving an indication or resources or related parameters for a DL SPS or UL CG can respond with a modified MCS, RB allocation, indication of antenna ports, starting offset, feedback offset, etc. In an example, the UE may modify, or request modification of, the parameters based on one or more power parameters of the device, such as a power consumption model, a current charging rate or charging rate profile, a discharging rate or discharging rate profile, an energy storage state or energy storage level, an energy storage capacity, etc. This can allow the UE to balance power consumption or available power with performance that can be achieved based on the modified parameters. This can, in turn, improve user experience when using the UE or other device. See paragraphs 0028-0031. UE communicating component 342 can receive one or more parameters related to resources scheduled for wireless communication, such as an activation DCI for PDSCH or PUSCH resources. In an example, UE communicating component 342 can transmit a control information response that includes a request to modify the one or more parameters, which may be based on a power consumption model or one or more power-related parameters at the UE 104. BS communicating component 442 can transmit the one or more parameters related to resources scheduled for wireless communication and/or can receive a control information response requesting modification of one or more parameters. In an example, BS communicating component 442 can accordingly modify the one or more parameters and/or can transmit a notification that the one or more parameters are modified. UE communicating component 342 and BS communicating component 442 can communicate over the scheduled resources based on the one or more modified parameters. See paragraphs 0047-0049. A receive (Rx) processor 958 may process (e.g., demodulate, deinterleave, and decode) the detected symbols, providing decoded data for the UE 104 to a data output, and provide decoded control information to a processor 980, or memory 982. See paragraphs 0106-0108.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the blind decoding of D3 in the system of D1 and D4. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to do so to comply with well-known standards for uplink communication.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Zhou et al. (US 2022/0150713 A1) - The controller uses the reported data, possibly along with biasing weight data, to allocate the total number of available shared spectrum resource blocks to the LTE and NR cells, for use in scheduling their respective user equipment communications until the next reporting period. The resource blocks allocated to the LTE cell do not collide with the resource blocks allocated to the NR cell, such as by top-down, bottom-up frequency division, or via an allocation bitmap sent to each cell.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONALD L MILLS whose telephone number is (571)272-3094. The examiner can normally be reached Monday through Friday from 9-5 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yemane Mesfin can be reached at 571-272-3927. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
DONALD L. MILLS
Primary Examiner
Art Unit 2462
/Donald L Mills/ Primary Examiner, Art Unit 2462
Prosecution Insights