CN116962994A - 多播通信方法、装置、计算机可读介质及电子设备 - Google Patents

多播通信方法、装置、计算机可读介质及电子设备 Download PDF

Info

Publication number
CN116962994A
CN116962994A CN202310898014.9A CN202310898014A CN116962994A CN 116962994 A CN116962994 A CN 116962994A CN 202310898014 A CN202310898014 A CN 202310898014A CN 116962994 A CN116962994 A CN 116962994A
Authority
CN
China
Prior art keywords
multicast
address
information
mbs
multicast service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310898014.9A
Other languages
English (en)
Inventor
熊春山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202310898014.9A priority Critical patent/CN116962994A/zh
Publication of CN116962994A publication Critical patent/CN116962994A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/26—Special purpose or proprietary protocols or architectures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/30—Resource management for broadcast services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请的实施例提供了一种多播通信方法、装置、计算机可读介质及电子设备。该多播通信方法，包括：接收策略控制功能实体发送的URSP信息，所述URSP信息中包含有支持多播业务的URSP规则；根据需要激活的多播业务上下文所对应的多播网络地址，查询所述支持多播业务的URSP规则，得到网络切片信息和数据网络名称信息；基于所述网络切片信息和所述数据网络名称信息激活用户设备的MBS上下文信息，以加入所述多播网络地址对应的多播组中进行多播通信。本申请实施例的技术方案可以减少多播业务上下文的激活流程，有利于降低网络部署的复杂性。

Description

