Preset path selection method, electronic device, and system

Abstract

Provided in the present application are a preset path selection method, an electronic device, and a system. The method comprises: on the basis of a first service scenario in which a first terminal is located on a first route, determining first preset path information from among a plurality of pieces of preset path information of the first route, wherein the first preset path information comprises a first cell handover list of the first route, and the first cell handover list comprises information of a plurality of cells; and the first terminal performing a cell handover on the first route on the basis of the first cell handover list. By means of the present application, occurrences of poor call quality and data service lag when a terminal travels along a fixed route can be reduced.

Description

A preset path selection method, electronic device and system

[0001] This application claims priority to Chinese Patent Application No. 202411631088.7, filed on November 14, 2024, entitled "A Preset Path Selection Method, Electronic Device and System", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer technology, and in particular to a preset path selection method, electronic device and system. Background Technology

[0003] In scenarios involving rapid travel such as high-speed rail, highways, and subways, users frequently experience network switching, delayed network switching, no network switching, and network rebuilding due to the high speed of movement. This can prevent users from using terminal applications normally when traveling along these fixed routes, resulting in poor call quality (such as dropped calls and poor voice quality) and data service lag (such as video playback lag), thus affecting the user experience. Summary of the Invention

[0004] This application discloses a preset path selection method, electronic device and system, which can reduce the poor call quality and data service lag that occur when the terminal travels through a fixed route.

[0005] In a first aspect, embodiments of this application provide a preset path selection method applied to a first terminal. The method includes: determining first preset path information from multiple preset path information of the first route based on a first service scenario in which the first terminal is located on a first route, wherein the first preset path information includes a first cell handover list of the first route, and the first cell handover list includes information of multiple cells; and the first terminal performs cell handover on the first route based on the first cell handover list.

[0006] In the above method, when the first terminal travels along the first route, it can determine the matching first preset path information from multiple preset path information based on the current first service scenario, and switch to the cell that provides wireless communication services to the first terminal based on the first cell handover list, i.e., perform cell handover. The first service scenario can include call services and / or data services, and data services include, but are not limited to, video services, conferencing services, and live streaming services. In this approach, the first terminal can determine the first preset path information that matches its actual service scenario, thereby reducing poor call quality and data service lag caused by frequent cell handovers when the first terminal is in the current service scenario, thus improving the user experience.

[0007] In one possible implementation, the multiple preset path information is calculated by the cloud server based on the cost value, and the cost value corresponding to any one of the multiple preset path information is less than a preset threshold.

[0008] In the above method, the multiple preset path information can be obtained by the cloud server based on the cost value of each line on the first route. The cost value corresponding to any preset path information is less than a preset threshold. For example, the line with the lowest cost value is taken as the preset path. The cost value can be used to characterize the quality of the line; the smaller the cost value, the better the line. Therefore, the determined multiple preset path information are all globally optimal preset paths, such as globally optimal preset paths under different business scenarios.

[0009] In one possible implementation, the method further includes: receiving multiple preset path information of the first route sent by the cloud server.

[0010] In the above method, multiple preset path information can be sent from the cloud server to the first terminal. The first terminal can receive multiple preset path information sent by the cloud server when needed, such as when it is on the first route. This reduces the data transmission and communication between the first terminal and the cloud server, saves data transmission bandwidth, and also reduces the storage pressure on the first terminal, ensuring that the first terminal can obtain the latest and most accurate optimal preset path information.

[0011] In one possible implementation, the first preset path information includes the first cell handover list and the corresponding first service information, wherein the first service information indicates a second service scenario applied to the first cell handover list, and the second service scenario matches the first service scenario.

[0012] In the above method, the first preset path information may include a first cell handover list and corresponding first service information. The first service information may indicate a second service scenario applicable to the first cell handover list, enabling the first terminal to determine the first preset path information matching the first service scenario from multiple preset path information options. For example, when the first terminal is in a video service scenario, it can select the optimal preset path for the video service from multiple preset path information options. This reduces poor call quality and data service lag when the first terminal is in the current service scenario, improving the user experience.

[0013] In one possible implementation, the first service information indicates the application effect of the first cell handover list in the second service scenario.

[0014] In the above method, the first service information can also indicate the application effect of the first cell handover list in the second service scenario, such as comprehensive service optimal (indicating that the first cell handover list is the optimal preset path applied to the comprehensive service scenario) and call service optimal (indicating that the first cell handover list is the optimal preset path applied to the call service scenario). This ensures that the selected first preset path information is the globally optimal preset path, reducing poor call quality and data service lag on the first terminal, and improving the user experience.

[0015] In one possible implementation, the first preset path information includes the first cell handover list and the corresponding first cell handover method information. The first terminal performs cell handover based on the first cell handover list on the first route, including: when the first terminal is on the first route and in the first service scenario, it performs cell handover based on the first cell handover list and the first cell handover method information.

[0016] In the above method, the handover method information of the first cell can include the handover methods between cells in the first cell handover list, such as handover, redirection, reconstruction, and reselection. When the first terminal is traveling on the first route and is currently in the first service scenario, it can perform cell handover based on the first cell handover list and the handover methods between cells.

[0017] In one possible implementation, the method further includes: when the first terminal is on the first route and in a third service scenario, the first terminal determines second preset path information from multiple preset path information of the first route, the second preset path information including a second cell handover list of the first route and corresponding second service information, the second service information indicating a fourth service scenario applied to the second cell handover list, the fourth service scenario matching the third service scenario; the first terminal performs cell handover on the first route based on the second cell handover list.

[0018] In the above method, when the service scenario of the first terminal changes during its journey along the first route, for example, when it enters a third service scenario, the first terminal can re-determine a second preset path that matches the current third service scenario from multiple preset path information. That is, it re-determines a new cell handover list (i.e., the second cell handover list) based on the changed service scenario (i.e., the third service scenario) and performs cell handover based on the new cell handover list. In this approach, the first terminal can continuously adjust the preset path according to the real-time service scenario, reducing poor call quality and data service lag caused by frequent cell handovers regardless of the service scenario it is in, thereby improving the user experience.

[0019] In one possible implementation, the method further includes: sending a first request message to a cloud server, the first request message including the scene where the first terminal is located and / or the first route, the first request message being used to request multiple preset path information of the scene where the first terminal is located and / or the first route.

[0020] In the above method, the first terminal can send a first request message to the cloud server, for example, when the first terminal is about to travel to the first route, and / or when the first terminal predicts that it will need to travel to the first route, and / or when the first terminal triggers a system upgrade, etc. The first terminal can send the first request message to the cloud server according to the actual scenario and needs, reducing the frequency of the cloud server sending multiple preset path information to the first terminal, reducing the data transmission and communication between the first terminal and the cloud server, saving data transmission bandwidth, and also reducing the storage pressure on the first terminal, ensuring that the first terminal can obtain the latest and most accurate optimal preset path information.

[0021] In one possible implementation, the method further includes: sending crowdsourced data obtained while traversing the first route to a cloud server, wherein the crowdsourced data includes at least one of the following: cell network information of the cell where the first terminal is located, and inter-cell network information, wherein the cell network information includes at least one of the following: cell information, cell lag information, and cell call drop information, and the inter-cell network information includes at least one of the following: inter-cell handover information, inter-cell reconstruction information, inter-cell redirection information, and inter-cell reselection information, wherein the cell lag information includes lag information for different data services, and the crowdsourced data is used by the cloud server to determine multiple preset path information for the first route.

