4G与5G会话建立流程描述以及对比

• 1. 用于会话建立流程的EPC网元与5GC网元
• • 1.1 EPC架构
  • 1.2 5GC架构
  • 1.3 有关会话建立流程中网络功能分离的描述
• 2. EPC与5GC会话建立信令流程对比
• • 2.1 EPC会话建立流程
  • 2.2 5GC会话建立流程
  • 2.3 会话建立信令流程中的异同点
  • • 流程触发
    • 签约数据获取
    • 会话标识分配
    • • **控制面：**
      • **用户面：**

注意：本文着重描述 3GPP-非漫游场景下的 会话建立过程的异同，且 5GS中仅考虑在 3GPP接入-非漫游-SA组网方式下的会话建立过程，即 3GPP TS-23.502中， PDU Session Establishment中非漫游场景下的第一种情况，如有必要，后续会跟进 3GPP-漫游场景下的 会话建立过程异同对比的文章。

1. 用于会话建立流程的EPC网元与5GC网元

1.1 EPC架构

关于EPC 会话建立流程中，使用的网元及其简单描述：

• MME：移动性管理实体（Mobile Management Entity），由MME中的ESM（EPS Session Management）模块执行会话管理的相关功能。ESM模块的主要任务是与UE在NAS层中，有关SM（Session Management）信令的交互。
• HSS：归属地用户签约服务器（Home Subscriber Server），存储UE的签约数据，在SM过程中，用来获取用户签约的APN（Access Point Name），PDN Type等信息。
• S-GW：服务网关（Service-Gateway），在用户面上，作为用户接入PDN网络的“移动锚点”；在控制面上，主要用于转发来自MME的S11接口的信令，并与P-GW在S5/S8接口上进行信令交互。
• P-GW：包数据网络网关（PDN-Gateway），在用户面上，作为用户接入PDN网络的“业务锚点”；在控制面上，用于IP地址分发，存储用户上下文以提供“永久在线”。

关于EPC 会话建立过程中，几个重要概念需要指出：

• PDN Session：PDN会话，在EPC中，会话的概念强调UE和P-GW端到端的对应，更加强调控制面的功能，而不关心底层提供会话的具体实现（即接下来要提到的承载的概念）。在会话中，UE关注APN、PDN Type以及UE在此会话中被分配的IP地址；而P-GW则关注UE的SM上下文（存储UE在此会话中的参数，如APN、IP地址等）。
• EPS Bear：EPS承载，在4G中，EPS Bear由三部分承载组成，分别为无线承载、S1承载、S5/S8承载。承载则更加注重用户面的功能，关注的重点在QoS质量，承载建立的完整性。
• 移动锚点：S-GW一个重要的功能就是作为UE在用户面的移动锚点，UE与S-GW是一一对应的关系，UE建立的多个Session，用户面数据也要经同一S-GW转发到各个P-GW。移动的意思是指S-GW会随用户的移动可能会发生变化。
• 业务锚点：P-GW一个重要的功能就是作为UE在用户面的业务锚点，Session与P-GW是一一对应关系，不同的Session对应的P-GW不同，也就意味着对应Session中，分配给UE的IP地址是不同的。即便用户移动切换了多个S-GW，但用户通过此APN接入到的P-GW是不变的。

  

  (图片转自微信公众号：猫呆呆的工作间)
• 4G QoS保障：Quality of Service，一个会话的服务质量保障在4G中是通过不同承载体现的。一个会话中，可以有多个不同的承载，同一的承载内的数据流，其转发策略，优先级是相同的。这就好比你通过中国移动提供给你的APN：cmnet，与EPC的P-GW建立了一个Session，但是对于浏览网页和玩王者荣耀所需要的QoS是不同的，可能你浏览网页用默认承载就可以实现QoS保障，但对于玩王者荣耀，再使用默认承载传输实时的游戏数据，时延就可能过大，需要在此Session中建立一个专用承载以保障游戏的QoS。

  

  (图片转自微信公众号：猫呆呆的工作间)

1.2 5GC架构

关于5GC 会话建立流程中，使用到的网络功能及其简单描述

