CN110557724B - 一种多播业务的数据传输方法以及相关设备 - Google Patents
一种多播业务的数据传输方法以及相关设备 Download PDFInfo
- Publication number
- CN110557724B CN110557724B CN201810568037.2A CN201810568037A CN110557724B CN 110557724 B CN110557724 B CN 110557724B CN 201810568037 A CN201810568037 A CN 201810568037A CN 110557724 B CN110557724 B CN 110557724B
- Authority
- CN
- China
- Prior art keywords
- network element
- multicast service
- request message
- terminal device
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
-
- 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
Abstract
本申请实施例公开了一种多播业务的数据传输方法以及相关设备和相关设备,用于解决现有技术中多播业务的数据包在5G系统中如何传输,多播业务的业务质量如何得到保障的问题。本申请实施例方法包括:第一网元接收来自于第一终端设备的第一请求消息,所述第一请求消息用于请求多播业务,所述第一请求消息包括所述第一终端设备的标识信息,和/或,所述多播业务的标识信息;所述第一网元获取所述多播业务对应的第一QoS策略,以使得在第二网元和第三网元之间的单播隧道上,根据所述第一QoS策略,传输所述多播业务的数据包。
Description
技术领域
本申请涉及通信领域,尤其涉及一种多播业务的数据传输方法以及相关设备。
背景技术
多播,也称组播,其相对于单播(unicast)和广播(broadcast),能够高效地解决一点对多点的传输和分发问题。在组播场景下,数据可沿特定路径被发送给一组用户,相同的组播数据在每一条链路上最多仅有一份。例如,对于一些业务如交互式网络电视(internetprotocol television,IPTV),服务器发往不同用户的报文内容是相同的,如图1a所示,在单播方式下,服务器要对不同的用户复制报文后,分别发往对应的用户;而在多播方式下,服务器只需要为每个加入多播组的下游路由设备发送一份报文,再由各级路由器进行设备粒度的报文复制,再发送给对应的用户。因此,对于接入点之上的上游网络,多播方式能够明显降低报文复制压力和对带宽的浪费。
在第4代移动通信(the 4th generation,4G)系统中,对于组播业务定义了多媒体广播多播业务(multimedia broadcast multicast service,MBMS)/演进的多媒体广播多播业务(evolved MBMS,eMBMS)标准,请参阅图1b,为一种可能的MBMS/eMBMS转发原理示意图,图中,MBMS/eMBMS网关(图中对应于eMBMS网关(eMBMS gateway,eMBMS-GW))创建多播隧道,且该多播隧道信息会在eMBMS-GW转发多播报文之前告知到加入该多播网的基站(evolved node B,eNB),使得eNB会接收对应多播隧道的报文。4G系统中转发多播业务报文的过程包括:1)组播平台发送用户组播报文;2)广播组播业务中心(broadcast/multicastservice center,BM-SC)转发从组播平台接收到的用户组播报文到加入组播组的MBMS/eMBMS网关设备上;3)eMBMS-GW包括控制面功能和用户面功能:在组播报文传输过程中,控制面功能为将创建的组播隧道信息通知给移动管理实体(mobility management entity,MME),用户面功能为将从BM-SC接收到的用户组播报文复制到创建的组播隧道中并向下行放下发送。
然而,第5代移动通信(the 5th generation,5G)系统如何支持多播技术还在研究中,特别是在固移融合的场景中,需要支持固定终端设备通过5G系统使用IPTV业务。此时,多播业务的数据包在5G系统中如何传输,多播业务的业务质量如何得到保障,以及如何对每个固定终端设备使用多播业务进行计费都需要进一步研究。
发明内容
本申请实施例提供了一种多播业务的数据传输方法以及相关设备,用于解决现有技术中多播业务的数据包在5G系统中如何传输,多播业务的业务质量如何得到保障的问题。
本申请实施例的第一方面提供了一种多播业务的数据传输方法,包括:第一网元接收来自于第一终端设备的第一请求消息,该第一请求消息用于指示第一终端设备请求多播业务,且,该第一请求消息包括第一终端设备的标识信息,和/或,多播业务的标识信息。第一网元接收到该第一请求消息后,获得与该多播业务对应的第一QoS策略,以使得在第二网元和第三网元之间的单播隧道上,可根据该第一QoS策略,传输该多播业务的数据包。本申请实施例中,通过第一网元获得的第一QoS策略,实现第二网元与第三网元之间的单播隧道在进行多播业务的数据包的转发时满足第一QoS策略,解决了现有技术中多播业务的数据包在第5代移动通信系统中如何传输,多播业务的业务质量如何得到保障的问题。
在一种可能的设计中,在本申请实施例第一方面的第一种实现方式中,该第一网元获取该多播业务对应的第一QoS策略包括:该第一网元向策略控制功能实体PCF发送QoS策略请求指示,其中,该QoS策略请求指示包括以下参数中的任意一种或者多种:单播隧道指示,该多播业务的标识信息,该多播组的标识信息,或,该多播组的地址信息;该第一网元接收该PCF发送的该第一QoS策略。本实现方式中,细化了第一网元如何从PCF侧获得该第一QoS策略,增强了本申请实施例的逻辑性。
在一种可能的设计中,在本申请实施例第一方面的第二种实现方式中,该第一网元获取该多播业务对应的第一QoS策略包括:该第一网元还可以将本地存储的多播业务对应的QoS策略作为第一QoS策略。本实现方式中,第一网元不仅可以从PCF侧获得第一QoS策略,还可以从本地获取该第一QoS策略,减少了网络中信令的交互,节约了网络资源。
在一种可能的设计中,在本申请实施例第一方面的第三种实现方式中,该方法还包括:该第一网元接收该PCF发送的该第一终端设备对应的该多播业务的第一计费策略,该第一计费策略为该PCF根据该第一终端设备的标识信息和该多播业务的标识信息获得。本实现方式中,第一网元不仅可以从PCF侧获得第一QoS策略,还可以获得第一计费策略,使得第二网元或者第三网元可以根据该第一计费策略为第一终端设备针对该多播业务进行计费。
在一种可能的设计中,在本申请实施例第一方面的第四种实现方式中,该第一网元获取该多播业务对应的第一QoS策略之后,该方法还包括:该第一网元向该第二网元发送第二请求消息,并向该第三网元发送第三请求消息,该第二请求消息包括该第一QoS策略,该第三请求消息包括该第一QoS策略。本实现方式中,第一网元获得第一QoS策略后,将该第一QoS策略通过第二请求消息告知给第二网元,通过第三请求消息告知给第三网元,以使得第二网元和第三网元之间的单播隧道根据该第一QoS策略传输多播业务的数据包。
在一种可能的设计中,在本申请实施例第一方面的第五种实现方式中,该第二请求消息还包括该第一计费策略,和/或,该第三请求消息还包括该第一计费策略。本实现方式中,第一网元还可将第一计费策略发送给第二网元和/或第三网元,使得第二网元或第三网元为第一终端设备对该多播业务进行计费或者统计。
在一种可能的设计中,在本申请实施例第一方面的第六种实现方式中,该第一网元向该第二网元发送第二请求消息,并向该第三网元发送第三请求消息之前,该方法还包括:该第一网元配置该单播隧道在该第二网元侧的标识信息和该单播隧道在该第三网元侧的标识信息;该第二请求消息还包括该单播隧道在该第三网元侧的标识信息,该第三请求消息还包括该单播隧道在该第二网元侧的标识信息。本实现方式中,第一网元还可以配置单播隧道在第二网元侧和第三网元侧的标识信息,并分别告知第三网元和第二网元,以实现第二网元和第三网元之间的单播隧道的建立。
在一种可能的设计中,在本申请实施例第一方面的第七种实现方式中,该第一网元向第二网元发送第二请求消息,并向第三网元发送第三请求消息包括:该第一网元向该第二网元发送该第二请求消息,该第二请求响应消息包括该单播隧道在该第三网元侧的标识信息;该第一网元接收该第二网元发送的第二请求响应消息,该第二请求响应消息包括该单播隧道在该第二网元侧的标识信息;该第一网元向该第三网元发送该第三请求消息,该第三请求消息包括该单播隧道在该第二网元侧的标识信息;该第一网元接收该第三网元发送的第三请求响应消息。本实现方式中,在建立第二网元与第三网元之间的单播隧道时,可以由各网元配置其在单播隧道侧的标识信息,并由第一网元转发给对侧网元,降低了第一网元的工作负荷。
在一种可能的设计中,在本申请实施例第一方面的第八种实现方式中,该第一网元向第二网元发送第二请求消息,并向第三网元发送第三请求消息包括:该第一网元向该第二网元发送该第二请求消息;该第一网元接收该第二网元发送的第二请求响应消息,该第二请求响应消息包括该单播隧道在该第二网元侧的标识信息;该第一网元向该第三网元发送该第三请求消息,该第三请求消息包括该单播隧道在该第二网元侧的标识信息;该第一网元接收该第三网元发送的第三请求响应消息,该第三请求响应消息包括该单播隧道在该第三网元侧的标识信息;该第一网元向该第二网元发送该单播隧道在该第三网元侧的标识信息。本实现方式中,在建立第二网元与第三网元之间的单播隧道时,可以由各网元配置其在单播隧道侧的标识信息,并由第一网元转发给对侧网元,增加了本申请实施例的可实现方式。
在一种可能的设计中,在本申请实施例第一方面的第九种实现方式中,该第一网元根据该第一请求消息获得第一QoS策略之后,该方法还包括:该第一网元接收第二终端设备发送的第四请求消息,该第四请求消息用于请求该多播业务;该第一网元向该第二网元发送第五请求消息,该第五请求消息用于指示该第二终端设备请求该多播业务,以使得该第二网元将该第二终端设备和该多播业务关联。本实现方式中,在单播隧道建立好后,又收到其他终端设备发起的该多播业务请求的场景,增加了本申请实施例的可适用场景。
在一种可能的设计中,在本申请实施例第一方面的第十种实现方式中,该第二网元和该第三网元都为UPF。本实现方式中,在一种可能的场景中,第二网元和第三网元都是UPF,使得本申请实施例的可应用网络框架更加具体化。
在一种可能的设计中,在本申请实施例第一方面的第十一种实现方式中,该方法还包括:该第一网元接收该第三网元或该第二网元发送的对应于该多播业务的统计信息,该统计信息包括收视率统计信息和/或者各终端设备的流量统计信息,该各终端设备与该多播业务关联。本实现方式中,第二网元或者第三网元为每个请求该多播业务的终端设备进行单独收费,并可以统计终端设备关于该多播业务的流量和请求该多播业务的数量,并计算收视率,以将得到的统计信息发送给第一网元,使得第一网元可将该统计信息上报给PCF,则PCF可以根据该统计信息更加灵活的做策略控制。
在一种可能的设计中,在本申请实施例第一方面的第十二种实现方式中,该第一网元接收第一终端设备发送的第一请求消息包括:该第一网元接收经由该下级UPF转发的该第一终端设备发送的第一请求消息;或,该第一网元接收经由接入和移动性管理功能实体AMF转发的该第一终端设备发送的第一请求消息。本实现方式中,提供了多种第一网元接收第一请求消息的方式,可以通过用户面接收,也可以通过控制面接收,增加了本申请实施例的可实现方式。
在一种可能的设计中,在本申请实施例第一方面的第十三种实现方式中,该第二网元为UPF,该第三网元为接入网AN网元。本实现方式中,在一种可能的场景中,第二网元为UPF,第三网元为AN网元,使得本申请实施例的可应用网络框架更加具体化。
在一种可能的设计中,在本申请实施例第一方面的第十四种实现方式中,该第一网元接收终端设备发送的第一请求消息包括:该第一网元接收经由接入和移动性管理功能实体AMF转发的该终端设备发送的第一请求消息;或,该第一网元接收经由该AN和该AMF转发的该终端设备发送的第一请求消息。本实现方式中,提供了多种第一网元接收第一请求消息的方式,可以通过用户面接收,也可以通过控制面接收,增加了本申请实施例的可实现方式。
在一种可能的设计中,在本申请实施例第一方面的第十五种实现方式中,该第一网元接收第一用户设备终端设备发送的第一请求消息之后,该方法还包括:该第一网元确定使用当前协议数据单元PDU会话发送该多播业务的数据包。本实现方式中,第一网元还可直接将当前PDU会话作为第二网元与第三网元之间的单播隧道,减少了整个网络中的信令发送,节约了网络资源。
本申请实施例的第二方面提供了一种多播业务的数据传输方法,包括:第二网元获得第一服务质量QoS策略;该第二网元根据该第一QoS策略在单播隧道上传输多播业务的数据包,该单播隧道为该第二网元与第三网元之间的隧道,该第一QoS策略与该多播业务对应。本申请实施例中,第二网元通过获得的第一QoS策略,实现第二网元与第三网元之间的单播隧道在进行多播业务的数据包的转发时满足第一QoS策略,解决了现有技术中多播业务的数据包在5G系统中如何传输,多播业务的业务质量如何得到保障的问题。
在一种可能的设计中,在本申请实施例第二方面的第一种实现方式中,该第二网元获得第一QoS策略包括:该第二网元接收第一网元发送的第一请求消息,该第一请求消息包括该第一QoS策略,该第一QoS策略由该第二网元根据第一用户设备终端设备发送的第二请求消息获得,该第二请求消息用于请求加入该多播业务。本实现方式中,第一网元获得第一QoS策略后,将该第一QoS策略通过第一请求消息告知给第二网元,以使得第二网元和第三网元之间的单播隧道根据该第一QoS策略传输多播业务的数据包。
在一种可能的设计中,在本申请实施例第二方面的第二种实现方式中,该第二网元根据该第一QoS策略在单播隧道上传输该多播业务的数据包之前,该方法还包括:该第二网元和该第三网元建立该单播隧道。本实现方式中,第二网元与第三网元建立对应于多播业务的单播隧道,使得根据第一QoS策略传输该多播业务的数据包。
在一种可能的设计中,在本申请实施例第二方面的第二种实现方式中,该第二网元和该第三网元建立该单播隧道包括:响应于该第一请求消息,该第二网元向该第一网元发送第一请求响应消息,该第一请求响应消息包括该单播隧道在该第二网元侧的标识信息,以使得该第一网元将该单播隧道在该第二网元侧的标识信息和该第一QoS策略发送给该第三网元;该第二网元接收该第一网元发送的该单播隧道在该第三网元侧的标识信息。本实现方式中,在建立第二网元与第三网元之间的单播隧道时,可以由各网元配置其在单播隧道侧的标识信息,并由第一网元转发给对侧网元,降低了第一网元的工作负荷。
在一种可能的设计中,在本申请实施例第二方面的第三种实现方式中,该第一请求消息还包括该单播隧道在该第三网元侧的标识信息。本实现方式中,第一网元还可以配置单播隧道在第二网元侧和第三网元侧的标识信息,并分别告知第三网元和第二网元,以实现第二网元和第三网元之间的单播隧道的建立。
在一种可能的设计中,在本申请实施例第二方面的第四种实现方式中,该方法还包括:该第二网元接收该第一网元发送的该第一终端设备对应的该多播业务的计费策略。本实现方式中,第二网元接收第一网元发送的计费策略,使得第二网元可以为每个请求该多播业务的终端设备进行单独收费。
在一种可能的设计中,在本申请实施例第二方面的第五种实现方式中,当该第二网元用于与该第一终端设备通信时,该方法还包括:该第二网元生成对应于该多播业务的统计信息,该统计信息包括收视率统计信息和/或各终端设备的流量统计信息;该第二网元将该统计信息发送给该第一网元,或者,接入和移动性管理功能实体AMF。本实现方式中,第二网元可以统计终端设备关于该多播业务的流量和请求该多播业务的数量,并计算收视率,并将获得的统计信息发送给第一网元或者AMF。
在一种可能的设计中,在本申请实施例第二方面的第六种实现方式中,当该第二网元用于与多播服务器通信时,该方法还包括:该第二网元接收该第一网元发送的第二请求消息,该第二请求消息包括第二终端设备的标识信息和该多播业务的标识信息,该第二请求消息用于指示该第二终端设备加入该多播业务;该第二网元将该第二终端设备的标识信息和该多播业务的标识信息关联。本实现方式中,在单播隧道建立好后,又收到其他终端设备发起的该多播业务请求的场景,则第二网元将该其他终端设备与多播业务关联,增加了本申请实施例的可适用场景。
在一种可能的设计中,在本申请实施例第二方面的第七种实现方式中,该方法还包括:该第二网元根据各终端设备的计费策略生成对应于该各终端设备的计费信息,该各终端设备与该多播业务关联。本实现方式中,第二网元根据第一网元发送的计费策略,为每个请求该多播业务的终端设备进行单独收费。
本申请实施例的第三方面提供了一种网元,该网元应用于第一网元侧,包括:第一收发单元,用于接收来自于第一终端设备的第一请求消息,该第一请求消息用于请求多播业务,该第一请求消息包括第一终端设备的标识信息,和/或,多播业务的标识信息;获得单元,用于获取该多播业务对应的第一服务质量QoS策略,以使得在第二网元和第三网元之间的单播隧道上,根据该第一QoS策略,传输该多播业务的数据包。本申请实施例中,通过第一网元获得的第一QoS策略,实现第二网元与第三网元之间的单播隧道在进行多播业务的数据包的转发时满足第一QoS策略,解决了现有技术中多播业务的数据包在5G系统中如何传输,多播业务的业务质量如何得到保障的问题。
在一种可能的设计中,在本申请实施例第三方面的第一种实现方式中,该获得单元具体用于,向策略控制功能实体PCF发送QoS策略请求消息,该QoS策略请求消息包括以下参数中的任意一种或者多种:单播隧道指示,该多播业务的标识信息,该多播组的标识信息,或,该多播组的地址信息;接收该PCF发送的该第一QoS策略。本实现方式中,细化了获得单元如何从PCF侧获得该第一QoS策略,增强了本申请实施例的逻辑性。
在一种可能的设计中,在本申请实施例第三方面的第二种实现方式中,该获得单元具体用于,将本地存储的该多播业务对应的QoS策略作为第一QoS策略。本实现方式中,第一网元不仅可以通过获得单元从PCF侧获得第一QoS策略,还可以通过获得单元从本地获取该第一QoS策略,减少了网络中信令的交互,节约了网络资源。
在一种可能的设计中,在本申请实施例第三方面的第三种实现方式中,该第一网元还包括:第二收发单元,该获得单元还用于接收该PCF发送的该第一终端设备对应的该多播业务的第一计费策略,该第一计费策略为该PCF根据该第一终端设备的标识信息和该多播业务的标识信息获得;该第二收发单元用于向该第二网元和/或该第三网元发送该第一计费策略。本实现方式中,获得单元不仅可以从PCF侧获得第一QoS策略,还可以获得第一计费策略,使得第二网元或者第三网元可以根据该第一计费策略为第一终端设备针对该多播业务进行计费。
在一种可能的设计中,在本申请实施例第三方面的第四种实现方式中,该第一收发单元还用于:接收第二终端设备发送的第二请求消息,该第二请求消息用于请求该多播业务;向该第二网元发送第三请求消息,该第三请求消息用于指示该第二终端设备请求该多播业务,以使得该第二网元将该第二终端设备和该多播业务关联。本实现方式中,在单播隧道建立好后,又收到其他终端设备发起的该多播业务请求的场景,增加了本申请实施例的可适用场景。
在一种可能的设计中,在本申请实施例第三方面的第五种实现方式中,该第二请求消息还包括该第一计费策略,和/或,该第三请求消息还包括该第一计费策略。本实现方式中,第二收发单元还可将第一计费策略发送给第二网元和/或第三网元,使得第二网元或第三网元为第一终端设备对该多播业务进行计费或者统计。
在一种可能的设计中,在本申请实施例第一方面的第六种实现方式中,该第一网元还包括:配置单元,用于配置该单播隧道在该第二网元侧的标识信息和该单播隧道在该第三网元侧的标识信息;该第二请求消息还包括该单播隧道在该第三网元侧的标识信息,该第三请求消息还包括该单播隧道在该第二网元侧的标识信息。本实现方式中,配置单元还可以配置单播隧道在第二网元侧和第三网元侧的标识信息,并分别告知第三网元和第二网元,以实现第二网元和第三网元之间的单播隧道的建立。
在一种可能的设计中,在本申请实施例第一方面的第七种实现方式中,该第二收发单元具体用于:向该第二网元发送该第二请求消息,该第二请求响应消息包括该单播隧道在该第三网元侧的标识信息;接收该第二网元发送的第二请求响应消息,该第二请求响应消息包括该单播隧道在该第二网元侧的标识信息;向该第三网元发送该第三请求消息,该第三请求消息包括该单播隧道在该第二网元侧的标识信息;接收该第三网元发送的第三请求响应消息。本实现方式中,在建立第二网元与第三网元之间的单播隧道时,可以由各网元配置其在单播隧道侧的标识信息,并由第一网元转发给对侧网元,降低了第一网元的工作负荷。
在一种可能的设计中,在本申请实施例第一方面的第八种实现方式中,该第二收发单元具体用于:向该第二网元发送该第二请求消息;接收该第二网元发送的第二请求响应消息,该第二请求响应消息包括该单播隧道在该第二网元侧的标识信息;向该第三网元发送该第三请求消息,该第三请求消息包括该单播隧道在该第二网元侧的标识信息;接收该第三网元发送的第三请求响应消息,该第三请求响应消息包括该单播隧道在该第三网元侧的标识信息;向该第二网元发送该单播隧道在该第三网元侧的标识信息。本实现方式中,在建立第二网元与第三网元之间的单播隧道时,可以由各网元配置其在单播隧道侧的标识信息,并由第一网元转发给对侧网元,增加了本申请实施例的可实现方式。
在一种可能的设计中,在本申请实施例第三方面的第九种实现方式中,该第三收发单元还用于:接收该第三网元或第二网元发送的对应于该多播业务的统计信息,该统计信息包括收视率统计信息和/或者各终端设备的流量统计信息,该各终端设备与该多播业务关联。本实现方式中,第二网元或者第三网元为每个请求该多播业务的终端设备进行单独收费,并可以统计终端设备关于该多播业务的流量和请求该多播业务的数量,并计算收视率。
在一种可能的设计中,在本申请实施例第三方面的第十种实现方式中,该第一网元还包括:确定单元,用于确定使用当前协议数据单元PDU会话发送该多播业务的数据包。本实现方式中,确定单元还可直接将当前PDU会话作为第二网元与第三网元之间的单播隧道,减少了整个网络中的信令发送,节约了网络资源。
在一种可能的设计中,在本申请实施例第一方面的第十一种实现方式中,该第二网元和该第三网元都为UPF。本实现方式中,在一种可能的场景中,第二网元和第三网元都是UPF,使得本申请实施例的可应用网络框架更加具体化。
在一种可能的设计中,在本申请实施例第一方面的第十二种实现方式中,该第二网元为UPF,该第三网元为接入网AN网元。本实现方式中,在一种可能的场景中,第二网元为UPF,第三网元为AN网元,使得本申请实施例的可应用网络框架更加具体化。
本申请实施例的第四方面提供了一种网元,该网元应用于第二网元侧,包括:获得单元,用于获得第一服务质量QoS策略;传输单元,用于根据该第一QoS策略在单播隧道上传输多播业务的数据包,该单播隧道为该第二网元与第三网元之间的隧道,该第一QoS策略与该多播业务对应。本申请实施例中,传输单元通过获得单元获得的第一QoS策略,实现第二网元与第三网元之间的单播隧道在进行多播业务的数据包的转发时满足第一QoS策略,解决了现有技术中多播业务的数据包在5G系统中如何传输,多播业务的业务质量如何得到保障的问题。
在一种可能的设计中,在本申请实施例第四方面的第一种实现方式中,该获得单元具体用于接收第一网元发送的第一请求消息,该第一请求消息包括该第一QoS策略,该第一QoS策略由该第二网元根据第一终端设备发送的第二请求消息获得,该第二请求消息用于请求该多播业务。本实现方式中,第一网元获得第一QoS策略后,将该第一QoS策略通过第一请求消息告知给第二网元的获得单元,以使得第二网元和第三网元之间的单播隧道根据该第一QoS策略传输多播业务的数据包。
在一种可能的设计中,在本申请实施例第四方面的第二种实现方式中,该获得单元还用于:响应于该第一请求消息,向该第一网元发送第一请求响应消息,该第一请求响应消息包括该单播隧道在该第二网元侧的标识信息,以使得该第一网元将该单播隧道在该第二网元侧的标识信息和该第一QoS策略发送给该第三网元;接收该第一网元发送的该单播隧道在该第三网元侧的标识信息。本实现方式中,在建立第二网元与第三网元之间的单播隧道时,可以由各网元配置其在单播隧道侧的标识信息,并由第一网元转发给对侧网元,降低了第一网元的工作负荷。
在一种可能的设计中,在本申请实施例第四方面的第三种实现方式中,该获得单元还用于:接收该第一网元发送的该第一终端设备对应的该多播业务的计费策略。本实现方式中,获得单元接收第一网元发送的计费策略,使得第二网元可以为每个请求该多播业务的终端设备进行单独收费。
在一种可能的设计中,在本申请实施例第四方面的第四种实现方式中,该第二网元还包括:关联单元,该获得单元还用于,接收该第一网元发送的第三请求消息,该第三请求消息用于指示第二终端设备请求该多播业务;该关联单元,用于将该第二终端设备和该多播业务关联。本实现方式中,在单播隧道建立好后,又收到其他终端设备发起的该多播业务请求的场景,则关联单元将该其他终端设备与多播业务关联,增加了本申请实施例的可适用场景。
在一种可能的设计中,在本申请实施例第四方面的第五种实现方式中,该第二网元还包括:生成单元,该生成单元,用于生成对应于该多播业务的统计信息,该统计信息包括收视率统计信息和/或各终端设备的流量统计信息;该收发单元,还用于将该统计信息发送给该第一网元,或者,接入和移动性管理功能实体AMF。本实现方式中,生成单元可以统计终端设备关于该多播业务的流量和请求该多播业务的数量,并计算收视率,并将获得的统计信息发送给第一网元或者AMF。
在一种可能的设计中,在本申请实施例第四方面的第六种实现方式中,该生成单元还用于:根据各终端设备对应的该多播业务的计费策略生成该各终端设备的计费信息,该各终端设备与该多播业务关联。本实现方式中,生成单元根据第一网元发送的计费策略,为每个请求该多播业务的终端设备进行单独收费。
本申请实施例的第五方面提供了一种通信设备,该通信设备具有实现上述方法设计中第一网元行为或者第二网元行为的功能。该功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。该模块可以是软件和/或硬件。
在一种可能的实现方式中,该通信设备包括存储单元、处理单元以及通信单元。
其中,存储单元,用于存储该通信设备所需的程序代码和数据;处理单元,用于调用该程序代码,对该通信设备的动作进行控制管理;通信单元,用于支持通信设备与其他设备的通信。
在一个可能的实现方式中,该通信设备的结构中包括处理器、通信接口、存储器和总线,其中,通信接口、处理器以及存储器通过总线相互连接;通信接口用于支持通信设备与其他设备的通信,该存储器用于存储该通信设备所需的程序代码和数据,处理器用于调用该程序代码,支持第一网元或者第二网元执行如上述方法中相应的功能。
本申请实施例的第六方面提供了一种网元,该网元具有实现上述方法实施例中第一网元或者第二网元的功能。该功能可以通过硬件实现,也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
本申请实施例的第七方面提供了一种网元,包括:处理器、存储器、总线、发射器和接收器;该存储器用于存储计算机执行指令,该处理器与该存储器通过该总线连接,当该网元运行时,该处理器执行该存储器存储的该计算机执行指令,以使该网元执行如上述第一方面或第二方面中任意一项的多播业务的数据传输方法。
本申请实施例的第八方面提供了一种装置,该装置包括存储器,该存储器用于存储指令。当存储器存储的指令被处理器执行时,支持处理器实现上述第一网元或者第二网元执行上述方法中相应的功能,例如发送或处理上述方法中所涉及的数据和/或信息。该装置可以通过芯片实现,也可以通过芯片和其他分立器件来实现。
本申请实施例的第九方面提供了一种系统,该系统包括前述第一方面的第一网元和第二方面的第二网元,或者,包括前述第三方面的第一网元和第四方面的第二网元。
本申请实施例的第十方面提供了一种计算机可读存储介质,该计算机可读存储介质中存储有指令,当其在计算机上运行时,使得计算机执行上述各方面的方法。
本申请实施例的第十一方面提供了一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述各方面的方法。
从以上技术方案可以看出,本申请实施例具有以下优点:第一网元接收来自于第一终端设备的第一请求消息,该第一请求消息用于请求多播业务;该第一网元根据该第一请求消息获得第一服务质量QoS策略,该第一QoS策略与该多播业务对应,以使得在第二网元和第三网元之间的单播隧道上,根据该第一QoS策略,传输该多播业务的数据包。本申请实施例中,通过第一网元获得的第一QoS策略,实现第二网元与第三网元之间的单播隧道在进行多播业务的数据包的转发时满足第一QoS策略,解决了现有技术中多播业务的数据包在5G系统中如何传输,多播业务的业务质量如何得到保障的问题。
附图说明
图1a为一种可能的单播方式和多播方式的报文发送示意图;
图1b为一种可能的MBMS/eMBMS转发原理示意图;
图2为一种可能的5G通信网络的基本架构图;
图3为一种可能的5G通信网络的系统架构图;
图4为本申请实施例提供的一种可能的多播业务的数据传输方法的实施例示意图;
图5为一种可能的PDU会话及策略控制会话的建立流程图;
图6为本申请实施例提供的另一可能的多播业务的数据传输方法的实施例示意图;
图7为本申请实施例提供的另一可能的多播业务的数据传输方法的实施例示意图;
图8为本申请实施例提供的另一可能的多播业务的数据传输方法的实施例示意图;
图9为本申请实施例提供的另一可能的多播业务的数据传输方法的实施例示意图;
图10为本申请实施例提供的一种可能的第一网元的实施例示意图;
图11为本申请实施例提供的一种可能的第二网元的实施例示意图;
图12为本申请实施例提供的一种可能的第一网元的结构示意图;
图13为本申请实施例提供的另一可能的第二网元的结构示意图。
具体实施方式
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。
本申请实施例提供一种多播业务的数据传输方法和相关设备,用于解决现有技术中多播业务的数据包在5G系统中如何传输,多播业务的业务质量如何得到保障的问题。
应理解,本申请实施例可以应用于5G通信网络架构,也可应用于其他网络架构,具体本申请实施例中不作限定。下面对5G通信网络架构进行简单介绍,请参阅图2,图2为一种可能的5G通信网络的基本架构图。在图2中,终端通过接入网接入到核心网,其中,终端可以是用户设备(User Equipment,UE),接入网可以是无线接入网(Radio Access Network,RAN),核心网可以包括控制面网元和用户面网元等,且控制面网元包括会话管理功能实体(Session Management Function,SMF),用户面网元包括用户面功能实体(user planefunction,UPF)。
在该网络架构中,应用功能实体(Application Function,AF)主要负责传递应用侧对网络侧的需求,例如服务质量(Quality of Service,Qos)需求等。
策略控制功能实体(Policy Control Function,PCF)主要负责对会话和业务的计费规则、Qos、移动性等策略的控制。
会话管理功能实体(Session Management Function,SMF)主要负责会话关联、PCF下发的控制策略的执行、UPF的选择、UE的IP地址分配等会话管理工作;同时SMF负责与UPF通过通信接口N4进行通信,将报文处理的规则下发到UPF,建立数据传输的用户面通道,其中报文处理的规则需要SMF的参数配置来实现,并将该参数通过NG4接口传递给用户面网元。
接入与移动性管理功能实体(Acess and Mobility Management Function,AMF)主要负责接入及移动性管理、接入鉴权/授权等接入和移动性管理工作。
用户面功能实体(user plane function,UPF),主要负责分组数据包的转发、QoS控制、基于会话/流级计费信息统计、带宽限制等工作。
下一代接入网((Next Generation Access Network,NG AN),对应5G通信网络中的不同接入网。
下一代终端(Next Generation User Equipment,NG UE),对应5G通信网络中的不同终端。
示例性的,在图2所示的5G通信网络的基本架构中,支持终端通过无线技术使用N2和N3接口接入核心网络侧(5G core network);也支持终端通过固定宽带接入网络使用N2和N3接口接入核心网络,此场景中,图2的UE由固定家庭网关(residential gateway,RG)代替,(R)AN由接入网关功能实体(access gateway function,RGF)代替。
应理解,图2中策略控制功能实体,会话管理功能实体,用户面功能实体仅是一个名字,名字本身对实体不构成限定,例如,该“策略控制功能实体”还可能被替换为“策略控制功能”或其他名字;“会话管理功能实体”也有可能被替换为“会话管理功能”或其他名字,而且,该策略控制功能实体可以对应一个包括除了策略控制功能外,还有其他功能的实体,会话管理功能实体可以对应一个包括除了会话管理功能外,还有其他功能的实体,用户面功能实体可以对应一个包括除了用户面功能外,还有其他功能的实体,在此进行统一说明,以下不再赘述。
上述网络架构中的任意一种功能节点或网元,具体实现中,可能由一个实体设备实现,也可由多个实体设备共同实现,本申请实施例对此不作具体限定。即,可以理解的是,上述图2中的任意一种功能节点或者网元,都可能是实体设备内的一个逻辑功能模块,也可能是由多个实体设备组成的一个逻辑功能模块,本申请实施例对此不作具体限定。
为了使接入5G核心网的终端也能够使用多播业务,如图3所示,可以在核心网的两级用户面功能(user plane function,UPF)网元即UPF1和UPF2之间,或者在接入网(accessnetwork,AN)和UPF2之间建立设备粒度的单播隧道来传递多播业务的数据包,其中,多播数据包在UPF1或者AN进行复制,再发给各用户设备(user equipment,UE)。示例性的,本申请实施例中,单播隧道是用来传输某一种或多种多播业务数据包的隧道,下行数据包将被发往一个或多个用户设备。当多个用户设备订阅同一种多播业务时,该多播业务的数据包在单播隧道内只需要传播一次。
基于上述通信网络架构如5G等,本申请实施例提供了一种多播业务的数据传输方法。为便于理解,以图3所示的系统架构为例,对本申请实施例的多播业务的数据传输方法进行简要说明:SMF接收到来自于UE的多播业务请求,SMF判断需要为此多播业务建立单播隧道,并按照PCF下发的单播隧道的QoS策略建立单播隧道。当单播隧道建立后,又有其他UE发起该多播业务的请求时,则SMF通知UPF2有其他UE请求该多播业务,使得UPF2将该其他UE与该多播业务的单播隧道关联,以在使用该单播隧道传输多播业务的数据包时,保障多播业务的业务质量。
如图3所示,由于单播隧道可以在两级UPF即UPF1和UPF2之间,也可以在AN和UPF2之间,或者UE发送多播业务请求时,单播隧道可能未建立,也可能已经建立,因此本申请实施例中多播业务的数据传输方法应用于多种场景。举例说明如下:
当收到多播业务的请求时,
场景1:需要在两级UPF之间建立支持QoS策略的单播隧道,该QoS策略与多播业务对应;
场景2:两级UPF之间的单播隧道已建立,且支持QoS策略;
场景3:需要在接入网和UPF之间建立支持QoS策略的单播隧道;
场景4:接入网和UPF之间的单播隧道已建立,且支持QoS策略;
场景5:将UE和UPF之间已建立的协议数据单元(Protocol Data Unit,PDU)会话作为单播隧道。
下面结合具体的实施例对上述各种场景进行具体说明。
应理解的,本申请实施例可应用于多种架构,为便于描述,将本申请中用于接收多播业务的请求并获得与该多播业务对应的QoS策略的网元称为第一网元,例如,在5G架构中,第一网元可为SMF。并将单播隧道两端的网元称为第二网元和第三网元,例如,在场景1~2中,第二网元和第三网元均为UPF,在场景3~5中,第二网元和第三网元为接入网和UPF。为便于区分,设第二网元主要用于与多播服务器通信,第三网元主要用于与终端设备通信,具体地,在图3中,第二网元为UPF2,第三网元为UPF1;或者,第二网元为UPF2,第三网元为AN。
为便于描述,本实施例中,以第一网元为SMF,第二网元为UPF2,第三网元为UPF1为例,结合图4所示的步骤来具体说明本申请实施例基于场景1提供的一种可能的多播业务的数据传输方法,包括:
401、第一终端设备与UPF1建立PDU会话。
基于本实施例可应用的网络架构如5G网络架构,当终端设备附着5G网络后,将会触发一个或多个PDU会话及策略控制会话的建立,下面对5G网络中PDU会话及策略控制会话的建立流程进行简单介绍,请参阅图5,PDU会话及策略控制会话的建立流程包括:
终端设备通过AN发送PDU会话建立请求(PDU session establishment request)到AMF;
AMF选择为该PDU会话建立请求对应的PDU会话提供服务的SMF,保存该SMF与该PDU会话的对应关系,并将该PDU会话建立请求发送至该SMF;
SMF为终端设备选择相应的UPF,通过该UPF建立用户面传输路径,并为该终端设备分配IP地址,与此同时,SMF还会向PCF发送策略控制会话建立请求;
而在策略控制会话建立的过程中,SMF会保存该策略控制会话与PDU会话的对应关系,AF与PCF之间还会建立AF会话,然后由PCF存储该AF会话与该策略控制会话的对应关系。
因此,通过上述方式或其他方式实现第一终端设备与第三网元之间PDU会话的建立。
示例性的,本申请实施例中,第一终端设备可以为UE,例如具有无线通信功能的手持设备、车载设备、可穿戴设备(如智能手表、智能手环等),或者,第一终端设备可以为客户终端设备(customer premise equipment,CPE)等,具体本申请不做限定。
402、第一终端设备向SMF发送第一请求消息。
当第一终端设备需要请求多播业务时,第一终端设备向SMF发送第一请求消息,该第一请求消息用于指示该第一终端设备请求多播业务。其中,该第一请求消息可包括第一终端设备的标识信息和/或多播业务的标识信息。多播业务的标识信息可以是该多播业务所对应的数据网络标识信息,也可以是多播业务的标识信息,或多播业务对应的多播组的标识信息,或者,多播组的地址信息。例如,该第一请求消息中可以包括第一终端设备的标识信息和该多播业务所对应的数据网络标识信息。或者可以包括第一终端设备的标识信息和多播地址信息。
示例性的,第一终端设备向SMF发送第一请求消息的方式有多种,包括:
方式1:通过用户面发送;
示例性的,第一终端设备从用户面发送因特组网管理协议加入(internet groupmanagement protocol join,IGMP Join)消息到UPF1,该IGMP Join消息中携带第一请求消息的参数。UPF1接收到该IGMP Join消息后,将IGMP Join消息携带的第一请求消息的参数发送到SMF。可选的,UPF1还可直接将来自第一终端设备的IGMP Join消息发送给SMF。
方式2:通过控制面发送。
示例性的,第一终端设备从控制面发送第一请求消息到AMF,具体地,第一终端设备可以在PDU会话修改请求消息(PDU session modification request)中携带第一请求消息。AMF将该第一请求消息发送给SMF。示例性的,第一终端设备也可以在其它非接入层(non-access stratum,NAS)消息中携带第一请求消息,具体不做限定。
其中,该第一请求消息可以为网络协议电视事件报告(internet protocoltelevision event report,IPTV event report)消息,也可以是其他现有消息或者新消息,具体此处不做限定。
403、SMF确定需要建立多播业务对应的单播隧道。
SMF接收到该第一请求消息后,可以根据该第一请求消息判断是否存在该多播业务对应的单播隧道。当不存在该多播业务对应的单播隧道时,SMF确定需要建立该多播业务对应的单播隧道,以传输多播业务的数据包。
可选的,SMF还可以选择一个UPF即UPF2,与UPF1建立单播隧道。其中,SMF选择UPF2的方式有多种,例如,在支持访问该多播业务的多个UPF中,选择与第一终端设备的物理距离最短的UPF作为UPF2,或者选择负载较轻的UPF作为UPF2等。因此SMF选择UPF2的方式具体此处不做限定。
404、SMF向PCF发送QoS策略请求消息。
当SMF确定需要建立多播业务对应的单播隧道后,SMF向PCF发送QoS策略请求消息以请求用于建立单播隧道的第一QoS策略。该QoS策略请求消息包括单播隧道指示和/或多播业务的标识信息。多播业务的标识信息可以是多播业务的标识,也可以是该多播业务所对应的数据网络标识,或多播组的标识信息,或多播组的地址信息,具体此处不做限定。例如,该QoS策略请求消息中可以包括单播隧道指示;或者可以包括多播地址;或者可以包括单播隧道指示和多播地址。
可选的,当SMF上已经有该多播业务对应的QoS策略时,则SMF可以不向PCF发送QoS策略请求消息,而使用本地存储的该多播业务对应的QoS策略作为第一QoS策略,因此本申请实施例中,SMF获得第一QoS策略的方式具体此处不做限定。
可选的,SMF还可向PCF发送计费策略请求消息,该计费策略请求消息包括第一终端设备的标识信息和多播业务的标识信息,以使得PCF根据该第一终端设备的标识信息和多播业务的标识信息,下发第一终端设备关于该多播业务的第一计费策略。其中,该多播业务的标识信息为可选的,即SMF上报的计费策略请求消息中可以只包括第一终端设备的标识信息。例如当第一终端设备和UPF1建立的PDU会话仅支持传输该多播业务的数据包时,则SMF可以不需上报该多播业务的标识信息;当该PDU会话还支持传输其他多播业务的数据包时,则SMF需上报该多播业务的标识信息。
可选的,SMF可以将QoS策略请求消息和计费策略请求消息携带于一个请求消息中向PCF发送,也可以该计费策略请求消息和QoS策略请求消息是同一条消息。也可以分离为两个请求消息向PCF发送,示例性的,当SMF分别向PCF发送QoS策略请求消息和计费策略请求消息时,这两个过程并不存在时序关系,即可以先发送QoS策略请求消息,也可以先发送计费策略请求消息,或者同时发送,具体此处不做限定。
405、SMF接收PCF发送的第一QoS策略。
SMF向PCF发送QoS策略请求消息后,接收PCF下发的用于建立UPF1和UPF2之间单播隧道的第一QoS策略。本申请实施例中,第一QoS策略包括该单播隧道对应的多播业务的描述信息和多播业务的服务需求信息等。其中,该描述信息具体可以是以下信息中的任意一种或者多种:多播业务标识信息,多播组标识信息,多播组IP地址信息;该服务需求信息可以是以下信息中的任意一种或者多种:该多播业务需要的带宽(如2Mbps),该多播业务的最大时延(如200ms),抖动(如正负不大于40ms),该多播业务的最大丢包率(如5%)。
可选的,在一些场景中,PCF只有在固网接入的时候才下发第一QoS策略,故SMF通过步骤404向PCF发送QoS策略请求消息来请求建立单播隧道的第一QoS策略时,还需发送固网接入技术指示消息给PCF。
对应的,当SMF还向PCF发送计费策略请求消息时,SMF接收PCF发送的第一计费策略。类似的,PCF可以将第一计费策略和第一QoS策略携带于一个消息中以向SMF发送;也可以分别发送第一计费策略和第一QoS策略,且这两个过程并不存在时序关系。
406、SMF向UPF1发送第二请求消息。
SMF获得第一QoS策略后,将第一QoS策略分发给UPF1和UPF2,以使得在UPF1和UPF2之间建立的单播隧道上,根据第一QoS策略,传输该多播业务的数据包。具体的,SMF向UPF1发送第二请求消息,以建立UPF1和UPF2之间的单播隧道,该第二请求消息包括第一QoS策略。
示例性的,该第二请求消息可以为会话建立请求(session establishmentrequest)消息,也可以是现有的其他消息或者新消息,具体此处不做限定。
407、UPF1向SMF发送第二请求响应消息。
UPF1向SMF发送第二请求响应消息,该第二请求响应消息携带有UPF1配置的单播隧道在UPF1侧的标识信息。
示例性的,该第二请求响应消息可以为会话建立响应(session establishmentresponse)消息,也可以是现有的其他消息或者新消息,具体此处不做限定。
408、SMF向UPF2发送第三请求消息。
故SMF收到该第二请求响应消息后,向UPF2发送第三请求消息,该第三请求消息包括第一QoS策略和单播隧道在UPF1侧的标识信息。另外,该第三请求消息还可包括第一终端设备的第一请求消息,具体包括以下信息中的任意一种或者多种:第一终端设备的标识信息,该多播业务所对应的数据网络标识信息,多播业务的标识信息,多播业务对应的多播组的标识信息,或者,多播组的地址信息。
示例性的,该第三请求消息可以为会话建立请求(session establishmentrequest)消息,也可以是现有的其他消息或者新消息,具体此处不做限定。
409、UPF2向SMF发送第三请求响应消息。
UPF2接收到该第三请求消息后,根据其中的第一请求消息将第一终端设备与该多播业务关联,即该多播业务的数据包会发送给与该多播业务关联的终端设备(包括第一终端设备)。另外,响应于该第三请求消息,UPF2向SMF发送第三请求响应消息,该第三请求响应消息还包括UPF2配置的单播隧道在UPF2侧的标识信息。
示例性的,该第三请求响应消息可以为会话建立响应(session establishmentresponse)消息,也可以是现有的其他消息或者新消息,具体此处不做限定。
410、SMF向UPF1发送单播隧道在UPF2侧的标识信息。
SMF收到该第三请求响应消息后,向UPF1发送单播隧道在UPF2侧的标识信息。
通过上述步骤406~410,UPF1和UPF2均获得了单播隧道在对方侧的标识信息,实现了UPF1和UPF2之间的单播隧道的建立。
可选的,实际应用中,建立UPF1和UPF2之间的单播隧道的方式还有多种,例如,SMF向UPF2发送第五请求消息,包括第一QoS策略,并接收UPF2发送的单播隧道在UPF2侧的标识信息。SMF再向UPF1发送第二请求消息,该第二请求消息包括第一QoS策略和单播隧道在UPF2侧的标识信息。响应于该第二请求消息,UPF1向SMF发送第二请求响应消息,该第二请求响应消息包括单播隧道在UPF1侧的标识信息。SMF接收到该第二请求响应消息后,向UPF2发送第三请求消息,该第三请求消息包括单播隧道在UPF1侧的标识信息。可选的,UPF2还可向SMF发送第三请求响应消息,以指示接收到该第三请求消息。
或者,SMF配置单播隧道在UPF1侧的标识信息和单播隧道在UPF2侧的标识信息,并通过第二请求消息将第一QoS策略和单播隧道在UPF2侧的标识信息发送给UPF1,可选的,SMF接收UPF1发送的第二请求响应消息。且SMF通过第三请求消息将第一QoS策略和单播隧道在UPF1侧的标识信息发送给UPF2,可选的,SMF接收UPF2发送的第三请求响应消息。因此,建立UPF1和UPF2之间的单播隧道的方式具体此处不做限定。
可选的,当SMF还接收到PCF下发的第一计费策略时,SMF可以将该第一计费策略发送给UPF1和/或UPF2,以使得UPF1或者UPF2可以为第一终端设备关于该多播业务进行计费。示例性的,SMF向UPF1发送的第二请求消息中还包括该第一计费策略,和/或,SMF向UPF2发送的第三请求消息中还包括该第一计费策略。
可选的,当UPF1和UPF2均获得该第一计费策略时,可以选择其中一个为第一终端设备关于该多播业务进行计费,另一个统计对应于该多播业务的相关信息,如为该多播业务做收视率统计或者为请求该多播业务的终端设备做流量统计。示例性的,运营商设备可配置UPF2进行计费,UPF1进行统计;或,UPF1进行计费,UPF2进行统计;或,UPF1和UPF2中的任一个或者两个都既进行统计也进行计费,具体此处不做限定。
411、UPF1向SMF发送对应于多播业务的统计信息。
可选的,UPF1可统计对应于该多播业务的相关信息,以得到该多播业务对应的统计信息。其中,该相关信息可以包括请求该多播业务的终端设备的数量等,该统计信息可包括收视率统计信息和/或各终端设备的流量统计信息,并将该统计信息发送给SMF,或者,UPF1可将该统计信息发送给运营商统计中心,或者多播业务平台。SMF接收到该统计信息可以上报给PCF,PCF可以用做策略控制,比如根据流量统计调整QoS和计费策略等。具体地,UPF1向SMF发送第四请求消息,该第四请求消息携带有多播业务的统计信息和多播业务的标识信息。其中,该多播业务的标识信息可以是多播业务的标识,也可以是该多播业务所对应的数据网络标识,或多播业务对应的多播组的标识信息,或者,多播组的地址信息。
可选的,该第四请求消息可以为会话修改请求(session modification request)消息,也可以为现有的其他消息或者新消息,具体此处不做限定。
可选的,若该UPF1统计该多播业务的相关信息,该UPF1将统计信息发送给SMF或者运营商统计中心,或者多播业务平台的方式有多种,例如当该统计信息为多播业务的收视率统计信息时,UPF1可以周期性的向SMF上报该收视率统计信息,如每间隔一小时UPF1向SMF发送一次收视率统计信息;或者,UPF1也可以在该单播隧道拆除时,一次性的向SMF上报该多播业务的总收视率统计信息。因此,UPF1将统计信息发送给SMF或者运营商统计中心,或者多播业务平台的方式具体此处不做限定。
412、UPF2上报计费信息。
可选的,UPF2可为第一终端设备关于该多播业务进行计费。具体地,UPF2在获得第一终端设备关于该多播业务的第一计费策略后,当收到多播业务的数据包时,根据该第一计费策略为第一终端设备进行计费,生成该第一终端设备关于该多播业务的计费信息。类似的,UPF2还可生成与该多播业务关联的其他终端设备的计费信息,并将获得的所有计费信息上报给计费系统。
本申请实施例适用于UPF1接收到第一个终端设备发起的请求某多播业务的场景,且SMF确定要为该多播业务建立单播隧道,并根据PCF下发的第一QoS策略建立UPF1和UPF2之间的单播隧道,核心网侧可以为请求该多播业务的终端设备单独计费,并且统计得到该多播业务的统计信息,如该多播业务的收视率等。
图4所示的实施例中,SMF确定需要建立多播业务对应的单播隧道,在实际应用中,当该多播业务对应的单播隧道已经建立,且有其他终端设备请求该多播业务时,本申请实施例提供了一种多播业务的数据传输方法,请参阅图6,为本申请实施例基于场景2提供的一种可能的多播业务的数据传输方法的流程示意图,包括:
601、第一终端设备与UPF1建立PDU会话。
602、第一终端设备向SMF发送第一请求消息。
本申请实施例中,步骤601至602与图4所示的实施例中的步骤401至402类似,此处不再赘述。
603、SMF确定多播业务对应的单播隧道已建立。
SMF接收到该第一请求消息后,可以根据该第一请求消息判断是否存在该多播业务对应的单播隧道。当存在该多播业务对应的单播隧道时,SMF确定该多播业务对应的单播隧道已建立。
604、SMF向PCF发送计费策略请求消息。
本步骤为可选步骤,具体地,当SMF本地没有第一终端设备关于该多播业务的计费策略时,执行该步骤604;当SMF本地有第一终端设备关于该多播业务的计费策略时,则可以不执行该步骤604,而使用本地存储的该多播业务对应的计费策略。
本申请实施例中,步骤604中SMF向PCF发送计费策略请求消息与图4中步骤404所描述的SMF向PCF发送计费策略请求消息类似,具体此处不再赘述。
605、SMF接收PCF发送的第一计费策略。
本申请实施例中,步骤605中SMF接收PCF发送的第一计费策略与图4中步骤405所描述的SMF接收PCF发送的第一计费策略类似,具体此处不再赘述。
606、SMF向UPF1发送第二请求消息。
可选的,SMF可向UPF1发送第二请求消息,该第二请求消息包括SMF从PCF接收的第一计费策略,以使得UPF1根据该第一计费策略为第一终端设备关于该多播业务单独计费。
可选的,SMF还可接收UPF1发送的第二请求响应消息,以响应于该第二请求消息。
607、SMF向UPF2发送第三请求消息。
SMF向UPF2发送第三请求消息,该第三请求消息用于指示第一终端设备请求该多播业务,以使得UPF2将该第一终端设备与多播业务关联。该第三请求消息可包括第一终端设备的标识信息和/或该多播业务的标识信息。其中多播业务的标识信息可以是多播业务的标识,也可以是多播业务所对应的数据网络标识信息,多播业务对应的多播组的标识信息,或者,多播组的地址信息。
可选的,当SMF获得第一计费策略后,该第三请求消息还可包括第一计费策略,以使得UPF2根据该第一计费策略为第一终端设备关于该多播业务单独计费。
可选的,当UPF1和UPF2均获得该第一计费策略时,可以选择其中一个为第一终端设备关于该多播业务进行计费,另一个统计对应于该多播业务的相关信息,如为该多播业务做收视率统计或者为与该多播业务关联的终端设备做流量统计。示例性的,运营商设备可配置UPF2进行计费,UPF1进行统计;或,UPF1进行计费,UPF2进行统计;或,UPF1和UPF2中的任一个或者两个都既进行统计也进行计费,具体此处不做限定。
可选的,SMF还可接收UPF2发送的第三请求响应消息,以响应于该第三请求消息。
608、UPF1向SMF发送对应于多播业务的统计信息。
609、UPF2上报计费信息。
本申请实施例中,步骤608至609与图4中的步骤411至412类似,此处不再赘述。
本申请实施例中,适用于单播隧道建立后,UPF1又接收到其他终端设备发起的请求某多播业务的场景。SMF确定该多播业务对应的单播隧道已建立,并通知UPF2又有终端设备请求该多播业务。核心网侧可以为请求该多播业务的终端设备单独计费,并且统计得到该多播业务的统计信息,如该多播业务的收视率等。
上述图4和图6分别以第一网元为SMF,第二网元为UPF2,第三网元为UPF1为例对本申请实施例基于场景1和2提供的多播业务的数据传输方法进行了说明,为便于描述,图7至图9将以第一网元为SMF,第二网元为UPF2,第三网元为AN为例,对本申请实施例基于场景3至场景5提供的多播业务的数据传输方法进行说明。
请参阅图7,为本申请实施例基于场景3提供的一种可能的多播业务的数据传输方法,包括:
701、第一终端设备与UPF2建立PDU会话。
本申请实施例中,步骤701中第一终端设备与UPF2建立PDU会话的方式与图4的步骤401中第一终端设备与UPF1建立PDU会话的方式类似,此处不再赘述。
702、第一终端设备向SMF发送第一请求消息。
当第一终端设备需要请求多播业务时,第一终端设备向SMF发送第一请求消息,该第一请求消息用于指示该第一终端设备请求多播业务,其中,该第一请求消息包括的内容与实施例4步骤402所描述的第一请求消息包括的内容类似,具体此处不再赘述。可选的,第一终端设备向SMF发送第一请求消息的方式有多种,包括:
方式1:通过用户面发送:
示例性的,第一终端设备从用户面发送IGMP Join消息到AN,该IGMP Join消息中携带第一请求消息。AN收到该IGMP Join消息后,在通过N2接口发送的N2会话管理(N2session manager,N2SM)消息中,携带该第一请求消息以发送给SMF,其中N2接口为AN与SMF之间的通信接口。
可选的,本申请实施例中,第一终端设备通过用户面发送第一请求消息的方式,与图4所示的步骤402中第一终端设备通过用户面发送第一请求消息的方式1类似,此处不再赘述。
方式2:通过控制面发送:
示例性的,第一终端设备在NAS消息中的PDU会话修改请求中携带第一请求消息,该NAS消息经由AN,AMF发送给SMF。
可选地,AN判断需要建立单播隧道。则AN收到NAS消息后,将AN侧的单播隧道标识信息和NAS消息一起经由AMF发送给SMF。AN还可以发送一个单播隧道建立指示给SMF。
703、SMF确定需要建立多播业务对应的单播隧道。
SMF可以根据AN侧的单播隧道标识信息或单播隧道建立指示确定,或者根据第一请求消息确定需要建立单播业务对应的单播隧道。
704、SMF向PCF发送QoS策略请求消息。
705、SMF接收PCF发送的第一QoS策略。
本申请实施例中,步骤704至705与图4中的步骤404至405类似,此处不再赘述。
706、SMF经由AMF转发向AN发送第二请求消息。
707、SMF接收AN经由AMF发送的第二请求响应消息。
本申请实施例中,步骤706至707中SMF向AN发送第二请求消息并接收来自AN的第二请求响应消息的方式与图4的步骤406至407中SMF向UPF1发送第二请求消息并接收来自UPF1的第二请求响应消息的方式类似,此处不再赘述。可选的,SMF与AN之间的通信需要经过AMF,即SMF向AN发送的第二请求消息需要经由AMF转发,即SMF将第二请求消息发送给AMF,AMF再将该第二请求消息发送给AN。且AN发送给SMF的第二请求消息也需要经由AMF转发。其中,AMF转发的方式可以为透传,也可以为从接收到的消息中解析出部分信息再转发,具体此处不做限定。
708、SMF向UPF2发送第三请求消息。
709、UPF2向SMF发送第三请求响应消息。
本申请实施例中,步骤708至709与图4的步骤408至409类似,此处不再赘述。
710、SMF通过AMF向AN发送单播隧道在UPF2侧的标识信息。
本申请实施例中,步骤710中SMF向AN发送的单播隧道在UPF2侧的标识信息与图4的步骤410中SMF向UPF1发送的单播隧道在UPF2侧的标识信息类似,此处不再赘述。
可选的,SMF向AN发送单播隧道在UPF2侧的标识信息需要经由AMF转发,即SMF将单播隧道在UPF2侧的标识信息发送给AMF,AMF再将单播隧道在UPF2侧的标识信息发送给AN。
可以理解的是,AN和UPF2之间建立单播隧道的方式有多种,与图4的步骤410中类似建立UPF1和UPF2之间的单播隧道的方式类似,具体此处不再赘述。可选的,AN和UPF2之间建立单播隧道的方式还可以包括:如果步骤702中AN已经将AN侧的单播隧道标识信息发送给SMF,则SMF先执行步骤708~709,并在步骤708中向UPF2发送的第三请求消息中包括AN侧单播隧道标识信息,然后再执行步骤706,并在步骤706中的第二请求消息中携带UPF2的单播隧道标识信息,另外,步骤707中AN侧单播隧道标识不需要再发送且步骤710不需要执行。
711、AN上报对应于多播业务的统计信息。
本申请实施例中,AN获得对应于该多播业务的统计信息,并将该统计信息上报给核心网。
可选的,AN获得对应于该多播业务的统计信息的方式与图4中的步骤UPF1获得对应于该多播业务的统计信息的方式类似,具体此处不再赘述。
且,AN将统计信息上报给核心网的方式与图4的步骤411中UPF1将统计信息发送给SMF的方式类似,即也可以周期性的发送或者在单播隧道拆除时一次性发送,具体此处不做限定。
在另一种可能的实现方式中,AN不把统计信息上报给核心网,而是将统计信息上报给固定网络运营商的统计系统。
AN还可能把计费信息上报给固定网络运营商的计费系统,这样可以用于例如与移动网络运营商的计费系统进行对帐单操作,故接收AN上报的统计信息的设备具体此处不做限定。
712、UPF2上报计费信息。
本申请实施例中,步骤712与图4中的步骤412类似,此处不再赘述。
本申请实施例适用于AN接收到第一个终端设备发起的请求某多播业务的场景,且SMF确定要为该多播业务建立单播隧道,并根据PCF下发的第一QoS策略建立AN和UPF2之间的单播隧道,核心网侧可以为请求该多播业务的终端设备单独计费,并且统计得到该多播业务的统计信息,如该多播业务的收视率等。
请参阅图8,为本申请实施例基于场景4提供的一种可能的多播业务的数据传输方法的流程示意图,包括:
801、第一终端设备与UPF2建立PDU会话。
本申请实施例中,步骤801至步骤802与图7中的步骤701至702类似,此处不再赘述。
802、第一终端设备向SMF发送第一请求消息。
当第一终端设备需要请求多播业务时,第一终端设备向SMF发送第一请求消息,该第一请求消息用于指示该第一终端设备请求多播业务,第一请求消息所携带的信息与图4中的步骤402中第一请求消息所携带的信息类似,此处不再赘述。可选的,第一终端设备向SMF发送第一请求消息的方式有多种,包括:
方式1:通过用户面发送:
本申请实施例中,第一终端设备通过用户面发送第一请求消息的方式与图7所示的步骤702中第一终端设备通过用户面发送第一请求消息的方式1类似,此处不再赘述。
另一种可能的发送方式:示例性的,第一终端设备从用户面发送IGMP Join消息到AN,该IGMP Join消息中携带第一请求消息。AN收到该IGMP Join消息后,确定该多播业务对应的单播隧道已经建立,故可以直接把该IGMP Join消息通过单播隧道发送给UPF2。UPF2收到该IGMP Join消息后,发送第一请求消息给SMF。
方式2:通过控制面发送:
本申请实施例中,第一终端设备通过控制面向SMF发送第一请求消息的方式与图4的步骤402中第一终端设备通过控制面向SMF发送第一请求消息的方式2类似,具体此处不再赘述。
803、SMF确定多播业务对应的单播隧道已建立。
可选的,SMF可以根据没有收到AN侧的单播隧道标识信息或单播隧道建立指示确定隧道已建立,或者根据第一请求消息确定对应的单播隧道已建立。
804、SMF向PCF发送计费策略请求消息。
805、SMF接收PCF发送的第一计费策略。
本申请实施例中,步骤803至步骤805与图6中的步骤603至605类似,此处不再赘述。
806、SMF经由AMF向AN发送第二请求消息。
本申请实施例中,步骤806中SMF向AN发送的第二请求消息与图6的步骤606中SMF向UPF1发送的第二请求消息类似,具体此处不再赘述。
可选的,SMF与AN的通信经过AMF,即SMF将第二请求消息发送给AMF,再由AMF将该第二请求消息发送给AN。
807、SMF向UPF2发送第三请求消息。
本申请实施例中,步骤807与图6中的步骤607类似,此处不再赘述。
808、AN上报对应于多播业务的统计信息。
809、UPF2上报计费信息。
本申请实施例中,步骤808至809与图7中的步骤711至712类似,此处不再赘述。
本申请实施例中,适用于单播隧道建立后,AN又接收到其他终端设备发起的请求某多播业务的场景。SMF确定该多播业务对应的单播隧道已建立,并通知UPF2又有终端设备请求该多播业务。核心网侧可以为请求该多播业务的终端设备单独计费,并且统计得到该多播业务的统计信息,如该多播业务的收视率等。
请参阅图9,为本申请实施例基于场景5提供的一种可能的多播业务的数据传输方法的流程示意图,包括:
901、第一终端设备与UPF2建立PDU会话。
本申请实施例中,步骤901与图7中的步骤701类似,具体此处不再赘述。
902、第一终端设备向SMF发送第一请求消息。
当第一终端设备需要请求多播业务时,第一终端设备向SMF发送第一请求消息,该第一请求消息用于指示该第一终端设备请求多播业务。其中,该第一请求消息包括的信息与图4所示的步骤402中第一请求消息所包括的信息类似,具体此处不再赘述。
示例性的,第一终端设备向SMF发送第一请求消息的方式有多种,包括:
方式1:通过用户面发送:
示例性的,第一终端设备从用户面发送IGMP Join消息到UPF2,该IGMP Join消息中携带第一请求消息。UPF2接收到该IGMP Join消息后,发送第一请求消息到SMF。
方式2:通过控制面发送:
本申请实施例中,第一终端设备通过控制面向SMF发送第一请求消息的方式可以与图4的步骤402中第一终端设备通过控制面向SMF发送第一请求消息的方式2类似,也可以与图7的步骤702中第一终端设备通过控制面向SMF发送第一请求消息的方式2类似,具体此处不再赘述。
903、SMF确定将当前PDU会话作为多播业务对应的单播隧道。
SMF接收到第一请求消息后,确定将当前PDU会话作为多播业务对应的单播隧道,即使用该当前PDU会话的AN侧与核心网UPF2之间的网络资源传输该多播业务的数据包,其中,该当前PDU会话为第一终端设备与UPF2之间建立的PDU会话。
904、SMF向PCF发送QoS策略请求消息。
可选的,SMF向PCF发送QoS策略请求消息,本申请实施例中,步骤904中SMF向PCF发送的QoS策略请求消息与图4的步骤404中SMF向PCF发送的QoS策略请求消息类似,此处不再赘述。
可选的,SMF还可向PCF发送计费策略请求消息,其中SMF向PCF发送计费策略请求消息的方式与图6的步骤604中SMF向PCF发送计费策略请求消息的方式和类似,此处不再赘述。
可选的,当SMF向PCF发送QoS策略请求消息和计费策略请求消息时,这两个消息可以包含于一个消息内向PCF发送,即为同一个消息;也可以分别向PCF发送,且发送QoS策略请求消息的步骤和发送计费策略请求消息得到步骤之间,并不存在时序关系。
实际应用中,SMF可通过PDU会话修改请求向PCF发送该QoS策略请求消息,也可通过现有的其他消息或者新消息,具体此处不做限定。
另外,当SMF上已经有该多播业务对应的QoS策略时,则SMF可以不向PCF发送QoS策略请求消息,而使用本地存储的该多播业务对应的QoS策略作为第一QoS策略。即该步骤为可选步骤。
905、SMF接收PCF发送的第一QoS策略。
可选的,本申请实施例中,步骤905中SMF接收PCF发送的第一QoS策略与图4中步骤405所描述的SMF接收PCF发送的第一QoS策略类似,具体此处不再赘述。
对应的,当步骤904中,SMF还向PCF发送计费策略请求消息时,SMF接收PCF发送的第一计费策略。类似的,PCF可以将第一计费策略和第一QoS策略携带于一个消息中以向SMF发送;也可以分别发送第一计费策略和第一QoS策略,且这两个过程并不存在时序关系。
906、SMF经由AMF向AN发送第二请求消息。
907、SMF向UPF2发送第三请求消息。
本申请实施例中,步骤906至907与图8的步骤806至807类似,此处不再赘述。
可选的,当SMF收到后续其他终端设备如第二终端设备发送的该多播业务的请求时,若确定仍然使用该单播隧道,则SMF可能向PCF发送第二计费策略请求消息。该第二计费请求策略消息包括该第二终端设备的标识信息和该多播业务的标识信息。PCF根据该第二计费请求策略消息确定第二终端设备关于该多播业务的第二计费策略,并下发给SMF。如果SMF已有第二终端设备针对该多播业务的计费规则,则不需要再向PCF请求计费策略。
SMF获得该第二计费策略后,向UPF2发送第四请求消息,该第四请求消息用于指示第二终端设备请求该多播业务,以使得UPF2将该第二终端设备与多播业务的标识信息关联。该第四请求消息可包括第二终端设备的多播请求消息,具体见图4中的步骤401中的多播请求消息。该第四请求消息还包括第二终端设备关于该多播业务的计费策略。
可选的,SMF也可将该第二计费策略发送给AN。
908、AN上报对应于多播业务的统计信息。
本申请实施例中,步骤908与图7中的步骤711类似,此处不再赘述。
909、UPF2上报计费信息。
可选的,UPF2可为与该多播业务关联的终端设备关于该多播业务进行计费。具体地,UPF2在获得第一终端设备关于该多播业务的第一计费策略后,当收到多播业务的数据包时,根据该第一计费策略为第一终端设备进行计费,生成该第一终端设备关于该多播业务的计费信息。类似的,UPF2还根据第二计费策略生成第二终端设备关于该多播业务的计费信息等,并将获得的所有计费信息上报给计费系统。
本申请实施例中,SMF根据终端设备的多播业务的请求决定使用当前PDU会话作为单播隧道,并把终端设备的多播请求以及该终端设备的计费策略发送给UPF2,增加了网络中网络资源的利用效率。
上面对本申请实施例中多播业务的数据传输方法进行了描述,下面对本申请实施例中的网元进行描述,请参阅图10,本申请实施例中网元的一个实施例,所述网元应用于第一网元侧,包括:
第一收发单元1001,用于接收来自于第一终端设备的第一请求消息,所述第一请求消息用于请求多播业务,所述第一请求消息包括所述第一终端设备的标识信息,和/或,所述多播业务的标识信息;
获得单元1002,用于获取所述多播业务对应的第一QoS策略,以使得在第二网元和第三网元之间的单播隧道上,根据所述第一QoS策略,传输所述多播业务的数据包。
可选的,在一些实施例中,该获得单元1002具体用于:
向策略控制功能实体PCF发送QoS策略请求消息,所述QoS策略请求消息包括以下参数中的任意一种或者多种:单播隧道指示,所述多播业务的标识信息,所述多播组的标识信息,或,所述多播组的地址信息;接收所述PCF发送的所述第一QoS策略。
可选的,在一些实施例中,该获得单元1002具体用于,将本地存储的所述多播业务对应的QoS策略作为所述第一QoS策略。
可选的,在一些实施例中,第一网元还包括:
第二收发单元1003,所述第二收发单元还用于接收所述PCF发送的所述第一终端设备对应的所述多播业务的第一计费策略,所述第一计费策略为所述PCF根据所述第一终端设备的标识信息和所述多播业务的标识信息获得;
所述第二收发单元用于向所述第二网元和/或所述第三网元发送所述第一计费策略。
可选的,在一些实施例中,所述第一收发单元1001还用于:
接收第二终端设备发送的第二请求消息,所述第二请求消息用于请求所述多播业务;向所述第二网元发送第三请求消息,所述第三请求消息用于指示所述第二终端设备请求所述多播业务,以使得所述第二网元将所述第二终端设备和所述多播业务关联。
可选的,在一些实施例中,所述第二收发单元1003还用于:
接收所述第三网元或第二网元发送的对应于所述多播业务的统计信息,所述统计信息包括收视率统计信息和/或者各终端设备的流量统计信息,所述各终端设备与所述多播业务关联。
可选的,在一些实施例中,所述第一网元还包括:
确定单元1004,用于确定使用当前协议数据单元PDU会话发送所述多播业务的数据包。
本申请实施例中,通过获得单元获得的第一QoS策略,实现第二网元与第三网元之间的单播隧道在进行多播业务的数据包的转发时满足第一QoS策略,解决了现有技术中多播业务的数据包在5G系统中如何传输,多播业务的业务质量如何得到保障的问题。
请参阅图11,为本申请实施例中网元的另一个实施例,所述网元应用于第二网元侧,包括:
获得单元1101,用于获得第一服务质量QoS策略;
传输单元1102,用于根据所述第一QoS策略在单播隧道上传输多播业务的数据包,所述单播隧道为所述第二网元与第三网元之间的隧道,所述第一QoS策略与所述多播业务对应。
可选的,在一些实施例中,所述获得单元1101具体用于:
接收第一网元发送的第一请求消息,所述第一请求消息包括所述第一QoS策略,所述第一QoS策略由所述第二网元根据第一终端设备发送的第二请求消息获得,所述第二请求消息用于请求所述多播业务。
可选的,在一些实施例中,所述获得单元1101还用于:
接收所述第一网元发送的所述第一终端设备对应的所述多播业务的计费策略。
可选的,在一些实施例中,所述第二网元还包括:关联单元1103,
所述获得单元1101还用于,接收所述第一网元发送的第三请求消息,所述第三请求消息用于指示第二终端设备请求所述多播业务;
所述关联单元1103,用于将所述第二终端设备和所述多播业务关联。
可选的,在一些实施例中,所述第二网元还包括:生成单元1304,
所述生成单元1104,用于生成对应于所述多播业务的统计信息,所述统计信息包括收视率统计信息和/或各终端设备的流量统计信息;
所述获得单元1101,还用于将所述统计信息发送给所述第一网元,或者,接入和移动性管理功能实体AMF。
可选得,在一些实施例中,所述生成单元1104还用于:
根据各终端设备对应的所述多播业务的计费策略生成所述各终端设备的计费信息,所述各终端设备与所述多播业务关联。
本申请实施例中,通过获得单元获得的第一QoS策略,实现第二网元与第三网元之间的单播隧道在进行多播业务的数据包的转发时满足第一QoS策略,解决了现有技术中多播业务的数据包在5G系统中如何传输,多播业务的业务质量如何得到保障的问题。
上面图10至图11从模块化功能实体的角度分别对本申请实施例中的网元进行详细描述,下面从硬件处理的角度对本申请实施例中的网元进行详细描述。
图12示出了上述实施例中一种网元1200可能的结构示意图,该网元1200所述网元应用于第一网元侧,该网元1200可以包括:处理器1202、收发器1204,可选的,还可以包括计算机可读存储介质/存储器1203,这些部件可通过总线1201互联。本申请实施例不限定上述部件之间的具体连接介质。
收发器1204可用于支持第一网元与上述实施例中的第二网元或者第三网元之间进行通信,可以执行图4至图9中涉及第一网元的数据收发过程和/或用于本申请所描述的技术的其他过程。
例如,收发器1204可以用于至少接收来自于第一终端设备的第一请求消息,其中,该第一请求消息用于请求多播业务,以及根据第一请求消息获得第一QoS策略,第一QoS策略与所述多播业务对应,以使得在第二网元和第三网元之间的单播隧道上,根据第一QoS策略,传输多播业务的数据包。收发器1204还可以执行图4中的步骤402、步骤404至步骤411,图6中的步骤602、步骤604至步骤608,图7中的步骤702、步骤704至步骤710,图8中的步骤802、步骤804至步骤807,以及图9中的步骤902、步骤904至步骤907。当然,收发器1204还可以用于执行本申请所描述的技术的其他过程和方法。
处理器1202用于对上述第一网元的动作进行控制管理,用于执行上述实施例中由第一网元进行的处理,可以执行图4至图9中涉及第一网元的处理过程和/或用于本申请所描述的技术的其他过程,可以负责管理总线以及可以执行存储在存储器中的程序或指令。例如,处理器1202可以执行图4中的步骤403、图6中的步骤603、图7中的步骤703、图8中的步骤803,以及图9中的步骤903。
计算机可读存储介质/存储器1203中保存有执行本申请技术方案的程序,指令或数据。例如,计算机可读存储介质/存储器1203可包含足以允许网元1200接收来自于第一终端设备的第一请求消息的指令,还可以包含足以允许网元1200获得与多播业务对应的第一服务质量QoS策略的指令,还可以包含足以允许网元1200实现上述图4至图9中涉及第一网元的收发过程、处理过程和/或用于本申请所描述的技术的其他过程。
可以理解的是,图12仅仅示出了第一网元的简化设计,在实际应用中,第一网元可以包含任意数量的收发器,处理器,存储器等,而所有的可以实现本申请的第一网元都在本申请的保护范围之内。
图13示出了上述实施例中一种网元1300可能的结构示意图,该装置1300可以配置为前述第二网元,该网元1300包括:处理器1302、收发器1304、可选的,还可以包括计算机可读存储介质/存储器1303,这些部件可通过总线1301互联。本申请实施例不限定上述部件之间的具体连接介质。
收发器1304可用于支持第二网元或第三网元与上述第一网元之间进行通信,可以执行图4至图9中涉及第二网元或第三网元的通信或交互过程和/或用于本申请所描述的技术的其他过程。例如,收发器1304可以用于获得第一服务质量QoS策略。当网元1300用于执行上述方法实施例中第二网元的动作时,收发器1304还用于执行图4中的步骤408至步骤409和步骤412,图6中的步骤607和步骤609,图7中的步骤708至步骤709,图8中的步骤807和步骤809,图9中的步骤907和步骤909;当网元1300用于执行上述方法实施例中第三网元的动作时,收发器1304还用于执行图4中的步骤406至步骤407、步骤410至步骤411,图6中的步骤606和步骤608,图7中的步骤706至步骤707和步骤710至步骤711,图8中的步骤806和步骤808,图9中的步骤906和步骤908。当然,收发器1304还可以用于执行本申请所描述的技术的其他过程和方法。
处理器1302用于对第二网元或第三网元的动作进行控制管理,用于执行上述实施例中由第二网元或第三网元进行的处理,可以执行图4至图9中涉及第二网元或者第三网元的处理过程和/或用于本申请所描述的技术的其他过程,可以负责管理总线以及可以执行存储在存储器中的程序或指令。
计算机可读存储介质/存储器1303中保存有执行本申请技术方案的程序,指令和数据。例如,计算机可读存储介质/存储器1303可包含足以允许网元1300获得第一服务质量QoS策略的指令,还可以包含足以允许网元1300实现上述图4至图9中涉及第二网元或者第三网元的收发过程、处理过程和/或用于本申请所描述的技术的其他过程。
可以理解的是,图13仅仅示出了第二网元的简化设计,在实际应用中,第二网元可以包含任意数量的收发器,处理器,存储器等,而所有的可以实现本申请的第二网元都在本申请的保护范围之内。
上述网元1200和网元1300中涉及的处理器可以是通用处理器,例如通用中央处理器(CPU)、网络处理器(network processor,NP)、微处理器等,也可以是特定应用集成电路(application-specific integrated circBIt,ASIC),或一个或多个用于控制本申请方案程序执行的集成电路。还可以是数字信号处理器(digital signal processor,DSP)、现场可编程门阵列(field-programmable gate array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。控制器/处理器也可以是实现计算功能的组合,例如包含一个或多个微处理器组合,DSP和微处理器的组合等等。处理器通常是基于存储器内存储的程序指令来执行逻辑和算术运算。
上述涉及的计算机可读存储介质/存储器1203与计算机可读存储介质/存储器1303还可以保存有操作系统和其他应用程序。具体地,程序可以包括程序代码,程序代码包括计算机操作指令。更具体的,上述存储器可以是只读存储器(read-only memory,ROM)、可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(random accessmemory,RAM)、可存储信息和指令的其他类型的动态存储设备、磁盘存储器等等。存储器可以是上述存储类型的组合。并且上述计算机可读存储介质/存储器可以在处理器中,还可以在处理器的外部,或在包括处理器或处理电路的多个实体上分布。上述计算机可读存储介质/存储器可以具体体现在计算机程序产品中。举例而言,计算机程序产品可以包括封装材料中的计算机可读介质。
可以替换的,网元1200和网元1300也可配置成通用处理系统,该系统可以通过芯片实现,该通用处理系统包括:提供处理器功能的一个或多个微处理器;以及提供存储介质的至少一部分的存储器,可选的,可通过总线与其它支持电路连接在一起。当存储器存储的指令被处理器执行时,使得处理器执行第一网元和第二网元在图4至图9所述实施例中的多播业务的数据传输方法,以及图4至图9所述的实施例中的多播业务的数据传输方法中的部分或全部步骤,例如图4中的步骤406至步骤411、图6中的步骤606至步骤608等,和/或用于本申请所描述的技术的其它过程。
结合本申请公开内容所描述的方法或者算法的步骤可以硬件的方式来实现,也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成,软件模块可以被存放于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然,存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外,该ASIC可以位于用户设备中。当然,处理器和存储介质也可以作为分立组件存在于用户设备中。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。
Claims (24)
1.一种多播业务的数据传输方法,其特征在于,包括:
第一网元接收来自于第一终端设备的第一请求消息,所述第一请求消息用于请求多播业务,所述第一请求消息包括所述第一终端设备的标识信息,和/或,所述多播业务的标识信息;
所述第一网元获取所述多播业务对应的第一服务质量QoS策略,以使得在第二网元和第三网元之间的单播隧道上,根据所述第一QoS策略,传输所述多播业务的数据包,所述第二网元和所述第三网元都为用户面功能实体UPF。
2.根据权利要求1所述的方法,其特征在于,所述第一网元获取所述多播业务对应的所述第一QoS策略,包括:
所述第一网元向策略控制功能实体PCF发送QoS策略请求消息,所述QoS策略请求消息包括以下参数中的任意一种或者多种:单播隧道指示,所述多播业务的标识信息,所述多播组的标识信息,或,所述多播组的地址信息;
所述第一网元接收所述PCF发送的所述第一QoS策略。
3.根据权利要求1所述的方法,其特征在于,所述第一网元获取所述多播业务对应的所述第一QoS策略,包括:
所述第一网元将本地存储的所述多播业务对应的QoS策略作为所述第一QoS策略。
4.根据权利要求2所述的方法,其特征在于,所述方法还包括:
所述第一网元接收所述PCF发送的所述第一终端设备对应的所述多播业务的第一计费策略,所述第一计费策略为所述PCF根据所述第一终端设备的标识信息和所述多播业务的标识信息获得;
所述第一网元向所述第二网元和/或所述第三网元发送所述第一计费策略。
5.根据权利要求1至4中任一项所述的方法,其特征在于,所述第一网元获取所述多播业务对应的第一QoS策略之后,所述方法还包括:
所述第一网元接收第二终端设备发送的第二请求消息,所述第二请求消息用于请求所述多播业务;
所述第一网元向所述第二网元发送第三请求消息,所述第三请求消息用于指示所述第二终端设备请求所述多播业务,以使得所述第二网元将所述第二终端设备和所述多播业务关联。
6.根据权利要求1所述的方法,其特征在于,所述方法还包括:
所述第一网元接收所述第三网元或第二网元发送的对应于所述多播业务的统计信息,所述统计信息包括收视率统计信息和/或者各终端设备的流量统计信息,所述各终端设备与所述多播业务关联。
7.一种多播业务的数据传输方法,其特征在于,包括:
第二网元获得第一服务质量QoS策略;
所述第二网元根据所述第一QoS策略在单播隧道上传输多播业务的数据包,所述单播隧道为所述第二网元与第三网元之间的隧道,所述第一QoS策略与所述多播业务对应,所述第二网元和所述第三网元都为用户面功能实体UPF。
8.根据权利要求7所述的方法,其特征在于,所述第二网元获得第一QoS策略包括:
所述第二网元接收第一网元发送的第一请求消息,所述第一请求消息包括所述第一QoS策略,所述第一QoS策略由所述第一网元根据第一终端设备发送的第二请求消息获得,所述第二请求消息用于请求所述多播业务。
9.根据权利要求7或8所述的方法,其特征在于,所述方法还包括:
所述第二网元接收第一网元发送的第一终端设备对应的所述多播业务的计费策略。
10.根据权利要求7至8中任一项所述的方法,其特征在于,所述第二网元获得第一QoS策略之后,所述方法还包括:
所述第二网元接收第一网元发送的第三请求消息,所述第三请求消息用于指示第二终端设备请求所述多播业务;
所述第二网元将所述第二终端设备和所述多播业务关联。
11.根据权利要求10所述的方法,其特征在于,所述方法还包括:
所述第二网元生成对应于所述多播业务的统计信息,所述统计信息包括收视率统计信息和/或各终端设备的流量统计信息;
所述第二网元将所述统计信息发送给所述第一网元,或者,接入和移动性管理功能实体AMF。
12.根据权利要求10所述的方法,其特征在于,所述方法还包括:
所述第二网元根据各终端设备对应的所述多播业务的计费策略生成所述各终端设备的计费信息,所述各终端设备与所述多播业务关联。
13.一种网元,所述网元应用于第一网元侧,其特征在于,包括:
第一收发单元,用于接收来自于第一终端设备的第一请求消息,所述第一请求消息用于请求多播业务,所述第一请求消息包括所述第一终端设备的标识信息,和/或,所述多播业务的标识信息;
获得单元,用于获取所述多播业务对应的第一服务质量QoS策略,所述第一QoS策略与所述多播业务对应,以使得在第二网元和第三网元之间的单播隧道上,根据所述第一QoS策略,传输所述多播业务的数据包,所述第二网元和所述第三网元都为用户面功能实体UPF。
14.根据权利要求13所述的网元,其特征在于,所述获得单元具体用于,向策略控制功能实体PCF发送QoS策略请求消息,所述QoS策略请求消息包括以下参数中的任意一种或者多种:单播隧道指示,所述多播业务的标识信息,所述多播组的标识信息,或,所述多播组的地址信息;接收所述PCF发送的所述第一QoS策略。
15.根据权利要求13所述的网元,其特征在于,所述获得单元具体用于:
将本地存储的所述多播业务对应的QoS策略作为所述第一QoS策略。
16.根据权利要求14所述的网元,其特征在于,所述第一网元还包括:第二收发单元,
所述获得单元还用于接收所述PCF发送的所述第一终端设备对应的所述多播业务的第一计费策略,所述第一计费策略为所述PCF根据所述第一终端设备的标识信息和所述多播业务的标识信息获得;
所述第二收发单元用于向所述第二网元和/或所述第三网元发送所述第一计费策略。
17.根据权利要求13至16中任一项所述的网元,其特征在于,所述第一收发单元还用于:
接收第二终端设备发送的第二请求消息,所述第二请求消息用于请求所述多播业务;向所述第二网元发送第三请求消息,所述第三请求消息用于指示所述第二终端设备请求所述多播业务,以使得所述第二网元将所述第二终端设备和所述多播业务关联。
18.根据权利要求16所述的网元,其特征在于,所述第二收发单元还用于:
接收所述第三网元或第二网元发送的对应于所述多播业务的统计信息,所述统计信息包括收视率统计信息和/或者各终端设备的流量统计信息,所述各终端设备与所述多播业务关联。
19.一种网元,所述网元应用于第二网元侧,其特征在于,包括:
获得单元,用于获得第一服务质量QoS策略;
传输单元,用于根据所述第一QoS策略在单播隧道上传输多播业务的数据包,所述单播隧道为所述第二网元与第三网元之间的隧道,所述第一QoS策略与所述多播业务对应,所述第二网元和所述第三网元都为用户面功能实体UPF。
20.根据权利要求19所述的网元,其特征在于,所述获得单元具体用于,
接收第一网元发送的第一请求消息,所述第一请求消息包括所述第一QoS策略,所述第一QoS策略由所述第一网元根据第一终端设备发送的第二请求消息获得,所述第二请求消息用于请求所述多播业务。
21.根据权利要求19或20所述的网元,其特征在于,所述获得单元还用于:
接收第一网元发送的第一终端设备对应的所述多播业务的计费策略。
22.根据权利要求19至20中任一项所述的网元,其特征在于,所述第二网元还包括:关联单元,
所述获得单元还用于,接收第一网元发送的第三请求消息,所述第三请求消息用于指示第二终端设备请求所述多播业务;
所述关联单元,用于将所述第二终端设备和所述多播业务关联。
23.根据权利要求22所述的网元,其特征在于,所述第二网元还包括:生成单元,
所述生成单元,用于生成对应于所述多播业务的统计信息,所述统计信息包括收视率统计信息和/或各终端设备的流量统计信息;
所述获得单元,还用于将所述统计信息发送给所述第一网元,或者,接入和移动性管理功能实体AMF。
24.根据权利要求23所述的网元,其特征在于,所述生成单元还用于:
根据各终端设备对应的所述多播业务的计费策略生成所述各终端设备的计费信息,所述各终端设备与所述多播业务关联。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810568037.2A CN110557724B (zh) | 2018-06-04 | 2018-06-04 | 一种多播业务的数据传输方法以及相关设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810568037.2A CN110557724B (zh) | 2018-06-04 | 2018-06-04 | 一种多播业务的数据传输方法以及相关设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110557724A CN110557724A (zh) | 2019-12-10 |
CN110557724B true CN110557724B (zh) | 2020-12-15 |
Family
ID=68735977
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810568037.2A Expired - Fee Related CN110557724B (zh) | 2018-06-04 | 2018-06-04 | 一种多播业务的数据传输方法以及相关设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110557724B (zh) |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113055812B (zh) * | 2019-12-27 | 2022-10-21 | 中国移动通信有限公司研究院 | 一种数据传输方法、基站及核心网网元 |
CN113068275B (zh) * | 2020-01-02 | 2024-01-09 | 维沃移动通信有限公司 | 多播业务实现方法及装置、通信设备 |
CN113068135B (zh) * | 2020-01-02 | 2022-07-19 | 维沃移动通信有限公司 | 多播业务处理方法、多播业务配置方法及相关设备 |
CN113163338B (zh) * | 2020-01-07 | 2022-11-11 | 华为技术有限公司 | 一种组播会话的管理方法、装置 |
CN113748746A (zh) * | 2020-01-15 | 2021-12-03 | Oppo广东移动通信有限公司 | 业务传输的方法和设备 |
CN113301446A (zh) * | 2020-02-21 | 2021-08-24 | 华为技术有限公司 | 传输组播业务的方法和装置 |
CN113473383B (zh) * | 2020-03-30 | 2023-02-03 | 大唐移动通信设备有限公司 | 一种服务质量参数提供、选择方法及设备、存储介质 |
CN113573248B (zh) * | 2020-04-28 | 2023-06-20 | 华为技术有限公司 | 用于传输数据的方法与装置 |
CN113709676A (zh) * | 2020-05-21 | 2021-11-26 | 维沃移动通信有限公司 | 一种多播业务的处理方法、装置及电子设备 |
CN113747604A (zh) * | 2020-05-27 | 2021-12-03 | 华为技术有限公司 | 一种通信方法、装置以及系统 |
CN113950042A (zh) * | 2020-07-17 | 2022-01-18 | 维沃移动通信有限公司 | 识别方法、发送方法及相关设备 |
WO2022041156A1 (zh) * | 2020-08-28 | 2022-03-03 | 华为技术有限公司 | 多播群组通信方法、装置和系统 |
CN114650576A (zh) * | 2020-12-18 | 2022-06-21 | 维沃移动通信有限公司 | 网络功能的选择方法和网络功能 |
WO2022141113A1 (zh) * | 2020-12-29 | 2022-07-07 | 华为技术有限公司 | 多播业务通信的方法和通信装置 |
CN112954614B (zh) * | 2021-02-10 | 2023-05-12 | 腾讯科技(深圳)有限公司 | 用于实现多播广播业务切换的方法及相关设备 |
CN115190433A (zh) * | 2021-04-06 | 2022-10-14 | 华为技术有限公司 | 一种多播业务的通信方法及装置 |
CN116170099A (zh) * | 2021-11-25 | 2023-05-26 | 维沃移动通信有限公司 | 数据传输方法、终端及网络侧设备 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2200220A1 (en) * | 2008-12-22 | 2010-06-23 | Thomson Licensing | Method and apparatus for reliable multicast streaming |
US9338073B2 (en) * | 2013-10-31 | 2016-05-10 | Aruba Networks, Inc. | Enhanced dynamic multicast optimization |
CN106488409B (zh) * | 2015-08-29 | 2020-01-21 | 华为技术有限公司 | 一种单播发送广播多播数据的方法、装置及系统 |
-
2018
- 2018-06-04 CN CN201810568037.2A patent/CN110557724B/zh not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
CN110557724A (zh) | 2019-12-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110557724B (zh) | 一种多播业务的数据传输方法以及相关设备 | |
JP7183416B2 (ja) | 時間依存ネットワーキング通信方法及び装置 | |
US10631144B2 (en) | Method and device for charging traffic data flow of user equipment | |
CN110662270B (zh) | 通信方法及装置 | |
US11071089B2 (en) | Dynamic switching of streaming service between broadcast and unicast delivery | |
JP2019083572A (ja) | サービス継続性を維持する方法およびデバイス | |
US20220256393A1 (en) | TSN AND 5GS QoS MAPPING - A USER PLANE BASED METHOD | |
US11343111B2 (en) | Quota management in mobile edge computing (MEC) | |
UA82114C2 (uk) | Спосіб, система та пристрій для отримання послуг (варіанти) та мережа для передачі послуг | |
KR20070094563A (ko) | 무선통신시스템에 사용되는 일대다 mbms 처리방법 및장치 | |
US20230019215A1 (en) | TSC-5G QoS MAPPING WITH CONSIDERATION OF ASSISTANCE TRAFFIC INFORMATION AND PCC RULES FOR TSC TRAFFIC MAPPING AND 5G QoS FLOWS BINDING | |
EP3001746B1 (en) | Embms management method, multimedia broadcast multicast service coordination entity and base station | |
JP2012508534A (ja) | 同期スケジューリング方法および装置 | |
JP2022551394A (ja) | ブロードキャストサービスのモード切り替え方法及びモード切り替え装置並びにコンピュータ機器及びコンピュータプログラム | |
US20220405153A1 (en) | Report application programming interface (api) capability change based on api filter | |
US10440681B2 (en) | Resource scheduling method, base station, scheduler, program source server, and system | |
CN116366567A (zh) | 一种处理服务质量QoS参数的方法、网元、系统及存储介质 | |
WO2016188128A1 (zh) | 一种能力开放方法及系统、能力开放功能实体 | |
CN113973269A (zh) | 一种数据传输方法、装置以及系统 | |
CN101370170A (zh) | 无线资源协调方法 | |
CN112910662B (zh) | 一种流量信息上报及接收上报方法、设备、介质 | |
Boudko et al. | Network selection for multicast groups in heterogeneous wireless environments | |
WO2023000305A1 (zh) | Qos调整方法、装置、设备及介质 | |
WO2015042836A1 (zh) | 一种无线资源分配的方法及装置 | |
CN117042036A (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 | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20201215 Termination date: 20210604 |
|
CF01 | Termination of patent right due to non-payment of annual fee |