[0022] In the above method, the cloud server can receive crowdsourced data obtained by at least one terminal (including the first terminal) when it travels through the first route. When generating a preset path based on this information, the cloud server comprehensively considers various factors such as the lag information of different data services in each cell, the dropped call information of the call service, and the inter-cell network information. Therefore, the preset path generated based on this information is the global optimal solution for all cells on the first route. This can avoid the situation of switching to an isolated cell due to only considering some single information (such as cell handover information) (i.e., only considering the local optimal solution), and ensure the best global service experience on the first route.

[0023] Secondly, this application provides a preset path selection method applied to a cloud server. The method includes: sending multiple preset path information for a first route to a first terminal. The first preset path information in the multiple preset path information includes a first cell handover list for the first route. The first cell handover list includes information on multiple cells. The multiple preset path information is used by the first terminal to determine the first preset path information based on a first service scenario in which the first terminal is located on the first route. The first cell handover list is used by the first terminal to perform cell handover on the first route.

[0024] In one possible implementation, the multiple preset path information is calculated by the cloud server based on the cost value, and the cost value corresponding to any one of the multiple preset path information is less than a preset threshold.

[0025] In one possible implementation, the method further includes: receiving a first request message sent by the first terminal, the first request message including the scene where the first terminal is located and / or the first route; and sending multiple preset path information of the scene where the first terminal is located and / or the first route to the first terminal according to the first request message.

[0026] In one possible implementation, the method further includes: receiving crowdsourced data obtained by the first terminal while traversing the first route, wherein the crowdsourced data includes at least one of the following: cell network information of the cell where the first terminal is located, and inter-cell network information, wherein the cell network information includes at least one of the following: cell information, cell lag information, and cell call drop information, and the inter-cell network information includes at least one of the following: inter-cell handover information, inter-cell reconstruction information, inter-cell redirection information, and inter-cell reselection information, wherein the cell lag information includes lag information for different data services, and the crowdsourced data is used by the cloud server to determine multiple preset path information for the first route.

[0027] Thirdly, this application provides a terminal including a transceiver, a processor, and a memory, wherein the memory is used to store a computer program, and the processor calls the computer program to execute a preset path selection method in any possible implementation of the first aspect.

[0028] Fourthly, this application provides a terminal including one or more processors and one or more memories. The one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code, including computer instructions. When the one or more processors execute the computer instructions, the terminal performs a preset path selection method in any possible implementation of the first aspect described above.

[0029] Fifthly, this application provides a network device including a transceiver, a processor, and a memory, wherein the memory is used to store a computer program, and the processor invokes the computer program to execute a preset path selection method in any possible implementation of the second aspect.

[0030] Sixthly, this application provides a computer storage medium storing a computer program that, when executed by a processor, implements a preset path selection method in any possible implementation of any of the above aspects.

[0031] In a seventh aspect, this application provides a computer program product that, when run on a terminal, causes the terminal to execute a preset path selection method in any possible implementation of the first aspect described above.

[0032] Eighthly, this application provides a terminal that includes the method or apparatus described in any implementation of the first aspect of this application. The terminal may be, for example, a chip.

[0033] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single embodiment. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one embodiment. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this specification do not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and beneficial effects described in this embodiment can be combined in any suitable manner. Those skilled in the art will understand that an embodiment can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular embodiment. In other embodiments, additional technical features and beneficial effects may be identified in specific embodiments that do not embody all embodiments. Attached Figure Description

[0034] The following describes the accompanying drawings used in this application.

[0035] Figure 1 is a schematic diagram of cell handover in a high-speed driving scenario provided in this application;

[0036] Figure 2 is a schematic diagram of a preset path in a high-speed driving scenario provided in this application;

[0037] Figure 3 is a schematic diagram of the architecture of a preset path selection system 10 provided in this application;

[0038] Figure 4 is a schematic diagram of the hardware structure of a terminal 100 provided in this application;

[0039] Figure 5 is a structural schematic diagram of a terminal 100 provided in this application;

[0040] Figure 6 is a structural schematic diagram of a cloud server 200 provided in this application;

[0041] Figure 7 is a flowchart illustrating a preset path selection method provided in this application;

[0042] Figure 8 is a schematic diagram of a preset path provided in this application;

[0043] Figure 9 is a flowchart illustrating a simulation process provided in this application;

[0044] Figure 10 is a schematic diagram of the structure of a probability graph provided in this application;

[0045] Figure 11 is a schematic diagram of another probability diagram provided in this application. Detailed Implementation

[0046] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0047] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0048] Currently, in high-speed rail, highway, and subway systems, when users travel along fixed routes (also known as deterministic routes) using their terminals, the terminals can receive preset path information sent from the cloud. This preset path information may include a cell handover list for that fixed route, and the terminal can perform cell handover based on this information. The preset path information can be generated by the cloud based on inter-cell handover success rates, and the cell handover list may include cell identifiers, frequency bands, frequency points, etc., with each cell corresponding to a unique cell identifier.

[0049] In this embodiment of the application, a cell, also known as a cellular cell, is an area covered by a base station or a part of a base station (such as a fan antenna). A base station can cover at least one cell, and a terminal in a cell can communicate with the base station to which the cell belongs.

[0050] Optionally, the cell identifier can be a cell global identifier (CGI), and the name of the cell identifier can be different in different wireless communication systems. For example, in Long Term Evolution (LTE), the cell identifier is called the Evolved Universal Mobile Telecommunications System CGI (E-UTRAN CGI). In New Radio (NR), the cell identifier is called the New Radio Cell Global Identifier (NCGI).

[0051] In this embodiment, cell handover refers to the change of a cell providing wireless communication services to a terminal from one cell to another. The methods by which a cell changes from one cell to another (which can be referred to as inter-cell interoperability) can include: handover, redirection, reconstruction, reselection, etc. The cell handover list can refer to a list of cell changes.

[0052] Please refer to Figure 1, which illustrates a schematic diagram of cell handover in a fast-moving scenario. The scenario shown in Figure 1 may include terminal 100 and base station 110, wherein:

[0053] Terminal 100 can be a device with wireless communication capabilities. Optionally, terminal 100 can also be user equipment (UE), mobile station, access terminal, user agent, etc. For example, the terminal can be a mobile phone, tablet computer, desktop, laptop, notebook computer, ultra-mobile personal computer (UMPC), handheld computer, netbook, personal digital assistant (PDA), wearable electronic device (smart bracelet, smart glasses, etc.), smart screen, etc.