• SMF：会话管理功能（Session Management Function），主要有两个主要的功能：面向SBI接口，SMF要接收、处理、回复来自其他NFs（本文专指AMF）的NAS-SM消息，该部分继承了原4G中MME中的ESM模块的功能；面向N4接口，SMF要与UPF进行交互，以N4消息的形式告知UPF按照何种规则处理来自用户面的数据流，该部分继承了原4G中，S-GW与P-GW控制面的功能。
• UPF：用户平面功能（User Plane Function），5GC中唯一的用户面网元，基于SMF下发的转发规则，UPF作出响应的转发处理，同时作为5GS（5G System）用户平面与DN（Data Network）之间的网关。该部分继承了原4G中S-GW与P-GW用户面的功能。
• AMF：接入和移动性管理功能（Access and Mobility Management Function），AMF在会话建立过程中，主要负责将SMF发送到AMF中的NAS-SM、SM Information分别基于N1、N2接口转发给UE和gNB，以上两个消息的信息来自于SMF使用AMF提供的Namf_Communication Service中的operation：N1N2MessageTransfer；UE或者gNB发送给SMF的有关SM的消息，AMF将使用Nsmf_PDUSession Service中的operation：CreateSMContextRequest/UpdateSMContextRequest 实现信息转发。

关于5GC 会话建立过程中，几个重要概念需要指出：

• SBI：基于服务的接口（Service Based Interface）。为了网元具备更好的扩展性，以及灵活性，网络功能被拆分为不同的微服务，每个网元将自己的SBI接口暴露在外部，允许合法的网元请求服务，本质上是一种服务器-客户端交互模式，SBI协议栈如下图所示，并给出一个调用SBI接口请求SMF服务的例子。

  

  POST http://127.0.0.1:8080/nsmf-pdusession/v1/sm-contexts
• Service：在5GC的控制面中，NF与NF之间的信令交互均是在SBI接口上，以请求服务（Service Request）/服务响应（Service Response）的形式进行的。每个Service都有若干个operation来详细描述一个服务的建立，如上述对SMF中的PDUSession Service有CreateSMContext和UpdateSMContext。（实际上，PDUSession Service的operation不止以上两个，但在本文中描述的场景下，会话建立这项服务用SMF提供的这两个operation就足够了）
• 5G QoS：4G中QoS的保障是通过不同的承载体现的，而5G中，QoS的保障是通过不同的QoS Flow来体现的。与承载的概念类似，同一QoS Flow下的数据流在用户面的转发策略是相同的，但与承载不同的是，一个PDU Session的多个QoS Flow并不需要逐一经过控制面信令交互来实现建立过程，就好比上面所说的手机通话与浏览网页的例子，对于手机通话而言，在会话层面，没有建立QoS Flow的额外信令开销。

1.3 有关会话建立流程中网络功能分离的描述

目前由EPC演进到5GC的核心网架构可由上图简单描述，图中的5GC架构采用了参考点(Reference Point)模式进行描述，可以较为清晰的看清演进过程。但请注意，N8、N10与N11实际上都是一个SBI的接口。

2. EPC与5GC会话建立信令流程对比

2.1 EPC会话建立流程

在此部分展开之前，强烈建议把流程图放在文章的旁边对照阅读，除非你对流程非常熟悉，不然读一会儿就蒙圈…

上图出自3GPP TS 23.401 section：5.3.2 Attach procedure。作者想描述EPC会话建立请求（PDN connectivity request）包含在Attach Request消息一同发送到MME的情况。对于标准中，UE附着成功后，再请求建立会话的过程，与上述类似，只不过后者的情况更加纯粹，并不包含在Attach流程中。前者的这种情况，我们称之为搭车。

注：用这张流程图只是为了说明会话建立流程采用的普遍形式，但为了不过多涉及有关注册的相关内容，下面的对流程的解说也尽可能的以会话建立为主。

1-2： Attach Request：属于NAS层消息，作为附着流程的触发源，这个NAS消息有一个专门用于存放PDN connectivity request的NAS-SM消息的容器：ESM container。这个PDN connectivity request将作为整个EPC会话建立流程的触发源，触发点在MME的ESM模块。

注：我们选择以搭车的情况描述，所以在Attach流程中，这个container是必需的。Attach与PDN connectivity可以分开进行，但必须要求Attach流程先行完成，即：PDN connectivity可以不搭Attach的车，但Attach这辆车必须先行发动。

3-6：身份信息获取、鉴权、进入安全模式、可选加密，都属于Attach流程的关键操作，此处不展开。

