WiFi P2P connection method and device

Abstract

The embodiment of the invention provides a WiFi (Wireless Fidelity) P2P (Peer-to-Peer) connection method and device, relates to the field of communication, and can avoid the compatibility problem. The method is applied to a first electronic device, and comprises the following steps: the first electronic device obtains a version of a P2P transmission protocol of a second electronic device; under the condition that the version of the P2P transmission protocol is a first version, the first electronic equipment encapsulates a first data packet according to a first data processing protocol, and sends the first data packet to second electronic equipment; the first data packet is used for requesting to establish WiFi P2P connection with the second electronic equipment; under the condition that the version of the P2P transmission protocol is a second version, the first electronic equipment encapsulates a second data packet according to a second data processing protocol, and sends the second data packet to second electronic equipment; the second data packet is used for requesting to establish WiFi P2P connection with the second electronic equipment; the second data processing protocol is different from the first data processing protocol.

Description

Technical Field

[0001] This application relates to the field of communications, and more particularly to a WiFi P2P connection method and apparatus. Background Technology

[0002] To better serve users, various electronic devices can exchange data (information), enabling functions such as file sharing, multi-screen collaboration, and screen mirroring. Electronic devices can use WiFi Direct (also known as peer-to-peer, P2P) technology for data transmission. Compared to Bluetooth communication, WiFi P2P offers a longer communication distance and greater bandwidth, providing significant advantages.

[0003] Currently, most electronic devices only support establishing one WiFi P2P connection. To support establishing multiple WiFi P2P connections, the electronic device needs to be upgraded. However, there may be compatibility issues between upgraded electronic devices (newer versions) and older electronic devices (older versions), which may cause WiFi P2P connection establishment to fail. Summary of the Invention

[0004] This application provides a WiFi P2P connection method and apparatus that can avoid compatibility issues and improve the communication quality of WiFi P2P.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, a WiFi P2P connection method is provided, applied to a first electronic device. The method includes: the first electronic device obtaining the version of the peer-to-peer (P2P) transmission protocol of a second electronic device; if the P2P transmission protocol version is a first version, the first electronic device encapsulates a first data packet using a first data processing protocol and sends the first data packet to the second electronic device; the first data packet is used to request the establishment of a WiFi P2P connection with the second electronic device; if the P2P transmission protocol version is a second version, the first electronic device encapsulates a second data packet using a second data processing protocol and sends the second data packet to the second electronic device; the second data packet is used to request the establishment of a WiFi P2P connection with the second electronic device; the second data processing protocol is different from the first data processing protocol.

[0007] Based on the method provided in the embodiments of this application, the first electronic device can encapsulate different data packets with different data processing protocols based on the version (first version or second version) of the P2P transmission protocol (e.g., MagicLink protocol) of the peer device (second electronic device). Different versions of the device can identify data packets encapsulated by different data processing protocols respectively. In this way, the local device (first electronic device) can be compatible with different versions of the device, and compatibility problems can be avoided.

[0008] In one possible implementation, the first data packet includes WiFi capability information of the first electronic device, which includes information about the first WiFi network card; the second data packet also includes WiFi capability information of the first electronic device, which includes information about the first and second WiFi network cards. Thus, when the second electronic device is an older version device (i.e., the P2P transmission protocol version of the second electronic device is version 1), the first electronic device only sends information about one idle WiFi network card (the first WiFi network card) to the second electronic device. In other words, the first electronic device can disguise itself as an older protocol device with only a single WiFi network card (i.e., a device with the P2P transmission protocol version 1), allowing the older version device to function normally and avoiding compatibility issues. When the second electronic device is a newer version device (i.e., the P2P transmission protocol version of the second electronic device is version 2), the first electronic device can send information about multiple idle WiFi network cards to the peer device. This allows the peer device to make decisions about WiFi P2P connection configuration information (determining the optimal network card and channel) based on the information about multiple idle WiFi network cards, thereby improving the communication quality of WiFi P2P.

[0009] In one possible implementation, the first electronic device includes a first module (e.g., a MagicLink application module) and a second module (e.g., a WiFi link module). The first electronic device obtaining the version of the peer-to-peer (P2P) transmission protocol of the second electronic device includes: the first module receiving the P2P transmission protocol version of the second electronic device; the first module sending the P2P transmission protocol version of the second electronic device to the second module; the first electronic device encapsulating a first data packet with a first data processing protocol includes: the second module encapsulating the first data packet with the first data processing protocol; the first electronic device encapsulating a second data packet with a second data processing protocol includes: the second module encapsulating the second data packet with the second data processing protocol. Thus, the second module (WiFi link module) uniformly encapsulates the data packets (first data packet or second data packet) used to request the establishment of a WiFi P2P connection with a new or old version device. This means that the second module uniformly manages the WiFi P2P connections between the device and both the new and old versions, avoiding potential conflicts that might occur if different modules manage the WiFi P2P connections separately. Furthermore, the second module can encapsulate different data packets with different data processing protocols based on the P2P transmission protocol version of the peer device, thus avoiding compatibility issues.

[0010] In one possible implementation, when the P2P transmission protocol version is first, before the first electronic device encapsulates the first data packet using the first data processing protocol, the method further includes: the first module establishing a first communication channel with the second electronic device; the first communication channel being used to transmit information between the first module and the second electronic device; the first module registering a second communication channel with the second module; the first module sending the version of the P2P transmission protocol to the second module; and sending the first data packet to the second electronic device including: the second module calling the second communication channel to send the first data packet to the first module; and the first module sending the first data packet to the second electronic device through the first communication channel.

[0011] In one possible implementation, the data processing format for both the first and second communication channels is key-value pair format. Key-value pair format data packets are easy to parse.

[0012] In one possible implementation, when the P2P transmission protocol is version 2, before the first electronic device encapsulates the second data packet using the second data processing protocol, the method further includes: the first module establishing a third communication channel with the second electronic device; the third communication channel being used to transmit information between the second module and the second electronic device; the first module registering the third communication channel with the second module; sending the second data packet to the second electronic device includes: the second module calling the third communication channel to send the second data packet to the first module; and the first module sending the second data packet to the second electronic device through the third communication channel.

[0013] In one possible implementation, the data packets transmitted in the third communication channel are in TLV format; where T in TLV indicates the type of receiving module corresponding to the data packet; V in TLV represents the actual value carried in the data packet; and L in TLV represents the length of the actual value. Using the TLV protocol to send data eliminates the need for redundant or invalid payloads (e.g., key fields), resulting in better transmission efficiency and scalability.

[0014] In one possible implementation, the method further includes: a first module receiving a third data packet from a second electronic device; the third data packet including WiFi P2P connection configuration information; the WiFi P2P connection configuration information indicating the network interface card (NIC) for WiFi P2P connection and the device acting as the administrator (GO); the first module sending the third data packet to a second module; and the second module parsing the third data packet to obtain the WiFi P2P connection configuration information. Thus, the first electronic device can establish a WiFi P2P connection with the second electronic device based on the WiFi P2P connection configuration information.

[0015] In one possible implementation, the method further includes: a first module receiving a third data packet from a second electronic device; the third data packet including WiFi capability information of the second electronic device; the first module sending the third data packet to a second module; the second module parsing the third data packet to obtain the WiFi capability information of the second electronic device; the second module determining WiFi P2P connection configuration information based on the WiFi capability information of the second and first electronic devices; the WiFi P2P connection configuration information is used to indicate the network card for WiFi P2P connection and the device acting as the manager (GO). Thus, the first electronic device can establish a WiFi P2P connection with the second electronic device based on the WiFi P2P connection configuration information.

[0016] In one possible implementation, the method further includes: a second module sending the Internet Protocol (IP) address and network interface card (NIC) name of the first electronic device to the first module; the first module listening to the Transmission Control Protocol (TCP) port; the first module sending the TCP port information to the second module; the second module encapsulating a fourth data packet, the fourth data packet including the IP address, TCP port, and connection information of the first electronic device as a GO device; the second module invoking a second communication channel to send the fourth data packet to the first module; and the first module sending the fourth data packet to the second electronic device through the first communication channel. This allows the second electronic device to establish a WiFi P2P connection with the first electronic device based on the information carried in the fourth data packet, and then to perform data interaction with the second electronic device based on the WiFi P2P connection.

[0017] In one possible implementation, the method further includes: a second module establishing a WiFi P2P connection with a second electronic device based on the connection information of the device acting as the GO. In this way, the first electronic device can interact with the second electronic device via the WiFi P2P connection.

[0018] In one possible implementation, the method further includes: the first module creating a secure TCP channel based on a WiFi P2P connection to the second electronic device using the IP and TCP ports of the first electronic device. This can further improve communication security.

[0019] Secondly, this application provides a chip system including one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The aforementioned chip system can be applied to electronic devices including communication modules and memory. The interface circuits are used to receive signals from the memory of the electronic device and send the received signals to the processor, the signals including computer instructions stored in the memory. When the processor executes the computer instructions, the electronic device can perform the methods described in the first aspect and any of its possible design embodiments.

[0020] Thirdly, this application provides a computer-readable storage medium including computer instructions. When the computer instructions are executed on an electronic device (such as a mobile phone), they cause the electronic device to perform the methods described in the first aspect and any of its possible design embodiments.

[0021] Fourthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the method described in the first aspect and any possible design thereof.

[0022] Fifthly, embodiments of this application provide a communication device including a processor and a memory coupled together. The memory stores program instructions, which, when executed by the processor, cause the device to implement the method described in the first aspect and any possible design of the above. The device may be a first electronic device; or it may be a component of a first electronic device, such as a chip.

[0023] In a sixth aspect, embodiments of this application provide a communication device that can be divided into different logical units or modules according to their functions, with each unit or module performing different functions, so that the device can perform the method described in the first aspect and any of its possible design methods.

[0024] It is understood that the beneficial effects achieved by the chip system described in the second aspect, the computer-readable storage medium described in the third aspect, the computer program product described in the fourth aspect, and the apparatus described in the fifth and sixth aspects can be referred to the beneficial effects in the first aspect and any of its possible design embodiments, which will not be repeated here. Attached Figure Description

[0025] Figure 1 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application;

[0026] Figure 2A A schematic diagram of the software architecture of an electronic device provided in an embodiment of this application;

[0027] Figure 2B A schematic diagram of the software architecture of another electronic device provided in an embodiment of this application;

[0028] Figure 3A A flowchart is provided for an embodiment of this application;

[0029] Figure 3B A schematic diagram of signal interaction provided in an embodiment of this application;

[0030] Figure 4A This application provides a schematic diagram illustrating the establishment of a WiFi P2P connection.

[0031] Figure 4B This is a schematic diagram illustrating another method for establishing a WiFi P2P connection, as provided in an embodiment of this application.

[0032] Figure 5A A schematic diagram provided for an embodiment of this application;

[0033] Figure 5B This is yet another display schematic diagram provided for an embodiment of this application;

[0034] Figure 6 A schematic diagram of a negotiation channel and an auxiliary channel provided for embodiments of this application;

[0035] Figure 7A This is a schematic diagram illustrating another method for establishing a WiFi P2P connection, as provided in an embodiment of this application.

[0036] Figure 7B This is a schematic diagram illustrating another method for establishing a WiFi P2P connection, as provided in an embodiment of this application.

[0037] Figure 7C A schematic diagram of channel 1 and channel 3 provided for an embodiment of this application;

[0038] Figure 8AThis is a schematic diagram illustrating another method for establishing a WiFi P2P connection, as provided in an embodiment of this application.

[0039] Figure 8B This is a schematic diagram illustrating another method for establishing a WiFi P2P connection, as provided in an embodiment of this application.

[0040] Figure 9 This is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0041] To ensure clarity and conciseness in the description of the following embodiments, a brief introduction to the relevant concepts or technologies is given first:

