《5GC实践篇》之SMF篇（9）N4接口支持之APP流量检测上报

规则，以及UPF发送的PFCP Session Report报告一起来完成的。这主要涉及到两个问题。

Q1：如何做App的检测呢？

A1：CU分离之前，4G就在PGW上做。CU分离之后，由SMF下发PDR规则，包含需要检测的App的匹配规则。App的

检测通常有两类：

1）基于IP五元组（源/目的IP、源/目的端口、协议号）。这种检测规则适用于一些运营商自有业务（例如VoLTE流

量），SMF可以把这些信息写在PDR中下发给UPF。

2）基于七层的深度检测（即基于http或wap的url来检测）。这类规则通常直接配置在UPF中，SMF在下发PDR的时

候，只包含一个app的ID，UPF根据这个ID映射到本地的深度检测规则，然后对App进行检测。这通常适用于一些第三

方的业务（运营商角度）。

Q2：如何上报呢？

A2：主要由SMF下发的URR中的Reporting Triggers（使用量报告的触发条件），上一节介绍了VOLTH（Volume

Threshold）这个取值，表示当使用量到达门限值，UPF需向SMF上报使用量。本节用到的是START (Start of Traffic)和

STOPT (Stop of Traffic)这两个取值，这两个Trigger设置为True时，表示要求UPF检测到该App流量产生和停止时，都

要向SMF发送报告。另外，Measurement Method参数的取值需设置为EVENT，表示基于特定事件的测量。

UPF发送的报告中应包含该App的ID、App是启动还是停止的报告原因等信息。

信令图如下：

二 检查点与消息举例

1）检查SMF发出的PFCP Session Establishment Request消息是否下发了前面提到的PDR、URR，并且在PDR中包

含了需要检测的AppId和报告触发器等关键参数。以下是PFCP Session Establishment Request消息中下发的PDR、

URR举例：

可以看到PDR中下发了关键的App-id、关联的URR等关键参数，URR中则下发了关键的Reporting Trigger、

Measurement Method等关键参数。

Create PDR :

IE Type: Create PDR

IE Length: 103

PDR ID : 1

Precedence : 255

PDI :

IE Type: PDI

IE Length: 48

Source Interface : Access

F-TEID :

Network Instance : n3-vpn

UE IP Address :

Application ID : wechat

IE Type: Application ID

IE Length: 9

Application Identifier: wechat

QFI : 5

Outer Header Removal : GTP-U/UDP/IPv4

URR ID : Dynamic by CP 1

关联的URR1如下：

Create URR :

IE Type: Create URR

IE Length: 19

URR ID : Dynamic by CP 1

Reporting Triggers :

IE Type: Reporting Triggers

IE Length: 2

0... .... = LIUSA (Linked Usage Reporting): False

.0.. .... = DROTH (Dropped DL Traffic Threshold): False

..1. .... = STOPT (Stop of Traffic): True

...1 .... = START (Start of Traffic): True

.... 0... = QUHTI (Quota Holding Time): False

.... .0.. = TIMTH (Time Threshold): False

.... ..0. = VOLTH (Volume Threshold): False

.... ...0 = PERIO (Periodic Reporting): False

000. .... = Spare: 0

..0. .... = EVEQU (Event Quota): False

...0 .... = EVETH (Event Threshold): False

.... 0... = MACAR (MAC Addresses Reporting): False

.... .0.. = ENVCL (Envelope Closure): False

.... ..0. = TIMQU (Time Quota): False

.... ...0 = VOLQU (Volume Quota): False

Measurement Method :

IE Type: Measurement Method (62)

IE Length: 1

Flags: 0x04, EVENT

2）当wechat这个App的流量产生时，UPF应给SMF发送报告。检查UPF发出的PFCP Session Report Request消息是

否包含正确的Reporting Trigger和应用检测信息。以下是PFCP Session Report Request消息中的报告举例：（可以看

到应用检测信息中包含了App的Id，Report Trigger的取值为START，代表wechat这个流量的第一个报文已经到达了

UPF，因此触发了上报。）

Packet Forwarding Control Protocol

Flags: 0x21, SEID (S)

Message Type: PFCP Session Report Request

Length: 60

SEID: 0x0000000006666888

Sequence Number: 0

Spare: 0

Report Type :

IE Type: Report Type

IE Length: 1

Flags: 0x02, USAR (Usage Report)

Usage Report :

IE Type: Usage Report

IE Length: 39

Usage Report Trigger :

IE Type: Usage Report Trigger

IE Length: 2

0... .... = IMMER (Immediate Report): False

.0.. .... = DROTH (Dropped DL Traffic Threshold): False

..0. .... = STOPT (Stop of Traffic): False

...1 .... = START (Start of Traffic): True

.... 0... = QUHTI (Quota Holding Time): False

.... .0.. = TIMTH (Time Threshold): False

.... ..0. = VOLTH (Volume Threshold): False

.... ...0 = PERIO (Periodic Reporting): False

0... .... = EVETH (Event Threshold): False

.0.. .... = MACAR (MAC Addresses Reporting): False

..0. .... = ENVCL (Envelope Closure): False

...0 .... = MONIT (Monitoring Time): False

.... 0... = TERMR (Termination Report): False

.... .0.. = LIUSA (Linked Usage Reporting): False

.... ..0. = TIMQU (Time Quota): False

.... ...0 = VOLQU (Volume Quota): False

Application Detection Information :

IE Type: Application Detection Information

IE Length: 13

Application ID : wechat

URR ID : Dynamic by CP 1

UR-SEQN : 0

IE Type: UR-SEQN

IE Length: 4

UR-SEQN: 0