7-10（可选）：删除有关此UE在此MME中之前建立的所有Session。为什么要做这一步呢？其原因主要在于：如果上次UE在此MME的Detach中，没能完全删除有关此UE的Session（有这种可能），且此UE在这个MME上又进行Attach，那就必须删除上次Attach相关的所有Session。本质上是对UE视每次Attach不同，对Session的初始化。

注：下面网元的交互是EPC会话建立流程的关键

11：Update Location，与8相呼应，MME获取HSS中，有关此UE的签约数据。主要是：EPS subscribed QoS profile 以及 subscribed APN-AMBR。

12：Create Session Request，由MME以GTP-C消息的形式发给S-GW，消息中主要包含：EBI、APN、Default EPS Bearer QoS、PDN Type以及APN-AMBR；消息中还包含一个重要信息信息S11 MME GTP-C TEID，用此ID唯一标识控制面中，Session在S11的MME侧的节点。S-GW收到此消息后，会为此Session建立一个默认承载的上下文。

13：Create Session Request，由S-GW以GTP-C消息的形式发给P-GW，消息的主要信息来自于12，除此之外，还有两个重要信息：S5/S8 S-GW GTP-C TEID与S5/S8 S-GW GTP-U TEID分别标识S5/S8在控制面和用户面在S-GW侧的节点。P-GW收到此消息后，会为此Session建立一个默认承载的上下文

14：P-GW与PCRF的交互，P-GW与PCRF（策略与计费规则功能单元）进行交互，对用户后续的业务数据流和IP承载资源的策略与计费进行决策，由PCRF告知P-GW该UE的应该使用多少承载资源。简而言之，PCRF会对UE的APN-AMBR以及QoS做出一定的约束。

15：Create Session Response，由P-GW以GTP-C消息的形式发给S-GW，由P-GW最终决定APN-AMBR与Default EPS Bearer QoS这些与承载资源有关的信息，并发送给S-GW，除此之外还有两个重要信息：S5/S8 P-GW GTP-C TEID与S5/S8 P-GW GTP-U TEID分别标识S5/S8在控制面和用户面在S-GW侧的节点。

注：15结束以后，S-GW与P-GW已相互获知在S5/S8接口的用户面TEID，即S5/S8承载已经建立，已经可以发送来自PDN网络的业务数据至S-GW。剩下就是建立S1-U承载与无线承载。

16：Create Session Response，由S-GW以GTP-C消息的形式发给MME，消息主要内容来自于15，除此之外，还有两个重要信息：S11 S-GW GTP-C TEID与S1-U S-GW GTP-U TEID。前一个ID主要用于打通此Session在EPC的控制面隧道；而后者，则需要让MME转发给eNodeB用以建立S1-U上行承载。

注：16结束以后，此Session在EPC的控制面隧道已经打通。

17:Initial context setup request，是一个S1AP层的消息，承载NAS层的消息：Attach accepted；同样的，这个NAS消息与Attach request消息一样，包含着ESM container，实际上也是一个NAS-SM消息：Activate default EPS bearer context request（又长又晦，打着真累…）里边包含着一些QoS参数、PDN地址和APN-AMBR。由于基站只解析S1AP层消息，那上面的来自S-GW的用户面ID以及QoS参数如何由MME告知给基站呢？没办法，只能让MME在S1AP层中添加这些信息，分别是：gTP-TEID与E-RAB Level QoS Parameters。

注：流程图中17位置，除了上面所说的S1AP消息外，还可能回复的是：DownlinkNASTransport，这是针对1中不搭车的情况，如果选择搭车，则回复Initial context setup request。

18-19:RRC connection Reconfiguration，eNodeB和UE之间建立起无线承载的过程，这部分不赘述（主要是不太了解…），咱们将更多精力放在EPC侧。

20:Initial context setup response，是针对上面S1AP消息的响应。注意，该消息不包含NAS消息，只是对上面S1AP消息的响应，消息中包含着一个gTP-ID。没错，这就是要发给S-GW，用于建立S1-U承载的eNodeB用户面ID。

注：这个S1AP消息是发给MME的，因此还需要MME进行转发，但是…MME并不着急，还要等一下UE的响应。同时，要注意，由于UE和eNodeB的无线承载已经建立，eNodeB已经知道S-GW用户面的TEID（即S1-U上行承载已经建立），S-GW与P-GW之间的S5/S8承载已经建立，因此可以传送上行的用户面数据。