[0042] WiFi P2P is a peer-to-peer connection technology that allows direct TCP / IP connections between any two devices (e.g., STAs) without the need for an access point (AP). One device acts as an access point (AP) and can be called the group owner (GO), while the other device is called a group client (GC). GCs can connect to the GO. In a P2P group, there is one GO and one or more GCs. Each GC can connect to a GO, meaning a GO can provide services to one or more GCs.

[0043] MagicLink protocol: It is a P2P data processing protocol (i.e., P2P transmission protocol), which is a communication protocol that discovers and pairs data through Bluetooth (e.g., BLE) broadcasts, and then exchanges data through WiFi P2P.

[0044] In this embodiment, when the MagicLink protocol version of the device (e.g., mobile phone A or tablet B) is an older version (first version), the device (i.e., the older version device) only supports one WiFi P2P network card management capability. Furthermore, the MagicLink application module of this device is responsible for both service scenario management and device networking, as well as deciding on WiFi P2P connection configuration information and instructing the WiFi link module to establish a WiFi P2P connection based on the decision results. Moreover, the MagicLink application module of this device only simply judges the role and channel capabilities to decide on the WiFi P2P connection configuration information (e.g., the channel for WiFi P2P communication when the device is a GO), which may lead to unreasonable decision results in certain scenarios.

[0045] When a device (e.g., mobile phone A or tablet B) uses the latest version (version 2) of the MagicLink protocol, the device (i.e., the new version device) can support the management of multiple WiFi P2P network cards. Furthermore, the MagicLink application module and the WiFi link module are functionally decoupled. The MagicLink application module is responsible for business scenario management and device networking, while the WiFi link module is responsible for deciding on WiFi P2P connection configuration information and establishing WiFi P2P connections. Moreover, since the WiFi module can obtain its own WiFi capability information in real time, it can more conveniently and efficiently decide on WiFi P2P connection configuration information based on its own WiFi capability information and the WiFi capability information from the peer, thus improving the communication quality of WiFi P2P. This eliminates the need for the MagicLink application module to obtain and store its own WiFi capability information from the WiFi module, saving communication overhead and storage space, making the WiFi P2P connection process simpler and more efficient.

[0046] In smart living scenarios (such as smart office, sports and health, smart home, smart travel, and audio-visual entertainment), various electronic devices (such as mobile phones, tablets, computers, TVs, cameras, and smart cars) bring users numerous conveniences and unprecedented experiences. These electronic devices can exchange data (information), enabling functions such as file sharing, multi-screen collaboration, and screen mirroring, thus better serving users. Data transmission between electronic devices can utilize WiFi P2P technology.

[0047] Currently, most electronic devices only support establishing one WiFi P2P connection. To support establishing multiple WiFi P2P connections, the electronic device needs to be upgraded. However, there may be compatibility issues between upgraded electronic devices (newer versions) and older electronic devices (older versions), which may cause WiFi P2P connection establishment to fail.

[0048] To address the aforementioned issues, this application provides a WiFi P2P connection method that resolves compatibility problems between upgraded electronic devices (new version devices) and non-upgraded electronic devices (old version devices), thus preventing WiFi P2P connection failures.

[0049] The method provided in this application can be applied to a first electronic device and a second electronic device. The first or second electronic device may be, for example, a mobile phone, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, cellular phone, personal digital assistant (PDA), augmented reality (AR) device, virtual reality (VR) device, artificial intelligence (AI) device, wearable device, in-vehicle device, smart home device, and / or smart city device. This application does not impose any special limitations on the specific type of the electronic device.

[0050] The following explanation uses the hardware structure of electronic device 100, with either the first or second electronic device as an example. Figure 1 A schematic diagram of the hardware structure of the electronic device 100 is shown.

[0051] Electronic device 100 may include processor 110, external memory interface 120, internal memory 121, Universal Serial Bus (USB) interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, button 190, camera 193, display screen 194, and Subscriber Identification Module (SIM) card interface 195, etc.

[0052] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0053] The processor 110 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0054] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0055] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0056] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0057] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image and video playback, etc.). The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.).

[0058] In some embodiments, the processor 110 may include one or more interfaces. The USB interface 130 is an interface compliant with the USB standard specification, specifically a Mini USB interface, a Micro USB interface, a USB Type-C interface, etc. The USB interface 130 can be used to connect a charger to charge the electronic device 100, and can also be used for data transfer between the electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices 100, such as AR devices.

[0059] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0060] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization.

[0061] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low-noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1.

[0062] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including Wireless Local Area Networks (WLAN) (such as Wi-Fi), Bluetooth (BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), NFC, and Infrared (IR). The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0063] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, so that electronic device 100 can communicate with networks and other devices through wireless communication technology.

[0064] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0065] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), an Active-Matrix Organic Light-Emitting Diode (AMOLED), a Flexible Light-Emitting Diode (FLED), Mini LED, Micro LED, Micro-OLED, Quantum Dot Light-Emitting Diodes (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0066] In this embodiment of the application, the display screen can be a touch screen, which can receive user operations (e.g., first operation, second operation, etc.) to realize human-computer interaction.

[0067] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU performs mathematical and geometric calculations and is used for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0068] Electronic device 100 can acquire images through ISP, camera 193, video codec, GPU, display screen 194, and application processor.

[0069] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses the layered architecture of the Android system as an example to illustrate the software structure of electronic device 100. The layered architecture divides the software into several layers, each with a clear role and division of labor. Layers communicate with each other through interfaces.

[0070] In some embodiments, the technical architecture of the electronic device 100 includes: an application layer (application layer), a framework layer (application framework layer), a kernel layer, and a hardware layer. It should be understood that the embodiments in this application only describe some layers and components related to the solution in this application. In actual applications, the electronic device 100 may also include other layers and components, and this application does not impose specific limitations.

[0071] like Figure 2A As shown, the application layer can include smart interconnection applications and MagicLink application modules.

[0072] Among them, the smart interconnection application can be used to receive user operations (such as screen sharing initiated by the user) and call the MagicLink application module based on the user operations.

[0073] The MagicLink application module is responsible for managing business scenarios and networking between multiple devices.

[0074] The framework layer can include a WiFi link module and an Android WiFi management module.

[0075] The Android WiFi management module is a native Android module used to manage the establishment and disconnection of WiFi P2P connections between the primary network interface card (NIC) of an electronic device (e.g., WiFi NIC 1) and the peer device. The process of establishing a WiFi P2P connection includes activating (raising / lowering) WiFi NIC 1, setting its frequency, service set identifier (SSID), and password, and then establishing a WiFi P2P connection with the peer device using the SSID and password. Subsequently, the MagicLink application module can establish an encrypted TCP channel based on the established WiFi P2P connection using the IP address and TCP port.

[0076] The WiFi link module is a self-developed (customized) module by Honor, which can be used to manage the extended network cards (e.g., WiFi network card 2) of electronic devices. These extended WiFi network cards can also include more network cards, such as WiFi network card 3, WiFi network card 4, etc., which are not limited in this application.

[0077] The WiFi link module can also be used to collect WiFi capability information (including the number of WiFi network cards, available WiFi channels, etc.) from WiFi drivers (e.g., the drivers for WiFi network card 1 and WiFi network card 2). The WiFi link module is compatible with the WiFi capabilities of different hardware platforms (e.g., WiFi chips or WiFi network cards).

[0078] The kernel layer is the layer between hardware and software. The kernel layer can contain WiFi drivers. WiFi drivers are the driver layer for WiFi network cards (e.g., WiFi card 1 and WiFi card 2), and are primarily responsible for interacting with the hardware. For example, a WiFi driver can include drivers for WiFi card 1 and WiFi card 2. The driver for WiFi card 1 is used to interact with WiFi card 1, and the driver for WiFi card 2 is used to interact with WiFi card 2.

[0079] The hardware layer may include a first network interface card (e.g., WiFi network interface card 1) and an extended network interface card (e.g., WiFi network interface card 2).

