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


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

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

1.1 EPC架构

3GPP接入-非漫游架构

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

  • MME:移动性管理实体(Mobile Management Entity),由MME中的ESM(EPS Session Management)模块执行会话管理的相关功能。ESM模块的主要任务是与UENAS层中,有关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架构

3GPP接入-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中的operationN1N2MessageTransfer;UE或者gNB发送给SMF的有关SM的消息,AMF将使用Nsmf_PDUSession Service中的operationCreateSMContextRequest/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 requestNAS-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,消息中主要包含:EBIAPNDefault EPS Bearer QoSPDN 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 TEIDS5/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-AMBRDefault EPS Bearer QoS这些与承载资源有关的信息,并发送给S-GW,除此之外还有两个重要信息:S5/S8 P-GW GTP-C TEIDS5/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 TEIDS1-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 ContainerActivate 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 IDRequested PDU Session TypeRequest SSC mode。AMF是不解析N1 SM container的内容的,但AMF也会获知一些在NAS中有关SM的信息,如:S-NSSAI(s)PDU Session IDRequest 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会话建立流程。请求中主要包含:SUPIDNNS-NSSAI(s)PDU Session IDAMF 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 IDN1 SM container(PDU Session Reject)。如果SMF在过程34出现异常,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 InfoPacket detectionenforcement 以及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上下文的重要信息。由1011过程,SMF与UPF在控制面上对此Session关联(Association)就建立起来了,其实也是隧道的概念,只不过UPF与SMF之间用的协议,不再是GTP-C,而是PFCP,但归根结底,道理是一样的。

11:Namf_Communication_N1N2MessageTransfer,SMF向AMF请求传输N1接口上的消息N2接口上的消息服务。显然,这是SMF想让AMF分别给UEgNB转发有关SM的相关信息。(并且,SM的具体内容还不想让AMF知道…也没必要知道,因为网络功能已经分离了)。这条请求非常重要,我们需要展开讲,请求的主要内容有:PDU Session IDN2 SM information以及N1 SM container
PDU Session ID:给AMF看的,AMF需要知道为UE的哪个Session提供Transfer服务,但不需要获知具体内容。

N2 SM information:给gNB看的,主要内容包含:PDU Session IDQFI(s)QoS Profile(s)CN Tunnel InfoSession-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)DNNIP地址以及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 informationN2 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的具体机制~

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

©️2020 CSDN 皮肤主题: 深蓝海洋 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值