21-22:UE使用RRC direct transfer消息将NAS层消息封装其中，再由eNodeB转发给MME。同样的。这个由eNodeB转发给MME的消息，上层是一个NAS消息（Attach complete）。其中，ESM Container：Activate default EPS bearer context response。MME收到这个消息，就可以放心的去告诉S-GW关于eNodeB的用户面TEID了。

23-24:Modify EPS Bearer Request/Response，S-GW最终获知eNodeB的TEID以及地址，完成S1-U下行承载的建立，如果MME需要报告UE的区域信息，则要同时告知S-GW与P-GW，S-GW要完成此信息的传递，即：23-a,b；否则，不需要再通知P-GW。最后，S-GW要回复MME，已经完成S1-U承载建立，作为对Modify的响应。

25-26:Notify request/response：MME告知HSS关于UE在此Session上承载的相关信息，HSS存储信息，完成一次Session的默认承载建立流程。

2.2 5GC会话建立流程

依然强烈建议流程图与流程描述对照阅读

5GS的会话建立流程更加纯粹，PDU Session Establishment Request（相当于PDN connectivity Request）完全独立于Registration Request，即无法搭车。但是AMF通知SMF处理PDU Session的请求之前，AMF需要先行完成Registration（除非是Emergency Registered，超出本文讲解范围）。即：4G会话建立流程可以全程搭Attach的车，但是在5G中，AMF的Registration流程和SMF的PDU Session Establishment是完全独立的。（网元功能更加明确，类似4G穿插进行反而不易让初学者理解）

1：PDU Session Establishment Request，UE请求建立PDU会话，这条消息包含在NAS消息中的N1 SM container。PDU Session Establishment Request主要内容有：PDU Session ID、Requested PDU Session Type、Request SSC mode。AMF是不解析N1 SM container的内容的，但AMF也会获知一些在NAS中有关SM的信息，如：S-NSSAI(s)、PDU Session ID、Request Type以及DNN。

注： Requested PDU Session Type是指IPv4、IPv6这些参数，而Request Type是指Initial Request还是Existing PDU Session， Existing PDU Session用于已经建立一个PDU Session的情况，不属于本文讨论的内容。

2：AMF选择为此UE服务的SMF，超出本文的讨论范围，咱们重点关注SMF的相关处理，感兴趣的同学可以参考clause 6.3.2 of TS 23.501 [2] and clause 4.3.2.2.3。

3：Nsmf_PDUSession_CreateSMContext Request，AMF选择好SMF以后，便向此SMF请求创建PDU Session上下文的服务。此条请求的主要目的有三个：建立AMF与SMF关于此UE Session的联系；传输有关此UE的签约数据、触发整个5GC会话建立流程。请求中主要包含：SUPI、DNN、S-NSSAI(s)、PDU Session ID、AMF ID、以及N1 SM container (PDU Session Establishment Request) 。即：AMF获知的签约数据以及UE给SMF的SM消息。

4：Subscription retrieval/ Subscription for updates（可选），SMF向UDM获取签约数据，或者更新签约数据。AMF在3中会告知SMF用户的签约数据，本条是可选的。

注：AMF的Registration流程先行完成，因此在向SMF请求之前，AMF已经在Registration流程获知UDM（类似于4G中的HSS）有关UE的签约数据，所以在请求的时候，会带一部分UE的签约数据给SMF。总之，SMF会在4结束后，最终获知UE的签约数据，并用签约数据约束会话建立过程中的一些参数。

5：Nsmf_PDUSession_CreateSMContext Response，响应中主要包括：SM Context ID、N1 SM container(PDU Session Reject)。如果SMF在过程3、4出现异常，container应包含Reject消息，表示立即中断PDU Session Establishment；否则，仅通知AMF，SM Context已经建立，且ID为XXXX。

注：未出现异常，上下文已经建立，不代表这条消息就带着PDU Session Accept。由于SMF与UPF之间的关联还没建立，因此不需要container带着PDU Session Accept通知UE，进而减少了不必要的信令开销，只需要告诉AMF：SM Context已经建立，AMF就默认SMF已经accept，PDU Session Accept会在后边告知UE，以一种更加高效的形式~。