[0080] In some embodiments, such as Figure 2A As shown, the MagicLink application module can manage the WiFi P2P connection between the local device and an older version device (e.g., establishing a WiFi P2P connection with the older version device through the local device's first WiFi network card (e.g., WiFi network card 1, and WiFi network card 1 is idle)). The WiFi link module can manage the WiFi P2P connection between the local device and a newer version device (e.g., establishing a WiFi P2P connection with the newer version device through any idle WiFi network card of the local device). Since both the MagicLink application module and the WiFi link module can manage the local device's WiFi network card to establish a WiFi P2P connection with the peer device, conflicts may occur in the management of the WiFi network card (e.g., repeatedly establishing a WiFi P2P connection using the same WiFi network card (e.g., WiFi network card 1)), causing the local device to fail to establish a WiFi P2P connection with the peer device. The following example illustrates the problem of WiFi network card conflicts.

[0081] In some embodiments, if the WiFi link module decides to use the first WiFi network card (e.g., WiFi network card 1) to establish a WiFi P2P connection with the newer version device, it can call the Android WiFi management module. The Android WiFi management module can configure WiFi network card 1 through its driver, allowing the local device to establish a WiFi P2P connection with the peer device (newer version device) via WiFi network card 1. However, if the local device needs to establish a WiFi P2P connection with an older version device, the MagicLink application module decides to use the first WiFi network card (e.g., WiFi network card 1) to establish a WiFi P2P connection with the older version device. However, since the first WiFi network card (e.g., WiFi network card 1) is already in use, it cannot establish a WiFi P2P connection with the older version device, resulting in a failure to establish a WiFi P2P connection between the local device and the older version device.

[0082] In other embodiments, such as Figure 2B As shown, the WiFi link module can manage WiFi P2P connections between the local device and both new and old version devices (e.g., establishing WiFi P2P connections between the local device and either the new or old version device via any of its idle WiFi network cards). The WiFi link module can decide to use the first WiFi network card (e.g., WiFi network card 1) to establish a WiFi P2P connection with the old version device. WiFi network card 1 can be configured by calling the Android WiFi management module to establish a WiFi P2P connection with the peer device. The WiFi link module can also decide to use the second WiFi network card (e.g., WiFi network card 2) to establish a WiFi P2P connection with the new version device. WiFi network card 2 can be configured through its driver to establish a WiFi P2P connection with the peer device (the new version device).

[0083] compared to Figure 2A The illustrated embodiment employs a MagicLink application module to manage the WiFi P2P connection between the local device and older devices, and a WiFi link module to manage the WiFi P2P connection between the local device and newer devices. Figure 2B In the illustrated embodiment, the WiFi link module manages the WiFi P2P connection between the local machine and both the new and old versions of the device. This allows for simple and efficient management of the WiFi P2P connection between the local machine and both new and old versions of the device, without causing WiFi network card conflicts.

[0084] Furthermore, compared to Figure 2A In the embodiment shown, the MagicLink application module is responsible for both business scenario management and managing the WiFi P2P connection between the local machine and the older version device. Figure 2BIn the illustrated embodiment, the WiFi link module manages the WiFi P2P connections between the local device and both new and old versions of the device. This decouples the functions of the MagicLink application module and the WiFi link module, allowing each to leverage its strengths. The MagicLink application module excels in service scenario management and multi-device networking; however, it lacks direct access to WiFi chip capabilities and cannot promptly detect WiFi status changes, limiting its management to a single WiFi network card. In contrast, the WiFi link module excels in channel management and hardware capability adaptation; it directly accesses WiFi chip capabilities, can readily detect WiFi status changes, and manages multiple WiFi network cards. Furthermore, this decoupling facilitates future evolution (e.g., the WiFi link module can flexibly adjust the number of WiFi P2P connections based on its hardware capabilities).

[0085] In this embodiment, WiFi P2P connections can be managed on a per-WiFi network card basis. Compared to managing WiFi P2P connections on a per-device basis, managing WiFi P2P connections on a per-WiFi network card basis can be compatible with more WiFi network cards on devices, and the management of WiFi P2P connections is more flexible and efficient.

[0086] In some embodiments (e.g., Figure 2B In the illustrated embodiment, a module (component) can be split into two or more modules, or two or more modules at the same level can be merged into the same module.

[0087] As an example, the MagicLink application module at the application layer can include a P2P direct connection module and a security authentication module. The P2P direct connection module can be used for networking and information exchange with peer devices, while the security authentication module can be used for device security authentication and key exchange.

[0088] The WiFi link module may include a WiFi service module. This WiFi service module can obtain WiFi capability information from the WiFi driver and make decisions on WiFi P2P connection configuration information based on that information.

[0089] Electronic devices may also include a WiFi protocol stack. An Android WiFi management module or WiFi service module can call the WiFi protocol stack to establish a WiFi P2P connection (WiFi P2P physical link) with the peer device.

[0090] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. In the description of this application, unless otherwise stated, "at least one" refers to one or more, and "more than one" refers to two or more. Furthermore, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0091] like Figure 3A As shown, this application provides a WiFi P2P connection method, taking mobile phone A as the first electronic device and tablet computer B as the second electronic device as an example, including:

[0092] 301. Mobile phone A obtains the version of the P2P transmission protocol of tablet computer B.

[0093] P2P transmission protocols could be, for example, the MagicLink protocol, which is a communication protocol that uses Bluetooth (e.g., BLE) for broadcast discovery and pairing, and then uses WiFi P2P for data exchange.

[0094] 302. When the P2P transmission protocol is version 1, mobile phone A encapsulates the first data packet using the first data processing protocol and sends the first data packet to tablet computer B.

[0095] If tablet B's MagicLink protocol version is version 1 (an older version), mobile phone A can encapsulate a first data packet using a first data processing protocol and send the first data packet to tablet B. The first data packet includes mobile phone A's WiFi capability information, which includes information about a first WiFi network card.

[0096] Among them, the data packet format corresponding to the first data processing protocol can be key+value format. The key+value format data packet is easy to parse and has a high parsing accuracy.

[0097] In this way, when tablet B is an older version device (i.e., tablet B uses an older version of the MagicLink protocol), the first electronic device sends information about an idle WiFi network card (the first WiFi network card) to the second electronic device based on the key+value format. In other words, the first electronic device can disguise itself as an older protocol device with only a single WiFi network card (i.e., a device using the first version of the P2P transmission protocol), allowing the older version device to function normally (the older version device only supports one WiFi P2P network card management capability), thus avoiding compatibility issues with the older version device.

[0098] For a detailed explanation of how mobile phone A communicates with an older device (e.g., tablet B), please refer to the following text. Figures 7A-7B The relevant description of the embodiments.

[0099] 303. When the P2P transmission protocol is version 2, mobile phone A encapsulates the second data packet using the second data processing protocol and sends the second data packet to tablet computer B.

[0100] The second data packet is used to request the establishment of a WiFi P2P connection with tablet B. The second data packet includes WiFi capability information of mobile phone A, which includes information about a first WiFi network card and a second WiFi network card.

[0101] The second data processing protocol differs from the first data processing protocol. The second data processing protocol can be a TLV protocol. When sending data based on the TLV protocol, there is no need to carry redundant or invalid payloads (e.g., a key field), resulting in better transmission efficiency and scalability.

[0102] In this way, when the second electronic device is a new version device (i.e., the P2P transmission protocol version of the second electronic device is the second version), the first electronic device can send information of multiple idle WiFi network cards to the peer device based on the TLV protocol, so that the peer device can make decisions on WiFi P2P connection configuration information (determine the optimal network card and channel) based on the information of multiple idle WiFi network cards, which can improve the communication quality of WiFi P2P.

[0103] Based on the method provided in the embodiments of this application, the first electronic device can encapsulate different data packets with different data processing protocols based on the version (first version or second version) of the P2P transmission protocol (e.g., MagicLink protocol) of the peer device (second electronic device). Different versions of the device can identify data packets encapsulated by different data processing protocols respectively. In this way, the local device (first electronic device) can be compatible with different versions of the device, and compatibility problems can be avoided.

[0104] For a detailed explanation of how mobile phone A communicates with the new device (e.g., tablet B), please refer to the following text. Figures 4A-4B The relevant description of the embodiments.

[0105] The following is a simple explanation of the process of establishing a WiFi P2P connection between older devices, using a mobile phone and a tablet (both phones and tablets use older versions of the MagicLink protocol).

[0106] For example, such as Figure 3B As shown, when establishing a WiFi P2P communication connection between a mobile phone and a tablet, the mobile phone can send a P2P connection request to the tablet's MagicLink application module through its own MagicLink application module. This P2P connection request can carry the mobile phone's P2P role and channel capabilities (e.g., whether it supports being a GO, whether it supports 5G frequency bands, etc.). The tablet's MagicLink application module can easily determine its own and the tablet's roles and channel capabilities, decide which device to use as the GO (e.g., the device itself can be used as the GO) and the channel for WiFi P2P communication, and send the decision result to the mobile phone. Then, the mobile phone's MagicLink application module can instruct its WiFi link module to establish a WiFi P2P connection with the tablet's WiFi link module.

[0107] The following explains the process of establishing a WiFi P2P connection between devices in the new version.

[0108] like Figure 4A As shown, this application provides a WiFi P2P connection method, taking a mobile phone A as the first electronic device and a tablet computer B as the second electronic device, and both mobile phone A and tablet computer B as the latest version devices, as an example, including:

[0109] 401. Turn on WiFi and Bluetooth on mobile phone A and tablet B.

[0110] Taking mobile phone A as an example, in response to the user from Figure 5A By swiping down from the top of interface 501, phone A can display interface 502. Interface 502 includes a WLAN switch 5021 and a Bluetooth switch 5022. Phone A can receive user input to switches 5021 and 5022 (e.g., tapping) to enable WiFi and Bluetooth.

[0111] For example, in response to user requests Figure 5AWhen the user clicks the application icon 5013 in the settings interface 501, phone A can display interface 503, which includes WLAN settings 5031 and Bluetooth settings 5032. Phone A can receive user actions on settings 5031 and 5032 to enable WiFi and Bluetooth.

[0112] The process of enabling WiFi and Bluetooth on tablet B can be referred to the above description, and will not be repeated in this application.

[0113] 402. The MagicLink application module of mobile phone A and the MagicLink application module of tablet B discover the other device via Bluetooth broadcast.

[0114] After Bluetooth is turned on on phone A, phone A can send Bluetooth broadcasts; similarly, after Bluetooth is turned on on tablet B, tablet B can send Bluetooth broadcasts. Phone A's MagicLink application module can discover tablet B based on the Bluetooth broadcasts sent by tablet B. Tablet B's MagicLink application module can discover phone A based on the Bluetooth broadcasts sent by phone A. In other words, phone A and tablet B can discover each other based on Bluetooth broadcasts sent by the other device.

[0115] 403. The MagicLink application module of mobile phone A and the MagicLink application module of tablet computer B establish a Bluetooth connection.

[0116] The MagicLink application module of mobile phone A and the MagicLink application module of tablet B can establish a Bluetooth connection and communicate via the Bluetooth communication protocol.

[0117] The Bluetooth communication protocol can be the traditional Bluetooth protocol, or the Bluetooth Low Energy (BLE) protocol; of course, it can also be other new Bluetooth protocol types that will be launched in the future, which is not limited in this application.

[0118] 404. The MagicLink application module of mobile phone A and the MagicLink application module of tablet B perform device security authentication and exchange keys based on Bluetooth connection.

[0119] Mobile phone A and tablet B can perform device security authentication via Bluetooth to confirm that the other end is a trusted device. Then, mobile phone A and tablet B can exchange keys for secure communication.

[0120] 405a. The MagicLink application module of mobile phone A requests the WiFi link module of mobile phone A to obtain the basic WiFi parameters.

[0121] The basic WiFi parameters may include the version number of the WiFi link module, which indicates the number of WiFi network cards supported by the device, the number of supported WiFi P2P links, and the supported service scenarios (e.g., Trust Ring, Honor Share).

[0122] 406a. The WiFi link module of mobile phone A obtains the basic WiFi parameters of mobile phone A.

[0123] 407a. The WiFi link module of mobile phone A returns the basic WiFi parameters of mobile phone A to the MagicLink application module of mobile phone A.

[0124] 405b. The MagicLink application module of tablet B requests the WiFi basic parameters of tablet B from the WiFi link module of tablet B.

[0125] 406b. The WiFi link module of tablet B obtains the basic WiFi parameters of tablet B.

[0126] The basic WiFi parameters of tablet B can be found in the description of the basic WiFi parameters of phone A, and will not be repeated here.

[0127] 407b. The WiFi link module of tablet B returns the basic WiFi parameters of tablet B to the MagicLink application module of tablet B.

[0128] Steps 405a-407a and steps 405b-407b can be executed simultaneously.

[0129] 408. The MagicLink application module of mobile phone A and the MagicLink application module of tablet B exchange the basic WiFi parameters of the other end.

[0130] Optionally, after mobile phone A and tablet B establish a Bluetooth connection, the MagicLink application module of mobile phone A and the MagicLink application module of tablet B can exchange the basic WiFi parameters of the other end. This allows mobile phone A or tablet B to make a preliminary judgment based on its own and the other end's basic WiFi parameters after receiving a user-initiated service (e.g., screen sharing service). For details, please refer to the relevant description in step 417.

[0131] The basic WiFi parameters may include the version of the MagicLink protocol. Specifically, tablet B's MagicLink protocol version can be the latest version (version 2). Mobile phone A's MagicLink protocol version is also the latest version (version 2).

[0132] 409a. The MagicLink application module of mobile phone A reports the online status of the peer device (i.e. tablet B) to the smart interconnection application of mobile phone A.

[0133] That is, the MagicLink application module of mobile phone A reports the online status of tablet B to the smart interconnection application of mobile phone A.

[0134] 409b. The MagicLink application module of tablet B reports the online status of device (phone A) to the smart interconnection application of tablet B.

[0135] 410. The smart interconnection application of mobile phone A notifies the user that device (tablet B) is online.

[0136] For example, such as Figure 5B As shown in (b), the interface of mobile phone A can display the icon 44 of tablet B (hereinafter referred to as tablet B), prompting the user that "tablet B is online".

[0137] 411a. The smart interconnection application of mobile phone A receives the screen sharing operation initiated by the user.

[0138] Screen sharing refers to projecting the screen of a device (e.g., mobile phone A) onto the screen of a peer device (e.g., tablet B). This application uses WiFi P2P communication as an example for screen sharing, but WiFi P2P communication can also include other types of services, such as multi-screen collaboration and file sharing, which are not limited in this application.

[0139] For example, such as Figure 5B As shown in (a), in response to a user swiping down from the status bar of phone A to display the notification panel, phone A displays the notification panel, which may include the "Trust Ring Multi-Device Interconnection Center" option 41. In response to a user triggering an action on the "Trust Ring Multi-Device Interconnection Center" option 41 (e.g., a click), phone A may display as shown in (a). Figure 5B The control interface 42 shown in (b) is shown in the figure. The control interface 42 includes the device identifier 43 of the local device (i.e., mobile phone A) and the device identifier 44 of the tablet computer B (hereinafter referred to as tablet B) (that is, the local device (i.e., mobile phone A) and tablet computer B are both joined to the same trust ring).

[0140] In some implementations, the user can drag the device identifier 44 of tablet B towards the device identifier 43 of the device itself. When the drag operation ends near the device identifier 43 of the device itself, screen sharing can be achieved between the device (i.e., mobile phone A) and tablet B (i.e., the screen of mobile phone A can be projected onto the screen of tablet B). In other implementations, the user can drag the device identifier 43 of the device itself towards the identifier 44 of tablet B. When the drag operation ends near the identifier 44 of tablet B, screen sharing can be achieved between the device (i.e., mobile phone A) and tablet B.

[0141] 411b. The Smart Interconnection Application of Mobile Phone A identifies the Quality of Service (QoS) information of the screen sharing service.

[0142] The QoS information for a service (e.g., screen sharing) may include one or more of the following: expected bandwidth, latency, jitter, priority, etc. For example, a screen sharing service can be a high-bandwidth service. For instance, the expected bandwidth of a screen sharing service may be greater than a preset bandwidth (e.g., 40MB / s). Alternatively, a screen sharing service can be a low-latency service. For instance, the latency requirement for a screen sharing service is less than 20ms.

[0143] 412. The Smart Interconnection application of mobile phone A initiates a connection call to the MagicLink application module of mobile phone A.

[0144] The smart interconnection application on mobile phone A can call the device connection interface of the MagicLink application module to pass in the QoS information of the screen sharing service.

[0145] 413a. The MagicLink application module of mobile phone A and the MagicLink application module of tablet computer B establish a negotiation channel (channel 1).

[0146] When the MagicLink application module of mobile phone A receives a connection call from the smart interconnection application, it can save the QoS information of the screen sharing service. Furthermore, the MagicLink application module of mobile phone A can create a negotiation channel (channel 1) with the peer device (tablet B). For example, as shown... Figure 6 As shown, channel 1 is used for information exchange between MagicLink application modules of different devices (MagicLink application module of mobile phone A and MagicLink application module of tablet computer B).

[0147] The MagicLink application module on phone A can create Channel 1 based on the discovery and network type between phone A and tablet B, regardless of the network connection type. For example, if the discovery and network type between phone A and tablet B is a WiFi LAN, Channel 1 can be created based on the WiFi connection; if the discovery and network type between phone A and tablet B is a Bluetooth network, Channel 1 can be created based on the Bluetooth connection.

[0148] Furthermore, after Channel 1 is successfully created, the MagicLink application module of mobile phone A and the MagicLink application module of tablet B can perform device security authentication and key exchange based on Channel 1, thereby completing the creation of the encrypted negotiation channel (i.e., encrypted Channel 1).

[0149] It should be understood that a Bluetooth connection or a WiFi connection refers to a physical channel (also called a physical link) used for data transmission between two communicating parties (e.g., mobile phone A and tablet B). Multiple virtual channels (also called data links) can be created based on the same physical channel. Virtual channels have the function of exchanging information between specific modules using predefined data processing protocols. For example, channel 1 is a virtual channel that can be used for information exchange between MagicLink application modules on different devices.

[0150] For example, the data processing protocol of the negotiation channel (i.e., channel 1) can be a first data processing protocol, which can be used to process (encapsulate or parse) data packets in key+value format. That is, the data packets corresponding to the first data processing protocol are in key+value format. Key+value format data packets are easy to parse, but they carry redundant payload (key) when sending data, consuming additional bandwidth. Furthermore, key+value format data packets require complete parsing during forwarding (e.g., data needs to be parsed into key+value format), making data transmission inefficient.

[0151] For example, the format of data packets for the negotiation channel (i.e., channel 1) can be as shown in Table 1:

[0152] Table 1

[0153] key IP TCP port value XX XX

[0154] Among them, IP and TCP port refer to the IP address and TCP port used by the local device (phone A) to establish a WiFi P2P connection.

[0155] 413b. The MagicLink application module of mobile phone A and the MagicLink application module of tablet computer B create an auxiliary channel (channel 2).

[0156] The MagicLink application module on phone A can also create an auxiliary channel (channel 2) to the other device (tablet B). Channel 2 (the third communication channel) is a virtual channel. For example, ... Figure 6 As shown, channel 2 can be used for communication (information exchange) between WiFi link modules of different devices (WiFi link module of mobile phone A and WiFi link module of tablet B). When WiFi link modules of different devices exchange information based on channel 2, the information can be forwarded through the respective MagicLink application modules of each device.

[0157] The MagicLink application module on phone A can create Channel 2 based on the discovery and network type between phone A and tablet B, regardless of the network connection type. For example, if the discovery and network type between phone A and tablet B is a WiFi LAN, Channel 2 can be created based on the WiFi connection; if the discovery and network type between phone A and tablet B is a Bluetooth network, Channel 2 can be created based on the Bluetooth connection.

[0158] Furthermore, after channel 2 is successfully created, the MagicLink application module of mobile phone A and the MagicLink application module of tablet B can perform device security authentication and key exchange based on channel 2. Thus, the encrypted auxiliary channel (i.e., encrypted channel 2) is created.

[0159] For example, the data processing protocol for the auxiliary channel (i.e., channel 2) can be a second data processing protocol, which can be used to process (encapsulate or parse) TLV format data packets. That is, the data packets corresponding to the second data processing protocol are in TLV format. In TLV, T stands for dataType (or simply Type), indicating the type of the receiving module corresponding to the data; V represents the actual value carried in the data packet; and L represents the length of the actual value. The lengths of T and L can be fixed, for example, 2 bytes or 4 bytes, and the length of V is determined based on L.

[0160] It should be noted that when WiFi link modules of different devices exchange information via Channel 2, the data can be forwarded through the respective MagicLink application modules of each device. Since the data packets corresponding to the data processing protocol of Channel 2 are in TLV format, the MagicLink application module does not need to parse the WiFi link module's data (e.g., it does not need to parse the WiFi link module's data into a key+value structure) when forwarding it; it can directly transmit the WiFi link module's data, thus improving transmission efficiency. Furthermore, compared to the JSON protocol, using the TLV protocol to send data does not require carrying redundant and invalid payloads (e.g., key fields), resulting in better transmission efficiency and scalability.