[0054] Base station 110 is a device deployed in a radio access network (RAN) to provide wireless communication functions. The name of a base station may differ in different RAN systems. For example, but not limited to, it may be a node B (NB) in wideband code division multiple access (WCDMA), an evolved node B (eNodeB) in long term evolution (LTE), a next-generation base station (g node B (gNB) in 5th generation mobile networks (5G), i.e., new radio (NR), or a base station in other future network systems.

[0055] As shown in Figure 1, terminal 100 can be located on a high-speed train traveling at high speed. Multiple base stations 110 can exist along this train line, each corresponding to a cell. When terminal 100 is within a cell covered by base station 110, terminal 100 can connect and communicate with that base station 110. The base station 110 can provide wireless communication functionality to terminal 100.

[0056] When terminal 100 travels along a high-speed rail line, cell handover may occur. In some examples, the preset path information of terminal 100 is determined based on the inter-cell handover success rate, and terminal 100 can perform cell handover based on this preset path information. For example, when terminal 100 is at location 1, cell handover may occur, and the cell providing wireless communication services to terminal 100 can switch from cell 1 to cell 2. Terminal 100 can disconnect from base station 110 in cell 1 and establish a connection and communication with base station 110 in cell 2. Subsequently, terminal 100 can continue traveling along the high-speed rail route. When terminal 100 passes through location 2, since the handover success rate between cell 2 and cell 3 is greater than the handover success rate between cell 2 and cell 4, switching from cell 2 to cell 3 is determined to be the optimal solution, and switching from cell 2 to cell 4 is determined to be the suboptimal solution. Terminal 100 can choose cell 3 as the next hop as the optimal solution; that is, when terminal 100 is at location 2, the cell providing wireless communication services to terminal 100 can switch from cell 2 to cell 3. Cell 3 is an isolated cell (i.e., a cell without a previous hop and / or next hop cell). Since there is no next hop cell in Cell 3, when terminal 100 is traveling along the high-speed rail line and is at the boundary of Cell 3, it cannot switch to another cell because there is no next hop cell. After leaving Cell 3, before reaching a new cell (e.g., Cell 5), terminal 100 is in a coverage hole area, meaning no cell provides wireless communication service. Terminal 100 cannot access the network, resulting in network drop and data service interruption. Subsequently, when terminal 100 passes through location 3, it can establish a connection and communication with base station 110 in Cell 5. At this time, Cell 5 provides wireless communication service to terminal 100, and then it can switch from Cell 5 to Cell 6.

[0057] Furthermore, when terminal 100 travels rapidly on the high-speed railway line, it will frequently move between multiple cells in a short period of time due to its high speed. This will result in frequent network switching (e.g., switching from cell 1 to cell 2 and then immediately switching from cell 2 to cell 3), untimely network switching (e.g., arriving at cell 3 before having time to switch from cell 1 to cell 2), and network reconstruction (e.g., when moving from cell 1 to cell 2, terminal 100 fails to establish a connection and communication with the base station in cell 2 in a timely manner). These issues lead to poor call quality (e.g., dropped calls) and data service lag (e.g., video playback lag), affecting the user's normal use of the terminal and resulting in a poor user experience.

[0058] Furthermore, this method of cell handover based on inter-cell handover success rate only considers the optimal next-hop cell of the current cell. For example, the current cell may be switched to the next-hop cell with the highest handover success rate, but it may be switched to an isolated cell. In this case, a complete cell handover list for the high-speed rail line cannot be obtained, which means that the terminal cannot obtain wireless communication services for a period of time after leaving the isolated cell. Understandably, this method only considers the local optimal solution of the cell and cannot generate the global optimal solution for the entire high-speed rail line.

[0059] This application proposes a preset path selection method applied to a preset path selection system. This system may include a terminal and a cloud server. In a high-speed driving scenario, the terminal can receive multiple preset path information for a fixed route from the cloud server. These preset path information may include multiple cell handover lists (referred to as preset paths) and corresponding service information. The service information may indicate the applicable service scenario for the corresponding preset path, and optionally, indicate the application effect of the corresponding preset path in that service scenario. Examples include optimal overall service (indicating the corresponding preset path is the optimal preset path for an overall service scenario), suboptimal overall service, optimal call service, optimal video service, etc. The terminal can determine a matching first preset path information (including the first preset path) from the multiple preset path information based on the current service scenario, and perform cell handover based on the first preset path. The service scenario may include call service and / or data service scenarios. Data services include, but are not limited to, video services, conferencing services, and live streaming services. In this approach, the terminal can determine a first preset path that matches its actual business scenario and perform cell handover based on the first preset path. Optionally, when the business scenario of the terminal changes, the terminal can re-determine a new preset path. This can be understood as the terminal continuously adjusting the preset path according to the real-time business scenario, so that the terminal can reduce poor call quality and data service lag caused by frequent cell handover, regardless of the business scenario, thereby improving the user experience.

[0060] The multiple pre-defined path information is determined by the cloud server based on crowdsourced data of fixed routes sent by at least one terminal. This crowdsourced data may include cell network information and inter-cell network information (including inter-cell handover information). Cell network information may include cell lag information and cell call drop information. Cell lag information may include lag information of different data services. When generating pre-defined paths based on this information, the cloud server not only considers inter-cell handover information (such as inter-cell handover success rate), but also comprehensively considers various factors such as lag information of different data services and call drop information of each cell. Therefore, the pre-defined path generated in this way is the globally optimal solution for all cells on the fixed route, which can avoid switching to isolated cells or cells with poor network performance, and ensure the best global service experience on the fixed route.

[0061] A schematic diagram of the preset path generated based on the embodiments of this application can be seen in Figure 2.

[0062] Please refer to Figure 2, which exemplarily illustrates a pre-set path in a high-speed travel scenario. The high-speed rail route shown in Figure 2 can be the same as the high-speed rail route shown in Figure 1, but the pre-set path used is different. As shown in Figure 2, when terminal 100 passes through location 2, from a local perspective, although the handover success rate between cell 2 and cell 4 is lower than that between cell 2 and cell 3, from a global perspective, the relevant parameters of cell 4 are better than those of cell 3. For example, cell 4 is not an isolated cell, while cell 3 is an isolated cell. Therefore, the cell providing wireless communication services to terminal 100 can be switched from cell 2 to cell 4, then from cell 4 to cell 5, and finally from cell 5 to cell 6. That is, the optimal handover path for terminal 100 can be: cell 1, cell 2, cell 4, cell 5, and cell 6. This ensures that at multiple locations on the high-speed rail route where cell handover is required, a successful handover to the next-hop cell can be achieved, reducing poor call quality and data service lag caused by cell handover on the high-speed rail route. This ensures stable network performance of the terminal during high-speed rail travel, allowing users to use the terminal normally and thus improving the user experience.

[0063] The following describes a preset path selection system 10 based on an embodiment of this application.

[0064] Figure 3 illustrates an exemplary architecture diagram of a preset path selection system 10.

[0065] As shown in Figure 3, the preset path selection system 10 may include a terminal 100, a cloud server 200, and one or more base stations 300. The terminal 100 can communicate with the cloud server 200 via wired (e.g., universal serial bus, twisted pair, coaxial cable, and fiber optic cable) and / or wireless (e.g., wireless local area networks (WLAN), Bluetooth, and cellular communication networks). The terminal 100 can communicate with one or more base stations 300 via wired and / or wireless means. Wherein:

[0066] Terminal 100 can be a device with wireless communication capabilities. Optionally, terminal 100 can also be user equipment (UE), mobile station, access terminal, user agent, etc. For example, the terminal can be a mobile phone, tablet computer, handheld computer, desktop computer, laptop computer, ultra-mobile personal computer (UMPC), netbook, cellular phone, personal digital assistant (PDA), as well as smart home devices such as smart TVs and smart cameras, wearable devices such as smart bracelets, smartwatches, and smart glasses, extended reality (XR) devices such as augmented reality (AR), virtual reality (VR), and mixed reality (MR), in-vehicle devices, or smart city devices. This application embodiment does not impose special restrictions on the specific type of terminal 100.

[0067] The cloud server 200 may include at least one server. In one embodiment, any server may be a hardware server; in another embodiment, any server may be a cloud server. In one embodiment, the cloud server 200 may be a Linux server, a Windows server, or other server equipment that can provide simultaneous access for multiple devices. In one embodiment, the cloud server 200 may be a server cluster composed of multiple regions, multiple data centers, and multiple servers.

[0068] A base station 300 is a device deployed in a radio access network (RAN) to provide wireless communication functions. The name of a base station may differ in different RAN systems. For example, but not limited to, it may be a node B (NB) in Wideband Code Division Multiple Access (WCDMA), an evolved node B (eNodeB) in Long Term Evolution (LTE), a next-generation base station (g node B, gNB) in 5th generation mobile networks (5G), i.e., new radio access (NR), or a base station in other future network systems.

[0069] In one implementation, terminal 100 can establish a connection and communicate with any one of the base stations 300, and the base station with which it establishes the connection can provide wireless communication functionality to terminal 100. In another implementation, terminal 100 can cancel the connection and communication with one base station and establish a connection and communication with another base station. Understandably, terminal 100 can switch the base station it is connected to, that is, terminal 100 can switch the cell corresponding to the base station.

[0070] In one implementation, at least one terminal can send crowdsourced data of a fixed route to a cloud server 200. The cloud server 200 can generate multiple preset path information for the fixed route based on this crowdsourced data. This multiple preset path information may include multiple preset paths and corresponding service information. The cloud server 200 can send this multiple preset path information to the terminal 100, for example, the cloud server 200 can periodically send multiple preset path information to the terminal 100, or the cloud server 200 can return multiple preset path information to the terminal 100 based on a request message sent by the terminal 100. After receiving the multiple preset path information, the terminal 100 can determine a first preset path information (including the first preset path) from these multiple preset path information according to the current service scenario, and perform cell handover based on the first preset path.

[0071] In one implementation, the preset path information may include a cell handover list, which may include a cell identifier. Optionally, the cell handover list may include the base station identifier corresponding to the cell. This application embodiment uses the cell handover list including a cell identifier as an example for illustration.

[0072] Understandably, the base station 300 shown in Figure 3 can also be other network devices, such as a wireless access point (AP), a transmission and receiver point (TRP), a relay device, or other network devices with base station functions. The number and form of the terminals shown in Figure 3 are merely examples. In specific implementations, the number can be more or less. For example, the preset path selection system 10 may also include other terminals, which is not limited in this application.

[0073] The structure of the exemplary terminal provided in the embodiments of this application will be described below.

[0074] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the terminal 100. In other embodiments of this application, the terminal 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.

[0075] Figure 4 illustrates a schematic diagram of the hardware structure of a terminal 100.

[0076] As shown in Figure 4, the terminal 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

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

[0078] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0079] The processor 110 may also include a memory for storing instructions and data. In one embodiment, 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 directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0080] The charging management module 140 receives charging input from a charger, which can be either a wireless or wired charger. The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, providing power to the processor 110, internal memory 121, display screen 194, camera 193, and wireless communication module 160. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In another embodiment, the power management module 141 can also be located within the processor 110. In yet another embodiment, the power management module 141 and the charging management module 140 can be housed in the same device.

