This application is a 35 U.S.C. § 371 national phase filing of International Application No. PCT/EP2018/072742, filed Aug. 23, 2018, which claims the benefit of European Patent Application No. 18382471.3, filed Jun. 25, 2018, the disclosures of which are incorporated herein by reference in their entireties.

TECHNICAL FIELD

The present disclosure relates to the reporting of traffic metrics and, more specifically, to the reporting of traffic metrics by the UPF to the SMF.

BACKGROUND

Control and user plane separation, CUPS, enables a flexible placement of the separated control plane and user plane functions for supporting diverse deployment scenarios such as a central or a distributed User Plane Function, UPF.

In The Fifth Generation, 5G, telecommunication network, CUPS refers to Session Management Function, SMF, and UPF network functions and to the N4 reference point between them, which is based on Packet Forwarding Control Protocol, PFCP.

The SMF controls the packet processing in the UPF by establishing, modifying or deleting PFCP Session contexts and by adding, modifying or deleting Packet Detection Rules, PDRs, Forwarding Action Rules, FARs, Quality of service Enforcement Rules, QERs, Usage Reporting Rules, URRs, and/or Buffering Action Rule, BAR, per PFCP session context, whereby an PFCP session context may correspond to an individual PDU session or a standalone PFCP session not tied to any PDU session.

Each PDR contains a Packet Data Inspection, PDI, that are one or more match fields against which incoming packets are matched, and may be associated to the following rules providing the set of instructions to apply to packets matching the PDI:one FAR, which contains instructions related to the processing of the packets, specifically forward, duplicate, drop or buffer the packet with or without notifying the CP function about the arrival of a DL packetzero, one, or more QERs, which contains instructions related to the QoS enforcement of the traffic;zero, one, or more URRs, which contains instructions related to traffic measurement and reporting.

The Network Data Analytics Function, NWDAF, is a new Network Function being standardized by the Third Generation Partnership Project, 3GPP, in 5G. NWDAF represents operator managed network analytics logical function. NWDAF provides slice specific network data analytics to the Policy Control Function, PCF, and Network Slice Selection Function, NSSF. NWDAF provides network data analytics such as load level information to the PCF and NSSF on a network slice level and the NWDAF is not required to be aware of the current subscribers using the slice. NWDAF notifies or publishes slice specific network status analytic information to the PCF(s) and NSSF that are subscribed to it. PCF(s) and NSSF can collect directly slice specific network status analytic information from NWDAF. This information is not subscriber specific. PCF uses that data in its policy decisions. NSSF may use the load level information provided by NWDAF for slice selection.

In the current PFCP reporting solution SMF configures PDRs associated to URRs in UPF. When a packet matches a PDR, the reporting actions configured in the associated URRs are executed. The current reporting solution in PFCP is used for charging, so the metric defined in URR is traffic volume. It is reported along with the reporting time or event (for time and event-based charging). As mentioned, the 5G Core network, 5GC, introduces a new function for analytics, NWDAF, that collects data from the NFs. So far, the standard specifies that NWDAF provides load analytics, so for the moment there is a requirement for UPF to provide load metrics. But standardization has just started and NWDAF will incorporate further analytics in the future. It is foreseen, by the inventors, that NWDAF will provide analytics as well taking user plane traffic metrics such as service flow metadata, network metrics, service QoE indicators, as input. As UPF is an important source of such user plane metrics, UPF shall be able to send these traffic metrics to SMF, and then SMF relies them to NWDAF. Such traffic measurements may also be consumed by other network functions such as PCF to enforce certain policies in real time.

In 5GC, the N4 interface between SMF and UPF will be based on the PCFP protocol. The current PFCP definition only allows to report volume from UPF to SMF. This is, according to the inventors, not enough to support the analytics use cases that will take place in 5G, where metrics such as data session, packet latency, jitter will be required to UPF. Packet latency may be defined as the mean, maximum access or Internet Round Trip Time during a transport connection time.