[0161] For example, the format of data packets for the auxiliary channel (i.e., channel 2) can be as shown in Table 2:

[0162] Table 2

[0163] dataType length value 0 XX XXXXX

[0164] For example, a dataType field of 0 can indicate that the receiving module corresponding to the data (i.e., the value) is the WiFi link module of the other end.

[0165] Optionally, the data packets of the secondary channel (i.e., channel 2) may also include encryption / decryption fields (e.g., AuthDataHead) to indicate the encryption / decryption type of the data packets of the secondary channel (i.e., channel 2).

[0166] In one possible implementation, the auxiliary channel (i.e., channel 2) can simultaneously provide negotiation capabilities for the MagicLink application module and the WiFi link module of different devices, meaning it can be used simultaneously for data interaction between the MagicLink application module and the WiFi link module of different devices. Thus, a single transmission based on the auxiliary channel (i.e., channel 2) can simultaneously meet the data interaction needs of the MagicLink application module and the WiFi link module. For example, the data packet format of the auxiliary channel (i.e., channel 2) can be as shown in Table 3:

[0167] Table 3

[0168] dataType 1 Length 1 value 1 dataType 2 Length 2 value 2 1 XX XX 0 XX XX

[0169] In this context, the dataType 1 field being 1 indicates that the receiving module corresponding to the data (value 1) is the Magiclink application module of the other end, and Length 1 indicates the length of value 1; the dataType 2 field being 0 indicates that the receiving module corresponding to the data (i.e., value 2) is the WiFi link module of the other end, and Length 2 indicates the length of value 2.

[0170] 414a. The MagicLink application module of mobile phone A saves channel 1 and channel 2.

[0171] Channel 1 can be the first communication channel, and channel 2 can be the second communication channel.

[0172] 414b. The MagicLink application module of tablet B saves channel 1 and channel 2.

[0173] 415a. The MagicLink application module of mobile phone A registers channel 2 with the WiFi link module of mobile phone A.

[0174] The MagicLink application module of mobile phone A can send a registration request to the WiFi link module. The registration request can carry the configuration information of channel 2 (e.g., channel name, channel data processing protocol). The WiFi link module of mobile phone A can save the configuration information of channel 2 for subsequent use.

[0175] Among them, the MagicLink application module of mobile phone A can be the first module, and the WiFi link module of mobile phone A can be the second module.

[0176] 415b. The MagicLink application module of tablet B registers channel 2 with the WiFi link module of tablet B.

[0177] The MagicLink application module of tablet B can send a registration request to the WiFi link module. The registration request can carry the configuration information of channel 2 (e.g., channel name, channel data processing protocol). The WiFi link module of tablet B can save the configuration information of channel 2 for later use.

[0178] 416. The MagicLink application module of mobile phone A initiates a connection call to the WiFi link module of mobile phone A.

[0179] That is, the MagicLink application module of mobile phone A can transmit the following information to the WiFi link module of mobile phone A: QoS information of screen sharing service and WiFi basic parameters of the peer device (tablet B).

[0180] 417. The WiFi link module of mobile phone A generates data packet 1.