[0081] The wireless communication function of terminal 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0082] Antennas 1 and 2 are used to transmit and receive electromagnetic wave signals. Each antenna in terminal 100 can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In another embodiment, the antenna can be used in conjunction with a tuning switch.

[0083] The mobile communication module 150 can provide wireless communication solutions for applications on the terminal 100, including second-generation (2G), third-generation (3G), fourth-generation (4G), fifth-generation (5G), and sixth-generation (6G) technologies. 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. In one embodiment, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In another embodiment, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0084] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through audio devices (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In one embodiment, the modem processor may be a separate device. In another embodiment, the modem processor may be independent of the processor 110 and housed within the same device as the mobile communication module 150 or other functional modules.

[0085] The wireless communication module 160 can provide solutions for wireless communication applications on the terminal 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. 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 signals, 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.

[0086] In one embodiment, antenna 1 of terminal 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling terminal 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

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

[0088] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can 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), a miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In one embodiment, terminal 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0089] Terminal 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0090] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, transforming it into an image visible to the naked eye. The ISP can also perform algorithmic optimization on image noise, brightness, and color. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In one implementation, the ISP can be integrated into the camera 193.

[0091] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then transmitted to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In one embodiment, terminal 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0092] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the storage capacity of the terminal 100. The external storage 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 storage card.

[0093] Internal memory 121 can be used to store computer executable program code, which includes instructions. 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 playback, etc.), etc. The data storage area may store data created during the use of terminal 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of terminal 100 by running instructions stored in internal memory 121 and / or instructions stored in memory located in the processor.

[0094] Terminal 100 can implement audio functions through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0095] Audio module 170 is used to convert digital audio information into analog audio signal output, and also to convert analog audio input into digital audio signal. Audio module 170 can also be used for encoding and decoding audio signals.

[0096] The loudspeaker 170A, also known as a "loudspeaker", is used to convert audio electrical signals into sound signals.

[0097] The receiver 170B, also known as the "earpiece", is used to convert audio electrical signals into sound signals.

[0098] The microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals.

[0099] The 170D headphone jack is used to connect wired headphones.

[0100] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In one embodiment, pressure sensor 180A can be disposed on display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When force is applied to pressure sensor 180A, the capacitance between the electrodes changes. Terminal 100 determines the pressure intensity based on the change in capacitance. When a touch operation is applied to display screen 194, terminal 100 detects the intensity of the touch operation based on pressure sensor 180A. Terminal 100 can also calculate the touch position based on the detection signal from pressure sensor 180A. In one embodiment, touch operations applied to the same touch position but with different touch operation intensities can correspond to different operation commands.

[0101] The gyroscope sensor 180B can be used to determine the motion attitude of the terminal 100. In one embodiment, the angular velocity of the terminal 100 about three axes (i.e., the x, y, and z axes) can be determined by the gyroscope sensor 180B.

[0102] The 180C barometric pressure sensor is used to measure barometric pressure.

[0103] The magnetic sensor 180D includes a Hall sensor. The terminal 100 can use the magnetic sensor 180D to detect the opening and closing of the flip cover.

[0104] The accelerometer 180E can detect the magnitude of the acceleration of the terminal 100 in various directions (generally three axes).

[0105] A distance sensor 180F is used to measure distance. Terminal 100 can measure distance via infrared or laser. In one embodiment, during scene capture, terminal 100 can utilize the distance sensor 180F for distance measurement to achieve fast focusing.

[0106] The proximity sensor 180G may include, for example, a light-emitting diode (LED) and a light detector, such as a photodiode. The LED may be an infrared LED. Terminal 100 emits infrared light outward through the LED. Terminal 100 uses the photodiode to detect infrared reflected light from nearby objects. When sufficient reflected light is detected, it can be determined that there is an object near terminal 100. When insufficient reflected light is detected, terminal 100 can determine that there is no object near terminal 100.

[0107] The 180L ambient light sensor is used to detect ambient light intensity.

[0108] The fingerprint sensor 180H is used to collect fingerprints. The terminal 100 can use the characteristics of the collected fingerprints to unlock the device, access application locks, take photos with fingerprints, and answer calls with fingerprints.

[0109] The 180J temperature sensor is used to detect temperature.

[0110] Touch sensor 180K, also known as a "touch device," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of terminal 100, in a different position than display screen 194.

[0111] The bone conduction sensor 180M can acquire vibration signals.

[0112] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. Terminal 100 can receive button input and generate key signal inputs related to user settings and function control of terminal 100.

[0113] Motor 191 can generate vibration alerts. Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, messages, missed calls, notifications, etc. SIM card interface 195 is used to connect a SIM card.

[0114] Figure 5 illustrates a schematic diagram of the structure of a terminal 100.

[0115] As shown in Figure 5, the terminal 100 may include a processor 210, a memory 220 and a transceiver 230, which can be interconnected via a bus.