The current Policy and Charging Control, PCC, architecture in 3GPP networks allows the operator to enforce a certain QoS both on a per user and on a per service/application basis. However, enforcing the QoS in the network does not directly map to a good/bad quality as perceived from end user perspective. This concept is called end user QoE, Quality of Experience, as opposed to network QoS. There is no current mechanism in 3GPP PCC architecture that monitors and guarantees a certain end user QoE. It is even foreseen, by the inventors, that in 5G, the QoE metric will need to be reported to the UPF.

SUMMARY

An object of the present disclosure is to allow reporting, by a User Plane Function, of any traffic metric in a telecommunication network to a Session Management Function, SMF.

An object of the invention according to the present disclosure is to allow network operators to guarantee a certain Quality of Experience, QoE to the end users.

In a first aspect of the present disclosure, there is presented, a method of reporting traffic metrics by a User Plane Function, UPF, to a Session Management Function, SMF, in a telecommunication network. The method comprises the steps of receiving, by said UPF, a session creation/modification message for creating/modifying a session between said UPF and said SMF, wherein said message comprises a Reporting Rule thereby defining which traffic metric is to be reported by said UPF to said SMF, measuring, by said UPF, said traffic metric based on said received Reporting Rule, and transmitting, by said UPF, to said SMF, a reporting message, wherein said reporting message comprises said measured traffic metric.

The solution allows the UPF to report to SMF any traffic metric that can be used for analytics in the Fifth Generation Core, 5GC, Network. The existing mechanism to report UPF capabilities is extended with a new capability which includes the metric measurements. This would allow the SMF to know which UPFs support this capability and this can influence on UPF selection. The proposed solution allows interoperability between different network vendors as it may be based on Packet Forwarding Control Protocol, PFCP, extensions.

It is an advantage of the present disclosure that the Reporting Rule is received, by the UPF, in a session creation or a session modification message. In this case, it is not necessary to use standalone, i.e. separate, messages for conveying the Reporting Rule. There is no additional load on the capacity of the network, by using already existing messages in the network.

The above thus allows for an efficient way of informing the UPF to measure any traffic metric, and to report the measured traffic metric back to the SMF.

It is noted that a plurality of UPF's may be instructed, by a single SMF, to measure a particular traffic metric, and to report the measured traffic metric back to the SMF. As such, a single particular SMF is arranged to manage a plurality of SMF's.

According to an example, the step of receiving comprises receiving, by said UPF, said creation/modification message, wherein said message comprises a reporting trigger, wherein said reporting trigger indicates a trigger for reporting said measured traffic. In this example, the step of transmitting comprises transmitting, by said UPF, to said SMF, said reporting message triggered by said reporting trigger.

It may be advantageous to include a trigger in the creation/modification message which provides a trigger definition to report the measured traffic. Upon the occurrence of such a trigger, the UPF provides the measured metrics to the SMF. The trigger may, for example, define that the reporting is to be periodic or when a metric reaches a specific threshold.

Another advantage of the above is that network capacity is not utilized for messages that are not required. The SMF indicates to the UPF when it desires to received the measured traffic metric using the reporting trigger. As such, the UPF transmits the reporting message only when such a reporting trigger actually occurs.

In an example, the step of receiving comprises receiving, by said UPF, said creation/modification message, wherein said message comprises any of an Analytics Reporting Rule, ARR, for indicating traffic metric to be reported by said UPF on a Packet Detection Rule, PDR, level, a Session Analytics Reporting Rule, SARR, for indicating traffic to be reported by said UPF on a session level, or a Node Analytics Reporting Rule, NARR, for indicating traffic metric to be reported by said UPF on a node level.

The ARR defines traffic metrics that UPF shall report to the SMF. Rach ARR comprises an ARR-Identifier, ID, identifying the ARR, a list of traffic metric IDs, which define the traffic metric that shall be reported to the SMF. It may be beneficial when the UPF and the SMF shall have a common understanding of the metric-IDs. Similarly, the SARR comprises an SARR-ID and al list of traffic metric IDs, which define the traffic metric to be reported to the SMF.