多播通信方法、装置、计算机可读介质及电子设备
本申请是2020年05月13日提交的、申请号为202010403660X、发明名称为“多播通信方法、装置、计算机可读介质及电子设备”的分案申请。
技术领域
本申请涉及计算机及通信技术领域，具体而言，涉及一种多播通信方法、装置、计算机可读介质及电子设备。
背景技术
“多播”也可以称为“组播”，是将相同的内容传输给多个目标节点，如传输给多个UE(User Equipment，用户设备)。采用多播方式，既可以实现一次向所有目标节点传送数据，也可以达到只对特定对象传送数据的目的。然而，相关技术中激活多播上下文及多播业务会话的流程繁琐，增加了网络部署的复杂性，并且也影响了多播通信的效率。
发明内容
本申请的实施例提供了一种多播通信方法、装置、计算机可读介质及电子设备，进而至少在一定程度上可以减少多播上下文的激活流程，有利于降低网络部署的复杂性。
本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。
根据本申请实施例的一个方面，提供了一种多播通信方法，包括：接收策略控制功能实体发送的URSP(UE Route Selection Policy，用户设备路由选择策略)信息，所述URSP信息中包含有支持多播业务的URSP规则；根据需要激活的多播业务上下文所对应的多播网络地址，查询所述支持多播业务的URSP规则，得到网络切片信息和数据网络名称信息；基于所述网络切片信息和所述数据网络名称信息激活用户设备的MBS(Multicast andBroadcast Service，多播广播业务)上下文信息，以加入所述多播网络地址对应的多播组中进行多播通信。
根据本申请实施例的一个方面，提供了一种多播通信方法，包括：获取用户设备的标识信息、所述用户设备需要激活的多播业务上下文所对应的多播网络地址，以及所述用户设备根据支持多播业务的URSP规则选择的网络切片信息和数据网络名称信息；根据所述网络切片信息、所述数据网络名称信息、所述用户设备的标识信息及所述多播网络地址，生成多播业务授权请求通知消息；将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体，以激活所述用户设备的MBS上下文信息。
根据本申请实施例的一个方面，提供了一种多播通信方法，包括：接收多播业务对应的会话管理功能实体发送的多播业务授权请求通知消息，所述多播业务授权请求通知消息中包含有用户设备的标识信息、所述用户设备需要激活的多播业务上下文所对应的多播网络地址，以及所述用户设备根据支持多播业务的URSP规则选择的网络切片信息和数据网络名称信息；将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体，以激活所述用户设备的MBS上下文信息。
根据本申请实施例的一个方面，提供了一种多播通信装置，包括：第一接收单元，配置为接收策略控制功能实体发送的URSP信息，所述URSP信息中包含有支持多播业务的URSP规则；查询单元，配置为根据需要激活的多播业务上下文所对应的多播网络地址，查询所述支持多播业务的URSP规则，得到网络切片信息和数据网络名称信息；第一处理单元，配置为基于所述网络切片信息和所述数据网络名称信息激活用户设备的多播广播业务MBS上下文信息，以加入所述多播网络地址对应的多播组中进行多播通信。
在本申请的一些实施例中，基于前述方案，所述第一处理单元配置为：基于所述网络切片信息和所述数据网络名称信息发起PDU(Protocol Data Unit，协议数据单元)会话建立请求，以建立PDU会话；基于建立的所述PDU会话，激活所述用户设备的MBS上下文信息。
在本申请的一些实施例中，基于前述方案，所述第一处理单元配置为：以在建立所述PDU会话时分配的网络地址作为源地址，向用户面功能实体发送包含有所述多播网络地址的IGMP(Internet Group Management Protocol，网际组管理协议)数据包，所述IGMP数据包用于指示激活所述用户设备的MBS上下文信息。
在本申请的一些实施例中，基于前述方案，所述第一处理单元配置为：在采用移动通信系统架构进行多播广播业务的情况下，向所述移动通信系统架构内的用户面功能实体发送所述IGMP数据包；在采用新的多播广播业务系统架构的情况下，向所述新的多播广播业务系统架构中的用于进行多播广播业务的用户面功能实体发送所述IGMP数据包。
在本申请的一些实施例中，基于前述方案，所述第一处理单元还配置为：若基于所述网络切片信息和所述数据网络名称信息确定已经存在相匹配的PDU会话，则直接基于所述相匹配的PDU会话，激活所述用户设备的MBS上下文信息。
在本申请的一些实施例中，基于前述方案，所述支持多播业务的URSP规则中包含有针对多播广播业务MBS或多播业务的第一IP地址描述符，所述第一IP地址描述符用于描述目标IP地址二元组，所述目标IP地址二元组中包含有所述多播网络地址及位于IP协议之上的IGMP协议。
在本申请的一些实施例中，基于前述方案，所述URSP信息中的URSP规则中包含有用于描述目标IP地址三元组的第二IP地址描述符，所述目标IP地址三元组中包含有IP地址或IPv6网络前缀，且包含有端口号及位于IP协议之上的协议号；其中，若一URSP规则中的第二IP地址描述符所描述的目标IP地址三元组中包含有所述多播网络地址和IGMP协议，且不包含端口号，则将该URSP规则作为所述支持多播业务的URSP规则。
在本申请的一些实施例中，基于前述方案，所述URSP信息中的URSP规则包含有连接能力信息，所述连接能力信息的值包括用于指示是多播通信的编码值；其中，若一URSP规则中的连接能力信息的值是指示多播通信的编码值，且该URSP规则中的IP地址描述符所描述的目标IP地址三元组中包含有所述多播网络地址和IGMP协议，且不包含端口号，则将该URSP规则作为所述支持多播业务的URSP规则。
在本申请的一些实施例中，基于前述方案，所述支持多播业务的URSP规则中包含有连接能力信息，以及针对多播广播业务MBS或多播业务的第一IP地址描述符；所述第一IP地址描述符用于描述目标IP地址二元组，所述目标IP地址二元组中包含有所述多播网络地址及位于IP协议之上的IGMP协议；所述连接能力信息的值指示的是多播通信的编码值。
在本申请的一些实施例中，基于前述方案，所述URSP信息中的URSP规则包含有连接能力信息，所述连接能力信息的值包括用于指示是多播通信或广播通信的编码值；其中，若一URSP规则中的连接能力信息的值是指示多播通信的编码值，则将该URSP规则作为通过下行传输来支持多播业务的URSP规则。
在本申请的一些实施例中，基于前述方案，所述URSP信息中的URSP规则中包含有针对MBS或多播业务或广播业务的第三IP地址描述符，所述第三IP地址描述符用于描述下行目标IP地址三元组，所述下行目标IP地址三元组中包含有多播网络地址或广播网络地址，且包含有端口号和位于IP协议之上的协议号；其中，若一URSP规则中的所述第三IP地址描述符所描述的下行目标IP地址三元组中包含有多播网络地址，则将该URSP规则作为通过下行传输来支持多播业务的URSP规则。
在本申请的一些实施例中，基于前述方案，所述URSP信息中的URSP规则包含有连接能力信息，所述连接能力信息的值包括用于指示是多播通信或广播通信的编码值；其中，若一URSP规则中的连接能力信息的值是指示多播通信的编码值，且该URSP规则中的针对MBS或多播业务或广播业务的第三IP地址描述符包含有多播网络地址、端口号和位于IP协议之上的协议号，则将该URSP规则作为通过下行传输来支持多播业务的URSP规则。
在本申请的一些实施例中，基于前述方案，所述第一接收单元配置为：在发送注册请求之后，接收所述策略控制功能实体发送的用户设备策略信息，所述用户设备策略信息中包含有所述URSP信息。
根据本申请实施例的一个方面，提供了一种多播通信装置，包括：获取单元，配置为获取用户设备的标识信息、所述用户设备需要激活的多播业务上下文所对应的多播网络地址，以及所述用户设备根据支持多播业务的URSP规则选择的网络切片信息和数据网络名称信息；生成单元，配置为根据所述网络切片信息、所述数据网络名称信息、所述用户设备的标识信息及所述多播网络地址，生成多播业务授权请求通知消息；第一发送单元，配置为将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体，以激活所述用户设备的MBS上下文信息。
在本申请的一些实施例中，基于前述方案，所述获取单元配置为：接收用户面功能实体发送的会话报告消息，根据所述会话报告消息获取所述多播网络地址；根据建立所述用户设备的PDU会话时所采用的信息获取所述网络切片信息、所述数据网络名称信息，以及所述用户设备的标识信息。
在本申请的一些实施例中，基于前述方案，在采用移动通信系统架构进行多播广播业务的情况下，所述第一发送单元配置为：根据所述网络切片信息、所述数据网络名称信息、所述用户设备的标识信息及所述多播网络地址，确定所述MBS对应的应用功能实体；将所述多播业务授权请求通知消息直接发送给所述应用功能实体，或者将所述多播业务授权请求通知消息发送给网络开放功能实体，以使所述网络开放功能实体转发至所述应用功能实体。
在本申请的一些实施例中，基于前述方案，在采用移动通信系统架构进行多播广播业务的情况下，所述第一发送单元配置为：将所述多播业务授权请求通知消息发送给网络开放功能实体，以使所述网络开放功能实体根据所述多播业务授权请求通知消息中包含的信息确定所述MBS对应的应用功能实体，并向所述应用功能实体发送所述多播业务授权请求通知消息。
在本申请的一些实施例中，基于前述方案，在采用移动通信系统架构进行多播广播业务的情况下，所述多播通信装置还包括：第一激活单元，配置为在所述第一发送单元将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体之后，接收来自于所述应用功能实体的多播业务会话开始请求，基于所述多播业务会话开始请求激活多播业务会话。
在本申请的一些实施例中，基于前述方案，所述第一激活单元配置为：接收所述应用功能实体直接发送的所述多播业务会话开始请求；或者接收网络开放功能实体转发的来自于所述应用功能实体的多播业务会话开始请求，其中，应用功能实体向所述网络开放功能实体发送的多播业务会话开始请求中包含有需要发送到的会话管理功能实体标识列表，或者应用功能实体向所述网络开放功能实体发送多个多播业务会话开始请求，各个多播业务会话开始请求中包含有一个需要发送到的会话管理功能实体的标识。
在本申请的一些实施例中，基于前述方案，在采用新的多播广播业务系统架构的情况下，所述第一发送单元配置为：根据所述网络切片信息、所述数据网络名称信息、所述用户设备的标识信息及所述多播网络地址，确定对应的MBSF(Multicast/BroadcastService Function，多播广播业务实体)；将所述多播业务授权请求通知消息发送给所述MBSF，以使所述MBSF将所述多播业务授权请求通知消息转发至所述应用功能实体。
根据本申请实施例的一个方面，提供了一种多播通信装置，包括：第二接收单元，配置为接收多播业务对应的会话管理功能实体发送的多播业务授权请求通知消息，所述多播业务授权请求通知消息中包含有用户设备的标识信息、所述用户设备需要激活的多播业务上下文所对应的多播网络地址，以及所述用户设备根据支持多播业务的URSP规则选择的网络切片信息和数据网络名称信息；第二发送单元，配置为将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体，以激活所述用户设备的MBS上下文信息。
在本申请的一些实施例中，基于前述方案，所述第二发送单元配置为：根据所述多播业务授权请求通知消息中所包含的信息，确定所述MBS对应的应用功能实体；将所述多播业务授权请求通知消息直接发送给所述应用功能实体，或者将所述多播业务授权请求通知消息发送给网络开放功能实体，以使所述网络开放功能实体转发至所述应用功能实体。
在本申请的一些实施例中，基于前述方案，所述第二发送单元配置为：将所述多播业务授权请求通知消息发送给网络开放功能实体，以使所述网络开放功能实体根据所述多播业务授权请求通知消息中包含的信息确定所述MBS对应的应用功能实体，并向所述应用功能实体发送所述多播业务授权请求通知消息。
在本申请的一些实施例中，基于前述方案，所述多播通信装置还包括：第二激活单元，配置为在所述第二发送单元将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体之后，接收来自于所述应用功能实体的多播业务会话开始请求，并基于所述多播业务会话开始请求激活多播业务会话。
在本申请的一些实施例中，基于前述方案，所述第二接收单元配置为：接收所述应用功能实体直接发送的所述多播业务会话开始请求；或者接收网络开放功能实体转发的来自于所述应用功能实体的多播业务会话开始请求，其中，应用功能实体向所述网络开放功能实体发送的多播业务会话开始请求中包含有需要发送到的MBSF标识列表，或者应用功能实体向所述网络开放功能实体发送多个多播业务会话开始请求，各个多播业务会话开始请求中包含有一个需要发送到的MBSF的标识。
根据本申请实施例的一个方面，提供了一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述实施例中所述的多播通信方法。
根据本申请实施例的一个方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中所述的多播通信方法。
在本申请的一些实施例所提供的技术方案中，通过接收包含有支持多播业务的URSP规则的URSP信息，以根据需要激活上下文到的多播业务所对应的多播网络地址，查询该URSP规则得到网络切片信息和数据网络名称信息，以基于该网络切片信息和数据网络名称信息激活用户设备的MBS上下文信息，使得用户设备能够直接根据支持多播业务的URSP规则来选择相应的网络切片信息和数据网络名称信息，并据此激活MBS上下文信息，减少了多播上下文的激活流程，进而有利于降低网络部署的复杂性，同时有利于提高多播通信的效率。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：
图1示出了单播通信系统及多播通信系统的数据传输流程示意图；
图2示出了MBMS的多播上下文激活过程示意图；
图3示出了IPv4网络地址的分类示意图；
图4示出了IPv4的多播地址的结构示意图；
图5示出了IPv6的多播地址的结构示意图；
图6示出了IPv4首部的结构示意图；
图7示出了IGMPv1的协议头部格式、IGMPv2的协议头部格式和IGMPv3中成员报告消息的格式示意图；
图8示出了UE Policy的传输过程示意图；
图9a至图9c示出了UE与PCF之间交互信息的三种方式的示意图；
图10示出了UE的注册过程的部分流程图；
图11示出了H-PCF通过V-PCF与AMF进行交互的流程图；
图12示出了一种MBS系统架构示意图；
图13示出了一种MBS系统结构示意图；
图14示出了根据本申请的一个实施例的多播通信方法的流程图；
图15示出了根据本申请的一个实施例的多播通信方法的流程图；
图16示出了根据本申请的一个实施例的多播通信方法的流程图；
图17示出了根据本申请的一个实施例的基于URSP的多播通信方法的流程图；
图18示出了根据本申请的一个实施例的基于URSP的多播通信方法的流程图；
图19示出了根据本申请的一个实施例的基于URSP的多播通信方法的流程图；
图20示出了根据本申请的一个实施例的多播通信装置的框图；
图21示出了根据本申请的一个实施例的多播通信装置的框图；
图22示出了根据本申请的一个实施例的多播通信装置的框图；
图23示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。
此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。
附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
需要说明的是：在本文中提及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
2G(第二代移动通信技术)、3G(第三代移动通信技术)与4G(第四代移动通信技术)的无线通信系统支持MBMS(Multimedia Broadcast and Multicast Service，多媒体广播组播业务)，这个业务分为Broadcast(广播)与Multicast(组播)两种业务。但是，只有2G与3G系统支持多播业务，4G系统在标准上不支持，并且2G、3G和4G系统都支持广播业务。
除了广播和组播业务之外，网络节点之间的通信方式还包括单播。“单播”就是最为常见的一对一的通信，其优点是发送方可以向不同的接收方传输不同的内容，但是如果发送方需要向多个接收方传输相同的内容，那么就需要端到端地分别传输多份相同的数据，效率较低。具体如图1中所示，单播源以单播的方式向多个接收方发送数据时，需要以端到端的方式分别传输多份相同的数据(图1中不同的线型表示不同的数据流)。
“组播”也可以称为“多播”，是发送方将相同的内容传输给多个接收方。网上视频会议、网上视频点播特别适合采用多播方式，因为如果采用单播方式，那么有多少个接收方，就会有多少次传送过程，这种方式显然效率极低；而如果采用不区分目标、全部发送的广播方式，虽然一次可以传送完数据，但是达不到区分特定数据接收方的目的。可见，采用多播方式，既可以实现一次向多个接收方发送相同的数据，也可以达到只对特定对象传送数据的目的。具体如图1中所示，多播源一次可以向多个接收方发送数据相同的数据。
“广播”也是将相同的内容传输给多个接收方，但是在传输的时候没有进行接收方的选择，因此可能存在着对不必要的设备也进行了数据的传输而造成网络资源的浪费。另外，有些接收方可能对广播的内容没有“兴趣”，那么在接收到广播的内容之后，也不得不丢弃掉接收到的数据包，进而也造成了终端资源的浪费。
广播业务与多播业务的根本区别在于系统中的UE都可以参加广播业务且无需签约，而多播业务的UE必须是要签约与认证后才能参加。同时需要注意的是：多播业务与广播业务有很多种，对于多播业务，UE是通过IP多播地址加入相应业务的多播组。而广播业务是通过不同的区域来区分，这样在某个区域中只有一个广播业务，而这个广播业务在不同的时间段可以传输不同的业务。
在3GPP(3rd Generation Partnership Project，第三代合作伙伴计划)协议的TS23.246章节8.2中定义了MBMS的多播上下文激活过程，具体如图2所示，包括如下步骤：
步骤S201，UE选择一个APN(Access Point Name，接入点名称)建立一个PDP(Packet Data Protocol，分组数据协议)Context，然后分配一个IP地址给UE，为便于后续描述，该步骤中UE选择的APN用APN0来进行标识。
步骤S202，UE选择一个IP Multicast Address(该IP多播地址用于标识一个多播业务)，然后向GGSN(Gateway GPRS Support Node，网关GPRS支持节点)发送IGMP Join数据包，以指示UE要加入这个多播组。
步骤S203，GGSN向BM-SC(Broadcast Multicast Service Center，广播多播业务中心)发送MBMS授权请求，并接收BM-SC反馈的MBMS授权响应。其中，BM-SC根据UE的签约数据认证UE是否可以加入这个多播组，如果确认UE可以加入这个多播组，则在MBMS授权响应中给出UE加入这个多播组所要使用的APN(该APN以APN1来进行标识)，然后通过步骤S204a、S204b、S205将UE所要使用的APN1传递给UE。
步骤S206，UE根据BM-SC提供的APN1发起一个新的MBMS Session，即发送激活MBMS上下文请求，该激活MBMS上下文请求中包含有IP Multicast Address、APN1和UE的MBMS能力。该MBMS能力比如可以是QoS(Quality of Service，服务质量)能力。
步骤S207，SGSN(Serving GPRS Support Node，服务GPRS支持节点)校验UE是否有签约APN1，若不能校验通过，则SGSN向GGSN发送MBMS通知拒绝请求，GGSN向MBMS发送通知拒绝响应。需要说明的是，UE的签约数据保存在HSS(Home Subscriber Server，归属用户服务器)中，图2中没有示出SGSN与HSS的交互过程。另外，图2中的步骤S208和步骤S209的具体过程请参见TS23.246章节8.2中定义的MBMS上下文激活过程。
步骤S210，若SGSN校验UE通过，则SGSN根据APN1选择另外一个GGSN(即支持Multicast业务的GGSN)，向该GGSN发送创建MBMS上下文请求消息，此消息中包含有UE的ID、UE Location ID、IP Multicast Address、APN1和UE的接入信息(比如是2G还是3G)。
其中，UE的ID可以是IMSI(International Mobile Subscriber Identity，国际移动用户识别码)或MSISDN(Mobile Station International Integrated Service DigitalNetwork Number，移动台国际综合业务数字网络号码)。UE Location ID可以是RAT(RadioAccess Technology，无线接入技术)ID或者CGI(Common Gateway Interface，公共网关接口)或者SAI(Service Area Identity，服务区域标识)等。
步骤S211，GGSN向BM-SC发送MBMS授权请求，BM-SC根据UE的签约信息对UE进行授权，并向GGSN反馈MBMS授权响应。
步骤S212，若授权允许接入，且GGSN上没有IP Multicast Address指示的任何UE的上下文，即此UE是此GGSN上第一个接入IP Multicast Address所标识的多播业务，则向其上级节点BM-SC作注册，以指示后续发送给IP multicast Address的多播业务数据时，需要发送到此GGSN上。(注意，不同的UE可能选择到不同的GGSN上，因此BM-SC向下发送多播数据时，需要向这些GGSN同时发送相同的多播数据)。
步骤S213，GGSN创建此UE的对应于此IP Multicast Address的MBMS UE上下文，然后向SGSN发送创建MBMS上下文响应，以指示MBMS上下文创建成功。
步骤S214，类型于步骤S212，若SGSN上没有IP Multicast Address指示的任何UE的上下文，即此UE是此SGSN上第一个接入IP Multicast Address所标识的多播业务，则向上级节点GGSN作注册，以指示后续发送给IP multicast Address的多播业务数据时，需要发送到此SGSN上。(注意，不同的UE可能选择到不同的SGSN上，因此此GGSN向下发送多播数据时，需要向这些SGSN同时发送相同的多播数据)。
图2中的步骤S215至步骤S217的具体过程请参见TS23.246章节8.2中定义的MBMS上下文激活过程。
由图2所示的流程可知：2G或3G的UE先是通过APN0建立一个PDP Context，分配得到一个IP地址，然后以此IP地址发送一个加入多播的IGMP Join数据包给网络，GGSN要截获这个IGMP数据包，然后向MB-SC发送一个信令(即MBMS授权请求)，进而BM-SC向UE分配一个APN1，然后UE再以这个APN1发送请求MBMS上下文激活消息，从而才能激活一个MBMS上下文。
图2所示流程的这种方法有如下缺点：几乎所有的GGSN都需要截获这个IGMP Join数据包，然后向MB-SC发送一个信令(即MBMS授权请求)，这对GGSN的开发增加了复杂性。并且UE要使用两个APN，一个APN用于建立PDP Context来发送IGMP Join数据包，另外一个APN是真正用于MBMS业务的，很显然，使用两个APN增加了UE的复杂性与网络部署的复杂性。
前述的MBS的多播地址可能是IPv4多播地址，也可以IPv6多播地址。如图3所示，IPv4的网络地址分为A类地址、B类地址、C类地址、D类地址和E类地址。其中，A类地址中的第1字节(8位)为网络号，其它3个字节(24位)为主机号，A类地址的范围是：0.0.0.0到127.255.255.255。B类地址中的第1字节和第2字节为网络号，其它2个字节为主机号，B类地址的范围是：128.0.0.0到191.255.255.255。C类地址中的前3个字节为网络号，第4个字节为主机号，C类地址的范围是：192.0.0.0到223.255.255.255。D类地址是多播地址，该类地址最前面4位是“1110”，D类地址的范围是：224.0.0.0到239.255.255.255。E类地址是保留地址，该类地址最前面5位是“11110”，E类地址的范围是：240.0.0.0到247.255.255.255。
如图4所示，IPv4的多播地址又可以具有三种结构，这三种结构分别适用于众所周知(Well-Known)的多播地址，全局范围(Globally-Scoped)的多播地址和本地范围(Locally-Scoped)的多播地址。
IPv6多播地址的结构如图5所示，第一个字节(8比特)表示该地址是多播地址，接下来的4比特是标志位(Flag)字段，再接下来的4比特是范围(Scope)字段，最后的112比特位组标识符(Group ID)。
其中，标志位字段的第一个比特为0，保留给将来使用；第二个比特指示该多播地址是否内嵌了RP(Rendezvous Point，聚合点)，RP是多播网络中指定多播流的分发点，比如第二个比特值为0时，表示未内嵌聚合点，第二个比特值为1时，表示内嵌了聚合点。标志位字段的第三个比特指示该多播地址是否内嵌了前缀信息，比如第三个比特值为0时，表示未内嵌前缀信息，第二个比特值为1时，表示内嵌了前缀信息。标志位字段的最后一个比特指示该多播地址是永久分配的多播地址(permanently assigned address)还是临时多播地址(transient multicast address)，比如最后一个比特值为0时，表示是永久分配的多播地址，最后一个比特值为1时，表示是临时多播地址。
范围(Scope)字段的作用是限定多播地址的范围，取值与描述如表1所示：
表1
在多播通信中，多播地址只能作为目的IP地址(即IP头中的目的IP地址)，多播地址不能作为源IP地址。在MBMS(2G、3G)与MBS(5G)的多播业务中，多播数据包都是网络侧向下发送给UE的，即多播数据包都是DL(Downlink，下行)数据包，UE不能通过对应的多播地址向网络侧发送数据。也就是说UE不能将此多播地址作为目的IP地址发送上行的IP包，即没有UL(Uplink，上行)的多播数据。
网络中传输的IP包是由IP首部和数据两部分组成的，IPv4首部的结构如图6所示，主要包括：“版本”字段、“首部长度”字段、“服务类型”字段、“总长度”字段、“标识”字段、“标志”字段、“片偏移”字段、“生存时间”字段、“协议”字段、“首部校验和”字段、“源地址”字段、“目的地址”字段、“可选字段”。
其中，“版本”字段占4位，指IP协议的版本，比如版本号为4(即IPv4)。“首部长度”字段占4位。“服务类型”字段占8位，用来获得更好的服务。“总长度”字段占16位，指首部和数据之和的长度。“标识”字段占16位，它是一个计数器，用来产生数据报的标识。“标志”字段占3位，“标志”字段的最低位是MF(More Fragment)，如果MF＝1则表示后面“还有分片”，如果MF＝0则表示是最后一个分片；“标志”字段中间的一位是DF(Don't Fragment)，只有当DF＝0时才允许分片。“片偏移”字段占12位，指较长的分组在分片后某片在原分组中的相对位置。“生存时间”字段即为TTL(Time To Live)，其占8位，TTL字段是由发送端初始设置一个字段。“协议”字段占8位，用于指示此数据报携带的数据使用何种协议，其中值为“1”表示是ICMP(Internet Control Message Protocol，Internet控制报文协议)协议；值为“2”表示是IGMP协议；值为“6”表示是TCP(Transmission Control Protocol，传输控制协议)协议；值为“17”表示是UDP(User Datagram Protocol，用户数据报协议)协议；值为“50”表示是ESP(Encapsulating Security Payload，封装安全载荷)协议；值为“51”表示是AH(Authentication header，认证头)协议。“首部校验和”字段占16位，只检验数据报的首部，不检验数据部分。“源地址”字段和“目的地址”字段分别占4字节，用于分别记录源地址和目的地址。
对于上述提到的IGMP协议，其有三个协议版本，分别为IGMPv1、IGMPv2和IGMPv3，对应的标准分别是RFC1054、RFC2236和RFC3376。IGMPv1的协议头部格式和IGMPv2的协议头部格式如图7所示，其中，IGMPv1的协议头部包括4比特的IGMP版本字段、4比特的IGMP报文类型字段(该字段值为1表示是Host Membership Query，即主机成员查询类型；值为2表示是Host Membership Report，即主机成员报告类型)、8比特的未用字段(该字段在发送时填0，接收时忽略)、16比特的IGMP校验和字段(当传送报文时，必须计算该校验字并插入到该字段中去；当接收包时，该字段必须在处理包之前进行检验)，以及32位的组播地址字段。
IGMPv2的协议头部包括8比特的报文类型字段、8比特的最大响应时间字段、16比特的IGMP校验和字段，以及32位的组播地址字段。
其中，IGMPv2的协议头部中的报文类型字段所指示的类型有如下几种：0x11＝Membership Query，表示的是IGMP成员查询消息；0x12＝Version 1Membership Report，表示的是IGMPv1的成员报告消息；0x16＝Version 2Membership Report，表示的是IGMPv2的成员报告消息；0x17＝Leave Group表示的是离开消息。在IGMPv2中，旧的4位版本字段和旧的4位类型字段拼成了一个新的8位类型字段，通过分别将成员查询消息(版本1和版本2的)及版本1的成员报告消息的类型代码置为0x11和0x12，保持了IGMP版本1和版本2包格式的向后兼容。
IGMPv2的协议头部中的最大响应时间字段用于指示在发出响应报告前的最长时间(以1/10秒为单位)，缺省值为10秒。类似于IGMPv1，在传送报文时，必须计算校验和并填入IGMPv2的协议头部中的校验和字段中，接收报文时，必须在处理报文之前检验校验和，以判断IGMP消息在传输过程中是否发生了错误。
继续参照图7所示，IGMPv3中成员报告消息(Membership Report)的格式包括类型字段(由于是成员报告消息，因此类型＝0x22)、保留字段、校验和字段、组记录数量字段以及组记录字段。其中，图2中所示的IGMP Join数据包就是IGMP的Membership Report消息来实现的。对IGMPv3而言，IGMP Joint消息的IP包中的目的IP地址不是要加入的IP多播地址，而是在消息的参数中包含了其要加入的IP多播地址。
在5G规范TS23.503的章节6.6.2中给出URSP中包含一个或多个URSP Rule，并且指出每个URSP Rule对应于一个优先级，用Traffic Description(流量描述符)来描述UE的应用流量，对应于这个应用流量有一个或多个“路由选择描述符(Route SelectionDescriptor)”，并从中选择出一个路由选择描述符，用于建立一个PDU Session来传输这个应用及其流量(详细参见TS23.503的章节6.6.2)。路由选择描述符的定义参见TS23.503中章节6.6.2的表格6.6.2.1-3所示。
其中，一个URSP包含一个或多个URSP Rule，每个URSP Rule有一个优先级；一个URSP Rule可以有多个Route Selection Descriptor，每个有Route SelectionDescriptor有优先级；一个Route Selection Descriptor包含一个或多个RouteSelection Components(路由选择组件)，一个Route Selection Component可以取一个值或一组值。
一个URSP Rule包含的信息如下表2所示，表2中Optional的项可能出现或不出现：
/>
表2
PCF(Policy Control Function，策略控制功能)在将URSP信息传输给UE之后，UE将利用URSP中包含的一个URSP Rule将Application与一个PDU会话关联起来。在5G规范TS23.503的章节6.6.2.3定义了Application与PDU会话关联的详细过程，简述如下：
对于一个应用，UE以URSP Rule的Precedence(优先级)次序来决定该应用是否与一个URSP Rule中的流量描述符匹配。当一个URSP Rule中的流量描述符与UE的应用匹配时，UE要再次选择这个URSP Rule中最高优先级的Route Selection Descriptor(以下简称RSD)；当一个有效的RSD被选择了，UE决定是否存在着一个PDU会话匹配RSD中的所有单元，此时的匹配过程如下：
如果某个单元(例如SSC Mode单元)只取一个值，则PDU会话的此单元值必须与RSD中这个单元值完全一样。
如果某个单元(例如网络切片单元)包含值列表，则PDU会话的此单元值必须与RSD中这个单元中的某个值完全一样。
如果某个单元在RSD中没有出现，若PDU会话在建立时没有包含此单元，则此PDU会话与此单元匹配。
如果RSD包含有Time Window(时间窗口)或Location Criteria(位置标准)，则在PDU会话与具有相同Time Windows或Location Criteria Validity Conditions(位置标准有效条件)的RSD关联时，才认为此PDU会话匹配。
当UE匹配到一个存在的PDU会话时，UE关联应用到这个PDU会话，并使用这个匹配的PDU会话来传输这个应用的数据。
当UE发现有多个存在的PDU Session匹配(如RSD Component只有NSS(NetworkSlice Subnet，网络切片子网)单元，且此单元取值如S-NSSAI(Single Network SliceSelection Assistance Information，单个网络切片选择协助信息)，同时有多个PDUSession有相同的S-NSSAI，但取不同的DNN(Data Network Name，数据网络名词)值)，此时取决于UE选择其中一个PDU Session。
若UE没有找到一个存在的PDU Session匹配，则UE依据URSP Rule中的一个RSD(从最高优先级开始)来建立一个新的PDU Session。若PDU Session建立成功了，则UE将此应用关联到此新建的PDU Session。
如果PDU Session建立请求被拒绝(Reject)了，则在允许的情况下，UE依据拒绝的原因重新选择一个新的RSD(比如若一个单元有多个值，则该单元取另外一个值，)再次尝试建立一个PDU Session，如果PDU Session建立请求还是被拒绝，则UE以优先级再次尝试URSP Rule(最高优先级开始)与RSD(最高优先级开始)。当一个Rule中所有RSD(以优先级次序)尝试全部失败后，再选择另外一个URSP Rule(以优先级为次序)，再次进行RSD(以优先级为次序)来尝试建立PDU Session。
当UE的URSP被更新了或一些事件发生了(由TS24.526所定义)，则UE可以基于新的URSP重新进行前面的匹配过程。另外UE还可以重新评估应用与PDU会话之间的关联，评估的时机可以包括如下几种情况：
(1)基于UE实施的定期重新评估；
(2)用于基于URSP Rule路由应用程序流量的现有PDU会话被释放；
(3)路径选择验证标准(Route Selection Validation Criteria)中的时间窗口(Time Window)期满，或UE的位置不再符合位置标准(Location Criteria)。
如果重新评估导致应用程序更改PDU会话的关联，例如该应用程序是与另一个PDU会话相关联或需要建立新的PDU会话时，UE根据实现可以及时强制执行此类更改，如立即或在UE进入CM-IDLE(Connection Management-IDLE，连接管理空闲态)状态时进行更改。
如果所选的路由选择描述符包含非无缝卸载指示(Non-Seamless Offloadindication)，并且UE已建立到WLAN(Wireless Local Area Network，无线局域网)接入的连接后，UE会通过WLAN接入路由PDU会话中与URSP规则的流量描述符匹配的流量。
在定义上述表2中的IP Description时是5G标准的R15，在R15设计时IPDescriptors是以UE的上行数据作为考虑的，因这个URSP rule是由网络配置的，并且提供给很多UE的。其中IP Descriptors中的目的IP地址是服务器的地址，目的端口号(如80、21、443)是服务器提供服务的端口号，使用的协议(如UDP、TCP)是服务器提供服务时的协议。这些DN(Data Network，数据网络)上的服务器可提供的数据服务的参数都是可以被网络获知，并且配置在URSP Rule中并提供给很多UE的。若以DL数据包作为IP Descriptors则存在如下问题：1)每个UE的情况都不一样，也可能没有分配IP地址；2)UE向服务器通信时，分配的端口号基本上是随机分配的，网络无法事先确定。总之，URSP是以DN可以提供服务的服务器的配置参数来配置IP Descriptors的，而这些配置是用于UE的上行数据中。
但是5G MBS标准是R17，MBS业务是下行数据服务，则DN中的一个服务器是通过发送下行数据给UE，而其中下行数据的目的IP地址为IP多播地址(这个多播地址同时用于标识这个多播组)，端口号也是可以事先配置的，协议一般只有UDP。因此，若以R15的IPDescriptor适用于UE发送的数据则是不能用于5G MBS，因为UE只有在IGMP Join中才有上行数据，而此时IGMP数据只是一个没有端口号的数据，并不适用。
此外，现有标准中定义的UE Policy的传输过程非常复杂，主要是由于UE Policy的数量(或内容)可能非常多，一次可能不能传输完成，可能需要多个传输过程，另外一个复杂性是UE与PCF之间的直接交互需要经过AMF(Access and Mobility ManagementFunction，接入与移动性管理功能)的中转所引起。在5G标准TS23.502的章节4.2.4.3UEConfiguration Update procedure for transparent UE Policy delivery(用于透明UE策略交付的UE配置更新过程)章节给出了UE Policy传输的整体过程，具体如图8所示，包括如下步骤：
步骤S800，PCF决定更新UE Policy；步骤S801，PCF向AMF传输信息；步骤S802，网络触发的服务请求；步骤S803，AMF向UE传输UE Policies；步骤S804，UE向AMF反馈UEPolicies的传输结果；步骤S805，AMF向PCF发送信息通知消息，通知UE Policy的更新结果。
另外，在标准TS24.501的Annex D给出了UE与PCF之间交互信息的三种方式。具体如图9a至图9c所示，在图9a中，PCF向UE发送管理UE Policy指令，UE向PCF反馈管理UEPolicy完成消息，或者管理UE Policy命令拒绝消息；在图9b中，UE向PCF发送UE状态指示；在图9c中，UE向PCF发送交易相关请求，PCF向UE发送交易相关命令，UE向PCF反馈交易相关响应。
在标准TS23.502的章节4.2.2.2中定义了UE的注册过程，如图10所示，包括如下步骤：
步骤S1001，UE向接入网发起注册请求；步骤S1002，接入网进行AMF的选择；步骤S1003，接入网实体向新的AMF发起注册请求；步骤S1004，新的AMF向旧的AMF发送UE上行文传输请求；步骤S1005，旧的AMF向新的AMF返回UE上行文传输响应；……步骤S1021，AMF向UE发送注册接受信息；步骤S1021b，AMF与PCF进行UE策略关联建立过程。图10中还包括一些其它必要的步骤，具体可参照3GPP协议TS23.502中的章节4.2.2.2Registration procedures(注册过程)。
其中，在步骤S1021b中AMF将与PCF建立UE Policy Association(UE策略关联)，在此过程中，PCF将UE Policy先传输给AMF，然后AMF再传输给UE。另外，当PCF因各种原因修改了UE Policy，则PCF发起TS23.502的章节4.2.4.3UE Configuration Update procedurefor transparent UE Policy delivery所定义的过程将UE Policy传输给UE。
需要说明的是：如果UE处于漫游(Roaming)状态，则由H-PCF(Home-PCF，归属地的PCF)通过V-PCF(Visited-PCF，拜访地的PCF)与AMF进行交互，具体如图11所示，包括如下步骤：步骤S1101，AMF决定建立UE策略关联；步骤S1102，AMF向V-PCF发送UE策略控制创建请求；步骤S1103，V-PCF向H-PCF发送UE策略控制创建请求；步骤S1104，H-PCF向V-PCF发送UE策略控制创建响应；步骤S1105，V-PCF向AMF发送UE策略控制创建响应；步骤S1106，H-PCF向V-PCF发送UE策略控制更新通知请求；步骤S1107，V-PCF向H-PCF发送UE策略控制更新通知响应；步骤S1108，AMF与V-PCF进行UE配置更新过程；步骤S1109，步骤S1109，V-PCF向H-PCF发送UE策略控制更新请求；步骤S1110，H-PCF向V-PCF发送UE策略控制更新响应。图11中各步骤的详细过程参照标准TS23.502的章节4.6.11。
此外，在5G MBS最新的研究报告中定义了如图12和图13所示的两种系统架构，其中，图12所示的系统架构是在目前5G架构上叠加功能，即在不修改目前5G架构的情形下，通过增强5G架构的功能与接口来支持5G MBS业务，这种架构的好处是通过软件升级就可以支持5G MBS。图13所示的系统架构是一个全新的架构，即在目前5G架构不变的情形下，增加一些新的网络功能节点。这种架构的好处是对目前的5G的架构影响最小化，但是有些网络功能节点可能还是需要进行增强，如NG-RAN(Next Generation Radio Access Network，下一代无线接入网)、UDM(Unified Data Management，统一数据管理)网元、UDR(User DataRepository，用户数据仓库)网元、NEF(Network Exposure Function，网络开放功能)、PCF等。
图12中的SMF是Session Management Function，即会话管理功能；UPF是UserPlane Function，即用户面功能；AF是Application Function，即应用功能。图13中的中的MB-UPF即为Multicast/Broadcast-UPF；M-AMF即为Multicast-AMF；MB-SMF即为Multicast/Broadcast-SMF；MBSU即为Multicast/Broadcast Service User Plane(多播/广播业务用户面)。根据MBS标准，此M-AMF是专用于MBS业务的AMF，可以不同于UE当前注册到5G网络的AMF。
从上述介绍可知，现有标准中对于MBMS上下文的激活流程繁琐，增加了网络部署的复杂性，并且也影响了多播通信的效率。基于此，本申请提出了一种新的多播通信方案，以下对本申请实施例的技术方案的实现细节进行详细阐述：
图14示出了根据本申请的一个实施例的多播通信方法的流程图，该多播通信方法可以由终端设备来执行。参照图14所示，该多播通信方法至少包括步骤S1410至步骤S1430，详细介绍如下：
在步骤S1410中，接收策略控制功能实体发送的用户路由选择策略URSP信息，该URSP信息中包含有支持多播业务的URSP规则。
在本申请的一个实施例中，终端设备可以在注册过程中接收PCF发送的URSP信息，即在发送注册请求之后，接收PCF发送的用户设备策略信息，该用户设备策略信息中包含有URSP信息。此外，在其它条件下，比如当URSP规则发生变化之后，PCF可以及时将变化后的URSP规则传输给终端设备。
在步骤S1420中，根据需要激活的多播业务上下文所对应的多播网络地址，查询支持多播业务的URSP规则，得到网络切片信息和数据网络名称信息。
在本申请的一个实施例中，网络切片信息可以是S-NSSAI，数据网络名称即为DNN。
在本申请的一个实施例中，可以在URSP规则中增加一个MBS IP描述符或者Multicast IP描述符，为便于与URSP规则中原有的IP地址描述符相区分，该MBS IP描述符或者Multicast IP描述符称之为第一IP地址描述符，如果是支持多播业务的URSP规则，那么该URSP规则中包含有该第一IP地址描述符，且该第一IP地址描述符用于描述目标IP地址二元组，目标IP地址二元组中包含有多播网络地址及位于IP协议之上的IGMP协议。
在本申请的一个实施例中，由于URSP信息中的URSP规则中包含有用于描述目标IP地址三元组的第二IP地址描述符，该目标IP地址三元组中包含有IP地址或IPv6网络前缀，且包含有端口号及位于IP协议之上的协议号。因此，可以复用该第二IP地址描述符来指示是支持多播业务的URSP规则，具体地，若一URSP规则中的第二IP地址描述符所描述的目标IP地址三元组中包含有多播网络地址和IGMP协议，且不包含端口号，则将该URSP规则作为支持多播业务的URSP规则。
在本申请的一个实施例中，由于URSP信息中的URSP规则包含有连接能力信息，因此可以针对该连接能力信息增加用于指示多播通信的编码值，具体地，若一URSP规则中的连接能力信息的值是指示多播通信的编码值，且该URSP规则中的IP地址描述符所描述的目标IP地址三元组中包含有多播网络地址和IGMP协议，且不包含端口号，则将该URSP规则作为支持多播业务的URSP规则。
在本申请的一个实施例中，支持多播业务的URSP规则中可以包含有连接能力信息，以及针对多播广播业务MBS或多播业务的第一IP地址描述符；该第一IP地址描述符用于描述目标IP地址二元组，该目标IP地址二元组中包含有多播网络地址及位于IP协议之上的IGMP协议，该连接能力信息的值指示的是多播通信的编码值。
在本申请的一个实施例中，URSP信息中的URSP规则包含有连接能力信息，该连接能力信息的值包括用于指示是多播通信或广播通信的编码值；其中，若一URSP规则中的连接能力信息的值是指示多播通信的编码值，则将该URSP规则作为通过下行传输来支持多播业务的URSP规则。
在本申请的一个实施例中，可以在URSP规则中增加针对MBS或多播业务或广播业务的第三IP地址描述符，该第三IP地址描述符用于描述下行目标IP地址三元组，该下行目标IP地址三元组中包含有多播网络地址或广播网络地址，且包含有端口号和位于IP协议之上的协议号；其中，若一URSP规则中的第三IP地址描述符所描述的下行目标IP地址三元组中包含有多播网络地址，则将该URSP规则作为通过下行传输来支持多播业务的URSP规则。
在本申请的一个实施例中，由于URSP信息中的URSP规则包含有连接能力信息，因此可以针对该连接能力信息增加用于指示是多播通信或广播通信的编码值；其中，若一URSP规则中的连接能力信息的值是指示多播通信的编码值，且该URSP规则中的针对MBS或多播业务或广播业务的第三IP地址描述符包含有多播网络地址、端口号和位于IP协议之上的协议号，则将该URSP规则作为通过下行传输来支持多播业务的URSP规则。
继续参照图14所示，在步骤S1430中，基于网络切片信息和数据网络名称信息激活用户设备的多播广播业务MBS上下文信息，以加入多播网络地址对应的多播组中进行多播通信。
在本申请的一个实施例中，可以基于网络切片信息和数据网络名称信息发起PDU会话建立请求，以建立PDU会话，然后基于建立的PDU会话，激活用户设备的MBS上下文信息。具体地，可以以在建立PDU会话时分配的网络地址作为源地址，向UPF发送包含有多播网络地址的IGMP数据包，该IGMP数据包用于指示激活用户设备的MBS上下文信息。
在本申请的一个实施例中，若IGMP数据包采用版本1的IGMP协议或版本2的IGMP协议，则多播网络地址是IGMP数据包的目的地址；若IGMP数据包采用版本3的IGMP协议，则多播网络地址位于IGMP数据包中的协议字段内。
在本申请的一个实施例中，对于图12所示的采用移动通信系统架构进行多播广播业务的场景而言，UE可以向移动通信系统架构内的UPF发送IGMP数据包；而对于图13所示的采用新的MBS系统架构的场景而言，UE可以向新的MBS系统架构中的用于进行多播广播业务的用户面功能实体(即MB-UPF)发送IGMP数据包。
在本申请的一个实施例中，如果基于网络切片信息和数据网络名称信息确定已经存在相匹配的PDU会话，则直接基于相匹配的PDU会话，激活用户设备的MBS上下文信息，即无需再发起PDU会话建立请求。
在本申请的一个实施例中，UE在获取到网络切片信息和数据网络名称信息之后，也可以不建立PDU会话，而是以无线优化的方式来使用MBS Multicast业务，具体过程在下文中进行详细说明。
图14所示实施例的技术方案是从终端设备的角度来阐述本申请实施例的多播通信方法，以下从会话管理功能实体的角度对本申请实施例的技术方案进行进一步阐述：
图15示出了根据本申请的一个实施例的多播通信方法的流程图，该多播通信方法可以由会话管理功能实体SMF来执行。参照图15所示，该多播通信方法至少包括步骤S1510至步骤S1530，详细介绍如下：
在步骤S1510中，获取用户设备的标识信息、用户设备需要激活的多播业务上下文所对应的多播网络地址，以及用户设备根据支持多播业务的URSP规则选择的网络切片信息和数据网络名称信息。
在本申请的一个实施例中，可以接收用户面功能实体发送的会话报告消息，根据会话报告消息获取多播网络地址，并根据建立用户设备的PDU会话时所采用的信息获取网络切片信息、数据网络名称信息，以及用户设备的标识信息。当然，也可以根据用户设备进行的上行非接入层(Non-Access Stratum，NAS)传输信息来获取网络切片信息、数据网络名称信息，以及用户设备的标识信息。
在步骤S1520中，根据网络切片信息、数据网络名称信息、用户设备的标识信息及多播网络地址，生成多播业务授权请求通知消息。
在步骤S1530中，将多播业务授权请求通知消息发送给MBS对应的应用功能实体，以激活用户设备的MBS上下文信息。
在本申请的一个实施例中，对于图12所示的采用移动通信系统架构进行多播广播业务的场景而言，可以根据网络切片信息、数据网络名称信息、用户设备的标识信息及多播网络地址，确定MBS对应的应用功能实体，然后将多播业务授权请求通知消息直接发送给该应用功能实体，或者将多播业务授权请求通知消息发送给网络开放功能实体，以使网络开放功能实体转发至该应用功能实体。该实施例中是由SMF来确定MBS对应的应用功能实体，然后直接或通过NEF向确定的应用功能实体发送多播业务授权请求通知消息。
在本申请的一个实施例中，对于图12所示的采用移动通信系统架构进行多播广播业务的场景而言，可以将多播业务授权请求通知消息发送给网络开放功能实体，以使网络开放功能实体根据多播业务授权请求通知消息中包含的信息确定MBS对应的应用功能实体，并向应用功能实体发送多播业务授权请求通知消息。该实施例中是由SMF将多播业务授权请求通知消息发送给NEF，由NEF来确定MBS对应的应用功能实体，然后向确定的应用功能实体发送多播业务授权请求通知消息。
在本申请的一个实施例中，对于图12所示的采用移动通信系统架构进行多播广播业务的场景而言，在将多播业务授权请求通知消息发送给MBS对应的应用功能实体之后，若接收到来自于该应用功能实体的多播业务会话开始请求，则基于该多播业务会话开始请求激活多播业务会话。
在本申请的一个实施例中，SMF接收来自于应用功能实体的多播业务会话开始请求的过程可以是接收应用功能实体直接发送的多播业务会话开始请求。
在本申请的一个实施例中，SMF接收来自于应用功能实体的多播业务会话开始请求的过程可以是接收NEF转发的来自于该应用功能实体的多播业务会话开始请求。由于不同的UE可以选择了不同的SMF，因此可能存在多个需要发送到的SMF，在这种情况下，该应用功能实体向NEF发送的多播业务会话开始请求中包含有需要发送到的会话管理功能实体标识列表，或者应用功能实体向NEF发送多个多播业务会话开始请求，各个多播业务会话开始请求中包含有一个需要发送到的会话管理功能实体的标识。
在本申请的一个实施例中，对于图13所示的采用新的MBS系统架构的场景而言，可以由MB-SMF将多播业务授权请求通知消息发送给MBS对应的应用功能实体，具体地，MB-SMF可以根据网络切片信息、数据网络名称信息、用户设备的标识信息及多播网络地址，确定对应的多播广播业务实体MBSF，然后将多播业务授权请求通知消息发送给MBSF，以使MBSF将多播业务授权请求通知消息转发至应用功能实体。其中，MBSF将多播业务授权请求通知消息转发至应用功能实体的过程参照图16所示。
图16示出了根据本申请的一个实施例的多播通信方法的流程图，该多播通信方法适用于如图13所示的采用新的MBS系统架构进行多播通信的应用场景，具体可以由MBSF来执行。参照图16所示，该多播通信方法至少包括步骤S1610至步骤S1620，详细介绍如下：
在步骤S1610中，接收多播业务对应的SMF发送的多播业务授权请求通知消息，多播业务授权请求通知消息中包含有用户设备的标识信息、用户设备需要激活的多播业务上下文所对应的多播网络地址，以及用户设备根据支持多播业务的URSP规则选择的网络切片信息和数据网络名称信息。
在步骤S1620中，将多播业务授权请求通知消息发送给MBS对应的应用功能实体，以激活用户设备的MBS上下文信息。
在本申请的一个实施例中，MBSF将多播业务授权请求通知消息发送给MBS对应的应用功能实体的过程可以是：根据多播业务授权请求通知消息中所包含的信息，确定MBS对应的应用功能实体，然后将多播业务授权请求通知消息直接发送给应用功能实体，或者将多播业务授权请求通知消息发送给NEF，以使NEF转发至应用功能实体。该实施例中是由MBSF来确定MBS对应的应用功能实体，然后直接或通过NEF向确定的应用功能实体发送多播业务授权请求通知消息。
在本申请的一个实施例中，MBSF将多播业务授权请求通知消息发送给MBS对应的应用功能实体的过程可以是：将多播业务授权请求通知消息发送给NEF，以使NEF根据多播业务授权请求通知消息中包含的信息确定MBS对应的应用功能实体，并向应用功能实体发送多播业务授权请求通知消息。该实施例中是由MBSF将多播业务授权请求通知消息发送给NEF，由NEF来确定MBS对应的应用功能实体，然后向确定的应用功能实体发送多播业务授权请求通知消息。
在本申请的一个实施例中，MBSF在将多播业务授权请求通知消息发送给MBS对应的应用功能实体之后，还可以接收来自于应用功能实体的多播业务会话开始请求，然后基于多播业务会话开始请求激活多播业务会话。
在本申请的一个实施例中，MBSF接收来自于应用功能实体的多播业务会话开始请求的过程可以是接收应用功能实体直接发送的多播业务会话开始请求。
在本申请的一个实施例中，MBSF接收来自于应用功能实体的多播业务会话开始请求的过程可以是接收NEF转发的来自于应用功能实体的多播业务会话开始请求。由于不同的UE可以选择了不同的MBSF，因此可能存在多个需要发送到的MBSF，在这种情况下，应用功能实体向NEF发送的多播业务会话开始请求中包含有需要发送到的MBSF标识列表，或者应用功能实体向NEF发送多个多播业务会话开始请求，各个多播业务会话开始请求中包含有一个需要发送到的MBSF的标识。
以上分别从终端设备、SMF和MBSF的角度对本申请实施例的技术方案进行了说明，以下从各个实体交互的角度对本申请实施例的技术方案的实现细节进行详细阐述。
本申请实施例的技术方案主要是希望在5G(乃至后续的诸如6G等)通信系统中，能够使得UE一次就可以正确地选择到MBMS多播业务的APN，并激活MBMS多播上下文。核心思路是：提出了通过5G的UE Policy配置UE的MBMS Policy，通过这个MBMS Policy，5G UE就可以根据不同的IP多播地址选择对应的S-NSSAI与DNN，然后以此S-NSSAI与DNN来创建MBMS UE上下文(或PDU Session)。
在本申请的实施例1a中，可以在如表2所示的URSP Rule中增加一个项，得到下述表3：
/>
表3
如表3所示，在URSP Rule中增加一个项，即MBS(or Multicast)IP Descriptors，同时增加了相应的说明(表3中加粗且由下划线的内容为新增内容)。该MBS(or Multicast)IP Descriptors用于描述一个目标IP 2元组，该目标IP 2元组中包含一个IPv4或IPv6多播地址，及高于IP的IGMP协议。该实施例1a使得可以基于IGMP Join数据包来实现多播上下文的激活。
在本申请的实施例1b中，可以在如表2所示的URSP Rule中增加值与功能说明，得到下述表4：
/>
表4
如表4所示(表4中加粗且由下划线的内容为新增内容)，通过增加连接能力的值，使得能够直接通过URSP中的连接能力的值来直接指示其实用于MBS的Multicast业务。由于连接能力(Connection Capabilities)是在标准TS24.526中所定义，因此需要在TS24.526中的“Connection Capabilities”增加一个新的8位字节的编码值用于指示是多播通信，比如可以是“00001001”。该新的编码值所对应的名称可以是MBS、Multicast、MBMS中的任意一个，或者也可以是其它用于表示多播通信的名称。
在实施例1b中，如果一个URSP Rule中的“Connection Capabilities”指示的值是“MBS/Multicast/MBMS”，同时基于IP Descriptors中的目的IP地址是(IPv4或IPv6)多播地址、Protocol ID为IGMP且没有Port Number(由于IGMP协议没有端口号)，则可确定该URSPRule是支持多播通信的URSP Rule。
在本申请的实施例1c中，可以在如表2所示的URSP Rule中增加一个项，并增加“Connection Capabilities”的值与功能说明，得到下述表5：
/>
表5
如表5所示(表5中加粗且由下划线的内容为新增内容)，在URSP Rule中增加一个项，即MBS(or Multicast)IP Descriptors，同时增加了相应的说明(表3中加粗且由下划线的内容为新增内容)。该MBS(or Multicast)IP Descriptors用于描述一个目标IP 2元组，该目标IP 2元组中包含一个IPv4或IPv6多播地址，及高于IP的IGMP协议。同时，如实施例1b，通过增加连接能力的值，使得能够直接通过URSP中的连接能力的值来直接指示其实用于MBS的Multicast业务。
实施例1c是实施例1a与实施例1b的综合，在这种情况下，如果一个URSP Rule中的“Connection Capabilities”指示的值是“MBS/Multicast/MBMS”，同时MBS(or Multicast)IP Descriptors描述的目标IP 2元组中包含一个IPv4或IPv6多播地址，及高于IP的IGMP协议，则可确定该URSP Rule是支持多播通信的URSP Rule。
在本申请的实施例2a中，可以在如表2所示的URSP Rule中增加值与功能说明，得到下述表6：
/>
/>
表6
如表6所示(表6中加粗且由下划线的内容为新增内容)，增加了连接能力的值，由于连接能力(Connection Capabilities)是在标准TS24.526中所定义，因此需要在TS24.526中的“Connection Capabilities”增加一个新的8位字节的编码值用于指示是多播通信/广播通信，比如可以是“00001001”。该新的编码值所对应的名称可以是MBS、Multicast、MBMS、Broadcast中的任意一个，或者也可以是其它用于表示多播通信/广播通信的名称。实施例2a相比于实施例1b而言，对连接能力的取值增加了一个broadcast，因此实施例1b是基于IGMP Join的方案，因此只能支持多播，而实施例2a是基于数据传输来实现，其不仅适用于多播通信，也可以实现广播传输。但是，如果使用广播传输，那么UE无需建立MBS上下文，也无需发送IGMP数据包。
基于实施例2a，如果一个URSP Rule中的“Connection Capabilities”指示的值是“MBS/Multicast/MBMS”，则可确定该URSP Rule是通过下行传输来支持多播通信的URSPRule。
在本申请的实施例2b中，可以在如表2所示的URSP Rule中增加一个项，得到下述表7：
/>
表7
如表7所示(表7中加粗且由下划线的内容为新增内容)，在URSP Rule中增加一个项，即MBS(or Multicast/Broadcast)IP Descriptors，同时增加了相应的说明。该MBS(orMulticast/Broadcast)IP Descriptors用于描述一个下行目标IP 3元组(IPv4或IPv6的多播/广播地址，端口号，高于IP的协议ID)。如果一个IP地址是多播或广播IPv4或IPv6地址，则使用MBS IP描述符。该实施例2b使得可以基于下行数据传输来实现多播业务。
在本申请的实施例2c中，可以在如表2所示的URSP Rule中增加一个项，得到下述表8：
/>
/>
表8
如表8所示(表8中加粗且由下划线的内容为新增内容)，增加了连接能力的值，由于连接能力(Connection Capabilities)是在标准TS24.526中所定义，因此需要在TS24.526中的“Connection Capabilities”增加一个新的8位字节的编码值用于指示是多播通信/广播通信，比如可以是“00001001”。该新的编码值所对应的名称可以是MBS、Multicast、MBMS、Broadcast中的任意一个，或者也可以是其它用于表示多播通信/广播通信的名称。同时，在URSP Rule中增加一个项，即MBS(or Multicast/Broadcast)IPDescriptors，同时增加了相应的说明。该MBS(or Multicast/Broadcast)IP Descriptors用于描述一个下行目标IP 3元组(IPv4或IPv6的多播/广播地址，端口号，高于IP的协议ID)。如果连接能力的值是“MBS”、“Multicast”、“MBMS”或者“Broadcast”，那么使用MBS IP描述符；否则，使用IP描述符用于上行IP包。该实施例2c同样使得可以基于下行数据传输来实现多播业务。
在本申请的一个实施例中，基于前述实施例中的URSP规则，当UE在注册过程中，AMF与PCF建立UE Policy Association，在此过程中，PCF将UE Policy传输给UE，其中就包含有本申请实施例中提出的支持MBS Multicast的URSP Rules，比如图10中在步骤S1021b中，图11中在步骤S1106和步骤S1108中都包含有本申请实施例中提出的支持MBSMulticast的URSP Rules，基于这些URSP Rules在申请的实施例中就可以通过一个过程建立MBS的PDU Session。
如图17所示，根据本申请的一个实施例的基于URSP的多播通信方法，该多播通信方法适用于图12所示的系统架构，主要包括如下步骤：
步骤S1701，UE发起注册(Registration)过程，此过程在标准TS23.502的章节4.2.2.2Registration procedures所定义，并且在图10中所示的步骤S1021b中，AMF与PCF建立UE Policy Association过程。
步骤S1702，依据标准TS23.502的章节4.16.11，在建立这个UE PolicyAssociation过程中，PCF将URSP Rule推送给UE。其中的URSP Rule就包含上述实施例1a、实施例1b、实施例1c、实施例2a、实施例2b、实施例2c中包含有MBS Multicast信息的URSPRules。
步骤S1703，UE需要激活到一个IP Multicast地址对应的多播业务上下文时，根据此IP Multicast地址查询相关的URSP Rule得到Route Selection Descriptor中所包含的S-NSSAI与DNN信息。注意，此IP Multicast地址可以是IPv4多播地址，也可以是IPv6多播地址。
步骤S1704，依据步骤S1703所获得的S-NSSAI与DNN，UE发起PDU会话建立过程，即发送PDU Session Establishment Request，该请求中包含有步骤S1703获得的S-NSSAI、DNN信息等，然后AMF根据S-NSSAI及DNN信息选择一个SMF，SMF选择一个UPF，然后SMF给此UE分配一个IP地址，此过程在标准TS23.502的章节4.3.2PDU Session Establishment所定义。
步骤S1705，在建立PDU Session之后，UE在用户面以步骤S1704中所分配的IP地址为源地址向UPF发送一个IGMP Join数据包，此IGMP数据包即为IGMP Membership Report消息。其中IGMP Join数据包所包含的IP Multicast地址就是步骤S1703中选择S-NSSAI与DNN时的IP Multicast地址。注意，如果采用IGMPv1/v2的协议，那么此IP包的目的IP地址就是此IP多播地址；如果采用IGMPv3协议，那么此IP多播地址是在IP包的IGMP协议部分。
步骤S1706，UPF根据SMF的PDR(Packet Detection Rule，报文检测规则)配置，检测到IGMP Join数据包后通过N4 Session Report消息向SMF报告此IGMP包的多播地址信息。
步骤S1707，SMF依据步骤S1704中建立的PDU Session时的信息(S-NSSAI、DNN、UEID、IP Multicast Address等)确定MBS AF，然后向MBS AF发送MBS授权请求通知(Nsmf_MBSAuthorizationRequest Notify)消息，该MBS授权请求通知消息中包含有S-NSSAI、DNN、UEID、IP Multicast Address、UE Location等。
其中，UE ID可以是GPSI(Generic Public Subscription Identifier，通用公共签约标识)、SUPI(Subscription Permanent Identifier，签约永久标识)。UE Location可以是CGI(Common Gateway Interface，公共网关接口)、TAI(Tracking Area Identity，跟踪区域标识)、GUAMI(Globally Unique AMF Identifier，全球唯一AMF标识)等。
在本申请的一个实施例中，SMF也可以事先不选择MBS AF，而是将此Nsmf_MBSAuthorizationRequest Notify消息发送给NEF，然后NEF根据根据消息中的参数S-NSSAI、DNN、UE ID、IP Multicast Address等确定MBS AF，并向MBS AF发送Nnef_MBSAuthorizationRequest Notify消息。
步骤S1708，整个UE的MBS UE上下文在5G系统中激活。
步骤S1709，当MBS AF将要发送多播数据到步骤S1703中同一IP多播地址之前，向SMF发送MBS会话开始请求(Nsmf_MBSSessionStart Request)，该MBS会话开始请求中包含有IP Multicast、TMGI、QoS、time to multicast data transfer(组播数据传输时间)、estimated session duration(预估工作时间)、session ID等。
在本申请的一个实施例中，当NEF被使用时，则MBS AF是先向NEF发送Nnef_MBSSessionStart Request(包含有SMF ID的列表、IP Multicast、TMGI、QoS、time tomulticast data transfer、estimated session duration、session ID)消息，然后NEF向各个SMF发送Nsmf_MBSSessionStart Request(包含有IP Multicast、TMGI、QoS、time tomulticast data transfer、estimated session duration、session ID)消息。
注意，由于有很多UE接入到相同的IP Multicast Address所标识的MBSMulticast业务，因此有可能有不同的SMF被不同的UE所选择。此时，MBS AF是要向所有这些SMF发送Nsmf_MBSSessionStart Request消息。在这种情况下，若使用NEF，则MBS AF发送的消息中包含这些SMF Id的列表，这样NEF才能分别向不同的SMF发送Nsmf_MBSSessionStart Request消息。另外，MBS AF也可以在向NEF发送的消息中只添加一个SMFID，这样MBS AF就分别以不同的SMF ID向NEF发送Nnef_MBSSessionStart Request(包含有SMF ID、IP Multicast、TMGI、QoS、time to multicast data transfer、estimatedsession duration、session ID)消息，然后NEF就向对应的SMF发送Nsmf_MBSSessionStartRequest消息。
步骤S1710，MBS Session被激活，即从UPF到UE的用户面被建立，特别是UE与RAN的空口资源被分配。
步骤S1711，MBS多播业务开始向IP多播地址发送数据，数据首先到UPF，然后到达RAN，最后到达UE。注意，由MBS多播业务的用户面整体上是一个传播树，MBS AF首先是向一个或多个UPF发送IP多播数据包，然后UPF向一个或多个RAN发送此IP多播数据包，然后RAN通过空口向一个或多个UE同时传输此IP多播数据包。
如图18所示，根据本申请的一个实施例的基于URSP的多播通信方法，该多播通信方法适用于图13所示的系统架构，主要包括如下步骤：
步骤S1801，UE发起注册(Registration)过程，此过程在标准TS23.502的章节4.2.2.2Registration procedures所定义，并且在图10中所示的步骤S1021b中，AMF与PCF建立UE Policy Association过程。
步骤S1802，依据标准TS23.502的章节4.16.11，在建立这个UE PolicyAssociation过程中，PCF将URSP Rule推送给UE。其中的URSP Rule就包含上述实施例1a、实施例1b、实施例1c、实施例2a、实施例2b、实施例2c中包含有MBS Multicast信息的URSPRules。
步骤S1803，UE需要激活到一个IP Multicast地址对应的多播业务上下文时，根据此IP Multicast地址查询相关的URSP Rule得到Route Selection Descriptor中所包含的S-NSSAI与DNN信息。注意，此IP Multicast地址可以是IPv4多播地址，也可以是IPv6多播地址。
步骤S1804，依据步骤S1803所获得的S-NSSAI与DNN，UE发起PDU会话建立过程，即发送PDU Session Establishment Request，该请求中包含有步骤S1803获得的S-NSSAI、DNN信息等，然后M-AMF(M-AMF在图18中未示出)根据S-NSSAI及DNN信息选择一个MB-SMF，MB-SMF选择一个MB-UPF，然后MB-SMF给此UE分配一个IP地址，此过程在标准TS23.502的章节4.3.2PDU Session Establishment所定义。根据5G MBS标准，此时UE接入的M-AMF可以是不同于步骤S1801中的AMF。
步骤S1805，在建立PDU Session之后，UE在用户面以步骤S1804中所分配的IP地址为源地址向MB-UPF发送一个IGMP Join数据包，此IGMP数据包即为IGMP MembershipReport消息。其中IGMP Join数据包所包含的IP Multicast地址就是步骤S1803中选择S-NSSAI与DNN时的IP Multicast地址。注意，如果采用IGMPv1/v2的协议，那么此IP包的目的IP地址就是此IP多播地址；如果采用IGMPv3协议，那么此IP多播地址是在IP包的IGMP协议部分。
步骤S1806，MB-UPF根据MB-SMF的PDR(Packet Detection Rule，报文检测规则)配置，检测到IGMP Join数据包后通过N4 Session Report消息向MB-SMF报告此IGMP包的多播地址信息。
步骤S1807，MB-SMF依据S1804中建立的PDU Session时的信息(S-NSSAI、DNN、UEID、IP Multicast Address等)确定MBSF，然后向MBSF发送MBS授权请求通知(Nmb-smf_MBSAuthorizationRequest Notify)消息，该MBS授权请求通知消息中包含有S-NSSAI、DNN、UEID、IP Multicast Address、UE Location等。其中，UE ID可以是GPSI、SUPI。UE Location可以是CGI、TAI、M-AMF的GUAMI等。
步骤S1808，MBSF依据步骤S1807接收到的参数(S-NSSAI、DNN、UE ID、IPMulticast Address等)确定MBS AF，然后向MBS AF发送Nmbsf_MBS AuthorizationRequestNotify消息(包含有S-NSSAI、DNN、UE ID、IP Multicast Address、UE Location)。
在本申请的一个实施例中，MBSF也可以事先不选择MBS AF，而是将此Nmbsf_MBSAuthorizationRequest Notify消息发送给NEF，然后NEF根据消息中的参数(S-NSSAI、DNN，UE ID、IP Multicast Address)确定MBS AF，并向MBS AF发送Nnef_MBSAuthorizationRequest Notify消息(该消息中包含有S-NSSAI、DNN、UE ID、IP MulticastAddress、UE Location)。
步骤S1809，整个UE的MBS UE上下文在5G系统中激活。
步骤S1810，当MBS AF将要发送多播数据到步骤S1803中同一IP多播地址之前，向MBSF发送MBS会话开始请求(Nmbsf_MBSSessionStart Request)消息，该MBS会话开始请求信息中包含有IP Multicast、TMGI、QoS、time to multicast data transfer、estimatedsession duration、session ID。
在本申请的一个实施例中，当NEF被使用时，则MBS AF是先向NEF发送Nnef_MBSSessionStart Request(包含有SMF ID的列表、IP Multicast、TMGI、QoS、time tomulticast data transfer、estimated session duration、session ID)消息，然后NEF向各个MBSF发送Nmbsf_MBSSessionStart Request(包含有IP Multicast、TMGI、QoS、time tomulticast data transfer、estimated session duration、session ID)消息。
注意，由于有很多的UE接入到相同的IP Multicast Address所标识的MBSMulticast业务，因此有可能有不同的MBSF被不同的UE所选择。此时，MBS AF是要向所有这些MBSF分别发送消息。在这种情况下，若使用NEF时，则MBS AF发送的消息中包含这些MBSFId的列表，这样NEF才能分别向不同的MBSF发送Nmbsf_MBSSessionStart Request消息。另外，MBS AF也可以在向NEF发送的消息中只添加一个MBSF ID，这样MBS AF就分别以不同的MBSF ID向NEF发送Nnef_MBSSessionStart Request(包含有MBSF ID、IP Multicast、TMGI、QoS、time to multicast data transfer、estimated session duration、session ID)消息，然后NEF就向对应的MBSF发送Nmbsf_MBSSessionStart Request消息。
步骤S1811，MBS Session被激活，即从UPF到UE的用户面被建立，特别是UE与RAN的空口资源被分配。
步骤S1812，MBS多播业务开始向IP多播地址发送数据，数据首先到MBSU，然后到达MB-UPF，再到达RAN，最后到达UE。注意，由MBS多播业务的用户面整体上是一个传播树，MBSAF首先是向一个或多个MBSUF发送IP多播数据包，然后MBSU向一个或多个MB-UPF发送此IP多播数据包，同样的MB-UPF向一个或多个RAN发送此IP多播数据包，然后RAN通过空口向一个或多个UE同时传输此IP多播数据包。
如图19所示，根据本申请的一个实施例的基于URSP的多播通信方法，该多播通信方法适用于图12所示的系统架构，主要包括如下步骤：
步骤S1901，UE发起注册(Registration)过程，此过程在标准TS23.502的章节4.2.2.2Registration procedures所定义，并且在图10中所示的步骤S1021b中，AMF与PCF建立UE Policy Association过程。
步骤S1902，依据标准TS23.502的章节4.16.11，在建立这个UE PolicyAssociation过程中，PCF将URSP Rule推送给UE。其中的URSP Rule就包含上述实施例1a、实施例1b、实施例1c、实施例2a、实施例2b、实施例2c中包含有MBS Multicast信息的URSPRules。
步骤S1903，UE需要激活到一个IP Multicast地址对应的多播业务上下文时，根据此IP Multicast地址查询相关的URSP Rule得到Route Selection Descriptor中所包含的S-NSSAI与DNN信息。注意，此IP Multicast地址可以是IPv4多播地址，也可以是IPv6多播地址。
步骤S1904，UE决定以无线优化的方式使用MBS Multicast业务，即不需要事先建立一个PDU Session并分配一个IP地址，UE如何决定以无线优化方式不作限定，如一个放到公共场所(如食堂、候机厅)的“屏幕”，就可使用这种优化的方式来显示一些多播业务。
步骤S1905，UE发起到一个IP Multicast Address的MBS上下文激活过程，UE为MBSSession分配一个MBS Context ID，并发送Activate MBS Context Request(包含MBSContext ID，IP Multicast Address)请求给SMF。类似于PDU Session establishmentRequest，这个Activate MBS Context Request消息作为UL NAS Transport消息中的一个信元发送给AMF，在这个UL NAS Transport消息中包含有在步骤3中得到的S-NSSAI与DNN，并且还包含有N1 MBS SM(Session Management，会话管理)Container，该N1 MBS SMContainer中包含有MBS Context ID和IP Multicast Address。
步骤S1906，AMF根据S-NSSAI和DNN选择一个SMF，然后向SMF发送创建MBS上下文请求(即Nsmf_MBSSession_CreateMBSContext Request)，该创建MBS上下文请求中包含有SUPI、S-NSSAI、DNN、RAN ID、N1 MBS SM Container(Activate MBS Context Request(IPmulticast address)。SMF将其中的RAN ID记录在UE的MBS UE Context中。
步骤S1907，SMF根据从UDM获得UE的签约数据(SMF与UDM的交互没有在图中画出)确定UE是否可以使用此IP Multicast Address的MBS业务。若允许，依据(S-NSSAI、DNN、IPMulticast Address)确定MBS AF，然后向MBS AF发送MBS授权请求通知消息(即Nsmf_MBSAuthorizationRequest Notify)，该MBS授权请求通知消息中包含有MBS AFID、S-NSSAI、DNN、UE ID、IP Multicast Address、SMF ID、UE Location等。其中SMF ID表示发送此消息的SMF的标识，UE ID可以是GPSI、SUPI，UE Location可以是CGI、TAI、GUAMI等。
若根据网络配置，向MBS AF发送消息必须要先发送给NEF，则将此消息先发送给NEF，且包含MBS AF ID参数(图19中示出了先发给NEF，然后由NEF发送给MBS AF的实施例)。
步骤S1908，NEF收到消息后，根据MBS AF ID参数向MBS AF发送Nnef_MBSAuthorizationRequest Notify消息(包含有S-NSSAI、DNN、UEID、IP Multicast Address、SMF ID，UE Location)。
步骤S1909，MBS AF记录消息中的IP Multicast Address对应的SMF ID，若MBS AF是从SMF收到消息的，则回复Nsmf_MBS AuthorizationRequest Notify Response(包含有TMSI)给SMF。若MBS AF是从NEF收到消息的，则回复Nnef_MBS AuthorizationRequestNotify Response(包含有TMGI)。若MBS AF授权不成功，则在响应消息中不分配TMGI，且给出失败的原因。其中，TMSI即为Temporary Mobile Subscriber Identity，中文名称是临时移动用户标识；TMGI即为Temporary Mobile Group Identify，中文名称是临时移动组标识。
步骤S1910，NEF回复MBS授权请求通知响应(即Nsmf_MBS AuthorizationRequestNotify Response)给SMF，该MBS授权请求通知响应中包含有TMSI。
步骤S1911，SMF为此UE创建基于IP Multicast Address的MBS UE Context，然后向AMF回复创建MBS上下文响应(即Nsmf_MBSSession_CreateMBSContext Response)。
步骤S1912，SMF决定回复UE的请求，向AMF发送消息Namf_Communication_N1MessageTransfer(N1 MBS SM Container(Activate MBS Context Response(TMGI)))，其中N1 MBS SM Container(Activate MBS Context Response(TMGI))是要发送给UE的MBS会话管理的响应，因不建立空口资源，所在此消息中不包含SMF给RAN的N2 MBS SessionContainer。
步骤S1913，AMF向RAN发送N2 downlinkNASTransport(DL NAS Transport(N1 MBSSM Container(Activate MBS Context Response(TMGI))))，指示RAN直接将DL NASTransport(N1 MBS SM Container(Activate MBS Context Response(TMGI))发送给UE。
步骤S1914，UE收到NAS消息，并通过MBS SM Container中的Activate MBSContext Response(TMGI)确定IP Multicast Group对应的MBS上下文激活成功，并分配了一个TMGI，后续可以开始进行多播业务。
本申请上述实施例的技术方案使得UE可以通过发送一次请求就激活MBSMulticast UE上下文，并且能够支持IPv4与IPv6的多播地址，以及IGMPv1/2/3协议。同时，本申请实施例的技术方案能够支持目前的两种5G MBS架构，有利于提高多播通信的效率。
以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的多播通信方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的多播通信方法的实施例。
图20示出了根据本申请的一个实施例的多播通信装置的框图，该多播通信装置可以设置在终端设备内部。
参照图20所示，根据本申请的一个实施例的多播通信装置2000，包括：第一接收单元2002、查询单元2004和第一处理单元2006。
其中，第一接收单元2002配置为接收策略控制功能实体发送的URSP信息，所述URSP信息中包含有支持多播业务的URSP规则；查询单元2004配置为根据需要激活的多播业务上下文所对应的多播网络地址，查询所述支持多播业务的URSP规则，得到网络切片信息和数据网络名称信息；第一处理单元2006配置为基于所述网络切片信息和所述数据网络名称信息激活用户设备的多播广播业务MBS上下文信息，以加入所述多播网络地址对应的多播组中进行多播通信。
在本申请的一些实施例中，基于前述方案，第一处理单元2006配置为：基于所述网络切片信息和所述数据网络名称信息发起PDU会话建立请求，以建立PDU会话；基于建立的所述PDU会话，激活所述用户设备的MBS上下文信息。
在本申请的一些实施例中，基于前述方案，第一处理单元2006配置为：以在建立所述PDU会话时分配的网络地址作为源地址，向用户面功能实体发送包含有所述多播网络地址的IGMP数据包，所述IGMP数据包用于指示激活所述用户设备的MBS上下文信息。
在本申请的一些实施例中，基于前述方案，第一处理单元2006配置为：在采用移动通信系统架构进行多播广播业务的情况下，向所述移动通信系统架构内的用户面功能实体发送所述IGMP数据包；在采用新的多播广播业务系统架构的情况下，向所述新的多播广播业务系统架构中的用于进行多播广播业务的用户面功能实体发送所述IGMP数据包。
在本申请的一些实施例中，基于前述方案，第一处理单元2006还配置为：若基于所述网络切片信息和所述数据网络名称信息确定已经存在相匹配的PDU会话，则直接基于所述相匹配的PDU会话，激活所述用户设备的MBS上下文信息。
在本申请的一些实施例中，基于前述方案，所述支持多播业务的URSP规则中包含有针对多播广播业务MBS或多播业务的第一IP地址描述符，所述第一IP地址描述符用于描述目标IP地址二元组，所述目标IP地址二元组中包含有所述多播网络地址及位于IP协议之上的IGMP协议。
在本申请的一些实施例中，基于前述方案，所述URSP信息中的URSP规则中包含有用于描述目标IP地址三元组的第二IP地址描述符，所述目标IP地址三元组中包含有IP地址或IPv6网络前缀，且包含有端口号及位于IP协议之上的协议号；其中，若一URSP规则中的第二IP地址描述符所描述的目标IP地址三元组中包含有所述多播网络地址和IGMP协议，且不包含端口号，则将该URSP规则作为所述支持多播业务的URSP规则。
在本申请的一些实施例中，基于前述方案，所述URSP信息中的URSP规则包含有连接能力信息，所述连接能力信息的值包括用于指示是多播通信的编码值；其中，若一URSP规则中的连接能力信息的值是指示多播通信的编码值，且该URSP规则中的IP地址描述符所描述的目标IP地址三元组中包含有所述多播网络地址和IGMP协议，且不包含端口号，则将该URSP规则作为所述支持多播业务的URSP规则。
在本申请的一些实施例中，基于前述方案，所述支持多播业务的URSP规则中包含有连接能力信息，以及针对多播广播业务MBS或多播业务的第一IP地址描述符；所述第一IP地址描述符用于描述目标IP地址二元组，所述目标IP地址二元组中包含有所述多播网络地址及位于IP协议之上的IGMP协议；所述连接能力信息的值指示的是多播通信的编码值。
在本申请的一些实施例中，基于前述方案，所述URSP信息中的URSP规则包含有连接能力信息，所述连接能力信息的值包括用于指示是多播通信或广播通信的编码值；其中，若一URSP规则中的连接能力信息的值是指示多播通信的编码值，则将该URSP规则作为通过下行传输来支持多播业务的URSP规则。
在本申请的一些实施例中，基于前述方案，所述URSP信息中的URSP规则中包含有针对MBS或多播业务或广播业务的第三IP地址描述符，所述第三IP地址描述符用于描述下行目标IP地址三元组，所述下行目标IP地址三元组中包含有多播网络地址或广播网络地址，且包含有端口号和位于IP协议之上的协议号；其中，若一URSP规则中的所述第三IP地址描述符所描述的下行目标IP地址三元组中包含有多播网络地址，则将该URSP规则作为通过下行传输来支持多播业务的URSP规则。
在本申请的一些实施例中，基于前述方案，所述URSP信息中的URSP规则包含有连接能力信息，所述连接能力信息的值包括用于指示是多播通信或广播通信的编码值；其中，若一URSP规则中的连接能力信息的值是指示多播通信的编码值，且该URSP规则中的针对MBS或多播业务或广播业务的第三IP地址描述符包含有多播网络地址、端口号和位于IP协议之上的协议号，则将该URSP规则作为通过下行传输来支持多播业务的URSP规则。
在本申请的一些实施例中，基于前述方案，第一接收单元2002配置为：在发送注册请求之后，接收所述策略控制功能实体发送的用户设备策略信息，所述用户设备策略信息中包含有所述URSP信息。
图21示出了根据本申请的一个实施例的多播通信装置的框图，该多播通信装置可以设置在会话管理功能实体内部。
参照图21所示，根据本申请的一个实施例的多播通信装置2100，包括：获取单元2102、生成单元2104和第一发送单元2106。
其中，获取单元2102配置为获取用户设备的标识信息、所述用户设备需要激活的多播业务上下文所对应的多播网络地址，以及所述用户设备根据支持多播业务的URSP规则选择的网络切片信息和数据网络名称信息；生成单元2104配置为根据所述网络切片信息、所述数据网络名称信息、所述用户设备的标识信息及所述多播网络地址，生成多播业务授权请求通知消息；第一发送单元2106配置为将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体，以激活所述用户设备的MBS上下文信息。
在本申请的一些实施例中，基于前述方案，获取单元2102配置为：接收用户面功能实体发送的会话报告消息，根据所述会话报告消息获取所述多播网络地址；根据建立所述用户设备的PDU会话时所采用的信息获取所述网络切片信息、所述数据网络名称信息，以及所述用户设备的标识信息。
在本申请的一些实施例中，基于前述方案，在采用移动通信系统架构进行多播广播业务的情况下，第一发送单元2106配置为：根据所述网络切片信息、所述数据网络名称信息、所述用户设备的标识信息及所述多播网络地址，确定所述MBS对应的应用功能实体；将所述多播业务授权请求通知消息直接发送给所述应用功能实体，或者将所述多播业务授权请求通知消息发送给网络开放功能实体，以使所述网络开放功能实体转发至所述应用功能实体。
在本申请的一些实施例中，基于前述方案，在采用移动通信系统架构进行多播广播业务的情况下，第一发送单元2106配置为：将所述多播业务授权请求通知消息发送给网络开放功能实体，以使所述网络开放功能实体根据所述多播业务授权请求通知消息中包含的信息确定所述MBS对应的应用功能实体，并向所述应用功能实体发送所述多播业务授权请求通知消息。
在本申请的一些实施例中，基于前述方案，在采用移动通信系统架构进行多播广播业务的情况下，所述多播通信装置2100还包括：第一激活单元，配置为在所述第一发送单元2106将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体之后，接收来自于所述应用功能实体的多播业务会话开始请求，基于所述多播业务会话开始请求激活多播业务会话。
在本申请的一些实施例中，基于前述方案，所述第一激活单元配置为：接收所述应用功能实体直接发送的所述多播业务会话开始请求；或者接收网络开放功能实体转发的来自于所述应用功能实体的多播业务会话开始请求，其中，应用功能实体向所述网络开放功能实体发送的多播业务会话开始请求中包含有需要发送到的会话管理功能实体标识列表，或者应用功能实体向所述网络开放功能实体发送多个多播业务会话开始请求，各个多播业务会话开始请求中包含有一个需要发送到的会话管理功能实体的标识。
在本申请的一些实施例中，基于前述方案，在采用新的多播广播业务系统架构的情况下，第一发送单元2106配置为：根据所述网络切片信息、所述数据网络名称信息、所述用户设备的标识信息及所述多播网络地址，确定对应的MBSF；将所述多播业务授权请求通知消息发送给所述MBSF，以使所述MBSF将所述多播业务授权请求通知消息转发至所述应用功能实体。
图22示出了根据本申请的一个实施例的多播通信装置的框图，该多播通信装置可以设置在MBSF内部。
参照图22所示，根据本申请的一个实施例的多播通信装置2200，包括：第二接收单元2202和第二发送单元2204。
其中，第二接收单元2202配置为接收多播业务对应的会话管理功能实体发送的多播业务授权请求通知消息，所述多播业务授权请求通知消息中包含有用户设备的标识信息、所述用户设备需要激活的多播业务上下文所对应的多播网络地址，以及所述用户设备根据支持多播业务的URSP规则选择的网络切片信息和数据网络名称信息；第二发送单元2204配置为将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体，以激活所述用户设备的MBS上下文信息。
在本申请的一些实施例中，基于前述方案，第二发送单元2204配置为：根据所述多播业务授权请求通知消息中所包含的信息，确定所述MBS对应的应用功能实体；将所述多播业务授权请求通知消息直接发送给所述应用功能实体，或者将所述多播业务授权请求通知消息发送给网络开放功能实体，以使所述网络开放功能实体转发至所述应用功能实体。
在本申请的一些实施例中，基于前述方案，第二发送单元2204配置为：将所述多播业务授权请求通知消息发送给网络开放功能实体，以使所述网络开放功能实体根据所述多播业务授权请求通知消息中包含的信息确定所述MBS对应的应用功能实体，并向所述应用功能实体发送所述多播业务授权请求通知消息。
在本申请的一些实施例中，基于前述方案，所述多播通信装置2200还包括：第二激活单元，配置为在第二发送单元2204将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体之后，接收来自于所述应用功能实体的多播业务会话开始请求，并基于所述多播业务会话开始请求激活多播业务会话。
在本申请的一些实施例中，基于前述方案，第二接收单元2202配置为：接收所述应用功能实体直接发送的所述多播业务会话开始请求；或者接收网络开放功能实体转发的来自于所述应用功能实体的多播业务会话开始请求，其中，应用功能实体向所述网络开放功能实体发送的多播业务会话开始请求中包含有需要发送到的MBSF标识列表，或者应用功能实体向所述网络开放功能实体发送多个多播业务会话开始请求，各个多播业务会话开始请求中包含有一个需要发送到的MBSF的标识。
图23示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。
需要说明的是，图23示出的电子设备的计算机系统2300仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
如图23所示，计算机系统2300包括中央处理单元(Central Processing Unit，CPU)2301，其可以根据存储在只读存储器(Read-Only Memory，ROM)2302中的程序或者从存储部分2308加载到随机访问存储器(Random Access Memory，RAM)2303中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 2303中，还存储有系统操作所需的各种程序和数据。CPU 2301、ROM 2302以及RAM 2303通过总线2304彼此相连。输入/输出(Input/Output，I/O)接口2305也连接至总线2304。
以下部件连接至I/O接口2305：包括键盘、鼠标等的输入部分2306；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分2307；包括硬盘等的存储部分2308；以及包括诸如LAN(Local AreaNetwork，局域网)卡、调制解调器等的网络接口卡的通信部分2309。通信部分2309经由诸如因特网的网络执行通信处理。驱动器2310也根据需要连接至I/O接口2305。可拆卸介质2311，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器2310上，以便于从其上读出的计算机程序根据需要被安装入存储部分2308。
特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分2309从网络上被下载和安装，和/或从可拆卸介质2311被安装。在该计算机程序被中央处理单元(CPU)2301执行时，执行本申请的系统中限定的各种功能。
需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。
作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。
本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (19)

1.一种多播通信方法，其特征在于，包括：
接收策略控制功能实体发送的用户路由选择策略URSP信息，所述URSP信息中包含有支持多播业务的URSP规则；
根据需要激活的多播业务上下文所对应的多播网络地址，查询所述支持多播业务的URSP规则，得到网络切片信息和数据网络名称信息；
基于所述网络切片信息和所述数据网络名称信息激活用户设备的多播广播业务MBS上下文信息，以加入所述多播网络地址对应的多播组中进行多播通信。
2.根据权利要求1所述的多播通信方法，其特征在于，所述支持多播业务的URSP规则中包含有针对多播广播业务MBS或多播业务的第一IP地址描述符，所述第一IP地址描述符用于描述目标IP地址二元组，所述目标IP地址二元组中包含有所述多播网络地址及位于IP协议之上的IGMP协议。
3.根据权利要求1所述的多播通信方法，其特征在于，所述URSP信息中的URSP规则中包含有用于描述目标IP地址三元组的第二IP地址描述符，所述目标IP地址三元组中包含有IP地址或IPv6网络前缀，且包含有端口号及位于IP协议之上的协议号；
其中，若一URSP规则中的第二IP地址描述符所描述的目标IP地址三元组中包含有所述多播网络地址和IGMP协议，且不包含端口号，则将该URSP规则作为所述支持多播业务的URSP规则。
4.根据权利要求1所述的多播通信方法，其特征在于，所述URSP信息中的URSP规则包含有连接能力信息，所述连接能力信息的值包括用于指示是多播通信的编码值；
其中，若一URSP规则中的连接能力信息的值是指示多播通信的编码值，且该URSP规则中的IP地址描述符所描述的目标IP地址三元组中包含有所述多播网络地址和IGMP协议，且不包含端口号，则将该URSP规则作为所述支持多播业务的URSP规则。
5.根据权利要求1所述的多播通信方法，其特征在于，所述支持多播业务的URSP规则中包含有连接能力信息，以及针对多播广播业务MBS或多播业务的第一IP地址描述符；
所述第一IP地址描述符用于描述目标IP地址二元组，所述目标IP地址二元组中包含有所述多播网络地址及位于IP协议之上的IGMP协议；所述连接能力信息的值指示的是多播通信的编码值。
6.根据权利要求1所述的多播通信方法，其特征在于，所述URSP信息中的URSP规则包含有连接能力信息，所述连接能力信息的值包括用于指示是多播通信或广播通信的编码值；
其中，若一URSP规则中的连接能力信息的值是指示多播通信的编码值，则将该URSP规则作为通过下行传输来支持多播业务的URSP规则。
7.根据权利要求1所述的多播通信方法，其特征在于，所述URSP信息中的URSP规则中包含有针对MBS或多播业务或广播业务的第三IP地址描述符，所述第三IP地址描述符用于描述下行目标IP地址三元组，所述下行目标IP地址三元组中包含有多播网络地址或广播网络地址，且包含有端口号和位于IP协议之上的协议号；
其中，若一URSP规则中的所述第三IP地址描述符所描述的下行目标IP地址三元组中包含有多播网络地址，则将该URSP规则作为通过下行传输来支持多播业务的URSP规则。
8.根据权利要求1所述的多播通信方法，其特征在于，所述URSP信息中的URSP规则包含有连接能力信息，所述连接能力信息的值包括用于指示是多播通信或广播通信的编码值；
其中，若一URSP规则中的连接能力信息的值是指示多播通信的编码值，且该URSP规则中的针对MBS或多播业务或广播业务的第三IP地址描述符包含有多播网络地址、端口号和位于IP协议之上的协议号，则将该URSP规则作为通过下行传输来支持多播业务的URSP规则。
9.一种多播通信方法，其特征在于，包括：
获取用户设备的标识信息、所述用户设备需要激活的多播业务上下文所对应的多播网络地址，以及所述用户设备根据支持多播业务的URSP规则选择的网络切片信息和数据网络名称信息；
根据所述网络切片信息、所述数据网络名称信息、所述用户设备的标识信息及所述多播网络地址，生成多播业务授权请求通知消息；
将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体，以激活所述用户设备的MBS上下文信息。
10.根据权利要求9所述的多播通信方法，其特征在于，获取用户设备的标识信息、所述用户设备需要激活的多播业务上下文所对应的多播网络地址，以及所述用户设备根据支持多播业务的URSP规则选择的网络切片信息和数据网络名称信息，包括：
接收用户面功能实体发送的会话报告消息，根据所述会话报告消息获取所述多播网络地址；
根据建立所述用户设备的PDU会话时所采用的信息获取所述网络切片信息、所述数据网络名称信息，以及所述用户设备的标识信息。
11.根据权利要求9所述的多播通信方法，其特征在于，在采用移动通信系统架构进行多播广播业务的情况下，将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体，包括：
根据所述网络切片信息、所述数据网络名称信息、所述用户设备的标识信息及所述多播网络地址，确定所述MBS对应的应用功能实体；
将所述多播业务授权请求通知消息直接发送给所述应用功能实体，或者将所述多播业务授权请求通知消息发送给网络开放功能实体，以使所述网络开放功能实体转发至所述应用功能实体。
12.根据权利要求9所述的多播通信方法，其特征在于，在采用移动通信系统架构进行多播广播业务的情况下，将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体，包括：
将所述多播业务授权请求通知消息发送给网络开放功能实体，以使所述网络开放功能实体根据所述多播业务授权请求通知消息中包含的信息确定所述MBS对应的应用功能实体，并向所述应用功能实体发送所述多播业务授权请求通知消息。
13.根据权利要求9所述的多播通信方法，其特征在于，在采用移动通信系统架构进行多播广播业务的情况下，在将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体之后，所述多播通信方法还包括：
接收来自于所述应用功能实体的多播业务会话开始请求；
基于所述多播业务会话开始请求激活多播业务会话。
14.根据权利要求13所述的多播通信方法，其特征在于，接收来自于所述应用功能实体的多播业务会话开始请求，包括：
接收所述应用功能实体直接发送的所述多播业务会话开始请求；或
接收网络开放功能实体转发的来自于所述应用功能实体的多播业务会话开始请求，其中，应用功能实体向所述网络开放功能实体发送的多播业务会话开始请求中包含有需要发送到的会话管理功能实体标识列表，或者应用功能实体向所述网络开放功能实体发送多个多播业务会话开始请求，各个多播业务会话开始请求中包含有一个需要发送到的会话管理功能实体的标识。
15.根据权利要求9所述的多播通信方法，其特征在于，在采用新的多播广播业务系统架构的情况下，将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体，包括：
根据所述网络切片信息、所述数据网络名称信息、所述用户设备的标识信息及所述多播网络地址，确定对应的多播广播业务实体MBSF；
将所述多播业务授权请求通知消息发送给所述MBSF，以使所述MBSF将所述多播业务授权请求通知消息转发至所述应用功能实体。
16.一种多播通信装置，其特征在于，包括：
第一接收单元，配置为接收策略控制功能实体发送的URSP信息，所述URSP信息中包含有支持多播业务的URSP规则；
查询单元，配置为根据需要激活的多播业务上下文所对应的多播网络地址，查询所述支持多播业务的URSP规则，得到网络切片信息和数据网络名称信息；
第一处理单元，配置为基于所述网络切片信息和所述数据网络名称信息激活用户设备的多播广播业务MBS上下文信息，以加入所述多播网络地址对应的多播组中进行多播通信。
17.一种多播通信装置，其特征在于，包括：
获取单元，配置为获取用户设备的标识信息、所述用户设备需要激活的多播业务上下文所对应的多播网络地址，以及所述用户设备根据支持多播业务的URSP规则选择的网络切片信息和数据网络名称信息；
生成单元，配置为根据所述网络切片信息、所述数据网络名称信息、所述用户设备的标识信息及所述多播网络地址，生成多播业务授权请求通知消息；
第一发送单元，配置为将所述多播业务授权请求通知消息发送给MBS对应的应用功能实体，以激活所述用户设备的MBS上下文信息。
18.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至15中任一项所述的多播通信方法。
19.一种电子设备，其特征在于，包括：
一个或多个处理器；
存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至15中任一项所述的多播通信方法。
CN202310898014.9A 2020-05-13 2020-05-13 多播通信方法、装置、计算机可读介质及电子设备 Pending CN116962994A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310898014.9A CN116962994A (zh) 2020-05-13 2020-05-13 多播通信方法、装置、计算机可读介质及电子设备

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010403660.XA CN111491346B (zh) 2020-05-13 2020-05-13 多播通信方法、装置、计算机可读介质及电子设备
CN202310898014.9A CN116962994A (zh) 2020-05-13 2020-05-13 多播通信方法、装置、计算机可读介质及电子设备

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN202010403660.XA Division CN111491346B (zh) 2020-05-13 2020-05-13 多播通信方法、装置、计算机可读介质及电子设备

Publications (1)

Publication Number Publication Date
CN116962994A true CN116962994A (zh) 2023-10-27

Family

ID=71795840

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202010403660.XA Active CN111491346B (zh) 2020-05-13 2020-05-13 多播通信方法、装置、计算机可读介质及电子设备
CN202310898014.9A Pending CN116962994A (zh) 2020-05-13 2020-05-13 多播通信方法、装置、计算机可读介质及电子设备

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202010403660.XA Active CN111491346B (zh) 2020-05-13 2020-05-13 多播通信方法、装置、计算机可读介质及电子设备

Country Status (4)

Country Link
US (1) US20220225058A1 (zh)
EP (1) EP4027700A4 (zh)
CN (2) CN111491346B (zh)
WO (1) WO2021227702A1 (zh)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111491346B (zh) * 2020-05-13 2023-06-30 腾讯科技（深圳）有限公司 多播通信方法、装置、计算机可读介质及电子设备
US11832277B2 (en) * 2020-07-07 2023-11-28 Lg Electronics Inc. Method and apparatus for paging for multicast and broadcast service in a wireless communication system
EP4184974A4 (en) * 2020-08-07 2023-08-30 Huawei Technologies Co., Ltd. REGISTRATION PROCEDURE AND DEVICE
CN114071374B (zh) * 2020-08-07 2023-06-20 华为技术有限公司 通信方法、装置及系统
WO2022032560A1 (en) * 2020-08-13 2022-02-17 Qualcomm Incorporated Flexible network slice selection procedure
BR112023002702A2 (pt) * 2020-08-13 2023-05-02 Huawei Tech Co Ltd Método e aparelho para enviar pacote de multicast e método e aparelho para obter entrada de encaminhamento
CN114079984B (zh) * 2020-08-14 2023-08-04 大唐移动通信设备有限公司 一种mbs业务数据传输方法和网络侧装置及设备
CN112073919B (zh) * 2020-09-08 2024-03-01 腾讯科技（深圳）有限公司 多播广播业务的通信方法及装置、电子设备、存储介质
WO2022060787A1 (en) * 2020-09-18 2022-03-24 Google Llc Managing multicast and broadcast services interest information
CN114513757B (zh) * 2020-11-17 2024-05-10 维沃移动通信有限公司 信息获取方法、指示方法、装置、相关设备和存储介质
CN114745717A (zh) * 2020-12-23 2022-07-12 中国移动通信有限公司研究院 一种校验方法、装置、通信设备和计算机存储介质
EP4216664A4 (en) * 2020-12-24 2024-04-17 Samsung Electronics Co Ltd METHOD AND DEVICE ALLOWING A TERMINAL TO PARTICIPATE IN A MULTICAST SERVICE
EP4260522A4 (en) * 2021-01-14 2024-02-21 Zte Corp ACTIVATION AND DEACTIVATION OF A MULTICAST BROADCAST SERVICE SESSION ON WIRELESS NETWORKS
CN114827907B (zh) * 2021-01-19 2023-07-11 维沃移动通信有限公司 触发非单播业务操作的方法、装置及网络功能实体
CN112968836B (zh) * 2021-01-31 2022-05-27 新华三信息安全技术有限公司 跨设备聚合链路配置方法、装置、设备及可读存储介质
CN112954615B (zh) * 2021-02-10 2023-05-23 腾讯科技（深圳）有限公司 多播广播业务的通信方法、装置、介质及电子设备
CN112954616B (zh) * 2021-02-10 2023-06-09 腾讯科技（深圳）有限公司 用于实现多播广播业务切换的方法及相关设备
CN115038050B (zh) * 2021-03-05 2023-09-05 中国移动通信有限公司研究院 业务通知方法、装置、设备及可读存储介质
CN113115299B (zh) * 2021-03-22 2022-11-18 中国联合网络通信集团有限公司 一种ursp规则更新方法及装置
JP2024517916A (ja) * 2021-05-10 2024-04-23 テレフオンアクチーボラゲット エルエム エリクソン（パブル） セッション解放のための方法およびデバイス
CN115706933A (zh) * 2021-08-10 2023-02-17 华为技术有限公司 一种通信方法及装置
CN113904871B (zh) * 2021-11-12 2023-11-21 中国电信股份有限公司 网络切片的接入方法、pcf实体、终端和通信系统
CN116471219A (zh) * 2022-01-11 2023-07-21 腾讯科技（深圳）有限公司 数据传输方法及相关设备
WO2023143241A1 (en) * 2022-01-27 2023-08-03 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for multicast and broadcast service
CN114980364A (zh) * 2022-04-18 2022-08-30 成都鼎桥通信技术有限公司 基于ursp规则的本地局域网通信方法、装置及介质
CN114885382B (zh) * 2022-07-12 2022-10-25 北京艾灵客科技有限公司 一种业务会话管理方法、装置及存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019034291A1 (en) * 2017-08-14 2019-02-21 Telefonaktiebolaget Lm Ericsson (Publ) METHOD AND APPARATUS FOR SETTING NETWORK INITIATED PACKET DATA UNIT (PDU) SESSION IN TELECOMMUNICATION NETWORK
WO2019211662A1 (en) * 2018-04-30 2019-11-07 Lenovo (Singapore) Pte. Ltd. Establishing an ip multimedia subsystem session
US10524198B2 (en) * 2018-05-18 2019-12-31 Intel Corporation UE indication to PCF whether or not to send UE policy
US11382145B2 (en) * 2018-08-06 2022-07-05 Huawei Technologies Co., Ltd. Systems and methods to support group communications
CN111988828B (zh) * 2018-11-23 2021-08-10 腾讯科技（深圳）有限公司 路由选择策略的获取方法、装置及设备
CN111526552B (zh) * 2020-05-13 2024-02-02 腾讯科技（深圳）有限公司 Ue执行的方法及ue、以及smf实体执行的方法及smf实体
CN111491346B (zh) * 2020-05-13 2023-06-30 腾讯科技（深圳）有限公司 多播通信方法、装置、计算机可读介质及电子设备

Also Published As

Publication number Publication date
EP4027700A1 (en) 2022-07-13
CN111491346B (zh) 2023-06-30
US20220225058A1 (en) 2022-07-14
EP4027700A4 (en) 2022-12-28
WO2021227702A1 (zh) 2021-11-18
CN111491346A (zh) 2020-08-04

Similar Documents

Publication Publication Date Title
CN111491346B (zh) 多播通信方法、装置、计算机可读介质及电子设备
US11051359B2 (en) Managing MBMS membership at the service capability exposure function
KR102065927B1 (ko) 에지 mbms 서비스를 위한 데이터 송신 방법 및 관련 디바이스
US8730860B2 (en) Provision of multimedia broadcast/multicast service (MBMS) for roaming subscribers
US8325641B2 (en) Method and apparatus for service identifying and routing in multimedia broadcast/multicast service system
US20230025793A1 (en) Method, apparatus, medium and electronic device for multicast broadcast service
US20220408228A1 (en) Communication method and apparatus for multicast broadcast service, storage medium, and electronic device
EP1921794A2 (en) Relay device, wireless communication system and multicast relay method
CN111556539B (zh) Ue执行的方法及ue、以及smf实体执行的方法及smf实体
CN111866756B (zh) 多播广播业务的通信方法、装置、计算机可读介质及设备
CN111866758B (zh) 多播广播业务的通信方法、装置、介质及电子设备
CN111526552A (zh) Ue执行的方法及ue、以及smf实体执行的方法及smf实体
US20090264064A1 (en) Method and system for service announcement using mbms multicast bearer
US20070133565A1 (en) Content packet transmission control method in mobile communication network supporting multimedia broadcast/multicast service
CN111526553A (zh) Ue执行的方法及ue、以及smf实体执行的方法及smf实体
CN113068134B (zh) 多播业务会话操作的方法、装置和通信设备
US20090080354A1 (en) Multimedia Broadcast Multicast Service Providing System and Method Thereof
US20230081286A1 (en) Methods and systems for multicast data forwarding during mobility procedures in wireless communication networks
WO2023151514A1 (en) Method and apparatus for group message delivery
WO2023143241A1 (en) Method and apparatus for multicast and broadcast service
KR20090100766A (ko) 멀티캐스팅을 지원하는 무선 통신 시스템 및 방법

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination