5GC中控制面SBI接口基本都是采用HTTP2协议，HTTP2消息中的application/json部分一般是ASCII明文编码，wireshark通常都能解码，但是N1 nas消息部分wireshark很多情况并不会进行解码。有些问题分析时，我们可能需要获知N1部分的内容，这种情况下倒是可以对照3GPP规范进行逐字段手工解码。
今天在分析inter AMF mobility registration时，发现在source AMF向 target AMF post用户信息时，target AMF很多回了404 content not found报错，所以尝试进行了手工对N1 message部分进行解码，过程分享给大家。

1. 先介绍下nas消息的三种编码格式

V/TV/TLV IE字段格式说明：
V:只包含IE字段值，解码依赖消息位置。
TV：包含IE字段名和字段值
TLV：包含IE字段名、字段长度和字段值

• V格式编码的消息，因为没有字段识别名字，所以编码依赖字段位置，一般放在nas的开头位置
• TV和TLV格式编码有IE type，所以位置可以改变

2. 通过规范确定要解码部分消息字段编码

确定要解码的信令消息，例如我开头提到的信令消息，属于AMF之间namf-comm服务类型消息参照规范29.518，找到对应消息：

POST …/ue-contexts/{ueContextId}/transfer (UeContextTransferReqData)

要解码的内容是UeContextTransferReqData，从data model里找对应消息：

指示N1 Message Content binary data, See subclause 6.1.6.4.2

指示参考24.501的8.2.5 REGISTRATION REQUEST message，在查找24.501的8.2.5时发现是Authentication reject，而registration request在8.2.6，应该是因为我的规范29.518是R15,24.501是R16的原因，所以没对上。我们参考8.2.6即可，如下8.2.6内容：

3. 找到V格式(硬编码)和TV/TLV格式编码的分界线

我们看到，规范registration request nas前7个字段是V格式编码，后面都是TLV或者TV格式编码。TV和TLV部分有IE type好解码，V格式是依赖位置的硬编码，咱们先找到他们的分界线，以防出现出错。
例如举例要解码的部分如下：

这部分原始码流copy如下：

V格式最后一个字段是“5GS mobile identity”，参照9.11.3.4

最后字段是5G-TMSI，这与消息头中5G-GUTI中5G-TMSI对应，消息头中5G-TMSI：
POST /namf-comm/v1/ue-contexts/5g-guti-46000086441E8E4421A/transfer
其中E8 E4 42 1A是5G-TMSI，从copy的字段找到E8 E4 42 1A，就能将V和T类型编码分开了，如下红线前是V格式，红线后是T格式。

4. 对照字段规范逐个字段进行翻译解码

• T格式内容解码：
  
  TLV 10:01:03 5GMM capability, 参照9.11.3.1看字段意思
  TLV 2e:02:e0 e0 UE security capability,9.11.3.54
  TLV 2f：02： 01 01 NSSAI，9.11.3.37
  TLV 17：07：e0 e0 c0 c0 01 80 30 ，S1 UE network capability， 9.11.3.48
  TLV 2b：01 ：00，UE status ，9.11.3.56
  TLV 18：01： 00UE’s usage setting 9.11.3.55
  后面91 53 01 01 0d 0a 是固定字段不在需要解码
• V格式内容解码
  前部分V格式也可解码，稍微麻烦一点，如果能参照真实N2口的registration request进行推测解码，会比较容易一些：
  如红框之间是V格式内容，可逐个参照解码：
  

分享记录：2022-06-28，跑完步回来，趁着汗水带来的好心情，于23:50完成分享。