[0181] In some embodiments, the WiFi link module of mobile phone A can receive information from the MagicLink application module of mobile phone A and perform the following processing: 1. Collect the latest WiFi capability information of the device (for example, the WiFi link module of mobile phone A can call the query interface of the WiFi driver to query the WiFi capability information, and the WiFi driver can return the WiFi capability information based on the current hardware capabilities (number, model, etc. of WiFi network cards) and resource usage (usage status of WiFi network cards); 2. Generate data packet 1 (second data packet) based on the collected WiFi capability information. That is, data packet 1 includes the latest WiFi capability information of the device. Optionally, data packet 1 also includes QoS information for screen sharing services. Data packet 1 is used to request the establishment of a WiFi P2P connection with tablet B, and can also be used to negotiate WiFi P2P connection configuration information with the peer.

[0182] In some embodiments, when the peer device uses a new version of the MagicLink protocol (i.e., the peer device is a new version device), the WiFi capability information of mobile phone A includes information on multiple idle WiFi network cards (e.g., a first WiFi network card and a second WiFi network card). That is, when the peer device is a new version device, the local device (new version device) can send the information on the multiple idle WiFi network cards to the peer device, enabling the peer device to make decisions on WiFi P2P connection configuration information based on the information on the multiple idle WiFi network cards (determining the optimal network card and channel), thereby improving the WiFi P2P communication quality.

[0183] The WiFi capability information can include static capability information (basically fixed information), which includes the number of WiFi network cards supported by the device, WiFi network card identifier, WiFi network card model, available WiFi channels, and other information.

[0184] Furthermore, WiFi capability information can also include dynamic capability information (dynamically changing information, also known as WiFi occupancy status information). Dynamic capability information can include information about WiFi connections that the device (or network card) has established (e.g., the number of established WiFi connections and the status of established WiFi connections (e.g., the P2P role of the two-end devices in the WiFi connection, network card information, etc.)).

[0185] In other embodiments, the WiFi link layer module can make a preliminary judgment based on the currently acquired information (the WiFi basic parameters of both devices and the QoS information of the service). If it is determined that the WiFi capabilities of the two devices (mainly the capabilities indicated by static capability information) cannot meet the service requirements, there is no need to establish a negotiation channel or initiate a negotiation process, avoiding unnecessary negotiation and saving negotiation resources. Furthermore, the WiFi link layer module can notify the smart interconnection application of screen sharing failure through the MagicLink application module, and the smart interconnection application can prompt the user that screen sharing has failed. If it is determined that the WiFi basic parameters of both devices can meet the service requirements, the latest WiFi capability information of the local device can be collected (mainly the latest dynamic capability information; static capability information is usually fixed and does not need to be collected repeatedly), and data packet 1 can be generated based on the collected WiFi capability information and the QoS information of the screen sharing service.

[0186] For example, after receiving a connection call initiated by the MagicLink application module, the WiFi link layer module can parse the bandwidth requirement of the service (e.g., screen sharing service) and determine the type of physical connection corresponding to the service based on the bandwidth requirement. For instance, if the bandwidth requirement of the service (e.g., screen sharing service) is high bandwidth (e.g., expected bandwidth greater than 40MB / s), the physical connection type can be a 5GHz WiFi P2P connection. If the bandwidth requirement of the service is medium bandwidth (e.g., expected bandwidth greater than 10MB / s and less than 40MB / s), the physical connection type can be a 2.4GHz WiFi P2P connection. If the bandwidth requirement of the service is low bandwidth (e.g., expected bandwidth less than 10MB / s), the physical connection type can be a Bluetooth connection.

[0187] If a service (e.g., screen sharing) requires high bandwidth, and the physical connection type can be a 5GHz WiFi P2P connection, but one end device does not support 5GHz WiFi P2P connections (meaning one end device's capabilities cannot meet the service requirements), then there is no need to establish a negotiation channel or initiate a negotiation process, avoiding unnecessary negotiation and saving negotiation resources. Furthermore, the WiFi link layer module can notify the smart interconnection application of screen sharing failure through the MagicLink application module, and the smart interconnection application can then notify the user of the screen sharing failure.

[0188] 418a. The WiFi link module of mobile phone A calls channel 2 and sends data packet 1.

[0189] That is, the WiFi link module of mobile phone A calls channel 2 registered by the MagicLink application module and sends data packet 1 to the MagicLink application module of mobile phone A.

[0190] 418b. The MagicLink application module of mobile phone A encapsulates data packet 1 into data packet 2 according to the communication protocol of channel 2.

[0191] The MagicLink application module of mobile phone A can add a MagicLink header to data packet 1 to obtain data packet 2.

[0192] The MagicLink header can include the data type and the data length.

[0193] For example, the format of data packet 2 can be as shown in Table 4:

[0194] Table 4

[0195] dataType length value 0 5 01 02 03 04 05

[0196] The dataType field is 0, which indicates that the receiving module corresponding to the data (value) is the WiFi link module of the other end. Length indicates the length of the value (e.g., 5 bytes). The value indicates the data packet 1 generated by the WiFi link module of mobile phone A (e.g., 01 02 03 04 05).

[0197] 418c. The MagicLink application module of mobile phone A sends data packet 2 through channel 2.

[0198] 419. The MagicLink application module of tablet B receives data packet 2 from channel 2 and parses data packet 2 to obtain data packet 1 according to the communication protocol of channel 2.

[0199] The MagicLink application module of tablet B can strip the MagicLink header from data packet 2 to obtain data packet 1.

[0200] 420. The MagicLink application module of tablet B sends data packet 1 to the WiFi link module of tablet B.

[0201] 421a. The WiFi link module of tablet B parses data packet 1 to obtain the WiFi capability information and QoS information of the initiating device (i.e., mobile phone A).

[0202] Furthermore, the WiFi link module of tablet B can obtain the WiFi capability information of the local device (i.e., tablet B).

[0203] like Figure 4B As shown, the method also includes:

[0204] 421b. The WiFi link module of tablet B makes a decision based on the information carried in data packet 1 and the WiFi capability information of tablet B, and generates data packet 3 based on the decision result.

[0205] That is, the WiFi link module of tablet B can make decisions based on the WiFi capability information of both devices and the QoS information of services (e.g., screen sharing services), and then generate data packets 3 based on the decision results.

[0206] In some embodiments, when the QoS information of the service meets the first condition, if tablet B and mobile phone A support WiFi P2P connection on the 5G band, then tablet B and mobile phone A can establish a WiFi P2P connection on the 5G band. Tablet B can then generate corresponding WiFi P2P connection configuration information. Data packet 3 includes WiFi P2P connection configuration information. This WiFi P2P connection configuration information may include the roles (GO and GC) of P2P communication, the network card used for P2P communication, the channel (e.g., a 5G channel), antenna information, etc.

[0207] Optionally, it can be determined whether tablet B supports 5G band WiFi P2P connections based on the tablet B's WiFi capability information. For example, if tablet B includes an idle network card that supports the 5G band, then tablet B is considered to support 5G band WiFi P2P connections. Similarly, it can be determined whether mobile phone A supports 5G band WiFi P2P connections based on the mobile phone A's WiFi capability information. For example, if mobile phone A includes an idle network card that supports the 5G band, then mobile phone A is considered to support 5G band WiFi P2P connections.

[0208] In some embodiments, when tablet B's P2P role is GO (i.e., tablet B's P2P role is GO in an established WiFi P2P connection (e.g., tablet B and mobile phone C establish a WiFi P2P connection), and the network card used by tablet B to establish the WiFi P2P connection supports the 5G band; and mobile phone A has an idle network card, tablet B can reuse the GO to establish a WiFi P2P connection with mobile phone A. That is, tablet B continues to act as GO, connecting to mobile phone A, which acts as GC. In other words, as GO, tablet B can connect not only to mobile phone C, which acts as GC, but also to mobile phone A, which also acts as GC. In this way, tablet B's reuse of the GO to establish a WiFi P2P connection with mobile phone A expands the connected devices of tablet B and saves network card resources.

[0209] For example, the first condition may include: the QoS information of the service indicates that the expected bandwidth of the service is greater than a first threshold (e.g., 40 MB / s). Optionally, the first condition may also include: the expected latency of the service is less than a second threshold (e.g., 20 ms) and / or the jitter of the service is less than a third threshold (e.g., 5 ms).

[0210] In some embodiments, when the QoS information of the service meets the first condition, if tablet B or mobile phone A does not support WiFi P2P connection on the 5G band, tablet B can return a decision result to mobile phone A. The decision result is used to instruct the establishment of a bridge.

[0211] In some embodiments, when the QoS information of the service meets the second condition, if tablet B and mobile phone A support WiFi P2P connection on the 5G band, then tablet B and mobile phone A can establish a WiFi P2P connection on the 5G band. If tablet B and mobile phone A do not support WiFi P2P connection on the 5G band, but support WiFi P2P connection on the 2.4G band, then tablet B and mobile phone A can establish a WiFi P2P connection on the 2.4G band. Tablet B can generate corresponding WiFi P2P connection configuration information, which may include the P2P communication role (GO and GC), the network card used for P2P communication, the channel (5G channel / 2.4G channel), antenna, and other information.

[0212] For example, the second condition may include: the QoS information of the service indicates that the expected bandwidth of the service is less than or equal to a first threshold (e.g., 40 MB / s). Optionally, the first condition may also include: the expected latency of the service is greater than or equal to a second threshold (e.g., 20 ms) and / or the jitter of the service is greater than or equal to a third threshold (e.g., 5 ms).

[0213] If the QoS information of the service meets the first condition, and tablet B and mobile phone A support establishing a WiFi P2P connection on the 5G band, after step 421a, steps 422a-437 can be executed to establish a WiFi P2P connection (5G band WiFi P2P connection) between tablet B and mobile phone A.

[0214] If the QoS information of the service meets the first condition, and tablet B and mobile phone A do not support WiFi P2P connection on the 5G band, a bridge can be established between tablet B and mobile phone A (e.g., 5G band bridging).

[0215] If the QoS information of the service meets the second condition, and tablet B and mobile phone A support establishing a WiFi P2P connection on the 2.4G or 5G frequency band, refer to steps 422a-437 to establish a WiFi P2P connection (WiFi P2P connection on the 2.4G or 5G frequency band) between tablet B and mobile phone A.

[0216] If the QoS information of the service meets the second condition, and tablet B and mobile phone A do not support establishing WiFi P2P connections on the 2.4G and 5G frequency bands, referring to steps 702-726, a bridge (bridging on the 2.4G or 5G frequency band) can be established between tablet B and mobile phone A.

[0217] In this embodiment, the connection method (WiFi P2P connection or bridging) between the local device and the peer device can be determined based on the QoS information of the service and the WiFi capability information of the device. This can better meet the service requirements and avoid problems such as stuttering and frame drops in the service (e.g., screen sharing service).

[0218] In some embodiments, the WiFi link module determines the P2P network card (the network card used for P2P communication) in the WiFi P2P connection configuration information by selecting an available, idle network card of the device (e.g., tablet B) to establish a WiFi P2P connection. For example, the WiFi link module can sequentially detect whether the first WiFi network card (e.g., WiFi network card 1) and the second WiFi network card (e.g., WiFi network card 2) are available. If the first WiFi network card is available, it directly uses the first WiFi network card to establish a WiFi P2P connection; if the first WiFi network card is unavailable, it then checks whether the second WiFi network card is available. If the second WiFi network card is available, it uses the second WiFi network card to establish a WiFi P2P connection. Of course, if the device (e.g., tablet B) also includes more WiFi network cards (e.g., a third WiFi network card), it can continue to detect until an available WiFi network card is found.

[0219] In some embodiments, the WiFi link module may decide on the P2P channel and antenna (the antenna used for P2P communication) in the WiFi P2P connection configuration information in the following ways: 1. When the service is high bandwidth (e.g., the expected bandwidth of the service is greater than the preset bandwidth (e.g., 40MB / s)), a 5G band channel is selected to establish a WiFi P2P connection, and the antenna is exclusively used (i.e., one WiFi P2P connection exclusively uses one or more antennas for data transmission); 2. When the service is medium to low bandwidth (e.g., the expected bandwidth of the service is less than the preset bandwidth), a 2.4G band channel is selected to establish a WiFi P2P connection, or a 5G band channel is selected to establish a WiFi P2P connection, and the antenna can be shared (e.g., two WiFi P2P connections can share one or more antennas for data transmission).

[0220] In some embodiments, the WiFi link module may determine the P2P role in the WiFi P2P connection configuration information by designating the device as the GO as having strong WiFi chip capabilities (e.g., WiFi chips can integrate WiFi network cards, and the more WiFi network cards integrated and the newer the WiFi network card model, the stronger the WiFi chip capabilities) and sufficient power (e.g., the device connected to a power source (e.g., a TV) has more power than the device being charged (e.g., a mobile phone or tablet)).

[0221] 422a. The WiFi link module of tablet B calls channel 2 and sends data packet 3.

[0222] The WiFi link module of tablet B can call channel 2 registered by the MagicLink application module of tablet B to send data packet 3 to the MagicLink application module of tablet B.

[0223] 422b. The MagicLink application module of tablet computer B encapsulates data packet 3 into data packet 4 according to the communication protocol of channel 2.

[0224] The MagicLink application module of tablet B adds a MagicLink header to data packet 3, resulting in data packet 4 (the third data packet).

[0225] 422c. The MagicLink application module of tablet B sends data packet 4 through channel 2.

[0226] 423a. The MagicLink application module of mobile phone A receives data packet 4 through channel 2 and parses data packet 4 according to the communication protocol of channel 2 to obtain data packet 3.

[0227] The MagicLink application module of mobile phone A can strip the MagicLink header from data packet 4 to obtain data packet 3.

[0228] 423b. The MagicLink application module of mobile phone A sends data packet 3 to the WiFi link module of mobile phone A.

[0229] 424. The WiFi link module of mobile phone A parses data packet 3 to obtain the WiFi P2P connection configuration information decided by the peer device (tablet B), and creates GO based on the WiFi P2P connection configuration information.

[0230] Data packet 3 includes WiFi P2P connection configuration information decided by the peer device (tablet B). For example, the WiFi P2P connection configuration information could be: mobile phone A acts as the GO (Go), tablet B acts as the GC (GC), the P2P channel is established on a 5G channel (e.g., channel 161 at a frequency of 5805MHz), and tablet B's WiFi network card 2 acts as the P2P network card. Mobile phone A can create a GO based on the WiFi P2P connection configuration information.

[0231] Furthermore, after phone A creates the GO, phone A can also perform the following steps:

[0232] 425a. The WiFi link module of mobile phone A sends the IP address and network card name of the local device (GO device) to the MagicLink application module of mobile phone A.

[0233] The IP address and network interface name of the local device (GO device) refer to the IP address and network interface used to create the WiFi P2P connection.

[0234] 425b. After receiving the IP address and network card name, the MagicLink application module of mobile phone A starts listening on the TCP port and encapsulates the local IP address and TCP port into a data packet 5 according to the communication protocol of channel 1.

[0235] That is, the MagicLink application module of mobile phone A can listen to the IP and TCP ports used to establish WiFi P2P connections, and encapsulate the listened local IP and TCP ports into data packets.

[0236] Among them, data packet 5 is used as the transmission channel for establishing a subsequent WiFi P2P connection.

[0237] For example, the format of data packet 5 can be as shown in Table 1 above (step 413a).

[0238] 425c. The MagicLink application module of mobile phone A sends data packet 5 to the MagicLink application module of tablet computer B through channel 1.

[0239] 426a. After receiving data packet 5, the MagicLink application module of tablet computer B parses data packet 5 through the communication protocol of channel 1.

[0240] 426b. The MagicLink application module of tablet B stores the IP and TCP port of the peer (phone A).

[0241] The IP and TCP ports of the peer (phone A) are used to establish a negotiation channel on the P2P platform later.

[0242] 427a. The WiFi link module of mobile phone A encapsulates the connection information of the local device (GO device) into a data packet 6, calls channel 2, and passes in the data packet 6.

[0243] The connection information for the GO device (i.e., the connection information of the device acting as the GO) includes the frequency created by the GO, SSID, password, etc. Data packet 6 is used for the GC and GO to establish a WiFi P2P connection.

[0244] 427b. The MagicLink application module of mobile phone A encapsulates data packet 6 into data packet 7 according to the communication protocol of channel 2.

[0245] The MagicLink application module of mobile phone A adds a MagicLink header to data packet 6, resulting in data packet 7.

[0246] 427c. The MagicLink application module of mobile phone A sends data packet 7 to the MagicLink application module of tablet computer B through channel 2.

[0247] Steps 425a-425c and steps 427a-427c can be executed in parallel.

[0248] 428a. After receiving data packet 7, the MagicLink application module of tablet computer B parses data packet 7 through the communication protocol of channel 2 to obtain data packet 6.

[0249] 428b. The MagicLink application module of tablet B sends data packet 6 to the WiFi link module of tablet B.

[0250] Steps 427a-427b and steps 428a-428b can be executed in parallel.

[0251] In other words, the MagicLink application module of tablet B can receive different data packets through different channels and process them differently.

[0252] 429. The WiFi link module of tablet B parses data packet 6 to obtain the GO connection information of the other end (phone A).

[0253] 430. The WiFi link module of tablet B establishes a WiFi P2P link layer connection with the WiFi link module of mobile phone A based on the GO connection information of the peer (mobile phone A).

[0254] The WiFi link module of tablet B connects to mobile phone A, which acts as GO, based on the GO connection information of the peer (mobile phone A).

[0255] That is, tablet B acts as GC and connects to mobile phone A as GO.

[0256] 431a. The WiFi link module of tablet B sends a WiFi notification message to the MagicLink application module of tablet B. The WiFi notification message is used to notify that the WiFi P2P connection is successful.

[0257] The WiFi notification message includes information related to the WiFi P2P connection, such as the IP address of the local device (tablet B) and the peer device (phone A) used to establish the WiFi P2P connection, the network card name (e.g., phone A corresponds to network card 1, and tablet B corresponds to network card 2), the P2P role (e.g., phone A is GO, and tablet B is GC), and the ID (serviceid) of this WiFi P2P connection.

[0258] 431b. The MagicLink application module of tablet B stores WiFi P2P connections.

[0259] The MagicLink application module of tablet B receives the WiFi notification message sent by the WiFi link module of tablet B, obtains the relevant information of WiFi P2P connection from the WiFi notification message, and saves the relevant information (i.e., saves the WiFi P2P connection).

[0260] 432a. The WiFi link module of mobile phone A sends a WiFi notification message to the MagicLink application module of mobile phone A. The WiFi notification message is used to notify that the WiFi P2P connection is successful.

[0261] 432b. The MagicLink application module of mobile phone A saves WiFi P2P connections.

[0262] Steps 431a-431b and 432a-432b can be executed in parallel. That is, after a successful WiFi connection, the WiFi modules of both devices A and B notify their respective MagicLink application modules that the P2P connection is successful. The MagicLink application modules of each device can save the WiFi P2P connection for subsequent communication based on that connection.

[0263] 433. The MagicLink application module of tablet B creates a TCP encrypted channel based on WiFi P2P connection to the MagicLink application module of mobile phone A.

[0264] The MagicLink application module of tablet B can make logical judgments based on its local P2P role to determine what kind of processing to perform. For example, when the P2P role of tablet B is GC, the MagicLink application module of tablet B can read the IP and port of the peer device (phone A) saved in step 427b, and create a TCP encrypted channel based on WiFi P2P connection to the peer device (phone A) based on the peer device (phone A)'s IP and port.

[0265] Among them, the TCP encrypted channel based on WiFi P2P connection can provide a more secure, stable, high-bandwidth, and low-latency negotiation channel for smart interconnection applications (such as screen sharing services) than the Bluetooth channel, providing a negotiation channel for subsequent link management negotiation of MagicLink application modules. That is, the MagicLink application modules of the two-end devices (e.g., mobile phone A and tablet B) can exchange service (e.g., screen sharing service) data (e.g., screen display information) based on the TCP encrypted channel of WiFi P2P connection.

[0266] Optionally, after the TCP encrypted channel based on the WiFi P2P connection is created, the devices (phone A and tablet B) can delete the previously created channel 1 and / or channel 2 to save storage space.

[0267] 434. The MagicLink application module of mobile phone A replies to the MagicLink application module of tablet computer B that the TCP encrypted channel based on WiFi P2P connection has been created.

[0268] 435a. The MagicLink application module of mobile phone A stores a TCP encrypted channel based on WiFi P2P connection.

[0269] That is, mobile phone A can save the TCP encrypted channel for subsequent interaction with the other end device (tablet B).

[0270] 435b. The MagicLink application module of tablet B stores a TCP encrypted channel based on WiFi P2P connection.

[0271] This means that tablet B can save the TCP encrypted channel for subsequent interaction with the peer device (phone A).

[0272] Steps 435a and 435b can be executed in parallel.

[0273] 436. The MagicLink application module of mobile phone A notifies the smart interconnection application of mobile phone A that the device connection is successful.

[0274] Once the encrypted TCP channel based on WiFi P2P connection is successfully established, the MagicLink application module of mobile phone A notifies the smart interconnection application of mobile phone A that the device connection is successful.

[0275] 437. The Smart Interconnection application on mobile phone A initiates a screen sharing service and notifies the user that the screen sharing service has been successfully established.

[0276] The smart connectivity application on mobile phone A can initiate screen sharing services over a TCP encrypted channel connected via WiFi P2P. This means sending screen sharing data (e.g., information related to mobile phone A's screen) to the other device (tablet B) via WiFi P2P connection.

[0277] Steps 436-437 can be performed after step 432a, step 432b, or step 434.

[0278] The solution provided in this application embodiment determines the WiFi P2P connection configuration information through the WiFi link module. Since the WiFi link module is capable of obtaining the local device's WiFi capability information in real time, it can more conveniently and efficiently determine the WiFi P2P connection configuration information based on the local device's WiFi capability information and the WiFi capability information from the peer, thereby improving the communication quality of WiFi P2P. This eliminates the need for the MagicLink application module to obtain and store the local device's WiFi capability information from the WiFi link module, saving communication overhead and storage space, and making the WiFi P2P connection method simpler and more efficient.

[0279] Figures 4A-4B The solution shown only works when both communication ends (e.g., mobile phone A and tablet B) are using the latest MagicLink protocol version (i.e., both communication ends are newer devices). When one communication end is a newer device and the other is an older device, the above solution is incompatible and may cause the WiFi P2P connection between the newer and older devices to fail.

[0280] This application provides a compatible solution for establishing WiFi P2P connections between new and old version devices. The following is a description of the solution in conjunction with the accompanying drawings (…). Figures 7A-7B ,as well as Figures 8A-8B This section describes the compatibility scheme.

[0281] like Figure 7A As shown, this application provides a WiFi P2P connection method, taking a mobile phone A as the first electronic device and a tablet B as the second electronic device, with mobile phone A being a newer version device and tablet B being an older version device, as an example. The method includes the following steps:

[0282] Steps 701-704 can be referred to the relevant descriptions of steps 401-404. Steps 705-707 can be referred to the relevant descriptions of steps 405a-407a.

[0283] 708. The MagicLink application module of mobile phone A and the MagicLink application module of tablet B exchange the MagicLink protocol version of the other end.

[0284] In this case, tablet B can use an older version of the MagicLink protocol (version 1), meaning phone A is an older version device. Phone A can use a newer version of the MagicLink protocol (version 2), meaning phone A is a newer version device.

[0285] Steps 709a-712 can be referenced from the relevant descriptions of steps 409a-412.

[0286] 713. The MagicLink application module of mobile phone A determines the version of the MagicLink protocol of the peer device.

[0287] If the MagicLink protocol version of the peer device is an older version (i.e., the peer device is an older version device), the MagicLink application module of mobile phone A can execute steps 714 and 715.

[0288] 714. The MagicLink application module of mobile phone A and the MagicLink application module of tablet computer B establish a negotiation channel (channel 1).

[0289] For a description of Channel 1, please refer to step 413a, which will not be repeated here.

[0290] 715. The MagicLink application module of mobile phone A registers an auxiliary channel (channel 3) with the WiFi link module of mobile phone A.

[0291] The MagicLink application module of mobile phone A can send a registration request to the WiFi link module. This registration request can carry the configuration information for channel 3 (e.g., channel name and channel data processing protocol). The data processing protocol for channel 3 (the second communication channel) is the same as that for channel 1 (the first communication channel). For example, the data processing protocol for channel 3 can be used to process key+value format data packets. The WiFi link module of mobile phone A can save the configuration information for channel 3 so that it can subsequently generate corresponding data packets based on the data processing protocol for channel 3 and call channel 3 based on its channel name, enabling the MagicLink application module to forward the corresponding data packets.

[0292] Among them, the channel name of channel 3 can be the same as that of channel 2. That is, during the process of establishing a WiFi P2P connection with a new version device or an old version device, the registration process initiated by the MagicLink application module to the WiFi link module is the same, avoiding redundant code logic.

[0293] For example, such as Figure 7C As shown, channel 1 is used for information exchange between the MagicLink application modules of different devices (the MagicLink application module of mobile phone A and the MagicLink application module of tablet B). Channel 3 is used for communication (information exchange) between the WiFi link module and the MagicLink application module of the new version device.

[0294] 716. The MagicLink application module of mobile phone A initiates a connection call to the WiFi link module of mobile phone A, passing in the MagicLink protocol version and service QoS information of the peer device.

[0295] The MagicLink protocol version of the peer device (Tablet B) can be an older version.

[0296] 717. The WiFi link module of mobile phone A generates data packet 21.

[0297] If the WiFi link module of mobile phone A determines that the MagicLink protocol version of the peer device is an older version (i.e., the peer device is an older version device), it can discard the QoS information of the service and generate data packet 21 (first data packet) based on the WiFi capability information of mobile phone A. The first data packet can be used to request the establishment of a WiFi P2P connection with tablet B. The format of data packet 21 can be determined based on the data processing protocol of channel 3 (first data processing protocol); for example, data packet 21 can be in key-value format. Data packet 21 includes the WiFi capability information of mobile phone A.

[0298] In some embodiments, when the peer device uses an older version of the MagicLink protocol (i.e., the peer device is an older version device), the WiFi capability information of mobile phone A includes information about one idle WiFi network card (e.g., the first WiFi network card). This is because older version devices can only recognize one WiFi network card, while newer version devices typically include multiple WiFi network cards. If the information of multiple WiFi network cards is directly sent to the older version device, the older version device cannot recognize the multiple WiFi network cards, leading to compatibility issues. Therefore, mobile phone A (the newer version device) can select one idle WiFi network card and encapsulate its information in data packet 21 before sending it to the peer device (the older version device). In other words, mobile phone A (the newer version device) can disguise itself as an older protocol device with only a single WiFi network card, allowing the older version device to function normally and avoiding compatibility issues.

[0299] In one possible implementation, the WiFi link module selects an idle P2P network card (the network card used for P2P communication) in the following way: the WiFi link module sequentially probes whether the first WiFi network card (e.g., WiFi network card 1) and the second WiFi network card (e.g., WiFi network card 2) are available (i.e., whether they are idle). If the first WiFi network card is available, a WiFi P2P connection is established directly using the first WiFi network card; if the first WiFi network card is unavailable, the module then checks whether the second WiFi network card is available. If the second WiFi network card is available, a WiFi P2P connection is established using the second WiFi network card. Of course, if the device (e.g., tablet B) also includes more WiFi network cards (e.g., a third WiFi network card), the probe can continue until an available WiFi network card is detected.

[0300] Optionally, data packet 21 may also include other information, such as the local P2P role (expected role), channel capability, device type, device ID, etc.

[0301] 718a. The WiFi link module of mobile phone A calls channel 3 and sends in data packet 21.

[0302] 718b. The MagicLink application module of mobile phone A does not need to add a MagicLink header to data packet 21.

[0303] The MagicLink application module of mobile phone A receives data packets (e.g., data packet 21) from the WiFi link module through channel 3. Since the data processing protocol corresponding to channel 3 is the first data processing protocol, and the data packet format corresponding to the first data processing protocol is key-value format, the MagicLink application module of mobile phone A does not need to add a MagicLink header to data packet 21.

[0304] 718c, The MagicLink application module of mobile phone A sends data packet 21 through channel 1.

[0305] 719. The MagicLink application module of tablet B receives data packet 21 from channel 1 and parses data packet 21.

[0306] It should be understood that a channel 1 is established between tablet B (older version device) and mobile phone A (newer version device). The data processing protocol corresponding to channel 1 is the first data processing protocol. Therefore, the MagicLink application module of tablet B (older version device) can directly parse data packet 21 (key-value format data packet) based on the first data processing protocol.

[0307] The MagicLink application module of tablet B can obtain the WiFi capability information of the other device (phone A) by parsing data packet 21.

[0308] like Figure 7B As shown, the method also includes:

[0309] 720. The MagicLink application module of tablet B generates data packet 22.

[0310] In some embodiments, the MagicLink application module of tablet B can generate data packet 22 (third data packet) based on the WiFi capability information of tablet B, that is, data packet 22 includes the WiFi capability information of tablet B.

[0311] In other embodiments, the MagicLink application module of tablet B can determine the WiFi P2P connection configuration information based on the WiFi capability information of the peer device (phone A) and its own (tablet B). It then generates data packet 22 (the third data packet) based on the WiFi P2P connection configuration information, meaning data packet 22 includes the WiFi P2P connection configuration information. This WiFi P2P connection configuration information includes P2P communication roles (GO and GC), channel information, etc. In this way, tablet B directly determines the WiFi P2P connection configuration information, eliminating the need to send tablet B's WiFi capability information to phone A, which then determines the WiFi P2P connection configuration information. This saves communication overhead and makes the WiFi P2P connection method simpler and more efficient.

[0312] 721. The MagicLink application module of tablet B sends data packet 22 to mobile phone A through channel 1.

[0313] 722. The MagicLink application module of mobile phone A receives data packet 22 through channel 1.

[0314] 723. The MagicLink application module of mobile phone A sends data packet 22 to the WiFi link module of mobile phone A.

[0315] The MagicLink application module of mobile phone A does not need to strip the header of data packet 22 and directly sends data packet 22 to the WiFi link module of mobile phone A.

[0316] 724. The WiFi link module of mobile phone A parses data packet 22, determines the WiFi P2P connection configuration information, and creates GO based on the WiFi P2P connection configuration information.

[0317] In some embodiments, data packet 22 includes WiFi capability information of tablet B. The WiFi link module of mobile phone A can parse data packet 22 to obtain the WiFi capability information of tablet B. Based on the WiFi capability information of the peer device (tablet B) and the local device (mobile phone A), the WiFi link module of mobile phone A can determine WiFi P2P connection configuration information and create a GO based on the WiFi P2P connection configuration information.

[0318] In other embodiments, data packet 22 includes WiFi P2P connection configuration information decided by tablet B. The WiFi link module of mobile phone A can parse data packet 22 to obtain the WiFi P2P connection configuration information and create a GO based on it.

[0319] The WiFi P2P connection configuration information includes the roles (GO and GC) of P2P communication, the network card, channel, antenna, and other information used for P2P communication.

[0320] For example, the WiFi P2P connection configuration information can be: mobile phone A as GO, tablet B as GC, and the P2P channel is established on a 5G channel (e.g., channel with a frequency of 5805MHz and channel number 161). Mobile phone A can create GO based on the WiFi P2P connection configuration information.

[0321] Furthermore, after phone A creates the GO, phone A can also perform the following steps:

[0322] 725a. The WiFi link module of mobile phone A sends the IP address and network card name of the local device (GO device) to the MagicLink application module of mobile phone A.

[0323] 725b. After receiving the IP address and network card name, the MagicLink application module of mobile phone A starts listening on the TCP port.

[0324] 725c, The MagicLink application module of mobile phone A sends the local IP and TCP port to the WiFi link module of mobile phone A.

[0325] 726a. The WiFi link module of mobile phone A encapsulates the local IP, TCP port and local (GO device) connection information into data packet 23 (fourth data packet).

[0326] 726b. The WiFi link module of mobile phone A calls channel 3 and sends in data packet 23.

[0327] The IP and TCP ports of the peer (phone A) are used to establish a negotiation channel on the P2P platform later.

[0328] Data packet 23 is used for GC and GO to establish a WiFi P2P connection.

[0329] 727a. The MagicLink application module of mobile phone A does not need to add a MagicLink header to data packet 23.

[0330] The MagicLink application module of mobile phone A receives data packets (e.g., data packet 23) from the WiFi link module through channel 3. Since the data processing protocol corresponding to channel 3 is the first data processing protocol, and the data packet format corresponding to the first data processing protocol is key-value format, the MagicLink application module of mobile phone A does not need to add a MagicLink header to data packet 23.

[0331] 727b. The MagicLink application module of mobile phone A sends data packet 23 to the MagicLink application module of tablet computer B through channel 1.

[0332] 728. After receiving data packet 23, the MagicLink application module of tablet B parses data packet 23 to obtain the IP address, TCP port, and connection information of the peer device and the GO device.

[0333] 729. The MagicLink application module of tablet B sends the connection information of the GO device to the WiFi link module of tablet B.

[0334] The subsequent steps 730-737 can be found in the descriptions of steps 430-437.

[0335] Based on the methods provided in the embodiments of this application, such as Figures 4A-4B When establishing a WiFi P2P connection between new version devices, or, as... Figures 7A-7B When establishing a WiFi P2P connection between a new version device and an older version device, the parsing and reassembly of data packets are uniformly handled by the WiFi link module. The MagicLink application module processes data packets in a similar manner for both new and older versions, forwarding them to the peer device. The WiFi link module can encapsulate different data packets using different data processing protocols based on different versions (new or old) of the peer device's P2P transmission protocol (e.g., the MagicLink protocol). Different versions of devices can recognize data packets encapsulated using different data processing protocols, thus ensuring compatibility between the new and older versions of the device and avoiding compatibility issues.

[0336] Furthermore, having the WiFi link module uniformly manage the WiFi P2P connection between the local device (new version device) and the peer device (new version device or old version device) can avoid the conflict issues that may occur if different modules manage the WiFi P2P connection between the local device and the old version device, as well as the WiFi P2P connection between the local device and the new version device.

[0337] In this embodiment, the new version device is compatible with both the new and old versions of the MagicLink protocol, and can manage the negotiation and status of WiFi P2P connections established between multiple P2P network cards and both the new and old versions of the device. Specifically, when the peer device is an old version device, the new version device can select one idle WiFi network card from multiple idle WiFi network cards to establish a WiFi P2P connection with the peer device. That is, the new version device can disguise itself as an old protocol device with only a single WiFi network card, allowing the old version device to function normally and avoiding compatibility issues. When the peer device is a new version device, the new version device can send information about the multiple idle WiFi network cards to the peer device, enabling the peer device to make decisions about WiFi P2P connection configuration information (determining the optimal network card and channel) based on this information, thus improving the WiFi P2P communication quality.

[0338] like Figure 8A As shown in the illustration, this application provides a WiFi P2P connection method, using mobile phone A as an older version device and tablet B as a newer version device as an example. The method includes the following steps:

[0339] Steps 801-804 can be referred to the relevant descriptions of steps 401-404. Steps 805-807 can be referred to the relevant descriptions of steps 405b-407b.

[0340] 808. The MagicLink application module of mobile phone A and the MagicLink application module of tablet B exchange the MagicLink protocol version of the peer device.

[0341] Phone A uses an older version of the MagicLink protocol, meaning it's an older device. Tablet B uses a newer version of the MagicLink protocol, meaning it's a newer device.

[0342] Steps 809a-812 can refer to the relevant descriptions of steps 409a-412.

[0343] 813. The MagicLink application module of mobile phone A and the MagicLink application module of tablet computer B establish a negotiation channel (channel 1).

[0344] For a related description, please refer to step 413a, which will not be repeated here.

[0345] 814. The MagicLink application module of mobile phone A sends data packet 31 to the MagicLink application module of tablet computer B through channel 1. Data packet 31 is used to request the establishment of WiFi P2P connection.

[0346] The MagicLink application module of mobile phone A can generate data packet 31 and send data packet 31 to the MagicLink application module of tablet computer B based on channel 1.

[0347] The format of data packet 31 can be determined based on the data processing protocol of channel 1 (first data processing protocol). For example, data packet 31 can be in key-value format. Data packet 31 includes the WiFi capability information of mobile phone A. The WiFi capability information of mobile phone A includes information about one idle WiFi network card.

[0348] Optionally, data packet 31 may also include other information, such as the local P2P role (expected role), channel capability, device type, device ID, etc.

[0349] 815. The MagicLink application module of tablet B determines that the peer device is an older version device.

[0350] If the MagicLink protocol version of the peer device is an older version (i.e., the peer device is an older version device), the MagicLink application module of tablet B can execute steps 816 and 817.

[0351] 816. The MagicLink application module of tablet B registers an auxiliary channel (channel 3) with the WiFi link module of tablet B.

[0352] The WiFi link module registration auxiliary channel (channel 3) for tablet B can be referred to in step 715. Simply replace mobile phone A with tablet B. It will not be elaborated here.

[0353] 817a. The MagicLink application module of tablet B sends data packet 31 to the WiFi link module of tablet B.

[0354] The MagicLink application module of tablet B can send data packet 31 to the WiFi link module of tablet B through channel 3.

[0355] 817b, The WiFi link module of tablet B parses data packets 31.

[0356] 817c, The WiFi link module of tablet B generates data packet 32.

[0357] In some embodiments, the MagicLink application module of tablet B can generate data packet 32 ​​based on the WiFi capability information of tablet B, that is, data packet 32 ​​includes the WiFi capability information of tablet B.

[0358] In some embodiments, when the MagicLink protocol version of the peer device (e.g., mobile phone A) is an older version (i.e., the peer device is an older version device), the WiFi capability information of tablet B includes information about an idle WiFi network card.

[0359] In other embodiments, the MagicLink application module of tablet B can determine the WiFi P2P connection configuration information based on the WiFi capability information of the peer device (phone A) and the local device (tablet B), and generate data packet 32 ​​based on the WiFi P2P connection configuration information. That is, data packet 32 ​​includes the WiFi P2P connection configuration information. The WiFi P2P connection configuration information includes information such as the P2P communication roles (GO and GC) and channel.

[0360] The format of data packet 32 ​​can be determined based on the data processing protocol of channel 3 (first data processing protocol). For example, data packet 32 ​​can be in key-value format.

[0361] 818a. The WiFi link module of tablet B calls channel 3 and sends in data packet 32.

[0362] 818b, The MagicLink application module of tablet B does not need to add a MagicLink header to data packet 32.

[0363] The MagicLink application module of tablet B receives data packets (e.g., data packet 32) from the WiFi link module through channel 3. Since the data processing protocol corresponding to channel 3 is the first data processing protocol, and the data packet format corresponding to the first data processing protocol is key-value format, the MagicLink application module of mobile phone A does not need to add a MagicLink header to data packet 32.

[0364] The MagicLink application module of tablet B (818c) sends data packet 32 ​​through channel 1.

[0365] 819. The MagicLink application module of mobile phone A receives data packet 32 ​​from channel 1.

[0366] like Figure 8B As shown, the method also includes:

[0367] 820. The MagicLink application module of mobile phone A parses data packet 32 ​​and determines the WiFi P2P connection configuration information.

[0368] In some embodiments, data packet 32 ​​includes WiFi capability information of tablet B. The WiFi link module of mobile phone A can parse data packet 32 ​​to obtain the WiFi capability information of tablet B. Based on the WiFi capability information of the peer device (tablet B) and the local device (mobile phone A), the WiFi link module of mobile phone A can determine WiFi P2P connection configuration information and create a GO based on the WiFi P2P connection configuration information.

[0369] In other embodiments, data packet 32 ​​includes WiFi P2P connection configuration information decided by tablet B. The WiFi link module of mobile phone A can parse data packet 32 ​​to obtain the WiFi P2P connection configuration information and create a GO based on this information.

[0370] The WiFi P2P connection configuration information includes the roles (GO and GC) of P2P communication, the network card, channel, antenna, and other information used for P2P communication.

[0371] In one possible implementation, the method (policy) by which the MagicLink application module of mobile phone A determines the WiFi P2P connection configuration information can be as follows: when the device types of both ends are the same, the initiating end is GO; when one end device is already GO, GO is reused; when one end device can only be GO, this device is selected as GO.

[0372] In some embodiments, an older device (e.g., mobile phone A) can be used as the GO, and a newer device (e.g., tablet B) can be used as the GC.

[0373] For example, the WiFi P2P connection configuration information can be: mobile phone A as GO, tablet B as GC, and the P2P channel is established on a 5G channel (e.g., channel with a frequency of 5805MHz and channel number 161). Mobile phone A can create GO based on the WiFi P2P connection configuration information.

[0374] 821. The MagicLink application module of mobile phone A sends WiFi P2P connection configuration information to the WiFi link module of mobile phone A.

[0375] 822. Mobile phone A's WiFi link module creates GO based on WiFi P2P connection configuration information.

[0376] Furthermore, after phone A creates the GO, phone A can also perform the following steps:

[0377] 823. The WiFi link module of mobile phone A sends the local (GO device) IP, network card name and GO connection information to the MagicLink application module of mobile phone A.

[0378] 824. After receiving the IP address and network card name, the MagicLink application module of mobile phone A starts listening on the TCP port.

[0379] 825. The MagicLink application module of mobile phone A encapsulates the local IP, TCP port and local (GO device) connection information into a data packet 33.

[0380] The IP and TCP ports of the peer (phone A) are used to establish a negotiation channel on the P2P platform later.

[0381] Data packet 33 is used for GC and GO to establish a WiFi P2P connection.

[0382] 826. The MagicLink application module of mobile phone A sends data packet 33 to the MagicLink application module of tablet computer B through channel 1.

[0383] 827. The MagicLink application module of tablet B parses data packet 33 to obtain the IP and TCP port of the peer device.

[0384] 828. The MagicLink application module of tablet B does not need to strip the MagicLink packet header to send data packet 33 to the WiFi link module of tablet B.

[0385] 829. The WiFi link module of tablet B parses data packet 33 to obtain the connection information of the GO device.

[0386] The subsequent steps 830-837 can be found in the descriptions of steps 430-437.

[0387] Based on the methods provided in the embodiments of this application, such as Figures 4A-4B When establishing a WiFi P2P connection between new version devices, or, as... Figures 8A-8B When establishing a WiFi P2P connection between a new version device and an older version device, the parsing and reassembly of data packets are uniformly handled by the WiFi link module. The MagicLink application module processes data packets in a similar manner for both new and older versions, forwarding them to the peer device. The WiFi link module can encapsulate different data packets using different data processing protocols based on different versions (new or old) of the peer device's P2P transmission protocol (e.g., the MagicLink protocol). Different versions of devices can recognize data packets encapsulated using different data processing protocols, thus ensuring compatibility between the new and older versions of the device and avoiding compatibility issues.

[0388] One embodiment of this application provides a chip system, such as... Figure 9 As shown, the chip system includes at least one processor 901 and at least one interface circuit 902. The processor 901 and the interface circuit 902 are interconnected via lines. For example, the interface circuit 902 can be used to receive signals from other devices (e.g., the memory of a first electronic device (e.g., tablet B) or the memory of a second electronic device (e.g., mobile phone A)). As another example, the interface circuit 902 can be used to send signals to other devices (e.g., the processor 901).

[0389] For example, interface circuit 902 can read instructions stored in the memory of the device and send those instructions to processor 901. When the instructions are executed by processor 901, they can cause a first electronic device or a second electronic device (such as...) to... Figure 1 The electronic device 100 shown executes the steps in the above embodiments.

[0390] Of course, the chip system may also include other discrete components, and this application does not specifically limit this.

[0391] Other embodiments of this application provide a first electronic device (such as...) Figure 1 The illustrated electronic device 100 may include a communication module, a memory, and one or more processors. The communication module and memory are coupled to the processors. The memory stores computer program code, including computer instructions.

[0392] Other embodiments of this application provide a second electronic device (such as...) Figure 1 The illustrated electronic device 100 may include a communication module, a memory, and one or more processors. The communication module and memory are coupled to the processors. The memory stores computer program code, including computer instructions.

[0393] This application embodiment also provides a computer-readable storage medium, which includes computer instructions, and the computer instructions are used in a first electronic device (such as...) Figure 1 When the computer instructions are executed on the second electronic device (e.g., tablet computer B), the electronic device 100 performs the various functions or steps performed by the first electronic device (e.g., tablet computer B) in the above method embodiment. Figure 1 When the electronic device 100 shown is run, it causes the electronic device 100 to perform the various functions or steps performed by the second electronic device (e.g., mobile phone A) in the above method embodiment.

[0394] This application also provides a computer program product that, when run on a computer, causes the computer to perform various functions or steps performed by the first electronic device (e.g., tablet B) or the second electronic device (e.g., mobile phone A) in the above method embodiments.

[0395] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0396] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0397] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0398] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks. The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A WiFi P2P connection method, characterized in that, Applied to a first electronic device, the method includes: The first electronic device obtains the version of the peer-to-peer (P2P) transmission protocol of the second electronic device; When the version of the P2P transmission protocol is version 1, the first electronic device encapsulates the first data packet using the first data processing protocol and sends the first data packet to the second electronic device; the first data packet is used to request the establishment of a WiFi P2P connection with the second electronic device. When the P2P transmission protocol is version 2, the first electronic device encapsulates the second data packet using the second data processing protocol and sends the second data packet to the second electronic device; the second data packet is used to request the establishment of a WiFi P2P connection with the second electronic device; the second data processing protocol is different from the first data processing protocol.

2. The method according to claim 1, characterized in that, The first data packet includes WiFi capability information of the first electronic device, and the WiFi capability information of the first electronic device includes information of the first WiFi network card; The second data packet includes WiFi capability information of the first electronic device, which includes information about the first WiFi network card and the second WiFi network card.

3. The method according to claim 1, characterized in that, The first electronic device includes a first module and a second module. The version of the peer-to-peer (P2P) transmission protocol obtained by the first electronic device from the second electronic device includes: The first module receives the P2P transmission protocol version of the second electronic device; The first module sends the P2P transmission protocol version of the second electronic device to the second module; The first electronic device encapsulates the first data packet using a first data processing protocol, including: The second module encapsulates the first data packet using the first data processing protocol; The first electronic device encapsulates the second data packet using the second data processing protocol, including: The second module encapsulates the second data packet using the second data processing protocol.

4. The method according to claim 3, characterized in that, When the P2P transmission protocol is version one, before the first electronic device encapsulates the first data packet using the first data processing protocol, the method further includes: The first module establishes a first communication channel with the second electronic device; the first communication channel is used to transmit information between the first module and the second electronic device. The first module registers a second communication channel with the second module; The first module sends the version of the P2P transmission protocol to the second module; Sending the first data packet to the second electronic device includes: The second module invokes the second communication channel to send the first data packet to the first module; The first module sends the first data packet to the second electronic device through the first communication channel.