6：Secondary authentication/authorization （可选），二次鉴权/授权，这一部分不属于咱们讨论的范围之内，感兴趣的同学可以查看TS 23.501 [2] clause 5.6.6 。

7：PCF选择与会话策略建立。如果SMF采用动态PCC，则SMF需要选择一个PCF，具体选择的方法详见TS 23.501 [2], clause 6.3.7.1；否则，SMF可以应用本地策略。获取到应用于PDU会话的默认PCC规则以后，SMF可以根据用户的计费策略调整UPF的转发规则。

注：PCF与SMF的交互仅简单描述，我们只需要知道SMF和PCF交互的主要目的。

8-9：SMF选择一个（或多个）为UE服务的UPF并为UE的Session分配一个IP地址（基于Requested PDU Session Type），用户面数据转发将会在此UPF上进行；同时，SMF可能会与PCF交互以修改的PCC规则，同时告知PCF在这个Session上分配的IP地址。

注：SMF将会为UE的每个Session分配一个IP地址，即便是选择多个UPF为UE的一个Session服务，那也是分配一个，本文中，我们考虑一个UPF为一个Session服务的情况。

10a：N4 Session Establishment Request，SMF向选择的UPF发起N4会话建立请求，试图建立SMF与UPF在控制面的关联(Association)。此消息中主要包含：IP地址、CN Tunnel Info、Packet detection、enforcement 以及reporting rules。其中，CN Tunnel Info是由SMF分配给UPF，UPF可以通过此信息标识此Session在N4接口上的SMF侧节点，所以，当UPF给SMF传送信令的时候，只要带着这个CN Tunnel Info，SMF就可以知道是关于哪个Session的信令。

10b：N4 Session Establishment Response，UPF向SMF回送N4会话建立响应，响应中包含一个重要的信息：CN Tunnel Info，但这个CN Tunnel Info是UPF分配给SMF的，所以，当SMF给UPF传送信令的时候，只要带着这个CN Tunnel Info，UPF就可以知道是关于哪个Session的信令。

注：CN Tunnel Info与Session是捆绑在一起的，CN Tunnel Info是一个写入SMF与UPF关于此Session的SM上下文的重要信息。由10、11过程，SMF与UPF在控制面上对此Session的关联(Association)就建立起来了，其实也是隧道的概念，只不过UPF与SMF之间用的协议，不再是GTP-C，而是PFCP，但归根结底，道理是一样的。

11:Namf_Communication_N1N2MessageTransfer，SMF向AMF请求传输N1接口上的消息与N2接口上的消息服务。显然，这是SMF想让AMF分别给UE和gNB转发有关SM的相关信息。（并且，SM的具体内容还不想让AMF知道…也没必要知道，因为网络功能已经分离了）。这条请求非常重要，我们需要展开讲，请求的主要内容有：PDU Session ID、N2 SM information以及N1 SM container。

PDU Session ID：给AMF看的，AMF需要知道为UE的哪个Session提供Transfer服务，但不需要获知具体内容。

N2 SM information：给gNB看的，主要内容包含：PDU Session ID、QFI(s)，QoS Profile(s)，CN Tunnel Info，Session-AMBR,PDU Session Type。其中**QoS Profile(s)**用于gNB对一个Session多个QoS Flow的配置；CN Tunnel Info则用于标识此Session在N3接口UPF侧节点。

N1 SM container：给UE看的，是一个SM消息，即前面所说的Session Established Accept。主要内容包含：QoS Rule(s)、S-NSSAI(s) 、DNN、IP地址以及Session-AMBR。其中 ，QoS Rule(s)用于UE对一个Session多个QoS Flow的配置；IP地址 用于UE从UPF出口以后的数据路由。

注：N2 SM information中的CN Tunnel Info是一个用户面的标识，与UE的一个Session捆绑在一起。

这里提到了QoS Profile(s)与QoS Rule(s)，与4G逐一信令流程建立承载不一样，5G中以这种方式一次性可以配置一个Session多个QoS Flow，大大提高了信令效率。这也是5G不再用承载概念的重要原因之一。

12：N2 PDU Session Request，这是一个NGAP消息，基站解析NGAP消息获取N2 SM information，而不解析上层的NAS消息。经过12，基站便可在用户面上向UPF传输上行数据。

