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 . This Office Action is in response to preliminary amendments filed 08/22/2024. Claims 1, 4-11, 14-17, 19-22, 24, 28, and 34 are pending.
Priority
The applicant’s claim for priority as a U.S. National Stage Patent Application of International Application No. PCT/IB2023/050435, filed 18 January, 2023, which claims priority to European Application No. 22382151.3, filed 23 February, 2022 is acknowledged.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 08/27/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
The drawings are objected to because, in Fig. 9, the items “Data 912” and “Communication Interface 916” are referenced differently in the Specification. See, for example, page 27, line 29: “a communication interface 912” and page 29, line 1: “corresponding data 916”. Fig. 9 should be corrected to match these descriptions in the Specification. In Fig. 9, “Data 912” should read “Data 916” and “Communication Interface 916” should read “Communication Interface 912”.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claims 5, 8, and 14 are objected to because of the following informalities:
claims 5 and 14 recite the limitation “for the aggregated data traffic” which should read “for the aggregated volume of data traffic” as established previously in each respective claim.
in claim 8, the limitation “one or more suggested action” should read “one or more suggested actions” (emphasis added).
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 28 and 34 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 28 claims a network data analytics function, NWDAF, which appears to be directed to device or machine. However, the claim fails to define the components of the NWDAF and therefore the metes and bounds of the NWDAF are not defined. See MPEP § 2106.03 which defines a machine as a “concrete thing, consisting of parts, or of certain devices and combination of devices” (emphasis added). The examiner suggests that the components of the NWDAF be defined to clearly establish this claim as a machine.
Claim 34 claims a user plane function, UPF, which appears to be directed to device or machine. However, the claim fails to define the components of the UPF and therefore the metes and bounds of the UPF are not defined. See MPEP § 2106.03 which defines a machine as a “concrete thing, consisting of parts, or of certain devices and combination of devices” (emphasis added). The examiner suggests that the components of the UPF be defined to clearly establish this claim as a machine.
Claim Rejections - 35 USC § 103
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 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.
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 nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 5-8, 10, 11, 14-17, 19, 24, 28, and 34 are rejected under 35 U.S.C. 103 as being unpatentable over Tian (US 2022/0103435), hereinafter “Tian”, in view of 3GPP TS 29.520 V17.5.0, published 22 December, 2021, hereinafter “TS 29.520”, and further in view of Xin et al. (US 2023/0188424), hereinafter “Xin”.
Regarding claims 1, 28, Tian teaches:
A method for a network data analytics function, NWDAF, of a communication network, or a network data analytics function, NWDAF, configured to operate in a communication network, the method comprising or the NWDAF being further configured to:
receiving, from a user plane function, UPF, of the communication network, a first subscription request for an analytic related to user plane, UP, traffic congestion (see Tian, Fig. 3, pars. [0104-0106]: S301: A requester sends an analysis request to a data analysis network element. Correspondingly, the data analysis network element receives the analysis request from the requester. The requester may be an NF, an AF, or OAM, and see par. [0096]: The NF may include an access and mobility management function (AMF), a session management function (SMF), a policy control function (PCF), unified data management (UDM), a network exposure function (NEF), and a user plane function (UPF), and see par. [0111]: S302: The data analysis network element obtains load data of the target network element based on the analysis request; in this case, the data analysis network element corresponds to a NWDAF and the analysis request corresponds to a request for an analytic related to UP traffic congestion), and
sending the computed analytic to the UPF, in accordance with the first subscription request (see Tian, Fig. 3, pars. [0172-0173]: S304: The data analysis network element sends the analysis result to the requester. Accordingly, the requester receives the analysis result from the data analysis network element).
However, Tian does not teach:
the first subscription request including the following:
an identifier of the analytic;
an identifier of a tunnel between the UPF and a Radio Access Network, RAN, for which the analytic is requested;
identifiers of one or more user equipment, UEs, for which the analytic is requested;
one or more other filtering criteria associated with the analytic;
one or more reporting criteria associated with the analytic;
a time period associated with the analytic; and
a required confidence level for the analytic;
sending, to the UPF, a second subscription request for information related to traffic between the UPF and the RAN, the second subscription request including an event identifier associated with the second subscription request and identifiers of one or more of the following, for which the traffic-related information is requested:
a range of tunnels between the UPF and the RAN node, indicated by a tunnel range identifier or by an identifier of the RAN node;
one or more user equipment, UEs;
one or more applications; and
one or more application types;
receiving the traffic-related information from the UPF, in accordance with the second subscription request;
computing the analytic related to UP traffic congestion, based on the received traffic-related information;
TS 29.520, in the same field of endeavor, teaches:
the first subscription request including the following:
an identifier of the analytic (see TS 29.520, Fig. 4.3.2.2.2-1, section 4.3.2.2.2: The NF service consumer shall send an HTTP GET request on the resource URI "{apiRoot}/nnwdaf-analyticsinfo/v1/analytics" representing the "NWDAF Analytics" (as shown in figure 4.3.2.2.2-1, step 1), to request analytics data according to the query parameter value of the "event-id" attribute; in this case, the event-id attribute corresponds to an identifier of the analytic);
an identifier of a tunnel between the UPF and a Radio Access Network, RAN, for which the analytic is requested (see TS 29.520, Fig. 4.2.2.2.2-1, section 4.2.2.2.2: The NnwdafEventsSubscription data structure provided in the request body shall include: an URI where to receive the requested notifications as "notificationURI" attribute; in this case, the URI for receiving notifications corresponds to an identifier of a tunnel for which the analytic is requested);
identifiers of one or more user equipment, UEs, for which the analytic is requested (see TS 29.520, Fig. 4.3.2.2.2-1, section 4.3.2.2.2: if the feature "UeCommunication" is supported and the event is "UE_COMM", it shall provide: 1) identification of target UE(s) to which the subscription applies by "supis" or "intGroupIds" attribute in the "tgt-ue" attribute);
one or more other filtering criteria associated with the analytic (see TS 29.520, Fig. 4.3.2.2.2-1, section 4.3.2.2.2: event specific filter information in the "event-filter" attribute: a) identification of network area to which the subscription applies via identification of network area by "networkArea" attribute);
one or more reporting criteria associated with the analytic (see TS 29.520, Fig. 4.3.2.2.2-1, section 4.3.2.2.2: in addition, the following information may be provided: common reporting requirement in the "ana-req" attribute as follows: 7) indication of which analytics metadata is requested to be delivered with the response in the "anaMeta" attribute if the feature "Aggregation" is supported; and/or 8) requested values for the analytics metadata information to be used for the generation of the analytics in the "anaMetaInd" attribute if the feature "Aggregation" is supported);
a time period associated with the analytic (see TS 29.520, Fig. 4.3.2.2.2-1, section 4.3.2.2.2: in addition, the following information may be provided: common reporting requirement in the "ana-req" attribute as follows: 1) identification of time window for the requested analytics data applies via identification of date-time(s) in the "startTs" and "endTs" attributes); and
a required confidence level for the analytic (see TS 29.520, Fig. 4.3.2.2.2-1, section 4.3.2.2.2: in addition, the following information may be provided: common reporting requirement in the "ana-req" attribute as follows: 2) preferred level of accuracy of the analytics in "accuracy" attribute; in this case, a level of accuracy corresponds to a confidence level);
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the subscription request of Tian with the specific information of TS 29.520 with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of enabling consumers to request and get specific analytics or context information related to analytics (see TS 29.520, section 4.1).
However, the combination of Tian in view of TS 29.520 does not teach:
sending, to the UPF, a second subscription request for information related to traffic between the UPF and the RAN, the second subscription request including an event identifier associated with the second subscription request and identifiers of one or more of the following, for which the traffic-related information is requested:
a range of tunnels between the UPF and the RAN node, indicated by a tunnel range identifier or by an identifier of the RAN node;
one or more user equipment, UEs;
one or more applications; and
one or more application types;
receiving the traffic-related information from the UPF, in accordance with the second subscription request;
computing the analytic related to UP traffic congestion, based on the received traffic-related information;
Xin, in the same field of endeavor, teaches:
sending, to the UPF, a second subscription request for information related to traffic between the UPF and the RAN, the second subscription request including an event identifier associated with the second subscription request (see Xin, Fig. 4, pars. [0217-0219]: S03a. The NWDAF 2 triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the SMF/UPF, and subscribes to traffic information from the NWDAF 2, where the Nsmf is a service interface of the SMF, and the service operation includes an event identifier (Event ID, for example, traffic information Traffic Info) and event filtering information (Event Filter, for example, application identifier App ID, S-NSSAI, DNN, and area of interest). The traffic information is ultimately from the UPF. Therefore, the NWDAF 2 obtains the traffic information in two manners: Manner 1: The NWDAF 2 performs subscription from the SMF through the Nsmf interface, and the SMF performs subscription from the UPF through an N4 interface. Manner 2: The NWDAF 2 performs subscription from the UPF through an Nupf interface) and identifiers of one or more of the following, for which the traffic-related information is requested:
a range of tunnels between the UPF and the RAN node, indicated by a tunnel range identifier or by an identifier of the RAN node (optional limitation);
one or more user equipment, UEs (optional limitation);
one or more applications (see Xin, par. [0220]: The event filter is generated when the NWDAF determines to collect data from the UPF. Then, in a process of subscribing to data from the UPF, the NWDAF sends the event filter to the UPF. The UPF installs the event filter locally and collects data based on a filter condition of the event filter. For example, the event filter may specify a filter condition corresponding to traffic information that needs to be reported by the UPF, such as an App ID, an S-NSSAI, a DNN, and a network area); and
one or more application types (optional limitation);
receiving the traffic-related information from the UPF, in accordance with the second subscription request (see Xin, Fig. 4, pars. [0221-0223]: S03b. The SMF/UPF triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the NWDAF 2, to send the traffic information to the SMF/UPF. For the traffic information, refer to Table 1. For the two different data subscription manners in S03a, the UPF may provide the traffic information to the NWDAF 2 in the following two manners. Manner 1: The UPF provides the traffic information to the SMF through the N4 interface, and the SMF provides the traffic information to the NWDAF 2 through the Nsmf interface. This manner is only for the subscription manner 1 in step S03a. Manner 2: The UPF directly provides the traffic information to the NWDAF 2 through the Nupf interface. This manner may be for the subscription manner 1 in step S03a, and may be for the subscription manner 2 in step S03a);
computing the analytic related to UP traffic congestion, based on the received traffic-related information (see Xin, par. [0244]: It can be learned from the foregoing example descriptions that the NWDAF determines, based on the historical PFD information and the traffic information on the corresponding UPF, the traffic dataset corresponding to the App ID, and may further determine the traffic characteristic of the App ID or train the application type identification model; in this case, determining traffic dataset information and traffic characteristic information corresponds to computing the analytic);
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or NWDAF of the combination of Tian in view of TS 29.520 with the additional signaling of Xin with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving an application analytics success rate (see Xin, par. [0008]).
Regarding claim 5, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method.
The combination of Tian in view of TS 29.520 does not teach, but Xin teaches:
wherein the traffic-related information received from the UPF includes the following:
aggregated volume of data traffic carried over the range of tunnels (see Xin, Fig. 4, pars. [0221-0223]: S03b. The SMF/UPF triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the NWDAF 2, to send the traffic information to the SMF/UPF. For the traffic information, refer to Table 1. For the two different data subscription manners in S03a, the UPF may provide the traffic information to the NWDAF 2 in the following two manners. Manner 1: The UPF provides the traffic information to the SMF through the N4 interface, and the SMF provides the traffic information to the NWDAF 2 through the Nsmf interface. This manner is only for the subscription manner 1 in step S03a. Manner 2: The UPF directly provides the traffic information to the NWDAF 2 through the Nupf interface. This manner may be for the subscription manner 1 in step S03a, and may be for the subscription manner 2 in step S03a, and see Table 1: Data volume, Traffic volume (uplink(UL)/downlink (DL)));
one or more key performance indicators, KPIs, for the aggregated data traffic carried over the range of tunnels (see Xin, Fig. 4, pars. [0221-0223]: S03b. The SMF/UPF triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the NWDAF 2, to send the traffic information to the SMF/UPF. For the traffic information, refer to Table 1. For the two different data subscription manners in S03a, the UPF may provide the traffic information to the NWDAF 2 in the following two manners. Manner 1: The UPF provides the traffic information to the SMF through the N4 interface, and the SMF provides the traffic information to the NWDAF 2 through the Nsmf interface. This manner is only for the subscription manner 1 in step S03a. Manner 2: The UPF directly provides the traffic information to the NWDAF 2 through the Nupf interface. This manner may be for the subscription manner 1 in step S03a, and may be for the subscription manner 2 in step S03a, and see Table 1: Data duration, Traffic duration (UL/DL); in this case, at least data duration and traffic duration correspond to KPIs); and
one or more of the following information associated with respective data flows carried over the range of tunnels: an identifier of a UE, an identifier of an application, flow data volume, flow start and stop times, flow duration, number of packets, average packet size, and other flow information relevant to congestion (see Xin, Fig. 4, pars. [0221-0223]: S03b. The SMF/UPF triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the NWDAF 2, to send the traffic information to the SMF/UPF. For the traffic information, refer to Table 1. For the two different data subscription manners in S03a, the UPF may provide the traffic information to the NWDAF 2 in the following two manners. Manner 1: The UPF provides the traffic information to the SMF through the N4 interface, and the SMF provides the traffic information to the NWDAF 2 through the Nsmf interface. This manner is only for the subscription manner 1 in step S03a. Manner 2: The UPF directly provides the traffic information to the NWDAF 2 through the Nupf interface. This manner may be for the subscription manner 1 in step S03a, and may be for the subscription manner 2 in step S03a, and see Table 1: Terminal identifier SUPI, Start/End time point, Data duration, Quantity of transmitted packets).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or NWDAF of the combination of Tian in view of TS 29.520 with the specific traffic-related information of Xin with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving an application analytics success rate (see Xin, par. [0008]).
Regarding claim 6, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method. Tian further teaches:
wherein one or more of the following applies:
the analytic is a congestion level (see Tian, par. [0113]: the load data includes the service load information. The service load information at least includes at least one of a service load, an upper limit of the service load, or a ratio of the service load. For example, the service load information may include any one of the service load, the upper limit of the service load, and the ratio of the service load, may include any two of the service load, the upper limit of the service load, and the ratio of the service load, or may include the service load, the upper limit of the service load, and the ratio of the service load)
The combination of Tian in view of TS 29.520 does not teach, but Xin teaches:
wherein one or more of the following applies:
the one or more KPIs include round trip time, RTT (see Xin, Fig. 4, pars. [0221-0223]: S03b. The SMF/UPF triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the NWDAF 2, to send the traffic information to the SMF/UPF. For the traffic information, refer to Table 1. For the two different data subscription manners in S03a, the UPF may provide the traffic information to the NWDAF 2 in the following two manners. Manner 1: The UPF provides the traffic information to the SMF through the N4 interface, and the SMF provides the traffic information to the NWDAF 2 through the Nsmf interface. This manner is only for the subscription manner 1 in step S03a. Manner 2: The UPF directly provides the traffic information to the NWDAF 2 through the Nupf interface. This manner may be for the subscription manner 1 in step S03a, and may be for the subscription manner 2 in step S03a, and see Table 1: Data duration, Traffic duration (UL/DL));
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or NWDAF of the combination of Tian in view of TS 29.520 with the specific information of Xin with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving an application analytics success rate (see Xin, par. [0008]).
Regarding claim 7, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method.
Tian does not teach, but TS 29.520 teaches:
wherein the congestion level is sent to the UPF according to one of the following:
based on the congestion level exceeding a reporting threshold identified in the first subscription request; or
periodically, according to a reporting period identified in the first subscription request (see TS 29.520, section 4.3.2.2.2: If the HTTP request message from the NF service consumer is accepted, the NWDAF shall respond with "200 OK" status code with the message body containing the analytics with parameters as relevant for the requesting NF service consumer. The AnalyticsData data structure in the response body shall include: analytics with the corresponding information as described in subclause 4.2.2.4.2, and see section 4.2.2.4.2: The NWDAF shall invoke the Nnwdaf_EventsSubscription_Notify service operation to notify the subscribed event. The NWDAF shall send an HTTP POST request with "{notificationURI}" received in the Nnwdaf_EventsSubscription_Subscribe service operation as Resource URI, as shown in figure 4.2.2.4.2-1, step 1. If both the "repPeriod" attribute and the "offsetPeriod" attribute are present in the subscription request for periodical notification, the NWDAF shall produce a notification every repPeriod seconds, including the statistics in the past offset period if the "offsetPeriod" attribute value is negative, or including the prediction for the future offset period if the "offsetPeriod" attribute value is positive).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the subscription request of Tian with the specific information of TS 29.520 with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of enabling consumers to request and get specific analytics or context information related to analytics (see TS 29.520, section 4.1).
Regarding claim 8, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method. Tian further teaches:
wherein the congestion level is sent to the UPF together with one or more of the following:
one or more suggested action for the UPF, based on the congestion level (optional limitation);
one or more KPIs associated with the congestion level (see Tian, par. [0166]: the data analysis network element can provide the load analysis result for the requester, for example, the average value or the peak value of the service load information, so that the requester selects the network element with the relatively low load based on the load analysis result. When the analysis result is an analysis result of the target network element in the slice corresponding to the information about the network slice, because impact of different network slices on the target network element is considered in the analysis result, accuracy of the analysis result is higher. When the analysis result is an analysis result of the target network element under different service types and service load ratios, because impact of the different service types on the target network element is fully considered in the analysis result, accuracy of the analysis result is higher; in this case, load information included in the load analysis result corresponds to KPIs associated with the congestion level);
one or more statistics for user data sessions (optional limitation);
identifiers of active ones of the UEs identified in the first subscription request (optional limitation); and
level of confidence associated with the congestion level (optional limitation).
Regarding claim 10, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method.
The combination of Tian in view of TS 29.520 does not teach, but Xin teaches:
wherein: multiple reports of traffic-related information are received from the UPF in accordance with the second subscription request (see Xin, Fig. 4, pars. [0221-0223]: S03b. The SMF/UPF triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the NWDAF 2, to send the traffic information to the SMF/UPF. For the traffic information, refer to Table 1. For the two different data subscription manners in S03a, the UPF may provide the traffic information to the NWDAF 2 in the following two manners. Manner 1: The UPF provides the traffic information to the SMF through the N4 interface, and the SMF provides the traffic information to the NWDAF 2 through the Nsmf interface. This manner is only for the subscription manner 1 in step S03a. Manner 2: The UPF directly provides the traffic information to the NWDAF 2 through the Nupf interface. This manner may be for the subscription manner 1 in step S03a, and may be for the subscription manner 2 in step S03a, and par. [0202]: it is assumed that service identification needs to be performed on three services (a service 1, a service 2, and a service 3). The NWDAF 1 may collect traffic information corresponding to the three services (refer to Table 1 below) and traffic information corresponding to another service. In this way, the NWDAF 1 may obtain training data, and see Table 1; in this case, traffic information is collected and communicated for multiple services (i.e. multiple reports));
each report includes an aggregated volume of data traffic carried over the range of tunnels (see Xin, Fig. 4, pars. [0221-0223]: S03b. The SMF/UPF triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the NWDAF 2, to send the traffic information to the SMF/UPF. For the traffic information, refer to Table 1. For the two different data subscription manners in S03a, the UPF may provide the traffic information to the NWDAF 2 in the following two manners. Manner 1: The UPF provides the traffic information to the SMF through the N4 interface, and the SMF provides the traffic information to the NWDAF 2 through the Nsmf interface. This manner is only for the subscription manner 1 in step S03a. Manner 2: The UPF directly provides the traffic information to the NWDAF 2 through the Nupf interface. This manner may be for the subscription manner 1 in step S03a, and may be for the subscription manner 2 in step S03a, and see Table 1: Data volume, Traffic volume (uplink(UL)/downlink (DL))); and
computing the analytic comprises determining a congestion level based on variations in the reported aggregate volumes of data traffic (see Xin, par. [0236]: the NWDAF 2 may further use an unsupervised learning method (for example, K-means) in a process of determining the traffic characteristic of each service. For example, for a training dataset corresponding to the App ID 1, the NWDAF 2 clusters the training dataset into K clusters by using the K-means algorithm, and the NWDAF 2 uses a centroid of a cluster that includes a largest quantity of sample data in the K clusters as the traffic characteristic corresponding to the App ID 1, and see par. [0244]: It can be learned from the foregoing example descriptions that the NWDAF determines, based on the historical PFD information and the traffic information on the corresponding UPF, the traffic dataset corresponding to the App ID, and may further determine the traffic characteristic of the App ID or train the application type identification model).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or NWDAF of the combination of Tian in view of TS 29.520 with the additional signaling of Xin with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving an application analytics success rate (see Xin, par. [0008]).
Regarding claims 11, 34, Tian teaches:
A method for a user plane function, UPF, of a communication network, or a user plane function, UPF, configured to operate in a communication network, the method comprising or the UPF being further configured to:
sending, to a network data analytics function, NWDAF, of the communication network, a first subscription request for an analytic related to user plane, UP, traffic congestion (see Tian, Fig. 3, pars. [0104-0106]: S301: A requester sends an analysis request to a data analysis network element. Correspondingly, the data analysis network element receives the analysis request from the requester. The requester may be an NF, an AF, or OAM, and see par. [0096]: The NF may include an access and mobility management function (AMF), a session management function (SMF), a policy control function (PCF), unified data management (UDM), a network exposure function (NEF), and a user plane function (UPF), and see par. [0111]: S302: The data analysis network element obtains load data of the target network element based on the analysis request; in this case, the data analysis network element corresponds to a NWDAF and the analysis request corresponds to a request for an analytic related to UP traffic congestion), and
receiving the analytic from the NWDAF, in accordance with the first subscription request (see Tian, Fig. 3, pars. [0172-0173]: S304: The data analysis network element sends the analysis result to the requester. Accordingly, the requester receives the analysis result from the data analysis network element).
However, Tian does not teach:
the first subscription request including the following:
an identifier of the analytic;
an identifier of a tunnel between the UPF and a Radio Access Network, RAN, for which the analytic is requested;
identifiers of one or more user equipment, UEs, for which the analytic is requested;
one or more other filtering criteria associated with the analytic;
one or more reporting criteria associated with the analytic;
a time period associated with the analytic; and
a required confidence level for the analytic;
receiving, from the NWDAF, a second subscription request for information related to traffic between the UPF and RAN, the second subscription request including an event identifier associated with the second subscription request and identifiers of one or more of the following, for which the traffic-related information is requested:
a range of tunnels between the UPF and the RAN node, indicated by a tunnel range identifier or by an identifier of the RAN node;
one or more user equipment, UEs;
one or more applications; and
one or more application types;
sending the traffic-related information to the NWDAF, in accordance with the second subscription request;
TS 29.520, in the same field of endeavor, teaches:
the first subscription request including the following:
an identifier of the analytic (see TS 29.520, Fig. 4.3.2.2.2-1, section 4.3.2.2.2: The NF service consumer shall send an HTTP GET request on the resource URI "{apiRoot}/nnwdaf-analyticsinfo/v1/analytics" representing the "NWDAF Analytics" (as shown in figure 4.3.2.2.2-1, step 1), to request analytics data according to the query parameter value of the "event-id" attribute; in this case, the event-id attribute corresponds to an identifier of the analytic);
an identifier of a tunnel between the UPF and a Radio Access Network, RAN, for which the analytic is requested (see TS 29.520, Fig. 4.2.2.2.2-1, section 4.2.2.2.2: The NnwdafEventsSubscription data structure provided in the request body shall include: an URI where to receive the requested notifications as "notificationURI" attribute; in this case, the URI for receiving notifications corresponds to an identifier of a tunnel for which the analytic is requested);
identifiers of one or more user equipment, UEs, for which the analytic is requested (see TS 29.520, Fig. 4.3.2.2.2-1, section 4.3.2.2.2: if the feature "UeCommunication" is supported and the event is "UE_COMM", it shall provide: 1) identification of target UE(s) to which the subscription applies by "supis" or "intGroupIds" attribute in the "tgt-ue" attribute);
one or more other filtering criteria associated with the analytic (see TS 29.520, Fig. 4.3.2.2.2-1, section 4.3.2.2.2: event specific filter information in the "event-filter" attribute: a) identification of network area to which the subscription applies via identification of network area by "networkArea" attribute);
one or more reporting criteria associated with the analytic (see TS 29.520, Fig. 4.3.2.2.2-1, section 4.3.2.2.2: in addition, the following information may be provided: common reporting requirement in the "ana-req" attribute as follows: 7) indication of which analytics metadata is requested to be delivered with the response in the "anaMeta" attribute if the feature "Aggregation" is supported; and/or 8) requested values for the analytics metadata information to be used for the generation of the analytics in the "anaMetaInd" attribute if the feature "Aggregation" is supported);
a time period associated with the analytic (see TS 29.520, Fig. 4.3.2.2.2-1, section 4.3.2.2.2: in addition, the following information may be provided: common reporting requirement in the "ana-req" attribute as follows: 1) identification of time window for the requested analytics data applies via identification of date-time(s) in the "startTs" and "endTs" attributes); and
a required confidence level for the analytic (see TS 29.520, Fig. 4.3.2.2.2-1, section 4.3.2.2.2: in addition, the following information may be provided: common reporting requirement in the "ana-req" attribute as follows: 2) preferred level of accuracy of the analytics in "accuracy" attribute; in this case, a level of accuracy corresponds to a confidence level);
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the subscription request of Tian with the specific information of TS 29.520 with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of enabling consumers to request and get specific analytics or context information related to analytics (see TS 29.520, section 4.1).
However, the combination of Tian in view of TS 29.520 does not teach:
receiving, from the NWDAF, a second subscription request for information related to traffic between the UPF and RAN, the second subscription request including an event identifier associated with the second subscription request and identifiers of one or more of the following, for which the traffic-related information is requested:
a range of tunnels between the UPF and the RAN node, indicated by a tunnel range identifier or by an identifier of the RAN node;
one or more user equipment, UEs;
one or more applications; and
one or more application types;
sending the traffic-related information to the NWDAF, in accordance with the second subscription request;
Xin, in the same field of endeavor, teaches:
receiving, from the NWDAF, a second subscription request for information related to traffic between the UPF and RAN, the second subscription request including an event identifier associated with the second subscription request (see Xin, Fig. 4, pars. [0217-0219]: S03a. The NWDAF 2 triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the SMF/UPF, and subscribes to traffic information from the NWDAF 2, where the Nsmf is a service interface of the SMF, and the service operation includes an event identifier (Event ID, for example, traffic information Traffic Info) and event filtering information (Event Filter, for example, application identifier App ID, S-NSSAI, DNN, and area of interest). The traffic information is ultimately from the UPF. Therefore, the NWDAF 2 obtains the traffic information in two manners: Manner 1: The NWDAF 2 performs subscription from the SMF through the Nsmf interface, and the SMF performs subscription from the UPF through an N4 interface. Manner 2: The NWDAF 2 performs subscription from the UPF through an Nupf interface) and identifiers of one or more of the following, for which the traffic-related information is requested:
a range of tunnels between the UPF and the RAN node, indicated by a tunnel range identifier or by an identifier of the RAN node (optional limitation);
one or more user equipment, UEs (optional limitation);
one or more applications (see Xin, par. [0220]: The event filter is generated when the NWDAF determines to collect data from the UPF. Then, in a process of subscribing to data from the UPF, the NWDAF sends the event filter to the UPF. The UPF installs the event filter locally and collects data based on a filter condition of the event filter. For example, the event filter may specify a filter condition corresponding to traffic information that needs to be reported by the UPF, such as an App ID, an S-NSSAI, a DNN, and a network area); and
one or more application types (optional limitation);
sending the traffic-related information to the NWDAF, in accordance with the second subscription request (see Xin, Fig. 4, pars. [0221-0223]: S03b. The SMF/UPF triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the NWDAF 2, to send the traffic information to the SMF/UPF. For the traffic information, refer to Table 1. For the two different data subscription manners in S03a, the UPF may provide the traffic information to the NWDAF 2 in the following two manners. Manner 1: The UPF provides the traffic information to the SMF through the N4 interface, and the SMF provides the traffic information to the NWDAF 2 through the Nsmf interface. This manner is only for the subscription manner 1 in step S03a. Manner 2: The UPF directly provides the traffic information to the NWDAF 2 through the Nupf interface. This manner may be for the subscription manner 1 in step S03a, and may be for the subscription manner 2 in step S03a);
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or NWDAF of the combination of Tian in view of TS 29.520 with the additional signaling of Xin with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving an application analytics success rate (see Xin, par. [0008]).
Regarding claim 14, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method.
The combination of Tian in view of TS 29.520 does not teach, but Xin teaches:
wherein the traffic-related information received from the UPF includes one or more of the following:
aggregated volume of data traffic carried over the range of tunnels (see Xin, Fig. 4, pars. [0221-0223]: S03b. The SMF/UPF triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the NWDAF 2, to send the traffic information to the SMF/UPF. For the traffic information, refer to Table 1. For the two different data subscription manners in S03a, the UPF may provide the traffic information to the NWDAF 2 in the following two manners. Manner 1: The UPF provides the traffic information to the SMF through the N4 interface, and the SMF provides the traffic information to the NWDAF 2 through the Nsmf interface. This manner is only for the subscription manner 1 in step S03a. Manner 2: The UPF directly provides the traffic information to the NWDAF 2 through the Nupf interface. This manner may be for the subscription manner 1 in step S03a, and may be for the subscription manner 2 in step S03a, and see Table 1: Data volume, Traffic volume (uplink(UL)/downlink (DL)));
one or more key performance indicators, KPIs, for the aggregated data traffic carried over the range of tunnels (see Xin, Fig. 4, pars. [0221-0223]: S03b. The SMF/UPF triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the NWDAF 2, to send the traffic information to the SMF/UPF. For the traffic information, refer to Table 1. For the two different data subscription manners in S03a, the UPF may provide the traffic information to the NWDAF 2 in the following two manners. Manner 1: The UPF provides the traffic information to the SMF through the N4 interface, and the SMF provides the traffic information to the NWDAF 2 through the Nsmf interface. This manner is only for the subscription manner 1 in step S03a. Manner 2: The UPF directly provides the traffic information to the NWDAF 2 through the Nupf interface. This manner may be for the subscription manner 1 in step S03a, and may be for the subscription manner 2 in step S03a, and see Table 1: Data duration, Traffic duration (UL/DL); in this case, at least data duration and traffic duration correspond to KPIs); and
one or more of the following information associated with respective data flows carried over the range of tunnels: an identifier of a UE, an identifier of an application, flow data volume, flow start and stop times, flow duration, number of packets, average packet size, and other flow information relevant to congestion (see Xin, Fig. 4, pars. [0221-0223]: S03b. The SMF/UPF triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the NWDAF 2, to send the traffic information to the SMF/UPF. For the traffic information, refer to Table 1. For the two different data subscription manners in S03a, the UPF may provide the traffic information to the NWDAF 2 in the following two manners. Manner 1: The UPF provides the traffic information to the SMF through the N4 interface, and the SMF provides the traffic information to the NWDAF 2 through the Nsmf interface. This manner is only for the subscription manner 1 in step S03a. Manner 2: The UPF directly provides the traffic information to the NWDAF 2 through the Nupf interface. This manner may be for the subscription manner 1 in step S03a, and may be for the subscription manner 2 in step S03a, and see Table 1: Terminal identifier SUPI, Start/End time point, Data duration, Quantity of transmitted packets).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or NWDAF of the combination of Tian in view of TS 29.520 with the specific traffic-related information of Xin with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving an application analytics success rate (see Xin, par. [0008]).
Regarding claim 15, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method. Tian further teaches:
wherein one or more of the following applies:
the analytic is a congestion level (see Tian, par. [0113]: the load data includes the service load information. The service load information at least includes at least one of a service load, an upper limit of the service load, or a ratio of the service load. For example, the service load information may include any one of the service load, the upper limit of the service load, and the ratio of the service load, may include any two of the service load, the upper limit of the service load, and the ratio of the service load, or may include the service load, the upper limit of the service load, and the ratio of the service load)
The combination of Tian in view of TS 29.520 does not teach, but Xin teaches:
wherein one or more of the following applies:
the one or more KPIs include round trip time, RTT (see Xin, Fig. 4, pars. [0221-0223]: S03b. The SMF/UPF triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the NWDAF 2, to send the traffic information to the SMF/UPF. For the traffic information, refer to Table 1. For the two different data subscription manners in S03a, the UPF may provide the traffic information to the NWDAF 2 in the following two manners. Manner 1: The UPF provides the traffic information to the SMF through the N4 interface, and the SMF provides the traffic information to the NWDAF 2 through the Nsmf interface. This manner is only for the subscription manner 1 in step S03a. Manner 2: The UPF directly provides the traffic information to the NWDAF 2 through the Nupf interface. This manner may be for the subscription manner 1 in step S03a, and may be for the subscription manner 2 in step S03a, and see Table 1: Data duration, Traffic duration (UL/DL));
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or NWDAF of the combination of Tian in view of TS 29.520 with the specific information of Xin with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving an application analytics success rate (see Xin, par. [0008]).
Regarding claim 16, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method.
Tian does not teach, but TS 29.520 teaches:
wherein the congestion level is received from the NWDAF according to one of the following:
based on the congestion level exceeding a reporting threshold identified in the first subscription request; or
periodically, according to a reporting period identified in the first subscription request (see TS 29.520, section 4.3.2.2.2: If the HTTP request message from the NF service consumer is accepted, the NWDAF shall respond with "200 OK" status code with the message body containing the analytics with parameters as relevant for the requesting NF service consumer. The AnalyticsData data structure in the response body shall include: analytics with the corresponding information as described in subclause 4.2.2.4.2, and see section 4.2.2.4.2: The NWDAF shall invoke the Nnwdaf_EventsSubscription_Notify service operation to notify the subscribed event. The NWDAF shall send an HTTP POST request with "{notificationURI}" received in the Nnwdaf_EventsSubscription_Subscribe service operation as Resource URI, as shown in figure 4.2.2.4.2-1, step 1. If both the "repPeriod" attribute and the "offsetPeriod" attribute are present in the subscription request for periodical notification, the NWDAF shall produce a notification every repPeriod seconds, including the statistics in the past offset period if the "offsetPeriod" attribute value is negative, or including the prediction for the future offset period if the "offsetPeriod" attribute value is positive).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the subscription request of Tian with the specific information of TS 29.520 with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of enabling consumers to request and get specific analytics or context information related to analytics (see TS 29.520, section 4.1).
Regarding claim 17, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method. Tian further teaches:
wherein the congestion level is received from the NWDAF together with one or more of the following:
one or more suggested actions for the UPF, based on the congestion level (optional limitation);
one or more KPIs associated with the congestion level (see Tian, par. [0166]: the data analysis network element can provide the load analysis result for the requester, for example, the average value or the peak value of the service load information, so that the requester selects the network element with the relatively low load based on the load analysis result. When the analysis result is an analysis result of the target network element in the slice corresponding to the information about the network slice, because impact of different network slices on the target network element is considered in the analysis result, accuracy of the analysis result is higher. When the analysis result is an analysis result of the target network element under different service types and service load ratios, because impact of the different service types on the target network element is fully considered in the analysis result, accuracy of the analysis result is higher; in this case, load information included in the load analysis result corresponds to KPIs associated with the congestion level);
one or more statistics for user data sessions (optional limitation);
identifiers of active ones of the UEs identified in the first subscription request (optional limitation); and
level of confidence associated with the congestion level (optional limitation).
Regarding claim 19, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method.
The combination of Tian in view of TS 29.520 does not teach, but Xin teaches:
wherein: the multiple reports of traffic-related information are sent to the NWDAF in accordance with the second subscription request (see Xin, Fig. 4, pars. [0221-0223]: S03b. The SMF/UPF triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the NWDAF 2, to send the traffic information to the SMF/UPF. For the traffic information, refer to Table 1. For the two different data subscription manners in S03a, the UPF may provide the traffic information to the NWDAF 2 in the following two manners. Manner 1: The UPF provides the traffic information to the SMF through the N4 interface, and the SMF provides the traffic information to the NWDAF 2 through the Nsmf interface. This manner is only for the subscription manner 1 in step S03a. Manner 2: The UPF directly provides the traffic information to the NWDAF 2 through the Nupf interface. This manner may be for the subscription manner 1 in step S03a, and may be for the subscription manner 2 in step S03a, and par. [0202]: it is assumed that service identification needs to be performed on three services (a service 1, a service 2, and a service 3). The NWDAF 1 may collect traffic information corresponding to the three services (refer to Table 1 below) and traffic information corresponding to another service. In this way, the NWDAF 1 may obtain training data, and see Table 1; in this case, traffic information is collected and communicated for multiple services (i.e. multiple reports));
each report includes an aggregated volume of data traffic carried over the range of tunnels (see Xin, Fig. 4, pars. [0221-0223]: S03b. The SMF/UPF triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the NWDAF 2, to send the traffic information to the SMF/UPF. For the traffic information, refer to Table 1. For the two different data subscription manners in S03a, the UPF may provide the traffic information to the NWDAF 2 in the following two manners. Manner 1: The UPF provides the traffic information to the SMF through the N4 interface, and the SMF provides the traffic information to the NWDAF 2 through the Nsmf interface. This manner is only for the subscription manner 1 in step S03a. Manner 2: The UPF directly provides the traffic information to the NWDAF 2 through the Nupf interface. This manner may be for the subscription manner 1 in step S03a, and may be for the subscription manner 2 in step S03a, and see Table 1: Data volume, Traffic volume (uplink(UL)/downlink (DL))); and
the congestion level is based on variations in the reported aggregate volumes of data traffic (see Xin, par. [0236]: the NWDAF 2 may further use an unsupervised learning method (for example, K-means) in a process of determining the traffic characteristic of each service. For example, for a training dataset corresponding to the App ID 1, the NWDAF 2 clusters the training dataset into K clusters by using the K-means algorithm, and the NWDAF 2 uses a centroid of a cluster that includes a largest quantity of sample data in the K clusters as the traffic characteristic corresponding to the App ID 1, and see par. [0244]: It can be learned from the foregoing example descriptions that the NWDAF determines, based on the historical PFD information and the traffic information on the corresponding UPF, the traffic dataset corresponding to the App ID, and may further determine the traffic characteristic of the App ID or train the application type identification model).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or NWDAF of the combination of Tian in view of TS 29.520 with the additional signaling of Xin with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving an application analytics success rate (see Xin, par. [0008]).
Regarding claim 24, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method.
The combination of Tian in view of TS 29.520 does not teach, but Xin teaches:
further comprising initiating collection of the traffic-related information based on detecting data traffic corresponding to the second subscription request (see Xin, par. [0179]: The NWDAF is configured to obtain first traffic information from the UPF. For example, the UPF may be the foregoing third network element, the first traffic information may be the foregoing second data, and the first traffic information includes the IP 3-tuple and historical service traffic data. The traffic data includes a data volume, data duration, a quantity of transmitted data packets, and the like, and see Fig. 4, pars. [0217-0219]: S03a. The NWDAF 2 triggers an SMF/UPF capability exposure subscription service Nsmf/upf_EventExposure_Subscribe to the SMF/UPF, and subscribes to traffic information from the NWDAF 2, where the Nsmf is a service interface of the SMF, and the service operation includes an event identifier (Event ID, for example, traffic information Traffic Info) and event filtering information (Event Filter, for example, application identifier App ID, S-NSSAI, DNN, and area of interest). The traffic information is ultimately from the UPF. Therefore, the NWDAF 2 obtains the traffic information in two manners: Manner 1: The NWDAF 2 performs subscription from the SMF through the Nsmf interface, and the SMF performs subscription from the UPF through an N4 interface. Manner 2: The NWDAF 2 performs subscription from the UPF through an Nupf interface), wherein the detected data traffic is associated with one or more of the following identified in the second subscription request: a UE, and an application (see Xin, par. [0220]: The event filter is generated when the NWDAF determines to collect data from the UPF. Then, in a process of subscribing to data from the UPF, the NWDAF sends the event filter to the UPF. The UPF installs the event filter locally and collects data based on a filter condition of the event filter. For example, the event filter may specify a filter condition corresponding to traffic information that needs to be reported by the UPF, such as an App ID, an S-NSSAI, a DNN, and a network area).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method or NWDAF of the combination of Tian in view of TS 29.520 with the additional signaling of Xin with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of improving an application analytics success rate (see Xin, par. [0008]).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Tian in view of TS 29.520, and further in view of Xin, as applied to claims 1, 5-8, 10, 11, 14-17, 19, 24, 28, and 34 above, and further in view of Xin et al. (US 2021/0014739), hereinafter “Xin ‘739”.
Regarding claim 4, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method.
However, the combination of Tian in view of TS 29.520, and further in view of Xin, does not teach:
further comprising determining the range of tunnels indicated in the second subscription request based on the identifier of the UPF tunnel in the first subscription request.
Xin ‘739, in the same field of endeavor, teaches:
further comprising determining the range of tunnels indicated in the second subscription request based on the identifier of the UPF tunnel in the first subscription request (see Xin ‘739, par. [0140]: The NWDAF network element is configured to: collect time-varying network data, services data, or terminal data, and corresponding service experience data, and obtain, through analysis, at least one set of QoS parameters in different network conditions (corresponding to network data), service conditions (corresponding to service data), or terminal conditions (corresponding to terminal data) of a service, and see Table 2: UPF tunnel information Identifies a tunnel through which the service flow is connected to the RAN device on the UPF network element, used for UPF network element selection/traffic routing; in this case, the NWDAF collecting information regarding UPF tunnel corresponds to determining the range of tunnels based on the identifier of the UPF tunnel).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of the combination of Tian in view of TS 29.520, and further in view of Xin, with the determining the range of tunnels of Xin ‘739 with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of obtaining parameters distributed on different network elements (see Xin ‘739, par. [0005]).
Claims 9 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Tian in view of TS 29.520, and further in view of Xin, as applied to claims 1, 5-8, 10, 11, 14-17, 19, 24, 28, and 34 above, and further in view of Jiang et al. (WO 2022/116665), hereinafter “Jiang”, published 09 June, 2022 (see “WO_2022116665_Translation.pdf” for citations).
Regarding claim 9, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method.
However, combination of Tian in view of TS 29.520, and further in view of Xin, does not teach:
wherein the one or more suggested actions include any of the following: adaptive bit rate, ABR, shaping; large flow shaping; transmission control protocol, TCP, traffic optimization; and QUIC traffic optimization.
Jiang, in the same field of endeavor, teaches:
wherein the one or more suggested actions include any of the following: adaptive bit rate, ABR, shaping; large flow shaping; transmission control protocol, TCP, traffic optimization; and QUIC traffic optimization (see Jiang, Fig. 4, pars. [0117-0118]: in Figure 4, after receiving the TCP flow adjustment policy pushed by NWDAF, TCPO will identify the destination IP address in the UE Internet access flow sent by UPF based on the destination IP address that needs to be accelerated recorded in the TCP flow adjustment policy, and then accelerate the TCP flow corresponding to the destination IP address that needs to be accelerated, i.e., the high-value APP, and then send the accelerated TCP flow to the external gateway; based on the destination IP address that needs to be rate-limited recorded in the TCP flow adjustment policy, TCPO will identify the destination IP address in the UE Internet access flow sent by UPF, and then rate-limit the TCP flow corresponding to the destination IP address that needs to be rate-limited, i.e., the low-value APP, and then send the rate-limited TCP flow to the external gateway. As can be seen from the above description, the TCP flow adjustment method provided in this embodiment utilizes the intelligent analysis and statistics of NWDAF combined with trend prediction to analyze the SMF data provided by SMF and the UPF data provided by UPF, thereby predicting the adjustment strategy for the TCP flow generated when each APP accesses the network. For example, the TCP flow of a certain type of APP is accelerated, while the TCP flow of another type is rate-limited. Finally, the predicted TCP flow adjustment strategy is pushed to the TCP acceleration device that is pre-connected between UPF and external gateway, so that the TCP acceleration device can reasonably adjust the TCP flow from UPF).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of the combination of Tian in view of TS 29.520, and further in view of Xin, with the suggested action of Jiang with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of efficiently using network resources and improving user experience (see Jiang, par. [0119]).
Regarding claim 20, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method.
However, combination of Tian in view of TS 29.520, and further in view of Xin, does not teach:
further comprising performing one or more of the following optimization operations on traffic between the UPF and the RAN, based the analytic: adaptive bit rate, ABR, shaping; large flow shaping; transmission control protocol, TCP, traffic optimization; and QUIC traffic optimization.
Jiang, in the same field of endeavor, teaches:
further comprising performing one or more of the following optimization operations on traffic between the UPF and the RAN, based the analytic: adaptive bit rate, ABR, shaping; large flow shaping; transmission control protocol, TCP, traffic optimization; and QUIC traffic optimization (see Jiang, Fig. 4, pars. [0117-0118]: in Figure 4, after receiving the TCP flow adjustment policy pushed by NWDAF, TCPO will identify the destination IP address in the UE Internet access flow sent by UPF based on the destination IP address that needs to be accelerated recorded in the TCP flow adjustment policy, and then accelerate the TCP flow corresponding to the destination IP address that needs to be accelerated, i.e., the high-value APP, and then send the accelerated TCP flow to the external gateway; based on the destination IP address that needs to be rate-limited recorded in the TCP flow adjustment policy, TCPO will identify the destination IP address in the UE Internet access flow sent by UPF, and then rate-limit the TCP flow corresponding to the destination IP address that needs to be rate-limited, i.e., the low-value APP, and then send the rate-limited TCP flow to the external gateway. As can be seen from the above description, the TCP flow adjustment method provided in this embodiment utilizes the intelligent analysis and statistics of NWDAF combined with trend prediction to analyze the SMF data provided by SMF and the UPF data provided by UPF, thereby predicting the adjustment strategy for the TCP flow generated when each APP accesses the network. For example, the TCP flow of a certain type of APP is accelerated, while the TCP flow of another type is rate-limited. Finally, the predicted TCP flow adjustment strategy is pushed to the TCP acceleration device that is pre-connected between UPF and external gateway, so that the TCP acceleration device can reasonably adjust the TCP flow from UPF).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of the combination of Tian in view of TS 29.520, and further in view of Xin, with the suggested action of Jiang with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of efficiently using network resources and improving user experience (see Jiang, par. [0119]).
Claims 21 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Tian in view of TS 29.520, and further in view of Xin, as applied to claims 1, 5-8, 10, 11, 14-17, 19, 24, 28, and 34 above, and further in view of Puente Pestaña et al. (WO 2020/001795), hereinafter “Puente”.
Regarding claim 21, the combination of Tian in view of TS 29.520, and further in view of Xin, teaches the method.
However, the combination of Tian in view of TS 29.520, and further in view of Xin, does not teach:
further comprising:
receiving, from a session management function, SMF, of the communication network, a packet forwarding control protocol, PFCP, session establishment request that indicates a congestion-aware traffic optimization, CATO, policy; and
establishing the tunnel between the UPF and the RAN, in accordance with the PCFP session establishment request,
wherein the first subscription request is sent in response to establishing the tunnel.
Puente, in the same field of endeavor, teaches:
further comprising:
receiving, from a session management function, SMF, of the communication network, a packet forwarding control protocol, PFCP, session establishment request that indicates a congestion-aware traffic optimization, CATO, policy (see Puente, Fig. 3, page 9, lines 6-19: the SMF 9 sends 31 a PFCP Session Establishment Request message to UPF 10. This message may include a Packet Detection Rule, PDR as defined in PFCP standard, which includes the traffic filter that applies to the associated rules further mentioned below, a Forwarding Action Rule, FAR, a Usage Reporting Rule, URR, a QoS Enforcement Rule, QER and a Buffering Action Rule, BAR, as defined in the PFCP standard. The message further includes an Analytics Reporting Rule, ARR. This rule, for example, defines traffic metrics that UPF 10 shall report to SMF 9. Each ARR includes an ARR-ID, identifying the ARR, a list of traffic metric IDs, which define the traffic metric that shall be reported to SMF 9. The UPF 10 and SMF 9 shall have a common understanding of the metric-IDs. The message may further comprise a reporting trigger associated to each metric-ID, for example, specifying a periodic reporting or reporting upon reaching a threshold; in this case, the PFCP establishment request including information on analytics reporting corresponds to a CATO policy); and
establishing the tunnel between the UPF and the RAN, in accordance with the PCFP session establishment request (see Puente, Fig. 3, page 9, lines 19-22: In a subsequent step 32, the UPF 10 sends a PFCP Session Establishment Response message to SMF 9. In a further step 33, the session is established. Traffic traverses UPF 33 and it starts matching packets and executing ARRs when the packets match the corresponding PDR),
wherein the first subscription request is sent in response to establishing the tunnel (see Puente, Fig. 3, page 9, lines 22-28: When a certain metric reporting trigger is activated, the next steps 34, 35 take place for that metric. In step 34, the UPF 10 sends to SMF 9, a PFCP Session Report Request including ARR-ID, indicating what ARR the report corresponds to, a metric- ID, indicating what metric is being reported and a metric value, including the value for that metric. In a final step 35, the SMF 9 sends a PFCP Session Report Response to UPF 10; in this case, starting analysis reporting corresponds to sending the first subscription request (for an analytic)).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of the combination of Tian in view of TS 29.520, and further in view of Xin, with the additional signaling of Puente with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of reducing signaling (see Puente, page 4, lines 8-12).
Regarding claim 22, the combination of Tian in view of TS 29.520, and further in view of Xin, and further in view of Puente, teaches the method.
The combination of Tian in view of TS 29.520, and further in view of Xin, does not teach, but Puente teaches:
further comprising sending to the SMF an indication that the UPF supports a CATO capability (see Puente, Fig. 2, page 5, lines 24-27: the method comprises the steps of transmitting, by said UPF, to said SMF, a session association setup request message, wherein said session association setup request message comprises a traffic metric capability identification for identifying capability for reporting said traffic metric, and see page 8, lines 30-33: It is proposed to extend the existing mechanism to report UPF 10 capabilities in the form of a PFCP Association Setup Request message 21 with a new capability - metric measurements: metric. This would allow SMF 9 to know which UPFs 10 support this capability and thus can influence on UPF 10 selection; in this case, a traffic metric capability corresponds to a CATO capability), wherein the PFCP session establishment request is received based on the indication, wherein the PFCP session establishment request indicates that the UPF should apply the CATO policy without further interaction with the SMF (see Puente, Fig. 2, page 8, lines 30-33: It is proposed to extend the existing mechanism to report UPF 10 capabilities in the form of a PFCP Association Setup Request message 21 with a new capability - metric measurements: metric. This would allow SMF 9 to know which UPFs 10 support this capability and thus can influence on UPF 10 selection, and see Fig. 3, page 9, lines 6-22: the SMF 9 sends 31 a PFCP Session Establishment Request message to UPF 10. This message may include a Packet Detection Rule, PDR as defined in PFCP standard, which includes the traffic filter that applies to the associated rules further mentioned below, a Forwarding Action Rule, FAR, a Usage Reporting Rule, URR, a QoS Enforcement Rule, QER and a Buffering Action Rule, BAR, as defined in the PFCP standard. The message further includes an Analytics Reporting Rule, ARR. This rule, for example, defines traffic metrics that UPF 10 shall report to SMF 9. Each ARR includes an ARR-ID, identifying the ARR, a list of traffic metric IDs, which define the traffic metric that shall be reported to SMF 9. The UPF 10 and SMF 9 shall have a common understanding of the metric-IDs. The message may further comprise a reporting trigger associated to each metric-ID, for example, specifying a periodic reporting or reporting upon reaching a threshold. In a subsequent step 32, the UPF 10 sends a PFCP Session Establishment Response message to SMF 9. In a further step 33, the session is established. Traffic traverses UPF 33 and it starts matching packets and executing ARRs when the packets match the corresponding PDR; in this case, the capability information is used for the establishment procedure).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the method of the combination of Tian in view of TS 29.520, and further in view of Xin, with the additional signaling of Puente with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make this modification for the benefit of reducing signaling (see Puente, page 4, lines 8-12).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Han et al. (US 2021/0099367) teaches apparatuses and methods for detecting a specific service through a NWDAF in a mobile communication system and analyzing a characteristic related to the service.
Hu (US 2024/0388624) teaches a data processing method, a network element and a computer-readable storage medium.
Mary et al. (US 2022/0103443) teaches a mobile network data analytics function node is described. The network data analytics function node obtains from a network function service consumer, a request for analytics of at least one load parameter for at least one network function service provider and obtains a load data from at least one network function service provider.
Pateromichelakis et al. (US 2025/0055902) teaches apparatuses, methods, and systems are disclosed for determining application data and/or analytics.
Shan et al. (US 2021/0014765) teaches systems, methods, and devices related to data forwarding tunnel establishment between two user plane functions in fifth generation (5G).
Skog et al. (WO 2021/028063) teaches a method for predicting congestion levels in a communication network.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CALEB J BALLOWE whose telephone number is (571)270-0410. The examiner can normally be reached MON-FRI 7:30-5.
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, Nishant B. Divecha can be reached at (571) 270-3125. 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.
/C.J.B./Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
Prosecution Insights