[0116] Processor 210 can be one or more central processing units (CPUs). If processor 210 is a CPU, it can be a single-core CPU or a multi-core CPU. Optionally, processor 210 can include one or more processing units, such as an application processor (AP) and a modem. Different processing units can be independent devices or integrated into one or more processors. In some embodiments, processor 210 can also include memory for storing instructions and data. Optionally, the memory in processor 210 is a cache memory. This memory can store instructions or data that processor 210 has just used or is repeatedly used. If processor 210 needs to reuse the instruction or data, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of processor 210, and thus improves system efficiency.

[0117] The memory 220 includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM), and is used to store related computer programs and data.

[0118] Transceiver 230 is used to receive and transmit data. Terminal 100 can communicate using wireless communication technologies and network equipment through transceiver 230. Wireless communication technologies may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies. GNSS may include GPS, Global Navigation Satellite System (GLONASS), BeiDou Navigation Satellite System (BDS), Quasi-Zenith Satellite System (QZSS), and / or Satellite Based Augmentation Systems (SBAS). In some embodiments, transceiver 230 can provide wireless communication solutions, including 2G / 3G / 4G / 5G / 6G, applied to terminal 100.

[0119] In some embodiments, the wireless communication function of terminal 100 can be implemented through transceiver 230, modem, and access point (AP). Optionally, the electromagnetic waves received by transceiver 230 can be transmitted to modem for demodulation. Optionally, the modem can transmit the demodulated low-frequency baseband signal to AP for processing. Optionally, the modem can determine the cell information of terminal 100 based on the electromagnetic waves received by transceiver 230. Optionally, the cell information may include a cell identifier.

[0120] The structure of the exemplary cloud server provided in the embodiments of this application will be described below.

[0121] Figure 6 illustrates a schematic diagram of the structure of a cloud server 200.

[0122] As shown in Figure 6, the cloud server 200 may include a processor 310, a memory 320, and a transceiver 330, which can be interconnected via a bus.

[0123] The processor 310 can be one or more central processing units (CPUs). When the processor 310 is a CPU, the CPU can be a single-core CPU or a multi-core CPU.

[0124] The memory 320 includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM), and is used to store related computer programs and data.

[0125] Transceiver 330 is used to receive and send data. Cloud server 200 can communicate via transceiver 330 using wireless communication technology and terminals. In some embodiments, transceiver 330 can provide wireless communication solutions, including 2G / 3G / 4G / 5G, applied to cloud server 200.

[0126] Optionally, the cloud server 200 can receive crowdsourcing data sent by at least one terminal via transceiver 330. Optionally, the processor 310 can determine multiple preset path information for a fixed route based on the crowdsourcing data from the terminal. Optionally, the memory 320 can store the multiple preset path information for the fixed route. Optionally, the cloud server 200 can send the multiple preset path information for the fixed route to at least one terminal via transceiver 330.

[0127] It should be noted that the cloud server 200 shown in Figure 6 is one implementation of an example embodiment of this application. In actual applications, the cloud server 200 may include more or fewer components, which is not limited here.

[0128] The following describes the preset path selection method provided in the embodiments of this application.

[0129] Please refer to Figure 7, which is a flowchart illustrating a preset path selection method provided in an embodiment of this application. The first terminal in this method can be the terminal 100 shown in Figures 3-5, and the cloud server in this method can be the cloud server 200 shown in Figures 3 and 6. This method may include, but is not limited to, the following steps:

[0130] S101: The cloud server receives crowdsourced data for the first route sent by at least one terminal.

[0131] In one implementation, the first route is, for example, a fixed route used by transportation vehicles such as high-speed rail, trains, subways, and buses, or a fixed route used by users for daily commuting. The first route may include a starting point and an ending point. Multiple base stations may exist along the first route, and each base station may correspond to one cell. Understandably, multiple cells exist along the first route. However, this is not a limitation; one base station may also correspond to multiple cells. For ease of explanation, this application embodiment uses one base station corresponding to one cell as an example for illustration.

[0132] In one implementation, the crowdsourced data may include cell network information and inter-cell network information of multiple cells along the first route. Cell network information may include cell information, cell lag information, cell call drop information, etc., while inter-cell network information may include inter-cell handover information, inter-cell reconstruction information, inter-cell redirection information, inter-cell reselection information, etc. Cell information may include cell identifiers, cell bandwidth information, and public information. Cell lag information may include lag information for different data services, such as, but not limited to, video services, conferencing services, and live streaming services. Lag information may include the number of lags and the lag rate. Cell call drop information may be call drop information for call services, such as, but not limited to, LTE call services and NR call services. Examples of crowdsourced data can be found in Table 1 below.

[0133] Table 1

[0134] In Table 1, the handover / reconstruction scenarios refer to the scenario in which the terminal is located when a handover / reconstruction occurs, such as a high-speed rail scenario, a subway scenario, or a highway scenario. The line refers to the specific railway line in the terminal's scenario, such as the Beijing-Shanghai Railway in a high-speed rail scenario or Shanghai Metro Line 9 in a subway scenario. The direction refers to the direction the terminal is traveling on the specific line, and the operator refers to the operator corresponding to the cell. The source cell ID and target cell ID can respectively indicate the current cell ID and the next-hop cell ID.

[0135] The community-related information shown in Table 1 is for illustrative purposes only and should not be construed as limiting.

[0136] In one implementation, the cloud server can receive crowdsourced data for a first route from at least one (e.g., millions or tens of millions) terminals. In some examples, terminals can periodically send crowdsourced data for the first route to the cloud server, for example, once every preset time period. In other examples, terminals can trigger the sending of crowdsourced data for the first route to the cloud server, for example, once when switching cells, once when rebuilding cells, once when data service is interrupted, once when a call is dropped, etc.

[0137] S102: The cloud server determines multiple pre-set path information for the first route based on the crowdsourced data of the first route.

[0138] In one implementation, multiple preset path information may include multiple cell handover lists (referred to as preset paths) and corresponding service information, as well as inter-cell interoperability information, islanding information, etc., corresponding to the cell handover lists. The service information may indicate the applicable service scenarios for the corresponding cell handover list, and optionally, indicate the application effect of the corresponding cell handover list in the service scenario. Examples include optimal overall service (indicating the corresponding cell handover list is the optimal preset path for an overall service scenario), suboptimal overall service (indicating the corresponding cell handover list is the suboptimal preset path for an overall service scenario), optimal call service (indicating the corresponding cell handover list is the optimal preset path for a call service scenario), and optimal video service (indicating the corresponding cell handover list is the optimal preset path for a video service scenario). The services may include data services and call services. Data services include, but are not limited to, video services, conferencing services, and live streaming services. The overall service may include multiple services, such as at least one data service and at least one call service. In some examples, a lower data service latency rate indicates a better data service. In some examples, a lower call drop rate indicates a better call service. In some examples, a cell handover list can correspond to at least one piece of service information. The inter-cell interoperability information can include handover methods between cells, such as handover, redirection, reconstruction, and reselection.

[0139] In one implementation, the cloud server can determine a network topology from the starting point to the ending point based on the crowdsourced data of the first route. This network topology may include multiple cells, multiple links, and multiple lines on the first route. Links can be links between two cells that have interoperability relationships (e.g., handover / redirection / reconstruction / reselection). Lines can be complete lines from the starting point to the ending point on the first route. A line may include a cell handover list (containing multiple cells), and a line includes at least one link. Understandably, a line can be a pre-selected path. In some examples, any cell or link can be represented by the following formulas (1)-(3):