13：UE与gNB交互，建立针对此Session的无线传输通道，与4G一样，这一部分不太了解，其目的是为了交付来自AMF的NAS层消息，针对Session Established流程而言，则是交付N1 SM container。经过13，UE与gNB在用户面的无线传输通道建立完毕，UE便可以向UPF传输上行数据，整个5GS上行数据传输隧道已被打通。

14：N2 PDU Session Response，封装在NGAP消息中的还有一个N2 SM information，是gNB希望AMF交付给SMF的。N2 SM information中有一个重要的参数：AN Tunnel Info，这个标识了Session在N3接口的gNB侧节点。一旦此标志由SMF交付给UPF，Session在N3接口上的下行隧道就打通了。

15：Nsmf_PDUSession_UpdateSMContext Request ，AMF使用SMF提供的更新SM上下文服务，向SMF交付N2 SM information。N2 SM information中有一些关于QoS Flow(s)的参数，SMF可以及时更新Session上下文的内容。

16a：SMF向UPF发送N4 Session Modification Request，希望传输来自gNB的AN Tunnel Info来打通N3的下行隧道，并最终将下行的转发规则告知UPF。

16b：UPF向SMF发送N4 Session Modification Response，UPF最终获知AN Tunnel Info，Session在N3接口上的下行隧道已被打通，因此整个5GS下行数据传输隧道被完全打通。UPF更新关于Session的上下文，并向SMF报告。

17：Nsmf_PDUSession_UpdateSMContext Response，SMF收到UPF下行隧道建立结果以后，对AMF的更新SM上下文请求进行确认。整个5GS的会话建立过程至此结束。

2.3 会话建立信令流程中的异同点

本节将从以下方面来描述4G与5G在会话建立流程上的差异

流程触发

4G中，由PDN connectivity request触发EMM的ESM模块的会话建立请求流程；

5G中，由PDU Session Establishment request触发SMF的会话建立请求流程；

前者因为ESM模块与EMM模块一并包含在MME中，因此Attach流程可能会包含着会话建立流程，但这只是针对EMM而言。对于ESM，只需要专注于会话建立的触发即可。（不需要考虑搭车与不搭车的情况）。

后者由于网络功能分离的缘故，SMF只需要专注于会话建立的触发即可。

签约数据获取

4G中，在MME与S-GW发出会话建立请求之前，需要向HSS发起请求，获取用户签约数据，这个过程可以在ESM模块中触发。

5G中，SMF与UPF发出N4会话建立请求之前，使用UDM提供的服务来获取用户的签约数据。

会话标识分配

由于隧道标识的种类比较多，所以打算从控制面和用户面的角度去区分标识，以实现对比。

控制面：

4G中，建立MME、S-GW与P-GW针对一个Session的控制面通道，采用的是GTP-C的TEID标识。每个网元都需要知道通道对端网元的TEID，在信令交互的时候，包头要带上对端的TEID，以让对端区分出是关于哪个Session的信令。

5G中，建立SMF与UPF针对一个Session的控制面通道，采用的是PFCP的CN Tunnel Info标识。SMF与UPF都会给对端分配CN Tunnel，在信令交互时，要带上对端分配的CN Tunnel Info。

用户面：

4G的用户面中中，一个Session可以建立多个EPS承载，每一个EPS承载都需要一个UE、eNodeB、S-GW与P-GW针对承载而建立的用户面隧道。不考虑UE与gNB之间的无线承载，在gNB与S-GW之间的S1-U承载、S-GW与P-GW之间的S5/S8承载，都是采用了GTP-U的TEID，且都需要对端获知。与Session在控制面建立通道不同的是，用户面不是针对Session建立隧道，而是针对承载建立隧道。

(图片转自微信公众号：猫呆呆的工作间)

5G的用户面中，一个Session可以建立多个QoS Flow，每个Session都需要一个UE，gNB、UPF针对Session而建立的用户面隧道。不考虑UE与gNB之间的无线承载，在gNB与UPF之间采用了GTP-U的TEID，且都需要对端获知。Session的每一个QoS Flow都需要用一个QFI（QoS Flow Identity）进行标识，由QoS rules与QoS profile进行管理。

好了，4G与5G会话建立流程描述以及对比就写到这里了，感谢您阅读至此处，下一篇想研究一下有关5G Session的具体机制～

文中若有任何不足之处，欢迎留言，感谢您的批评指正。