N4报告流程

1.2 相关的重要知识点和FAQ 3

1.2.1本流程相关的规范主要有哪些？3

1.2.2 什么是N4报告流程？做什么用的？

1.2.3 哪些事件需要UPF通过N4报告流程上报SMF？或者说该流程的触发条件是什么？

1.2.4 是不是只要上述事件发生，UPF就要触发本流程报告UPF？5

1.2.5 Reporting Triggers参数的构成是怎样的？6

1.3 规范中的原版流程简介7

二 N4报告流程实战8

2.1 使用量的报告

2.2 业务流量检测的报告10

2.3 空闲态收到下行数据的报告12

规范，尽量用大白话、结合具体实例、生活化场景来介绍。尽可能降低新手的学习门槛，也节省老通信人学习信令、

规范的时间(毕竟5G初期，大家都很忙。即便有经验、聪明，也没时间去啃规范啊）。

所有的5GC信令流程都在23502的第4章：System Procedures里。

一 规范中的N4报告流程简介

1.1 本期文章在规范中的位置

【注：完整的23502导图下载地址：http://51xuetongxin.com/23502.svg 】

【我们不生产规范，我们只是规范的搬运工】

1.2 相关的重要知识点和FAQ

1.2.1本流程相关的规范主要有哪些？

本流程涉及的主要规范包括：23502（信令流程）和29244（PFCP协议）。

1.2.2 什么是N4报告流程？做什么用的？

N4报告流程用于UPF向SMF报告和某个PDU会话相关的事件。原文是：【This procedure is used by the UPF to

report events related to an N4 session for an individual PDU Session. 】敲重点：N4报告是和UE的某个PDU会话有关

的，而不是针对UPF网元级系统参数或全局类的报告，并不是用于运维目的的。而是和业务有关、和用户有关。例

如：UPF不会通过这个来上报自己的告警、KPI、日志等。那是网管的事，走专门的OAM的接口和网管专用网络上报

或被动采集。

1.2.3 哪些事件需要UPF通过N4报告流程上报SMF？或者说该流程的触发条件是什么？

23502中明确提到，当UPF检测到以下事件发生，则有可能需要走N4报告流程，上报SMF。主要包括以下9类事件：

1）使用量报告（Usage report）：UPF需要向SMF报告用户的使用量，用于性能管理、策略控制、计费等目的。

2）检测到某个应用开始产生流量（Start of traffic detection）：如果SMF要求针对某个业务（例如某个App）做流量产

生的检测，并且UPF根据PDR规则检测到了这个业务流量的产生，那么UPF需要向SMF报告。并且上报关联的PDR规

则ID。

3）检测到某个应用的流量停止（Stop of traffic detection）：如果SMF要求针对某个业务（例如某个App）做流量停止

的检测，并且UPF根据PDR规则检测到了这个业务流量的停止，那么UPF需要向SMF报告。并且上报关联的PDR规则

4）当用户面连接去激活场景下，收到了第1个下行数据（Detection of 1st downlink data for PDU Session with UP

Connection deactivated.）：这个说了这么多，其实是指UE在CM-IDLE态下，UPF侧的N3隧道已经释放，不知道怎么

转发下行数据。此时如果有下行数据到达（只要有1个下行数据到达），UPF需要给SMF发N4报告，作为下行数据通

知（downlink data notification）。同时UPF可根据BAR（Buffer Action Rule：缓存规则）的要求对收到的下行数据进

行缓存。

5）检测到PDU会话在一段时间内不活跃（Detection of PDU Session Inactivity for a specified period.）：SMF可以在

N4会话建立或者N4会话修改流程中，给UPF下发一个PDU会话的Inactive Timer（不活跃计时器），如果该计时器超

时，并且该PDU会话没有流量产生，那UPF需要通过N4报告流程通知SMF。

6）上行、下行或者往返报文延迟的测量报告（The UL, DL or round trip packet delay measurement report.）：这个主

要是针对URLLC的特定Qos流的Qos监控目的。UPF需要计算该Qos流的上行、下行或者往返报文延迟。当UPF发现实

际值超过了SMF要求的报告门限值、或者报告周期到了、或者PDU会话释放了，UPF需要将计算的结果上报SMF。当

SMF收到报告后，会通知PCF或者AF。PCF可以据此调整Qos策略，AF收到后也可以做一些应用层面的调整（例如

TCP滑动窗口调整等）。

7）端口管理信息容器可用时（Port Management Information Container available.）：用于TSN（Time-Sensitive

Networking：时间敏感网络）网络的特殊场景。目前还没有商用，比较冷门。可以暂时先不关注。

8）丢弃下行数据检测（Discard Downlink Traffic detection.）：当UPF检测到某个PDR对应的业务流量下行方向出现

丢包、并且SMF要求上报时，则UPF应向SMF报告，并报告关联的PDR ID。

9）缓存下行数据检测（Buffered Downlink Traffic detection）：当UPF检测到某个PDR对应的业务流量下行方向被缓

存到内存中、并且SMF要求上报时，则UPF应向SMF报告，并报告关联的PDR ID。

1.2.4 是不是只要上述事件发生，UPF就要触发本流程报告UPF？

不是的。除了事件必须发生，还要看SMF是否要求UPF（没让你报就别报）上报。UPF要检查在N4会话建立或N4会话

修改流程中，SMF是否下发了这个Reporting Triggers这个参数。这个Reporting Triggers包含在URR（Usage

Reporting Rule：使用量报告规则）中，可通过PFCP Session Establish Request消息的Create URR参数中下发、也

可通过PFCP Session Modification Request消息的Update URR参数来下发。

1.2.5 Reporting Triggers参数的构成是怎样的？

Reporting Triggers参数在29244的8.2.19中定义。如下：

它的构成如下：首先看字节5的几个bit位（从右往左依次是bit1到8）：

- Bit1：PERIO(Periodic Reporting) ，置1表示要做周期性报告；

- Bit2：VOLTH (Volume Threshold) ，置1表示流量门限值到达时要发报告；

- Bit3：TIMTH（Time Threshold），置1表示时间门限值到达时要发报告；

- Bit4：QUHTI (Quota Holding Time)，置1表示当QHT超时（配额的保持时间）且还没收到用户面数据时要发送报

- Bit5：START (Start of Traffic) ，置1表示当检测到某个特定App流量的开始，要发报告；

- Bit6：STOPT (Stop of Traffic) ，置1表示当检测到某个特定App流量的停止，要发报告；

- Bit7：DROTH (Dropped DL Traffic Threshold) ，置1表示当下行数据丢包到达一个门限值要发报告；

- Bit8：LIUSA (Linked Usage Reporting) ，置1表示请求做关联的使用量报告（也就是一个URR关联到另一个URR，

可能是家庭套餐两大一小这种场景。）

再看字节6的几个bit位（从右往左依次是bit1到8）：

- Bit1：VOLQU (Volume Quota) ，置1表示当流量配额耗尽时要报告；

- Bit2：TIMQU (Time Quota) ，置1表示当时间配额耗尽时要报告；

- Bit3：ENVCL (Envelope Closure)，置1表示当信封关闭时要发报告；

- Bit4：MACAR (MAC Addresses Reporting) ，置1表示在检测UE发起的上行报文的源MAC地址时要上报；

- Bit5：EVETH (Event Threshold) ，置1表示当事件的门限值到达，要发报告；（注：有些是业务是按次也就是一次成

功的事件，比如彩信）

- Bit6：EVEQU (Event Quota) ，置1表示当事件的配额耗尽，要发报告；

- Bit7：IPMJL (IP Multicast Join/Leave) ，置1表示当加入或离开一个IP组播组要发报告；

- Bit8：QUVTI (Quota Validity Time) ，置1表示配额的有效时间超时，要发报告请求重新下发配额。

再看字节7的几个bit位，它只有一个bit位1，其余都是留白的：

- Bit1：REEMR (REport the End Marker Reception) ，置1表示当UPF收到End Marker的报文时要报告。

1.3 规范中的原版流程简介

规范中的N4报告流程在23502的4.4.1.2定义，如下图：

第1步：UPF检测到用户面的事件产生，同时比对SMF所下发的Reporting Trigger（1.2.5节）是否条件满足，如果满

足，则向SMF发送报告。

第2步：UPF发送PFCP Session Report Request消息给SMF，并携带使用量报告。

第3步：SMF保存使用量报告，并返回PFCP Session Report Response给UPF。

后续，SMF和其他网元的后续交互。例如通知PCF采取相应的策略调整。

二 N4报告流程实战

本章以三种典型和常见的N4报告场景为例，加深对现网的理解。

【本场景举例纯属虚构，如有雷同，纯属巧合。】

2.1 使用量的报告

场景假设：SMF已经下发Reporting Trigger，要求UPF发送使用量报告。

第1步：UPF给SMF发N4会话报告，消息是：PFCP Session Report Request，主要参数有：{关联的URR ID、Report

Type：USAR（使用量报告）、SEID、

Usage Report：【Volume Measurement（上行流量、下行流量、总流量）、Usage Report Trigger：Volume

Threshold、第一个包到达的时间戳、最后一个包的时间戳、报告的起始时间等】}。其中Report Trigger的取值是

Volume Threshold表示是因为使用量到达门限值而触发的报告。

第2步：SMF回PFCP Session Report Response。

以下是一个使用量报告的实际报文举例，供参考。

Packet Forwarding Control Protocol

Flags: 0x21, SEID (S)

Message Type: PFCP Session Report Request (56)

Length: 104

SEID: 0x00000000aaabbbcc

Sequence Number: 65536

Spare: 0

Report Type :

IE Type: Report Type (39)

IE Length: 1

Flags: 0x02, USAR (Usage Report)

Usage Report (Session Report Request) : [Grouped IE]

IE Type: Usage Report (Session Report Request) (80)

IE Length: 83

Usage Report Trigger :

IE Type: Usage Report Trigger (63)

IE Length: 2

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

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

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

...0 .... = START (Start of Traffic): False

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

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

.... ..1. = VOLTH (Volume Threshold): True

.... ...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

Volume Measurement :

IE Type: Volume Measurement (66)

IE Length: 25

Flags: 0x07, DLVOL, ULVOL, TOVOL

0000 0... = Spare: 0

.... .1.. = DLVOL: True

.... ..1. = ULVOL: True

.... ...1 = TOVOL: True

Total Volume: 10000

Uplink Volume: 3000

Downlink Volume: 7000

Time of First Packet : May 31, 2020 09:09:27.000000000 UTC

Time of Last Packet : May 31, 2020 09:09:27.000000000 UTC

Start Time : May 31, 2020 09:09:18.000000000 UTC

End Time : May 31, 2020 09:09:27.000000000 UTC

URR ID : Dynamic by CP 1

2.2 业务流量检测的报告

假设SMF下发Reporting Trigger，要求UPF针对APP100的流量进行报告。

第1步：UPF给SMF发N4会话报告，消息是：PFCP Session Report Request，主要参数有：{关联的URR ID、Report

Type：USAR（使用量报告）、SEID、

Usage Report：【Usage Report Trigger：Start Of Traffic、第一个包/最后一个包的时间戳、Application-ID：100】}。

其中Report Trigger的取值是Start Of Traffic表示是因为检测到了App100的流程产生而触发的报告。App-ID 100会和

UPF中的业务检测规则对应，最终会关联到某个特定的App，例如微信等。

第2步：SMF回PFCP Session Report Response。

以下是一个业务流量检测报告的实际报文举例，供参考。

Packet Forwarding Control Protocol

Flags: 0x21, SEID (S)

Message Type: PFCP Session Report Request (56)

Length: 76

SEID: 0x000000000aaabbcc

Sequence Number: 65536

Spare: 0

Report Type :

IE Type: Report Type (39)

IE Length: 1

Flags: 0x02, USAR (Usage Report)

Usage Report (Session Report Request) : [Grouped IE]

IE Type: Usage Report (Session Report Request) (80)

IE Length: 55

Usage Report Trigger :

IE Type: Usage Report Trigger (63)

IE Length: 2

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

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

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

...0 .... = 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 : [Grouped IE]

IE Type: Application Detection Information (68)

IE Length: 13

Application ID : app-id100

IE Type: Application ID (24)

IE Length: 9

Application Identifier: app-id100

Time of First Packet : Jul 20, 2020 16:57:00.000000000 UTC

Time of Last Packet : Jul 20, 2020 16:57:24.000000000 UTC

URR ID : Dynamic by CP 1

2.3 空闲态收到下行数据的报告

假设SMF已经下发空闲态数据到达报告规则给UPF。

第1步：从Internet有下行用户数据到达UPF，但因为UE在CM-IDLE即空闲态，下行N3隧道已经拆除了。UPF开始缓存

下行数据，并给SMF发下行数据到达通知。

第2步：UPF给SMF发N4会话报告，消息是：PFCP Session Report Request，主要参数有：【Report Type：DLDR

（下行数据报告）、SEID、Downlink Data Report：QFI、关联的PDR ID】。其中Report Type：DLDR表示是因为收

到了下行数据到达而触发的报告。该消息中还包含了下行数据所关联的QFI和PDR-ID信息。

第3步：SMF回PFCP Session Report Response。

以下是一个空闲态数据到达报告的实际报文举例，供参考。

Packet Forwarding Control Protocol

Flags: 0x21, SEID (S)

Message Type: PFCP Session Report Request (56)

Length: 33

SEID: 0x000000000aaabbcc

Sequence Number: 0

Spare: 0

Report Type :

IE Type: Report Type (39)

IE Length: 1

Flags: 0x01, DLDR (Downlink Data Report)

Downlink Data Report : [Grouped IE]

IE Type: Downlink Data Report (83)

IE Length: 12

Downlink Data Service Information :

IE Type: Downlink Data Service Information (45)

IE Length: 2

Flags: 0x02, QFII(QoS Flow Identifier)

00.. .... = Spare: 0

.000 0101 = QFI: 0x05

PDR ID : 5

【全文完】