CN117939406A - 组播通信方法及相关装置 - Google Patents

组播通信方法及相关装置 Download PDF

Info

Publication number
CN117939406A
CN117939406A CN202211304468.0A CN202211304468A CN117939406A CN 117939406 A CN117939406 A CN 117939406A CN 202211304468 A CN202211304468 A CN 202211304468A CN 117939406 A CN117939406 A CN 117939406A
Authority
CN
China
Prior art keywords
multicast
client
source
frame
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211304468.0A
Other languages
English (en)
Inventor
孟梦
冯冰
张利
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
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
Priority to CN202211304468.0A priority Critical patent/CN117939406A/zh
Priority to PCT/CN2023/125653 priority patent/WO2024088173A1/zh
Publication of CN117939406A publication Critical patent/CN117939406A/zh
Pending legal-status Critical Current

Links

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
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

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

Abstract

本申请公开了一种组播通信方法，应用于组播通信系统，组播通信系统包括组播源和至少一个客户端，例如第一客户端；该方法包括：组播源确定组播地址和组播密钥；组播源向第一客户端发送第一蓝牙消息，该消息包括组播地址和组播密钥；第一客户端向组播源发送第二蓝牙消息，以指示确认加入组播组；第一客户端配置组播密钥对应的源地址为组播源的MAC地址；组播源通过WiFi组播发送经组播密钥加密的第一组播报文，第一组播报文的MAC头中的源地址为组播源的MAC地址，目的地址为组播地址；基于组播地址，第一客户端监听到第一组播报文；第一客户端利用组播密钥解析第一组播报文。这样，可以实现无WiFi连接的大规模组播传输。

Description

