CN114731460B - 一种多播会话的建立方法及网络设备 - Google Patents

一种多播会话的建立方法及网络设备 Download PDF

Info

Publication number
CN114731460B
CN114731460B CN201980102026.8A CN201980102026A CN114731460B CN 114731460 B CN114731460 B CN 114731460B CN 201980102026 A CN201980102026 A CN 201980102026A CN 114731460 B CN114731460 B CN 114731460B
Authority
CN
China
Prior art keywords
multicast
network element
information
session
policy
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.)
Active
Application number
CN201980102026.8A
Other languages
English (en)
Other versions
CN114731460A (zh
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN114731460A publication Critical patent/CN114731460A/zh
Application granted granted Critical
Publication of CN114731460B publication Critical patent/CN114731460B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1403—Architecture for metering, charging or billing
    • H04L12/1407—Policy-and-charging control [PCC] architecture
    • 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/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission
    • 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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/66—Policy and charging system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/80—Rating or billing plans; Tariff determination aspects
    • H04M15/8016—Rating or billing plans; Tariff determination aspects based on quality of service [QoS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/82—Criteria or parameters used for performing billing operations
    • H04M15/8228—Session based

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Quality & Reliability (AREA)
  • Accounting & Taxation (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请公开了一种多播会话的建立方法及网络设备，涉及无线通信技术领域，可以基于运营商已部署的网络架构实现多播会话的建立，简化网络架构，节省开支。具体的，在建立多播会话时，通过基于运营商已部署的网络架构中的策略控制网元或会话管理网元便可以完成多播会话的策略控制，如服务质量QoS的控制等。从而支持更灵活的多播广播的传输方案。

Description

一种多播会话的建立方法及网络设备
技术领域
本申请实施例涉及无线通信技术领域，尤其涉及一种多播会话的建立方法及网络设备。
背景技术
多播(也称广播)技术是一种允许一个接入点同时向多个站点发送数据的数据传输技术。多播传输作为一点对多点的数据传输技术，可以提高网络吞吐率，节省网络带宽。其中，多播技术包括多播业务管理和多播会话管理。多播业务管理用于管理多播传输的接收端和传输模式等。多播会话管理用于管理传输资源和多播承载等。
常规的多播传输是基于如图1所示的网络服务架构实现的。如图1所示，广播多播业务中心(Broadcast Multicast Service Centre，BM-SC)以及多媒体多播广播业务网关(Multimedia Broadcast and Multicast GateWay，MBMS GW)作为可以用于进行多播会话管理和多播业务管理的网元，可以实现一个发送端(如图1所示的应用服务器)到多个接收端(如图1所示的用户设备(User Equipment，UE)1、UE2、UE3和UE4)的多播传输。
但是，在通过如图1所示的常规的网络服务架构进行单播传输时，则无需BM-SC和MBMS GW的参与。如图1所示，应用服务器到UE5和UE6的单播传输是通过分组数据单元网关(Pack Data Unit GateWay，PDU GW)完成传输的。因此，对于单播传输，BM-SC和MBMS GW的部署是完全没有必要的。也就是说，运营商购买的BM-SC和MBMS GW并未被最大化的利用，反而增加了网络架构的复杂性。
发明内容
本申请实施例提供一种多播会话的建立方法和网络设备，可以基于运营商已部署的网络架构实现多播会话的建立，简化网络架构，节省开支。
为达到上述目的，本申请实施例采用如下技术方案：
第一方面，提供一种多播会话的建立方法，该方法包括：策略控制网元接收来自第二网元的第一消息，该第一消息包含多播会话的信息；策略控制网元发送第二消息，该第二消息包含所述多播会话的策略。
上述第一方面提供的技术方案，在建立多播会话时，通过基于运营商已部署的网络架构中的策略控制网元便可以完成多播会话的策略控制，从而支持更灵活的多播广播的传输方案。通过该方法，可以简化网络架构，节省开支。
结合第一方面，在第一种可能的实现方式中，上述第二网元为能力开放网元、会话管理网元或者应用服务器。在本方案中，策略控制网元可以支持接受能力开放网元的请求完成多播会话的策略决策，也可以支持接受会话管理网元或者应用服务器的请求完成多播会话的策略决策。通过基于运营商已部署的网络架构中的各个网元，配合完成多播会话的建立，可以简化网络架构，且容易实现。
结合第一方面第一种可能的实现方式，在第二种可能的实现方式中，上述第二网元为能力开放网元；上述策略控制网元发送第二消息，包括：策略控制网元向能力开放网元发送第二消息；或者，策略控制网元向会话管理网元发送上述第二消息。在本方案中，若策略控制网元接受能力开放网元的请求完成多播会话的策略决策，策略控制网元可以支持将确定的策略发送给能力开放网元，用于后续的多播会话建立。也可以支持将确定的策略发送给会话管理网元，用于后续的多播会话建立。通过基于运营商已部署的网络架构中的各个网元，配合完成多播会话的建立，可以简化网络架构，且容易实现。
结合第一方面第一种可能的实现方式，在第三种可能的实现方式中，第二网元为会话管理网元；策略控制网元发送第二消息，包括：策略控制网元向会话管理网元发送第二消息。在本方案中，若策略控制网元接受会话管理网元的请求完成多播会话的策略决策，策略控制网元可以将确定的策略发送给会话管理网元，用于后续的多播会话建立。通过基于运营商已部署的网络架构中的各个网元，配合完成多播会话的建立，可以简化网络架构，且容易实现。
结合第一方面第一种可能的实现方式，在第四种可能的实现方式中，第二网元为应用服务器；上述策略控制网元发送第二消息，包括：策略控制网元向会话管理网元发送第二消息。在本方案中，若策略控制网元接受应用服务器的请求完成多播会话的策略决策，策略控制网元可以将确定的策略发送给会话管理网元，用于后续的多播会话建立。通过基于运营商已部署的网络架构中的各个网元，配合完成多播会话的建立，可以简化网络架构，且容易实现。
结合第一方面第二种或第四种可能的实现方式，在第五种可能的实现方式中，上述策略控制网元向会话管理网元发送第二消息，上述方法还包括：策略控制网元根据多播会话的信息和会话管理网元的能力信息确定上述会话管理网元，会话管理网元的能力信息用于指示会话管理网元是否支持多播会话管理。策略控制网元可以支持在向会话管理网元请求建立多播会话之前，考虑每一个会话管理网元的能力从多个会话管理网元中确定可以支持多播会话管理的会话管理网元。
结合第一方面第二种或第四种可能的实现方式，在第六种可能的实现方式中，上述第一消息还包含会话管理网元的标识信息。其中，会话管理网元的标识信息用于后续请求建立多播会话。
结合第一方面，或第一方面第一种至第六种中任一种可能的实现方式，在第七种可能的实现方式中，上述第一消息用于请求为多播会话做策略决策。通过由能力开放网元或会话管理网元向策略管理网元发起策略决策的请求，可以基于运营商已部署的网络架构中的各个网元，配合完成策略的确定，简化网络架构，且容易实现。
结合第一方面，或第一方面第一种至第七种中任一种可能的实现方式，在第八种可能的实现方式中，上述多播会话的信息包含以下任意一项或多项：多播会话的质量要求信息、传输区域信息和业务标识信息。本方案中，策略的确定可以基于多播会话的质量要求信息、传输区域信息和业务标识信息中的至少一个来实现。
结合第一方面第八种可能的实现方式，在第九种可能的实现方式中，上述业务标识信息包含应用服务器的IP地址和端口号。其中，业务标识信息用于后续多播传输时识别来自应用服务器的多播数据。
结合第一方面，或第一方面第一种至第九种中任一种可能的实现方式，在第十种可能的实现方式中，上述策略包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数，上述多播数据的标识信息用于标识来自应用服务器的多播数据。通过确定的策略，可以用于规定后续多播数据传输的质量、接收、过滤等。
第二方面，提供一种多播会话的建立方法，该方法包括：会话管理网元接收来自能力开放网元的第一消息，该第一消息包含多播会话的信息；会话管理网元获取多播会话的策略。
上述第二方面提供的技术方案，在建立多播会话时，通过基于运营商已部署的网络架构中的策略控制网元便可以完成多播会话的策略控制，从而支持更灵活的多播广播的传输方案。通过该方法，可以简化网络架构，节省开支。
结合第二方面，在第一种可能的实现方式中，上述多播会话的信息包含以下任意一项或多项：多播会话的质量要求信息、传输区域信息和业务标识信息。本方案中，策略的确定可以基于多播会话的质量要求信息、传输区域信息和业务标识信息中的至少一个来实现，容易实现。
结合第二方面第一种可能的实现方式，在第二种可能的实现方式中，会话管理网元获取所述策略，包括：会话管理网元根据会话管理网元中配置的质量要求信息与策略的映射关系，获取策略。本方案中，策略的确定可以基于多播会话的质量要求信息来实现，容易实现。
结合第二方面第一种可能的实现方式，在第三种可能的实现方式中，上述会话管理网元获取策略，包括：会话管理网元根据会话管理网元中配置的业务标识信息与策略的映射关系，获取策略。本方案中，策略的确定可以基于多播会话的业务标识信息来实现，容易实现。
结合第二方面，或第二方面第一种至第三种中任一种可能的实现方式，在第四种可能的实现方式中，第一消息用于请求建立所述多播会话。
结合第二方面，或第二方面第一种至第四种中任一种可能的实现方式，在第五种可能的实现方式中，上述方法还包括：会话管理网元根据多播会话的信息和策略建立所述多播会话。通过基于运营商已部署的网络架构中的会话管理网元，完成多播会话的建立，简化网络架构，且容易实现。
结合第二方面第一种至第五种中任一种可能的实现方式，在第六种可能的实现方式中，上述业务标识信息包含所述应用服务器的IP地址和端口号。其中，业务标识信息用于后续多播传输时识别来自应用服务器的多播数据。
结合第二方面，或第二方面第一种至第六种中任一种可能的实现方式，在第七种可能的实现方式中，上述策略包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数，多播数据的标识信息用于标识来自应用服务器的多播数据。通过确定的策略，可以用于规定后续多播数据传输的质量、接收、过滤等。
第三方面，提供一种多播会话的建立方法，该方法包括：能力开放网元接收来自应用服务器的第三消息，该第三消息用于请求建立多播会话；该第三消息包含多播会话的信息；能力开放网元发送第一消息，该第一消息包括所述多播会话的信息，多播会话的信息用于生成多播会话的策略。
上述第三方面提供的技术方案，能力开放网元可以根据应用服务器的请求指示策略的决策。通过基于运营商已部署的网络架构中的网元，配合完成策略的决策，可以简化网络架构，且容易实现。
结合第三方面，在第一种可能的实现方式中，上述能力开放网元发送第一消息，包括：能力开放网元向策略控制网元发送第一消息，该第一消息用于请求为多播会话做策略决策。能力开放网元可以请求策略控制网元做策略决策。通过基于运营商已部署的网络架构中的网元，配合完成策略的决策，可以简化网络架构，且容易实现。
结合第三方面第一种可能的实现方式，在第二种可能的实现方式中，上述方法还包括：能力开放网元根据多播会话的信息和策略控制网元的能力信息确定策略控制网元，该策略控制网元的能力信息用于指示策略控制网元是否支持多播会话的策略管理。能力开放网元可以支持在向策略控制网元请求作策略决策前，考虑每一个策略控制网元的能力从多个策略控制网元中确定可以支持多播策略管理的策略控制网元。
结合第三方面第一种或第二种可能的实现方式，在第三种可能的实现方式中，上述方法还包括：能力开放网元接收来自策略控制网元的第二消息，该第二消息包含上述策略。能力开放网元可以根据确定的策略进一步请求建立多播会话，通过运营商已部署的网络架构中的各个网元，配合完成多播会话的建立，可以简化网络架构，且容易实现。
结合第三方面第三种可能的实现方式，在第四种可能的实现方式中，上述方法还包括：能力开放网元向会话管理网元发送第四消息，该第四消息包含多播会话的信息和策略。通过基于运营商已部署的网络架构中的网元，配合完成多播会话的建立，可以简化网络架构，且容易实现。
结合第三方面第四种可能的实现方式，在第五种可能的实现方式中，上述第四消息用于请求建立所述多播会话。
结合第三方面第一种或第二种可能的实现方式，在第六种可能的实现方式中，上述第一消息还包含会话管理网元的标识信息。其中，会话管理网元的标识信息用于后续请求建立多播会话。
结合第三方面第四种至第六种中任一种可能的实现方式，在第七种可能的实现方式中，上述方法还包括：能力开放网元根据多播会话的信息和会话管理网元的能力信息确定上述会话管理网元，会话管理网元的能力信息用于指示上述会话管理网元是否支持多播会话管理。能力开放网元可以支持在向会话管理网元请求建立多播会话之前，考虑每一个会话管理网元的能力从多个会话管理网元中确定可以支持多播会话管理的会话管理网元。
结合第三方面，在第八种可能的实现方式中，上述能力开放网元发送第一消息，包括：上述能力开放网元向会话管理网元发送第一消息，该第一消息用于请求建立多播会话。
结合第三方面第八种可能的实现方式，在第九种可能的实现方式中，上述第一消息还包含策略控制网元的标识信息。其中，策略控制网元的标识信息用于后续的策略决策。
结合第三方面第九种可能的实现方式，在第十种可能的实现方式中，在上述能力开放网元向会话管理网元发送第一消息之前，上述方法还包括：能力开放网元根据所多播会话的信息和会话管理网元的能力信息确定上述会话管理网元，会话管理网元的能力信息用于指示该会话管理网元是否支持多播会话管理；上述能力开放网元根据多播会话的信息和策略控制网元的能力信息确定上述策略控制网元，该策略控制网元的能力信息用于指示策略控制网元是否支持多播会话的策略管理。能力开放网元可以考虑每一个网元的能力从多个策略控制网元中确定可以支持多播策略管理的策略控制网元，以及从多个会话管理网元中确定可以支持多播会话管理的会话管理网元。
结合第三方面，或第三方面第一种至第十种中任一种可能的实现方式，在第十一种可能的实现方式中，上述多播会话的信息包含以下任意一项或多项：多播会话的质量要求信息、传输区域信息和业务标识信息。本方案中，策略的确定可以基于多播会话的质量要求信息、传输区域信息和业务标识信息中的至少一个来实现。
结合第三方面第十一种可能的实现方式，在第十二种可能的实现方式中，上述业务标识信息包含应用服务器的IP地址和端口号。其中，业务标识信息用于后续多播传输时识别来自应用服务器的多播数据。
结合第三方面，或第三方面第一种至第十二种中任一种可能的实现方式，在第十三种可能的实现方式中，上述策略包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数，多播数据的标识信息用于标识来自应用服务器的多播数据。通过确定的策略，可以用于规定后续多播数据传输的质量、接收、过滤等。
第四方面，提供一种多播会话的建立方法，该方法包括：会话管理网元从策略管理网元接收第二消息，该第二消息包含多播会话的策略；会话管理网元建立多播会话。
上述第四方面提供的技术方案，会话管理网元可以根据策略管理网元的请求建立多播会话。通过基于运营商已部署的网络架构中的网元，配合完成多播会话的建立，可以简化网络架构，且容易实现。
结合第四方面，在第一种可能的实现方式中，上述多播会话的策略由策略管理网元决策得到。通过基于运营商已部署的网络架构中的策略管理网元，完成策略的决策，可以简化网络架构，且容易实现。
结合第四方面，或第四方面第一种可能的实现方式，在第二种可能的实现方式中，上述第二消息用于请求建立多播会话。
结合第四方面，或第四方面第一种或第二种可能的实现方式，在第三种可能的实现方式中，上述第二消息还包含传输区域信息和业务标识信息。
结合第四方面第三种可能的实现方式，在第四种可能的实现方式中，业务标识信息包含应用服务器的IP地址和端口号。其中，业务标识信息用于后续多播传输时识别来自应用服务器的多播数据。
结合第四方面，或第四方面第一种至第四种中任一种可能的实现方式，在第五种可能的实现方式中，策略包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数，多播数据的标识信息用于标识来自应用服务器的多播数据。通过确定的策略，可以用于规定后续多播数据传输的质量、接收、过滤等。
第五方面，提供一种多播会话的建立方法，该方法包括：会话管理网元从能力开放网元接收第四消息，该第四消息包含多播会话的策略；会话管理网元建立多播会话。
上述第五方面提供的技术方案，会话管理网元可以根据能力开放网元的请求建立多播会话。通过基于运营商已部署的网络架构中的网元，配合完成多播会话的建立，可以简化网络架构，且容易实现。
结合第五方面，在第一种可能的实现方式中，第四消息用于请求建立多播会话。
结合第五方面，或第五方面第一种中任一种可能的实现方式，在第二种可能的实现方式中，上述第四消息还包含传输区域信息和业务标识信息。
结合第五方面第二种可能的实现方式，在第三种可能的实现方式中，业务标识信息包含所述应用服务器的IP地址和端口号。其中，业务标识信息用于后续多播传输时识别来自应用服务器的多播数据。
结合第五方面，或第五方面第一种至第三种中任一种可能的实现方式，在第四种可能的实现方式中，策略包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数，多播数据的标识信息用于标识来自应用服务器的多播数据。通过确定的策略，可以用于规定后续多播数据传输的质量、接收、过滤等。
第六方面，提供一种策略控制网元，该策略控制网元包括接收单元，用于接收来自第二网元的第一消息，该第一消息包含多播会话的信息；发送单元，用于发送第二消息，该第二消息包含所述多播会话的策略。
上述第六方面提供的技术方案，在建立多播会话时，通过基于运营商已部署的网络架构中的策略控制网元便可以完成多播会话的策略控制，从而支持更灵活的多播广播的传输方案。通过该方法，可以简化网络架构，节省开支。
结合第六方面，在第一种可能的实现方式中，上述第二网元为能力开放网元、会话管理网元或者应用服务器。在本方案中，策略控制网元可以支持接受能力开放网元的请求完成多播会话的策略决策，也可以支持接受会话管理网元或者应用服务器的请求完成多播会话的策略决策。通过基于运营商已部署的网络架构中的各个网元，配合完成多播会话的建立，可以简化网络架构，且容易实现。
结合第六方面第一种可能的实现方式，在第二种可能的实现方式中，上述第二网元为能力开放网元；上述发送单元发送第二消息，包括：发送单元向能力开放网元发送第二消息；或者，发送单元向会话管理网元发送上述第二消息。在本方案中，若策略控制网元接受能力开放网元的请求完成多播会话的策略决策，策略控制网元可以支持将确定的策略发送给能力开放网元，用于后续的多播会话建立。也可以支持将确定的策略发送给会话管理网元，用于后续的多播会话建立。通过基于运营商已部署的网络架构中的各个网元，配合完成多播会话的建立，可以简化网络架构，且容易实现。
结合第六方面第一种可能的实现方式，在第三种可能的实现方式中，第二网元为会话管理网元；发送单元发送第二消息，包括：发送单元向会话管理网元发送第二消息。在本方案中，若策略控制网元接受会话管理网元的请求完成多播会话的策略决策，策略控制网元可以将确定的策略发送给会话管理网元，用于后续的多播会话建立。通过基于运营商已部署的网络架构中的各个网元，配合完成多播会话的建立，可以简化网络架构，且容易实现。
结合第六方面第一种可能的实现方式，在第四种可能的实现方式中，第二网元为应用服务器；上述发送单元发送第二消息，包括：发送单元向会话管理网元发送第二消息。在本方案中，若策略控制网元接受应用服务器的请求完成多播会话的策略决策，策略控制网元可以将确定的策略发送给会话管理网元，用于后续的多播会话建立。通过基于运营商已部署的网络架构中的各个网元，配合完成多播会话的建立，可以简化网络架构，且容易实现。
结合第六方面第二种或第四种可能的实现方式，在第五种可能的实现方式中，上述发送单元向会话管理网元发送第二消息，上述策略控制网元还包括处理单元，用于根据多播会话的信息和会话管理网元的能力信息确定上述会话管理网元，会话管理网元的能力信息用于指示会话管理网元是否支持多播会话管理。策略控制网元可以支持在向会话管理网元请求建立多播会话之前，考虑每一个会话管理网元的能力从多个会话管理网元中确定可以支持多播会话管理的会话管理网元。
结合第六方面第二种或第四种可能的实现方式，在第六种可能的实现方式中，上述第一消息还包含会话管理网元的标识信息。其中，会话管理网元的标识信息用于后续请求建立多播会话。
结合第六方面，或第六方面第一种至第六种中任一种可能的实现方式，在第七种可能的实现方式中，上述第一消息用于请求为多播会话做策略决策。通过由能力开放网元或会话管理网元向策略管理网元发起策略决策的请求，可以基于运营商已部署的网络架构中的各个网元，配合完成策略的确定，简化网络架构，且容易实现。
结合第六方面，或第六方面第一种至第七种中任一种可能的实现方式，在第八种可能的实现方式中，上述多播会话的信息包含以下任意一项或多项：多播会话的质量要求信息、传输区域信息和业务标识信息。本方案中，策略的确定可以基于多播会话的质量要求信息、传输区域信息和业务标识信息中的至少一个来实现。
结合第六方面第八种可能的实现方式，在第九种可能的实现方式中，上述业务标识信息包含应用服务器的IP地址和端口号。其中，业务标识信息用于后续多播传输时识别来自应用服务器的多播数据。
结合第六方面，或第六方面第一种至第九种中任一种可能的实现方式，在第十种可能的实现方式中，上述策略包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数，上述多播数据的标识信息用于标识来自应用服务器的多播数据。通过确定的策略，可以用于规定后续多播数据传输的质量、接收、过滤等。
第七方面，提供一种会话管理网元，该会话管理网元包括：接收单元，用于接收来自能力开放网元的第一消息，该第一消息包含多播会话的信息；处理单元，用于获取多播会话的策略。
上述第七方面提供的技术方案，在建立多播会话时，通过基于运营商已部署的网络架构中的策略控制网元便可以完成多播会话的策略控制，从而支持更灵活的多播广播的传输方案。通过该方法，可以简化网络架构，节省开支。
结合第七方面，在第一种可能的实现方式中，上述多播会话的信息包含以下任意一项或多项：多播会话的质量要求信息、传输区域信息和业务标识信息。本方案中，策略的确定可以基于多播会话的质量要求信息、传输区域信息和业务标识信息中的至少一个来实现，容易实现。
结合第七方面第一种可能的实现方式，在第二种可能的实现方式中，处理单元获取所述策略，包括：处理单元根据会话管理网元中配置的质量要求信息与策略的映射关系，获取策略。本方案中，策略的确定可以基于多播会话的质量要求信息来实现，容易实现。
结合第七方面第一种可能的实现方式，在第三种可能的实现方式中，上述处理单元获取策略，包括：处理单元根据会话管理网元中配置的业务标识信息与策略的映射关系，获取策略。本方案中，策略的确定可以基于多播会话的业务标识信息来实现，容易实现。
结合第七方面，或第七方面第一种至第三种中任一种可能的实现方式，在第四种可能的实现方式中，第一消息用于请求建立所述多播会话。
结合第七方面，或第七方面第一种至第四种中任一种可能的实现方式，在第五种可能的实现方式中，上述处理单元还用于根据多播会话的信息和策略建立所述多播会话。通过基于运营商已部署的网络架构中的会话管理网元，完成多播会话的建立，简化网络架构，且容易实现。
结合第七方面第一种至第五种中任一种可能的实现方式，在第六种可能的实现方式中，上述业务标识信息包含所述应用服务器的IP地址和端口号。其中，业务标识信息用于后续多播传输时识别来自应用服务器的多播数据。
结合第七方面，或第七方面第一种至第六种中任一种可能的实现方式，在第七种可能的实现方式中，上述策略包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数，多播数据的标识信息用于标识来自应用服务器的多播数据。通过确定的策略，可以用于规定后续多播数据传输的质量、接收、过滤等。
第八方面，提供一种能力开放网元，该能力开放网元包括：接收单元，用于接收来自应用服务器的第三消息，该第三消息用于请求建立多播会话；该第三消息包含多播会话的信息；发送单元，用于发送第一消息，该第一消息包括所述多播会话的信息，多播会话的信息用于生成多播会话的策略。
上述第八方面提供的技术方案，能力开放网元可以根据应用服务器的请求指示策略的决策。通过基于运营商已部署的网络架构中的网元，配合完成策略的决策，可以简化网络架构，且容易实现。
结合第八方面，在第一种可能的实现方式中，上述发送单元发送第一消息，包括：发送单元向策略控制网元发送第一消息，该第一消息用于请求为多播会话做策略决策。能力开放网元可以请求策略控制网元做策略决策。通过基于运营商已部署的网络架构中的网元，配合完成策略的决策，可以简化网络架构，且容易实现。
结合第八方面第一种可能的实现方式，在第二种可能的实现方式中，上述能力开放网元还包括处理单元，用于根据多播会话的信息和策略控制网元的能力信息确定策略控制网元，该策略控制网元的能力信息用于指示策略控制网元是否支持多播会话的策略管理。能力开放网元可以支持在向策略控制网元请求作策略决策前，考虑每一个策略控制网元的能力从多个策略控制网元中确定可以支持多播策略管理的策略控制网元。
结合第八方面第一种或第二种可能的实现方式，在第三种可能的实现方式中，上述接收单元还用于，接收来自策略控制网元的第二消息，该第二消息包含上述策略。能力开放网元可以根据确定的策略进一步请求建立多播会话，通过运营商已部署的网络架构中的各个网元，配合完成多播会话的建立，可以简化网络架构，且容易实现。
结合第八方面第三种可能的实现方式，在第四种可能的实现方式中，上述发送单元还用于，向会话管理网元发送第四消息，该第四消息包含多播会话的信息和策略。通过基于运营商已部署的网络架构中的网元，配合完成多播会话的建立，可以简化网络架构，且容易实现。
结合第八方面第四种可能的实现方式，在第五种可能的实现方式中，上述第四消息用于请求建立所述多播会话。
结合第八方面第一种或第二种可能的实现方式，在第六种可能的实现方式中，上述第一消息还包含会话管理网元的标识信息。其中，会话管理网元的标识信息用于后续请求建立多播会话。
结合第八方面第一种可能的实现方式，在第七种可能的实现方式中，上述处理单元还用于，根据多播会话的信息和会话管理网元的能力信息确定上述会话管理网元，会话管理网元的能力信息用于指示上述会话管理网元是否支持多播会话管理。能力开放网元可以支持在向会话管理网元请求建立多播会话之前，考虑每一个会话管理网元的能力从多个会话管理网元中确定可以支持多播会话管理的会话管理网元。
结合第八方面，在第八种可能的实现方式中，上述发送单元发送第一消息，包括：上述发送单元向会话管理网元发送第一消息，该第一消息用于请求建立多播会话。
结合第八方面第八种可能的实现方式，在第九种可能的实现方式中，上述第一消息还包含策略控制网元的标识信息。其中，策略控制网元的标识信息用于后续的策略决策。
结合第八方面第九种可能的实现方式，在第十种可能的实现方式中，在上述发送单元向会话管理网元发送第一消息之前，上述处理单元还用于，根据所多播会话的信息和会话管理网元的能力信息确定上述会话管理网元，会话管理网元的能力信息用于指示该会话管理网元是否支持多播会话管理；以及，根据多播会话的信息和策略控制网元的能力信息确定上述策略控制网元，该策略控制网元的能力信息用于指示策略控制网元是否支持多播会话的策略管理。能力开放网元可以考虑每一个网元的能力从多个策略控制网元中确定可以支持多播策略管理的策略控制网元，以及从多个会话管理网元中确定可以支持多播会话管理的会话管理网元。
结合第八方面，或第八方面第一种至第十种中任一种可能的实现方式，在第十一种可能的实现方式中，上述多播会话的信息包含以下任意一项或多项：多播会话的质量要求信息、传输区域信息和业务标识信息。本方案中，策略的确定可以基于多播会话的质量要求信息、传输区域信息和业务标识信息中的至少一个来实现。
结合第八方面第十一种可能的实现方式，在第十二种可能的实现方式中，上述业务标识信息包含应用服务器的IP地址和端口号。其中，业务标识信息用于后续多播传输时识别来自应用服务器的多播数据。
结合第八方面，或第八方面第一种至第十二种中任一种可能的实现方式，在第十三种可能的实现方式中，上述策略包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数，多播数据的标识信息用于标识来自应用服务器的多播数据。通过确定的策略，可以用于规定后续多播数据传输的质量、接收、过滤等。
第九方面，提供一种策略控制网元，该策略控制网元包括：存储器，用于存储计算机程序代码，该计算机程序代码包括指令；射频电路，用于进行无线信号的发送和接收；处理器，用于执行上述指令，使得策略控制网元执行第一方面任一种可能的实现方式中的多播会话的建立方法。
第十方面，提供一种会话管理网元，该会话管理网元包括：存储器，用于存储计算机程序代码，该计算机程序代码包括指令；射频电路，用于进行无线信号的发送和接收；处理器，用于执行上述指令，使得会话管理网元执行第二方面、第四方面或第五方面任一种可能的实现方式中的多播会话的建立方法。
第十一方面，提供一种能力开放网元，该能力开放网元包括：存储器，用于存储计算机程序代码，该计算机程序代码包括指令；射频电路，用于进行无线信号的发送和接收；处理器，用于执行上述指令，使得能力开放网元执行第三方面任一种可能的实现方式中的多播会话的建立方法。
第十二方面，提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机执行指令，该计算机执行指令被处理器执行时实现如第一方面、第二方面、第三方面、第四方面或第五方面任一种可能的实现方式中的多播会话的建立方法。
第十三方面，提供一种芯片系统，该芯片系统包括处理器、存储器，存储器中存储有指令；所述指令被所述处理器执行时，实现如第一方面、第二方面、第三方面、第四方面或第五方面任一种可能的实现方式中的多播会话的建立方法。该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。
第十四方面，提供一种计算机程序产品，提供一种计算机程序产品，当其在计算机上运行时，使得实现第一方面、第二方面、第三方面、第四方面或第五方面任一种可能的实现方式中的多播会话的建立方法。例如，该计算机可以是至少一个存储节点。
第十五方面，提供一种通信系统，该通信系统包括第六方面至第八方面中所述的任意多个网元。
第十六方面，提供一种通信系统，该通信系统包括第九方面至第十一方面中所述的任意多个网元。
附图说明
图1为本申请实施例提供的一种常规的网络服务架构示例示意图；
图2为本申请实施例提供的一种网络服务架构的示例示意图；
图3为本申请实施例提供的一种UE的结构示意图；
图4为本申请实施例提供的一种功能扩展后的用于多播/广播传输的网络架构示例示意图；
图5为本申请实施例提供的一种多播会话的建立方法流程图一；
图6为本申请实施例提供的一种多播会话的建立方法流程图二；
图7为本申请实施例提供的一种多播会话的建立方法流程图三；
图8为本申请实施例提供的一种多播会话的建立方法流程图四；
图9为本申请实施例提供的一种多播会话的建立方法流程图五；
图10为本申请实施例提供的一种多播会话的建立方法流程图六；
图11为本申请实施例提供的一种多播会话的建立方法交互图一；
图12为本申请实施例提供的一种多播会话的建立方法交互图二；
图13为本申请实施例提供的一种多播会话的建立方法交互图三；
图14为本申请实施例提供的一种多播会话的建立方法交互图四；
图15为本申请实施例提供的一种多播会话的建立方法交互图五；
图16为本申请实施例提供的一种多播会话的建立方法交互图六；
图17为本申请实施例提供的一种策略管理网元的结构示意图；
图18为本申请实施例提供的一种会话管理网元的结构示意图；
图19为本申请实施例提供的一种能力开放网元的结构示意图。
具体实施方式
本申请实施例提供一种多播会话的建立方法，该方法用于建立应用功能(Application Function，AF)(如应用服务器)与多个用户设备(User Equipment，UE)之间的多播会话。其中，建立的多播会话用于AF同时向特定区域发送多播数据(例如，应用系统消息)。值得说明的是，在文后的描述中，术语“多播/广播”，“组播”，“群组通信”，“广播”等相关术语的可以互换。
本申请实施例提供的多播会话的建立方法可以适用于运营商已经部署的网络服务架构。例如，基于运营商已经部署的第五代(5th-Generation，5G)移动通信系统新无线(New Radio，NR)网络的网络服务架构，或者基于第四代(4th-Generation，4G)移动通信系统长期演进(Long Term Evolution，LTE)网络的网络服务架构完成多播数据的传输。还可以应用于其他网络服务架构。例如，第五代之后发展的其他移动通信系统，本申请实施例对此不作限定。采用本申请实施例提供的多播会话的建立方法，既可以实现对于多播会话的策略控制，从而支持更灵活的多播广播的传输方案。还可以简化网络架构，节省网络开销，以及为运营商节省花费。
需要说明的是，本申请实施例提供的多播会话的建立方法同样适用于广播会话、多播/广播会话、多播广播业务会话(Multicast Broadcasting Service Session，MBSSession)或者组播会话。本申请实施例以多播会话的建立过程作为示例具体介绍。
请参考图2，图2以5G移动通信系统NR网络的网络服务架构为例示出了一种网络服务架构，以及网络服务架构中各个网络功能和实体之间的交互关系以及对应的接口。如图2所示，5G系统的3GPP基于服务的网络架构(service-based architecture，SBA)包含的网络功能和实体主要包括：UE、接入网(Access Network，AN)或无线接入网(Radio AccessNetwork，RAN)、用户面功能(User Plane Function，UPF)、数据网络(Data Network，DN)、接入管理功能(Access Management Function，AMF)、会话管理功能(Session ManagementFunction，SMF)、认证服务功能(Authentication Server Function，AUSF)、策略控制功能(Policy Control Function，PCF)、应用功能AF、网络切片选择功能(Network SliceSelection Function，NSSF)、统一数据管理(Unified Data Management，UDM)、网络开放功能(Network Exposure Function，NEF)(也称能力开放网元)和网络存储功能(NFRepository Function，NRF)。
其中，UE、(R)AN、UPF和DN一般被称为用户面网络功能和实体(或者用户面网元)，其他的部分则一般被称为控制面网络功能和实体(或者控制面网元)。控制面网元由3GPP定义了在一个网络里的处理功能，控制面网元具有3GPP定义的功能行为和3GPP定义的接口，网络功能能够作为一个运行在专有硬件上的网络元素，或者运行在专有硬件上的软件实例，或者在一个合适平台上进行实例化的虚拟功能，比如在一个云基础设备被实施。
下面对各个网元的主要功能做具体介绍。
(R)AN：(R)AN可以是AN，也可以是RAN。具体的，(R)AN可以是各种形式的基站，例如：宏基站，微基站，分散单元-控制单元(distribute unit-control unit，DU-CU)等，其中，DU-CU是一种部署在无线接入网中能够和UE进行无线通信的设备。另外，上述基站还可以是云无线接入网络(cloud radio access network，CRAN)场景下的无线控制器，或者中继站、接入点、车载设备、可穿戴设备或者未来演进的公共陆地移动网络(public landmobile network，PLMN)网络中的网络设备等。(R)AN主要负责空口侧的无线资源管理、服务质量管理、数据压缩和加密等。需要说明的是，在采用不同的无线接入技术的系统中，具备基站功能的设备的名称可能会有所不同。例如，基站可以是长期演进技术(Long TermEvolution，LTE)中的演进型基站(evolutional NodeB，eNB或e-NodeB)，也可以是5G系统中的gNB等。
UPF：主要负责分组路由和转发，以及用户面数据的服务质量(Quality ofService，QoS)处理等。UPF可以接收来自AF的下行数据，然后通过(R)AN将该下行数据传输给UE。
DN：DN是用于传输数据的网络。例如：DN可以是运营商服务网络、互联网接入或第三方服务网络等。DN可以通过PDU会话与UE进行信息交互。其中，PDU会话可以分为多种类型，如互联网协议版本4(Internet Protocol Version 4,IPv4)、IPv6等。
AMF：主要负责控制面消息的处理，例如：接入控制、移动性管理、合法监听、接入鉴权/授权等。
SMF：主要用于会话管理，UE的网络互连协议(Internet Protocol，IP)地址分配和管理，选择可管理用户平面功能，策略控制和收费功能接口的终结点，下行数据通知等。
AUSF：主要负责网络安全，用于产生密钥，实现对于UE的双向鉴权等。
PCF：主要用于向UE，AMF或SMF分别提供UE策略规则，AM策略规则以及SM策略规则相关的参数，管理用户订阅信息等。在V2X的场景中，PCF向UE，NG-RAN提供V2X相关的鉴权和策略参数等信息。
UDM：主要用于鉴权信用处理，用户标识处理，访问授权，注册/移动性管理，订阅管理和短消息管理等。
NEF：用于运营商网络将网络中的数据开放给第三方应用服务器，或接收第三方应用服务器为网络提供的数据。
NRF：主要用于提供内部/外部寻址功能，接收其他网元对某类网元的查询请求并返回相关网元的信息等。
AF：用于向用户提供应用服务(也称业务)，其作用与业务能力服务器(servicecapability server，SCS)/应用服务器(application server，AS)相似。AF可以提供业务或应用服务的描述信息，也可以提供待传输的数据。本申请中，AF网元可以是运营商部署的应用服务器，也可以是第三方部署的应用服务器。
其中，图2所示的UE和(R)AN之间可以采用空口技术相互通信。如图2所示，N1为UE和AMF之间的参考点。N2为(R)AN和AMF之间的参考点，N2可以用于非接入层(Non-accessstratum，NAS)消息的发送等。N3为(R)AN和UPF之间的参考点，N3用于传输传输用户面数据等。N4为SMF和UPF之间的参考点。N6为UPF为DN之间的参考点。图2所示的Namf为AMF提供的基于服务的接口，Nsmf为SMF提供的基于服务的接口，Nausf为AUSF提供的基于服务的接口。Nnssf为NSSF提供的基于服务的接口。Nnef为NEF提供的基于服务的接口。Nnrf为NRF提供的基于服务的接口。Npcf为PCF提供的基于服务的接口。Nudm为UDM提供的基于服务的接口。Naf为AF提供的基于服务的接口。
需要说明的是，本申请实施例仅对图2所示的网络服务架构中的各个网元的功能作简单介绍。各个网元的功能可以根据实际的使用场景作出调整，本申请实施例对此不作具体限定。关于图2所示的网络服务架构中的各个网元的功能和工作原理，可以参考常规技术中的相关描述，这里不再赘述。
在本申请实施例中，用户设备可以是上网本、平板电脑、智能手表等。或者，用户设备还可以是其他具有无线电通信功能的桌面型设备、膝上型设备、手持型设备、可穿戴设备、智能家居设备和车载型设备等，例如超级移动个人计算机(Ultra-mobile PersonalComputer，UMPC)、智能相机、上网本、个人数字助理(Personal Digital Assistant，PDA)、便携式多媒体播放器(Portable Multimedia Player，PMP)、AR(增强现实)/VR(虚拟现实)设备、飞行器、机器人等。本申请实施例对用户设备的具体类型和结构等不作限定。
请参考图3，图3示出了本申请实施例提供的一种用户设备的硬件结果示意图。如图3所示，该用户设备300可以包括处理器301，通信线路302，存储器303以及至少一个通信接口(图3中仅是示例性的以包括通信接口304为例进行说明)。
处理器301可以是一个通用中央处理器(central processing unit，CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。
通信线路302可包括一通路，在上述组件之间传送信息。
通信接口304，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线接入网RAN，无线局域网(wireless local area networks，WLAN)等。
存储器303可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过通信线路302与处理器相连接。存储器也可以和处理器集成在一起。
其中，存储器303用于存储执行本申请方案的计算机执行指令，其中，存储器303可以存储指令，并由处理器301来控制执行。处理器301用于执行存储器303中存储的计算机执行指令，从而实现多播数据的接收。图3中示出的存储器303仅为示意图，该存储器还可以包括其他功能化的指令，对此，本发明对此不进行限定。
可选的，本申请实施例中的计算机执行指令也可以称之为应用程序代码，本申请实施例对此不作具体限定。
在具体实现中，作为一种实施例，处理器301可以包括一个或多个CPU，例如图3中的CPU0和CPU1。
本申请实施例提供的多播会话的建立方法的基本原理是：通过对运营商已经部署的网络服务架构(如图2所示的网络服务架构)中的部分网元进行功能扩展，使得其具备进行多播会话建立的功能。
示例性的，本申请实施例对图2所示的网络服务架构中的NEF网元、SMF网元、PCF网元和UPF网元进行了功能扩展。请参考图4，图4示出了本申请实施例提供的一种功能扩展后的用于多播传输的网络架构示例示意图。为方便与如图2所示的网元区分，如图4所示，经过功能扩展的NEF网元、SMF网元、PCF网元和UPF网元分别用MB-NEF 410、MB-PCF 420、MB-SMF430和MB-UPF 440表示。如图4所示，经过功能扩展后的用于多播传输的网络架构还包括RAN450，AF(如应用服务器460)，AMF和UE。
关于MB-NEF、MB-SMF、MB-PCF、MB-UPF、AMF、RAN、AF和UE的常规功能，可以参考上文中对图2所示的网络服务架构的介绍。关于MB-NEF、MB-SMF、MB-PCF和MB-UPF网元的具体功能扩展，存在不同的方案。具体的功能扩展介绍，将在下文中不同的实施例中作具体说明。
可以理解，基于功能扩展后的网络服务架构，可以借助扩展后的MB-NEF、MB-SMF、MB-PCF或MB-UPF网元中的至少一个所提供的功能，采用本申请实施例提供的多播会话的建立方法完成多播传输。对于单播传输，可以借助各个网元的常规功能，采用常规的技术进行单播传输。其中，关于常规的单播传输技术，本申请实施例不做赘述。
本申请实施例提供的多播会话的建立方法可以用于建立如图4所示的AF(例如应用服务器)到特定区域的多播会话。建立的多播会话用于AF同时向特定区域发送多播数据。其中，UE可以具有与图3所示相同的结构或者相似的结构。
以下以AF为应用服务器为例，对本申请实施例提供的多播会话的建立方法进行介绍。对于其他类型AF，也可以参考本申请实施例提供的多播会话的建立方法。
可以理解，建立多播会话，一个重要的部分是多播会话的策略生成。在本申请实施例中，策略可以由策略控制网元获取，或者由会话管理网元获取。
(一)、由策略控制网元做策略决策(例如，PCF makes PCC decision)。
其中，策略控制网元具备多播会话的策略管理功能。例如，策略控制网元具备创建策略的功能。其中，多播会话的策略管理还包括但不限于策略和计费控制(Policy andCharging Control，PCC)，管理多播会话的QoS参数，或者管理服务质量流(QoS Flow)的生成规则中的一项或多项。
请参考图5，图5示出了本申请实施例提供的一种多播会话的建立方法流程图一。如图5所示，本申请实施例提供的多播会话的建立方法可以包括：
S501、策略控制网元接收来自第二网元的第一消息。第一消息包含多播会话的信息。
其中，策略控制网元可以是如图4所示的MB-PCF 420，也可以是用于多播/广播/组播的管理网元的策略控制模块，本申请实施例对策略控制网元的具体形态和结构不作限定。
其中，第一消息用于请求为多播会话创建策略。(或者可以说为多播会话做策略决策，需要说明的是，本申请中的创建策略都可以替换为做策略决策，对此不作限定)。策略用于规定但不限于建立QoS flow的规则授权的QoS规则、识别多播数据的规则或过滤多播数据的规则中的一项或多项。建立QoS flow的规则包含了多播数据被授权的QoS参数。被授权的QoS参数包含但不限于抢占优先级信息，比特速率信息等。被授权的QoS参数用于规定多播数据的传输质量。识别多播数据的规则用于识别下行多播数据。过滤多播数据的规则用于将下行多播数据通过网络的对应资源进行传输。
在本申请实施例中，多播会话的信息包括以下任意一项或多项：多播会话的质量要求信息、传输区域信息和业务标识信息。其中，多播会话的质量要求信息用于表征应用服务器460对多播会话的质量要求。传输区域信息用于表征多播传输的目标区域。示例性的，传输区域信息可以包括至少一个小区的ID等。业务标识信息用于在多播传输过程中识别来自应用服务器460的多播数据。
在本申请实施例中，多播会话的质量要求信息可以包含但不限于应用服务器460对多播会话的时延要求，传输速率要求或带宽要求中的一项或多项。可选的，应用服务器460对多播会话的时延、传输速率和带宽等要求还可以以索引的形式包含在多播会话的质量要求信息中。示例性的，多播会话的质量要求信息可以包含质量要求索引信息。例如，质量要求索引信息可以是5QI信息。其中，5QI信息是一种标量，用于对5G QoS流的特定QoS转发行为(例如包丢失率、包延迟预算)的参考。例如标准化5QI的值为1时，其对应的包丢失率最大为10-2，包延迟预算为100ms。
传输区域信息是多播数据的目标传输区域。示例性的，传输区域信息可以包括小区标识信息(如小区的ID)，或者追踪区域标识信息，或者为广播定义的区域标识信息。例如，传输区域信息可以包括多播广播业务区域(Multicast Broadcast Service Area)。
在本申请实施例中，第二网元可以是能力开放网元。策略控制网元可以根据能力开放网元的请求/指示为多播会话创建策略。其中，能力开放网元可以是如图4所示的MB-NEF 410，也可以是用于多播/广播/组播的管理网元的能力开放模块，本申请实施例对能力开放网元的具体形态和结构不作限定。
可选的，第二网元可以是会话管理网元。策略控制网元可以根据会话管理网元的请求/指示为多播会话创建策略。其中，会话管理网元可以是如图4所示的MB-SMF 430，也可以是用于多播/广播/组播的管理网元的会话管理模块，本申请实施例对会话管理网元的具体形态和结构不作限定。
可选的，第二网元可以是应用服务器。策略控制网元可以根据应用服务器的请求/指示为多播会话创建策略。
在本申请实施例中，业务标识信息可以是应用服务器460通过在第一请求消息中携带业务数据流(Service Data Flow，SDF)模板信息发送给能力开放网元(如MB-NEF 410)的。示例性的，SDF模板信息可以包括应用服务器460的IP地址和端口号。
S502、策略控制网元发送第二消息。第二消息包括多播会话的策略。
其中，策略可以包括以下任意一项或多项：多播数据的标识信息、多播会话质量参数(即多播数据被授权的QoS参数)。多播数据的标识信息用于标识来自应用服务器的多播数据。多播会话质量参数用于规定多播数据的传输质量，例如传输时延、传输速率和带宽等。多播数据过滤参数用于规定多播数据的接收参数。
在一个示例中，策略为PCC规则。
在第二网元是能力开放网元(如MB-NEF 410)时，如图6所示，图5中的S502可以替换为S601或者S602：
S601、策略控制网元向能力开放网元发送第二消息。第二消息包括多播会话的策略。
S602、策略控制网元向会话管理网元发送第二消息。第二消息包括多播会话的策略。
进一步的，在第二网元是能力开放网元(如MB-NEF 410)时，可选的，如图7所示，在策略控制网元向会话管理网元发送第二消息(即S602)之前，本申请实施例提供的多播会话的建立方法还可以包括：
S701、策略控制网元根据多播会话的信息和会话管理网元的能力信息确定会话管理网元。
其中，会话管理网元的能力信息用于指示会话管理网元是否支持多播会话管理。
在本申请实施例中，能力开放网元(如MB-NEF 410)可以根据传输区域信息，以及该传输区域信息所指示的传输区域内的多个会话管理网元的能力信息，确定用于多播会话管理的网元(如MB-SMF 430)。
可以理解，核心网中通常部署有多个会话管理网元。其中，该多个会话管理网元的能力是不同的。例如，该多个会话管理网元中有的网元支持多播会话管理，有的不支持多播会话管理。能力开放网元(如MB-NEF 410)可以结合传输区域信息以及会话管理网元的能力信息，确定用于进行多播会话管理(如多播会话建立)的会话管理网元(如MB-SMF 430)。其中，会话管理网元的能力信息用于指示会话管理网元是否支持多播会话管理。例如，SMF是否是功能扩展后的MB-SMF。
在第二网元是会话管理网元(如MB-SMF 430)或者应用服务器时，如图8所示，图5中的S502可以替换为S801：
S801、策略控制网元向会话管理网元发送第二消息。第二消息包括多播会话的策略。
进一步的，在S502之前，本申请实施例提供的多播会话的建立方法还可以包括：策略控制网元根据多播会话的信息为多播会话创建策略。
其中，策略可以包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数或多播数据过滤参数。
在本申请实施例中，策略控制网元可以根据多播会话的质量要求信息和业务标识信息等信息为多播会话创建策略。
可选的，策略控制网元可以仅根据业务标识信息为多播会话创建策略。
(二)、由会话管理网元获取多播会话的策略。
其中，会话管理网元具备确定策略的功能。
请参考图9，如图9所示，本申请实施例提供的多播会话的建立方法可以包括：
S901、会话管理网元接收来自能力开放网元的第一消息。第一消息包含多播会话的信息。
其中，会话管理网元可以是如图4所示的MB-SMF 430，能力开放网元可以是如图4所示的MB-NEF 410。第一消息用于请求获取多播会话创建策略。策略用于规定但不限于建立QoS flow的规则、授权的QoS规则、识别多播数据的规则或过滤多播数据的规则中的一项或多项。关于策略的相关介绍，可以参考S502中的说明，这里不做赘述。
在本申请实施例中，多播会话的信息包括以下任意一项或多项：多播会话的质量要求信息、传输区域信息和业务标识信息。示例性的，业务标识信息可以包含应用服务器的IP地址和端口号。
S902、会话管理网元获取多播会话的策略。
其中，策略可以包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数或多播数据过滤参数。多播数据的标识信息用于标识来自应用服务器460的多播数据。多播会话质量参数用于规定多播数据的传输质量，例如传输时延、传输速率和带宽等。多播数据过滤参数用于规定多播数据的接收参数。
在本申请实施例中，会话管理网元(如MB-SMF 430)中可以预先配置有质量要求信息与策略的映射关系。会话管理网元可以根据会话管理网元中配置的质量要求信息与策略的映射关系，获取多播会话的策略。
可选的，会话管理网元(如MB-SMF 430)中还可以预先配置有业务标识信息与策略的映射关系。会话管理网元可以根据会话管理网元中配置的业务标识信息与策略的映射关系，获取多播会话的策略。
进一步的，第一消息还用于请求建立多播会话。
可选的，如图10所示，在S902之后，本申请实施例提供的多播会话的建立方法还可以包括：
S1001、会话管理网元根据多播会话的信息和策略建立多播会话。
其中，建立的多播会话用于到特定区域的多播数据传输。建立多播会话是指建立用于进行多播传输的核心网资源。
为便于理解，本申请以能力开放网元为MB-NEF 410，策略管理网元为MB-PCF 420，会话管理网元为MB-SMF 430为例，通过以下实施例1、实施例2、实施例3和实施例4具体介绍几种可能的多播会话的建立方法的交互过程。
实施例1：
在实施例1中，MB-NEF 410具备选择MB-PCF和MB-SMF的功能。MB-PCF 420具备多播会话的策略管理功能。MB-SMF 430具备多播会话管理功能。
其中，多播会话的策略管理包括但不限于PCC，管理多播会话的QoS参数，或者管理QoS Flow的生成规则中的一项或多项。多播会话管理包括但不限于管理多播会话的IP地址分配，进行用户面网元的选择，或者进行QoS flow的生成决策中的一项或多项。
在实施例1中，应用服务器460需要建立多播会话，同时向特定区域发送多播数据。其中，多播会话的建立过程是：由MB-NEF 410确定用于进行多播会话的策略管理的MB-PCF420，以及确定用于进行多播会话管理(如多播会话建立)的MB-SMF 430。由MB-PCF 420根据MB-NEF 410的指示进行策略的创建。由MB-SMF 430在MB-PCF 420完成策略决策之后，基于策略建立用于传输多播数据的多播会话。
请参考图11，图11示出了本申请实施例提供的一种多播会话的建立方法交互图一。如图11所示，本申请实施例提供的一种多播会话的建立方法包括：
S1101、MB-NEF 410接收来自应用服务器460的第一请求消息。
其中，第一请求消息可以是上文中的第三消息。第一请求消息用于请求建立多播会话。示例性的，第一请求消息可以为多播会话建立请求消息。其中，建立多播会话是指建立用于进行多播传输的核心网资源。
在本申请实施例中，第一请求消息中包含多播会话的信息。多播会话的信息可以包括以下任意一项或多项：多播会话的质量要求信息、传输区域信息和业务标识信息。其中，多播会话的质量要求信息用于表征应用服务器460对多播会话的质量要求。传输区域信息用于表征多播传输的目标区域。业务标识信息用于在多播传输过程中识别来自应用服务器460的多播数据。
在本申请实施例中，多播会话的质量要求信息可以包含但不限于应用服务器460对多播会话的时延要求，传输速率要求或带宽要求中的一项或多项。业务标识信息可以是应用服务器460通过在第一请求消息中携带业务数据流(Service Data Flow，SDF)模板信息发送给MB-NEF 410的。示例性的，SDF模板信息可以包括应用服务器460的IP地址和端口号。
S1102、MB-NEF 410确定MB-PCF 420。MB-PCF 420用于为多播会话创建策略。
在本申请实施例中，MB-NEF 410可以根据第一请求消息中包含的传输区域信息，以及该传输区域信息所指示的传输区域内的多个PCF的能力信息，确定MB-PCF 420。
可以理解，核心网中通常部署有多个PCF。其中，该多个PCF的能力是不同的。例如，该多个PCF中有的PCF的支持多播会话的策略管理(即MB-PCF)，有的不支持多播会话的策略管理(即常规的PCF)。MB-NEF 410可以结合传输区域信息以及PCF的能力信息，确定用于进行多播会话的策略管理(如多播会话建立策略)的MB-PCF，如MB-PCF 420。其中，PCF的能力信息用于指示PCF是否支持多播会话的策略管理，即PCF是否是功能扩展后的MB-PCF。
S1103、MB-NEF 410向MB-PCF 420发送第二请求消息。
其中，第二请求消息可以是图5或图6中所示的第一消息。第二请求消息用于请求MB-PCF 420为多播会话做策略决策。示例性的，第二请求消息可以为策略请求消息。
其中，第二请求消息中可以包含多播会话的质量要求信息、传输区域信息和业务标识信息中的一项或多项。质量要求信息可以包含但不限于应用服务器460对多播会话的时延要求，传输速率要求或带宽要求中的一项或多项。业务标识信息可以包括应用服务器460的IP地址和端口号。第二请求消息请求的策略用于规定但不限于建立QoS flow的规则、授权的QoS规则、识别多播数据的规则或过滤多播数据的规则中的一项或多项。
S1104、MB-PCF 420为多播会话做策略决策。
其中，策略可以包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数(即多播数据被授权的QoS参数)或多播数据过滤参数。多播数据的标识信息用于标识来自应用服务器460的多播数据。多播会话质量参数用于规定多播数据的传输质量，例如传输时延、传输速率和带宽等。多播数据过滤参数用于规定多播数据的接收参数。
在本申请实施例中，MB-PCF 420可以根据多播会话的质量要求信息和业务标识信息等信息做策略决策，获取多播会话的策略。
示例性的，MB-PCF 420可以根据多播会话的质量要求信息为多播会话匹配能够满足多播会话需求的质量参数。
可选的，MB-PCF 420中可以预先配置有业务标识信息与策略的映射关系。MB-PCF420可以根据MB-PCF 420中预先配置的业务标识信息与策略的映射关系，获取多播会话的策略。
可选的，MB-PCF 420中可以预先配置质量要求信息与策略的映射关系。MB-PCF420可以根据MB-PCF 420中预先配置的质量要求信息与策略的映射关系，获取多播会话的策略。
S1105、MB-PCF 420向MB-NEF 410发送第一响应消息。
其中，第一响应消息可以是图5或图6中所示的第二消息。第一响应消息还可以包含MB-PCF 420获取的策略或其他信息。第一响应消息还可以包含多播数据标识信息，多播会话质量参数和多播数据过滤参数中的至少一个。示例性的，第一响应消息可以为策略响应消息。
S1106、MB-NEF 410确定MB-SMF 430。MB-SMF 430用于管理多播会话。
在本申请实施例中，MB-NEF 410可以根据传输区域信息，以及该传输区域信息所指示的传输区域内的多个SMF的能力信息，确定MB-SMF 430。
S1107、MB-NEF 410为应用服务器460分配事务标识信息。
其中，事务标识信息用于识别第一信息。第一信息为MB-NEF 410中存储的建立多播会话的上下文信息。
在本申请实施例中，第一信息可以包含但不限于策略、事务标识信息、应用服务器460的标识信息和MB-SMF 430的标识信息中的一项或多项。其中，应用服务器460的标识信息可以是应用服务器460的IP地址或者应用服务器460的全限定域名(Fully QualifiedDomain Name，FQDN)等。MB-SMF 430的标识信息可以是MB-SMF 430的IP地址或者MB-SMF430的FQDN等。
进一步的，第一信息还可以包含MB-PCF 420的标识信息和/或多播会话的群组标识信息。其中，MB-PCF 420的标识信息可以是MB-PCF 420的IP地址或者MB-PCF 420的FQDN等。多播会话的群组标识信息用于标识在空口发送的，用于指示UE接收多播群组数据的配置。例如，接收多播群组数据的频点等。当此后应用服务器发送更新/修改/删除请求时，可以根据MB-PCF 420的标识信息找到对应的上下文/会话。
需要注意的是，S1107是可选的。即MB-NEF 410还可以在执行完S1106之后，不执行S1107，执行S1108。
S1108、MB-NEF 410向MB-SMF 430发送第三请求消息。
其中，第三请求消息可以是第四消息。第三请求消息用于请求MB-SMF 430建立多播会话。示例性的，第三请求消息可以为多播会话建立请求消息。
在本申请实施例中，第三请求消息包含MB-PCF 420获取的策略中的部分或全部信息，或者获取的其他信息。第三请求消息还可以包含但不限于传输区域信息和/或业务标识信息。
需要说明的是，本申请实施例不限定S1107和S1108的执行顺序。例如，可以先执行S1107，再执行S1108；也可以先执行S1108，再执行S1107。
S1109、MB-SMF 430向MB-UPF 440发送第二信息。
其中，第二信息用于MB-UPF 440识别来自应用服务器460的多播数据。所述第二信息包含但不限于业务标识信息。
在本申请实施例中，MB-UPF 440可以是MB-SMF 430根据传输区域信息，以及该传输区域信息所指示的传输区域内的多个UPF的能力信息确定的。其中，MB-UPF 440用于根据业务标识信息识别来自应用服务器460的多播数据。UPF的能力信息用于指示UPF是否支持多播数据传输。
在本申请实施例中，第二信息还可以包含多播数据的计费规则，计费规则可以来源于第三请求消息，进一步来源于MB-PCF 420所获取的策略，也就说，S1104的策略还可以包括多播数据的计费规则。MB-UPF 440还用于根据多播数据的计费规则对识别出的多播数据进行计费。UPF的能力信息还用于指示UPF是否支持对多播数据的计费。
在本申请实施例中，MB-SMF 430可以通过N4会话建立消息向MB-UPF 440发送第二信息。其中，N4为MB-SMF 430和MB-UPF 440之间的参考点。
S1110、MB-SMF 430向RAN 450发送第三信息。
其中，第三信息用于RAN 450进行多播传输配置。第三信息可以包含但不限于MB-PCF 420获取的策略中的部分或全部信息，或者获取的其他信息。多播传输配置包括但不限于以下任意一项或多项：建立多播传输的上下文、配置QoS参数或处理多播数据。
在本申请实施例中，QoS参数可以包含但不限于多播会话质量5QI，QoS等级标识(QoS Class Identifier，QCI)，分配/保持优先级(Allocation/Retension priority，ARP)，保证流比特速率(Guaranteed Flow Bit Rate，GFBR)或最大流比特速率(MaximumFlow Bit Rate，MFBR)中的一个或多个。
其中，GFBR用于描述固定不变的多播数据传输时的比特速率。MFBR用于描述多播数据传输时的最大比特速率。
QCI用于描述多播数据的传输特性。ARP用于描述用户优先级和/或用户请求业务类型的优先级高低，以便基于ARP进行资源的分配，以及在资源紧张时不同业务之间的资源抢占。
在本申请实施例中，第三信息还可以包含多播数据的标识信息。其中，多播数据的标识信息可以是MB-SMF 430分配的。多播数据的标识信息用于RAN 450从MB-UPF 440的识别对应的多播数据。由于多播数据从MB-UPF 440发送到RAN 450使用的是IP多播的路由方式。示例性的，RAN 450可以根据多播数据的标识信息向MB-UPF 440发送因特网组管理协议(Internet Group Management Protocol，IGMP)Join消息，中间经过的路由器会记录下行的传输路径。当有多个RAN发送IGMP Join消息时会形成一个下行多播树。在本申请实施例中，MB-SMF 430可以通过N2消息向RAN 450发送第三信息。其中，N2为MB-SMF 430和RAN 450之间的参考点。
进一步的，第三信息还可以包含多播会话的群组标识信息。多播会话的群组标识信息用于RAN 450标识在空口发送的，用于指示UE接收多播群组数据的配置。例如，接收多播群组数据的频点等。
S1111、MB-SMF 430向MB-NEF 410发送第二响应消息。
其中，第二响应消息用于指示多播会话已建立。示例性的，第二响应消息可以是多播会话建立响应消息。
第二响应消息可以包含但不限于MB-UPF 440的标识信息。示例性的，MB-UPF 440的标识信息可以包括MB-UPF 440的IP地址信息和端口号信息。其中，MB-UPF 440的标识信息可以是MB-UPF 440的IP地址或者MB-UPF 440的FQDN等。
S1112、MB-NEF 410向应用服务器460发送第三响应消息。
其中，第三响应消息用于指示多播会话已建立。示例性的，第三响应消息可以是多播会话建立响应消息。第三响应消息可以包含但不限于MB-UPF 440的标识信息和/或事务标识信息。当此后应用服务器发送更新/修改/删除请求时，可以根据事务标识信息找到对应的上下文/会话。
实施例2：
在实施例2中，MB-NEF 410具备选择MB-PCF的功能。MB-PCF 420具备选择MB-SMF的功能，以及多播会话的策略管理功能。MB-SMF 430具备多播会话管理功能。
在实施例2中，应用服务器460需要建立多播会话，同时向特定区域发送多播数据。其中，多播会话的建立过程是：由MB-NEF 410确定用于进行多播会话的策略管理的MB-PCF420。由MB-PCF 420根据MB-NEF 410的指示做策略决策，以及确定用于进行多播会话管理(如多播会话建立)的MB-SMF 430。由MB-SMF 430在MB-PCF 420完成策略决策之后，基于确定的策略建立用于传输多播数据的多播会话。
请参考图12，图12示出了本申请实施例提供的一种多播会话的建立方法交互图二。如图12所示，本申请实施例提供的一种多播会话的建立方法包括：
S1201、MB-NEF 410接收来自应用服务器460的第一请求消息。
其中，第一请求消息可以是上文中的第三消息。第一请求消息用于请求建立多播会话。示例性的，第一请求消息可以为多播会话建立请求消息。其中，建立多播会话是指建立用于进行多播传输的核心网资源。
在本申请实施例中，第一请求消息中包含多播会话的信息。多播会话的信息可以包括以下任意一项或多项：多播会话的质量要求信息、传输区域信息和业务标识信息。
S1202、MB-NEF 410确定MB-PCF 420。MB-PCF 420用于为多播会话创建策略。
在本申请实施例中，MB-NEF 410可以根据第一请求消息中包含的传输区域信息，以及该传输区域信息所指示的传输区域内的多个PCF的能力信息，确定MB-PCF 420。
S1203、MB-NEF 410为应用服务器460分配事务标识信息。
其中，事务标识信息用于识别第一信息。第一信息包括MB-NEF 410中存储的建立多播会话的上下文信息，和/或MB-PCF 420中存储的建立多播会话的上下文信息。关于MB-PCF 420中存储的建立多播会话的上下文信息，将在下文中具体介绍。
在本申请实施例中，第一信息可以包含但不限于MB-NEF 410中存储的MB-PCF 420的标识信息、事务标识信息、应用服务器460的标识信息和多播会话的群组标识信息中的一项或多项。其中，多播会话的群组标识信息用于标识在空口发送的，用于指示UE接收多播群组数据的配置。例如，接收多播群组数据的频点等。需要说明的是，本申请实施例不限定S1203和S1204的执行顺序。例如，可以先执行S1203，再执行S1204；也可以先执行S1204，再执行S1203。
需要注意的是，S1203是可选的。即MB-NEF 410还可以在执行完S1202之后，不执行S1203，执行S1204。
S1204、MB-NEF 410向MB-PCF 420发送第二请求消息。
其中，第二请求消息可以是图5、图6或图7中所示的第一消息。第二请求消息用于请求MB-PCF 420为多播会话做策略决策。示例性的，第二请求消息可以为策略请求消息。
在本申请实施例中，第二请求消息中可以包含多播会话的质量要求信息、传输区域信息和业务标识信息中的一项或多项。质量要求信息可以包含但不限于应用服务器460对多播会话的时延要求，传输速率要求或带宽要求中的一项或多项。业务标识信息可以包括应用服务器460的IP地址和端口号。第二请求消息请求的策略用于规定但不限于建立QoSflow的规则、授权的QoS规则、识别多播数据的规则或过滤多播数据的规则中的一项或多项。
S1205、MB-PCF 420为多播会话做策略决策。
其中，策略可以包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数(即多播数据被授权的QoS参数)或多播数据过滤参数。多播数据的标识信息用于标识来自应用服务器460的多播数据。多播会话质量参数用于规定多播数据的传输质量，例如传输时延、传输速率和带宽等。多播数据过滤参数用于规定多播数据的接收参数。
在本申请实施例中，MB-PCF 420可以根据多播会话的质量要求信息和业务标识信息等信息为多播会话创建策略。
示例性的，MB-PCF 420可以根据多播会话的质量要求信息为多播会话匹配能够满足多播会话需求的质量参数。
可选的，MB-PCF 420中可以预先配置有业务标识信息与策略的映射关系。MB-PCF420可以根据MB-PCF 420中预先配置的业务标识信息与策略的映射关系，获取多播会话的策略。
可选的，MB-PCF 420中可以预先配置质量要求信息与策略的映射关系。MB-PCF420可以根据MB-PCF 420中预先配置的质量要求信息与策略的映射关系，获取多播会话的策略。
S1206、MB-PCF 420确定MB-SMF 430。MB-SMF 430用于管理多播会话。
在本申请实施例中，MB-PCF 420可以根据传输区域信息，以及该传输区域信息所指示的传输区域内的多个SMF的能力信息，确定MB-SMF 430。
进一步的，MB-PCF 420中还可以存储建立多播会话的上下文信息。示例性的，建立多播会话的上下文信息可以包括但不限于事务标识信息，策略，应用服务器460和MB-SMF430的标识信息中的一项或多项。其中，事务标识信息用于标识MB-PCF 420中存储的建立多播会话的上下文信息。
S1207、MB-PCF 420向MB-SMF 430发送第三请求消息。
其中，第三请求消息可以是图5、图6或图7中所示的第二消息。第三请求消息请求MB-SMF 430建立多播会话。示例性的，第三请求消息可以为多播会话建立请求消息。
在本申请实施例中，第三请求消息包含MB-PCF 420获取的策略中的部分或全部信息，或者获取的其他信息。第三请求消息还可以包含但不限于传输区域信息和/或业务标识信息。示例性的，第三请求消息还可以包括策略。
S1208、MB-SMF 430向MB-UPF 440发送第二信息。
其中，第二信息用于MB-UPF 440识别来自应用服务器460的多播数据。所述第二信息包含但不限于业务标识信息。
在本申请实施例中，MB-UPF 440可以是MB-SMF 430根据传输区域信息，以及该传输区域信息所指示的传输区域内的多个UPF的能力信息确定的。其中，MB-UPF 440用于根据业务标识信息识别来自应用服务器460的多播数据。UPF的能力信息用于指示UPF是否支持多播数据传输。
进一步的，第二信息还可以包含多播数据的计费规则，计费规则可以来源于第三请求消息，进一步来源于MB-PCF 420所获取的策略，也就说，S1205的策略还可以包括多播数据的计费规则。MB-UPF 440还用于根据多播数据的计费规则对识别出的多播数据进行计费。UPF的能力信息还用于指示UPF是否支持对多播数据的计费。
在本申请实施例中，MB-SMF 430可以通过N4会话建立消息向MB-UPF 440发送第二信息。其中，N4为MB-SMF 430和MB-UPF 440之间的参考点。
S1209、MB-SMF 430向RAN 450发送第三信息。
其中，第三信息用于RAN 450进行多播传输配置。第三信息可以包含但不限于MB-PCF 420创建的策略。多播传输配置包括但不限于以下任意一项或多项：建立多播传输的上下文、配置QoS参数或处理多播数据。关于QoS参数的说明，可以参考上文实施例1中的介绍，这里不做赘述。
进一步的，第三信息还可以包含多播数据的标识信息。其中，多播数据的标识信息可以是MB-SMF 430分配的。多播数据的标识信息用于RAN 450从MB-UPF 440的识别对应的多播数据。示例性的，RAN 450可以根据多播数据的标识信息向MB-UPF 440发送IGMPJoin消息，中间经过的路由器会记录下行的传输路径。在本申请实施例中，MB-SMF 430可以通过N2消息向RAN 450发送第三信息。其中，N2为MB-SMF 430和RAN 450之间的参考点。
S1210、MB-SMF 430向MB-PCF 420发送第一响应消息。
其中，第一响应消息用于指示多播会话已建立。示例性的，第一响应消息可以是多播会话建立响应消息。
其中，第一响应消息可以包含但不限于MB-UPF 440的标识信息。示例性的，MB-UPF440的标识信息可以包含MB-UPF 440的IP地址信息和端口号信息。
S1211、MB-SMF 430向MB-NEF 410发送第二响应消息。
其中，第二响应消息用于指示多播会话已建立。示例性的，第二响应消息可以是多播会话建立响应消息。第二响应消息可以包含但不限于MB-UPF 440的标识信息。
S1212、MB-NEF 410向应用服务器460发送第三响应消息。
其中，第三响应消息用于指示多播会话已建立。示例性的，第三响应消息可以是多播会话建立响应消息。第三响应消息可以包含但不限于MB-UPF 440的标识信息和/或事务标识信息。
实施例3：
在实施例3中，MB-NEF 410具备选择MB-SMF 430的功能。MB-SMF 430具备确定多播会话的策略的功能，以及具备多播会话管理功能。
其中，MB-SMF 430中预先配置有质量要求信息与策略的映射关系；或者，MB-SMF430中预先配置有业务标识信息与策略的映射关系。MB-SMF 430具备确定策略的功能是指MB-SMF 430具备根据MB-SMF 430中预先配置的质量要求信息(或业务标识信息)与策略的映射关系，确定多播会话的策略的功能。多播会话管理包括但不限于管理多播会话的IP地址分配，进行用户面网元的选择，或者进行QoS flow的生成决策中的一项或多项。
在实施例3中应用服务器460需要建立多播会话，同时向特定区域发送多播数据。其中，多播会话的建立过程是：由MB-NEF 410确定用于进行多播会话管理(如多播会话建立)的MB-SMF 430。由MB-SMF 430根据MB-SMF 430中预先配置的质量要求信息(或业务标识信息)与策略的映射关系确定策略，以及基于确定的策略建立用于传输多播数据的多播会话。
请参考图13，图13示出了本申请实施例提供的一种多播会话的建立方法交互图三。如图13所示，本申请实施例提供的一种多播会话的建立方法包括：
S1301、MB-NEF 410接收来自应用服务器460的第一请求消息。
其中，第一请求消息用于请求建立多播会话。示例性的，第一请求消息可以为多播会话建立请求消息。其中，建立多播会话是指建立用于进行多播传输的核心网资源。
在本申请实施例中，第一请求消息中包含多播会话的信息。多播会话的信息可以包括以下任意一项或多项：多播会话的质量要求信息、传输区域信息和业务标识信息。
S1302、MB-NEF 410确定MB-SMF 430。MB-SMF 430用于确定策略和管理多播会话。
在本申请实施例中，MB-NEF 410可以根据传输区域信息，以及该传输区域信息所指示的传输区域内的多个SMF的能力信息，确定MB-SMF 430。
S1303、MB-NEF 410为应用服务器460分配事务标识信息。
其中，事务标识信息用于识别第一信息。第一信息包括MB-NEF 410中存储的建立多播会话的上下文信息。示例性的，MB-NEF 410中存储的建立多播会话的上下文信息可以包含但不限于事务标识信息、应用服务器460的标识信息和MB-SMF 430的标识信息中的一项或多项。
进一步的，MB-NEF 410中存储的建立多播会话的上下文信息还可以包含多播会话的群组标识。其中，多播会话的群组标识信息用于标识在空口发送的，用于指示UE接收多播群组数据的配置。例如，接收多播群组数据的频点等。
需要说明的是，本申请实施例不限定S1303和S1304的执行顺序。例如，可以先执行S1303，再执行S1304；也可以先执行S1304，再执行S1303。
需要注意的是，S1303是可选的。即MB-NEF 410还可以在执行完S1302之后，不执行S1303，执行S1304。
S1304、MB-NEF 410向MB-SMF 430发送第二请求消息。
其中，第二请求消息可以是图9或图10中所示的第一消息。第二请求消息用于请求MB-SMF 430建立多播会话。示例性的，第三请求消息可以为多播会话建立请求消息。
在本申请实施例中，第二请求消息可以包含但不限于传输区域信息和/或业务标识信息。
S1305、MB-SMF 430获取多播会话的策略。
其中，策略可以包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数(即多播数据被授权的QoS参数)或多播数据过滤参数。多播数据的标识信息用于标识来自应用服务器460的多播数据。多播会话质量参数用于规定多播数据的传输质量，例如传输时延、传输速率和带宽等。多播数据过滤参数用于规定多播数据的接收参数。
在本申请实施例中，MB-SMF 430中可以预先配置有业务标识信息与策略的映射关系。MB-SMF 430可以根据MB-SMF 430中预先配置的业务标识信息与策略的映射关系，获取多播会话的策略。
可选的，MB-SMF 430中可以预先配置质量要求信息与策略的映射关系。MB-SMF430可以根据MB-SMF 430中预先配置的质量要求信息与策略的映射关系，获取多播会话的策略。
S1306、MB-SMF 430向MB-UPF 440发送第二信息。
其中，第二信息用于MB-UPF 440识别来自应用服务器460的多播数据。所述第二信息包含但不限于业务标识信息。
在本申请实施例中，MB-UPF 440可以是MB-SMF 430根据传输区域信息，以及该传输区域信息所指示的传输区域内的多个UPF的能力信息确定的。其中，MB-UPF 440用于根据业务标识信息识别来自应用服务器460的多播数据。UPF的能力信息用于指示UPF是否支持多播数据传输。
进一步的，第二信息还可以包含多播数据的计费规则，计费规则可以来源于MB-SMF 430所获取的策略，也就说，S1305的策略还可以包括多播数据的计费规则。MB-UPF 440还用于根据多播数据的计费规则对识别出的多播数据进行计费。UPF的能力信息还用于指示UPF是否支持对多播数据的计费。
在本申请实施例中，MB-SMF 430可以通过N4会话建立消息向MB-UPF 440发送第二信息。其中，N4为MB-SMF 430和MB-UPF 440之间的参考点。
S1307、MB-SMF 430向RAN 450发送第三信息。
其中，第三信息用于RAN 450进行多播传输配置。第三信息可以包含但不限于MB-PCF 420创建的策略。多播传输配置包括但不限于以下任意一项或多项：建立多播传输的上下文、配置QoS参数或处理多播数据。关于QoS参数的说明，可以参考上文实施例1中的介绍，这里不做赘述。
进一步的，第三信息还可以包含多播数据的标识信息。其中，多播数据的标识信息可以是MB-SMF 430分配的。多播数据的标识信息用于RAN 450从MB-UPF 440的识别对应的多播数据。示例性的，RAN 450可以根据多播数据的标识信息向MB-UPF 440发送IGMPJoin消息，中间经过的路由器会记录下行的传输路径。在本申请实施例中，MB-SMF 430可以通过N2消息向RAN 450发送第三信息。其中，N2为MB-SMF 430和RAN 450之间的参考点。
S1308、MB-SMF 430向MB-NEF 410发送第一响应消息。
其中，第一响应消息用于指示多播会话已建立。示例性的，第一响应消息可以是多播会话建立响应消息。第一响应消息可以包含但不限于MB-UPF 440的标识信息。
S1309、MB-NEF 410向应用服务器460发送第二响应消息。
其中，第二响应消息用于指示多播会话已建立。示例性的，第二响应消息可以是多播会话建立响应消息。第二响应消息可以包含但不限于MB-UPF 440的标识信息和/或事务标识信息。
实施例4：
在实施例4中，MB-NEF 410具备选择MB-PCF和MB-SMF的功能。MB-PCF 420具备多播会话的策略管理功能。MB-SMF 430具备多播会话管理功能。
其中，多播会话的策略管理包括但不限于PCC，管理多播会话的QoS参数，或者管理QoS Flow的生成规则中的一项或多项。多播会话管理包括但不限于管理多播会话的IP地址分配，进行用户面网元的选择，或者进行QoS flow的生成决策中的一项或多项。
在实施例4中，应用服务器460需要建立多播会话，同时向特定区域发送多播数据。其中，多播会话的建立过程是：由MB-NEF 410确定用于进行多播会话的策略管理的MB-PCF420，以及确定用于进行多播会话管理(如多播会话建立)的MB-SMF 430。由MB-PCF 420根据MB-SMF 430的指示做多播会话的策略决策。由MB-SMF 430在MB-PCF 420完成策略决策之后，基于策略建立用于传输多播数据的多播会话。
请参考图14，图14示出了本申请实施例提供的一种多播会话的建立方法交互图四。如图14所示，本申请实施例提供的一种多播会话的建立方法包括：
S1401、MB-NEF 410接收来自应用服务器470的第一请求消息。
其中，第一请求消息可以是上文中的第三消息。第一请求消息用于请求建立多播会话。示例性的，第一请求消息可以为多播会话建立请求消息。其中，建立多播会话是指建立用于进行多播传输的核心网资源。
在本申请实施例中，第一请求消息中包含多播会话的信息。多播会话的信息可以包括以下任意一项或多项：多播会话的质量要求信息、传输区域信息和业务标识信息。
S1402、MB-NEF 410确定MB-SMF 430和MB-PCF 420。
其中，MB-SMF 430用于管理多播会话。MB-PCF 420用于为多播会话创建策略。
在本申请实施例中，MB-NEF 410可以根据第一请求消息中包含的传输区域信息，以及该传输区域信息所指示的传输区域内的多个SMF的能力信息，确定MB-SMF 430。
在本申请实施例中，MB-NEF 410可以根据第一请求消息中包含的传输区域信息，以及该传输区域信息所指示的传输区域内的多个PCF的能力信息，确定MB-PCF 420。
S1403、MB-NEF 410向MB-SMF 430发送第二请求消息。
其中，第二请求消息用于请求MB-SMF 430建立多播会话。示例性的，第三请求消息可以为多播会话建立请求消息。
在本申请实施例中，第二请求消息中包含MB-PCF 420的标识信息。第二请求消息还可以包含多播会话的质量要求信息、传输区域信息和业务标识信息中的一项或多项。质量要求信息可以包含但不限于应用服务器460对多播会话的时延要求，传输速率要求或带宽要求中的一项或多项。业务标识信息可以包括应用服务器460的IP地址和端口号。
S1404、MB-SMF 430向MB-PCF 420发送第三请求消息。
其中，第三请求消息可以是上文中图5或图8中所示的第一消息。第三请求消息用于请求MB-PCF 420为多播会话做策略决策。示例性的，第三请求消息可以为策略请求消息。
在本申请实施例中，第三请求消息中可以包含多播会话的质量要求信息、传输区域信息和业务标识信息中的一项或多项。第三请求消息请求的策略用于规定但不限于建立QoS flow的规则、授权的QoS规则、识别多播数据的规则或过滤多播数据的规则中的一项或多项。S1405、MB-PCF 420为多播会话做策略决策。
其中，策略可以包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数(即多播数据被授权的QoS参数)或多播数据过滤参数。多播数据的标识信息用于标识来自应用服务器460的多播数据。多播会话质量参数用于规定多播数据的传输质量，例如传输时延、传输速率和带宽等。多播数据过滤参数用于规定多播数据的接收参数。
在本申请实施例中，MB-PCF 420可以根据多播会话的质量要求信息和业务标识信息等信息为多播会话创建策略。
示例性的，MB-PCF 420可以根据多播会话的质量要求信息为多播会话匹配能够满足多播会话需求的质量参数。
可选的，MB-PCF 420中可以预先配置有业务标识信息与策略的映射关系。MB-PCF420可以根据MB-PCF 420中预先配置的业务标识信息与策略的映射关系，获取多播会话的策略。
在另一些实施例中，MB-PCF 420中可以预先配置质量要求信息与策略的映射关系。MB-PCF 420可以根据MB-PCF 420中预先配置的质量要求信息与策略的映射关系，获取多播会话的策略。
S1406、MB-PCF 420向MB-SMF 430发送第一响应消息。
其中，第一响应消息可以是图5或图8中所示的第二消息。示例性的，第三请求消息可以为策略响应消息。
在本申请实施例中，第一响应消息包含策略。
S1407、MB-SMF 430向MB-UPF 440发送第二信息。
其中，第二信息用于MB-UPF 440识别来自应用服务器460的多播数据。第二信息包含但不限于业务标识信息。
在本申请实施例中，MB-UPF 440可以是MB-SMF 430根据传输区域信息，以及该传输区域信息所指示的传输区域内的多个UPF的能力信息确定的。其中，MB-UPF 440用于根据业务标识信息识别来自应用服务器460的多播数据。UPF的能力信息用于指示UPF是否支持多播数据传输。
进一步的，第二信息还可以包含多播数据的计费规则，计费规则可以来源于第一响应消息，进一步来源于MB-PCF 420所获取的策略，也就说，S1405的策略还可以包括多播数据的计费规则。MB-UPF 440还用于根据多播数据的计费规则对识别出的多播数据进行计费。UPF的能力信息还用于指示UPF是否支持对多播数据的计费。
在本申请实施例中，MB-SMF 430可以通过N4会话建立消息向MB-UPF 440发送第二信息。其中，N4为MB-SMF 430和MB-UPF 440之间的参考点。
S1408、MB-SMF 430向RAN 450发送第三信息。
其中，第三信息用于RAN 450进行多播传输配置。第三信息可以包含但不限于MB-PCF 420创建的策略。多播传输配置包括但不限于以下任意一项或多项：建立多播传输的上下文、配置QoS参数或处理多播数据。关于QoS参数的说明，可以参考上文实施例1中的介绍，这里不做赘述。
进一步的，第三信息还可以包含多播数据的标识信息。其中，多播数据的标识信息可以是MB-SMF 430分配的。多播数据的标识信息用于RAN 450从MB-UPF 440的识别对应的多播数据。示例性的，RAN 450可以根据多播数据的标识信息向MB-UPF 440发送IGMPJoin消息，中间经过的路由器会记录下行的传输路径。在本申请实施例中，MB-SMF 430可以通过N2消息向RAN 450发送第三信息。其中，N2为MB-SMF 430和RAN 450之间的参考点。
S1409、MB-SMF 430向MB-NEF 410发送第二响应消息。
其中，第二响应消息用于指示多播会话已建立。示例性的，第二响应消息可以是多播会话建立响应消息。第二响应消息可以包含但不限于MB-UPF 440的标识信息。
S1410、MB-NEF 410向应用服务器460发送第三响应消息。
其中，第三响应消息用于指示多播会话已建立。示例性的，第三响应消息可以是多播会话建立响应消息。第三响应消息可以包含但不限于MB-UPF 440的标识信息和/或事务标识信息。
可选的，本申请实施例4提供的多播会话的建立方法还包括：MB-PCF 420为应用服务器460分配事务标识信息；以及MB-PCF 420存储第一信息。
其中，事务标识信息用于识别第一信息。第一信息包括建立多播会话的上下文信息。建立多播会话的上下文信息可以包含但不限于事务标识信息，策略，应用服务器460的标识信息或MB-SMF 430的标识信息中的一项或多项。
实施例5：
在实施例5中，MB-NEF 410具备选择MB-PCF和MB-SMF的功能。MB-PCF 420具备多播会话的策略管理功能。MB-SMF 430具备多播会话管理功能。
其中，多播会话的策略管理包括但不限于PCC，管理多播会话的QoS参数，或者管理QoS Flow的生成规则中的一项或多项。多播会话管理包括但不限于管理多播会话的IP地址分配，进行用户面网元的选择，或者进行QoS flow的生成决策中的一项或多项。
在实施例5中，应用服务器460需要建立多播会话，同时向特定区域发送多播数据。其中，多播会话的建立过程是：由MB-NEF 410确定用于进行多播会话的策略管理的MB-PCF420，以及确定用于进行多播会话管理(如多播会话建立)的MB-SMF 430。由MB-PCF 420根据由MB-NEF 410的指示做多播会话的策略决策。由MB-SMF 430在MB-PCF 420完成策略决策之后，基于策略建立用于传输多播数据的多播会话。
请参考图15，图15示出了本申请实施例提供的一种多播会话的建立方法交互图五。如图15所示，本申请实施例提供的一种多播会话的建立方法包括：
S1501、MB-NEF 410接收来自应用服务器470的第一请求消息。
其中，第一请求消息可以是上文中的第三消息。第一请求消息用于请求建立多播会话。示例性的，第一请求消息可以为多播会话建立请求消息。其中，建立多播会话是指建立用于进行多播传输的核心网资源。
在本申请实施例中，第一请求消息中包含多播会话的信息。多播会话的信息可以包括以下任意一项或多项：多播会话的质量要求信息、传输区域信息和业务标识信息。
S1502、MB-NEF 410确定MB-SMF 430和MB-PCF 420。
其中，MB-SMF 430用于管理多播会话。MB-PCF 420用于为多播会话创建策略。
在本申请实施例中，MB-NEF 410可以根据第一请求消息中包含的传输区域信息，以及该传输区域信息所指示的传输区域内的多个SMF的能力信息，确定MB-SMF 430。
在本申请实施例中，MB-NEF 410可以根据第一请求消息中包含的传输区域信息，以及该传输区域信息所指示的传输区域内的多个PCF的能力信息，确定MB-PCF 420。
S1503、MB-NEF 410向MB-PCF 420发送第二请求消息。
其中，第二请求消息可以是上文中图5或图6中所示的第一消息。第二请求消息用于请求MB-PCF 420为多播会话做策略决策。示例性的，第二请求消息可以为策略请求消息。
在本申请实施例中，第二请求消息中包含MB-SMF 430的标识信息。第二请求消息中还可以包含多播会话的质量要求信息、传输区域信息和业务标识信息中的一项或多项。第二请求消息请求的策略用于规定但不限于建立QoS flow的规则、授权的QoS规则、识别多播数据的规则或过滤多播数据的规则中的一项或多项。
S1504、MB-PCF 420为多播会话做策略决策。
其中，策略可以包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数(即多播数据被授权的QoS参数)或多播数据过滤参数。多播数据的标识信息用于标识来自应用服务器460的多播数据。多播会话质量参数用于规定多播数据的传输质量，例如传输时延、传输速率和带宽等。多播数据过滤参数用于规定多播数据的接收参数。
在本申请实施例中，MB-PCF 420可以根据多播会话的质量要求信息和业务标识信息等信息为多播会话创建策略。
可选的，MB-PCF 420中可以预先配置有业务标识信息与策略的映射关系。MB-PCF420可以根据MB-PCF 420中预先配置的业务标识信息与策略的映射关系，获取多播会话的策略。
可选的，MB-PCF 420中可以预先配置质量要求信息与策略的映射关系。MB-PCF420可以根据MB-PCF 420中预先配置的质量要求信息与策略的映射关系，获取多播会话的策略。
S1505、MB-PCF 420向MB-SMF 430发送第三请求消息。
其中，第三请求消息可以是上文中图5或图6中所示的第二消息。第三请求消息用于请求MB-SMF 430建立多播会话。示例性的，第三请求消息可以为多播会话建立请求消息。
在本申请实施例中，第三请求消息可以包含MB-PCF 420创建的策略。
S1506、MB-SMF 430向MB-UPF 440发送第二信息。
其中，第二信息用于MB-UPF 440识别来自应用服务器460的多播数据。第二信息包含但不限于业务标识信息。
在本申请实施例中，MB-UPF 440可以是MB-SMF 430根据传输区域信息，以及该传输区域信息所指示的传输区域内的多个UPF的能力信息确定的。其中，MB-UPF 440用于根据业务标识信息识别来自应用服务器460的多播数据。UPF的能力信息用于指示UPF是否支持多播数据传输。
进一步的，第二信息还可以包含多播数据的计费规则，计费规则可以来源于第三请求消息，进一步来源于MB-PCF 420所获取的策略，也就说，S1504的策略还可以包括多播数据的计费规则。MB-UPF 440还用于根据多播数据的计费规则对识别出的多播数据进行计费。UPF的能力信息还用于指示UPF是否支持对多播数据的计费。
在本申请实施例中，MB-SMF 430可以通过N4会话建立消息向MB-UPF 440发送第二信息。其中，N4为MB-SMF 430和MB-UPF 440之间的参考点。
S1507、MB-SMF 430向RAN 450发送第三信息。
其中，第三信息用于RAN 450进行多播传输配置。第三信息可以包含但不限于MB-PCF 420创建的策略。多播传输配置包括但不限于以下任意一项或多项：建立多播传输的上下文、配置QoS参数或处理多播数据。关于QoS参数的说明，可以参考上文实施例1中的介绍，这里不做赘述。
进一步的，第三信息还可以包含多播数据的标识信息。其中，多播数据的标识信息可以是MB-SMF 430分配的。多播数据的标识信息用于RAN 450从MB-UPF 440的识别对应的多播数据。示例性的，RAN 450可以根据多播数据的标识信息向MB-UPF 440发送IGMPJoin消息，中间经过的路由器会记录下行的传输路径。
在本申请实施例中，MB-SMF 430可以通过N2消息向RAN 450发送第三信息。其中，N2为MB-SMF 430和RAN 450之间的参考点。
S1508、MB-SMF 430向MB-NEF 410发送第一响应消息。
其中，第一响应消息用于指示多播会话已建立。示例性的，第一响应消息可以是多播会话建立响应消息。第一响应消息可以包含但不限于MB-UPF 440的标识信息。
S1509、MB-NEF 410向应用服务器460发送第二响应消息。
其中，第二响应消息用于指示多播会话已建立。示例性的，第二响应消息可以是多播会话建立响应消息。第二响应消息可以包含但不限于MB-UPF 440的标识信息。
可选的，本申请实施例5提供的多播会话的建立方法还包括：MB-PCF 420为应用服务器460分配事务标识信息；以及MB-PCF 420存储第一信息。
其中事务标识信息用于识别第一信息。第一信息包括建立多播会话的上下文信息。建立多播会话的上下文信息可以包含但不限于事务标识信息，策略，应用服务器460的标识信息或MB-SMF 430的标识信息中的一项或多项。
实施例6：
在实施例6中，应用服务器460具备选择MB-PCF和MB-SMF的功能。MB-PCF 420具备多播会话的策略管理功能。MB-SMF 430具备多播会话管理功能。
其中，多播会话的策略管理包括但不限于PCC，管理多播会话的QoS参数，或者管理QoS Flow的生成规则中的一项或多项。多播会话管理包括但不限于管理多播会话的IP地址分配，进行用户面网元的选择，或者进行QoS flow的生成决策中的一项或多项。
在实施例6中，应用服务器460需要建多播会话，同时向特定区域发送多播数据。其中，多播会话的建立过程是：由应用服务器460确定用于进行多播会话的策略管理的MB-PCF420，以及确定用于进行多播会话管理(如多播会话建立)的MB-SMF 430。由MB-PCF 420根据应用服务器460的指示做多播会话的策略决策。由MB-SMF 430在MB-PCF 420完成策略决策之后，基于策略建立用于传输多播数据的多播会话。
请参考图16，图16示出了本申请实施例提供的一种多播会话的建立方法交互图六。如图16所示，本申请实施例提供的一种多播会话的建立方法包括：
S1601、应用服务器470确定MB-SMF 430和MB-PCF 420。
其中，MB-SMF 430用于管理多播会话。MB-PCF 420用于为多播会话创建策略。
在本申请些实施例中，应用服务器470可以根据传输区域信息，以及该传输区域信息所指示的传输区域内的多个SMF的能力信息，确定MB-SMF 430。
在本申请实施例中，应用服务器470可以根据传输区域信息，以及该传输区域信息所指示的传输区域内的多个PCF的能力信息，确定MB-PCF 420。
S1602、应用服务器470向MB-PCF 420发送第一请求消息。
其中，第一请求消息可以是上文中图5或图8中所示的第一消息。第一请求消息用于请求建立多播会话。示例性的，第一请求消息可以为多播会话建立请求消息。其中，建立多播会话是指建立用于进行多播传输的核心网资源。
在本申请实施例中，第一请求消息中包含多播会话的信息和MB-SMF 430的标识信息。多播会话的信息可以包括以下任意一项或多项：多播会话的质量要求信息、传输区域信息和业务标识信息。
S1603、MB-PCF 420为多播会话做策略决策。
其中，策略可以包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数(即多播数据被授权的QoS参数)或多播数据过滤参数。多播数据的标识信息用于标识来自应用服务器460的多播数据。多播会话质量参数用于规定多播数据的传输质量，例如传输时延、传输速率和带宽等。多播数据过滤参数用于规定多播数据的接收参数。
在本申请实施例中，MB-PCF 420可以根据多播会话的质量要求信息和业务标识信息等信息为多播会话创建策略。
可选的，MB-PCF 420中可以预先配置有业务标识信息与策略的映射关系。MB-PCF420可以根据MB-PCF 420中预先配置的业务标识信息与策略的映射关系，获取多播会话的策略。
可选的，MB-PCF 420中可以预先配置质量要求信息与策略的映射关系。MB-PCF420可以根据MB-PCF 420中预先配置的质量要求信息与策略的映射关系，获取多播会话的策略。
S1604、MB-PCF 420向MB-SMF 430发送第二请求消息。
其中，第二请求消息可以是上文中图5或图8中所示的第二消息。第二请求消息用于请求建立多播会话。示例性的，第二请求消息可以为会话请求消息。
在本申请实施例中，第二请求消息包含MB-PCF 420获取的策略中的部分或全部信息，或者获取的其他信息。
S1605、MB-SMF 430向MB-UPF 440发送第二信息。
其中，第二信息用于MB-UPF 440识别来自应用服务器460的多播数据。第二信息包含但不限于业务标识信息。
在本申请实施例中，MB-UPF 440可以是MB-SMF 430根据传输区域信息，以及该传输区域信息所指示的传输区域内的多个UPF的能力信息确定的。其中，MB-UPF 440用于根据业务标识信息识别来自应用服务器460的多播数据。UPF的能力信息用于指示UPF是否支持多播数据传输。
进一步的，第二信息还可以包含多播数据的计费规则，计费规则可以来源于第二请求消息，进一步来源于MB-PCF 420所获取的策略，也就说，S1603的策略还可以包括多播数据的计费规则。MB-UPF 440还用于根据多播数据的计费规则对识别出的多播数据进行计费。UPF的能力信息还用于指示UPF是否支持对多播数据的计费。
在本申请实施例中，MB-SMF 430可以通过N4会话建立消息向MB-UPF 440发送第二信息。其中，N4为MB-SMF 430和MB-UPF 440之间的参考点。
S1606、MB-SMF 430向RAN 450发送第三信息。
其中，第三信息用于RAN 450进行多播传输配置。第三信息可以包含但不限于MB-PCF 420创建的策略。多播传输配置包括但不限于以下任意一项或多项：建立多播传输的上下文、配置QoS参数或处理多播数据。关于QoS参数的说明，可以参考上文实施例1中的介绍，这里不做赘述。
进一步的，第三信息还可以包含多播数据的标识信息。其中，多播数据的标识信息可以是MB-SMF 430分配的。多播数据的标识信息用于RAN 450从MB-UPF 440的识别对应的多播数据。示例性的，RAN 450可以根据多播数据的标识信息向MB-UPF 440发送IGMPJoin消息，中间经过的路由器会记录下行的传输路径。
在本申请实施例中，MB-SMF 430可以通过N2消息向RAN 450发送第三信息。其中，N2为MB-SMF 430和RAN 450之间的参考点。
S1607、MB-SMF 430向应用服务器发送第一响应消息。
其中，第一响应消息用于指示多播会话已建立。示例性的，第一响应消息可以是多播会话建立响应消息。第三响应消息可以包含但不限于MB-UPF 440的标识信息。
可选的，本申请实施例6提供的多播会话的建立方法还包括：MB-PCF 420为应用服务器460分配事务标识信息；以及MB-PCF 420存储第一信息。
其中，事务标识信息用于识别第一信息。第一信息包括建立多播会话的上下文信息。建立多播会话的上下文信息可以包含但不限于事务标识信息，策略，应用服务器460的标识信息或MB-SMF 430的标识信息中的一项或多项。
需要说明的是，本申请实施例中的实施例1、实施例2、实施例3、实施例4、实施例5和实施例6仅作为几种可能的多播会话的建立方法示例。多播会话的建立方法还可以是其他的变形，本申请实施例对此不作具体限定。例如，还可以由应用服务器460确定用于进行多播会话的策略管理的MB-PCF 420。由MB-PCF 420根据应用服务器460的指示做多播会话的策略决策，以及确定用于进行多播会话管理(如多播会话建立)的MB-SMF 430。由MB-SMF430在MB-PCF 420完成策略决策之后，基于策略建立用于传输多播数据的多播会话。
可以理解的是，MB-PCF 420、MB-SMF 430、MB-NEF 410、MB-UPF 440、应用服务器460、RAN等网元为了实现上述任一个实施例的功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本申请实施例可以对MB-PCF 420、MB-SMF 430、MB-NEF 410、MB-UPF 440、应用服务器460、RAN等网元进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
比如，以采用集成的方式划分各个功能模块的情况下，如图17所示，为本申请实施例提供的一种策略管理网元的结构示意图。该策略管理网元可以包括接收单元1710、发送单元1720和处理单元1730。
其中，接收单元1710用于支持策略管理网元执行上述步骤S501、S1204、S1210、S1404、S1503和S1602，和/或用于本文所描述的技术的其他过程。发送单元1720用于支持策略管理网元执行上述步骤S502、S601、S602、S801、S1105、S1207、S1406、S1505和S1604，和/或用于本文所描述的技术的其他过程。处理单元1730用于支持策略管理网元执行上述步骤S701、S902、S1104、S1205、S1206、S1405、S1504和S1603，和/或用于本文所描述的技术的其他过程。
如图18所示，为本申请实施例提供的一种会话管理网元的结构示意图。该会话管理网元可以包括接收单元1810、发送单元1820和处理单元1830。
其中，接收单元1810用于支持会话管理网元执行上述步骤S901、S1108、S1201、S1304、S1403、S1406、S1505和S1604，和/或用于本文所描述的技术的其他过程。发送单元1820用于支持会话管理网元执行上述步骤S1109、S1110、S1111、S1208、S1209、S1210、S1211、S1306、S1306、S1308、S1404、S1407、S1408、S1409、S1506、S1507、S1508、S1605、S1606和S1607，和/或用于本文所描述的技术的其他过程。处理单元1830用于支持会话管理网元执行上述步骤S901、S902、S1001和S1305，和/或用于本文所描述的技术的其他过程。
如图19所示，为本申请实施例提供的一种能力开放网元的结构示意图。该能力开放网元可以包括接收单元1910、发送单元1920和处理单元1930。
其中，接收单元1910用于支持能力开放网元执行上述步骤S1101、S1105、S1111、S1201、S1211、S1301、S1308、S1401、S1409、S1501和S1508，和/或用于本文所描述的技术的其他过程。发送单元1920用于支持能力开放网元执行上述步骤S1103、S1108、S1112、S1204、S1212、S1304、S1309、S1403、S1410、S1503和S1509，和/或用于本文所描述的技术的其他过程。处理单元1930用于支持能力开放网元执行上述步骤S1102、S1106、S1107、S1202、S1203、S1302、S1303、S1402和S1502，和/或用于本文所描述的技术的其他过程。
需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
需要说明的是，上述发送单元(1720、1820和1920)和接收单元(1710、1810和1910)可以包括射频电路。具体的，网元可以通过射频电路进行无线信号的接收和发送。通常，射频电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等。此外，射频电路还可以通过无线通信和其他设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统、通用分组无线服务、码分多址、宽带码分多址、长期演进、电子邮件、短消息服务等。
对MB-UPF 440、应用服务器460、RAN等网元的结构，可以参考图17、图18和图19所示的结构示意图，本申请实施例不做赘述。
在一种可选的方式中，当使用软件实现数据传输时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地实现本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如软盘、硬盘、磁带)、光介质(例如DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
结合本申请实施例所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外，该ASIC可以位于探测装置中。当然，处理器和存储介质也可以作为分立组件存在于探测装置中。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。
在本申请所提供的几个实施例中，应该理解到，所揭露的用户设备和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (18)

1.一种多播会话的建立方法，其特征在于，所述方法包括：
策略控制网元接收来自会话管理网元的第一消息，所述第一消息包含多播会话的信息,所述多播会话的信息包含所述多播会话的质量要求信息，所述第一消息用于请求为所述多播会话做策略决策；
所述策略控制网元根据所述质量要求信息，获取所述多播会话的策略；
所述策略控制网元向所述会话管理网元发送第二消息，所述第二消息包含所述多播会话的策略。
2.根据权利要求1所述的方法，其特征在于，所述质量要求信息包括质量要求索引5QI信息。
3.根据权利要求1或2所述的方法，其特征在于，所述多播会话的策略用于规定建立服务质量流QoS flow的规则、授权的QoS规则、识别多播数据的规则或过滤多播数据的规则中的一项或多项。
4.根据权利要求3所述的方法，其特征在于，所述策略控制网元向所述会话管理网元发送所述第二消息，所述方法还包括：
所述策略控制网元根据所述多播会话的信息和会话管理网元的能力信息确定所述会话管理网元，所述会话管理网元的能力信息用于指示所述会话管理网元是否支持多播会话管理。
5.根据权利要求1或2所述的方法，其特征在于，所述第一消息还包含所述会话管理网元的标识信息。
6.根据权利要求1或2所述的方法，其特征在于，所述第一消息还包含业务标识信息，所述业务标识信息用于在多播传输过程中识别来自应用服务器的多播数据。
7.根据权利要求6所述的方法，其特征在于，所述业务标识信息包含应用服务器的IP地址和端口号。
8.根据权利要求1或2所述的方法，其特征在于，所述策略包含以下任意一项或多项：多播数据的标识信息、多播会话质量参数，所述多播数据的标识信息用于标识来自应用服务器的多播数据。
9.一种多播会话的建立方法，其特征在于，所述方法包括：
会话管理网元接收来自能力开放网元的多播会话的信息，所述多播会话的信息包含所述多播会话的质量要求信息；
所述会话管理网元向策略控制网元发送第一消息，所述第一消息用于请求为所述多播会话做策略决策，所述第一消息携带所述多播会话的信息。
10.根据权利要求9所述的方法，其特征在于，所述质量要求信息包括质量要求索引5QI信息。
11.根据权利要求9或10所述的方法，其特征在于，所述多播会话的策略用于规定建立QoS flow的规则、授权的QoS规则、识别多播数据的规则或过滤多播数据的规则中的一项或多项。
12.根据权利要求9或10所述的方法，其特征在于，所述第一消息还包含业务标识信息，所述业务标识信息用于在多播传输过程中识别来自应用服务器的多播数据。
13.根据权利要求12所述的方法，其特征在于，所述业务标识信息包含应用服务器的IP地址和端口号。
14.一种策略控制网元，其特征在于，所述策略控制网元包括：
存储器，用于存储计算机程序代码，所述计算机程序代码包括指令；
处理器，用于执行所述指令，使得所述策略控制网元执行如权利要求1-8任一项所述的多播会话的建立方法。
15.一种会话管理网元，其特征在于，所述会话管理网元包括：
存储器，用于存储计算机程序代码，所述计算机程序代码包括指令；
处理器，用于执行所述指令，使得所述会话管理网元执行如权利要求9-13任一项所述的多播会话的建立方法。
16.一种通信系统，其特征在于，所述通信系统包括：策略控制网元和会话管理网元；
所述策略控制网元，用于执行如权利要求1-8任一项所述的多播会话的建立方法；
所述会话管理网元，用于向所述策略控制网元发送所述第一消息，以及接收所述第二消息。
17.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理电路执行时实现如权利要求1-13中任一项所述的方法。
18.一种通信装置，其特征在于，包括：接收单元，发送单元和处理单元，
所述接收单元，用于接收来自会话管理网元的第一消息，所述第一消息包含多播会话的信息，所述多播会话的信息包含：所述多播会话的质量要求信息，所述第一消息用于请求为所述多播会话做策略决策；
所述处理单元，用于根据所述质量要求信息，获取所述多播会话的策略；
所述发送单元，用于向所述会话管理网元发送第二消息，所述第二消息包含所述多播会话的策略。
CN201980102026.8A 2019-11-08 2019-11-08 一种多播会话的建立方法及网络设备 Active CN114731460B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2019/116849 WO2021088051A1 (zh) 2019-11-08 2019-11-08 一种多播会话的建立方法及网络设备

Publications (2)

Publication Number Publication Date
CN114731460A CN114731460A (zh) 2022-07-08
CN114731460B true CN114731460B (zh) 2023-11-17

Family

ID=75849515

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980102026.8A Active CN114731460B (zh) 2019-11-08 2019-11-08 一种多播会话的建立方法及网络设备

Country Status (4)

Country Link
US (1) US20220263879A1 (zh)
EP (1) EP4044614A4 (zh)
CN (1) CN114731460B (zh)
WO (1) WO2021088051A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113068134B (zh) * 2020-01-02 2022-06-10 维沃移动通信有限公司 多播业务会话操作的方法、装置和通信设备
EP4135361A1 (en) * 2021-08-10 2023-02-15 Nokia Technologies Oy Policy control for broadcast session

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107995603A (zh) * 2016-10-27 2018-05-04 中兴通讯股份有限公司 一种能力开放实现方法及装置
CN108702724A (zh) * 2016-11-27 2018-10-23 Lg 电子株式会社 无线通信系统中的注销方法及其装置
CN109699013A (zh) * 2017-10-24 2019-04-30 华为技术有限公司 一种通信系统、通信方法及其装置
WO2019136128A1 (en) * 2018-01-03 2019-07-11 Convida Wireless, Llc Multicast and broadcast services in 5g networks for iot applications
WO2019154036A1 (zh) * 2018-02-12 2019-08-15 华为技术有限公司 QoS流处理方法、设备及系统
WO2019157893A1 (zh) * 2018-02-14 2019-08-22 华为技术有限公司 会话建立方法和设备
CN110169104A (zh) * 2017-01-05 2019-08-23 华为技术有限公司 具有组播和广播多媒体子系统能力的网络架构
CN110383877A (zh) * 2017-03-10 2019-10-25 华为技术有限公司 网络策略优化的系统和方法

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6845389B1 (en) * 2000-05-12 2005-01-18 Nortel Networks Limited System and method for broadband multi-user communication sessions
US20020119821A1 (en) * 2000-05-12 2002-08-29 Sanjoy Sen System and method for joining a broadband multi-user communication session
US9503470B2 (en) * 2002-12-24 2016-11-22 Fred Herz Patents, LLC Distributed agent based model for security monitoring and response
JP5612105B2 (ja) * 2009-10-02 2014-10-22 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ データ・サービスに対するスケーラブルなビデオ制御帯域幅の割り当て
US8934371B2 (en) * 2010-04-28 2015-01-13 Telefonaktiebolaget L M Ericsson (Publ) Monitoring broadcast and multicast streaming service
US10182465B2 (en) * 2014-06-03 2019-01-15 Telefonaktiebolaget Lm Ericsson (Publ) Handling of control interface failure in multicast transmissions via a cellular network
US9621938B2 (en) * 2014-09-10 2017-04-11 Ericsson Ab Advertisement targeting scheme in a multicast ABR environment based on switched video
US20160156691A1 (en) * 2014-12-01 2016-06-02 Microsoft Technology Licensing, Llc Session Awareness for Communication Sessions
US9577741B2 (en) * 2015-06-04 2017-02-21 Hughes Network Systems, Llc Multicast service delivery over high throughput satellite in a Ka spot-beam network
CN109769150B (zh) * 2017-11-09 2021-02-23 华为技术有限公司 一种传输组播业务的方法和设备
CN111406391A (zh) * 2017-11-16 2020-07-10 诺基亚通信公司 利用核心网络对无线电接入网络的多播/广播服务
US10932095B2 (en) * 2017-11-22 2021-02-23 Huawei Technologies Co., Ltd. Method and system for multicast and broadcast services
US11013052B2 (en) * 2018-01-15 2021-05-18 Huawei Technologies Co., Ltd. Methods and systems for multicast-broadcast session release and modification
CN117651306A (zh) * 2018-05-21 2024-03-05 华为技术有限公司 在会话中建立GBR QoS流的方法和装置
CN110662270B (zh) * 2018-06-28 2021-05-18 华为技术有限公司 通信方法及装置
CN113891255B (zh) * 2018-11-27 2023-04-11 华为技术有限公司 一种通信方法、装置及系统
CN113678423B (zh) * 2019-03-13 2024-09-06 交互数字专利控股公司 动态网络能力配置

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107995603A (zh) * 2016-10-27 2018-05-04 中兴通讯股份有限公司 一种能力开放实现方法及装置
CN108702724A (zh) * 2016-11-27 2018-10-23 Lg 电子株式会社 无线通信系统中的注销方法及其装置
CN110169104A (zh) * 2017-01-05 2019-08-23 华为技术有限公司 具有组播和广播多媒体子系统能力的网络架构
CN110383877A (zh) * 2017-03-10 2019-10-25 华为技术有限公司 网络策略优化的系统和方法
CN109699013A (zh) * 2017-10-24 2019-04-30 华为技术有限公司 一种通信系统、通信方法及其装置
WO2019080690A1 (zh) * 2017-10-24 2019-05-02 华为技术有限公司 一种通信系统、通信方法及其装置
WO2019136128A1 (en) * 2018-01-03 2019-07-11 Convida Wireless, Llc Multicast and broadcast services in 5g networks for iot applications
WO2019154036A1 (zh) * 2018-02-12 2019-08-15 华为技术有限公司 QoS流处理方法、设备及系统
WO2019157893A1 (zh) * 2018-02-14 2019-08-22 华为技术有限公司 会话建立方法和设备
CN110167190A (zh) * 2018-02-14 2019-08-23 华为技术有限公司 会话建立方法和设备

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
clarification on N6 traffic routing information for Ethernet type PDU session;HUAWEI等;《3GPP TSG-WG SA2 Meeting》;第S2-1908860卷;第5.6.7.1节 *
IPTV solution for WWC （S2-187085）;Huawei, HiSilicon;SA WG2 Meeting;全文 *
IPTV solution for WWC;HUAWEI等;《SA WG2 Meeting》;第S2-187085卷;全文 *

Also Published As

Publication number Publication date
WO2021088051A1 (zh) 2021-05-14
EP4044614A1 (en) 2022-08-17
US20220263879A1 (en) 2022-08-18
EP4044614A4 (en) 2022-10-19
CN114731460A (zh) 2022-07-08

Similar Documents

Publication Publication Date Title
US12069568B2 (en) Method and device for terminal attaching and creating home-routed PDU session in roaming environment supporting network slice
US20210112379A1 (en) Communication method and communications apparatus
US20200128614A1 (en) Session processing method and device
CN111526552A (zh) Ue执行的方法及ue、以及smf实体执行的方法及smf实体
CN113630783A (zh) 一种通信方法及装置
CN112584327B (zh) 一种更新用户面路径的方法、装置及系统
WO2017070838A1 (zh) 资源调度方法、基站、调度器、节目源服务器和系统
US20220263879A1 (en) Multicast session establishment method and network device
CN116530208A (zh) 一种通信方法、装置及系统
US11843997B2 (en) Network slicing framework for time-sensitive peer-to-peer networking
CN116868603A (zh) 针对af会话的外部参数提供的新方法
WO2024027436A1 (zh) 管理网络资源的方法、装置及系统
WO2023045472A1 (zh) 一种通信方法、装置及系统
US20220217005A1 (en) Network Slice Charging Method and Apparatus
WO2022213799A1 (zh) 一种多播业务的通信方法及装置
CN114424498B (zh) 数据传输方法、装置、系统和存储介质
WO2021139378A1 (zh) 通信方法和通信装置
CN116671137A (zh) 一种确定mec接入点的方法及装置
CN114915918B (zh) 一种通信方法及装置
WO2024074148A1 (zh) 通信方法、装置及系统
CN116156668A (zh) 数据传输方法及装置
KR20230051059A (ko) 무선 통신 시스템에서 최대 허용 비트율을 고려한 세션 연속성 지원 방법 및 장치
CN117641255A (zh) 广播安全通信的方法和装置
CN116866986A (zh) 通信方法及装置
CN117240826A (zh) 一种分配互联网协议地址的方法及通信装置

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
GR01 Patent grant
GR01 Patent grant