[0140] Where x represents a point, which can be a cell on the first route. d This represents the number of points, i.e., the number of cells on the first route, x. i Let i represent a cell (e.g., a cell on the first route), and x represent a cell. j Let represent the next-hop cell (i.e., cell j) of cell i. Cell i and cell j can be referred to as the source cell and the target cell, respectively. Let y represent an edge, which can be a link between two cells that has an interoperability relationship (e.g., handover / redirection / re-selection). (i,j) This represents the link between cell i (source cell) and cell j (target cell).

[0141] In one implementation, the cloud server can use a mathematical model of Mixed Integer Programming (MIP) to calculate the cost value of each line on the first route (i.e., each line in the above network topology) based on multiple cells (multiple points) and multiple links (multiple edges), and select at least one line with a cost value less than a preset threshold as a preset path. For example, the cost values ​​can be sorted in ascending order, and the N lines corresponding to the first N cost values ​​can be selected as preset paths, where N is a positive integer. The specific number of N is not limited in this embodiment. This method of generating preset paths can be called an operations research optimization algorithm, such as the Shortest Processing Time (SPT) algorithm. The cost value of the line can be calculated using the following formula (4):

[0142] Where W represents the cost value, q represents the weight of the point / cell, and c represents the weight of the edge / link.

[0143] In some examples, the cloud server can calculate the cell weight based on factors such as the cell's signal strength, the lag rate of different data services, and the call drop rate of call services. The formula for calculating the cell weight can be found in the following equation (5): q i =α1f1(p1(i))+α2f2(p2(i))…+α n f n (p n (i)) (5)

[0144] Where α1, α2, ..., α n Represents the non-negative weighting coefficients / weighting values, f1, f2, ..., f n Let p1(i), p2(i), ... p be monotonically nonnegative functions. n(i) represents the n types of cell network information of cell i. For example, p1(i) represents the call drop rate of cell i, p2(i) represents the lag rate of data service 1 of cell i, and p3(i) represents the lag rate of data service 2 of cell i. The cell weight of cell i can be obtained by weighting according to at least one type of cell network information of cell i.

[0145] In some examples, the cloud server can calculate the link weight based on the inter-cell handover success rate, inter-cell reconstruction rate, and inter-cell redirection rate. The formula for calculating the link weight can be found in the following equation (6): c (i,j) =α1f1(p1(i,j))+α2f2(p2(i,j))+α3f3(p3(i,j))+α4f4(d1(i,j))+α5f5(d2(i,j)) (6)

[0146] Here, p1(i,j), p2(i,j), ..., p5(i,j) can represent different types of inter-cell network information between cell i and cell j. For example, p1(i,j) represents the handover success rate between cell i and cell j, with a value range of [0,1]. p2(i,j) represents the reconstruction rate between cell i and cell j, with a value range of [0,1]. p3(i,j) represents the redirection rate between cell i and cell j, with a value range of [0,1]. d1(i,j) indicates whether cell i is an isolated cell; for example, if cell i is an isolated cell, the value is 1, and if cell i is not an isolated cell, the value is 0. d2(i,j) indicates that cell i is a non-high-speed rail cell and cell j is a high-speed rail cell, or vice versa. The link weight between cell i and cell j can be obtained by weighting the different types of inter-cell network information between cell i and cell j.

[0147] For the same line, the cloud server can adjust the weighted value of the cell weight in the line (the weighted value of Equation (5)) according to different business scenarios to obtain the cost value of the line under different business scenarios.

[0148] In some examples, the cell weights in the integrated service scenario can be adjusted by formula (5). For example, if each weight value is not 0, the preset path with the optimal integrated service (i.e. the minimum cost of integrated service) can be obtained.

[0149] In other examples, the cell weights in a single service scenario can be obtained by adjusting the weights to obtain the preset path that is optimal for a single service (i.e., the minimum cost of a single service). For example, when it is necessary to obtain the optimal data service 1 (e.g., p2(i) in equation (5)), the weight α2 of data service 1 can be increased, for example, set to 1.

[0150] In some other examples, when a certain business function does not need to be considered, its corresponding weighting value can be reduced, for example, set to 0.

[0151] By adjusting weighting values, cloud servers can learn the optimal pre-configured paths for comprehensive services, optimal pre-configured paths for call services (e.g., the lowest call drop rate), and optimal pre-configured paths for different data services. Specifically, when calculating the cost of a link under different service scenarios, the cloud server maintains optimal link performance. For example, a higher handover success rate, lower reconstruction rate, lower redirection rate, fewer isolated cells, and more handovers from non-high-speed rail cells to high-speed rail cells (or fewer handovers from high-speed rail cells to non-high-speed rail cells) result in a better link and lower cost.

[0152] The specific implementation of S102 is described below with reference to Figure 8, which illustrates a schematic diagram of a preset path.

[0153] As shown in Figure 8, the cloud server can determine multiple cells, links, and lines on the first route based on the crowdsourced data of the first route. The first route can include 5 cells, such as cell A, cell B, cell C, cell D, and cell E. Optionally, cell A is the starting point of the first route, and cell E is the ending point of the first route. The first route can include 6 links. For example, there is link 1 between cell A and cell B, link 2 between cell B and cell D, link 3 between cell D and cell E, link 4 between cell A and cell C, link 5 between cell C and cell D, and link 6 between cell C and cell E. The first route can include 3 lines. For example, line 1 includes links 1, 2, and 3 (i.e., the cell handover list includes: cell A, cell B, cell D, and cell E), line 2 includes links 4, 5, and 3 (i.e., the cell handover list includes: cell A, cell C, cell D, and cell E), and line 3 includes links 4 and 6 (i.e., the cell handover list includes: cell A, cell C, and cell E).

[0154] Next, the cloud server can calculate the cost value of the three lines according to formulas (4)-(6). Assuming that it is necessary to learn the three optimal preset paths for integrated services, call services, and video services, the cloud server can first calculate the cost value of integrated services, call services, and video services for each line, and take the line with the smallest cost value for each service as the preset path for that service scenario. The cloud server will keep the link optimal. For examples of specific calculation results, please refer to Table 2 below.

[0155] Table 2

[0156] Among them, Line 2 has the lowest integrated service cost (e.g., A2 is less than A1 and A2 is less than A3), Line 1 has the lowest voice service cost (e.g., B1 is less than B2 and B1 is less than B3), and Line 3 has the lowest video service cost (e.g., C1 is less than C2 and C1 is less than C3). Therefore, Line 2 is the optimal preset path for integrated services, and Line 1 is the optimal preset path for both voice and video services.

[0157] S103: The first terminal sends the first request message to the cloud server.

[0158] In one implementation, S103 is an optional step.

[0159] In one implementation, when the first terminal is about to travel to the first route (e.g., the first terminal is detected to be within a preset range of the first route), and / or when the first terminal predicts that it will need to travel to the first route (e.g., the ticket information related to the first route is detected on the first terminal), and / or when the first terminal triggers a system upgrade, the first terminal may send a first request message to the cloud server. The first request message may include the scene and / or route in which the first terminal is located, and the first request message may be used to request multiple preset paths of the scene and / or route in which the first terminal is located.

[0160] S104: The cloud server sends multiple preset path information of the first route to the first terminal.

[0161] In one implementation, S104 is an optional step.

[0162] In one implementation, the cloud server can send multiple preset path information of the first route to the first terminal based on the first request message.

[0163] Not limited to this, in another implementation, the cloud server can periodically send multiple preset path information for the first route to the first terminal, for example, once every preset time period. In another implementation, the cloud server can trigger the sending of multiple preset path information for the first route to the first terminal, for example, once when the system is updated (preset path information is updated), once when the first terminal maintains a network connection at night, once when the geographical location of the first terminal changes, etc.