5. The method according to claim 4, characterized in that, The data processing format for the first communication channel and the second communication channel is a key-value pair format.

6. The method according to claim 3, characterized in that, When the P2P transmission protocol is version 2, before the first electronic device encapsulates the second data packet using the second data processing protocol, the method further includes: The first module establishes a third communication channel with the second electronic device; the third communication channel is used to transmit information between the second module and the second electronic device. The first module registers the third communication channel with the second module; Sending the second data packet to the second electronic device includes: The second module invokes the third communication channel to send the second data packet to the first module; The first module sends the second data packet to the second electronic device through the third communication channel.

7. The method according to claim 6, characterized in that, The data packets transmitted in the third communication channel are in TLV format; wherein, T in TLV indicates the type of receiving module corresponding to the data packet; V in TLV represents the actual value carried in the data packet; and L in TLV represents the length of the actual value.

8. The method according to any one of claims 4-7, characterized in that, The method further includes: The first module receives a third data packet from the second electronic device; the third data packet includes WiFi P2P connection configuration information; the WiFi P2P connection configuration information is used to indicate the network card for WiFi P2P connection and the device acting as the manager GO. The first module sends the third data packet to the second module; The second module parses the third data packet to obtain the WiFi P2P connection configuration information.

9. The method according to any one of claims 4-7, characterized in that, The method further includes: The first module receives a third data packet from the second electronic device; the third data packet includes WiFi capability information of the second electronic device; The first module sends the third data packet to the second module; The second module parses the third data packet to obtain the WiFi capability information of the second electronic device; The second module determines the WiFi P2P connection configuration information based on the WiFi capability information of the second electronic device and the WiFi capability information of the first electronic device; the WiFi P2P connection configuration information is used to indicate the network card for WiFi P2P connection and the device acting as the manager GO.