组播通信方法及相关装置
技术领域
本申请涉及通信技术领域，尤其涉及组播通信方法及相关装置。
背景技术
在日常生活中，用户可以通过终端设备(例如手机、平板、电脑)向多个其他用户的设备分享同一文件，例如包含音视频、文档或游戏等内容的大容量文件。用户也可以通过终端设备将包含视频、文档或游戏等内容的显示画面，通过一对多投屏分享到多个其他用户的设备上。例如，在会议投屏场景中，将演讲者的设备的显示画面投屏到多个参会者的设备以及会议室显示器上。
对于上述一对多的数据传输场景，现有技术方案往往通过组播转单播的机制来实现，即将组播帧转单播帧后通过WiFi单播发送给各用户设备，该方案中大量重复报文形成极大的空口资源浪费。
目前，如何实现组播通信，从而在避免空口资源浪费的情况下满足上述一对多的数据传输需求，还有待解决。
发明内容
本申请提供了组播通信方法及相关装置，能够快捷建立组播组，实现无WiFi连接的大规模组播传输。
第一方面，本申请提供了组播通信方法，应用于组播通信系统，组播通信系统包括组播源和至少一个客户端，上述至少一个客户端包括第一客户端；上述方法包括：组播源确定组播组的组播地址和第一组播密钥；组播源向第一客户端发送第一蓝牙消息，第一蓝牙消息用于邀请第一客户端加入组播组，第一蓝牙消息包括组播地址和第一组播密钥；第一客户端基于第一蓝牙消息，向组播源发送第二蓝牙消息；第二蓝牙消息用于指示第一客户端确认加入组播组；第一客户端配置第一组播密钥对应的源地址为组播源的媒体存取控制(Media Access Control，MAC)地址；组播源通过无线保真(wireless fidelity，WiFi)通信技术组播发送经第一组播密钥加密的第一组播报文，第一组播报文的第一MAC头中的源地址为组播源的MAC地址，第一MAC头中的目的地址为组播地址；基于组播地址，第一客户端监听到第一组播报文；第一客户端确定第一MAC头中的源地址对应的密钥为第一组播密钥，并利用第一组播密钥解析第一组播报文的数据单元。
实施本申请实施例，组播源确定建立组播组的相关信息(例如组播地址、组播密钥)后，通过与客户端的蓝牙交互，告知客户端上述相关信息，以邀请客户端加入组播组；这样，无需其他第三方设备参与，通过蓝牙辅助实现快捷建立组播组。进而在后续组播组传输阶段，组播源和各客户端无需建立Wifi连接，组播源也能通过WiFi通信技术组播发送组播报文，加入组播组的各客户端也能通过WiFi通信技术直接监听到组播源组播发送的组播报文；这样，无需受限于可关联的WiFi单播链路数量，也无需其他设备进行报文中转，就可以实现无WiFi连接的大规模的组播传输，提高了组播传输效率。
在一种实现方式中，上述组播源向第一客户端发送第一蓝牙消息之前，上述方法还包括：组播源开启第一虚拟接入点(Virtual Access Point，VAP)；上述组播源通过WiFi通信技术组播发送经第一组播密钥加密的第一组播报文，包括：组播源的第一VAP通过WiFi通信技术组播发送经第一组播密钥加密的第一组播报文。实施本申请实施例，用户的终端设备也可以作为组播源，通过开启VAP(例如WiFi热点)，实现通过WiFi通信技术组播发送组播报文。
在一种实现方式中，上述方法还包括：组播源接收第一操作，第一操作用于创建组播组；上述组播源确定组播组的组播地址和第一组播密钥，包括：响应于第一操作，组播源确定组播组的组播地址和第一组播密钥。实施本申请实施例，用户可以通过第一操作触发组播源建立组播组。例如，组播源设置有组播业务的用户界面(UI)入口，用户通过作用于该UI入口的第一操作，可以触发建立组播组。
在一种实现方式中，组播源向第一客户端发送第一蓝牙消息之前，上述方法还包括：组播源蓝牙扫描附近支持组播通信的蓝牙设备；组播源显示扫描到的至少一个蓝牙设备，上述至少一个蓝牙设备包括第一客户端；组播源接收第二操作，第二操作用于邀请第一客户端加入组播组；响应于第二操作，组播源与第一客户端建立蓝牙连接。实施本申请实施例，组播源建立组播组时，可以启动蓝牙发现服务，扫描附近支持组播的蓝牙设备；扫描到蓝牙设备后，组播源可以与用户选择的蓝牙设备建立蓝牙连接。这样，通过该蓝牙连接，组播源可以直接邀请该设备加入组播组，组播源和客户端间无需其他设备进行报文分发，提高了组播组的管理效率。
在一种实现方式中，组播源显示扫描到的至少一个蓝牙设备之前，上述方法还包括：第一客户端接收第三操作；响应于第三操作，第一客户端蓝牙广播第一发现信号，第一发现信号指示第一客户端支持组播通信；组播源基于第一发现信号扫描到第一客户端。实施本申请实施例，用户通过第三操作可以触发客户端启动蓝牙发现服务，蓝牙广播发现信号，并在发现信号中携带组播的能力标识，以便于被组播源发现，进而与组播源建立蓝牙连接。
在一种实现方式中，组播源向第一客户端发送第一蓝牙消息之前，上述方法还包括：响应于第一操作，组播源蓝牙广播第二发现信号；基于蓝牙监听到的第二发现信号，第一客户端与组播源建立蓝牙连接；第一客户端向组播源发送第三蓝牙消息，第三蓝牙消息用于请求加入组播组；上述组播源向第一客户端发送第一蓝牙消息，包括：响应于第三蓝牙消息，组播源向第一客户端发送第一蓝牙消息。实施本申请实施例，用户通过第一操作可以触发组播源启动蓝牙发现服务，蓝牙广播发现信号，以便于被客户端发现，进而与客户端建立蓝牙连接。组播源与客户端建立蓝牙连接后，客户端可以通过该蓝牙连接主动请求加入组播组。
在一种实现方式中，上述第一客户端向组播源发送第二蓝牙消息之后，还包括：断开组播源与第一客户端的蓝牙连接。实施本申请实施例，在组播源通过蓝牙连接邀请一个客户端加入组播组后，即可断开组播源与该客户端的蓝牙连接，删除蓝牙连接的相关信息，以便于节省蓝牙资源，降低设备负载。
在一种实现方式中，上述组播源向第一客户端发送第一蓝牙消息之前，还包括：组播源为组播源的第一VAP分配第一IP地址，为客户端的第二VAP分配第二IP地址；第一蓝牙消息还包括第一IP地址和第二IP地址；第一IP地址和第二IP地址用于封装组播报文，组播源发送的组播报文中的源IP地址为第一IP地址，第一客户端发送的组播报文中的源IP地址为第二IP地址。实施本申请实施例，组播源可以为本设备以及客户端分配用于组播的IP地址。
在一种实现方式中，上述方法还包括：基于第二蓝牙消息，第一组播源在组播设备列表中添加第一客户端的组播用户信息；组播设备列表用于存储组播组中的各客户端的组播用户信息，第一客户端的组播用户信息包括第一客户端的MAC地址和第二IP地址。实施本申请实施例，组播源邀请客户端加入组播组后，存储各客户端的组播用户信息，以便于对组播组种的客户端进行管理。
在一种实现方式中，上述组播源向第一客户端发送第一蓝牙消息之前，还包括：组播源生成虚拟组播源地址；组播源配置第一组播密钥对应的源地址为虚拟组播源地址；第一蓝牙消息还包括虚拟主播源地址，组播组中的客户端发送的组播报文的MAC头中的源地址为虚拟组播源地址。实施本申请实施例，各客户端采用同一虚拟组播源地址，以便于组播源可以通过虚拟组播源地址对应的组播密钥，解析所有客户端的组播报文。
在一种实现方式中，上述方法还包括：第一客户端通过WiFi通信技术组播发送经第一组播密钥加密的第二组播报文，第二组播报文的第二MAC头中的源地址为虚拟组播源地址，第二MAC头中的目的地址为组播地址；基于组播地址，组播源监听到第二组播报文；组播源确定第二MAC头中的源地址对应的密钥为第一组播密钥，并利用第一组播密钥解析第二组播报文的数据单元。实施本申请实施例，各客户端采用同一虚拟组播源地址，以便于组播源可以通过虚拟组播源地址对应的组播密钥，解析所有客户端的组播报文。
在一种实现方式中，上述组播源向第一客户端发送第一蓝牙消息之后，还包括：第一客户端基于第一蓝牙消息开启第二VAP；上述第一客户端通过WiFi通信技术组播发送经第一组播密钥加密的第二组播报文，包括：第一客户端的第二VAP通过WiFi通信技术组播发送经第一组播密钥加密的第二组播报文。实施本申请实施例，无需其他第三方设备，也可以实现组播组中的客户端组播发送组播报文，组播源监听到该组播报文，实现了高效的组播传输。
在一种实现方式中，组播报文的数据单元为MAC服务数据单元MSDU。
在一种实现方式中，组播报文的类型包括信令帧和数据帧，信令帧的组播类型包括控制信令帧和信令确认帧；第一组播报文包括第一控制信令帧，第二组播报文包括第一信令确认帧，第一信令确认帧是第一客户端基于第一控制信令帧生成的，第一信令确认帧用于指示组播源发送的控制信令帧的接收情况。实施本申请实施例，针对信令帧传输，提供了反馈机制；组播源可以针对组播组中的任一客户端发送控制信令帧，客户端可以反馈控制信令帧的接收情况，以便于组播源根据接收情况做出进一步决策，进而提高信号传输可靠性。
在一种实现方式中，组播报文的类型包括信令帧和数据帧，信令帧的组播类型包括控制信令帧和信令确认帧；第二组播报文包括第一控制信令帧，第一组播报文包括第一信令确认帧，第一信令确认帧是组播源基于第一控制信令帧生成的，第一信令确认帧用于指示第一客户端发送的控制信令帧的接收情况。实施本申请实施例，针对信令帧传输，提供了反馈机制；组播组中的任一客户端可以针对组播源发送控制信令帧，组播源可以反馈控制信令帧的接收情况，以便于客户端根据接收情况做出进一步决策，进而提高组播传输可靠性。
在一种实现方式中，信令帧中的数据单元包括信令帧的接收端对应的实际目的地址和信令帧的发送端对应的实际源地址；控制信令帧的数据单元还包括控制标识和数据载荷，数据载荷用于传输有效的控制信令，控制标识用于指示控制信令帧的编号；信令确认帧的数据单元还包括确认信息，确认信息用于指示信令确认帧的接收端已发送的控制信令帧的接收情况。实施本申请实施例，信令帧可以携带接收端对应的实际目的地址和发送端对应的实际源地址，以便于接收端确定该信令帧是否是发送给本设备的，以及发送端是否属于组播组；这样，可以通过组播传输间接实现组播源和客户端的一对一单播。
在一种实现方式中，第一客户端为组播源设置了一个接收窗口，用于维护来自组播源的控制信令帧的接收信息；组播源为第一客户端设置一个发送窗口，用于维护发送给第一客户端的控制信令帧的发送信息；上述方法还包括；第一客户端基于第一控制信令帧更新组播源对应的接收窗口，并基于更新后的接收窗口确定第一信令确认帧；第一信令确认帧指示发送窗口维护的第二控制信令帧未被接收；组播源基于第一信令确认帧更新第一客户端对应的发送窗口，确定是否重传第二控制信令帧。实施本申请实施例，针对信令帧传输，提供了反馈机制和重传机制；针对客户端反馈的接收情况，组播源可以确定是否重传未被该客户端接收的控制信令帧，进而提高组播传输可靠性。
在一种实现方式中，信令帧还包括组播类型；信令帧的组播类型为控制信令帧时，信令帧还包括控制信令帧的子类型，控制信令帧的子类型包括第一子类型和第二子类型，第一子类型和第二子类型对应的处理模块不同；上述方法还包括：第一客户端根据第一控制信令帧中的第一子类型，将第一控制信令帧提交给第一子类型对应的处理模块进行处理。实施本申请实施例，根据控制信令帧的子类型，可以对其进行分类处理。
在一种实现方式中，接收窗口包括M个小窗口，M为正整数；接收窗口中的小窗口，按照接收到的组播源的控制信令帧的控制标识，依序维护控制信令帧的接收信息；接收窗口中的一个小窗口维护的接收信息包括控制信令帧的控制标识和接收标识；接收标识用于指示控制信令帧是否已接收；接收窗口的第一上沿UE指接收窗口维护的已接收的控制信令帧的控制标识的最大值，接收窗口的第一下沿LE指接收窗口维护的未接收的控制信令帧的控制标识的最小值；发送窗口包M个小窗口；发送窗口中的小窗口，按照向第一客户端发送的控制信令帧的控制标识，依序维护控制信令帧的发送信息；一个小窗口维护的发送信息包括控制信令帧的控制标识；发送窗口的第二UE指发送窗口维护的未被接收的控制信令帧的控制标识的最大值，发送窗口的第二LE指发送窗口维护的未接收的控制信令帧的控制标识的最小值。实施本申请实施例，每个客户端针对组播源，可以利用发送窗口和接收窗口维护其发送和接收的控制信令帧；组播源针对组播组中的每个客户端，也可以利用发送窗口和接收窗口维护其发送和接收的控制信令帧；进而可以基于接收窗口进行反馈，基于发送窗口进行重传，以提高组播传输可靠性。
在一种实现方式中，第一信令确认帧中的确认信息包括接收窗口的第一UE和第一LE，以及位图，位图依序指示了接收窗口中第一LE指向的小窗口至第一UE指向的小窗口维护的控制信令帧的接收情况。实施本申请实施例，客户端可以利用接收窗口的UE、LE和位图反馈控制信令帧的接收情况，以便于组播源根据接收情况做出进一步决策，进而提高组播传输可靠性。
在一种实现方式中，上述第一客户端基于第一控制信令帧更新组播源对应的接收窗口，包括：根据第一控制信令帧中的实际目的地址，确定是发送给本设备的组播帧，且根据第一控制信令帧中的实际源地址，确定第一控制信令帧的发送端属于组播组时，基于第一控制信令帧中的实际源地址获取组播源对应的接收窗口，第一客户端基于第一控制信令帧更新组播源对应的接收窗口。实施本申请实施例，信令帧可以携带接收端对应的实际目的地址和发送端对应的实际源地址，以便于接收端确定该信令帧是否是发送给本设备的，以及发送端是否属于组播组；这样，可以通过组播传输间接实现组播源和客户端的一对一单播。
在一种实现方式中，上述第一客户端基于第一控制信令帧更新组播源对应的接收窗口，包括：根据第一控制信令帧的控制标识，确定用于维护第一控制信令帧的小窗口的第一索引，第一索引等于第一控制信令帧的控制标识除以M后的余数；根据第一LE和第一UE确定接收窗口已满时，将第一LE指向的小窗口至第一索引对应的小窗口清空；确定接收窗口未满时，若第一索引对应的小窗口的接收标识取值为第一值，丢弃第一控制信令帧，若第一索引对应的小窗口的接收标识取值为第二值，则将第一索引对应的小窗口的接收标识的取值更新为第一值；接收标识取值为第一值，指示控制信令帧已被接收；接收标识取值为第二值，指示控制信令帧未被接收；第一控制信令帧的控制标识大于第一UE时，将第一UE的取值更新为第一控制信令帧的控制标识；确定第一LE指向的小窗口及其之后的小窗口中第一个接收标识为第二值的第一小窗口，并将第一LE的取值更新为第一小窗口的控制标识。实施本申请实施例，组播组中的客户端可以根据来自组播源的控制信令帧，更新组播源对应的接收窗口。
在一种实现方式中，上述组播源基于第一信令确认帧更新所UE述第一客户端对应的发送窗口，包括：根据第一信令确认帧中的实际目的地址，确定是发送给本设备的组播帧，且根据第一信令确认帧中的实际源地址，确定第一控制信令帧的发送端是否属于组播组时，根据第一信令确认帧中的实际源地址获取第一客户端对应的发送窗口，组播源基于第一信令确认帧更新第一客户端对应的发送窗口。实施本申请实施例，信令帧可以携带接收端对应的实际目的地址和发送端对应的实际源地址，以便于接收端确定该信令帧是否是发送给本设备的，以及发送端是否属于组播组；这样，可以通过组播传输间接实现组播源和客户端的一对一单播。
在一种实现方式中，上述组播源基于第一信令确认帧更新第一客户端对应的发送窗口，包括:基于第一信令确认帧中的确认信息，确定第一LE大于等于发送窗口的第二LE，且第一UE小于等于第二UE时，组播源基于第一信令确认帧更新第一客户端对应的发送窗口。实施本申请实施例，组播源可以根据信令确认帧中的LE和UE，过滤掉过时的或错误的信令确认帧。
在一种实现方式中，发送窗口中的一个小窗口维护的发送信息还包括发送状态和存储地址，发送状态用于指示控制信令帧是否已被接收，存储地址用于指示控制信令帧的缓存地址；上述组播源基于第一信令确认帧更新第一客户端对应的发送窗口，包括:第一LE大于第二LE时，清空发送窗口中第二LE指向的小窗口至第一LE指向的小窗口的前一个小窗口，并更新第二LE的取值为第一LE的取值；第一LE等于第二LE时，遍历发送窗口中第一LE指向的小窗口至第一UE指向的小窗口中，位图指示的控制信令帧已被接收的第二小窗口，释放第二小窗口的存储地址缓存的控制信令帧。实施本申请实施例，组播源可以根据来自组播组中的任一客户端的信令确认帧，更新该客户端对应的发送窗口。
在一种实现方式中，发送窗口的一个小窗口维护的发送信息还包括重传标识和重传次数，重传标识用于指示在本重传周期内是否被重传过，重传次数用于指示控制信令帧被重传的次数；上述确定是否重传第二控制信令帧，包括：第一LE等于第二LE时，遍历发送窗口中第一LE指向的小窗口至第一UE指向的小窗口中，位图指示的控制信令帧未被接收的第三小窗口，第三小窗口维护的第二控制信令帧满足重传条件式时，确定向第一客户端重传第二控制信令帧，更新第三小窗口对应的重传标识为第一值，重传次数加1；重传标识取值为第一值，指示控制信令帧在本重传周期内被重传过。实施本申请实施例，针对信令帧传输，提供重传机制；针对客户端反馈的信令确认帧，组播源可以确定是否重传未被该客户端接收的控制信令帧，进而提高组播传输可靠性。
在一种实现方式中，上述重传条件包括：第三小窗口的重传标识为第二值，重传次数小于第一预设值；重传标识取值为第二值，指示控制信令帧在本重传周期内未被重传过。
在一种实现方式中，上述方法还包括：第一客户端对其维护的组播源对应的接收窗口进行周期性地超时处理。实施本申请实施例，可以定期对每个接收窗口进行超时处理，以避免接收窗口已满，无法继续处理新的控制信令帧的接收信息。
在一种实现方式中，接收窗口的一个小窗口维护的接收信息还包括轮询次数，上述第一客户端对其维护的组播源对应的接收窗口进行周期性地超时处理，包括：确定接收窗口中第一LE指向的小窗口至第一UE指向的小窗口中，接收标识为第二值的第四小窗口，将第四小窗口的轮询次数加1；第四小窗口的轮询次数大于第二预设值时，清空第一LE指向的小窗口至第四小窗口；确定接收窗口中第四小窗口之后的第一个接收标识为第二值的第五小窗口；更新接收窗口的第一LE为第五小窗口的控制标识。实施本申请实施例，可以定期对每个接收窗口进行超时处理，以避免接收窗口已满，无法继续处理新的控制信令帧的接收信息。
在一种实现方式中，上述方法还包括：组播源对其维护的第一客户端对应的发送窗口进行周期性地超时处理。实施本申请实施例，可以定期对每个发送窗口进行超时处理，以避免发送窗口已满，无法继续处理新的控制信令帧的发送信息。
在一种实现方式中，上述组播源对其维护的第一客户端对应的发送窗口进行周期性地超时处理，包括：遍历发送窗口中第二LE指向的小窗口至第二UE指向的小窗口中，发送状态为第二值的第六小窗口；发送状态取值为第二值，指示控制信令帧未被接收；将第六小窗口对应的轮询次数加1；第六小窗口的轮询次数大于等于第三预设值时，确定第六小窗口是否满足重传条件；满足重传条件时，确定重传第六小窗口维护的控制信令帧，并将第六小窗口的轮询次数置为0，重传标识置为第一值，重传次数加1；不满足重传条件且重传次数超过第五预设值时，清空第六小窗口，并释放第六小窗口的存储地址缓存的控制信令帧；确定第二LE等于发送窗口中发送状态为第二值且控制标识最小的小窗口的控制标识。实施本申请实施例，可以定期对每个发送窗口进行超时处理，以避免发送窗口已满，无法继续处理新的控制信令帧的发送信息。
在一种实现方式中，还包括：第一客户端和组播源建立蓝牙连接，并向组播源发送第四蓝牙消息，第四蓝牙消息用于请求退出组播组；组播源向第一客户端发送第五蓝牙消息，并删除第一客户端的组播用户信息，第五蓝牙消息用于指示确认第一客户端退出组播组；第一客户端蓝牙监听到第五蓝牙消息，基于第五蓝牙消息删除客户端侧的第二组播组信息；第二组播组信息包括组播地址和第一组播密钥；第一客户端和组播源断开蓝牙连接。实施本申请实施例，组播组中的成员是动态的，任一客户端可以主动退出组播组，并通过蓝牙连接通知组播源，以便于组播源管理组播组中的客户端。
在一种实现方式中，上述第一客户端和组播源建立蓝牙连接，并向组播源发送第四蓝牙消息，包括：第一客户端接收第四操作；响应于第四操作，第一客户端和组播源建立蓝牙连接，并向组播源发送第四蓝牙消息；上述方法还包括：响应于第四操作，第一客户端关闭组播应用。实施本申请实施例，用户可以通过第四操作触发客户端主动退出组播组，关闭组播应用。
在一种实现方式中，组播源蓝牙广播第六蓝牙消息，并删除组播源侧的第一组播组信息；第六蓝牙消息用于指示删除组播组，第一组播组信息包括组播设备列表、第一组播密钥和组播地址；第一客户端蓝牙监听到第六蓝牙消息，基于第六蓝牙消息删除客户端侧的第二组播组信息；第二组播组信息包括组播地址和第一组播密钥。实施本申请实施例，组播组中的成员是动态的，组播源可以删除组播组，并通过蓝牙广播通知组播组中的客户端，以便于客户端删除该组播组的相关信息。
在一种实现方式中，上述组播源蓝牙广播第六蓝牙消息，包括：组播源接收第五操作；响应于第五操作，组播源蓝牙广播第六蓝牙消息；上述方法还包括：响应于第五操作，关闭组播应用。实施本申请实施例，用户可以通过第五操作触发客户端主动退出组播组，关闭组播应用。
第二方面，本申请提供组播通信方法，上述方法包括：组播源确定组播组的组播地址和第一组播密钥；组播源向第一客户端发送第一蓝牙消息，第一蓝牙消息用于邀请第一客户端加入组播组，第一蓝牙消息包括组播地址和第一组播密钥；组播源接收到第一客户端发送的第二蓝牙消息；第二蓝牙消息用于指示第一客户端确认加入组播组，在第一客户端侧第一组播密钥对应的源地址为组播源的MAC地址；组播源通过WiFi通信技术组播发送经第一组播密钥加密的第一组播报文，第一组播报文的第一MAC头中的源地址为组播源的MAC地址，第一MAC头中的目的地址为组播地址。
实施本申请实施例，组播源确定建立组播组的相关信息(例如组播地址、组播密钥)后，通过与客户端的蓝牙交互，告知客户端上述相关信息，以邀请客户端加入组播组；这样，无需其他第三方设备参与，通过蓝牙辅助实现快捷建立组播组。进而在后续组播组传输阶段，组播源和各客户端无需建立Wifi连接，组播源也能通过WiFi通信技术组播发送组播报文，加入组播组的各客户端也能通过WiFi通信技术直接监听到组播源组播发送的组播报文；这样，无需受限于可关联的WiFi单播链路数量，也无需其他设备进行报文中转，就可以实现无WiFi连接的大规模的组播传输，提高了组播传输效率。
在一种实现方式中，组播源向第一客户端发送第一蓝牙消息之前，上述方法还包括：组播源开启第一虚拟接入点VAP；上述组播源通过WiFi通信技术组播发送经第一组播密钥加密的第一组播报文，包括：组播源的第一VAP通过WiFi通信技术组播发送经第一组播密钥加密的第一组播报文。
在一种实现方式中，上述方法还包括：组播源接收第一操作，第一操作用于创建组播组；组播源确定组播组的组播地址和第一组播密钥，包括：响应于第一操作，组播源确定组播组的组播地址和第一组播密钥。
在一种实现方式中，上述组播源向第一客户端发送第一蓝牙消息之前上述方法还包括：组播源蓝牙扫描附近支持组播通信的蓝牙设备；组播源显示扫描到的至少一个蓝牙设备，上述至少一个蓝牙设备包括第一客户端；组播源接收第二操作，第二操作用于邀请第一客户端加入组播组；响应于第二操作，组播源与第一客户端建立蓝牙连接。
在一种实现方式中，上述组播源接收到第一客户端发送的第二蓝牙消息之后，还包括：断开组播源与第一客户端的蓝牙连接。
在一种实现方式中，上述组播源向第一客户端发送第一蓝牙消息之前，还包括：组播源为组播源的第一VAP分配第一IP地址，为客户端的第二VAP分配第二IP地址；第一蓝牙消息还包括第一IP地址和第二IP地址；第一IP地址和第二IP地址用于封装组播报文，组播源发送的组播报文中的源IP地址为第一IP地址，第一客户端发送的组播报文中的源IP地址为第二IP地址。
在一种实现方式中，上述方法还包括：基于第二蓝牙消息，第一组播源在组播设备列表中添加第一客户端的组播用户信息；组播设备列表用于存储组播组中的各客户端的组播用户信息，第一客户端的组播用户信息包括第一客户端的MAC地址和第二IP地址。
在一种实现方式中，上述组播源向第一客户端发送第一蓝牙消息之前，还包括：组播源生成虚拟组播源地址；组播源配置第一组播密钥对应的源地址为虚拟组播源地址；第一蓝牙消息还包括虚拟主播源地址，组播组中的客户端发送的组播报文的MAC头中的源地址为虚拟组播源地址。
在一种实现方式中，上述方法还包括：基于组播地址，组播源通过WiFi通信技术监听到来自第一客户端的第二组播报文；第二组播报文的第二MAC头中的源地址为虚拟组播源地址，第二MAC头中的目的地址为组播地址；组播源确定第二MAC头中的源地址对应的密钥为第一组播密钥，并利用第一组播密钥解析第二组播报文的数据单元。
在一种实现方式中，组播报文的数据单元为MAC服务数据单元MSDU。
在一种实现方式中，组播报文的类型包括信令帧和数据帧，信令帧的组播类型包括控制信令帧和信令确认帧；第一组播报文包括第一控制信令帧，第二组播报文包括第一信令确认帧，第一信令确认帧是第一客户端基于第一控制信令帧生成的，第一信令确认帧用于指示组播源发送的控制信令帧的接收情况。
在一种实现方式中，组播报文的类型包括信令帧和数据帧，信令帧的组播类型包括控制信令帧和信令确认帧；第二组播报文包括第一控制信令帧，第一组播报文包括第一信令确认帧，第一信令确认帧是组播源基于第一控制信令帧生成的，第一信令确认帧用于指示第一客户端发送的控制信令帧的接收情况。
在一种实现方式中，第一客户端为组播源设置了一个接收窗口，用于维护来自组播源的控制信令帧的接收信息；组播源为第一客户端设置一个发送窗口，用于维护发送给第一客户端的控制信令帧的发送信息；第一控制信令帧用于第一客户端更新组播源对应的接收窗口，并基于更新后的接收窗口确定第一信令确认帧；第一信令确认帧指示发送窗口维护的第二控制信令帧未被接收；上述方法还包括；组播源基于第一信令确认帧更新第一客户端对应的发送窗口，确定是否重传第二控制信令帧。
在一种实现方式中，信令帧中的数据单元包括信令帧的接收端对应的实际目的地址和信令帧的发送端对应的实际源地址；控制信令帧的数据单元还包括控制标识和数据载荷，数据载荷用于传输有效的控制信令，控制标识用于指示控制信令帧的编号；信令确认帧的数据单元还包括确认信息，确认信息用于指示信令确认帧的接收端已发送的控制信令帧的接收情况。
在一种实现方式中，信令帧还包括组播类型；信令帧的组播类型为控制信令帧时，信令帧还包括控制信令帧的子类型，控制信令帧的子类型包括第一子类型和第二子类型，第一子类型和第二子类型对应的处理模块不同。
在一种实现方式中，接收窗口包括M个小窗口，M为正整数；接收窗口中的小窗口，按照接收到的组播源的控制信令帧的控制标识，依序维护控制信令帧的接收信息；接收窗口中的一个小窗口维护的接收信息包括控制信令帧的控制标识和接收标识；接收标识用于指示控制信令帧是否已接收；接收窗口的第一上沿UE指接收窗口维护的已接收的控制信令帧的控制标识的最大值，接收窗口的第一下沿LE指接收窗口维护的未接收的控制信令帧的控制标识的最小值；发送窗口包M个小窗口；发送窗口中的小窗口，按照向第一客户端发送的控制信令帧的控制标识，依序维护控制信令帧的发送信息；一个小窗口维护的发送信息包括控制信令帧的控制标识；发送窗口的第二UE指发送窗口维护的未被接收的控制信令帧的控制标识的最大值，发送窗口的第二LE指发送窗口维护的未接收的控制信令帧的控制标识的最小值。
在一种实现方式中，第一信令确认帧中的确认信息包括接收窗口的第一UE和第一LE，以及位图，位图依序指示了接收窗口中第一LE指向的小窗口至第一UE指向的小窗口维护的控制信令帧的接收情况。
在一种实现方式中，上述组播源基于第一信令确认帧更新所UE述第一客户端对应的发送窗口，包括：根据第一信令确认帧中的实际目的地址，确定是发送给本设备的组播帧，且根据第一信令确认帧中的实际源地址，确定第一控制信令帧的发送端是否属于组播组时，根据第一信令确认帧中的实际源地址获取第一客户端对应的发送窗口，组播源基于第一信令确认帧更新第一客户端对应的发送窗口。
在一种实现方式中，组播源基于第一信令确认帧更新第一客户端对应的发送窗口，包括:基于第一信令确认帧中的确认信息，确定第一LE大于等于发送窗口的第二LE，且第一UE小于等于第二UE时，组播源基于第一信令确认帧更新第一客户端对应的发送窗口。
在一种实现方式中，发送窗口中的一个小窗口维护的发送信息还包括发送状态和存储地址，发送状态用于指示控制信令帧是否已被接收，存储地址用于指示控制信令帧的缓存地址；组播源基于第一信令确认帧更新第一客户端对应的发送窗口，包括:第一LE大于第二LE时，清空发送窗口中第二LE指向的小窗口至第一LE指向的小窗口的前一个小窗口，并更新第二LE的取值为第一LE的取值；第一LE等于第二LE时，遍历发送窗口中第一LE指向的小窗口至第一UE指向的小窗口中，位图指示的控制信令帧已被接收的第二小窗口，释放第二小窗口的存储地址缓存的控制信令帧。
在一种实现方式中，发送窗口的一个小窗口维护的发送信息还包括重传标识和重传次数，重传标识用于指示在本重传周期内是否被重传过，重传次数用于指示控制信令帧被重传的次数；上述确定是否重传第二控制信令帧，包括：第一LE等于第二LE时，遍历发送窗口中第一LE指向的小窗口至第一UE指向的小窗口中，位图指示的控制信令帧未被接收的第三小窗口，第三小窗口维护的第二控制信令帧满足重传条件式时，确定向第一客户端重传第二控制信令帧，更新第三小窗口对应的重传标识为第一值，重传次数加1；重传标识取值为第一值，指示控制信令帧在本重传周期内被重传过。
在一种实现方式中，重传条件包括：第三小窗口的重传标识为第二值，重传次数小于第一预设值；重传标识取值为第二值，指示控制信令帧在本重传周期内未被重传过。
在一种实现方式中，上述方法还包括：组播源对其维护的第一客户端对应的发送窗口进行周期性地超时处理。
在一种实现方式中，上述组播源对其维护的第一客户端对应的发送窗口进行周期性地超时处理，包括：遍历发送窗口中第二LE指向的小窗口至第二UE指向的小窗口中，发送状态为第二值的第六小窗口；发送状态取值为第二值，指示控制信令帧未被接收；将第六小窗口对应的轮询次数加1；第六小窗口的轮询次数大于等于第三预设值时，确定第六小窗口是否满足重传条件；满足重传条件时，确定重传第六小窗口维护的控制信令帧，并将第六小窗口的轮询次数置为0，重传标识置为第一值，重传次数加1；不满足重传条件且重传次数超过第五预设值时，清空第六小窗口，并释放第六小窗口的存储地址缓存的控制信令帧；确定第二LE等于发送窗口中发送状态为第二值且控制标识最小的小窗口的控制标识。
在一种实现方式中，还包括：组播源和第一客户端建立了蓝牙连接；组播源接收第一客户端发送的第四蓝牙消息，第四蓝牙消息用于请求退出组播组；组播源向第一客户端发送第五蓝牙消息，并删除第一客户端的组播用户信息，第五蓝牙消息用于指示确认第一客户端退出组播组；组播源和第一客户端断开蓝牙连接。
在一种实现方式中，还包括：组播源蓝牙广播第六蓝牙消息，并删除组播源侧的第一组播组信息；第六蓝牙消息用于指示删除组播组，第一组播组信息包括组播设备列表、第一组播密钥和组播地址。
在一种实现方式中，上述组播源蓝牙广播第五蓝牙消息，包括：组播源接收第五操作；响应于第五操作，组播源蓝牙广播第六蓝牙消息；上述方法还包括：响应于第五操作，关闭组播应用。
第三方面，本申请提供组播通信方法，上述方法包括：第一客户端接收组播源发送的第一蓝牙消息，第一蓝牙消息用于邀请第一客户端加入组播组，第一蓝牙消息包括组播组的组播地址和第一组播密钥；第一客户端基于第一蓝牙消息，向组播源发送第二蓝牙消息；第二蓝牙消息用于指示第一客户端确认加入组播组；第一客户端配置第一组播密钥对应的源地址为组播源的MAC地址；基于组播地址，第一客户端通过WiFi通信技术监听到组播源发送的第一组播报文，第一组播报文的第一MAC头中的源地址为组播源的MAC地址，第一MAC头中的目的地址为组播地址；第一客户端确定第一MAC头中的源地址对应的密钥为第一组播密钥，并利用第一组播密钥解析第一组播报文的数据单元。
实施本申请实施例，组播源通过与客户端的蓝牙交互，告知客户端组播组的相关信息(例如组播地址、组播密钥)，以邀请客户端加入组播组；这样，无需其他第三方设备参与，通过蓝牙辅助实现快捷建立组播组。进而在后续组播组传输阶段，组播源和各客户端无需建立Wifi连接，组播源也能通过WiFi通信技术组播发送组播报文，加入组播组的各客户端也能通过WiFi通信技术直接监听到组播源组播发送的组播报文；这样，无需受限于可关联的WiFi单播链路数量，也无需其他设备进行报文中转，就可以实现无WiFi连接的大规模的组播传输，提高了组播传输效率。
在一种实现方式中，还包括：第一客户端基于第一蓝牙消息开启第二VAP；上述第一客户端通过WiFi通信技术监听到组播源发送的第一组播报文，包括：第一客户端的第二VAP通过WiFi通信技术监听到组播源发送的第一组播报文。
在一种实现方式中，上述第一客户端接收组播源发送的第一蓝牙消息之前，上述方法还包括：第一客户端接收第三操作；响应于第三操作，第一客户端蓝牙广播第一发现信号，第一发现信号指示第一客户端支持组播通信，第一发现信号用于与组播源建立蓝牙连接；第一客户端与组播源建立蓝牙连接。
在一种实现方式中，第一客户端接收组播源发送的第一蓝牙消息之前，上述方法还包括：第一客户端蓝牙监听到来自组播源的第二发现信号；基于第二发现信号，第一客户端与组播源建立蓝牙连接；第一客户端向组播源发送第三蓝牙消息，第三蓝牙消息用于请求加入组播组，第一蓝牙消息是组播源基于第三蓝牙消息发送的。
在一种实现方式中，上述第一客户端向组播源发送第二蓝牙消息之后，还包括：断开组播源与第一客户端的蓝牙连接。
在一种实现方式中，第一蓝牙消息还包括虚拟主播源地址，第一客户端发送的组播报文的MAC头中的源地址为虚拟组播源地址，在组播源侧第一组播密钥对应的源地址为虚拟组播源地址。
在一种实现方式中，上述方法还包括：第一客户端通过WiFi通信技术组播发送经第一组播密钥加密的第二组播报文，第二组播报文的第二MAC头中的源地址为虚拟组播源地址，第二MAC头中的目的地址为组播地址。
在一种实现方式中，其特征在于，上述方法还包括：第一客户端基于第一蓝牙消息开启第二VAP；上述第一客户端通过WiFi通信技术组播发送经第一组播密钥加密的第二组播报文，包括：第一客户端的第二VAP通过WiFi通信技术组播发送经第一组播密钥加密的第二组播报文。
在一种实现方式中，组播报文的数据单元为MAC服务数据单元MSDU。
在一种实现方式中，组播报文的类型包括信令帧和数据帧，信令帧的组播类型包括控制信令帧和信令确认帧；第一组播报文包括第一控制信令帧，第二组播报文包括第一信令确认帧，第一信令确认帧是第一客户端基于第一控制信令帧生成的，第一信令确认帧用于指示组播源发送的控制信令帧的接收情况。
在一种实现方式中，组播报文的类型包括信令帧和数据帧，信令帧的组播类型包括控制信令帧和信令确认帧；第二组播报文包括第一控制信令帧，第一组播报文包括第一信令确认帧，第一信令确认帧是组播源基于第一控制信令帧生成的，第一信令确认帧用于指示第一客户端发送的控制信令帧的接收情况。
在一种实现方式中，第一客户端为组播源设置了一个接收窗口，用于维护来自组播源的控制信令帧的接收信息；组播源为第一客户端设置一个发送窗口，用于维护发送给第一客户端的控制信令帧的发送信息；上述方法还包括；第一客户端基于第一控制信令帧更新组播源对应的接收窗口，并基于更新后的接收窗口确定第一信令确认帧；第一信令确认帧指示发送窗口维护的第二控制信令帧未被接收；第一信令确认帧用于更新第一客户端对应的发送窗口，以及确定是否重传第二控制信令帧。
在一种实现方式中，信令帧中的数据单元包括信令帧的接收端对应的实际目的地址和信令帧的发送端对应的实际源地址；控制信令帧的数据单元还包括控制标识和数据载荷，数据载荷用于传输有效的控制信令，控制标识用于指示控制信令帧的编号；信令确认帧的数据单元还包括确认信息，确认信息用于指示信令确认帧的接收端已发送的控制信令帧的接收情况。
在一种实现方式中，信令帧还包括组播类型；信令帧的组播类型为控制信令帧时，信令帧还包括控制信令帧的子类型，控制信令帧的子类型包括第一子类型和第二子类型，第一子类型和第二子类型对应的处理模块不同；上述方法还包括：第一客户端根据第一控制信令帧中的第一子类型，将第一控制信令帧提交给第一子类型对应的处理模块进行处理。
在一种实现方式中，接收窗口包括M个小窗口，M为正整数；接收窗口中的小窗口，按照接收到的组播源的控制信令帧的控制标识，依序维护控制信令帧的接收信息；接收窗口中的一个小窗口维护的接收信息包括控制信令帧的控制标识和接收标识；接收标识用于指示控制信令帧是否已接收；接收窗口的第一上沿UE指接收窗口维护的已接收的控制信令帧的控制标识的最大值，接收窗口的第一下沿LE指接收窗口维护的未接收的控制信令帧的控制标识的最小值；发送窗口包M个小窗口；发送窗口中的小窗口，按照向第一客户端发送的控制信令帧的控制标识，依序维护控制信令帧的发送信息；一个小窗口维护的发送信息包括控制信令帧的控制标识；发送窗口的第二UE指发送窗口维护的未被接收的控制信令帧的控制标识的最大值，发送窗口的第二LE指发送窗口维护的未接收的控制信令帧的控制标识的最小值。
在一种实现方式中，第一信令确认帧中的确认信息包括接收窗口的第一UE和第一LE，以及位图，位图依序指示了接收窗口中第一LE指向的小窗口至第一UE指向的小窗口维护的控制信令帧的接收情况。
在一种实现方式中，上述第一客户端基于第一控制信令帧更新组播源对应的接收窗口，包括：根据第一控制信令帧中的实际目的地址，确定是发送给本设备的组播帧，且根据第一控制信令帧中的实际源地址，确定第一控制信令帧的发送端属于组播组时，基于第一控制信令帧中的实际源地址获取组播源对应的接收窗口，第一客户端基于第一控制信令帧更新组播源对应的接收窗口。
在一种实现方式中，上述第一客户端基于第一控制信令帧更新组播源对应的接收窗口，包括：根据第一控制信令帧的控制标识，确定用于维护第一控制信令帧的小窗口的第一索引，第一索引等于第一控制信令帧的控制标识除以M后的余数；根据第一LE和第一UE确定接收窗口已满时，将第一LE指向的小窗口至第一索引对应的小窗口清空；确定接收窗口未满时，若第一索引对应的小窗口的接收标识取值为第一值，丢弃第一控制信令帧，若第一索引对应的小窗口的接收标识取值为第二值，则将第一索引对应的小窗口的接收标识的取值更新为第一值；接收标识取值为第一值，指示控制信令帧已被接收；接收标识取值为第二值，指示控制信令帧未被接收；第一控制信令帧的控制标识大于第一UE时，将第一UE的取值更新为第一控制信令帧的控制标识；确定第一LE指向的小窗口及其之后的小窗口中第一个接收标识为第二值的第一小窗口，并将第一LE的取值更新为第一小窗口的控制标识。
在一种实现方式中，上述方法还包括：第一客户端对其维护的组播源对应的接收窗口进行周期性地超时处理。
在一种实现方式中，接收窗口的一个小窗口维护的接收信息还包括轮询次数，上述第一客户端对其维护的组播源对应的接收窗口进行周期性地超时处理，包括：确定接收窗口中第一LE指向的小窗口至第一UE指向的小窗口中，接收标识为第二值的第四小窗口，将第四小窗口的轮询次数加1；第四小窗口的轮询次数大于第二预设值时，清空第一LE指向的小窗口至第四小窗口；确定接收窗口中第四小窗口之后的第一个接收标识为第二值的第五小窗口；更新接收窗口的第一LE为第五小窗口的控制标识。
在一种实现方式中，还包括：第一客户端和组播源建立蓝牙连接，并向组播源发送第四蓝牙消息，第四蓝牙消息用于请求退出组播组；第一客户端接收到组播源发送的第五蓝牙消息，第五蓝牙消息用于指示确认第一客户端退出组播组；第一客户端基于第五蓝牙消息删除客户端侧的第二组播组信息；第二组播组信息包括组播地址和第一组播密钥；第一客户端和组播源断开蓝牙连接。
在一种实现方式中，上述第一客户端和组播源建立蓝牙连接，并向组播源发送第四蓝牙消息，包括：第一客户端接收第四操作；响应于第四操作，第一客户端和组播源建立蓝牙连接，并向组播源发送第四蓝牙消息；上述方法还包括：响应于第四操作，第一客户端关闭组播应用。
在一种实现方式中，还包括：第一客户端蓝牙监听到来自组播源的第六蓝牙消息；第六消息用于指示删除组播组；第一客户端基于第六蓝牙消息删除客户端侧的第二组播组信息；第二组播组信息包括组播地址和第一组播密钥。
第四方面，本申请提供了一种通信装置，包括：一个或多个处理器和一个或多个存储器。该一个或多个存储器与一个或多个处理器耦合，一个或多个存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，使得通信装置执行上述第二方面任一项可能的实现方式中的组播通信方法。
第五方面，本申请提供了一种通信装置，包括一个或多个处理器和一个或多个存储器。该一个或多个存储器与一个或多个处理器耦合，一个或多个存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，使得通信装置执行上述第三方面任一项可能的实现方式中的组播通信方法。
第六方面，本申请实施例提供了一种计算机存储介质，包括计算机指令，当计算机指令在电子设备上运行时，使得通信装置执行上述任一方面任一项可能的实现方式中的组播通信方法。
第七方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行上述任一方面任一项可能的实现方式中的组播通信方法。
附图说明
图1为本申请实施例提供的一种组播系统示意图；
图2A为本申请实施例提供的另一种组播系统示意图；
图2B为本申请实施例提供的一种组播传输方式的示意图；
图2C为本申请实施例提供的一种建立WiFi连接的流程示意图；
图2D为本申请实施例提供的另一种组播系统示意图；
图2E为本申请实施例提供的一种软件架构图；
图3A至图3G为本申请实施例提供的组播组建立的相关用户界面；
图4A至图4I为本申请实施例提供的客户端主动加入组播组的相关界面；
图5A至图5D为本申请实施例提供的组播组删除的相关用户界面；
图6A为本申请实施例提供的组播通信方法的阶段示意图；
图6B为本申请实施例提供的另一种组播传输方式的示意图；
图7A为本申请实施例提供的一种组播启动阶段的方法流程图；
图7B为本申请实施例提供的一种组播源邀请阶段的方法流程图；
图7C为本申请实施例提供的一种客户端主动加入阶段的方法流程图；
图8为本申请实施例提供的一种组播传输阶段的方法流程图；
图9A为本申请实施例提供的一种控制信令帧的帧格式示意图；
图9B为本申请实施例提供的一种信令确认帧的帧格式示意图；
图9C为本申请实施例提供的一种信令帧传输阶段的方法流程图；
图10A和图10B为本申请实施例提供的接收窗口的示意图；
图10C为本申请实施例提供的一种更新接收窗口的方法流程图；
图10D为本申请实施例提供的一种更新接收窗口的方法流程图；
图10E为本申请实施例提供的接收窗口的示意图；
图10F为本申请实施例提供的发送窗口的超时处理的流程示意图；
图10G为本申请实施例提供的接收窗口的示意图；
图11A为本申请实施例提供的发送窗口的示意图；
图11B为本申请实施例提供的一种更新发送窗口的方法流程图；
图11C为本申请实施例提供的一种更新发送窗口的方法流程图；
图11D为本申请实施例提供的发送窗口的示意图；
图11E为本申请实施例提供的发送窗口的超时处理的流程示意图；
图12A为本申请实施例提供的一种客户端主动退出阶段的方法流程图；
图12B为本申请实施例提供的一种组播源删除阶段的方法流程图；
图13为本申请实施例提供的一种组播源的结构示意图。
具体实施方式
下面将结合附图对本申请实施例中的技术方案进行清楚、详尽地描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；文本中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，另外，在本申请实施例的描述中，“多个”是指两个或多于两个。
以下，术语“第一”、“第二”仅用于描述目的，而不能理解为暗示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征，在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。
本申请以下实施例中的术语“用户界面(user interface，UI)”，是应用程序或操作系统与用户之间进行交互和信息交换的介质接口，它实现信息的内部形式与用户可以接受形式之间的转换。用户界面是通过java、可扩展标记语言(extensible markuplanguage，XML)等特定计算机语言编写的源代码，界面源代码在电子设备上经过解析，渲染，最终呈现为用户可以识别的内容。用户界面常用的表现形式是图形用户界面(graphicuser interface，GUI)，是指采用图形方式显示的与计算机操作相关的用户界面。它可以是在电子设备的显示屏中显示的文本、图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、Widget等可视的界面元素。
单播，指在源主机和目标主机之间实现点对点网络连接，源主机发送的单播数据包包括该目标主机的地址。当目标主机数量较多时，单播方式会占据大量网络带宽，导致源主机负载重和网络拥塞。
组播，指按照最大投递的原则，将一份数据包传输到一个组播组(multicastgroup)中的主机集合。当源主机有向多个主机发送相同数据的需求时，源主机不必向上述多个主机分别发送该数据，只需发送一份数据到特定的组播地址,该组播地址标识了一个组播组；所有加入该组播组的主机均可以接收到一份源主机发送的数据的拷贝，而组播组之外的主机不会收到。相比单播，组播节约了网络带宽，减轻了网络负载和源主机的负载。组播方式中，源主机可以被称为组播源。
示例性的，图1示出了一种传统的组播系统10。
该组播系统中，组播组中的客户端可以分别与无线接入点(Access Point，AP)建立WiFi连接，从而通过AP接入无线局域网(Wireless Local Area Network，WLAN)。组播源上传到通信网络中的组播数据，由网络中的中转设备(例如交换机、路由器等)根据加入组播组的各客户端(Client)的分布情况对该组播数据进行复制和转发，该组播数据会准确地发送给各客户端接入的无线接入点；然后由AP通过与客户端的WiFi连接，将组播数据发送给组播组中的客户端。图1涉及的通信网络可以包括WLAN和/或广域网(例如互联网)。
由图1可知，上述组播系统10中，组播源发送的组播数据，需要经过多个中间设备(例如中转设备和AP)的处理和分发，才能发送到组播组中的客户端。该组播系统中组播源和客户端之间涉及的中间设备较多，进而使得组播管理和组播传输的处理流程非常复杂。
目前存在如下场景需求，组播组的组播源和意图加入组播组的各客户端距离较近，处于WLAN通信范围内；针对上述组播源和各客户端，快捷建立组播组，提高组播组的管理效率和组播传输效率，实现大规模可靠组播。上述组播系统10中组播源和客户端之间涉及的中间设备较多，组播管理和组播传输的处理流程非常复杂；且各客户端均需要与AP建立WiFi连接，不适用于无AP的环境；因此，组播系统10并不适用该场景需求。
示例性的，针对上述场景需求，图2A示出了本申请实施例提供的一种组播系统20。组播系统20中，组播源100创建虚拟接入点(VAP)，作为AP与组播组中的各客户端建立了WiFi连接，然后基于与各客户端的WiFi连接，向组播组中的各客户端发送组播报文。
组播系统20中，当AP向客户端发送的组播报文通过WLAN传输时，为了保证组播传输的可靠性，可以采用的一种典型的传输方式是组播转单播的方式(在IEEE 802.11v标准中定义)。图2B示出了该组播传输方式的时序图。参见图2B，针对一个组播IP帧，AP会确定组播组中的接入该AP的各客户端的MAC地址；基于各客户端的MAC地址，AP将一个组播IP帧转换成针对各客户端的单播帧；然后，基于WiFi协议依次对上述各客户端发送组播IP帧对应的单播帧，并采用单播传输的反馈机制。例如，组播组中的2个客户端接入该AP，AP依次对2客户端发送一个组播IP帧(例如Frame 1)对应的单播帧后，再依次对2个客户端发送下一个组播IP帧(例如Frame 2)对应的单播帧。此外，依赖单播传输的反馈机制，该传输方式可以采用高阶传输速率。即向一个客户端发送一个单播帧后，可以接收到该客户端反馈的确认字符(Acknowledge character，ACK)，上述单播帧和ACK间隔了帧间间隙(Inter-frameSpacing，IFS)，上述ACK和下一个发送的单播帧间隔了分布式帧间间隙(DistributedInter-frame Spacing，DIFS)和随机回退值(Backoff)。
显然，这种组播转单播的组播传输方式失去了组播本身的意义，当加入组播组的客户端数量数较大时会形成空口资源浪费。同时，在组播系统20中，组播源100需要与每个客户端都建立WiFi连接，即与每个客户端之间都维护了一条WiFi单播链路。参见图2C，“WiFi连接”是指，两个设备通过服务发现、链路认证(Auth Req/Resp)、关联过程(AssoReq/Resp)、密钥协商(即四步)和IP分配这五个阶段中部分或全部阶段，建立WiFi单播链路，并在两个设备为该WiFi单播链路维护对应的链路信息，例如各种链路参数和各种链路优化算法(例如速率选择算法、聚合算法等)。这样，组播组包括N个客户端时，组播源需要关联N个客户端的WiFi单播链路，分别维护N条WiFi单播链路的链路信息。
对于无线路由器来说，可以同时关联32个甚至64个设备的WiFi单播链路；但用户的终端设备(例如手机、平板等等)作为组播源时，受限于硬件资源，一般只可以关联4到8个设备的WiFi单播链路，这样就极大地限制了组播组中客户端的数量。
示例性的，图2D示出了本申请实施例提供的另一种组播系统30，可以避免终端设备作为组播源时可关联客户端数量少的问题。如图2D所示，组播系统30可以包括组播组的组播源100，以及加入组播组的多个客户端，例如客户端200、客户端300等。下面以客户端200为例进行说明。
组播源100和客户端200为具备近距离通信模块的终端设备，上述近距离通信模块包括WiFi通信模块和蓝牙(bluetooth，BLE)通信模块。确定开启组播后，组播源100通过WiFi通信模块启动用于组播的VAP(例如开启WiFi热点)；组播源100与客户端200通过蓝牙通信模块建立蓝牙连接；基于该蓝牙连接，客户端200可以加入组播组并开启用于组播的VAP，组播源100可以获取客户端200的组播用户信息(例如IP地址和MAC地址等)。在一些实施例中，上述VAP可以理解为一个驱动网卡，也就是用户态可以操作的一个内核态网卡。这样，通过蓝牙辅助建立组播组后，组播源100和各客户端无需建立Wifi连接，组播源100的VAP也能基于各客户端的组播用户信息通过WiFi通信模块组播发送组播报文，各客户端的VAP也能通过WiFi通信模块监听到组播源100组播发送的组播报文。这样，无需受限于可关联的客户端数量，可以实现无WiFi连接的大规模的WiFi组播传输。
组播系统30中，组播源100和组播组中的各客户端间的“无WiFi连接”，指组播源100和各客户端没有图2C所示的WiFi连接过程，进而也无需维护每个客户端对应的链路信息(即各种链路参数和各种链路优化算法)。组播源100，只需要将组播组中的所有客户端，虚拟为一个组播用户，并仅维护该组播用户对应的链路信息，包括组播组的组播地址、组播密钥、客户端的虚拟组播源地址和各客户端的组播用户信息等。
在一些实施例中，组播源100可以具备显示屏，用户可以通过该显示屏显示的用户界面触发组播组建立/删除。在一些实施例中，客户端200也可以具备显示屏，用户可以通过该显示屏显示的用户界面触发客户端200加入/退出组播组。
组播源100和各客户端200可以为用户的终端设备。组播源100和客户端200可以是手机、平板电脑、桌面型计算机、膝上型计算机、手持计算机、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本，以及蜂窝电话、个人数字助理(personal digital assistant，PDA)、增强现实(augmented reality，AR)设备、虚拟现实(virtual reality，VR)设备、人工智能(artificial intelligence,AI)设备、可穿戴式设备、车载设备、智能家居设备和/或智慧城市设备等等，本申请实施例对组播源100和客户端200的具体类型不作特殊限制。组播源100和客户端200可以搭载iOS、Android、Microsoft或者其它操作系统，此处也不做具体限定。
下面对本申请实施例涉及的组播源100和客户端的软件架构进行介绍。
组播源100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的Android系统为例，示例性说明组播源100的软件结构。
图2E是本发明实施例的组播源100的软件架构图。
分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，组播源100的软件架构包括但不限于应用程序层(Application)，应用程序框架层(Freamwork)，以及内核层(kernel)。
应用程序(application，APP)层可以包括一系列应用程序包。如图2E所示，应用程序包可以包括用户界面(UI)和组播应用(例如投屏应用)，还可以包括WLAN应用，蓝牙应用，视频应用等应用程序。
应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。
如图2E所示，应用程序框架层中的系统服务可以包括蓝牙服务和WLAN服务。蓝牙应用可以调用蓝牙服务来与附近的客户端建立无线通信连接，以及进行数据传输；WLAN应用可以调用WLAN服务开启VAP，该VAP通过WiFi通信协议可以组播发送组播报文，以及监听到组播组中的客户端组播发送的组播报文。
在一些实施例中，应用程序框架层还可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等(附图未示出)。
内核层是硬件和软件之间的抽象层。Android核心系统服务依赖于内核层(即Linux内核)，如安全性、内存管理、进程管理、网络协议栈和驱动模型等。内核层(kernel)可以响应于应用程序框架层调用的功能，执行对应的操作。
内核层(kernel)可以包括TCP/IP协议栈(TCP/IP Multicast Stack)，HML组播栈(HML Multicast Stack)和硬件驱动层(Driver)。
在一些实施例中，TCP/IP协议栈从高至低包括传输层和网络层。TCP/IP协议栈用于报文分段重组、报文封装、报文校验、拥塞控制、慢启动、乱序重排、超时重排等。
发送数据时，TCP/IP栈按照从高至低的顺序，利用对应的分层协议封装待发送数据。在一些实施例中，网络层将用于将上层传输下来的报文添加一个IP头以生成IP报文，并发送至WiFi驱动中的数据链路层，IP头包括组播源100的IP地址和目的IP地址(例如组播IP地址或客户端的IP地址)。数据链路层将上层传输下来的报文添加一个MAC头以生成MAC帧，并发送至物理层，MAC头包括组播源100的MAC地址和目的MAC地址(例如组播MAC地址或客户端的MAC地址)。本申请实施例对组播IP地址的获取方式不做具体限定。
接收数据时，TCP/IP栈按照从低至高的顺序，利用对应的分层协议解析接收到的数据。在一些实施例中，数据链路层用于对下层传输上来的报文进行MAC帧校验，例如解析MAC头，基于MAC头中的源地址查询组播密钥，并利用该组播密钥解析该报文获取解析后的数据单元(例如MAC服务数据单元(MSDU))。网络层用于对下层传输上来的报文进行IP报文校验，例如解封IP头，基于IP报文中的目的IP地址确定是否为该本设备的IP地址，若是，则将解封后的报文上传至上一层。
HML组播栈包括组播管理模块和组播传输模块，组播管理模块用于管理组播源100侧的组播组信息，为组播源100和加入组播组的客户端分配IP地址；上述组播组信息可以包括组播用户信息、组播地址、虚拟组播源地址、组播密钥等。组播传输模块用于确定待发送的组播报文及其发送时机，还用于对客户端反馈的组播报文进行处理。
硬件驱动层至少包含显示驱动，蓝牙驱动，WiFi驱动。显示驱动可以驱动显示屏显示用户界面，用户界面可以设置有触发组播组建立、组播删除的控件。蓝牙服务可以向蓝牙驱动发送指令，指示蓝牙驱动通过蓝牙通信模块发送探测信号扫描附近的蓝牙设备，与其他蓝牙设备进行交互以建立蓝牙连接，以及通过上述蓝牙连接收发信号。组播源100通过上述蓝牙连接可以邀请客户端加入组播组或接收来自客户端的加入组播组的请求，还可以通知客户端删除组播组或接收客户端退出组播组的请求。WiFi服务可以向WiFi驱动发送指令，指示WiFi驱动通过WiFi通信模块启动VAP，并通过该VAP向组播地址组播发送组播报文，以及监听客户端的VAP反馈的组播报文。
客户端的软件架构可以参考图2E中组播源100的相关描述，可以比图2E所示的软件架构包括更多或更少的模块，此处不赘述。
基于上述组播系统30和软件架构，本申请实施例提供了组播通信方法，该方法可以实现大规模可靠的组播传输。下面对上述组播通信方法的应用场景进行示例性介绍。
本申请实施例涉及的应用场景包括一对多的信息分享，上述信息分享可以是文件分享，例如组播源100同时发送一个文件给多个客户端；上述信息分享也可以是投屏分享，例如将组播源100的屏幕画面同时投射到多个客户端的屏幕上。下面以投屏分享场景为例进行介绍。
示例性的，以视频应用为例，图3A至图3F示出了投屏分享场景中用户通过UI触发组播组建立，并邀请客户端200加入组播组的相关界面。
如图3A所示，组播源100显示视频应用的用户界面11时，检测到用户调出控制界面12的操作(例如以状态栏为起点的向下滑动操作)；响应于该操作，组播源100显示图3B所示的控制界面12。控制界面12可以包括用于控制组播源100的各种快捷功能的开关图标，例如，无线投屏的开关图标201、WiFi的开关图标和蓝牙的开关图标等等，其中WiFi的开关图标和蓝牙的开关图标均处于开启状态。本申请实施例对用户调出控制界面的方式不做具体限定。
用户可以通过无线投屏的开关图标201开启/关闭无线投屏。开关图标有两种显示状态，即开启状态和关闭状态；图3B所示的开关图标201当前处于关闭状态，指示了当前未开启无线投屏。如图3B和图3C所示，检测到用户点击开关图标201后，组播源100将开关图标201切换为开启状态，开启无线投屏，执行投屏组播组的建立流程。
在一些实施例中，开启无线投屏后，组播源100执行投屏组播组的建立流程包括：检测可进行无线投屏的附近设备(例如，开启了无线分享的附近设备)，并显示图3D所示的选择框202。选择框202包括检测到的附近设备的设备选项，例如客户端200的设备选项203，还可以包括确定控件204。上述设备选项可以包括设备图标、设备名称、设备型号中的部分或全部。
在一些实施例中，开启无线分享的终端设备定期蓝牙广播发现信号，发现信号可以指示该设备的设备标识，以及指示该设备可以接收其他设备的无线分享数据，例如投屏数据。组播源100可以通过蓝牙驱动监听到开启无线分享的设备发送的发现信号。
选择框202用于选择目标投屏设备，用户可以从检测到的附近设备中选择至少一个设备作为目标投屏设备。如图3E所示，在用户通过客户端200的设备选项203选中客户端200后，组播源100检测到用户点击确定控件204时，组播源100向客户端200发送组播邀请消息，以邀请其加入投屏组播组；并在客户端200加入投屏组播组后向其组播发送投屏数据。可选的，无需显示确定控件204，检测到选中客户端200的操作(例如点击设备选项203的操作)后，就向客户端200发送组播邀请消息。
在一些实施例中，除了用于选择目标投屏设备，选择框202还可以用于选择投屏内容。如图3D所示，投屏内容可以包括如下选项：组播源100的屏幕205和前台运行的应用(即视频应用)206。若用户选择屏幕205，则组播源100组播发送的投屏数据包括组播源100的显示屏当前的显示内容；若用户选择视频应用206，则组播源100组播发送的投屏数据包括组播源100运行的视频应用的显示内容。
本申请实施例中，客户端200接受组播源100的邀请，加入投屏组播组后，才可以接收到组播源100组播发送的投屏数据。在一些实施例中，客户端200接收到组播源100发送的加入投屏组播组的邀请请求后，可以先显示提示框207，提示框207用于提示用户是否接受组播源100的投屏。提示框207可以包括确认控件208和拒绝控件209，确认控件208用于接受投屏，拒绝控件209用于拒绝投屏。如图3F和图3G所示，检测到用户点击确认控件208时，客户端200才接受组播源100的邀请，加入投屏组播组；然后，客户端200才基于接收到的组播源100的投屏数据显示投屏画面13，投屏画面13可以包括组播源100当前显示的用户界面11。
图3A至图3F所示的示例中，组播源100主动邀请客户端200加入投屏组播组。在一些实施例中，组播源100未主动邀请客户端300加入投屏组播组，客户端300也可以主动请求加入投屏组播组。
示例性的，图4A至图4I示出了组播源100建立投屏组播组后，客户端300主动加入投屏组播组的相关界面。
在一些实施例中，组播源100建立投屏组播组时可以生成加入投屏组播组的密码，例如，身份识别码(Personal identification number，PIN)。如图4A所示，组播源100对已加入投屏组播组的客户端进行投屏时，可以显示加入投屏组播组的PIN 301，附近设备可以利用这个PIN主动加入投屏组播组。
如图4B所示，客户端300显示用户界面16(例如主界面)时，检测到用户调出控制界面14的操作；响应于该操作，客户端300显示图4C所示的控制界面14。客户端300的控制界面14可以包括用于控制客户端300的各种快捷功能的开关图标，例如，无线分享的开关图标302、WiFi的开关图标和蓝牙的开关图标等等。
如图4C和图4D所示，检测到用户点击无线分享的开关图标302后，可以将开关图标302的显示状态由未开启状态切换为开启状态，并开启无线分享。开启无线分享后，用户可以通过多设备协同页面15加入组播源100建立的投屏组播组。本申请实施例对调出多设备协同页面15的方式不做具体限定。
在一些实施例中，如图4D和图4E所示，检测到用户长按无线分享的开关图标302时，客户端300显示多设备协同页面15。多设备协同页面15包括客户端300的图标303，以及客户端300检测到的其他开启无线分享和/或无线投屏的设备的图标，例如组播源100的图标304。如图4E所示，在多设备协同页面15中，客户端300的图标303位于区域1，其他设备的图标位于区域2。可选的，区域1可以为中心的圆形区域，区域2可以为环绕于区域1的环形区域。本申请实施例对上述区域1和区域2的形状和位置不做具体限定。
在一些实施例中，开启无线投屏的组播源100可以定期广播蓝牙信号，指示本设备正在进行无线投屏；开启无线分享的设备也可以定期广播蓝牙信号，指示本设备可以进行无线分享。客户端300可以根据检测到的各设备的蓝牙信号，在多设备协同页面15的区域2显示各设备的图标。在一些实施例中，如图4E所示，客户端300检测到组播源100广播的蓝牙信号后，还可以在多设备协同页面15中显示提示信息305，以指示组播源100正在进行投屏。
如图4F和图4G所示，用户可以通过拖动组播源100的图标304贴近客户端300的图标303，来触发客户端300加入组播源100的投屏组播组。客户端300检测到作用于图标304的滑动操作时，客户端300将图标304沿用户手指的滑动方向向图标303移动。在一些实施例中，如图4H所示，检测到图标304被拖动至图标303的所在区域1时，响应于上述滑动操作，组播源100显示提示框306，提示框306用于验证组播源100的投屏密码。提示框306可以包括提示信息307、密码输入框308和确定控件309，提示信息307用于提示用户输入组播源100的投屏PIN码。
如图4H所示，用户在密码输入框308输入组播源100的投屏PIN码后，客户端300检测到用户作用于确定控件309的操作(例如点击操作)；响应于该操作，客户端300向组播源100发送投屏请求，投屏请求用于请求加入组播源100的投屏组播组，投屏请求携带用户输入的投屏PIN码。组播源100验证上述投屏请求中的PIN码正确后，将客户端300加入投屏组播组；然后，客户端300才可以接收到组播源100组播发送的投屏数据。如图4I所示，客户端基于接收到的投屏数据，可以显示投屏画面17，投屏画面17可以包括组播源100当前显示的用户界面11。
在一些实施例中，也可以不显示提示框306，无需用户输入PIN码。检测到图标304被拖动至图标303的所在区域1时，客户端300直接向组播源100发送投屏请求；组播源100基于该投屏请求可以显示提示框，以提示用户是否允许客户端300加入投屏组播组，提示框可以包括确定控件和拒绝控件；检测到用户作用于确定控件的操作时，组播源100才将客户端300加入投屏组播组。
不限于通过多设备协同页面15触发客户端300主动加入组播源100建立的投屏组播组，还可以通过其他方式触发客户端300主动加入上述投屏组播组，此处不做具体限定。
组播源100与投屏组播组中的客户端进行投屏时，投屏组播组中的客户端的用户可以自主退出投屏组播组，结束该客户端的投屏；组播源100也可以结束投屏，删除整个投屏组播组。
示例性的，图5A和图5B示出了客户端300主动退出投屏组播组的相关界面。如图5A和图5B所示，客户端300可以在投屏画面17上显示退出控件401；检测到用户作用于退出控件401的操作(例如点击操作)时，客户端300停止显示投屏画面，并向组播源100发送退出请求，退出请求用于指示客户端300退出投屏组播组。
在一些实施例，客户端300还可以通过前述无线分享的开关图标302关闭无线分享，进而触发主动退出投屏组播组。本申请实施例对触发客户端300主动退出投屏组播组的方式不做具体限定。
示例性的，图5C和图5D示出了组播源100删除投屏组播组的相关界面。如图5C所示，组播源100进行组播投屏时，可以显示结束控件402；检测到用户作用于结束控件402的操作(例如点击操作)时，组播源100停止组播发送投屏数据，并删除投屏组播组。组播组中的各客户端也停止显示投屏画面。在一些实施例中，如图5D所示，组播源100删除投屏组播组后，显示提示信息403，以提示用户投屏已结束。
在一些实施例，组播源100还可以通过前述无线投屏的开关图标201关闭无线投屏，进而触发组播源100删除投屏组播组。本申请实施例对触发组播源100删除投屏组播组的方式不做具体限定。
下面对本申请实施例提供的组播通信方法的方法流程进行介绍。
如图6A所示，本申请实施例提供的组播通信方法涉及如下三个阶段：组播组建立、组播传输和组播组删除。其中，
组播组建立阶段中，组播源100和各客户端通过蓝牙进行交互。组播组建立阶段又可以包括如下三阶段：组播启动，组播源邀请，客户端主动加入。
组播准备启动中，用户可以通过组播源100的用户界面触发组播源100通过蓝牙扫描附近可加入组播组的设备，启动用于组播的VAP，并确定组播组所需的启动信息(例如组播地址、虚拟组播源地址、组播密钥)。组播源邀请客户端阶段中，在组播源100检测到附近可加入组播组的客户端后，与该客户端建立蓝牙连接，并通过该蓝牙连接邀请该客户端加入组播组。客户端主动加入阶段中，客户端检测到组播源100蓝牙广播的组播组的发现信号后，与组播源100建立蓝牙连接，并通过该蓝牙连接主动加入组播组。组播源邀请阶段和客户端主动加入阶段中，确定客户端加入组播组后，组播源100可以获取该客户端的组播用户信息，并触发客户端启动用于组播的VAP并配置客户端侧的组播组信息；此外，确定客户端加入组播组后，客户端或组播源100即可断开上述蓝牙连接。
组播传输阶段中，组播源100和各客户端通过WiFi驱动进行交互，但无需建立WiFi连接。基于组播组的启动信息和客户端的组播用户信息，组播源100的VAP通过WiFi驱动组播发送组播报文，客户端的VAP通过WiFi驱动可以监听到组播源100发送的组播报文。基于客户端侧的组播组信息，各客户端的VAP也可以通过WiFi驱动组播发送组播报文，组播源100的VAP通过WiFi驱动也可以监听到客户端发送的组播报文。
组播传输阶段又可以包括如下两阶段：数据帧传输，信令帧传输。
对于WiFi驱动而言，本申请实施例的组播传输可以采用传统的组播传输方式(例如图6B所示的组播传输方式)，组播源100在组播帧的MAC头中填写组播组的组播MAC地址，然后WiFi驱动通过VAP依次在空口中发送各组播帧(例如图6B所示的Frame 1、Frame 2和Frame 3)。该传输方式中，发送一个组播帧(例如Frame 1)后，需要间隔DIFS和Backoff，才能发送下一个组播帧(例如Frame 2)。传统的组播传输方式存在如下问题：由于不具备反馈机制，传输可靠性低，为保障传输稳定性，通常采用最低阶传输速率。
特别地，本申请实施例在上述组播传输方式的基础上，还针对控制信令帧设计了重传机制。接收到组播源100的控制信令帧后，客户端200的VAP通过WiFi驱动可以反馈信令确认帧，组播源100的VAP通过WiFi驱动可以监听到客户端200反馈的信令确认帧；组播源100可以根据该信令确认帧对客户端300未接收到的控制信令帧进行重传。这样，可以有效提高传输可靠性低和传输速率。
组播删除阶段中，组播源100和各客户端通过蓝牙进行交互。组播删除阶段又可以包括如下两阶段：组播源删除，客户端主动退出。
客户端主动退出阶段中，用户可以通过客户端的用户界面触发该客户端主动退出组播组；客户端与组播源100建立蓝牙连接，向组播源100发送退出组播的请求，并在退出后断开上述蓝牙连接。组播源删除阶段中，用户可以通过组播源100的用户界面触发组播源100删除组播组，组播源100可以蓝牙广播删除组播组的消息。
本申请实施例提供的组播组通信方法，无需其他第三方设备(例如路由器)参与，组播源和客户端通过蓝牙交互，可以实现快捷建立组播组，提高组播传输效率和组播组的管理效率，避免组播源100的VAP可关联客户端数量少的问题，实现了无WiFi连接的近距离的大规模组播；此外，通过本申请实施例提供的重传机制还有效提高了组播可靠性。
下面对上述组播组建立、组播删除和组播传输这三阶段进行详细介绍。
1、组播组建立
示例性的，以客户端200为例，图7A示出了本申请实施例提供的一种组播启动阶段的方法流程图，组播启动阶段包括但不限于步骤S101至S113。
S101、组播源100的UI检测到用户的操作1，操作1用于触发组播组建立的组播启动流程。
S102、基于操作1，组播源100的UI向组播源100的蓝牙驱动发送发现指令。
在一些实施例中，基于操作1，组播源100的UI向组播源100的组播栈发送指令，以指示组播栈向蓝牙驱动发送发现指令。
S103、基于发现指令，组播源100的蓝牙驱动蓝牙广播发现信号1，发现信号1用于检测可加入组播组的HML组播设备。
本申请实施例中，组播源100设置有组播业务的UI入口，用户通过作用于该UI入口的操作1，可以触发组播启动流程，启动蓝牙发现服务。示例性的，考图3A至图3D的相关描述，在投屏场景中，上述组播业务可以为无线投屏业务；操作1可以是用于开启无线投屏的操作，例如作用于无线投屏的开关图标201的点击操作。
本申请实施例中，将支持本申请实施例提供的组播通信方法的设备简称为HML组播设备。组播源100响应于用户的操作1，会启动蓝牙发现服务，蓝牙广播发现信号1，并进入蓝牙监听状态，以检测周围的HML组播设备。上述发现信号1可以用于指示本设备支持组播通信和/或本设备为HML组播设备；投屏场景中，发现信号1还可以用于指示本设备正在发起投屏。
S104、客户端200的UI检测到用户的操作2。
S105、基于操作2，客户端200的UI向客户端200的蓝牙驱动发送发现指令。
S106、基于发现指令，客户端200的蓝牙驱动蓝牙广播发现信号2，发现信号2用于指示客户端200为HML组播设备。
在一些实施例中，客户端200设置有预设的UI入口，用户通过作用于该UI入口的操作2，可以触发客户端200启动蓝牙发现服务，蓝牙广播发现信号2，发现信号2可以用于指示本设备支持组播通信和/或本设备为HML组播设备。在一些实施例中，客户端200可以设置无线分享功能，客户端200开启无线分享功能后，可以接收其他设备无线分享的数据；HML组播设备也可以包括开启无线分享功能的设备，上述操作2包括开启无线分享的操作。示例性的，参考图4C至图4D的相关描述，操作2可以为作用于无线投屏的开关图标302的点击操作。
在一些实施例中，组播源100的蓝牙驱动定期广播发现信号1，例如广播频率为5秒12次。在一些实施例中，接收到UI的发现指令后，客户端200的蓝牙驱动在检测到组播源100发送的发现信号1时，才开始蓝牙广播发现信号2；这样，可以节省客户端200的功耗和空口资源。在一些实施例中，组播源100无需执行步骤S103，组播源100的蓝牙驱动接收到发现指令1后，通过蓝牙驱动监听来自其他设备的发现信号，例如客户端200定期蓝牙广播的发现信号2；这样，可以节省组播源100的功耗和空口资源。
在一些实施例中，上述发现信号1可以携带组播源100的设备信息，上述发现信号2可以携带客户端200的设备信息，设备信息包括以下部分或全部：设备身份标识(Identity，ID)、设备型号、设备名称、设备登录的账号的hash值等。可选的，账号的hash值可以用于验证设备合法性，客户端200可以基于发现信号1中的账号的hash值，验证组播源100与客户端200是否登录同一账户；登录同一账号的情况下，客户端200后续才会同意加入组播组。组播源100可以基于发现信号2中的账号的hash值，验证组播源100与客户端200是否登录同一账户；登录同一账号的情况下，组播源100后续才会允许客户端200加入组播组。
S107、基于监听到的发现信号2，组播源100的蓝牙驱动向组播源100的UI发送设备的回调指令。
S108、基于上述回调指令，组播源100的UI显示检测到的HML组播设备，检测到的HML组播设备包括客户端200。
S109、组播源100的UI检测到用户的操作3，操作3用于从检测到的HML组播设备选择至少一个目标设备，以及用于确定创建包括上述至少一个目标设备的组播组。
本申请实施例中，组播源100的蓝牙驱动监听到来自客户端200的发现信号2后，向UI发送设备的回调指令，回调指令可以携带检测到的HML组播设备列表，HML组播设备列表可以包括各HML组播设备的设备信息。组播源100的UI可以基于HML组播设备列表，显示各HML组播设备的设备选项，以供用户选择。例如，组播源100的UI基于客户端200的设备信息，显示客户端200的设备选项。示例性的，参考图3A至图3D的相关描述，投屏场景中，组播源100将检测到的开启无线分享的HML组播设备的设备选项显示在用户界面11上，以供用户选择目标投屏设备；上述至少一个目标设备包括客户端200时，客户端200的设备选项203可以包括客户端200的图标和设备名称，操作3包括作用于设备选项203的操作(例如点击操作)。
S110、响应于操作3，组播源100的UI向组播源100的组播栈发送组播启动指令。
S111、组播源100的组播栈向组播源100的WiFi驱动发送组播启动指令。
S112、基于上述组播启动指令，组播源100的WiFi驱动创建用于实现组播业务的VAP 1。
确定启动组播后，组播源100开启用于实现组播业务的虚拟局域网(即VAP 1)。不限于组播业务，上述VAP 1还可以实现其他业务，此处不做具体限定。
S113、基于上述组播启动指令，组播源100的组播栈还为组播源100的VAP 1分配IP地址1，为上述至少一个目标设备的VAP分别分配IP地址，生成组播组的组播MAC地址、虚拟组播源地址、组播密钥1。
本申请实施例中，确定建启动组播后，组播源100不仅要为本设备的VAP 1分配IP地址，还要为用户选中的各目标设备的VAP分别分配IP地址。例如，目标设备包括客户端200时，组播源100为客户端200的VAP 1分配IP地址2；目标设备包括客户端300时，组播源100的为客户端300的VAP 1分配IP地址3。
此外，确定启动组播后，组播源100还为组播组配置一个组播IP地址。组播源100在封装组播报文时，将目的IP地址设为组播IP地址，凡是加入到该组播IP地址指示的组播组的客户端，都可以接收到组播源100发送的组播报文。组播IP地址使用动态分配的一个D类地址，D类地址空间的范围是224.0.0.0～239.255.255.255，都可以接收到组播源组播组；当该组播组的组播结束时，相对应的D类地址会被回收。
一个数据包到从源端发送到目标设备，IP层的寻址需要目标设备的IP地址，而在以太网环境中二层寻址还需要目标设备的MAC地址。组播源100确定组播IP地址后，获取由组播IP地址映射而来的组播MAC地址。组播MAC地址也可以简称为组播地址。
WiFi单播链路来说一般采用WPA2/WPA3加密协议，每个WiFi单播链路的收发两端在建立WiFi连接时，可以协商该链路的单播密钥和组播密钥。对于大多数芯片来说，单一设备不支持配置多个组播密钥，即一个设备只能有一个组播密钥；而接收端的芯片解密组播报文时，通常根据该组播报文的MAC头(MAC Header)中的Address2字段获取源地址，查表获取源地址对应的组播密钥，进而利用该组播密钥对组播报文进行解密。因此，对于一个配置组播密钥1为HML组播设备的VAP来说，其接收到的组播报文中，只有来自一个设备的组播报文能够被解密成功，该设备的MAC地址为组播密钥1对应的源地址。
在本申请实施例提供的无WiFi连接的组播传输中，对于客户端来说，其只会接收到来自组播源100的组播报文；因此，客户端只需要将组播源100的MAC地址配置为组播密钥1的源地址，客户端根据组播报文的MAC头中的源地址(即组播源100的MAC地址)，可以查询到组播密钥1，并利用组播密钥1解密组播报文。而对于组播源100来说，其会接收到来自组播组中所有客户端的组播报文。为实现组播源100可以解密组播组中所有客户端发送的组播报文，组播组中所有客户端均采用相同的虚拟组播源地址；组播源100会将上述虚拟组播源地址配置为组播密钥1对应的源地址，组播组中的所有客户端在给组播源100发送组播报文时会设置源地址为上述虚拟组播源地址，同时在组播报文的数据单元(例如MAC帧中的MSDU)中携带该客户端的实际源地址。
在一些实施例中，上述虚拟组播源地址可以基于如下预设规则生成：虚拟组播源地址的前三个字节为组播源100的组织唯一标识符(OUIOrganizationally uniqueidentifier，OUI)，后3个字节为组播源100的MAC地址的后3个字节。
本申请实施例对组播组的组播密钥1的生成方式不做具体限定。
在一些实施例中，组播源100利用预设密钥算法(例如哈希算法)，生成组播组的组播密钥1。
在一些实施例中，组播源100与组播组中的一个客户端(例如客户端200)进行WiFi连接，在WiFi连接过程中进行密钥协商，获取组播源100与客户端200间的WiFi单播链路对应的组播密钥1，并将组播密钥1作为整个组播组的组播密钥。可选的，上述客户端可以为最早加入组播组的客户端之一。上述实现方案中，组播源100只需要与组播组中的一个客户端建立WiFi连接和进行密钥协商，并在获取组播密钥后即可断开上述WiFi连接；在组播传输阶段，组播源100与该客户端无需建立WiFi连接。
用户从检测到的HML组播设备选择至少一个目标设备后，组播源100会通过蓝牙驱动依次向每个目标设备发起蓝牙连接，以邀请目标设备加入组播组，下面以客户端200为例进行说明。
示例性的，图7B示出了本申请实施例提供的一种组播源邀请阶段的方法流程图。如图所示，在上述组播启动阶段的步骤S113之后，还可以包括但不限于步骤S201至S216。
S201、组播源100的组播栈向组播源100的蓝牙驱动发送客户端添加指令，客户端添加指令用于指示邀请客户端200加入组播组。
客户端添加指令可以包括客户端200的设备标识(例如设备ID、MAC地址等)，还可以包括组播MAC地址、虚拟组播源地址、组播源100的IP地址1、客户端200的IP地址2和组播密钥1。
S202、基于客户端200的设备标识，组播源100的蓝牙驱动与客户端200的蓝牙驱动进行信息交互，以建立蓝牙连接。
在一些实施例中，参考前述步骤S103至S106，客户端200开启无线分享后，会定期蓝牙广播发现信号2，发现信号2包括客户端200的设备标识。组播源100的蓝牙驱动基于客户端200的设备标识，可以向客户端200的蓝牙驱动发送蓝牙连接请求，以请求与客户端200建立蓝牙连接。本申请实施例对组播源100与客户端200建立蓝牙连接的实现过程不做具体限定，此处不再赘述。
S203、组播源100的蓝牙驱动向客户端200的蓝牙驱动发送组播邀请消息，组播邀请消息用于邀请客户端200加入组播组，组播邀请消息包括以下部分或全部：组播IP地址、组播MAC地址、虚拟组播源地址、组播源100的IP地址1、客户端200的IP地址2和组播密钥1。
S204、基于上述组播邀请消息，客户端200的蓝牙驱动向WiFi驱动发送HML创建指令。
S205、基于HML创建指令，客户端200的WiFi驱动创建用于实现组播业务的VAP 2。
S206、客户端200的WiFi驱动向客户端200的蓝牙驱动发送创建完毕通知。
S207、基于上述创建完毕通知，客户端200的蓝牙驱动向组播栈发送组播配置指令，组播配置指令包括组播MAC地址、虚拟组播源地址、组播源100的IP地址1、客户端200的IP地址2和组播密钥1。
S208、基于上述组播配置指令，客户端200的组播栈为组播组配置组播组信息，组播组信息包括以下部分或全部：组播MAC地址、虚拟组播源地址、组播密钥1、组播源100的IP地址1、客户端200的IP地址2和组播源100的MAC地址。
在一些实施例中，组播源100发送的组播邀请消息也可以不包括虚拟组播源地址；客户端200的可以基于组播源100的OUI、组播源100的MAC地址以及用于生成虚拟组播源地址的预设规则，自己生成上述虚拟组播源地址。
S209、客户端200的组播栈向WiFi驱动发送组播密钥配置指令，组播密钥配置指令包括上述组播密钥1和组播源100的MAC地址。
S210、基于上述组播密钥配置指令，客户端200的WiFi驱动配置组播密钥1为组播组的组播密钥，且组播密钥1对应的源地址为组播源100的MAC地址。
客户端200的硬件模块维护有一个组播密钥查询表，该表中用于存储组播密钥和源地址的对应关系。基于上述组播密钥配置指令，客户端200的WiFi驱动指示硬件模块在该表中存储组播密钥1和组播源100的MAC地址的对应关系。后续组播传输阶段，客户端200接收到组播源100的组播报文后，可以根据组播报文中的源地址(即组播源100的MAC地址)，在上表中查询到对应的组播密钥1；利用组播密钥1即可以解密上述组播报文。
可以理解，客户端200与组播源100进行信息交互时，可以获取组播源100的MAC地址。例如，步骤S202和S203中，通过蓝牙驱动可以获取组播源100的MAC地址。在一些实施例中，步骤S207中，客户端200的蓝牙驱动可以通过组播配置指令将组播源100的MAC地址发送给客户端200的组播栈。
在一些实施例中，客户端200接收到组播邀请消息后，可以显示提示信息，以提示用户是否加入组播源100的组播组。客户端200的UI检测到用户确认加入的操作后，客户端200才执行步骤S204至S210。示例性的，参见图3E至图3G的相关描述，在投屏场景中，客户端200接收到来自组播源100的组播邀请消息后，可以显示提示框207，提示框207可以用于提示用户是否加入组播源100的投屏组播组；提示框207可以包括确认控件208，用户可以通过点击确认控件208，确认加入投屏组播组。
S211、客户端200的组播栈向WiFi驱动发送IP地址配置指令，IP地址配置指令包括上述IP地址2。
S212、基于上述IP地址配置指令，客户端200的WiFi驱动将VAP2的IP地址配置为IP地址2。
本申请实施例对上述步骤S209和S211的执行顺序不做具体限定。
步骤S206后，即在客户端200的蓝牙驱动接收到创建完毕通知后，客户端200的蓝牙驱动还执行步骤S213。
S213、客户端200的蓝牙驱动向组播源100的蓝牙驱动发送加入组播组的确认加入消息，确认加入消息可以包括客户端200的设备标识。
S214、基于上述确认加入消息，组播源100的蓝牙驱动向组播源100的组播栈发送确认添加通知，确认添加通知用于指示客户端200确认加入组播组。
S215、基于上述确认添加通知，组播源100的组播栈添加客户端200的组播用户信息。
在一些实施例中，组播用户信息可以包括以下部分或全部：客户端200的IP地址2、客户端200的MAC地址和设备ID。可以理解，组播源100与客户端200进行信息交互时，也可以获取客户端200的MAC地址。例如，步骤S202和S213中，通过蓝牙驱动可以获取客户端200的MAC地址。
组播源100的组播栈用于管理组播源侧的组播组信息。在一些实施例中，组播源侧的组播组信息包括组播设备列表，组播设备列表用于存储组播组中各客户端的组播用户信息。基于上述确认添加通知，组播栈在组播设备列表中添加客户端200的组播用户信息。后续组播传输阶段中，组播源100接收来自其他设备的报文后，根据组播用户列表中各客户端的MAC地址和/或IP地址可以确定上述报文是否来自组播组中的客户端。
S216、组播源100的蓝牙驱动与客户端200的蓝牙驱动断开蓝牙连接。
本申请实施例中，可以是客户端200的蓝牙驱动在执行步骤S213或S207之后，主动断开上述蓝牙连接，也可以是组播源100的蓝牙驱动在步骤S213或S214之后，主动断开上述蓝牙连接，此处不做具体限定。
本申请实施例中，组播源100创建组播的VAP1后，依次向每个目标设备发起蓝牙连接，以邀请目标设备加入组播组。由于终端设备的蓝牙连接链路存在上限(例如连接链路数量为7)，在组播源100通过蓝牙连接邀请一个目标设备加入组播组后，立即断开组播源100与该目标设备的蓝牙连接，删除蓝牙连接的相关信息。
示例性的，以客户端300为例，图7C示出了本申请实施例提供的一种客户端主动加入阶段的方法流程图。如图所示，在上述组播启动阶段的步骤S113之后，还可以包括但不限于步骤S301至S318。
S301、客户端200的蓝牙驱动与组播源100的蓝牙驱动进行信息交互，以建立蓝牙连接。
本申请实施例中，参考前述步骤S101至S103的描述，用户通过操作1触发组播源100的组播启动流程后，组播源100会定期蓝牙广播发现信号1，发现信号1包括组播源100的设备标识。客户端300的蓝牙驱动接收到发现信号1后，基于组播源100的设备标识，可以向组播源100的蓝牙驱动发送蓝牙连接请求，以请求与组播源100建立蓝牙连接。本申请实施例对客户端300与组播源100建立蓝牙连接的实现过程不做具体限定，此处不再赘述。
在一些实施例中，客户端300的蓝牙驱动接收到发现信号1后，显示提示信息，提示信息可以用于提示组播源100正在进行组播；基于上述提示信息，用户实施用于加入组播组操作4；客户端200的UI检测到操作4后，才通知客户端200的蓝牙驱动向组播源100的蓝牙驱动发送蓝牙连接请求，以请求与组播源100建立蓝牙连接，进而执行后续的方法流程(即步骤S302至S317)。
示例性的，参考图4E至图4H的相关描述，在投屏场景中，客户端300的蓝牙驱动接收到组播源100广播的发现信号后，在多设备协同页面15中组播源100的图标304周围显示提示信息305，提示信息305用于提示组播源100正在发起组播投屏；上述操作4可以包括拖动组播源100的图标304贴近客户端300的图标303的操作。
S302、客户端300的蓝牙驱动向组播源100的蓝牙驱动发送加入请求消息，加入请求消息用于请求加入组播组；加入请求消息可以包括客户端300的设备标识。
S303、基于上述加入请求消息，组播源100的蓝牙驱动向组播源100的组播栈发送加入请求指令，加入请求指令用于指示客户端300请求加入组播组；加入请求指令可以包括客户端300的设备标识。
在一些实施例中，前述组播启动阶段中，组播源100还可以生成和显示用于加入组播组的组播密码。步骤S301中客户端300与组播源100建立蓝牙连接后，还可以显示密码输入框。用户在密码输入框输入密码后，客户端300的UI可以将用户输入的密码发送给客户端300的蓝牙驱动；步骤S302中确定用户输入的密码后，客户端300才向组播源100发送加入请求消息，且加入请求消息携带用户输入的密码。当组播源100验证蓝牙连接请求中携带的密码与前述组播密码相同时，才执行步骤S303。
示例性的，参考图4E至图4H的相关描述，检测到操作4(用户拖动组播源100的图标304贴近客户端300的图标303)后，客户端300可以显示密码输入框308，用户输入投屏组播组的PIN码后，客户端300才向组播源100发送加入请求消息。
S304、基于上述加入请求指令，组播源100的组播栈为客户端300的VAP分配IP地址3，向组播源100的蓝牙驱动发送客户端添加指令，客户端添加指令用于指示邀请客户端300加入组播组。
S305、基于上述客户端添加指令，组播源100的蓝牙驱动向客户端300的蓝牙驱动发送组播邀请消息，组播邀请消息包括组播MAC地址、虚拟组播源地址、组播源100的IP地址1、客户端300的IP地址3和组播密钥1。
相比于图7B所示组播源邀请阶段，客户端主动加入阶段多了客户端300通过加入请求消息主动请求加入组播组(即步骤S302)，以及组播源100的蓝牙驱动通过加入请求指令通知WiFi驱动客户端300请求加入组播组(即步骤S303)；客户端主动加入阶段的后续方法流程(即S305至S317)的具体实现，可以参考前述组播源邀请阶段(即S203至S215)。
S306、基于上述组播邀请消息，客户端300的蓝牙驱动向WiFi驱动发送HML创建指令。
S307、基于HML创建指令，客户端300的WiFi驱动创建用于实现组播业务的VAP 3。
S308、客户端300的WiFi驱动向客户端300的蓝牙驱动发送创建完毕通知。
S309、基于上述创建完毕通知，客户端300的蓝牙驱动向组播栈发送组播配置指令，组播配置指令包括组播MAC地址、虚拟组播源地址、组播源100的IP地址1、客户端300的IP地址3和组播密钥1。
S310、基于上述组播配置指令，客户端300的组播栈为组播组配置组播组信息，组播组信息包括组播MAC地址、虚拟组播源地址、组播密钥1、组播源100的IP地址1和客户端300的IP地址3。
S311、客户端300的组播栈向WiFi驱动发送组播密钥配置指令，组播密钥配置指令包括上述组播密钥1和组播源100的MAC地址。
S312、基于上述组播密钥配置指令，客户端300的WiFi驱动配置组播密钥1配置为组播组的组播密钥，且组播密钥1对应的源地址为组播源100的MAC地址。
S313、客户端300的组播栈向WiFi驱动发送IP地址配置指令，IP地址配置指令包括上述IP地址3。
S314、基于上述IP地址配置指令，客户端300的WiFi驱动将VAP3的IP地址配置为IP地址3。
步骤S309后，即在客户端300的蓝牙驱动接收到创建完毕通知后，客户端300的蓝牙驱动还执行步骤S314。
S315、客户端300的蓝牙驱动向组播源100的蓝牙驱动发送加入组播组的确认加入消息。
S316、基于上述确认加入消息，组播源100的蓝牙驱动向组播源100的组播栈发送确认添加通知，确认添加通知用于指示客户端300确认加入组播组。
S317、基于上述确认添加通知，组播源100的组播栈添加客户端300的组播用户信息，组播用户信息可以包括客户端300的IP地址3、MAC地址和设备ID。
S318、组播源100的蓝牙驱动与客户端300的蓝牙驱动断开蓝牙连接。
本申请实施例中，可以是客户端200的蓝牙驱动在步骤S315(即向组播源100发送确认加入消息)或步骤S309之后，主动断开上述蓝牙连接，也可以是组播源100的蓝牙驱动在步骤S315(即接收客户端200发送的确认加入消息)或步骤S316之后，主动断开上述蓝牙连接，此处不做具体限定。
2、组播传输
示例性的，以客户端200为例，图8示出了本申请实施例提供的一种组播传输阶段的方法流程图。如图所示，在上述组播启动阶段的步骤S216之后，还可以包括但不限于步骤S801至S804。
S801、组播源100的组播栈向组播源100的WiFi驱动发送组播传输指令，组播传输指令包括组播报文1；组播报文1是基于组播源侧的组播组信息生成的，组播源侧的组播组信息可以包括以下部分或全部：组播设备列表、组播IP地址、组播MAC地址、组播密钥1。
在一些实施例中，待组播传输的数据1经TCP/IP协议栈的封装，生成组播报文1。具体的，TCP/IP协议栈将数据1封装为组播报文1，包括：网络层将用于将上层传输下来的数据1对应的报文添加一个IP头以生成IP报文，并发送至WiFi驱动的数据链路层；IP头包括组播源100的IP地址和目的IP地址(即组播IP地址)。数据链路层将上层传输下来的IP报文对应的MSDU添加一个MAC头，并利用组播密钥1对MSDU加密后，生成组播报文1，MAC头包括组播源100的MAC地址和目的MAC地址(即组播MAC地址)。组播传输阶段包括数据帧传输和信令帧传输，即上述组播报文1可以是数据帧，也可以是信令帧。
在一些实施例中，数据1为来自应用层的组播传输的有效数据信息(例如投屏场景的音视频数据)时，封装后的组播报文1为组播数据帧。
在一些实施例中，数据1为组播传输的控制信令和确认信息时，封装后的组播报文1为组播信令帧。在一些实施例中，组播报文1为信令帧时，组播报文1的MSDU中还可以携带目标客户端的实际目的地址。
上述组播传输的控制信令可以包括：应用层需要传输的控制信息，例如视频编解码参数、投屏控制信息、心跳包等；HML组播协议本身的控制信息，例如自适应速率探测反馈、编码参数等。
S802、组播源100的WiFI驱动通过VAP1组播发送组播报文1。
S803、客户端200的WiFI驱动通过VAP2监听到组播报文1。
S804、客户端200的WiFI驱动向组播栈发送经组播密钥1解密后的组播报文1。
在一些实施例中，客户端200的WiFI驱动监听到组播报文1后，获取组播报文1的MAC头中的目的地址，确定目的地址是否为本设备加入的组播组的组播MAC地址；若不是，则丢弃该组播报文；若是，则获取组播报文1的MAC头中的源地址(即组播源100的MAC地址)。客户端200的WiFI驱动查表获取上述源地址对应的密钥为组播密钥1；客户端200利用组播密钥1解析组播报文1中的数据单元(例如MASDU)。
在一些实施例中，当组播报文1为信令帧时，经组播密钥1解析后，客户端200可以获取组播报文1的数据单元(例如MSDU)中携带的实际目的地址；客户端200确定上述实际目的地址是否为本设备的MAC地址；若是，则确定组播报文1是发送给本设备的；若不是，则丢弃该组播报文1。
示例性的，投屏场景中，组播报文1可以为数据帧；组播报文1用于传输投屏数据，客户端200将组播报文1中的投屏数据发送至显示驱动，显示驱动指示显示屏基于上述投屏数据显示投屏画面。
类似的，客户端200的组播栈也可以向客户端200的WiFi驱动发送组播传输指令，组播传输指令包括组播报文2；组播报文2是基于客户端侧的组播组信息生成的；客户端200的WiFI驱动通过VAP2组播发送组播报文2；组播源100的WiFI驱动通过VAP1监听到组播报文2；组播源100的WiFI驱动向组播栈发送经组播密钥1解密后的组播报文2。
在一些实施例中，针对组播传输阶段的数据帧，视频编解码可以容忍一定程度的丢包，可以通过冗余编码来进行组播传输；但是对于上述信令帧，必须保证传输到接收端，才能保障组播传输的稳定性。因此，针对上述信令帧，本申请实施例还提供了组播的重传机制，通过该重传机制可以极大提高信令帧的传输可靠性，进而可以提高信令帧的传输速率。
本申请实施例涉及的信令帧包括如下两种类型：控制信令帧和信令确认帧。控制信令帧用于传输上述控制信令；信令确认帧用于指示控制信令帧的接收状态，组播源100基于客户端反馈的信令确认帧可以确定是否对控制信令帧进行重传。
下面介绍本申请实施例提供的信令帧的帧结构。
示例性的，图9A示出了本申请实施例提供的一种控制信令帧的帧格式示意图，图9B示出了本申请实施例提供的一种信令确认帧的帧格式示意图。如图9A和图9B所示，本申请实施例提供的信令帧可以包括如下字段：MAC头(Header)、MAC服务数据单元(MACService Data Unit，MSDU)和帧检验序列(FrameCheck Sequence，FCS)。其中，MAC Header用于指示数据传输的相关信息，MSDU承载传输的有效数据；FCS用于对帧进行完整性检验。
在一些实施例中，MAC Header包括如下7部分：帧控制结构(Frame Control)、持续时长/标识(Duration/ID)、Address1、Address2、Address3、序列控制(Sequence control)、Address4、服务质量控制(Qos control)、高速控制(HT control)。其中，帧控制结构用于指示以下部分或全部事项：协议版本、帧类型(Type)、是否为基本服务集(BSS)向分布式系统(DS)发送的帧、是否是DS向BSS发送的帧、针对被分段的帧是否还有剩余的片段、是否是重传帧、是否进入省电模式、是否开启了链路认证等事项。帧类型可以包括如下类型：管理帧00(用于执行管理操作)、控制帧01(用于信道控制)、数据帧10(用于传输有效数据)。Duration/ID用来指示该帧及其确认帧需要占用信道的时间。地址域(即Address1、Address2、Address3和Address4)可以分别用于指示：TA(传输地址)、SA(源地址)、RA(接收地址)、DA(目的地址)。Sequence control用于重组帧片段以及丢弃重复帧。在一些实施例中，Address2字段用于存储源地址，即发送端的MAC地址。
在一些实施例中，如图9A所示，控制信令帧的MSDU依次可以包括如下字段：目的地址(Des Addr)、源地址(Src Addr)、类型/长度(Type/Length)、实际目的地址(Actual DesAddr)、实际源地址(Actual Src Addr)、HML控制标识(HML Contron ID)、数据载荷(Payload)。
其中，控制信令帧的各字段含义如下：
目的地址：接收端为组播组中的客户端时，目的地址为组播组的组播MAC地址；接收端为组播源100时，目的地址也为组播MAC地址。
源地址：发送端为组播源100时，源地址为组播源100的MAC地址；发送端为组播组中的客户端时，源地址为前述虚拟组播源地址。
类型/长度(Type/Length)又以包括如下字段：组播类型(Multicast Type)和子类型(Subtype)。组播类型表示HML组播帧类型，HML组播帧类型可以包括数据帧、控制信令帧和信令确认帧。例如，组播帧类型为控制信令帧时，该字段取值为0xFE。子类型表示组播帧类型对应的子类型。如表1所示，控制信令帧主要包括如下几种子类型：
子类型(Subtype) 说明
0 应用层下发的控制信令
1 RaptorQ编码参数通知帧
2 自适应参数反馈帧
其他(others) 保留
表1
实际目的地址：接收端的实际的MAC地址。接收端为组播组中的客户端时，由于控制信令帧采用组播传输，所以在以太网头和MAC头对应的目的地址填写的都是组播MAC地址，而该字段是为了标识客户端的准确地址。
实际源地址：发送端的实际的MAC地址。根据前文所言，发送端为组播组中的客户端时，为了解决芯片按照源地址来查表获取组播密钥的问题，客户端在以太网头和MAC头会填写一个统一的虚拟组播源地址，而该字段是为了标识客户端的准确地址。
HML控制标识：控制信令帧的编号(0～255)。
数据载荷：控制信令帧携带的具体的控制信令。
在一些实施例中，如图9B所示，信令确认帧的MSDU可以包括如下字段：目的地址、源地址、类型/长度、实际目的地址、实际源地址、确认信息(Confirm Info)。类型/长度又可以包括：组播类型和子类型。其中，信令确认帧的各字段含义如下：
组播类型：表示HML组播帧类型。例如，组播帧类型为信令确认帧时，该字段取值为0xFD。子类型：对于信令确认帧来说，该字段无用，可以填写预设值，例如0。
确认信息又可以包括如下字段：下沿(Low Edge，LE)、上沿(UP Edge，UE)和位图(Bitmap)。R-LE用于表示接收窗口的下沿，R-UE用于表示接收窗口的上沿，位图用于反馈当前接收窗口中各控制信令帧的接收情况。后续实施例介绍接收窗口时，会对上述下沿、上沿和位图做进一步介绍，此处暂不赘述。
信令确认帧中的目的地址、源地址、实际目的地址和实际源地址，可以参考控制信令帧中对应字段的相关描述，此处不再赘述。
下面以客户端200为例，对信令帧传输阶段进行详细介绍。
示例性的，以客户端200为例，图9C示出了本申请实施例提供的一种信令帧传输阶段的方法流程图。如图9C所示，上述组播报文1为控制信令帧1，组播报文2为信令确认帧1时，在上述组播建立阶段的步骤S216之后，还可以包括但不限于步骤S901至S911。
S901、组播源100的组播栈向组播源100的WiFi驱动发送组播传输指令；组播传输指令包括控制信令帧1。
S902、组播源100的WiFI驱动通过VAP1组播发送控制信令帧1。
控制信令帧1可以为首次传输的控制信令帧，也可以是重传的控制信令帧，此处不做具体限定。
示例性的，参考图9A，控制信令帧1的MAC头携带的源地址为组播源100的MAC地址；控制信令帧1的MSDU中的源地址为组播源100的MAC地址，目的地址为组播MAC地址，实际源地址为组播源100的MAC地址，实际目的地址为客户端200的MAC地址。
S903、客户端200的WiFI驱动通过VAP2监听到控制信令帧1。
S904、客户端200的WiFI驱动向组播栈发送经组播密钥1解密后的控制信令帧1。
接收到控制信令帧1，客户端200的WiFI驱动获取控制信令帧1的MAC头中的源地址，并查表获取上述源地址对应的密钥为组播密钥1；客户端200的WiFI驱动利用组播密钥1解密控制信令帧1中的MSDU，并将解密后的MSDU发送给组播栈。
S905、客户端200的组播栈基于控制信令帧1更新组播源100对应的接收窗口，基于更新后的接收窗口确定信令确认帧1，信令确认帧1包括确认信息，确认信息用于指示组播源100对应的接收窗口维护的控制信令帧的接收情况。
组播组中的各客户端(例如客户端200)可以为组播源100维护一个接收窗口，接收窗口用于维护接收到的来自组播源100的控制信令帧的接收信息。当接收到来自组播源100的控制信令帧时，客户端200基于该控制信令帧中的MSDU携带的实际目的地址，确定该控制信令帧是否是发送给本设备的；若是，则基于上述MSDU更新组播源100对应的接收窗口；并基于更新后的接收窗口确定确认信息。确认信息包括接收窗口当前对应的R-LE、R-UE和Bitmap，确认信息用于指示组播源100对应的接收窗口维护的控制信令帧的接收情况。
可以理解，组播源100想要单独向客户端200发送控制信令时，利用控制信令帧1中MSDU携带的实际目的地址(即客户端200的MAC地址)，可以让客户端200知道该控制信令帧是发送给本设备的；这样，组播源100无需和客户端200建立WiFi连接，通过VAP组播发送上述控制信令帧1也间接实现了对客户端200的单播传输。
在一些实施例中，还提供了接收窗口的超时处理机制，客户端200可以定期基于超时处理机制更新组播源100对应的接收窗口；然后，基于更新后的接收窗口确定确认信息，并向组播源100反馈上述确认信息对应的信令确认帧。
S906、客户端200的组播栈向客户端200的WiFI驱动发送信令确认帧1。
S907、客户端200的WiFI驱动通过VAP2组播发送信令确认帧1。
S908、组播源100的WiFI驱动通过VAP1监听到信令确认帧1。
S909、组播源100的WiFI驱动向组播栈发送经组播密钥1解密后的信令确认帧1。
示例性的，参考图9B，信令确认帧1的MAC头携带的源地址为虚拟组播源地址；信令确认帧1的MSDU中的源地址为虚拟组播源地址，目的地址为组播MAC地址，实际源地址为客户端200的MAC地址、实际目的地址为组播源100的MAC地址。
S910、组播源100的组播栈的基于信令确认帧1更新客户端100对应发送窗口，并确定是否重传控制信令帧2，若是，则执行S911。
在一些实施例中，组播源100可以为组播组中的每个客户端分别维护一个发送窗口，例如客户端200对应的发送窗口，该发送窗口用于缓存已发送且未被客户端200接收的控制信令帧以及维护已发送的控制信令帧的发送信息。组播源100基于客户端200反馈的信令确认帧1，可以更新客户端200对应的发送窗口。此外，针对信令确认帧1指示的客户端200未接收到的控制信令帧2，组播源100基于发送窗口维护的控制信令帧2的发送信息，可以确定是否重传控制信令帧2。
在一些实施例中，还提供了发送窗口的超时处理机制，组播源100可以定期基于超时处理机制分别定期更新各客户端(例如客户端200)对应的发送窗口，并基于更新后的客户端200对应的发送窗口，确定是否重传该发送窗口缓存的还未被接收的控制信令帧。
S911、组播源100的组播栈向WiFI驱动发送组播传输指令，组播传输指令用于传输控制信令帧2。
本申请实施例中，组播组中客户端也可以向组播源100组播发送控制信令帧，组播源100也可以根据接收到控制信令帧向客户端反馈信令确认帧。示例性的，如图9C所示，上述组播报文2为控制信令帧3，组播报文1为信令确认帧2时，在上述组播建立阶段的步骤S216之后，还可以包括但不限于步骤S1001至S1011。
S1001、客户端200的组播栈向客户端200的WiFi驱动发送组播传输指令；组播传输指令包括控制信令帧3。
示例性的，参考图9A，控制信令帧3的MAC头携带的源地址为虚拟组播源地址；控制信令帧3的MSDU中的源地址为虚拟组播源地址，目的地址为组播MAC地址，实际目的地址为组播源100的MAC地址，实际源地址为客户端200的MAC地址。
S1002、客户端200的WiFI驱动通过VAP2组播发送控制信令帧3。
S1003、组播源100的WiFI驱动通过VAP1监听控制信令帧3。
S1004、组播源100的WiFI驱动向组播栈发送经组播密钥1解密后的控制信令帧3。
S1005、组播源100的组播栈基于控制信令帧3更新客户端200对应的接收窗口，基于更新后的接收窗口确定确认信息，确认信息用于指示客户端200对应的接收窗口维护的控制信令帧的接收情况。
组播源100可以为组播组中的各客户端(例如客户端200)分别维护一个接收窗口，接收窗口用于维护接收到的来自客户端200的控制信令帧的接收信息。当接收到来自客户端200的控制信令帧时，组播源100基于该控制信令帧中的MSDU携带的实际目的地址，确定该控制信令帧是否是发送给本设备的；若是，则基于上述MSDU更新客户端200对应的接收窗口；并基于更新后的接收窗口确定确认信息。确认信息包括接收窗口当前对应的R-LE、R-UE和Bitmap，确认信息用于指示客户端200对应的接收窗口维护的控制信令帧的接收情况。
S1006、组播源100的组播栈向组播源100的WiFI驱动发送信令确认帧2，信令确认帧2包括上述确认信息。
S1007、组播源100的WiFI驱动通过VAP1组播发送信令确认帧2。
S1008、客户端200的WiFI驱动通过VAP2监听到信令确认帧2。
S1009、客户端200的WiFI驱动向组播栈发送经组播密钥1解密后的信令确认帧2。
示例性的，参考图9B，信令确认帧2的MAC头携带的源地址为虚拟组播源地址；控制信令帧1的MSDU中的源地址为虚拟组播源地址，目的地址为组播MAC地址，实际源地址为客户端200的MAC地址，实际目的地址为组播源100的MAC地址。
S1010、客户端200的组播栈的基于信令确认帧2更新组播源100对应的发送窗口，并确定是否重传控制信令帧4，若是，则执行S1011。
在一些实施例中，组播组中的每个客户端分别为组播源100维护了一个发送窗口，该发送窗口用于缓存已发送且未被组播源100接收的控制信令帧以及维护已发送的控制信令帧的发送信息。客户端200基于组播源100反馈的信令确认帧2，可以更新组播源100对应的发送窗口。此外，针对信令确认帧2指示的组播源100未接收到的控制信令帧4，组播源100基于发送窗口维护的控制信令帧4的接收信息，可以确定是否重传控制信令帧4。
S1011、客户端200的组播栈向WiFI驱动发送组播传输指令，组播传输指令用于传输控制信令帧4。
下面对本申请实施例提供的重传机制涉及的接收窗口发送窗口分别进行详细介绍，进而对上述步骤S901、S905、S910的具体实现进行介绍。类似的，步骤S1001、S1005、S1010的具体实现可以分别参考S901、S905、S910的相关描述。
(1)接收窗口
本申请实施例中，组播源100为组播组中的为每个客户端维护一个接收窗口，而组播组中的每个客户端则只需为组播源100维护一个接收窗口。一个接收窗口用来维护来自一个指定发送端的控制信令帧的接收信息；接收窗口最多可维护MAX_WINDOW_LEN个控制信令帧的接收信息。例如，MAX_WINDOW_LEN的默认值为16。
示例性的，客户端200根据接收到的来自组播源100的控制信令帧，维护组播源100对应的接收窗口。图10A示出了客户端200为组播源100维护的一种接收窗口的示意图，该接收窗口可以包括MAX_WINDOW_LEN(例如16)个小窗口，各小窗口对应的索引(index)为0～(MAX_WINDOW_LEN-1)，例如0～15。针对上述接收窗口中每个小窗口对应的控制信令帧，该小窗口可以维护表2所示的接收信息。
表2
如图10A所示，按照客户端200接收到的来自组播源100的控制信令帧的HML控制标识，该接收窗口可以依序维护各控制信令帧的接收信息；根据各小窗口对应的HML接收标识，图10A示出了该接收窗口中各小窗口对应的控制信令帧是否已接收。如图10A所示，HML控制标识小于等于35的信令帧均已接收，HML控制标识为36的信令帧还未接收到，即该接收窗口中未接收的控制信令帧的HML控制标识的最小值是36；HML控制标识为41的控制信令帧已接收，HML控制标识大于41的控制信令帧均未接收，即该接收窗口中已接收到的控制信令帧的HML控制标识的最大值为41。
接收窗口的下沿(R-LE)，指接收窗口中未接收的控制信令帧的HML控制标识的最小值；接收窗口的上沿(R-UE)，指接收窗口中已接收的控制信令帧的HML控制标识的最大值。图10A的示例中，接收窗口的R-LE为36，R-UE为41。
本申请实施例中，接收窗口的R-UE对应的小窗口的索引可以小于R-LE对应的小窗口的索引。示例性的，图10B示出了客户端200为组播源100维护的另一种接收窗口的示意图，该接收窗口的R-UE为47，R-UE对应小窗口的索引为0，R-LE为42，R-LE对应小窗口的索引为10。可以理解，当索引为15的小窗口按照HML控制标识依序维护了控制信令帧的接收信息时，则返回从索引为0的小窗口开始继续依序维护新接收到控制信令帧的接收信息。可以理解，接收窗口的第一个小窗口也可以视为最后一个小窗口的下一个小窗口。
本申请实施例中，客户端200可以根据接收窗口中各小窗口的接收信息，向组播源100回复信令确认帧，以反馈各控制信令帧的接收情况。参考图9B描述的信令确认帧，信令确认帧中的确认信息包括接收窗口的R-LE、接收窗口的R-UE以及Bitmap，Bitmap指示了R-LE指向的小窗口至R-UE指向的小窗口中的各小窗口对应的控制信令帧的接收情况。示例性的，基于图10A所示的接收窗口确认接收窗口的R-LE为36，R-UE为41，Bitmap为001101；Bitmap的最低bit位“0”指示“36”所指向的小窗口对应的控制信令帧未接收，最高bit位“1”指示“41”所指向的小窗口对应的控制信令帧已接收。
下面具体介绍步骤S905中客户端200如何基于接收到的控制信令帧1更新组播源100的接收窗口，并根据接收窗口向组播源100反馈信令确认帧。
示例性的，图10C示出了客户端200更新组播源100的接收窗口以及反馈信令确认帧的一种处理流程，该处理流程包括步骤S601至S605。
S601、根据控制信令帧1中的实际目的地址(actual dest addr)，确定是否是发送给本设备的组播帧；若是则执行步骤S602；若否，则直接丢弃，并退出。
S602、根据控制信令帧1中的实际源地址(actual src addr)，确定控制信令帧1的发送端是否属于自己的组播组；若是则执行步骤S603；若否，则直接丢弃，并退出。
具体的，客户端200的组播栈配置有组播组的组播源100的MAC地址，客户端200确定控制信令帧1中的实际源地址是否为组播源100的MAC地址；若是，则确定控制信令帧1的发送端属于自己的组播组，客户端200执行步骤S603。
类似的，组播源100的组播栈配置有组播组中各客户端的实际的MAC地址，步骤S1005中，针对客户端200发送给组播源100的控制信令帧3，组播源100根据控制信令帧3中的实际源地址字段，可以确定控制信令帧3的发送端是否为组播组中的客户端。
S603、根据控制信令帧1中的子类型(subtype)，将本控制信令帧1提交给相应的模块进行处理。
参考表1，控制信令帧的子类型可以包括0(即应用层下发的控制信令)、1即(RaptorQ编码参数通知帧)、2(即自适应参数反馈帧)和其他。本申请实施例中，不同的子类型的控制信令帧，可以对应不同的处理模块。例如，控制信令帧1的子类型为0时，将控制信令帧1传输给应用层进行处理。
S604、根据控制信令帧1中的实际源地址(actual src addr)，获取组播源100对应的接收窗口。
S605、根据控制信令帧1中的HML控制标识对该接收窗口进行更新。
在一些实施例中，参见图10D，步骤S605具体可以包括步骤A1至A10。
A1、根据控制信令帧1的HML控制标识确定小窗口对应的索引Index1＝(HMLControl ID％MAX_WINDOW_LEN)。
本申请实施例中，接收窗口中的小窗口，按照接收到的控制信令帧的HML控制标识，依序维护接收到的控制信令帧的接收信息。因此，根据控制信令帧1的HML控制标识，可以确定用于维护控制信令帧1的小窗口的Index1。
A2、根据接收窗口的R-LE和R-UE确定接收窗口是否已满，若已满，则执行步骤A3；若未满，则执行步骤A4。
在一些实施例中，参考图10E，当R-LE指向的窗口的索引1等于R-UE指向的窗口的索引2加1时，即R-LE指向的小窗口是R-UE指向的小窗口的下一个时，确定接收窗口已满，不存在空闲小窗口。参考图10A和图10B，R-LE指向的小窗口不是R-UE指向的小窗口的下一个时，则确定接收窗口未满，存在空闲小窗口。
在一些实施例中，空闲小窗口指还未维护指定控制信令帧的小窗口，空闲小窗口中的接收信息(例如HML控制标识)均为格式化的初始值。在一些实施例中，参考图10A，R-UE指向的小窗口的索引(即In1)大于R-LE指向的小窗口的索引(即In2)时，索引大于In2的小窗口和/或索引小于In1的小窗口中，存在空闲小窗口。参考图10B，R-UE指向的窗口的索引2小于R-LE指向的窗口的索引1时，索引大于In2且小于In1的小窗口中存在空闲小窗口。
A3、将Index2至Index1对应的小窗口清空后，利用Index1对应的小窗口维护控制信令帧1的接收信息，Index2为R-LE指向的小窗口的索引，Index2＝(R-LE％MAX_WINDOW_LEN)。
在一些实施例中，接收窗口已满时，将R-LE指向的小窗口至Index1对应的小窗口均清空。将接收窗口的小窗口清空，包括将该小窗口维护的接收信息格式化，接收信息恢复初始值。利用Index1对应的小窗口维护控制信令帧1，具体包括：将Index1对应的小窗口的接收标识更新为1，小窗口的HML控制标识更新为控制信令帧1的HML控制标识。
A4、确定Index1对应的小窗口的接收标识(RecvFlag)是否为1；若是，则执行步骤A5；若否，则执行步骤A6。
A5、控制信令帧1为重复帧，丢弃控制信令帧1，并退出。
A6、将该小窗口的接收标识更新为1。
在一些实施例中，接收窗口未满时，若Index1对应的小窗口的接收标识为1，则表明Index1对应的小窗口维护的控制信令帧为控制信令帧1，且控制信令帧1已被接收过；客户端200直接丢弃控制信令帧1，并退出该处理流程。若Index1对应的小窗口的接收标识为0，则基于已接收到的控制信令帧1，将小窗口的接收标识由0置为1。
本申请实施例中，确定控制信令帧1对应的索引为index1的小窗口，且更新小窗口的接收信息后；客户端200可以更新接收窗口的R-UE(例如执行步骤A7、A8)，和/或，更新接收窗口的R-LE(例如执行步骤A7、A9和A10)。
A7、确定控制信令帧1的HML控制标识是否大于R-UE，若是，则执行步骤A8；若否，则另j＝R-LE，并执行步骤A9。
A8、将R-UE更新为控制信令帧1的HML控制标识。
A9、HML控制标识为j的小窗口的RecvFlag是否为0；若否，则令j＝j+1,并返回执行步骤A9；若是，则执行步骤A10。
A10、确定该接收窗口的R-LE为j。
在一些实施例中，控制信令帧1的HML控制标识小于等于R-UE时，客户端确定R-LE指向的窗口及其之后的小窗口中第一个接收标识为0的小窗口，并将R-LE更新为该小窗口的HML控制标识，该小窗口可以被称为第一小窗口。
S606、客户端200可以根据更新后的组播源100的接收窗口，确定向组播源100反馈的信令确认帧1。
在一些实施例中，客户端200在每次接收组播源100的控制信令帧，并对组播源100的接收窗口处理后，即向组播源100反馈一个信令确认帧。这样，可以及时向组播源100反馈控制信令帧的接收情况。
在一些实施例中，客户端200也可以在接收组播源100的N个控制信令帧，并根据N个控制信令帧分别对组播源100的接收窗口处理后，才向组播源100反馈一个信令确认帧。相比每次接收控制信令帧后均反馈信令确认帧，这样可以降低信令损耗，提高信令发送速率。
在一些实施例中，客户端200根据组播源100的接收窗口的最新情况，定期向设备反馈信令确认帧。相比每次接收控制信令帧后均反馈信令确认帧，这样可以降低信令损耗，提高信令发送速率。
下面具体介绍接收窗口的超时处理机制。
本申请实施例中，组播源100和组播组中客户端均以预设时长为一个周期对其维护的每个接收窗口进行周期性地超时处理。例如，预设时长为1s。下面以客户端200维护的组播源100对应的接收窗口为例，介绍接收窗口的超时处理机制。
在一些实施例中，针对组播源100的发送窗口，客户端200遍历R-LE指向的小窗口至R-UE指向的小窗口中的N个小窗口，查找N个小窗口中每一个接收标识为0的小窗口，N为大于1的正整数。针对一个接收标识为0的小窗口1(该小窗口可以被称为第四小窗口)，将小窗口1对应的超时轮询(Tick)次数加1。若该Tick加1后超过预设值1(即第二预设值)，则将R-LE指向的小窗口至小窗口1强制清空。上述预设值1可以被称为强制提交周期(FORCE_COMMIT_PERIOD)，例如上述预设值1等于5。然后，客户端200从小窗口1开始进行移窗处理，确定小窗口1之后的第一个未接收的小窗口2(该小窗口可以被称为第五小窗口)；更新接收窗口的R-LE为小窗口2对应的HML控制标识，即将R-LE指向小窗口2。
示例性的，图10F示出了客户端200对组播源100的接收窗口进行超时处理的流程示意图。设置j的初始值为1，上述流程包括如下步骤B1至B6。令j的初始值为1。
B1、确定接收窗口中R-LE至R-UE的N个小窗口中的第j个小窗口的接收标识(RecvFlag)是否为0，N为大于1的正整数；若否，则令j＝j+1，并返回执行步骤B1；若是，则执行步骤B2。
B2、将第j个小窗口对应的超时轮询次数(Tick)加1。
B3、确定第j个小窗口对应的Tick是否大于预设值1；若否，则令j＝j+1，并返回执行步骤B1；若是，则执行步骤B4。
B4、清空上述N个窗口中的R-LE指向的小窗口至第j个小窗口，并令j＝j+1。
B5、确定第j个小窗口的接收标识是否为0；若否，则令j＝j+1，并返回执行步骤B5；若是，则执行步骤B6。
B6、将接收窗口的R-LE指向第j个小窗口，即更新R-LE为第j个小窗口对应的HML控制标识。
示例性的，如图10G所示，针对接收窗口中HML控制标识为R-LE(即36)至R-UE(即41)的6个小窗口，确定HML控制标识为37的小窗口1的接收标识为0，若小窗口1的Tick加1后大于5，清空HML控制标识为36至37的小窗口，并更新R-LE为小窗口1之后的第一个未接收的小窗口的HML控制标识，即40。
类似的，组播源100对客户端的接收窗口的超时处理流程包括：组播源100遍历组播组每个客户端对应的接收窗口，对每个客户端对应的接收窗口进行超时处理，以更新每个客户端对应的接收窗口和该接收窗口的R-LE。组播源100对客户端200的接收窗口进行超时处理的具体实现，可以参考上述客户端200对组播源100的接收窗口进行超时处理的相关描述，此处不再赘述，
(2)发送窗口
本申请实施例中，组播源100为组播组中的为每个客户端维护一个发送窗口，而组播组中的每个客户端则只需为组播源100维护一个发送窗口。发送窗口用来缓存已经发送但还未被成功接收的信令帧以及维护其对应的发送信息；发送窗口最多可缓存MAX_WINDOW_LEN个控制信令帧。例如MAX_WINDOW_LEN的默认值为16。
示例性的，组播源100可以向客户端200发送控制信令帧，并根据已发送的控制信令帧和客户端200反馈的信令确认帧1，维护客户端200对应的发送窗口。客户端200反馈的信令确认帧1用于指示未接收到的控制信令帧。图11A示出了组播源100为客户端200维护的发送窗口的示意图，该发送窗口可以包括MAX_WINDOW_LEN(例如16)个小窗口，各小窗口对应的索引(index)为0～(MAX_WINDOW_LEN-1)，例如0～15。针对上述发送窗口中每个小窗口对应的控制信令帧，该小窗口可以维护表3所示的发送信息。
表3
如图11A所示，按照组播源100向客户端200发送的控制信令帧的HML控制标识，发送窗口可以依序维护各控制信令帧的发送信息，根据各小窗口对应的发送状态，图11A示出了该发送窗口中各小窗口对应的控制信令帧是否已收到确认，即是否确认已被接收。示例性的，HML控制标识为35的控制信令帧已收到确认，HML控制标识为36的信令帧还未收到确认。
类似于接收窗口，发送窗口也存在一个下沿(T-LE)和一个上沿(T-UE)。其中T-LE指向最早发送但未收到确认的控制信令帧对应的小窗口，T-LE等于该控制信令帧的HML控制标识；而T-UE指向最新发送的控制信令帧对应的小窗口，T-UE等于该控制信令帧的HML控制标识。当发送窗口已满时，后续待发送的信令帧会被缓存到预设链表(例如CachedSkb链表)中。
类似于接收窗口，发送窗口已满，指T-LE指向的小窗口是T-UE指向的小窗口的下一个，发送窗口不存在空闲小窗口。发送窗口未满，指T-LE指向的小窗口不是T-UE指向的小窗口的下一个，发送窗口存在空闲小窗口。发送窗口中的第一个小窗口可以视为最后一个小窗口的下一个小窗口。在一些实施例中，发送窗口中的空闲小窗口指该空闲小窗口未缓存控制信令帧，也未维护指定控制信令帧的发送信息，该发送窗口的发送信息为格式化的初始值。
本申请实施例中，当组播源100发生特定事件时，可以触发组播源100向客户端200发送控制信令帧，以及更新发送窗口。例如，前述步骤S901中组播源100向客户端200发送控制信令帧1，前述步骤S911中组播源100向客户端200发送控制信令帧2。上述特定事件可以包括如下事件1至3。
事件1：其他模块(例如应用层中的APP或自适应参数调整模块)新构建一个针对客户端200的控制信令帧，组播源100向客户端200发送该控制信令帧。
事件2：组播源100接收到来自客户端200的一个信令确认帧，该信令确认帧触发重传指定控制信令帧。
示例性的，前述步骤S910中，当接收到客户端200反馈的信令确认帧1时，组播源100可以根据信令确认帧1中的R-UE、R-LE和Bitmap更新发送窗口，并在发送窗口满足重传条件时触发重传控制信令帧2。后续实施例中，图11B示出了步骤S910的具体实现流程，此处暂不赘述。
事件3：超时处理机制触发重传。
本申请实施例中，组播源100或组播组中客户端以预设时长为一个周期对其维护的接收窗口进行周期性地超时处理。超时处理流程中，发送窗口满足重传条件时会触发重传特定的控制信令帧。例如，上述预设时长为1s。后续实施例中，图11E示出了发送窗口的超时处理机制的一种实现流程，此处暂不赘述。
下面具体介绍步骤S910中组播源100如何根据信令确认帧1更新客户端200对应的发送窗口和触发重传。信令确认帧1的确认信息携带接收窗口的R_LE、R_UE和Bitmap。
示例性的，图11B示出了步骤S910的一种处理流程，该处理流程包括步骤S701至S706。
S701、根据信令确认帧1中的实际目的地址(actual dest addr)，确定是否是发送给本设备的组播帧；若是则执行步骤S702；若否，则直接丢弃该信令确认帧，并退出。
S702、根据信令确认帧1中的实际源地址(actual src addr)，确定信令确认帧1的发送端是否属于自己的组播组；若是则执行步骤S703；若否，则直接丢弃该信令确认帧，并退出。
组播源100的组播栈配置有组播组中各客户端的实际的MAC地址，组播源100根据信令确认帧1中的实际源地址，可以确定信令确认帧1的发送端是否为组播组中的客户端。
S703、根据信令确认帧1中的实际源地址(actual src addr)，组播源100获取客户端200对应的发送窗口。
S704、确认R-LE小于T-LE或者R-UE大于T-UE；若是，则退出该处理流程；若否，则执行步骤S705。
示例性的，参见图11A，发送窗口当前的T_LE为36，T_UE为42；当R-LE小于36或R-UE大于42时，表明信令确认帧1为过时帧或错误帧，组播源100退出该处理流程；当R-LE大于36且R-UE小于42时，则组播源100继续执行后续流程。
S705、当R-LE大于T-LE时，将发送窗口中T-LE指向的小窗口至R-LE指向的小窗口(即HML控制标识为R-LE的小窗口)的前一个小窗口清空；然后将T-LE的取值更新为R-LE。
在一些实施例中，将发送窗口中的小窗口清空，包括释放该小窗口的PktBuf字段中的存储地址缓存的控制信令帧，并清空(例如格式化，恢复初始值)该小窗口维护的发送信息。
具体的，在一种实现方式中，参见图11C，步骤S705包括步骤C1至C3。
C1、令frameid等于T-LE。
C2、确定frameid是否等于R-LE；若否，则执行步骤C3；若是，将T-LE的取值更新为R-LE，并执行步骤S706。
C3、清空frameid对应的小窗口；然后，令frameid＝frameid+1，并返回执行步骤C2。
示例性的，参见图11D，发送窗口当前的T_LE为36，T_UE为42；信令确认帧1携带的接收窗口的R-LE为38，R-UE为41。组播源100清空发送窗口中HML控制标识为36至37的小窗口，并将T-LE的取值更新为38。
S706、当R-LE等于T-LE时，基于Bitmap，确定发送窗口中R-LE至R-UE指向的小窗口中已被接收的小窗口，释放小窗口的存储地址缓存的控制信令帧；以及确定未被接收的小窗口，并确定是否对小窗口维护的控制信令帧2进行重传。
在一些实施例中，组播源100基于信令确认帧1携带R-LE、R-UE和Bitmap，确定发送窗口中上述Bitmap标记为1的控制信令帧对应的小窗口，释放该小窗口对应的存储地址缓存的控制信令帧，该小窗口可以被称为第二小窗口；确定发送窗口中上述Bitmap标记为0的控制信令帧2对应的小窗口，并在确定该小窗口满足重传条件时，重传控制信令帧2，该小窗口可以被称为第三小窗口。在一些实施例中，释放该小窗口对应的存储地址缓存的控制信令帧，包括：删除小窗口的PktBuf字段中的存储地址缓存的控制信令帧，并清空删除(例如格式化，恢复初始值)PktBuf字段中的存储地址。
具体的，在一种实现方式中，设置frameid初始值等于R-LE，参见图11C，步骤S706包括C4至C8。
C4、确定frameid是否小于R-UE；若是，则执行步骤C5；若否，则退出该处理流程。
C5、根据信令确认帧1中携带的Bitmap，确定frameid对应的小窗口在Bitmap中是否标记为1；若是，则执行步骤C6；若否，执行步骤C7。
根据信令确认帧1中携带的R-LE、R-UE和Bitmap，可以确定HML控制标识为frameid的小窗口在Bitmap中是否标记为1。标记为1表示该小窗口对应的控制信令帧已被接收，标记为0表示该小窗口对应的控制信令帧未被接收。
C6、释放frameid对应的小窗口中的存储地址缓存的控制信令帧，令frameid＝frameid+1，并返回执行步骤C4。然后继续对下一个窗口进行处理，直至遍历Bitmap中的所有标识位。
C7、确定frameid对应的小窗口是否满足重传条件；若是，则执行步骤C8；若否，则令frameid＝frameid+1，并返回执行步骤C4。然后继续对下一个窗口进行处理，直至遍历Bitmap中的所有标识位。
若HML控制标识为frameid的小窗口在Bitmap中的标志位被标记为0，则基于该小窗口的重传标识和重传次数，确定该小窗口缓存的控制信令帧是否满足重传条件；若满足，则重传上述控制信令帧。
在一些实施例中，重传条件包括：该frameid对应的小窗口在本重传周期内还未被重传过(即重传标识RetranFlag为0)；该frameid对应的小窗口的重传次数(RetranCnt)小于预设的最大值(MAX_RETRAN_CNT)，例如MAX_RETRAN_CNT取值为5。
C8、重传frameid对应的小窗口缓存的控制信令帧2，更新该小窗口对应的重传标识为1，重传次数RerantCnt等于RerantCnt+1。
示例性的，参见图11D，发送窗口当前的T_LE为36，T_UE为42；信令确认携带的接收窗口的R-LE为38，R-UE为41，Bitmap为0101。组播源100清空HML控制标识为36和37的小窗口，更新T-LE为38。Bitmap中的4个标识位，分别指示HML控制标识为38至41的控制信令帧是否已被接收。Bitmap指示HML控制标识为39和41的控制信令帧已被接收，针对发送窗口中HML控制标识为38和40的小窗口，组播源100释放小窗口中的存储地址缓存的控制信令帧。Bitmap指示HML控制标识为38和40的控制信令帧未被接收；以HML控制标识为38的控制信号帧为例，组播源100确定发送窗口中HML控制标识为38的小窗口是否满足重传条件；若满足，则重传该小窗口缓存的HML控制标识为39的控制信令帧。
下面具体介绍发送窗口的超时处理机制。
类似于接收窗口，组播源100和组播组中客户端均以预设时长为一个周期对其维护的每个接收窗口进行周期性地超时处理。例如，预设时长为1s。下面以组播源100维护的客户端200对应的发送窗口为例，介绍发送窗口的超时处理机制。
在一些实施例中，以1s为一个周期进行发送窗口的超时处理。针对客户端200对应的发送窗口，组播源100遍历T-LE指向的小窗口至T-UE指向的小窗口中的N个小窗口。针对N个小窗口中任一个发送状态(SendStatus)为0的小窗口1，将小窗口1对应的超时轮询(Tick)次数加1，该小窗口可以被称为第六小窗口。若该Tick加1后大于等于预设值2(例如RETRAN_PEROID)，则判断小窗口1是否满足重传条件，如果满足则重传小窗口1维护的控制信令帧，并将小窗口1的Tick置为0，重传标识(RetranFlag)置为1，重传次数(RetranCnt)加1；如果不满足重传条件且重传次数超过预设值3(例如MAX_RETRAN_CNT)，则清空小窗口1，并将T-LE指向该小窗口之后第一个发送状态为0的小窗口。在一些实施例中，组播源100也可以在遍历上述N个小窗口之后，再将T-LE指向发送状态为0且控制标识最小的小窗口。
示例性的，图11E示出了组播源100对客户端200对应的发送窗口进行超时处理的一种处理流程。设置j的初始值为1，上述流程包括如下步骤D1至D6。
D1、确定接收窗口中T-LE至T-UE的N个小窗口中的第j个小窗口的发送状态(SendStatus)是否为0，N为大于1的正整数，j小于等于N；若否，则令j＝j+1，并返回执行步骤D1；若是，则执行步骤D2。
D2、将第j个小窗口对应的超时轮询次数(Tick)加1。
D3、确定第j个小窗口对应的Tick是否大于预设值2；若否，则令j＝j+1，并返回执行步骤D1；若是，则执行步骤D4。
D4、确定第j个小窗口是否满足重传条件；若是，则执行步骤D5；若否，则行步骤D6。
D5、重传第j个小窗口缓存的控制信令帧，并将Tick置为0，重传标识置为0，重传次数加1。然后，令j＝j+1，并返回执行步骤D1。
D6、确定第j个小窗口的重传次数是否大于预设值3；若是，则执行步骤D7；若否，则令j＝j+1，并返回执行步骤D1。
D7、清空第j个小窗口，令j＝j+1。
D8、确定第j个小窗口的接收标识是否等于0；若是，则执行步骤D9；若否，则令j＝j+1，并返回执行步骤D1。
D9、将T-LE指向第j个窗口。
3、组播删除
组播组中的成员是动态的，主机可以在任何时刻加入和离开组播组。
在一些实施例中，以客户端200为例，客户端200可以主动退出组播组；客户端200主动退出组播组时，会删除该组播组的组播组信息，并通过蓝牙通知组播源100，组播源100会将该客户端200从组播组的组播设备列表中清除。
示例性的，以客户端200为例，图12A示出了本申请实施例提供的一种客户端主动退出阶段的方法流程图。如图所示，客户端200加入组播组后(例如前述步骤S216后)，还可以包括但不限于步骤S401至S412。
S401、客户端200的UI检测到用户的操作5，操作5用于退出组播组。
在一些实施例中，客户端200设置有退出组播组的UI入口，用户通过作用于该UI入口的操作5，可以触发客户端200主动退出组播组，关闭组播应用。示例性的，参考图5A至图5B的相关描述，在投屏场景中，上述组播应用可以为投屏应用，操作5可以用于退出投屏组播组；基于组播源100组播发送的投屏数据，客户端200可以显示投屏画面17；投屏画面17中设置有退出控件401，操作5包括作用于退出控件401的点击操作；响应于操作5，客户端200可以停止显示投屏画面，关闭投屏应用。
S402、基于操作5，客户端200的UI向蓝牙驱动发送组播结束指令。
S403、基于组播结束指令，客户端200的蓝牙驱动与组播源100的蓝牙驱动进行信息交互，以建立蓝牙连接。
具体的，可以参考步骤S202的相关描述，此处不再赘述。
S404、客户端200的蓝牙驱动向组播源100的蓝牙驱动发送组播断开请求消息，组播断开请求消息包括客户端200的设备标识。
S405、基于组播断开请求消息，组播源100的蓝牙驱动向客户端200的蓝牙驱动发送组播断开确认消息。
S406、基于组播断开确认消息，客户端200的蓝牙驱动向客户端200的WiFi驱动发送组播消除指令。
S407、基于上述组播消除指令，客户端200的WiFi驱动向客户端200的组播栈发送组播结束通知。
S408、基于上述组播结束通知，客户端200的组播栈删除客户端侧的组播组信息。
在一些实施例中，客户端侧的组播组信息包括以下部分或全部信息：组播MAC地址、虚拟组播源地址、组播密钥1、组播源100的IP地址1和客户端200的IP地址2。
步骤S404中组播源100的蓝牙驱动接收到组播断开请求消息之后，还包括步骤S409至S412。
S409、基于组播断开请求消息，组播源100的蓝牙驱动向组播源100的WiFi驱动发送客户端退出指令，客户端退出指令用于指示删除组播组中的客户端200。
S410、基于上述客户端退出指令，组播源100的WiFi驱动向组播源100的组播栈发送客户端删除指令，客户端删除指令用于指示删除组播组中的客户端200。
S411、基于上述客户端删除指令，组播源100的组播栈删除客户端200的组播用户信息。
在一些实施例中，组播源100侧维护的组播组信息包括组播组的组播设备列表，组播设备列表存储有组播组中各客户端的组播用户信息。组播源100删除组播设备列表中的客户端200的组播用户信息。
S412、组播源100的蓝牙驱动与客户端200的蓝牙驱动断开蓝牙连接。
本申请实施例中，可以是组播源100的蓝牙驱动在步骤S405(即向客户端200发送组播断开确认消息)或S409之后，主动断开上述蓝牙连接，也可以是客户端200的蓝牙驱动在步骤S405(即接收组播源100发送的组播断开确认消息)或S406之后，主动断开上述蓝牙连接，此处不做具体限定。
在一些实施例中，组播源100结束组播组的组播分享时，可以删除组播源侧的组播组信息，并蓝牙广播组播删除消息；每个客户端接收到组播删除消息后，退出组播应用，并删除本客户端中的组播组信息。
示例性的，以客户端200为例，图12B示出了本申请实施例提供的一种组播源删除阶段的方法流程图。如图所示，客户端200加入组播组后(例如前述步骤S216后)，还可以包括但不限于步骤S501至S511。
S501、组播源100的UI检测到用户的操作6，操作6用于删除组播组。
在一些实施例中，组播源100设置有删除组播组的UI入口，用户通过作用于该UI入口的操作6，可以触发组播源100删除组播组，关闭组播应用。示例性的，参考图5C至图5D的相关描述，在投屏场景中，上述组播应用可以为投屏应用，操作6可以用于删除投屏组播组；组播源100对组播组中的客户端组播投屏时，组播源100显示的用户界面设置有结束控件402，操作6包括作用于结束控件402的点击操作；响应于操作6，组播源100停止组播投屏，删除投屏组播组，关闭投屏应用。
S502、基于操作6，组播源100的UI向组播源100的蓝牙驱动发送组播结束指令。
S503、基于上述组播结束指令，组播源100的蓝牙驱动广播组播删除消息。
在一些实施例中，组播源100的蓝牙驱动，在接收到组播结束指令后的预设时间段内，定期蓝牙广播组播删除消息，以便于组播组内的客户端都能接收到。
S504、基于上述组播结束指令，组播源100的蓝牙驱动向组播源100的WiFi驱动发送组播消除指令。
S505、基于上述组播消除指令，组播源100的WiFi驱动向组播源100的组播栈发送组播结束通知。
S506、基于上述组播结束通知，组播源100的组播栈删除组播源侧的组播组信息。
在一些实施例中，组播源侧的组播组信息包括以下部分或全部信息：组播设备列表、组播MAC地址、虚拟组播源地址、组播密钥1等信息。
S507、客户端200的蓝牙驱动接收到组播源100蓝牙广播的组播删除消息后，向客户端200的UI发送组播消除指令。
S508、基于上述组播消除指令，客户端200的UI退出组播分享界面。
示例性的，参考图3F和图3G的相关描述，投屏场景中，上述组播分享界面可以包括投屏画面13。
S509、客户端200的蓝牙驱动接收到组播源100蓝牙广播的组播删除消息后，还向客户端200的WiFi驱动发送消除指令。
S510、基于上述消除指令，客户端200的WiFi驱动向客户端200的组播栈发送组播结束通知。
S511、基于上述组播结束通知，客户端200的组播栈删除组播组信息。
基于前述实施例，本申请实施例提供了一种组播通信方法，该组播通信方法应用于组播通信系统，组播通信系统包括组播源和至少一个客户端，上述至少一个客户端包括第一客户端。示例性的，该组播通信方法包括步骤S1101至S1107。
S1101、组播源确定组播组的组播地址和第一组播密钥。
示例性的，第一组播密钥包括前述组播密钥1。
S1102、组播源向第一客户端发送第一蓝牙消息，第一蓝牙消息用于邀请第一客户端加入组播组，第一蓝牙消息包括组播地址和第一组播密钥。
示例性的，第一客户端包括前述客户端200或客户端300，第一蓝牙消息包括前述组播邀请消息。
在一些实施例中，上述方法还包括：组播源接收第一操作，第一操作用于创建组播组；上述组播源确定组播组的组播地址和第一组播密钥，包括：响应于第一操作，组播源确定组播组的组播地址和第一组播密钥。
示例性的，第一操作包括前述操作1。参考图3A至图3D的相关描述，在投屏场景中，操作1可以是用于开启无线投屏的操作，例如作用于无线投屏的开关图标201的点击操作。
在一些实施例中，组播源向第一客户端发送第一蓝牙消息之前，上述方法还包括：组播源蓝牙扫描附近支持组播通信的蓝牙设备；组播源显示扫描到的至少一个蓝牙设备，上述至少一个蓝牙设备包括第一客户端；组播源接收第二操作，第二操作用于邀请第一客户端加入组播组；响应于第二操作，组播源与第一客户端建立蓝牙连接。
示例性的，第二操作包括前述操作3。示例性的，参考图3A至图3D的相关描述，投屏场景中，组播源将检测到的开启无线分享的HML组播设备的设备选项显示在用户界面11上，以供用户选择。例如操作3包括作用于客户端200的设备选项203的操作(例如点击操作)。
在一些实施例中，组播源显示扫描到的至少一个蓝牙设备之前，上述方法还包括：第一客户端接收第三操作；响应于第三操作，第一客户端蓝牙广播第一发现信号，第一发现信号指示第一客户端支持组播通信；组播源基于第一发现信号扫描到第一客户端。
示例性的，第三操作包括前述操作2，第一发现信号包括前述发现信号2。参考图4C至图4D的相关描述，在投屏场景中，上述操作2包括开启无线分享的操作，例如操作2可以为作用于无线投屏的开关图标302的点击操作。
在一些实施例中，组播源向第一客户端发送第一蓝牙消息之前，上述方法还包括：响应于第一操作，组播源蓝牙广播第二发现信号；基于蓝牙监听到的第二发现信号，第一客户端与组播源建立蓝牙连接；第一客户端向组播源发送第三蓝牙消息，第三蓝牙消息用于请求加入组播组；上述组播源向第一客户端发送第一蓝牙消息，包括：响应于第三蓝牙消息，组播源向第一客户端发送第一蓝牙消息。
示例性的，第二发现信号包括前述发现信号1，第三蓝牙消息包括前述加入请求消息。
在一些实施例中，上述组播源向第一客户端发送第一蓝牙消息之前，还包括：组播源为组播源的第一VAP分配第一IP地址，为客户端的第二VAP分配第二IP地址；第一蓝牙消息还包括第一IP地址和第二IP地址；第一IP地址和第二IP地址用于封装组播报文，组播源发送的组播报文中的源IP地址为第一IP地址，第一客户端发送的组播报文中的源IP地址为第二IP地址。
示例性的，第一VAP包括前述VAP1，第一IP地址包括前述IP地址1。第一客户端包括前述客户端200，第二VAP包括前述VAP2，第二IP地址包括前述IP地址2；或者，第一客户端包括前述客户端300，第二VAP包括前述VAP3，第二IP地址包括前述IP地址3。
S1103、第一客户端基于第一蓝牙消息，向组播源发送第二蓝牙消息；第二蓝牙消息用于指示第一客户端确认加入组播组。
示例性的，第二蓝牙消息包括前述确认加入消息。
在一些实施例中，上述第一客户端向组播源发送第二蓝牙消息之后，还包括：断开组播源与第一客户端的蓝牙连接。
在一些实施例中，上述方法还包括：基于第二蓝牙消息，第一组播源在组播设备列表中添加第一客户端的组播用户信息；组播设备列表用于存储组播组中的各客户端的组播用户信息，第一客户端的组播用户信息包括第一客户端的MAC地址和第二IP地址。
S1104、第一客户端配置第一组播密钥对应的源地址为组播源的MAC地址。
S1105、组播源通过WiFi通信技术组播发送经第一组播密钥加密的第一组播报文，第一组播报文的第一MAC头中的源地址为组播源的MAC地址，第一MAC头中的目的地址为组播地址。
示例性的，第一组播报文包括前述组播报文1。
S1106、基于组播地址，第一客户端监听到第一组播报文。
S1107、第一客户端确定第一MAC头中的源地址对应的密钥为第一组播密钥，并利用第一组播密钥解析第一组播报文的数据单元(例如MSDU)。
在一些实施例中，上述组播源向第一客户端发送第一蓝牙消息之前，上述方法还包括：组播源开启第一VAP；上述组播源通过WiFi通信技术组播发送经第一组播密钥加密的第一组播报文，包括：组播源的第一VAP通过WiFi通信技术组播发送经第一组播密钥加密的第一组播报文。
在一些实施例中，上述组播源向第一客户端发送第一蓝牙消息之前，还包括：组播源生成虚拟组播源地址；组播源配置第一组播密钥对应的源地址为虚拟组播源地址；第一蓝牙消息还包括虚拟主播源地址，组播组中的客户端发送的组播报文的MAC头中的源地址为虚拟组播源地址。
在一些实施例中，上述方法还包括：第一客户端通过WiFi通信技术组播发送经第一组播密钥加密的第二组播报文，第二组播报文的第二MAC头中的源地址为虚拟组播源地址，第二MAC头中的目的地址为组播地址；基于组播地址，组播源监听到第二组播报文；组播源确定第二MAC头中的源地址对应的密钥为第一组播密钥，并利用第一组播密钥解析第二组播报文的数据单元。
示例性的，第二组播报文包括前述组播报文2。
在一些实施例中，上述组播源向第一客户端发送第一蓝牙消息之后，还包括：第一客户端基于第一蓝牙消息开启第二VAP；上述第一客户端通过WiFi通信技术组播发送经第一组播密钥加密的第二组播报文，包括：第一客户端的第二VAP通过WiFi通信技术组播发送经第一组播密钥加密的第二组播报文。
在一些实施例中，组播报文的类型包括信令帧和数据帧，信令帧的组播类型包括控制信令帧和信令确认帧；第一组播报文包括第一控制信令帧，第二组播报文包括第一信令确认帧，第一信令确认帧是第一客户端基于第一控制信令帧生成的，第一信令确认帧用于指示组播源发送的控制信令帧的接收情况。
示例性的，第一控制信令帧包括前述控制信令帧1，第一信令确认帧包括前述信令确认帧1。
在一些实施例中，组播报文的类型包括信令帧和数据帧，信令帧的组播类型包括控制信令帧和信令确认帧；第二组播报文包括第一控制信令帧，第一组播报文包括第一信令确认帧，第一信令确认帧是组播源基于第一控制信令帧生成的，第一信令确认帧用于指示第一客户端发送的控制信令帧的接收情况。
示例性的，第一控制信令帧包括前述控制信令帧3，第一信令确认帧包括前述信令确认帧2。
在一些实施例中，信令帧中的数据单元包括信令帧的接收端对应的实际目的地址和信令帧的发送端对应的实际源地址；控制信令帧的数据单元还包括控制标识和数据载荷，数据载荷用于传输有效的控制信令，控制标识用于指示控制信令帧的编号；信令确认帧的数据单元还包括确认信息，确认信息用于指示信令确认帧的接收端已发送的控制信令帧的接收情况。
示例性的，参考图9A和图9B，信令帧的MSDU携带实际目的地址和实际源地址，控制信令帧的MSDU还包括控制标识和数据载荷，信令确认帧的MSDU还包括确认信息。
在一些实施例中，第一客户端为组播源设置了一个接收窗口，用于维护来自组播源的控制信令帧的接收信息；组播源为第一客户端设置一个发送窗口，用于维护发送给第一客户端的控制信令帧的发送信息；上述方法还包括；第一客户端基于第一控制信令帧更新组播源对应的接收窗口，并基于更新后的接收窗口确定第一信令确认帧；第一信令确认帧指示发送窗口维护的第二控制信令帧未被接收；组播源基于第一信令确认帧更新第一客户端对应的发送窗口，确定是否重传第二控制信令帧。示例性的，第二控制信令帧包括前述控制信令帧2。
在一些实施例中，信令帧还包括组播类型；信令帧的组播类型为控制信令帧时，信令帧还包括控制信令帧的子类型，控制信令帧的子类型包括第一子类型和第二子类型，第一子类型和第二子类型对应的处理模块不同；上述方法还包括：第一客户端根据第一控制信令帧中的第一子类型，将第一控制信令帧提交给第一子类型对应的处理模块进行处理。
示例性的，参考图9A，信令帧的MSDU携带组播类型和子类型，表1示出了本申请实施例提供的控制信令帧的几种子类型。
在一些实施例中，接收窗口包括M个小窗口，M为正整数；接收窗口中的小窗口，按照接收到的组播源的控制信令帧的控制标识，依序维护控制信令帧的接收信息；接收窗口中的一个小窗口维护的接收信息包括控制信令帧的控制标识和接收标识；接收标识用于指示控制信令帧是否已接收；接收窗口的第一上沿UE指接收窗口维护的已接收的控制信令帧的控制标识的最大值，接收窗口的第一下沿LE指接收窗口维护的未接收的控制信令帧的控制标识的最小值；发送窗口包M个小窗口；发送窗口中的小窗口，按照向第一客户端发送的控制信令帧的控制标识，依序维护控制信令帧的发送信息；一个小窗口维护的发送信息包括控制信令帧的控制标识；发送窗口的第二UE指发送窗口维护的未被接收的控制信令帧的控制标识的最大值，发送窗口的第二LE指发送窗口维护的未接收的控制信令帧的控制标识的最小值。
示例性的，图10A、图10B和图10E，示出了本申请实施例提供的几种接收窗口；表2示出了本申请实施例提供的接收窗口中的小窗口维护的控制信令帧的接收信息；接收窗口的第一上沿UE包括前述R-UE，接收窗口的第一下沿LE包括前述R-LE。图11A示出了本申请实施例提供的一种接收窗口；表3示出了本申请实施例提供的发送窗口中的小窗口维护的控制信令帧的发送信息；发送窗口的第二UE包括前述T-UE，发送窗口的第二LE包括前述T-LE。
在一些实施例中，第一信令确认帧中的确认信息包括接收窗口的第一UE和第一LE，以及位图，位图依序指示了接收窗口中第一LE指向的小窗口至第一UE指向的小窗口维护的控制信令帧的接收情况。示例性的，参考图9B，信令确认帧的确认信息携带LE、UE和Bitmap。
在一些实施例中，上述第一客户端基于第一控制信令帧更新组播源对应的接收窗口，包括：根据第一控制信令帧中的实际目的地址，确定是发送给本设备的组播帧，且根据第一控制信令帧中的实际源地址，确定第一控制信令帧的发送端属于组播组时，基于第一控制信令帧中的实际源地址获取组播源对应的接收窗口，第一客户端基于第一控制信令帧更新组播源对应的接收窗口。
在一些实施例中，上述第一客户端基于第一控制信令帧更新组播源对应的接收窗口，包括：根据第一控制信令帧的控制标识，确定用于维护第一控制信令帧的小窗口的第一索引，第一索引等于第一控制信令帧的控制标识除以M后的余数；根据第一LE和第一UE确定接收窗口已满时，将第一LE指向的小窗口至第一索引对应的小窗口清空；确定接收窗口未满时，若第一索引对应的小窗口的接收标识取值为第一值，丢弃第一控制信令帧，若第一索引对应的小窗口的接收标识取值为第二值，则将第一索引对应的小窗口的接收标识的取值更新为第一值；接收标识取值为第一值，指示控制信令帧已被接收；接收标识取值为第二值，指示控制信令帧未被接收；第一控制信令帧的控制标识大于第一UE时，将第一UE的取值更新为第一控制信令帧的控制标识；确定第一LE指向的小窗口及其之后的小窗口中第一个接收标识为第二值的第一小窗口，并将第一LE的取值更新为第一小窗口的控制标识。
示例性的，第一索引包括前述Index1。第一值等于1，第二值等于0；或者，第一值等于0，第二值等于1。
在一些实施例中，上述组播源基于第一信令确认帧更新所UE述第一客户端对应的发送窗口，包括：根据第一信令确认帧中的实际目的地址，确定是发送给本设备的组播帧，且根据第一信令确认帧中的实际源地址，确定第一控制信令帧的发送端是否属于组播组时，根据第一信令确认帧中的实际源地址获取第一客户端对应的发送窗口，组播源基于第一信令确认帧更新第一客户端对应的发送窗口。
在一些实施例中，上述组播源基于第一信令确认帧更新第一客户端对应的发送窗口，包括:基于第一信令确认帧中的确认信息，确定第一LE大于等于发送窗口的第二LE，且第一UE小于等于第二UE时，组播源基于第一信令确认帧更新第一客户端对应的发送窗口。
在一些实施例中，发送窗口中的一个小窗口维护的发送信息还包括发送状态和存储地址，发送状态用于指示控制信令帧是否已被接收，存储地址用于指示控制信令帧的缓存地址；上述组播源基于第一信令确认帧更新第一客户端对应的发送窗口，包括:第一LE大于第二LE时，清空发送窗口中第二LE指向的小窗口至第一LE指向的小窗口的前一个小窗口，并更新第二LE的取值为第一LE的取值；第一LE等于第二LE时，遍历发送窗口中第一LE指向的小窗口至第一UE指向的小窗口中，位图指示的控制信令帧已被接收的第二小窗口，释放第二小窗口的存储地址缓存的控制信令帧。
在一些实施例中，发送窗口的一个小窗口维护的发送信息还包括重传标识和重传次数，重传标识用于指示在本重传周期内是否被重传过，重传次数用于指示控制信令帧被重传的次数；上述确定是否重传第二控制信令帧，包括：第一LE等于第二LE时，遍历发送窗口中第一LE指向的小窗口至第一UE指向的小窗口中，位图指示的控制信令帧未被接收的第三小窗口，第三小窗口维护的第二控制信令帧满足重传条件式时，确定向第一客户端重传第二控制信令帧，更新第三小窗口对应的重传标识为第一值，重传次数加1；重传标识取值为第一值，指示控制信令帧在本重传周期内被重传过。
在一些实施例中，上述重传条件包括：第三小窗口的重传标识为第二值，重传次数小于第一预设值；重传标识取值为第二值，指示控制信令帧在本重传周期内未被重传过。示例性的，第一预设值包括前述MAX_RETRAN_CNT，例如第一预设值等于5。
在一些实施例中，上述方法还包括：第一客户端对其维护的组播源对应的接收窗口进行周期性地超时处理。
在一些实施例中，接收窗口的一个小窗口维护的接收信息还包括轮询次数，上述第一客户端对其维护的组播源对应的接收窗口进行周期性地超时处理，包括：确定接收窗口中第一LE指向的小窗口至第一UE指向的小窗口中，接收标识为第二值的第四小窗口，将第四小窗口的轮询次数加1；第四小窗口的轮询次数大于第二预设值时，清空第一LE指向的小窗口至第四小窗口；确定接收窗口中第四小窗口之后的第一个接收标识为第二值的第五小窗口；更新接收窗口的第一LE为第五小窗口的控制标识。
示例性的，第二预设值包括前述预设值1。
在一些实施例中，上述方法还包括：组播源对其维护的第一客户端对应的发送窗口进行周期性地超时处理。
在一些实施例中，上述组播源对其维护的第一客户端对应的发送窗口进行周期性地超时处理，包括：遍历发送窗口中第二LE指向的小窗口至第二UE指向的小窗口中，发送状态为第二值的第六小窗口；发送状态取值为第二值，指示控制信令帧未被接收；将第六小窗口对应的轮询次数加1；第六小窗口的轮询次数大于等于第三预设值时，确定第六小窗口是否满足重传条件；满足重传条件时，确定重传第六小窗口维护的控制信令帧，并将第六小窗口的轮询次数置为0，重传标识置为第一值，重传次数加1；不满足重传条件且重传次数超过第五预设值时，清空第六小窗口，并释放第六小窗口的存储地址缓存的控制信令帧；确定第二LE等于发送窗口中发送状态为第二值且控制标识最小的小窗口的控制标识。
示例性的，第三预设值包括前述预设值2。
在一些实施例中，还包括：第一客户端和组播源建立蓝牙连接，并向组播源发送第四蓝牙消息，第四蓝牙消息用于请求退出组播组；组播源向第一客户端发送第五蓝牙消息，并删除第一客户端的组播用户信息，第五蓝牙消息用于指示确认第一客户端退出组播组；第一客户端蓝牙监听到第五蓝牙消息，基于第五蓝牙消息删除客户端侧的第二组播组信息；第二组播组信息包括组播地址和第一组播密钥；第一客户端和组播源断开蓝牙连接。
示例性的，第四蓝牙消息包括前述断开请求消息，第五蓝牙消息包括前述断开确认消息，第二组播组信息包括前述客户端200侧的组播组信息。
在一些实施例中，上述第一客户端和组播源建立蓝牙连接，并向组播源发送第四蓝牙消息，包括：第一客户端接收第四操作；响应于第四操作，第一客户端和组播源建立蓝牙连接，并向组播源发送第四蓝牙消息；上述方法还包括：响应于第四操作，第一客户端关闭组播应用。
示例性的，第四操作包括前述操作5。参考图5A至图5B的相关描述，在投屏场景中，操作5可以用于退出投屏组播组，例如操作5包括作用于退出控件401的点击操作。
在一些实施例中，组播源蓝牙广播第六蓝牙消息，并删除组播源侧的第一组播组信息；第六蓝牙消息用于指示删除组播组，第一组播组信息包括组播设备列表、第一组播密钥和组播地址；第一客户端蓝牙监听到第六蓝牙消息，基于第六蓝牙消息删除客户端侧的第二组播组信息；第二组播组信息包括组播地址和第一组播密钥。
示例性的，第六蓝牙消息包括前述组播删除消息，第一组播组信息包括前述组播源100侧的组播组信息。
在一些实施例中，上述组播源蓝牙广播第六蓝牙消息，包括：组播源接收第五操作；响应于第五操作，组播源蓝牙广播第六蓝牙消息；上述方法还包括：响应于第五操作，关闭组播应用。
示例性的，第五操作包括前述操作6。参考图5A至图5B的相关描述，在投屏场景中，操作6可以用于删除投屏组播组，例如操作6包括作用于结束控件402的点击操作。
下面示例性地接收组播源100和客户端的硬件结构。
下面介绍本申请实施例提供的一种组播源100的结构。本申请实施例涉及的客户端的结构可以参考组播源100的相关描述，后续不再赘述。
图13示出了组播源100的结构示意图。组播源100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriberidentification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。
可以理解的是，本发明实施例示意的结构并不构成对组播源100的具体限定。在本申请另一些实施例中，组播源100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
处理器110中还可以设置存储器，用于存储指令和数据。
在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。
I2C接口是一种双向同步串行总线，包括一根串行数据线(serial data line，SDA)和一根串行时钟线(derail clock line，SCL)。在一些实施例中，处理器110可以包含多组I2C总线。处理器110可以通过不同的I2C总线接口分别耦合触摸传感器180K，充电器，闪光灯，摄像头193等。例如：处理器110可以通过I2C接口耦合触摸传感器180K，使处理器110与触摸传感器180K通过I2C总线接口通信，实现组播源100的触摸功能。
I2S接口可以用于音频通信。在一些实施例中，处理器110可以包含多组I2S总线。处理器110可以通过I2S总线与音频模块170耦合，实现处理器110与音频模块170之间的通信。在一些实施例中，音频模块170可以通过I2S接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。
PCM接口也可以用于音频通信，将模拟信号抽样，量化和编码。在一些实施例中，音频模块170与无线通信模块160可以通过PCM总线接口耦合。在一些实施例中，音频模块170也可以通过PCM接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。所述I2S接口和所述PCM接口都可以用于音频通信。
UART接口是一种通用串行数据总线，用于异步通信。该总线可以为双向通信总线。它将要传输的数据在串行通信与并行通信之间转换。在一些实施例中，UART接口通常被用于连接处理器110与无线通信模块160。例如：处理器110通过UART接口与无线通信模块160中的蓝牙模块通信，实现蓝牙功能。在一些实施例中，音频模块170可以通过UART接口向无线通信模块160传递音频信号，实现通过蓝牙耳机播放音乐的功能。
MIPI接口可以被用于连接处理器110与显示屏194，摄像头193等外围器件。MIPI接口包括摄像头串行接口(camera serial interface，CSI)，显示屏串行接口(displayserial interface，DSI)等。在一些实施例中，处理器110和摄像头193通过CSI接口通信，实现组播源100的拍摄功能。处理器110和显示屏194通过DSI接口通信，实现组播源100的显示功能。
GPIO接口可以通过软件配置。GPIO接口可以被配置为控制信号，也可被配置为数据信号。在一些实施例中，GPIO接口可以用于连接处理器110与摄像头193，显示屏194，无线通信模块160，音频模块170，传感器模块180等。GPIO接口还可以被配置为I2C接口，I2S接口，UART接口，MIPI接口等。
USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为组播源100充电，也可以用于组播源100与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他电子设备，例如AR设备等。
可以理解的是，本发明实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对组播源100的结构限定。在本申请另一些实施例中，组播源100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。
充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块140可以通过组播源100的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。
电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实施例中，电源管理模块141也可以设置于处理器110中。在另一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。
组播源100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。
天线1和天线2用于发射和接收电磁波信号。组播源100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。
移动通信模块150可以提供应用在组播源100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。
调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。
无线通信模块160可以提供应用在组播源100上的包括无线局域网(wirelesslocal area networks，WLAN)(如WiFi网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号解调以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。
在一些实施例中，组播源100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得组播源100可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(codedivision multiple access，CDMA)，宽带码分多址(wideband code division multipleaccess，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统(global positioning system，GPS)，全球导航卫星系统(global navigation satellite system，GLONASS)，北斗卫星导航系统(beidounavigation satellite system，BDS)，准天顶卫星系统(quasi-zenith satellitesystem，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。
组播源100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。
显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，组播源100可以包括1个或N个显示屏194，N为大于1的正整数。
组播源100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。
ISP用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头193中。
摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实施例中，组播源100可以包括1个或N个摄像头193，N为大于1的正整数。
数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当组播源100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。
视频编解码器用于对数字视频压缩或解压缩。组播源100可以支持一种或多种视频编解码器。这样，组播源100可以播放或录制多种编码格式的视频，例如：动态图像专家组(moving picture experts group，MPEG)1，MPEG2，MPEG3，MPEG4等。
NPU为神经网络(neural-network，NN)计算处理器，通过借鉴生物神经网络结构，例如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。通过NPU可以实现组播源100的智能认知等应用，例如：图像识别，人脸识别，语音识别，文本理解等。
内部存储器121可以包括一个或多个随机存取存储器(random access memory，RAM)和一个或多个非易失性存储器(non-volatile memory，NVM)。
随机存取存储器可以包括静态随机存储器(static random-access memory，SRAM)、动态随机存储器(dynamic random access memory，DRAM)、同步动态随机存储器(synchronous dynamic random access memory,SDRAM)、双倍资料率同步动态随机存取存储器(double data rate synchronous dynamic random access memory,DDR SDRAM，例如第五代DDR SDRAM一般称为DDR5 SDRAM)等；非易失性存储器可以包括磁盘存储器件、快闪存储器(flash memory)。
快闪存储器按照运作原理划分可以包括NOR FLASH、NAND FLASH、3D NAND FLASH等，按照存储单元电位阶数划分可以包括单阶存储单元(single-level cell,SLC)、多阶存储单元(multi-level cell,MLC)、三阶储存单元(triple-level cell,TLC)、四阶储存单元(quad-level cell,QLC)等，按照存储规范划分可以包括通用闪存存储(英文：universalflash storage，UFS)、嵌入式多媒体存储卡(embedded multi media Card，eMMC)等。
随机存取存储器可以由处理器110直接进行读写，可以用于存储操作系统或其他正在运行中的程序的可执行程序(例如机器指令)，还可以用于存储用户及应用程序的数据等。
非易失性存储器也可以存储可执行程序和存储用户及应用程序的数据等，可以提前加载到随机存取存储器中，用于处理器110直接进行读写。
外部存储器接口120可以用于连接外部的非易失性存储器，实现扩展组播源100的存储能力。外部的非易失性存储器通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部的非易失性存储器中。
组播源100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。
音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。
扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。
受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。
麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。
耳机接口170D用于连接有线耳机。
压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。压力传感器180A的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。
陀螺仪传感器180B可以用于确定组播源100的运动姿态。在一些实施例中，可以通过陀螺仪传感器180B确定组播源100围绕三个轴(即，x，y和z轴)的角速度。
气压传感器180C用于测量气压。
磁传感器180D包括霍尔传感器。
加速度传感器180E可检测组播源100在各个方向上(一般为三轴)加速度的大小。当组播源100静止时可检测出重力的大小及方向。还可以用于识别终端设备的姿态。
距离传感器180F，用于测量距离。组播源100可以通过红外或激光测量距离。
接近光传感器180G可以包括例如发光二极管(LED)和光检测器，例如光电二极管。发光二极管可以是红外发光二极管。
环境光传感器180L用于感知环境光亮度。组播源100可以根据感知的环境光亮度自适应调节显示屏194亮度。
指纹传感器180H用于采集指纹。
温度传感器180J用于检测温度。在一些实施例中，组播源100利用温度传感器180J检测的温度，执行温度处理策略。
触摸传感器180K，也称“触控器件”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于组播源100的表面，与显示屏194所处的位置不同。
骨传导传感器180M可以获取振动信号。
按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。组播源100可以接收按键输入，产生与组播源100的用户设置以及功能控制有关的键信号输入。
马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。
指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。
SIM卡接口195用于连接SIM卡。
本申请的各实施方式可以任意进行组合，以实现不同的技术效果。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solidstate disk，SSD))等。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。
总之，以上所述仅为本发明技术方案的实施例而已，并非用于限定本发明的保护范围。凡根据本发明的揭露，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (38)

1.一种组播通信方法，其特征在于，应用于组播通信系统，所述组播通信系统包括组播源和至少一个客户端，所述至少一个客户端包括第一客户端；所述方法包括：
所述组播源确定组播组的组播地址和第一组播密钥；
所述组播源向所述第一客户端发送第一蓝牙消息，所述第一蓝牙消息用于邀请所述第一客户端加入所述组播组，所述第一蓝牙消息包括所述组播地址和所述第一组播密钥；
所述第一客户端基于所述第一蓝牙消息，向所述组播源发送第二蓝牙消息；所述第二蓝牙消息用于指示所述第一客户端确认加入所述组播组；
所述第一客户端配置所述第一组播密钥对应的源地址为所述组播源的媒体存取控制MAC地址；
所述组播源通过WiFi通信技术组播发送经所述第一组播密钥加密的第一组播报文，所述第一组播报文的第一MAC头中的源地址为所述组播源的MAC地址，所述第一MAC头中的目的地址为所述组播地址；
基于所述组播地址，所述第一客户端监听到所述第一组播报文；
所述第一客户端确定所述第一MAC头中的源地址对应的密钥为所述第一组播密钥，并利用所述第一组播密钥解析所述第一组播报文的数据单元。
2.根据权利要求1所述的方法，其特征在于，所述组播源向所述第一客户端发送第一蓝牙消息之前，所述方法还包括：
所述组播源开启第一虚拟接入点VAP；
所述组播源通过WiFi通信技术组播发送经所述第一组播密钥加密的第一组播报文，包括：
所述组播源的第一VAP通过WiFi通信技术组播发送经所述第一组播密钥加密的第一组播报文。
3.根据权利要求1所述的方法，其特征在于，所述方法还包括：
所述组播源接收第一操作，所述第一操作用于创建所述组播组；
所述组播源确定组播组的组播地址和第一组播密钥，包括：
响应于所述第一操作，所述组播源确定所述组播组的所述组播地址和所述第一组播密钥。
4.根据权利要求1所述的方法，其特征在于，所述组播源向所述第一客户端发送第一蓝牙消息之前，所述方法还包括：
所述组播源蓝牙扫描附近支持组播通信的蓝牙设备；
所述组播源显示扫描到的至少一个蓝牙设备，所述至少一个蓝牙设备包括所述第一客户端；
所述组播源接收第二操作，所述第二操作用于邀请第一客户端加入组播组；
响应于所述第二操作，所述组播源与所述第一客户端建立蓝牙连接。
5.根据权利要求4所述的方法，其特征在于，所述组播源显示扫描到的至少一个蓝牙设备之前，所述方法还包括：
所述第一客户端接收第三操作；
响应于所述第三操作，所述第一客户端蓝牙广播第一发现信号，所述第一发现信号指示所述第一客户端支持组播通信；
所述组播源基于所述第一发现信号扫描到所述第一客户端。
6.根据权利要求3所述的方法，其特征在于，所述组播源向所述第一客户端发送所述第一蓝牙消息之前，所述方法还包括：
响应于所述第一操作，所述组播源蓝牙广播第二发现信号；
基于蓝牙监听到的所述第二发现信号，所述第一客户端与所述组播源建立蓝牙连接；
所述第一客户端向所述组播源发送第三蓝牙消息，所述第三蓝牙消息用于请求加入所述组播组；
所述组播源向所述第一客户端发送第一蓝牙消息，包括：
响应于所述第三蓝牙消息，所述组播源向所述第一客户端发送所述第一蓝牙消息。
7.根据权利要求1所述的方法，其特征在于，所述第一客户端向所述组播源发送第二蓝牙消息之后，还包括：
断开所述组播源与所述第一客户端的蓝牙连接。
8.根据权利要求2所述的方法，其特征在于，所述组播源向所述第一客户端发送第一蓝牙消息之前，还包括：
所述组播源为所述组播源的所述第一VAP分配第一IP地址，为所述客户端的所述第二VAP分配第二IP地址；
所述第一蓝牙消息还包括所述第一IP地址和所述第二IP地址；所述第一IP地址和所述第二IP地址用于封装组播报文，所述组播源发送的组播报文中的源IP地址为第一IP地址，第一客户端发送的组播报文中的源IP地址为第二IP地址。
9.根据权利要求8所述的方法，其特征在于，所述方法还包括：
基于所述第二蓝牙消息，所述第一组播源在组播设备列表中添加所述第一客户端的组播用户信息；所述组播设备列表用于存储所述组播组中的各客户端的组播用户信息，所述第一客户端的组播用户信息包括所述第一客户端的MAC地址和所述第二IP地址。
10.根据权利要求1所述的方法，其特征在于，所述组播源向所述第一客户端发送第一蓝牙消息之前，还包括：
所述组播源生成虚拟组播源地址；
所述组播源配置所述第一组播密钥对应的源地址为所述虚拟组播源地址；
所述第一蓝牙消息还包括所述虚拟主播源地址，所述组播组中的客户端发送的组播报文的MAC头中的源地址为所述虚拟组播源地址。
11.根据权利要求10所述的方法，其特征在于，所述方法还包括：
所述第一客户端通过WiFi通信技术组播发送经所述第一组播密钥加密的第二组播报文，所述第二组播报文的第二MAC头中的源地址为所述虚拟组播源地址，所述第二MAC头中的目的地址为所述组播地址；
基于所述组播地址，所述组播源监听到所述第二组播报文；
所述组播源确定所述第二MAC头中的源地址对应的密钥为所述第一组播密钥，并利用所述第一组播密钥解析所述第二组播报文的数据单元。
12.根据权利要求11所述的方法，其特征在于，所述组播源向所述第一客户端发送第一蓝牙消息之后，还包括：
所述第一客户端基于所述第一蓝牙消息开启第二VAP；
所述第一客户端通过WiFi通信技术组播发送经所述第一组播密钥加密的第二组播报文，包括：
所述第一客户端的第二VAP通过WiFi通信技术组播发送经所述第一组播密钥加密的第二组播报文。
13.根据权利要求1所述的方法，其特征在于，组播报文的数据单元为MAC服务数据单元MSDU。
14.根据权利要求11所述的方法，其特征在于，组播报文的类型包括信令帧和数据帧，信令帧的组播类型包括控制信令帧和信令确认帧；
所述第一组播报文包括第一控制信令帧，所述第二组播报文包括第一信令确认帧，所述第一信令确认帧是所述第一客户端基于所述第一控制信令帧生成的，所述第一信令确认帧用于指示所述组播源发送的控制信令帧的接收情况。
15.根据权利要求11所述的方法，其特征在于，组播报文的类型包括信令帧和数据帧，信令帧的组播类型包括控制信令帧和信令确认帧；
所述第二组播报文包括第一控制信令帧，所述第一组播报文包括第一信令确认帧，所述第一信令确认帧是所述组播源基于所述第一控制信令帧生成的，所述第一信令确认帧用于指示所述第一客户端发送的控制信令帧的接收情况。
16.根据权利要求14或15所述的方法，其特征在于，所述信令帧中的数据单元包括所述信令帧的接收端对应的实际目的地址和所述信令帧的发送端对应的实际源地址；
所述控制信令帧的数据单元还包括控制标识和数据载荷，所述数据载荷用于传输有效的控制信令，所述控制标识用于指示控制信令帧的编号；
所述信令确认帧的数据单元还包括确认信息，所述确认信息用于指示所述信令确认帧的接收端已发送的控制信令帧的接收情况。
17.根据权利要求16所述的方法，其特征在于，第一客户端为组播源设置了一个接收窗口，用于维护来自组播源的控制信令帧的接收信息；组播源为第一客户端设置一个发送窗口，用于维护发送给所述第一客户端的控制信令帧的发送信息；所述方法还包括；
所述第一客户端基于所述第一控制信令帧更新所述组播源对应的接收窗口，并基于更新后的接收窗口确定所述第一信令确认帧；所述第一信令确认帧指示所述发送窗口维护的第二控制信令帧未被接收；
所述组播源基于所述第一信令确认帧更新所述第一客户端对应的发送窗口，确定是否重传所述第二控制信令帧。
18.根据权利要求16或17所述的方法，其特征在于，所述信令帧还包括组播类型；所述信令帧的组播类型为控制信令帧时，所述信令帧还包括控制信令帧的子类型，所述控制信令帧的子类型包括第一子类型和第二子类型，所述第一子类型和所述第二子类型对应的处理模块不同；所述方法还包括：
所述第一客户端根据所述第一控制信令帧中的所述第一子类型，将所述第一控制信令帧提交给所述第一子类型对应的处理模块进行处理。
19.根据权利要求17所述的方法，其特征在于，所述接收窗口包括M个小窗口，所述M为正整数；所述接收窗口中的小窗口，按照接收到的所述组播源的控制信令帧的控制标识，依序维护控制信令帧的接收信息；所述接收窗口中的一个小窗口维护的接收信息包括控制信令帧的控制标识和接收标识；所述接收标识用于指示控制信令帧是否已接收；所述接收窗口的第一上沿UE指所述接收窗口维护的已接收的控制信令帧的控制标识的最大值，所述接收窗口的第一下沿LE指所述接收窗口维护的未接收的控制信令帧的控制标识的最小值；
所述发送窗口包M个小窗口；所述发送窗口中的小窗口，按照向第一客户端发送的控制信令帧的控制标识，依序维护控制信令帧的发送信息；一个小窗口维护的发送信息包括控制信令帧的控制标识；所述发送窗口的第二UE指所述发送窗口维护的未被接收的控制信令帧的控制标识的最大值，所述发送窗口的第二LE指所述发送窗口维护的未接收的控制信令帧的控制标识的最小值。
20.根据权利要求19所述的方法，其特征在于，所述第一信令确认帧中的确认信息包括所述接收窗口的第一UE和第一LE，以及位图，所述位图依序指示了所述接收窗口中第一LE指向的小窗口至第一UE指向的小窗口维护的控制信令帧的接收情况。
21.根据权利要求16所述的方法，其特征在于，所述第一客户端基于所述第一控制信令帧更新所述组播源对应的接收窗口，包括：
根据所述第一控制信令帧中的实际目的地址，确定是发送给本设备的组播帧，且根据所述第一控制信令帧中的实际源地址，确定所述第一控制信令帧的发送端属于所述组播组时，基于所述第一控制信令帧中的实际源地址获取所述组播源对应的接收窗口，所述第一客户端基于所述第一控制信令帧更新所述组播源对应的接收窗口。
22.根据权利要求19所述的方法，其特征在于，所述第一客户端基于所述第一控制信令帧更新所述组播源对应的接收窗口，包括：
根据所述第一控制信令帧的控制标识，确定用于维护所述第一控制信令帧的小窗口的第一索引，所述第一索引等于所述第一控制信令帧的控制标识除以所述M后的余数；
根据所述第一LE和所述第一UE确定所述接收窗口已满时，将所述第一LE指向的小窗口至所述第一索引对应的小窗口清空；确定所述接收窗口未满时，若所述第一索引对应的小窗口的接收标识取值为所述第一值，丢弃所述第一控制信令帧，若所述第一索引对应的小窗口的接收标识取值为所述第二值，则将所述第一索引对应的小窗口的接收标识的取值更新为所述第一值；所述接收标识取值为第一值，指示控制信令帧已被接收；所述接收标识取值为第二值，指示控制信令帧未被接收；
所述第一控制信令帧的控制标识大于所述第一UE时，将所述第一UE的取值更新为所述第一控制信令帧的控制标识；
确定所述第一LE指向的小窗口及其之后的小窗口中第一个接收标识为所述第二值的第一小窗口，并将所述第一LE的取值更新为所述第一小窗口的控制标识。
23.根据权利要求16所述的方法，其特征在于，所述组播源基于所述第一信令确认帧更新所UE述第一客户端对应的发送窗口，包括：
根据所述第一信令确认帧中的实际目的地址，确定是发送给本设备的组播帧，且根据所述第一信令确认帧中的实际源地址，确定第一控制信令帧的发送端是否属于所述组播组时，根据所述第一信令确认帧中的实际源地址获取所述第一客户端对应的发送窗口，所述组播源基于所述第一信令确认帧更新所述第一客户端对应的发送窗口。
24.根据权利要求20所述的方法，其特征在于，所述组播源基于所述第一信令确认帧更新所述第一客户端对应的发送窗口，包括:
基于所述第一信令确认帧中的所述确认信息，确定所述第一LE大于等于所述发送窗口的所述第二LE，且所述第一UE小于等于所述第二UE时，所述组播源基于所述第一信令确认帧更新所述第一客户端对应的发送窗口。
25.根据权利要求24所述的方法，其特征在于，所述发送窗口中的一个小窗口维护的发送信息还包括发送状态和存储地址，所述发送状态用于指示控制信令帧是否已被接收，所述存储地址用于指示控制信令帧的缓存地址；
所述组播源基于所述第一信令确认帧更新所述第一客户端对应的发送窗口，包括:
所述第一LE大于所述第二LE时，清空所述发送窗口中所述第二LE指向的小窗口至所述第一LE指向的小窗口的前一个小窗口，并更新所述第二LE的取值为所述第一LE的取值；
所述第一LE等于所述第二LE时，遍历所述发送窗口中所述第一LE指向的小窗口至所述第一UE指向的小窗口中，所述位图指示的控制信令帧已被接收的第二小窗口，释放所述第二小窗口的存储地址缓存的控制信令帧。
26.根据权利要求25所述的方法，其特征在于，所述发送窗口的一个小窗口维护的发送信息还包括重传标识和重传次数，重传标识用于指示在本重传周期内是否被重传过，重传次数用于指示控制信令帧被重传的次数；
所述确定是否重传所述第二控制信令帧，包括：
所述第一LE等于所述第二LE时，遍历所述发送窗口中所述第一LE指向的小窗口至所述第一UE指向的小窗口中，所述位图指示的控制信令帧未被接收的第三小窗口，
所述第三小窗口维护的所述第二控制信令帧满足重传条件式时，确定向所述第一客户端重传所述第二控制信令帧，更新所述第三小窗口对应的重传标识为第一值，重传次数加1；重传标识取值为第一值，指示控制信令帧在本重传周期内被重传过。
27.根据权利要求26所述的方法，其特征在于，所述重传条件包括：
所述第三小窗口的重传标识为第二值，重传次数小于第一预设值；重传标识取值为第二值，指示控制信令帧在本重传周期内未被重传过。
28.根据权利要求19所述的方法，其特征在于，所述方法还包括：
所述第一客户端对其维护的所述组播源对应的接收窗口进行周期性地超时处理。
29.根据权利要求28所述的方法，其特征在于，所述接收窗口的一个小窗口维护的接收信息还包括轮询次数，所述第一客户端对其维护的所述组播源对应的接收窗口进行周期性地超时处理，包括：
确定所述接收窗口中所述第一LE指向的小窗口至所述第一UE指向的小窗口中，所述接收标识为所述第二值的第四小窗口，
将所述第四小窗口的轮询次数加1；
所述第四小窗口的轮询次数大于第二预设值时，清空所述第一LE指向的小窗口至所述第四小窗口；
确定所述接收窗口中所述第四小窗口之后的第一个接收标识为第二值的第五小窗口；更新所述接收窗口的所述第一LE为所述第五小窗口的控制标识。
30.根据权利要求19所述的方法，其特征在于，所述方法还包括：
所述组播源对其维护的第一客户端对应的发送窗口进行周期性地超时处理。
31.根据权利要求30所述的方法，其特征在于，所述组播源对其维护的第一客户端对应的发送窗口进行周期性地超时处理，包括：
遍历所述发送窗口中所述第二LE指向的小窗口至所述第二UE指向的小窗口中，所述发送状态为第二值的第六小窗口；所述发送状态取值为第二值，指示控制信令帧未被接收；
将所述第六小窗口对应的轮询次数加1；
所述第六小窗口的轮询次数大于等于第三预设值时，确定所述第六小窗口是否满足重传条件；
满足重传条件时，确定重传所述第六小窗口维护的控制信令帧，并将所述第六小窗口的所述轮询次数置为0，所述重传标识置为第一值，所述重传次数加1；
不满足重传条件且所述重传次数超过第五预设值时，清空所述第六小窗口，并释放所述第六小窗口的存储地址缓存的控制信令帧；
确定所述第二LE等于所述发送窗口中发送状态为第二值且控制标识最小的小窗口的控制标识。
32.根据权利要求9所述的方法，其特征在于，还包括：
所述第一客户端和所述组播源建立蓝牙连接，并向所述组播源发送第四蓝牙消息，第四蓝牙消息用于请求退出组播组；
所述组播源向所述第一客户端发送第五蓝牙消息，并删除所述第一客户端的组播用户信息，所述第五蓝牙消息用于指示确认所述第一客户端退出组播组；
所述第一客户端蓝牙监听到所述第五蓝牙消息，基于所述第五蓝牙消息删除客户端侧的第二组播组信息；所述第二组播组信息包括所述组播地址和所述第一组播密钥；
所述第一客户端和所述组播源断开蓝牙连接。
33.根据权利要求32所述的方法，其特征在于，所述第一客户端和所述组播源建立蓝牙连接，并向所述组播源发送第四蓝牙消息，包括：
所述第一客户端接收第四操作；
响应于所述第四操作，所述第一客户端和所述组播源建立蓝牙连接，并向所述组播源发送第四蓝牙消息；
所述方法还包括：
响应于所述第四操作，所述第一客户端关闭组播应用。
34.根据权利要求9所述的方法，其特征在于，还包括：
所述组播源蓝牙广播第六蓝牙消息，并删除所述组播源侧的第一组播组信息；第六蓝牙消息用于指示删除所述组播组，所述第一组播组信息包括所述组播设备列表、所述第一组播密钥和所述组播地址；
所述第一客户端蓝牙监听到所述第六蓝牙消息，基于所述第六蓝牙消息删除客户端侧的第二组播组信息；所述第二组播组信息包括所述组播地址和所述第一组播密钥。
35.根据权利要求34所述的方法，其特征在于，所述组播源蓝牙广播第六蓝牙消息，包括：
所述组播源接收第五操作；
响应于所述第五操作，所述组播源蓝牙广播第六蓝牙消息；
所述方法还包括：响应于所述第五操作，关闭组播应用。
36.一种组播通信系统，其特征在于，包括组播源和至少一个客户端，所述至少一个客户端包括第一客户端；
所述组播源用于执行如权利要求1-35任一项所述的方法中所述组播源执行的步骤，所述组第一客户端执行如权利要求1-35任一项所述的方法中所述第一客户端执行的步骤。
37.一种通信装置，其特征在于，包括存储器和处理器，所述存储器和所述处理器电偶合，所述存储器用于存储程序指令，所述处理器被配置用于调用所述存储器存储的全部或部分程序指令，执行如权利要求1-35任一项所述的方法中所述组播源执行的步骤。
38.一种通信装置，其特征在于，包括存储器和处理器，所述存储器和所述处理器电偶合，所述存储器用于存储程序指令，所述处理器被配置用于调用所述存储器存储的全部或部分程序指令，执行如权利要求1-35任一项所述的方法中所述第一客户端执行的步骤。
CN202211304468.0A 2022-10-24 2022-10-24 组播通信方法及相关装置 Pending CN117939406A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202211304468.0A CN117939406A (zh) 2022-10-24 2022-10-24 组播通信方法及相关装置
PCT/CN2023/125653 WO2024088173A1 (zh) 2022-10-24 2023-10-20 组播通信方法及相关装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211304468.0A CN117939406A (zh) 2022-10-24 2022-10-24 组播通信方法及相关装置

Publications (1)

Publication Number Publication Date
CN117939406A true CN117939406A (zh) 2024-04-26

Family

ID=90751205

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211304468.0A Pending CN117939406A (zh) 2022-10-24 2022-10-24 组播通信方法及相关装置

Country Status (2)

Country Link
CN (1) CN117939406A (zh)
WO (1) WO2024088173A1 (zh)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101145900A (zh) * 2006-09-15 2008-03-19 华为技术有限公司 组播方法和组播系统以及组播设备
CN1929638A (zh) * 2006-10-20 2007-03-14 中兴通讯股份有限公司 一种无线局域网ip组播帧传输的组播成员管理方法
US8588417B2 (en) * 2007-05-04 2013-11-19 Conexant Systems, Inc. Systems and methods for multicast retransmission over a secure wireless LAN
CN101702672A (zh) * 2009-11-04 2010-05-05 华为技术有限公司 组播数据报文转发方法和转发装置
CN109842854B (zh) * 2017-11-29 2021-01-05 华为技术有限公司 一种报文组播、报文广播方法及设备
CN109067578B (zh) * 2018-07-31 2021-05-25 杭州迪普科技股份有限公司 一种组播快速切换的方法和装置

Also Published As

Publication number Publication date
WO2024088173A1 (zh) 2024-05-02

Similar Documents

Publication Publication Date Title
US10693969B2 (en) Electronic device using logical channels for communication
WO2019196690A1 (zh) 旁链路的传输方法和终端
WO2021218864A1 (zh) 一种Wi-Fi点对点业务的实现方法以及相关设备
WO2021175214A1 (zh) 一种投屏连接控制方法及电子设备
EP4213512A1 (en) Screen projection method and system, and electronic device
CN114554000B (zh) 摄像头调用方法、系统、电子设备及存储介质
JP7181990B2 (ja) データ伝送方法及び電子デバイス
WO2022179405A1 (zh) 一种投屏显示方法及电子设备
WO2022068513A1 (zh) 无线通信方法和终端设备
JP2019533958A (ja) プロトコル・データ・ユニット（ｐｄｕ）パケットを生成するための方法およびデバイス
WO2021179990A1 (zh) 一种应用服务器的访问方法及终端
EP4199562A1 (en) Method for transmitting data and electronic device
WO2021007823A1 (zh) 信息指示、确定方法及装置、通信设备及存储介质
EP4283931A1 (en) Nfc method and system, and electronic device
CN111315038B (zh) 数据传输方法、装置、电子设备及存储介质
WO2021244456A1 (zh) 反向地址解析方法及电子设备
WO2022213333A1 (zh) 物理直连链路反馈方法、装置及存储介质
WO2024088173A1 (zh) 组播通信方法及相关装置
WO2022222773A1 (zh) 拍摄方法、相关装置及系统
WO2023050362A1 (zh) 下行传输配置、接收方法及装置、通信设备及存储介质
WO2023202533A1 (zh) 通信方法、电子设备以及系统
WO2023039890A1 (zh) 视频传输的方法和电子设备
WO2022188813A1 (zh) 蓝牙通信方法、系统及电子设备
EP4283464A1 (en) Distributed device capability virtualization method, medium, and electronic device
WO2023273464A1 (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