[0164] In some scenario examples, when the first route is a subway route, the first terminal can download multiple preset route information in advance according to the city; when the first route is a high-speed rail route, the first terminal can download multiple preset route information in advance according to the province; when the first route is an urban road, the first terminal can download multiple preset route information in real time according to the geographical location of the first terminal; when the first terminal is a highway route, the first terminal can download multiple preset route information according to the historical data of the first terminal (such as frequently traveled highway routes or highway routes with high passenger flow). Understandably, the scenarios in which the first terminal obtains multiple preset route information are diverse, and can be either downloaded in advance or obtained in real time; this application does not limit this.

[0165] In addition to the above example where the cloud server sends multiple preset path information of the first route to the first terminal, in another implementation, the multiple preset path information of the first route can also be preset when the first terminal leaves the factory.

[0166] S105: The first terminal determines the matching first preset path information from multiple preset path information of the first route according to the current service scenario of the first terminal, and performs cell handover based on the first cell handover list.

[0167] In one embodiment, the first preset path information may include a first cell handover list and corresponding service information, as well as inter-cell interoperability information corresponding to the first cell handover list. For details, please refer to the description in S102 of Figure 7, which will not be repeated here.

[0168] In one implementation, the service scenario may include a service scenario for voice calls and / or data services. Data services include, but are not limited to, video services, conferencing services, and live streaming services. Voice calls include, but are not limited to, LTE voice calls and NR voice calls.

[0169] In one implementation, when the first terminal is traveling on the first route, it can determine the first preset path information that matches the current service scenario from multiple preset path information on the first route. For example, the service information corresponding to the first cell handover list matches the current service scenario. In some examples, when the first terminal is currently in a call service scenario, the optimal preset path for the call service (i.e., the first cell handover list) can be selected from the multiple preset path information on the first route.

[0170] In one implementation, when the first terminal travels along the first route, it can switch to a cell that provides wireless communication services to the first terminal based on a first cell handover list and inter-cell interoperability information, i.e., perform a cell handover. In some examples, when the first cell handover list is line 1 in Figure 8, i.e., the first cell handover list is: cell A, cell B, cell D, and cell E, when the first terminal travels to the area of ​​cell A, it can establish a connection and communication with the base station in cell A. When the first terminal travels to the junction area of ​​cell A and cell B, it can cancel the connection to the base station in cell A and establish a connection and communication with the base station in cell B, and so on, until it switches to establish a connection and communication with the base station in cell E. In some examples, assuming the handover method between cell A and cell B is reconstruction, when the first terminal travels to the junction area of ​​cell A and cell B, the first terminal can actively initiate the re-establishment of the base station corresponding to cell B.

[0171] The scenario described above, where the first terminal performs cell handover based on the first cell handover list and inter-cell interoperability information, is not limited to the case where the first terminal performs cell handover based on the first cell handover list and inter-cell interoperability information. In other examples, when the first terminal is traveling along the first route, it can adjust the cell to be handed over in real time by combining the first cell handover list, inter-cell interoperability information, and the signal strength between the first terminal and multiple base stations in the actual scenario. That is, the cell that the first terminal hands over when traveling along the first route can be the same as or different from the first cell handover list. In some examples, the first terminal can determine the cell it is currently in (i.e., the source cell) and the next-hop cell (i.e., the target cell), and send measurement information to the base station corresponding to the source cell. The measurement information can include the signal strength between the first terminal and the source cell, and the signal strength between the first terminal and the target cell. The base station can guide the first terminal to perform cell handover based on the measurement information. For example, when the signal strength between the first terminal and the source cell is weak, and the signal strength between the first terminal and the target cell is strong, the base station can send an instruction to the first terminal to make the first terminal handover from the source cell to the target cell.

[0172] The preset path in Figure 7 is not limited to the complete route from the starting point to the ending point on the first route. In another embodiment, the preset path can also be a route from any node on the first route to the ending point. The node can be any cell other than the ending point, and the route includes at least one link. For example, the preset path can be the route between cell B and cell E in Figure 8, which includes link 2 and link 3. Furthermore, in some other examples, the preset path can also be the route between any two cells on the first route. For example, the preset path can be the route between cell B and cell D in Figure 8, which includes link 2. This application does not limit the preset path.

[0173] Alternatively, in another implementation, when the service scenario of the first terminal changes during its travel on the first route, the first terminal can re-execute S105, that is, redetermine a new cell handover list based on the changed service scenario, and perform cell handover based on the new cell handover list.

[0174] In the method shown in Figure 7, in a high-speed driving scenario, the terminal can send crowdsourced data to the cloud server. The cloud server can generate multiple preset paths based on the MIP mathematical model and using an operations research optimization algorithm. The terminal can receive the multiple preset path information sent by the cloud server and determine the first preset path information (including the first preset path) that conforms to the current business scenario based on its own actual business scenario. Cell handover is then performed based on the first preset path. Optionally, when the business scenario of the terminal changes, the terminal can re-determine a new preset path. This can be understood as the terminal continuously adjusting the preset path according to the real-time business scenario, so that regardless of the business scenario, the terminal can reduce poor call quality and data service lag caused by frequent cell handover, thereby improving the user experience.

[0175] In one implementation, the cloud server can use a probabilistic graph simulation platform to simulate multiple routes on the first route using Monte Carlo (MC) random event simulation and the law of large numbers. The simulation results are used to evaluate the merits of the multiple preset paths. For a detailed description of the simulation process, please refer to the flowchart shown in Figure 9.

[0176] As shown in Figure 9, the cloud server can acquire crowdsourced data for the first route. This crowdsourced data can include crowdsourced event data and handover / reconstruction data. The cloud server can extract communication quality information from the crowdsourced event data to obtain cell network information. It can also extract handover relationship information from the handover / reconstruction data to obtain inter-cell network information. Then, based on the stuttering rate of different data services and the call drop rate of each cell in the cell network information, the cloud server can model multiple cells (multiple points) to obtain multiple node information in the probability graph, with each node corresponding to one cell. Furthermore, based on the inter-cell handover success rate, reconstruction rate, and redirection rate in the inter-cell network information, the cloud server can model multiple edges (multiple links) to obtain multiple link information in the probability graph. A specific example can be seen in Figure 10, which exemplarily illustrates a schematic diagram of a probability graph structure.

[0177] As shown in Figure 10, the first route in Figure 10 may include cell F, cell G, cell H, cell I, cell J, and cell K. Optionally, cell F is the starting point of the first route, and cell K is the ending point of the first route. Each cell displays two values, where the black value represents the lag rate (e.g., the lag rate of integrated services), and the gray value represents the call drop rate. Values ​​are displayed on the links between cells, which can represent the inter-cell handover success rate. Figure 10 shows the cell network information, inter-cell network information, and multiple lines of multiple cells on the first route. It can be understood that the multiple cells, multiple links, and multiple lines determined by formulas (1)-(3) in S102 of Figure 7 can correspond to the structural diagram of the probability diagram shown in Figure 10.