10. The method according to claim 8 or 9, characterized in that, The method further includes: The second module sends the Internet Protocol (IP) address and network interface card (NIC) name of the first electronic device to the first module; The first module listens on the Transmission Control Protocol (TCP) port; The first module sends the TCP port to the second module; The second module encapsulates a fourth data packet, which includes the IP address, TCP port, and connection information of the first electronic device as a GO device; The second module invokes the second communication channel to send the fourth data packet to the first module; The first module sends the fourth data packet to the second electronic device through the first communication channel.

11. The method according to claim 10, characterized in that, The method further includes: The second module establishes a WiFi P2P connection with the second electronic device based on the connection information of the device acting as GO.

12. The method according to claim 11, characterized in that, The method further includes: The first module creates a secure TCP channel based on the WiFi P2P connection to the second electronic device based on the IP and TCP port of the first electronic device.

13. A first electronic device, characterized in that, The first electronic device includes: a wireless communication module, a memory, and one or more processors; the wireless communication module, the memory, and the processors are coupled together. The memory is used to store computer program code, which includes computer instructions; when the computer instructions are executed by the processor, the first electronic device performs the method as described in any one of claims 1-12.

14. A computer-readable storage medium, characterized in that, Includes computer instructions; When the computer instructions are executed on the first electronic device, the first electronic device causes the first electronic device to perform the method as described in any one of claims 1-12.

Images