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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 01/29/2025, 07/25/2025 and 08/14/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Rejections - 35 USC § 103
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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claims 21-23, 28-30 and 33-35 are rejected under 35 U.S.C. 103 as being unpatentable over Azorero et al. (US 2022/0279431 A1), Azorero hereinafter, and further in view of Sachs et al. (US 2020/0259896 A1), Sachs hereinafter.
Re. Claim 21, Azorero teaches an apparatus, wherein the apparatus comprises: a transceiver; at least one processor; and one or more non-transitory memories coupled to the at least one processor and storing programming instructions that are executable by the at least one processor, wherein execution of the programming instructions causes the apparatus to: (Fig. 4 & ¶0099 - With reference to FIG. 4, an apparatus 40 comprises a storage device 410 and a processor 420 coupled to the storage device 410. The storage device 410 is configured to store a computer program 430 comprising computer instructions. The processor 420 is configured to execute the computer instructions to perform some or all of the method steps as shown in FIG. 3. In this embodiment, the apparatus 40 may be a node for PCF);
receive information about first time windows and information about first parameters, (Fig. 3 & ¶0088 - Step 301: The node for PCF receives, from a node for AF e.g., via a node for Network Exposure Function (NEF), a BDT policy request indicating the BDT for a UE is UE trajectory-relevant. ¶0089 - … the request may include an Application Service Provider (ASP) identifier, volume of data to be transferred for the UE, desired time window for data transfer, an indicator indicating the BDT is UE trajectory-relevant, and UE trajectory of the UE if available);
wherein a first time window of the first time windows is a time window of data transfer of a first service and configured by an application function network element, (¶0002 - BDT policy handling is a functionality that allows an Application Function (AF) to transmit/receive a certain volume of background data traffic per UE or for a number of UEs under some requirements, such as a time window for transfer, specific network conditions, and optionally a network area where the transfer occurs. A Policy Control Function (PCF) can derive a BDT policy that adapts to those requirements. The BDT policy typically may define which QoS and charging control policy are employed within a specific time window for a UE. Please also see ¶0103);
the first parameters comprise parameters of the data transfer of the first service in the first time windows, (¶0089 - … the request may include an Application Service Provider (ASP) identifier, volume of data to be transferred for the UE, desired time window for data transfer, an indicator indicating the BDT is UE trajectory-relevant, and UE trajectory of the UE if available);
and send information about M policies of the first service, (Fig. 3 & ¶0095 - Step 307: The node for PCF transmits to the node for AF, e.g. via the NEF, one or more common BDT policies as derived at step 304 or a plurality policy groups as derived at step 305. ¶0110 - If more than one available BDT policies is included in one BDT policy group, an indicator may be accompanied with the BDT policy group, indicating multiple transfer policies for the corresponding section. Moreover, the PCF may transmit UE trajectory-irrelevant BDT policies);
wherein information about each policy of the M policies comprises information about corresponding N time windows, (¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated. ¶0069 - … one available BDT policy may consist of a recommended BDT time window for the corresponding section of the UE trajectory, a reference to a charging rate for the recommended BDT time window, and optionally a maximum aggregated bitrate … );
M and N are positive integers, (Fig. 1 & ¶0081 - Step 102: The node for AF receives, from the node for PCF e.g. via the node for NEF, a plurality of BDT policy groups … associated with or allocated to the UE trajectory of the UE … each of the BDT policy groups is associated with a corresponding section of the UE trajectory and may include one or more available BDT policies. Each available BDT policy defines a time period and a network area associated with the corresponding section, and QoS/charging conditions applied to the time period or the network area. Fig. 3 & ¶0095 - Step 307: The node for PCF transmits to the node for AF, e.g. via the NEF, one or more common BDT policies as derived at step 304 or a plurality policy groups as derived at step 305. ¶0110 - If more than one available BDT policies is included in one BDT policy group, an indicator may be accompanied with the BDT policy group, indicating multiple transfer policies for the corresponding section. Moreover, the PCF may transmit UE trajectory-irrelevant BDT policies. Examiner interprets Azorero allows one or more policies and one time period per policy, thus M is greater than or equal to 1 and N is equal to 1);
the information about the each policy is determined based on the information about the first time windows and the information about the first parameters, (Fig. 3 & ¶0092 - Step 304: The node for PCF derives one or more common BDT policies without considering the UE trajectory. For example, the common BDT policies may rely on the following aspects individually or in combination: network policy, level information in a S-NSSAI and load status estimation for the required time window, network area information, and existing transfer policies. Fig. 5 & ¶0109 - Step 505: The (H-) PCF determines one or more BDT policies based on the information received from the NEF and other available information (e.g. network policy, existing transfer policies, network area information and load status estimation for the desired time window). If the UE trajectory was received and the (H-)PCF supports this functionality, the (H-)PCF may derive BDT policies per trajectory section having respective QoS and charging demands. That is, the (H-)PCF may derive a plurality of BDT policy groups for the UE trajectory, each of which is applicable to one corresponding section … Therefore, the (H-)PCF determines the BDT policies for the sections of the expected or analytic UE trajectory);
and N time windows in one of the M policies of the first service are used to transmit or receive data of the first service (¶0076 - For UE controlled xBDT, background data will be transmitted to the UE as part of UE policy … The UE will be responsible for handling MO traffic in accordance with the time interval and location condition in the UE policy. ¶0077 - For network controlled xBDT, the Npcf_UEPolicyControl service may be in charge of updating the UE with the applicable UE Policy per section, based on the time interval and location conditions defined for the corresponding section of the UE trajectory. Moreover, the network (PCF—Npcf_SMPolicyControl) may be responsible for controlling the UE PDU session's QoS/Charging according to the negotiated BDT policy on the section-basis. Fig. 1 & ¶0082 - Step 103: The node for AF determines one applied BDT policy for each of the BDT policy groups … For one BDT policy group including more than one available BDT policies, the node for AF selects one as an applied BDT policy).
Yet, Azorero does not explicitly teach and a first parameter of the first parameters comprises at least one of a delay, a packet error rate, a packet loss rate, a bit rate, or a guaranteed bit rate;
However, in the analogous art, Sachs explicitly teaches and a first parameter of the first parameters comprises at least one of a delay (Fig. 114 & ¶0774 - The Application Function (AF) in the 5GS might be an option to interface the CNC … The AF then could also accept a time schedule from the CNC and translate it into meaningful parameters for the 5GS to support the time gated queuing happening in the external TSN network. ¶1255 - For each QoS flow (which can correspond to one or multiple traffic classes), a certain QoS requirement can be indicated to the gNB. In some embodiments, this indication to the gNB can include an indicator of a time-window during which a packet of the QoS flow should be guaranteed to be transmitted. This time window can be indicated, e.g., by providing an absolute time reference for the time window start together with a length of the window (e.g., as a latency bound). ¶1257 - after determining the information as discussed above, the AMF sends an indication and/or request the gNB(s) to confirm that the QoS, time window, and/or periodicity requirements can be met. In operation 15, after receiving the request/indication sent in operation 14, the gNB (or gNBs, as the case may be) determines whether it can serve this additional QoS flow with the indicated time-window requirement … In some embodiments, when declining the request, the gNB can indicate an alternative time window ... the gNB can also reserve any additional resources identified as required to meet the requested transmission schedule), a packet error rate, a packet loss rate, a bit rate, or a guaranteed bit rate;
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Sachs to the teaching of Azorero. The motivation would be because the invention describes enhancing performance in Industrial Internet-of-Things (IIoT) scenarios, including techniques for time-sensitive networking (TSN) and 5G wireless network integration (Abstract, Sachs).
Re. Claim 22, Azorero and Sachs teach Claim 21.
Azorero further teaches the programming instructions, when executed by the at least one processor, further cause the apparatus to: send information about N second parameters, (Fig. 1-4 (Fig. 3) & ¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated. ¶0069 - In one or more embodiments of the present invention, one available BDT policy may consist of a recommended BDT time window for the corresponding section of the UE trajectory, a reference to a charging rate for the recommended BDT time window, and optionally a maximum aggregated bitrate indicating that the charging level according to the referenced charging rate is only applicable to the aggregated traffic of all involved UEs that stay below the referenced charging rate. ¶0095 - Step 307: The node for PCF transmits to the node for AF, e.g. via the NEF, one or more common BDT policies as derived at step 304 or a plurality policy groups as derived at step 305);
wherein the information about the N time windows is in a one-to-one correspondence with the information about the N second parameters, (¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated);
each second parameter of the N second parameters comprises parameters of data transfer of the first service in a corresponding time window, (¶0002 - BDT policy handling is a functionality that allows an Application Function (AF) to transmit/receive a certain volume of background data traffic per UE or for a number of UEs under some requirements, such as a time window for transfer, specific network conditions, and optionally a network area where the transfer occurs. A Policy Control Function (PCF) can derive a BDT policy that adapts to those requirements. The BDT policy typically may define which QoS and charging control policy are employed within a specific time window for a UE. ¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated);
and the each second parameter comprises at least one of a corresponding delay, a corresponding packet error rate, a corresponding packet loss rate, a corresponding bit rate, or a corresponding guaranteed bit rate (¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated. ¶0069 - In one ore more embodiments of the present invention, one available BDT policy may consist of a recommended BDT time window for the corresponding section of the UE trajectory, a reference to a charging rate for the recommended BDT time window, and optionally a maximum aggregated bitrate indicating that the charging level according to the referenced charging rate is only applicable to the aggregated traffic of all involved UEs that stay below the referenced charging rate).
Re. Claim 23, Azorero and Sachs teach Claim 21.
Yet, Azorero does not explicitly teach the programming instructions, when executed by the at least one processor, further cause the apparatus to: receive first indication information, wherein the first indication information indicates whether the information about the each policy is allowed to comprise information about a plurality of time windows.
However, in the analogous art, Sachs explicitly teaches the programming instructions, when executed by the at least one processor, further cause the apparatus to: receive first indication information, wherein the first indication information indicates whether the information about the each policy is allowed to comprise information about a plurality of time windows (Fig. 114 & ¶1255 - … a mapping between traffic classes within this TSN stream and QoS flows of the UE can be identified. For each QoS flow (which can correspond to one or multiple traffic classes), a certain QoS requirement can be indicated to the gNB. In some embodiments, this indication to the gNB can include an indicator of a time-window during which a packet of the QoS flow should be guaranteed to be transmitted … In some embodiments, the indication to the gNB can also include a periodicity (or period) of the time window. This can be included, e.g., if the TSN stream comprises multiple transmission events that occur according to a periodic schedule).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Sachs to the teaching of Azorero. The motivation would be because the invention describes enhancing performance in Industrial Internet-of-Things (IIoT) scenarios, including techniques for time-sensitive networking (TSN) and 5G wireless network integration (Abstract, Sachs).
Re. Claim 28, Azorero teaches an apparatus, wherein the apparatus comprises: a transceiver; at least one processor; and one or more non-transitory memories coupled to the at least one processor and storing programming instructions that are executable by the at least one processor, wherein execution of the programming instructions causes the apparatus to: (Fig. 2 & ¶0085 - With reference to FIG. 2, an apparatus 20 comprises a storage device 210 and a processor 220 coupled to the storage device 210. The storage device 210 is configured to store a computer program 230 comprising computer instructions. The processor 220 is configured to execute the computer instructions to perform some or all of the method steps as shown in FIG. 1. In this embodiment, the apparatus 20 may be a node for AF);
send information about first time windows and information about first parameters, (Fig. 3 & ¶0088 - Step 301: The node for PCF receives, from a node for AF e.g., via a node for Network Exposure Function (NEF), a BDT policy request indicating the BDT for a UE is UE trajectory-relevant. ¶0089 - … the request may include an Application Service Provider (ASP) identifier, volume of data to be transferred for the UE, desired time window for data transfer, an indicator indicating the BDT is UE trajectory-relevant, and UE trajectory of the UE if available);
wherein a first time window of the first time windows is a time window of data transfer of a first service and configured by the apparatus, (¶0002 - BDT policy handling is a functionality that allows an Application Function (AF) to transmit/receive a certain volume of background data traffic per UE or for a number of UEs under some requirements, such as a time window for transfer, specific network conditions, and optionally a network area where the transfer occurs. A Policy Control Function (PCF) can derive a BDT policy that adapts to those requirements. The BDT policy typically may define which QoS and charging control policy are employed within a specific time window for a UE. Please also see ¶0103);
the first parameters comprise parameters of the data transfer of the first service in the first time windows, (¶0089 - … the request may include an Application Service Provider (ASP) identifier, volume of data to be transferred for the UE, desired time window for data transfer, an indicator indicating the BDT is UE trajectory-relevant, and UE trajectory of the UE if available);
and receive information about M policies of the first service, (Fig. 3 & ¶0095 - Step 307: The node for PCF transmits to the node for AF, e.g. via the NEF, one or more common BDT policies as derived at step 304 or a plurality policy groups as derived at step 305. ¶0110 - If more than one available BDT policies is included in one BDT policy group, an indicator may be accompanied with the BDT policy group, indicating multiple transfer policies for the corresponding section. Moreover, the PCF may transmit UE trajectory-irrelevant BDT policies);
wherein information about each policy of the M policies comprises information about corresponding N time windows, (¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated. ¶0069 - … one available BDT policy may consist of a recommended BDT time window for the corresponding section of the UE trajectory, a reference to a charging rate for the recommended BDT time window, and optionally a maximum aggregated bitrate … );
M and N are positive integers, (Fig. 1 & ¶0081 - Step 102: The node for AF receives, from the node for PCF e.g. via the node for NEF, a plurality of BDT policy groups … associated with or allocated to the UE trajectory of the UE … each of the BDT policy groups is associated with a corresponding section of the UE trajectory and may include one or more available BDT policies. Each available BDT policy defines a time period and a network area associated with the corresponding section, and QoS/charging conditions applied to the time period or the network area. Fig. 3 & ¶0095 - Step 307: The node for PCF transmits to the node for AF, e.g. via the NEF, one or more common BDT policies as derived at step 304 or a plurality policy groups as derived at step 305. ¶0110 - If more than one available BDT policies is included in one BDT policy group, an indicator may be accompanied with the BDT policy group, indicating multiple transfer policies for the corresponding section. Moreover, the PCF may transmit UE trajectory-irrelevant BDT policies. Examiner interprets Azorero allows one or more policies and one time period per policy, thus M is greater than or equal to 1 and N is equal to 1);
and the information about the each policy is determined based on the information about the first time windows and the information about the first parameters, (Fig. 3 & ¶0092 - Step 304: The node for PCF derives one or more common BDT policies without considering the UE trajectory. For example, the common BDT policies may rely on the following aspects individually or in combination: network policy, level information in a S-NSSAI and load status estimation for the required time window, network area information, and existing transfer policies. Fig. 5 & ¶0109 - Step 505: The (H-) PCF determines one or more BDT policies based on the information received from the NEF and other available information (e.g. network policy, existing transfer policies, network area information and load status estimation for the desired time window). If the UE trajectory was received and the (H-)PCF supports this functionality, the (H-)PCF may derive BDT policies per trajectory section having respective QoS and charging demands. That is, the (H-)PCF may derive a plurality of BDT policy groups for the UE trajectory, each of which is applicable to one corresponding section … Therefore, the (H-)PCF determines the BDT policies for the sections of the expected or analytic UE trajectory);
and N time windows in one of the M policies of the first service are used to transmit or receive data of the first service (¶0076 - For UE controlled xBDT, background data will be transmitted to the UE as part of UE policy … The UE will be responsible for handling MO traffic in accordance with the time interval and location condition in the UE policy. ¶0077 - For network controlled xBDT, the Npcf_UEPolicyControl service may be in charge of updating the UE with the applicable UE Policy per section, based on the time interval and location conditions defined for the corresponding section of the UE trajectory. Moreover, the network (PCF—Npcf_SMPolicyControl) may be responsible for controlling the UE PDU session's QoS/Charging according to the negotiated BDT policy on the section-basis. Fig. 1 & ¶0082 - Step 103: The node for AF determines one applied BDT policy for each of the BDT policy groups … For one BDT policy group including more than one available BDT policies, the node for AF selects one as an applied BDT policy).
Yet, Azorero does not explicitly teach and a first parameter of the first parameters comprises at least one of a delay, a packet error rate, a packet loss rate, a bit rate, or a guaranteed bit rate;
However, in the analogous art, Sachs explicitly teaches and a first parameter of the first parameters comprises at least one of a delay (Fig. 114 & ¶0774 - The Application Function (AF) in the 5GS might be an option to interface the CNC … The AF then could also accept a time schedule from the CNC and translate it into meaningful parameters for the 5GS to support the time gated queuing happening in the external TSN network. ¶1255 - For each QoS flow (which can correspond to one or multiple traffic classes), a certain QoS requirement can be indicated to the gNB. In some embodiments, this indication to the gNB can include an indicator of a time-window during which a packet of the QoS flow should be guaranteed to be transmitted. This time window can be indicated, e.g., by providing an absolute time reference for the time window start together with a length of the window (e.g., as a latency bound). ¶1257 - after determining the information as discussed above, the AMF sends an indication and/or request the gNB(s) to confirm that the QoS, time window, and/or periodicity requirements can be met. In operation 15, after receiving the request/indication sent in operation 14, the gNB (or gNBs, as the case may be) determines whether it can serve this additional QoS flow with the indicated time-window requirement … In some embodiments, when declining the request, the gNB can indicate an alternative time window ... the gNB can also reserve any additional resources identified as required to meet the requested transmission schedule), a packet error rate, a packet loss rate, a bit rate, or a guaranteed bit rate;
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Sachs to the teaching of Azorero. The motivation would be because the invention describes enhancing performance in Industrial Internet-of-Things (IIoT) scenarios, including techniques for time-sensitive networking (TSN) and 5G wireless network integration (Abstract, Sachs).
Re. Claim 29, Azorero and Sachs teach Claim 28.
Azorero further teaches the programming instructions, when executed by the at least one processor, further cause the apparatus to: receive information about N second parameters, (Fig. 1-4 (Fig. 3) & ¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated. ¶0069 - In one or more embodiments of the present invention, one available BDT policy may consist of a recommended BDT time window for the corresponding section of the UE trajectory, a reference to a charging rate for the recommended BDT time window, and optionally a maximum aggregated bitrate indicating that the charging level according to the referenced charging rate is only applicable to the aggregated traffic of all involved UEs that stay below the referenced charging rate. ¶0095 - Step 307: The node for PCF transmits to the node for AF, e.g. via the NEF, one or more common BDT policies as derived at step 304 or a plurality policy groups as derived at step 305);
wherein the information about the N time windows is in a one-to-one correspondence with the information about the N second parameters, (¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated);
each second parameter of the N second parameters comprises parameters of data transfer of the first service in a corresponding time window, (¶0002 - BDT policy handling is a functionality that allows an Application Function (AF) to transmit/receive a certain volume of background data traffic per UE or for a number of UEs under some requirements, such as a time window for transfer, specific network conditions, and optionally a network area where the transfer occurs. A Policy Control Function (PCF) can derive a BDT policy that adapts to those requirements. The BDT policy typically may define which QoS and charging control policy are employed within a specific time window for a UE. ¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated);
and the each second parameter comprises at least one of a corresponding delay, a corresponding packet error rate, a corresponding packet loss rate, a corresponding bit rate, or a corresponding guaranteed bit rate (¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated. ¶0069 - In one ore more embodiments of the present invention, one available BDT policy may consist of a recommended BDT time window for the corresponding section of the UE trajectory, a reference to a charging rate for the recommended BDT time window, and optionally a maximum aggregated bitrate indicating that the charging level according to the referenced charging rate is only applicable to the aggregated traffic of all involved UEs that stay below the referenced charging rate).
Re. Claim 30, Azorero and Sachs teach Claim 28.
Yet, Azorero does not explicitly teach the programming instructions, when executed by the at least one processor, further cause the apparatus to: send first indication information, wherein the first indication information indicates whether the information about the each policy is allowed to comprise information about a plurality of time windows.
However, in the analogous art, Sachs explicitly teaches the programming instructions, when executed by the at least one processor, further cause the apparatus to: send first indication information, wherein the first indication information indicates whether the information about the each policy is allowed to comprise information about a plurality of time windows (Fig. 114 & ¶1255 - … a mapping between traffic classes within this TSN stream and QoS flows of the UE can be identified. For each QoS flow (which can correspond to one or multiple traffic classes), a certain QoS requirement can be indicated to the gNB. In some embodiments, this indication to the gNB can include an indicator of a time-window during which a packet of the QoS flow should be guaranteed to be transmitted … In some embodiments, the indication to the gNB can also include a periodicity (or period) of the time window. This can be included, e.g., if the TSN stream comprises multiple transmission events that occur according to a periodic schedule).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Sachs to the teaching of Azorero. The motivation would be because the invention describes enhancing performance in Industrial Internet-of-Things (IIoT) scenarios, including techniques for time-sensitive networking (TSN) and 5G wireless network integration (Abstract, Sachs).
Re. Claim 33, Azorero teaches a method, wherein the method comprises: sending, by an application function network element, information about first time windows and information about first parameters to a policy control function network element, (Fig. 3 & ¶0088 - Step 301: The node for PCF receives, from a node for AF e.g., via a node for Network Exposure Function (NEF), a BDT policy request indicating the BDT for a UE is UE trajectory-relevant. ¶0089 - … the request may include an Application Service Provider (ASP) identifier, volume of data to be transferred for the UE, desired time window for data transfer, an indicator indicating the BDT is UE trajectory-relevant, and UE trajectory of the UE if available);
wherein a first time window of the first time windows is a time window of data transfer of a first service and configured by the application function network element, (¶0002 - BDT policy handling is a functionality that allows an Application Function (AF) to transmit/receive a certain volume of background data traffic per UE or for a number of UEs under some requirements, such as a time window for transfer, specific network conditions, and optionally a network area where the transfer occurs. A Policy Control Function (PCF) can derive a BDT policy that adapts to those requirements. The BDT policy typically may define which QoS and charging control policy are employed within a specific time window for a UE. Please also see ¶0103);
the first parameters comprise parameters of data transfer of the first service in the first time windows, (¶0089 - … the request may include an Application Service Provider (ASP) identifier, volume of data to be transferred for the UE, desired time window for data transfer, an indicator indicating the BDT is UE trajectory-relevant, and UE trajectory of the UE if available);
receiving, by the policy control function network element, the information about the first time windows and the information about the first parameters; (Fig. 3 & ¶0088 - Step 301: The node for PCF receives, from a node for AF e.g., via a node for Network Exposure Function (NEF), a BDT policy request indicating the BDT for a UE is UE trajectory-relevant. ¶0089 - … the request may include an Application Service Provider (ASP) identifier, volume of data to be transferred for the UE, desired time window for data transfer, an indicator indicating the BDT is UE trajectory-relevant, and UE trajectory of the UE if available);
sending, by the policy control function network element, information about M policies of the first service to the application function network element, (Fig. 3 & ¶0095 - Step 307: The node for PCF transmits to the node for AF, e.g. via the NEF, one or more common BDT policies as derived at step 304 or a plurality policy groups as derived at step 305. ¶0110 - If more than one available BDT policies is included in one BDT policy group, an indicator may be accompanied with the BDT policy group, indicating multiple transfer policies for the corresponding section. Moreover, the PCF may transmit UE trajectory-irrelevant BDT policies);
wherein information about each policy of the M policies comprises information about corresponding N time windows, (¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated. ¶0069 - … one available BDT policy may consist of a recommended BDT time window for the corresponding section of the UE trajectory, a reference to a charging rate for the recommended BDT time window, and optionally a maximum aggregated bitrate … );
M and N are positive integers, (Fig. 1 & ¶0081 - Step 102: The node for AF receives, from the node for PCF e.g. via the node for NEF, a plurality of BDT policy groups … associated with or allocated to the UE trajectory of the UE … each of the BDT policy groups is associated with a corresponding section of the UE trajectory and may include one or more available BDT policies. Each available BDT policy defines a time period and a network area associated with the corresponding section, and QoS/charging conditions applied to the time period or the network area. Fig. 3 & ¶0095 - Step 307: The node for PCF transmits to the node for AF, e.g. via the NEF, one or more common BDT policies as derived at step 304 or a plurality policy groups as derived at step 305. ¶0110 - If more than one available BDT policies is included in one BDT policy group, an indicator may be accompanied with the BDT policy group, indicating multiple transfer policies for the corresponding section. Moreover, the PCF may transmit UE trajectory-irrelevant BDT policies. Examiner interprets Azorero allows one or more policies and one time period per policy, thus M is greater than or equal to 1 and N is equal to 1);
the information about the each policy is determined based on the information about the first time windows and the information about the first parameters, (Fig. 3 & ¶0092 - Step 304: The node for PCF derives one or more common BDT policies without considering the UE trajectory. For example, the common BDT policies may rely on the following aspects individually or in combination: network policy, level information in a S-NSSAI and load status estimation for the required time window, network area information, and existing transfer policies. Fig. 5 & ¶0109 - Step 505: The (H-) PCF determines one or more BDT policies based on the information received from the NEF and other available information (e.g. network policy, existing transfer policies, network area information and load status estimation for the desired time window). If the UE trajectory was received and the (H-)PCF supports this functionality, the (H-)PCF may derive BDT policies per trajectory section having respective QoS and charging demands. That is, the (H-)PCF may derive a plurality of BDT policy groups for the UE trajectory, each of which is applicable to one corresponding section … Therefore, the (H-)PCF determines the BDT policies for the sections of the expected or analytic UE trajectory);
and N time windows in one of the M policies of the first service are used to send or receive data of the first service; (¶0076 - For UE controlled xBDT, background data will be transmitted to the UE as part of UE policy … The UE will be responsible for handling MO traffic in accordance with the time interval and location condition in the UE policy. ¶0077 - For network controlled xBDT, the Npcf_UEPolicyControl service may be in charge of updating the UE with the applicable UE Policy per section, based on the time interval and location conditions defined for the corresponding section of the UE trajectory. Moreover, the network (PCF—Npcf_SMPolicyControl) may be responsible for controlling the UE PDU session's QoS/Charging according to the negotiated BDT policy on the section-basis. Fig. 1 & ¶0082 - Step 103: The node for AF determines one applied BDT policy for each of the BDT policy groups … For one BDT policy group including more than one available BDT policies, the node for AF selects one as an applied BDT policy).
and receiving, by the application function network element, the information about the M policies of the first service (Fig. 3 & ¶0095 - Step 307: The node for PCF transmits to the node for AF, e.g. via the NEF, one or more common BDT policies as derived at step 304 or a plurality policy groups as derived at step 305. ¶0110 - If more than one available BDT policies is included in one BDT policy group, an indicator may be accompanied with the BDT policy group, indicating multiple transfer policies for the corresponding section. Moreover, the PCF may transmit UE trajectory-irrelevant BDT policies);
Yet, Azorero does not explicitly teach and a first parameter of the first parameters comprises at least one of a delay, a packet error rate, a packet loss rate, a bit rate, or a guaranteed bit rate;
However, in the analogous art, Sachs explicitly teaches and a first parameter of the first parameters comprises at least one of a delay (Fig. 114 & ¶0774 - The Application Function (AF) in the 5GS might be an option to interface the CNC … The AF then could also accept a time schedule from the CNC and translate it into meaningful parameters for the 5GS to support the time gated queuing happening in the external TSN network. ¶1255 - For each QoS flow (which can correspond to one or multiple traffic classes), a certain QoS requirement can be indicated to the gNB. In some embodiments, this indication to the gNB can include an indicator of a time-window during which a packet of the QoS flow should be guaranteed to be transmitted. This time window can be indicated, e.g., by providing an absolute time reference for the time window start together with a length of the window (e.g., as a latency bound). ¶1257 - after determining the information as discussed above, the AMF sends an indication and/or request the gNB(s) to confirm that the QoS, time window, and/or periodicity requirements can be met. In operation 15, after receiving the request/indication sent in operation 14, the gNB (or gNBs, as the case may be) determines whether it can serve this additional QoS flow with the indicated time-window requirement … In some embodiments, when declining the request, the gNB can indicate an alternative time window ... the gNB can also reserve any additional resources identified as required to meet the requested transmission schedule), a packet error rate, a packet loss rate, a bit rate, or a guaranteed bit rate;
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Sachs to the teaching of Azorero. The motivation would be because the invention describes enhancing performance in Industrial Internet-of-Things (IIoT) scenarios, including techniques for time-sensitive networking (TSN) and 5G wireless network integration (Abstract, Sachs).
Re. Claim 34, Azorero and Sachs teach Claim 33.
Azorero further teaches the method further comprises: sending, by the policy control function network element, information about N second parameters to the application function network element, (Fig. 1-4 (Fig. 3) & ¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated. ¶0069 - In one or more embodiments of the present invention, one available BDT policy may consist of a recommended BDT time window for the corresponding section of the UE trajectory, a reference to a charging rate for the recommended BDT time window, and optionally a maximum aggregated bitrate indicating that the charging level according to the referenced charging rate is only applicable to the aggregated traffic of all involved UEs that stay below the referenced charging rate. ¶0095 - Step 307: The node for PCF transmits to the node for AF, e.g. via the NEF, one or more common BDT policies as derived at step 304 or a plurality policy groups as derived at step 305);
wherein the information about the N time windows is in a one-to-one correspondence with the information about the N second parameters, (¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated);
each second parameter of the N second parameters comprises parameters of data transfer of the first service in a corresponding time window, (¶0002 - BDT policy handling is a functionality that allows an Application Function (AF) to transmit/receive a certain volume of background data traffic per UE or for a number of UEs under some requirements, such as a time window for transfer, specific network conditions, and optionally a network area where the transfer occurs. A Policy Control Function (PCF) can derive a BDT policy that adapts to those requirements. The BDT policy typically may define which QoS and charging control policy are employed within a specific time window for a UE. ¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated);
and the each second parameter comprises at least one of a corresponding delay, a corresponding packet error rate, a corresponding packet loss rate, a corresponding bit rate, or a corresponding guaranteed bit rate; (¶0060 - For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated. ¶0069 - In one ore more embodiments of the present invention, one available BDT policy may consist of a recommended BDT time window for the corresponding section of the UE trajectory, a reference to a charging rate for the recommended BDT time window, and optionally a maximum aggregated bitrate indicating that the charging level according to the referenced charging rate is only applicable to the aggregated traffic of all involved UEs that stay below the referenced charging rate);
and receiving, by the application function network element, the information about the N second parameters (¶0059 - a node for Application Function (AF) and a node for Policy Control Function (PCF) may negotiate BDT policies for one or more UEs. The node for AF may initiate a BDT policy negotiation procedure by transmitting to the node for PCF a BDT policy request. As a response, the node for PCF derives or determines the BDT policies and returns them to the node for AF. See 3GPP TS 23.503 15.5.0, which is incorporated herein by reference in its entirety. Please also see ¶0067 and Fig. 5 & ¶0111).
Re. Claim 35, Azorero and Sachs teach Claim 33.
Azorero further teaches the method further comprises: sending, by the application function network element, first indication information, and receiving, by the policy control function network element, the first indication information (Fig. 1-5 & (Fig. 3) & ¶0088 - Step 301: The node for PCF receives, from a node for AF e.g., via a node for Network Exposure Function (NEF), a BDT policy request indicating the BDT for a UE is UE trajectory-relevant. ¶0089 - the request may include an Application Service Provider (ASP) identifier, volume of data to be transferred for the UE, desired time window for data transfer, an indicator indicating the BDT is UE trajectory-relevant, and UE trajectory of the UE if available. Please also see ¶0063-¶0064, Fig. 5 & ¶0103);
Yet, Azorero does not explicitly teach wherein the first indication information indicates whether the information about the each policy is allowed to comprise information about a plurality of time windows;
However, in the analogous art, Sachs explicitly teaches wherein the first indication information indicates whether the information about the each policy is allowed to comprise information about a plurality of time windows; (Fig. 114 & ¶1255 - … a mapping between traffic classes within this TSN stream and QoS flows of the UE can be identified. For each QoS flow (which can correspond to one or multiple traffic classes), a certain QoS requirement can be indicated to the gNB. In some embodiments, this indication to the gNB can include an indicator of a time-window during which a packet of the QoS flow should be guaranteed to be transmitted … In some embodiments, the indication to the gNB can also include a periodicity (or period) of the time window. This can be included, e.g., if the TSN stream comprises multiple transmission events that occur according to a periodic schedule).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Sachs to the teaching of Azorero. The motivation would be because the invention describes enhancing performance in Industrial Internet-of-Things (IIoT) scenarios, including techniques for time-sensitive networking (TSN) and 5G wireless network integration (Abstract, Sachs).
Claims 24, 31 and 36 are rejected under 35 U.S.C. 103 as being unpatentable over Azorero and Sachs, as applied to Claims 21-23, 28-30 and 33-35 above, and further in view of Xin et al. (US 2023/0058871 A1), Xin hereinafter.
Re. Claims 24, 31 and 36, Azorero and Sachs teach Claims 23, 30 and 35.
Yet, Azorero does not explicitly teach information about one policy comprises the information about the plurality of time windows, and wherein a time interval between any two adjacent time windows in the plurality of time windows is less than or equal to a first threshold.
However, in the analogous art, Sachs explicitly teaches information about one policy comprises the information about the plurality of time windows, (Fig. 114 & ¶1255 - For each QoS flow (which can correspond to one or multiple traffic classes), a certain QoS requirement can be indicated to the gNB. In some embodiments, this indication to the gNB can include an indicator of a time-window during which a packet of the QoS flow should be guaranteed to be transmitted. This time window can be indicated, e.g., by providing an absolute time reference for the time window start together with a length of the window … In some embodiments, the indication to the gNB can also include a periodicity (or period) of the time window. This can be included, e.g., if the TSN stream comprises multiple transmission events that occur according to a periodic schedule);
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Sachs to the teaching of Azorero. The motivation would be because the invention describes enhancing performance in Industrial Internet-of-Things (IIoT) scenarios, including techniques for time-sensitive networking (TSN) and 5G wireless network integration (Abstract, Sachs).
Yet, Azorero and Sachs do not explicitly teach and wherein a time interval between any two adjacent time windows in the plurality of time windows is less than or equal to a first threshold.
However, in the analogous art, Xin explicitly teaches and wherein a time interval between any two adjacent time windows in the plurality of time windows is less than or equal to a first threshold (Fig. 29 & ¶0058 - A Maximum Service Interval field indicates the maximum time between the start time of two successive SPs. ¶0223 - As shown in the figure, the interval of R-TWT1 (the interval between R-TWT1 SPs) should be between the minimum service interval and maximum service interval of SCS2. The figure depicts this interval 286 between R-TWT1 SP 284 and a subsequent R-TWT1 SP 296. ¶0247 - If multiple R-TWTs are scheduled for the traffic transmission of an SCS, then an R-TWT SP should be scheduled for an interval of time set between the minimum service interval and maximum service interval … ).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Xin to the teachings of Azorero and Sachs. The motivation would be because the invention describes an apparatus capable of setting a maximum service interval that defines the maximum time permitted between two service periods of a SCS traffic stream (¶0352, Xin).
Claims 25-27, 32 and 37-40 are rejected under 35 U.S.C. 103 as being unpatentable over Azorero and Sachs, as applied to Claims 21-23, 28-30 and 33-35 above, and further in view of Dao et al. (US 2020/0112907 A1), Dao hereinafter.
Re. Claim 25, Azorero and Sachs teach Claim 21.
Yet, Azorero and Sachs do not explicitly teach the programming instructions, when executed by the at least one processor, further cause the apparatus to: receive a network performance analytics result, wherein the network performance analytics result comprises information about K time windows and information about K fourth parameters, the information about the K time windows is in a one-to-one correspondence with the information about the K fourth parameters, K is a positive integer greater than or equal to N, each fourth parameter of the K fourth parameters comprises parameters of data transfer of the first service in a corresponding time window, and the each fourth parameter of the K fourth parameters comprises at least one of a corresponding delay, a corresponding packet error rate, a corresponding packet loss rate, a corresponding bit rate, or a corresponding guaranteed bit rate.
However, in the analogous art, Dao explicitly teaches the programming instructions, when executed by the at least one processor, further cause the apparatus to: receive a network performance analytics result, (Fig. 7 & ¶0280 - The PCF 205, at operation 730a, may send a request to the NWDAF 105 for Network QoS Data Analytics information. The request sent by the PCF 205 may include one or more of Data Analytics Request ID, UE Route Information, Application QoS Level(s), PDU Session Context information, and PQCNC. ¶0281 - In response to the request for network QoS Data Analytics information, the NWDAF 105, at operation 730b, may send the PCF 205 a response including Network QoS Data Analytics information);
wherein the network performance analytics result comprises information about K time windows and information about K fourth parameters, (¶0281 - The response may also include time period(s) that one or more important QoS parameters are anticipated to drop below the critical threshold of this QoS parameter at the critical road sub-segment(s) with probability greater than or equal to the pre-determined probability threshold, according to the UE travel information. Please also see ¶0121. ¶0122 - the statistics or prediction of network QoS information in each road segment corresponding to the time information, which may be one or more of the following statistical value of each required QoS parameter—average value, minimum value, maximum value, median value, probability of potential QoS change for each required QoS parameter compared with the current value);
the information about the K time windows is in a one-to-one correspondence with the information about the K fourth parameters, (Please see ¶0121-¶0122. ¶0124 - time duration(s)/period(s) and specific locations along the travelling route of UE 101 associated with one or more QoS parameters that may drop below its (or their) corresponding predetermined threshold QoS values with its (or their) corresponding probability larger than or equal to probability threshold(s) (e.g. for the time period of 7:30-8:00 am, on a given road segment, the GFBR may drop below a GFBR threshold of 5 Mbps with 90% probability, and/or below a GFBR threshold of 7 Mbps with 95% probability);
K is a positive integer greater than or equal to N, (¶0043 - For example, analysis of network QoS parameters or statistics of QoS parameters may be provided for … different time periods …);
each fourth parameter of the K fourth parameters comprises parameters of data transfer of the first service in a corresponding time window, (¶0054 - According to embodiments, a UE, AF and/or Application Server (AS) may request or subscribe for Network QoS Information. For that, the UE and/or AF may provide one or more of the following information to the CN: information describing the future location of the UE, mobility speed between two locations and current and/or future values of QoS parameters required by the application (e.g. MFBR, GFBR, PDB, MDBV, Session-AMBR (Aggregate Maximum Bit Rate));
and the each fourth parameter of the K fourth parameters comprises at least one of a corresponding delay, a corresponding packet error rate, a corresponding packet loss rate, a corresponding bit rate, or a corresponding guaranteed bit rate (¶0229 - According to embodiments, the PCF may store Application QoS level(s) and PQCNC. Depending on the application logic, the important QoS parameters may be: ¶0230 - for GBR or delay critical GBR QoS flows, one or more of GFBR, MFBR, MDBV, PDB and PER, and a combination of QoS parameters, such as 5QI; and ¶0231 - for non-GBR QoS flows, one or more of the average bit rate (ABR) and PER, and a combination of QoS parameters, such as 5QI).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Dao to the teachings of Azorero and Sachs. The motivation would be because embodiments of the present invention may analyze the network QoS and/or statistics of QoS parameters using one or more functions such as Network Data Analytics Function (NWDAF) (Abstract, Dao).
Re. Claim 26, Azorero and Sachs teach Claim 21.
Yet, Azorero and Sachs do not explicitly teach the programming instructions, when executed by the at least one processor, further cause the apparatus to: send information about a third parameter, wherein the information about the third parameter comprises a value range of the first parameter.
However, in the analogous art, Dao explicitly teaches the programming instructions, when executed by the at least one processor, further cause the apparatus to: send information about a third parameter, wherein the information about the third parameter comprises a value range of the first parameter (Fig. 7 & ¶0157 - The QoS requirements may include (or consist of) values or ranges of QoS parameters. For example, for remote driving, the QoS requirements may include that GFBR is at least 20 Mbit/s, the MFBR is 25 Mbit/s, or the GFBR is within 20-30 Mbit/s in the UL and/or in the DL. ¶0161 - statistic(s) or prediction of the important QoS parameters (e.g. average value, median value, minimum value, maximum value, or a specific range); ¶0166 - a CP function, such as the UDM, the PCF or the V2XCF, may store Application QoS level(s) and PQCNC. Depending on the application logic, the important QoS parameters may be: ¶0167 - for GBR or delay critical GBR QoS flows, one or more parameters of GFBR, MFBR, MDBV, PDB and PER; ¶0173 - According to embodiments, the NWDAF may provide relevant statistical or predicted network QoS information to the CP-A function, such as SMF. Upon receiving the QoS information, the CP-A function, such as SMF, may send QoS notification to the UE …).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Dao to the teachings of Azorero and Sachs. The motivation would be because embodiments of the present invention may analyze the network QoS and/or statistics of QoS parameters using one or more functions such as Network Data Analytics Function (NWDAF) (Abstract, Dao).
Re. Claim 27, Azorero and Sachs teach Claim 21.
Yet, Azorero and Sachs do not explicitly teach the guaranteed bit rate corresponding to the time window meets at least one of: an average quantity of running access network devices in the time window meeting a first threshold, resource utilization of an access network device in the time window meeting a second threshold, an average bit rate of data transfer in the time window meeting a third threshold, or a maximum bit rate of the data transfer in the time window meeting a fourth threshold.
However, in the analogous art, Dao explicitly teaches the guaranteed bit rate corresponding to the time window meets at least one of:
an average quantity of running access network devices in the time window meeting a first threshold,
resource utilization of an access network device in the time window meeting a second threshold,
an average bit rate of data transfer in the time window meeting a third threshold,
or a maximum bit rate of the data transfer in the time window meeting a fourth threshold (Fig. 7 & ¶0050 - value(s) (statistical or otherwise) of QoS parameter(s) for one or more particular times (e.g. times of day, days of week) … ¶0053 - Some examples of QoS parameters that the application may require specific values for are MFBR, GFBR, PER, PDB, Session Aggregated Maximum Bit Rate (Session-AMBR) and Maximum Data Burst Volume (MDBV). The specific values may be specific threshold levels. ¶0344 - The NWDAF 803 may send a recommendation for QoS parameters to the PCF 205 via the N23 interface. The QoS parameters may include a GBR rate, a MBR rate … ¶0345 - For example, the QoS information may include the MBR at different times of the day …).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Dao to the teachings of Azorero and Sachs. The motivation would be because embodiments of the present invention may analyze the network QoS and/or statistics of QoS parameters using one or more functions such as Network Data Analytics Function (NWDAF) (Abstract, Dao).
Re. Claim 32, Azorero and Sachs teach Claim 28.
Yet, Azorero and Sachs do not explicitly teach the guaranteed bit rate corresponding to the time window meets at least one of: an average quantity of running access network devices in the time window meeting a first threshold, resource utilization of an access network device in the time window meeting a second threshold, an average bit rate of data transfer in the time window meeting a third threshold, or a maximum bit rate of the data transfer in the time window meeting a fourth threshold.
However, in the analogous art, Dao explicitly teaches the guaranteed bit rate corresponding to the time window meets at least one of:
an average quantity of running access network devices in the time window meeting a first threshold,
resource utilization of an access network device in the time window meeting a second threshold,
an average bit rate of data transfer in the time window meeting a third threshold,
or a maximum bit rate of the data transfer in the time window meeting a fourth threshold (Fig. 7 & ¶0050 - value(s) (statistical or otherwise) of QoS parameter(s) for one or more particular times (e.g. times of day, days of week) … ¶0053 - Some examples of QoS parameters that the application may require specific values for are MFBR, GFBR, PER, PDB, Session Aggregated Maximum Bit Rate (Session-AMBR) and Maximum Data Burst Volume (MDBV). The specific values may be specific threshold levels. ¶0344 - The NWDAF 803 may send a recommendation for QoS parameters to the PCF 205 via the N23 interface. The QoS parameters may include a GBR rate, a MBR rate … ¶0345 - For example, the QoS information may include the MBR at different times of the day …).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Dao to the teachings of Azorero and Sachs. The motivation would be because embodiments of the present invention may analyze the network QoS and/or statistics of QoS parameters using one or more functions such as Network Data Analytics Function (NWDAF) (Abstract, Dao).
Re. Claim 37, Azorero and Sachs teach Claim 33.
Yet, Azorero and Sachs do not explicitly teach the method further comprises: receiving, by the policy control function network element, a network performance analytics result from a network data analytics function network element, wherein the network performance analytics result comprises information about K time windows and information about K fourth parameters, the information about the K time windows is in a one-to-one correspondence with the information about the K fourth parameters, K is a positive integer greater than or equal to N, each fourth parameter of the K fourth parameters comprises parameters of data transfer of the first service in a corresponding time window, and the each fourth parameter of the K fourth parameters comprises at least one of a corresponding delay, a corresponding packet error rate, a corresponding packet loss rate, a corresponding bit rate, or a corresponding guaranteed bit rate.
However, in the analogous art, Dao explicitly teaches the method further comprises: receiving, by the policy control function network element, a network performance analytics result from a network data analytics function network element, (Fig. 7 & ¶0280 - The PCF 205, at operation 730a, may send a request to the NWDAF 105 for Network QoS Data Analytics information. The request sent by the PCF 205 may include one or more of Data Analytics Request ID, UE Route Information, Application QoS Level(s), PDU Session Context information, and PQCNC. ¶0281 - In response to the request for network QoS Data Analytics information, the NWDAF 105, at operation 730b, may send the PCF 205 a response including Network QoS Data Analytics information);
wherein the network performance analytics result comprises information about K time windows and information about K fourth parameters, (¶0281 - The response may also include time period(s) that one or more important QoS parameters are anticipated to drop below the critical threshold of this QoS parameter at the critical road sub-segment(s) with probability greater than or equal to the pre-determined probability threshold, according to the UE travel information. Please also see ¶0121. ¶0122 - the statistics or prediction of network QoS information in each road segment corresponding to the time information, which may be one or more of the following statistical value of each required QoS parameter—average value, minimum value, maximum value, median value, probability of potential QoS change for each required QoS parameter compared with the current value);
the information about the K time windows is in a one-to-one correspondence with the information about the K fourth parameters, (Please see ¶0121-¶0122. ¶0124 - time duration(s)/period(s) and specific locations along the travelling route of UE 101 associated with one or more QoS parameters that may drop below its (or their) corresponding predetermined threshold QoS values with its (or their) corresponding probability larger than or equal to probability threshold(s) (e.g. for the time period of 7:30-8:00 am, on a given road segment, the GFBR may drop below a GFBR threshold of 5 Mbps with 90% probability, and/or below a GFBR threshold of 7 Mbps with 95% probability);
K is a positive integer greater than or equal to N, (¶0043 - For example, analysis of network QoS parameters or statistics of QoS parameters may be provided for … different time periods …);
each fourth parameter of the K fourth parameters comprises parameters of data transfer of the first service in a corresponding time window, (¶0054 - According to embodiments, a UE, AF and/or Application Server (AS) may request or subscribe for Network QoS Information. For that, the UE and/or AF may provide one or more of the following information to the CN: information describing the future location of the UE, mobility speed between two locations and current and/or future values of QoS parameters required by the application (e.g. MFBR, GFBR, PDB, MDBV, Session-AMBR (Aggregate Maximum Bit Rate));
and the each fourth parameter of the K fourth parameters comprises at least one of a corresponding delay, a corresponding packet error rate, a corresponding packet loss rate, a corresponding bit rate, or a corresponding guaranteed bit rate (¶0229 - According to embodiments, the PCF may store Application QoS level(s) and PQCNC. Depending on the application logic, the important QoS parameters may be: ¶0230 - for GBR or delay critical GBR QoS flows, one or more of GFBR, MFBR, MDBV, PDB and PER, and a combination of QoS parameters, such as 5QI; and ¶0231 - for non-GBR QoS flows, one or more of the average bit rate (ABR) and PER, and a combination of QoS parameters, such as 5QI).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Dao to the teachings of Azorero and Sachs. The motivation would be because embodiments of the present invention may analyze the network QoS and/or statistics of QoS parameters using one or more functions such as Network Data Analytics Function (NWDAF) (Abstract, Dao).
Re. Claim 38, Azorero and Sachs teach Claim 37.
Yet, Azorero and Sachs do not explicitly teach the method further comprises: sending, by the policy control function network element, information about a third parameter to the network data analytics function network element, wherein the information about the third parameter comprises a value range of the first parameter.
However, in the analogous art, Dao explicitly teaches the method further comprises: sending, by the policy control function network element, information about a third parameter to the network data analytics function network element, wherein the information about the third parameter comprises a value range of the first parameter (Fig. 7 & ¶0157 - The QoS requirements may include (or consist of) values or ranges of QoS parameters. For example, for remote driving, the QoS requirements may include that GFBR is at least 20 Mbit/s, the MFBR is 25 Mbit/s, or the GFBR is within 20-30 Mbit/s in the UL and/or in the DL. ¶0161 - statistic(s) or prediction of the important QoS parameters (e.g. average value, median value, minimum value, maximum value, or a specific range); ¶0166 - a CP function, such as the UDM, the PCF or the V2XCF, may store Application QoS level(s) and PQCNC. Depending on the application logic, the important QoS parameters may be: ¶0167 - for GBR or delay critical GBR QoS flows, one or more parameters of GFBR, MFBR, MDBV, PDB and PER; ¶0173 - According to embodiments, the NWDAF may provide relevant statistical or predicted network QoS information to the CP-A function, such as SMF. Upon receiving the QoS information, the CP-A function, such as SMF, may send QoS notification to the UE …).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Dao to the teachings of Azorero and Sachs. The motivation would be because embodiments of the present invention may analyze the network QoS and/or statistics of QoS parameters using one or more functions such as Network Data Analytics Function (NWDAF) (Abstract, Dao).
Re. Claim 39, Azorero and Sachs teach Claim 33.
Yet, Azorero and Sachs do not explicitly teach the guaranteed bit rate corresponding to the time window meets at least one of: an average quantity of running access network devices in the time window meeting a first threshold, resource utilization of an access network device in the time window meeting a second threshold, an average bit rate of data transfer in the time window meeting a third threshold, or a maximum bit rate of the data transfer in the time window meeting a fourth threshold.
However, in the analogous art, Dao explicitly teaches the guaranteed bit rate corresponding to the time window meets at least one of:
an average quantity of running access network devices in the time window meeting a first threshold,
resource utilization of an access network device in the time window meeting a second threshold,
an average bit rate of data transfer in the time window meeting a third threshold,
or a maximum bit rate of the data transfer in the time window meeting a fourth threshold (Fig. 7 & ¶0050 - value(s) (statistical or otherwise) of QoS parameter(s) for one or more particular times (e.g. times of day, days of week) … ¶0053 - Some examples of QoS parameters that the application may require specific values for are MFBR, GFBR, PER, PDB, Session Aggregated Maximum Bit Rate (Session-AMBR) and Maximum Data Burst Volume (MDBV). The specific values may be specific threshold levels. ¶0344 - The NWDAF 803 may send a recommendation for QoS parameters to the PCF 205 via the N23 interface. The QoS parameters may include a GBR rate, a MBR rate … ¶0345 - For example, the QoS information may include the MBR at different times of the day …).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Dao to the teachings of Azorero and Sachs. The motivation would be because embodiments of the present invention may analyze the network QoS and/or statistics of QoS parameters using one or more functions such as Network Data Analytics Function (NWDAF) (Abstract, Dao).
Re. Claim 40, Azorero and Sachs and Dao teach Claim 37.
Azorero further teaches the method further comprises: determining, by the policy control function network element, the information about the M policies of the first service based on the information about the first time windows, (Fig. 1-5 & ¶0059 - a node for Application Function (AF) and a node for Policy Control Function (PCF) may negotiate BDT policies for one or more UEs. The node for AF may initiate a BDT policy negotiation procedure by transmitting to the node for PCF a BDT policy request. As a response, the node for PCF derives or determines the BDT policies and returns them to the node for AF. See 3GPP TS 23.503 15.5.0, which is incorporated herein by reference in its entirety. ¶0064 - … the BDT policy request at least includes an Application Service Provider (ASP) identifier, volume of data to be transferred for a UE, desired time window for data transfer, and a UE trajectory if available. Please also see ¶0067-¶0069 and Fig. 3 & ¶0092-¶0095 and Fig. 5 & ¶0109);
Yet, Azorero does not explicitly teach the information about the first parameters, and the network performance analytics result.
However, in the analogous art, Sachs explicitly teaches the information about the first parameters, (Fig. 114 & ¶1255 - For each QoS flow (which can correspond to one or multiple traffic classes), a certain QoS requirement can be indicated to the gNB. In some embodiments, this indication to the gNB can include an indicator of a time-window during which a packet of the QoS flow should be guaranteed to be transmitted. This time window can be indicated, e.g., by providing an absolute time reference for the time window start together with a length of the window (e.g., as a latency bound). ¶1257 - after determining the information as discussed above, the AMF sends an indication and/or request the gNB(s) to confirm that the QoS, time window, and/or periodicity requirements can be met. In operation 15, after receiving the request/indication sent in operation 14, the gNB (or gNBs, as the case may be) determines whether it can serve this additional QoS flow with the indicated time-window requirement … In some embodiments, when declining the request, the gNB can indicate an alternative time window ... the gNB can also reserve any additional resources identified as required to meet the requested transmission schedule. Please see ¶1255-¶1257);
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Sachs to the teaching of Azorero. The motivation would be because the invention describes enhancing performance in Industrial Internet-of-Things (IIoT) scenarios, including techniques for time-sensitive networking (TSN) and 5G wireless network integration (Abstract, Sachs).
Yet, Azorero and Sachs do not explicitly teach and the network performance analytics result.
However, in the analogous art, Dao explicitly teaches and the network performance analytics result (Fig. 7 & ¶0280 - The PCF 205, at operation 730a, may send a request to the NWDAF 105 for Network QoS Data Analytics information. The request sent by the PCF 205 may include one or more of Data Analytics Request ID, UE Route Information, Application QoS Level(s), PDU Session Context information, and PQCNC. Please also see ¶0281-¶0282. ¶0299 - The PCF can handle network QoS information request from the UE and AF; store Application QoS Level(s) and Potential QoS Change Notification Control (PQCNC); and/or use network data analytics services of NWDAF to obtain statistical QoS information).
Therefore, it would have been obvious to one of the ordinary skilled in the art before the effective filing date of the claimed invention to add the teaching of Dao to the teachings of Azorero and Sachs. The motivation would be because embodiments of the present invention may analyze the network QoS and/or statistics of QoS parameters using one or more functions such as Network Data Analytics Function (NWDAF) (Abstract, Dao).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Shan (US 2019/0222489 A1) - Please see Abstract and Fig. 1-10.
Iwai et al. (US 2020/0022027 A1) – Please see Abstract and Fig. 1-11.
Xu et al. (WO 2021/046676 A1) – Please see Abstract and Fig. 1-7.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALYSSA WILLIAMS whose telephone number is (571)270-7673. The examiner can normally be reached Mon-Fri 8-5pm. 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, Ayman Abaza can be reached on (571) 270-0422. 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.
/ALYSSA WILLIAMS/Examiner, Art Unit 2465B /AYMAN A ABAZA/Primary Examiner, Art Unit 2465
Prosecution Insights