The inventors have found that a reporting rule may be defined for specific applications. For example an ARR defines a traffic metric to be reported on a PDR level, a SARR defines traffic to be reported on a session level, and a NARR defines traffic metric to be reported on a node level. This aids the UPF in performing a correct measurement, i.e. a measurement which is actually requested by the SMF.

According to an example, the reporting message comprises any of a reporting rule identification for identifying wherein said reporting message is associated with one of said ARR, SARR and NARR, a metric identification for identifying said traffic metric, and a traffic metric value for identifying a measured traffic value of said traffic metric.

The advantage of the above described example is that only three fields are required in the reporting message for correctly reporting a particular traffic metric. It is a convenient and adequate way of reporting the measured traffic metric.

In an example, 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 receiving, by said UPF, from said SMF, an acknowledgement message thereby acknowledging said session association setup request message.

According to an example of the first aspect of the present disclosure, the session is a Packet Forwarding Control Protocol, PFCP, session.

In an example, the UPF comprises an N4 interface.

In a second aspect of the present disclosure, there is presented a User Plane Function, UPF, arranged for reporting traffic metrics to a Session Management Function, SMF, in a telecommunication network. The UPF comprises of a receive equipment arranged for receiving a session creation/modification message for creating/modifying a session between said UPF and said SMF, wherein said message comprises a Reporting Rule thereby defining which traffic metric is to be reported by said UPF to said SMF, a measure equipment arranged for measuring said traffic metric based on said received Reporting Rule, and transmit equipment arranged for transmitting to said SMF, a reporting message, wherein said reporting message comprises said measured traffic metric.

The advantages of the first aspect of the disclosure being a method of reporting traffic metrics by a UPF to an SMF, are also inherently a part of the second aspect of the disclosure. Furthermore, it is pointed out that although the claims read as if all the modules/equipments according to this second aspect of the present disclosure are incorporated into a single node, a person skilled in the art understands that the same disclosure could be implemented by, for example, distributing each of the modules over several nodes. Alternately, the disclosure could also be purely implemented in the cloud, whereby none of the physical nodes possess any of these modules/equipments as such.

According to an example of the second aspect of the disclosure, the receive equipment is further arranged for receiving said creation/modification message, wherein said message comprises a reporting trigger, wherein said reporting trigger indicates a trigger for reporting said measured traffic, and wherein said transmit equipment is further arranged for transmitting, to said SMF, said reporting message triggered by said reporting trigger.

In an example of the second aspect of the present disclosure, the receive equipment is further arranged for receiving said creation/modification message, wherein said message comprises any of an Analytics Reporting Rule, ARR, for indicating traffic metric to be reported by said UPF on a Packet Detection Rule, PDR, level, a Session Analytics Reporting Rule, SARR, for indicating traffic to be reported by said UPF on a session level, and/or a Node Analytics Reporting Rule, NARR, for indicating traffic metric to be reported by said UPF on a node level.

According to an example of the second aspect, the reporting message comprises any of a reporting rule identification for identifying wherein said reporting message is associated with one of said ARR, SARR and NARR, a metric identification for identifying said traffic metric, and/or a traffic metric value for identifying a measured traffic value of said traffic metric.

A UPF in accordance with any of the claims 8-10, wherein said transmit equipment is further arranged for transmitting, 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 wherein said receive equipment is further arranged for receiving, from said SMF, an acknowledgement message thereby acknowledging said session association setup request message.

In a further example of the second aspect of the present disclosure, the session is a Packet Forwarding Control Protocol, PFCP, session.

In an example according to the second aspect of the disclosure, the UPF comprises an N4 interface.

According to a third aspect of the present disclosure, there is presented a computer program product comprising a computer readable medium having instructions which, when executed by a User Plane Function, UPF, in a telecommunication network, cause said UPF to implement any of the methods as explained above.

In this aspect of the disclosure, a computer readable storage medium is provided with instructions that enable a system onto which said storage medium has been loaded to perform the method according to the present disclosure.

The above mentioned and other features and advantages of the disclosure will be best understood from the following description referring to the attached drawings. In the drawings, like reference numerals denote identical parts or parts performing an identical or comparable function or operation.

