第17篇：支持下发非连续接收DRX

《5GC原理与实践》实践篇是按网元来规划的。包括AMF篇、SMF篇、PCF篇等。

本文是AMF篇的第17篇。

本期目录：

1.3.10 支持下发非连续接收DRX 102

1.3.10.1 概述 102

1.3.10.2 AMF如何与UE协商DRX参数 102

1.3.10.3 主要参数Requested DRX parameters和Negotiated DRX parameters 103

1.3.10.4 检查项和检查点 104

1.3.10.5 AMF如何处理的业务逻辑举例 104

1.3.10 支持下发非连续接收DRX

1.3.10.1 概述

AMF应支持与UE协商，并给UE下发空闲模式DRX周期参数。该功能在23501的5.4.5节：DRX (Discontinuous Reception) framework定义。空闲模式的DRX周期参数适用于CM-IDLE态，以及CM-Connected+RRC Inactive态。

规范原文：“The 5G System supports DRX architecture which allows Idle mode DRX cycle is negotiated between UE and the AMF.The Idle mode DRX cycle applies in CM-IDLE state and in CM-CONNECTED with RRC Inactive state.”。

1.3.10.2 AMF如何与UE协商DRX参数

如果UE希望使用自己提供的DRX参数，UE应该在注册请求消息中提供Requested DRX参数。但需要注意，仅适用于初始注册和MRU流程，不适用于周期性注册流程。

当收到UE请求的DRX参数后，AMF可以接受UE请求的DRX参数，也可以修改该参数，并最终在注册接受消息中给UE下发允许的DRX参数。

UE收到后以AMF下发的DRX参数为准【The AMF shall determine Accepted DRX parameters based on the received UE specific DRX parameters and the AMF should accept the UE requested values, but subject to operator policy the AMF may change the UE requested values.】关于DRX参数的细节可以看38331。

Q：如果UE没有得到AMF下发的DRX参数，怎么办?

A：如果AMF没有给UE下发DRX参数，则UE应使用空口广播的DRX周期参数。在38304中详细介绍。原文是：“The UE shall apply the DRX cycle broadcast in the cell by the RAN unless it has received Accepted DRX parameters for the RAT from the AMF and for NB-IoT the cell supports UE specific DRX for NB-IoT, in which case the UE shall apply either the DRX cycle broadcast in the cell or the Accepted DRX parameters for the RAT, as defined in TS 38.304.”

1.3.10.3 主要参数Requested DRX parameters和Negotiated DRX parameters

最后看下具体的消息参数。UE请求的DRX参数叫Requested DRX parameters，在NAS消息：Registration Request中携带；如下表所示：

AMF下发的DRX参数叫Negotiated DRX parameters，在NAS消息Registration Accept中携带。 

如下表所示：

可以看到，无论是UE请求的还是AMF下发的DRX参数，都是O，也就是可选参数。表示这个是一个可选特性。另外，该参数的详细信息在9.11.3.2A中定义。顺藤摸瓜找到该参数如下表：

可以看到，5GS DRX参数总共3个字节。其中具体的DRX值是在字节3的bit1到bit4，取值为1表示DRX周期参数值T为32，取值为2表示DRX周期参数值T为64，取值为3表示DRX周期参数值T为128，取值为4表示DRX周期参数值T为256。

bit5到bit8是预留的，在编码的时候应取值为0。

1.3.10.4 检查项和检查点

检查项：在5G注册流程中，AMF能正确处理和解析UE请求的DRX参数，并能在注册接受消息中下发网络侧接受的DRX参数。

检查点：直接看包检查。

1.3.10.5 AMF如何处理的业务逻辑举例

由于没有找到对应的wireshark log，以开源项目Free5GC中AMF处理逻辑举例：

简短说明下上述两段代码：

第1段：637行判断UE发上来的注册请求消息中是否携带了RequestedDRX参数，如果携带了，则

638行先提取出RequestedDRX参数的取值，并进行以下条件判断：

- 639-641行，如果UE请求的值是T32，则将T32这个值写入变量ue.UESpecificDRX并写入log。

- 642-644行，如果UE请求的值是T64，则将T64这个值写入变量ue.UESpecificDRX并写入log。

- 645-647行，如果UE请求的值是T128，则将T128这个值写入变量ue.UESpecificDRX并写入log。

- 648-650行，如果UE请求的值是T256，则将T256这个值写入变量ue.UESpecificDRX并写入log。

还有几行是对UE携带了错误的DRX值时的容错处理。

第2段：将变量ue.UESpecificDRX的值赋予注册接受消息的NegotiatedDRXParameters参数并发给UE。

---

---

更多精彩内容，请阅知识星球800+篇精华合集帖。

该链接收录了知识星球800+篇的精华内容，

含视频、图文专栏、精华帖、问答等等精华内容。

无论是想学习课程、看视频、看案例、看log、看实战，统统都有。

各位星友必看！！！

精华合集（链接永久不变，内容自动更新）：

https://drpn55b08y.feishu.cn/docx/Y8MqdnyKooY8yKxfBdoc3EvZnof 

飞书域名太长，还创建了一个短链接：

http://gg.gg/15t0bu