本帖最后由 wuyou125 于 2021-5-18 14:50 编辑
相关文章会在公众号同步更新。公众号:5G通信大家学
持续更新的相关5G内容都是直接根据3GPP整理,保证更新内容的准确性,避免通过二手,甚至多手的资料,以讹传讹误导网友。
在先容完流程详解后,会整理专题内容,比如切片、服务发现、QoS流端到端的映射等内容,各位同学不仅可以纵向学习常识点,横向也会将常识关联起来,达到深入理解灵活运用的目的。
1.3.2.3 优享篇
漫游场景下,AMF来决定一个PDU Session是建立为LBO漫游还是归属地漫游(判断依据是AMF下载的SMF选择签约数据)。不论哪种漫游方式,用的AMF都是漫游地的。因为基站是和AMF强相关的,基站在哪,AMF就要在哪。 LBO漫游场景和非漫游场景的流程基本一致,所以流程图画在了一起,唯一区别是AMF、SMF、UPF、PCF是漫游地的还是归属地的。LBO场景只有AUSF、UDM、hPCF是归属地的。 1.3.2.3.1 PDU Session EstablishmentRequestUE发送PDU Session Establishment Request消息给AMF,该消息承载在UL NAS TRANSPORT5GMM消息中。UL NAS TRANSPORT消息携带的信息有:S-NSSAI、UE请求的DNN、PDU Session ID、Request type、Old PDU Session ID、Payload container。其中: (1)Payload container type的取值为0001时,表示Payload container中包含的是N1 SM消息,也就是:PDU Session Establishment Request消息。 (2)如果UE策略中URSP规则没有关联的S-NSSAI、或者没有匹配上URSP、或者UE本地及缺省URSP中都没有配置S-NSSAI,UE在PDU会话建立中不会携带S-NSSAI信息。也就是说在建立PDU会话的时候,UE可以不携带切片信息。目前大部分手机还不支撑UE策略,所以目前在网络中抓取到的信令在PDU会话建立消息中基本都见不到切片信息。 (3)Request type标识该5GSM请求的类型,分为:初始请求、现存PDU会话建立请求等,详见下图: 下图是UE发送给AMF的消息UL NAS TRANSPORT消息携带PDU Session Establishment Request请求的说明图: 下面看一下5GSM消息PDU Session EstablishmentRequest的定义: 重点IE先容: - PDUSession ID 新建立PDU会话时UE分配的PDU Session ID,或者现存PDU会话、PDN连接已经分配的PDU Session ID。 对于3GPP和non-3GPP间切换的PDU会话或者现存PDN连接的切换,切换到5G时包含在PDU SESSIONESTABLISHMENT REQUEST消息和UL NAS TRANSPORT消息中的PDU Session ID都是UE之前保存的。PDU会话和PDN连接对应的S-NSSAI也是原有的,将其包含在UL NAS TRANSPORT消息中。 - PTI 该值大家在先容UE策略时讲过,这里再次出现,其和会话建立过程中的区别只是PTI在消息中的位置不同(这里是第三个字节,UE策略中是消息的第一个字节),意义一样。它用于识别一个事务(Transaction),也就是:通过PTI可以将多个相关联的消息关联起来,表示这几条消息是为了同一个事而交互的。 会话建立过程中的PTI由UE分配。 - SSC Mode 当UE请求建立的PDU会话类型是IP类型时,可以不包含该IE,或者设置为三种模式中的任何一种。 "Ethernet"或者"Unstructured"类型的PDU会话只支撑Mode 1或者Mode 2。需要注意的是,4G到5G切换的PDN连接只能设置为:Mode 1。因为在4G中只支撑SSC Mode 1场景,提供IP地址的连续性。 - Integrity protection maximum data rate UE向网络指示的、UE侧支撑的上行和下行用户面数据完整性保护功能开启时的最大数据速率。 - 5GSM capability 该IE中包含UE的会话支撑能力,也就是UE侧在某些PDU会话特性方面支撑与否的信息都包含在这里,如:Reflective QoS supported、Multi-homed IPv6 PDU sessionsupported、Ethernet PDN type in S1 mode supported、Transfer of port management information containers supported等。其中:反射QoS支撑的PDU会话类型是"IPv4"、"IPv6"、"IPv4v6"或者"Ethernet"。如果是4G中建立的"Non-IP"类型的PDN连接切换到5G时映射为"Ethernet"类型的PDU会话。 该IE包含的信息是由SMF进行处理的。 UE请求建立新的PDU会话或者将PDN连接从4G切换到5G时会包含该IE。 - Maximum number of supported packetfilters PDU会话最多支撑的数据包过滤器的数量。当PDU会话类型为:"IPv4"、"IPv6"、"IPv4v6" 或者"Ethernet"时,PDU会话可以支撑16个以上的数据包过滤器(packet filters)。 - Always-on PDU sessionrequested UE请求建立always-on PDUSession时包含该IE。 目前ToC网络的UE一般都会请求建立“always-on PDU Session”类型的会话。上网数据频繁是一方面,另一方面,因为ToC网络的语音通话,IMS网络的信令数据还需要随时发送,如果不请求为always-on类型的会话,会增加语音通话建立的时延。 - SM PDU DN request container UE请求建立的PDU会话需要外部网络进行鉴权和授权时,UE在该IE中提供相关信息。 - Extendedprotocol configuration options 该IE的作用是: (1)传递和会话激活相关的网络协议相关参数 (2)传递外部网络协议或者应用相关的协议数据,如配置参数、错误码、消息、时间等。 如果UE开启VOLTE功能,UE想要获取IMS网络的P-CSCF的IP地址信息需要在IE中指示网络。该IE中可以包含非常丰富的信息,例如:UE想要使用DHCPv4进行IPv4地址分配、UE支撑Reliable Data Service、UE支撑DNS over (D)TLS、3GPP PS data off UE status、5GSM cause value、ATSSS request等等,详见TS 24.008。 - IP header compressionconfiguration UE请求的PDU会话类型是IP类型,并且注册过程中UE和网络都支撑"Control Plane CIoT 5GS optimizationsupported"和"IP header compression for control plane CIoT 5GS optimizationsupported"时,可能会包含该IE。 该IE用于协商ROHC信道配置参数,也可以提供额外的头压缩配置参数。 - Portmanagement information container UE请求建立"Ethernet"类型的PDU会话时,如果UE支撑传递Ethernetport management service消息时会包含该IE,详见TS 24.519。 从上面PDU SessionEstablishment Request和UL NAS TRANSPORT消息的定义可以看出来,PDU Session ID信息在两条消息中都包含。建立会话的其它关键参数S-NSSAI、DNN也包含在UL NAS TRANSPORT消息中。其它信息包含在PDUSession Establishment Request中。都是创建会话的关键参数,为什么分开存放,一部分处在庙堂之上,一部分又居江湖之远呢? 大家前面叙述过,AMF在建立会话的过程中,需要检查UE分配的PDU Session ID是否合法。对于切片S-NSSAI、DNN信息,AMF还需要根据用户的签约信息对他们进行纠正,并根据这些信息来选择SMF。也就是说,UL NAS TRANSPORT消息包含的是AMF在会话建立过程中需要使用的信息,而PDU SessionEstablishment Request消息中包含的信息是SMF需要处理的信息,AMF只需要做透明转发就可以。这样,责任划分明确,免得有网络问题AMF和SMF责任摘落不清。AMF本来就是个二手房中介的角色,如果什么信息都经过他的手,凭空增加了很多腐败空间,也不符合嵌入式风险防控的要求。可见,5G虽然只是通信技术,但是大家日常生活中的处事哲学也会经常得到体现。
|