[0178] The cloud server can use MC random event simulation to simulate multiple users traversing multiple lines of the first route shown in Figure 10 (referred to as Scheme 1). For example, assuming 100,000 users traverse the first route, there will be 100,000 data points for each line from the start to the end of the first route. This data can include the lag rate, call drop rate, and inter-cell handover success rate for each user passing through each cell. This can be understood as simulating a real-world scenario using a large amount of user data. Finally, based on the data from the 100,000 lines, the average number of lags, average number of call drops, average number of handovers, and average number of reconstructions for each line from the start to the end of the first route can be calculated (i.e., the simulation results of Scheme 1). Understandably, the law of large numbers used in simulating Scheme 1 means that when the user data reaches a certain magnitude, the sample mean converges to a stable value. In other words, with a sufficiently large number of users, the calculated simulation results tend to be more stable, approaching a constant, thus ensuring the data validity and stability of the simulation results.

[0179] In some examples, the cloud server can use the first algorithm to calculate multiple preset paths based on the probability graph shown in Figure 10 (e.g., by calculating the cost of each line on the first route shown in Figure 10 using the first algorithm) to adjust the handover success rate between cells. For example, the optimal preset path for integrated services calculated by the first algorithm is the bolded line in Figure 11 (i.e., the corresponding cell handover list is: cell F, cell G, cell K). During the simulation, if the simulation shows that the user actually chooses to go from cell F to cell G (the link is on the preset path), the handover success rate between cell F and cell G is increased; if the simulation shows that the user actually chooses to go from cell F to cell H (the link is not on the preset path), the handover success rate between cell F and cell H is decreased. Finally, at the end of the simulation, a schematic diagram of the probability graph structure shown in Figure 11 can be obtained.

[0180] As shown in Figure 11, which is similar to Figure 10, the difference is that the handover success rate between cell F and cell G in Figure 11 (60%) is greater than that between cell F and cell G in Figure 10 (50%), and the handover success rate between cell F and cell H in Figure 11 (10%) is less than that between cell F and cell H in Figure 10 (20%).

[0181] The cloud server can use MC random event simulation to simulate multiple users traversing multiple lines (referred to as Scheme 2) of the first route shown in Figure 11, and calculate the simulation results of Scheme 2, including, for example, the average number of pauses, average number of dropped calls, average number of handovers, and average number of rebuilds. Next, the cloud server can compare the simulation results of Scheme 1 and Scheme 2. If the simulation results after adjustment (Scheme 2) are better than those before adjustment (Scheme 1), for example, if at least one item in the simulation results of Scheme 2 is less than at least one item in the simulation results of Scheme 1, then it proves that the multiple preset paths calculated by the first algorithm are effective, the first algorithm is good, and the preset paths are good. If the simulation results after adjustment (Scheme 2) are worse than those before adjustment (Scheme 1), then the first algorithm for calculating costs can be modified, for example, by modifying the weighting values. Understandably, the simulation results can be used to measure the quality of preset paths. Optionally, the simulation results can also be used to measure the accuracy of different preset path algorithms, such as, but not limited to, greedy algorithms, Shortest Processing (SP) algorithms, and SPT algorithms.

[0182] The simulation method shown in Figure 9 can simulate a real scene in the indoor field, reducing the testing cost in the outdoor field. Moreover, the simulation accuracy is high, and it can accurately measure the quality of the generated multiple preset paths.

[0183] The methods provided in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented, in whole or in part, in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DWD), or a semiconductor medium (e.g., solid-state drive). (disk, SSD, etc.). The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A pre-path selection method characterized by, Applied to a first terminal, the method includes: Based on the first service scenario where the first terminal is located on the first route, the first preset path information is determined from multiple preset path information of the first route, wherein the first preset path information includes the first cell handover list of the first route, and the first cell handover list includes information of multiple cells; The first terminal performs cell handover on the first route based on the first cell handover list.

2. The method of claim 1, wherein, The multiple preset path information is calculated by the cloud server based on the cost value, and the cost value corresponding to any one of the multiple preset path information is less than a preset threshold.

3. The method of claim 1 or 2, wherein, The method further includes: Receive multiple preset path information for the first route sent by the cloud server.

4. The method according to any one of claims 1 to 3, characterized in that, The first preset path information includes the first cell handover list and the corresponding first service information. The first service information indicates the second service scenario applied by the first cell handover list, and the second service scenario matches the first service scenario.

5. The method of claim 4, wherein, The first service information indicates the application effect of the first cell handover list in the second service scenario.

6. The method according to any one of claims 1 to 5, wherein, The first preset path information includes the first cell handover list and the corresponding first cell handover method information. The first terminal performs cell handover on the first route based on the first cell handover list, including: When the first terminal is on the first route and in the first service scenario, cell handover is performed based on the first cell handover list and the first cell handover method information.

7. The method according to any one of claims 1 to 6, wherein The method further includes: When the first terminal is on the first route and is in the third service scenario, the first terminal determines the second preset path information from multiple preset path information of the first route. The second preset path information includes the second cell handover list of the first route and the corresponding second service information. The second service information indicates the fourth service scenario applied by the second cell handover list. The fourth service scenario matches the third service scenario. The first terminal performs cell handover on the first route based on the second cell handover list.

8. The method according to any one of claims 1 to 7, wherein The method further includes: Send a first request message to the cloud server. The first request message includes the scene where the first terminal is located and / or the first route. The first request message is used to request multiple preset path information of the scene where the first terminal is located and / or the first route.

9. The method according to any one of claims 1 to 8, wherein, The method further includes: The cloud server sends crowdsourced data obtained while traversing the first route. The crowdsourced data includes at least one of the following: cell network information of the cell where the first terminal is located, and inter-cell network information. The cell network information includes at least one of the following: cell information, cell lag information, and cell call drop information. The inter-cell network information includes at least one of the following: inter-cell handover information, inter-cell reconstruction information, inter-cell redirection information, and inter-cell reselection information. The cell lag information includes lag information for different data services. The crowdsourced data is used by the cloud server to determine multiple preset path information for the first route.

10. A method of pre-routing, characterized by, Applied to cloud servers, the method includes: Multiple preset path information for a first route are sent to a first terminal. The first preset path information in the multiple preset path information includes a first cell handover list for the first route. The first cell handover list includes information on multiple cells. The multiple preset path information is used by the first terminal to determine the first preset path information based on the first service scenario in which the first terminal is located on the first route. The first cell handover list is used by the first terminal to perform cell handover on the first route.

11. The method of claim 10, wherein, The multiple preset path information is calculated by the cloud server based on the cost value, and the cost value corresponding to any one of the multiple preset path information is less than a preset threshold.

12. The method of claim 10 or 11, wherein, The method further includes: Receive a first request message sent by the first terminal, the first request message including the scene where the first terminal is located and / or the first route; Based on the first request message, the first terminal is sent with the scene where the first terminal is located and / or multiple preset path information of the first route.

13. The method according to any one of claims 10 to 12, wherein, The method further includes: The cloud server receives crowdsourced data obtained when traversing the first route, sent by the first terminal. The crowdsourced data includes at least one of the following: cell network information of the cell where the first terminal is located, and inter-cell network information. The cell network information includes at least one of the following: cell information, cell lag information, and cell call drop information. The inter-cell network information includes at least one of the following: inter-cell handover information, inter-cell reconstruction information, inter-cell redirection information, and inter-cell reselection information. The cell lag information includes lag information for different data services. The crowdsourced data is used by the cloud server to determine multiple preset path information for the first route.

14. A terminal, characterized by It includes a transceiver, a processor, and a memory, the memory being used to store a computer program, and the processor calling the computer program to perform the method as described in any one of claims 1-9.

15. A network device, comprising: It includes a transceiver, a processor, and a memory, the memory being used to store a computer program, and the processor calling the computer program to perform the method as described in any one of claims 10-13.

16. A computer storage medium, comprising, The computer storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1-13.

Images