Vehicle positioning method, device, system and storage medium

Abstract

The application provides a vehicle positioning method, device, system and storage medium. The method comprises the following steps: collecting a call record of a vehicle; analyzing the call record of the vehicle to obtain a routing area code, a core network node position and an access operator address of the vehicle; obtaining a first weight, a second weight and a third weight, wherein the first weight is used to represent a weight coefficient of the routing area code, the second weight is used to represent a weight coefficient of the core network node position, and the third weight is used to represent a weight coefficient of the access operator address; and positioning the vehicle based on the routing area code, the core network node position and the access operator address, and the corresponding first weight, the second weight and the third weight. The method provided by the application is helpful to assist in improving the positioning accuracy of the vehicle.

Description

Technical Field

[0001] This application relates to the field of vehicle networking, and in particular to a vehicle positioning method, device, system and storage medium. Background Technology

[0002] In related technologies, vehicle positioning methods may include the following: Global Positioning System (GPS), cellular network base station positioning, Wireless Fidelity (Wi-Fi) location matching, and V2X roadside unit positioning.

[0003] Understandably, the aforementioned vehicle positioning methods each have their advantages in vehicle-to-everything (V2X) and intelligent transportation systems, but they also have certain drawbacks and limitations. GPS positioning is susceptible to environmental interference; for example, in densely built-up cities, GPS signals are easily emitted or blocked by buildings, leading to multipath effects and positioning errors. Furthermore, the Global Navigation Satellite System (GNSS) module in the vehicle needs to operate continuously, resulting in rapid battery drain, especially noticeable in pure electric vehicles. Cellular base station positioning has low accuracy and cannot meet the high-precision requirements of V2X applications. Additionally, vehicles must maintain a connection with mobile operator base stations, and data may be unavailable across operators, affecting positioning consistency. Wi-Fi positioning technology is mainly limited by the distribution of Wi-Fi hotspots and the susceptibility of signals to interference, resulting in suboptimal positioning data. Although V2X roadside unit positioning technology is a crucial cornerstone and development trend for future autonomous driving and intelligent transportation, its current limitations, such as the need for large-scale infrastructure development and low adoption rates, prevent its widespread application.

[0004] Therefore, accurately obtaining the vehicle's geographical location when the vehicle is in an environment with weak or lost GPS signal, such as in tunnels, underground parking lots, under overpasses, or mountainous areas, becomes an urgent problem to be solved. Summary of the Invention

[0005] This application provides a vehicle positioning method, device, system, and storage medium, which helps to improve the positioning accuracy of vehicles.

[0006] In a first aspect, embodiments of this application provide a vehicle positioning method applied to a local operating platform, comprising: collecting call detail records (CDRs) of a vehicle; parsing the CDRs of the vehicle to obtain the vehicle's routing area code, core network node location, and access operator address; obtaining a first weight, a second weight, and a third weight, wherein the first weight is used to characterize the weight coefficient of the routing area code, the second weight is used to characterize the weight coefficient of the core network node location, and the third weight is used to characterize the weight coefficient of the access operator address; and locating the vehicle based on the routing area code, the core network node location, and the access operator address, as well as the corresponding first weight, second weight, and third weight.

[0007] In one possible implementation, the first weight is determined by the signal strength of the wireless link between the vehicle's onboard terminal and the cellular network base station, the second weight is determined by the network load, and the third weight is determined by the vehicle's roaming status.

[0008] In one possible implementation, the first weight is calculated using the following formula:

[0009]

[0010] Wherein, α is the first weight, and the signal strength The signal strength of the wireless link between the vehicle's onboard terminal and the cellular network base station.

[0011] In one possible implementation, the second weight is calculated using the following formula:

[0012] β = 0.3 * (1 - network) load );

[0013] Wherein, β is the second weight, and the network load For network load.

[0014] In one possible implementation, when the vehicle is in a roaming state, the third weight is a first preset value; when the vehicle is not in a roaming state, the third weight is a second preset value.

[0015] In one possible implementation, locating the vehicle based on the routing area code, the core network node location, and the access operator address, as well as the corresponding first weight, second weight, and third weight, includes: normalizing the first weight, second weight, and third weight to obtain a first coefficient, a second coefficient, and a third coefficient, where the first coefficient is the normalized value corresponding to the first weight, the second coefficient is the normalized value corresponding to the second weight, and the third coefficient is the normalized value corresponding to the third weight; locating the vehicle based on the routing area code, the core network node location, and the access operator address, as well as the corresponding first coefficient, second coefficient, and third coefficient.

[0016] In one possible implementation, after collecting the vehicle's call detail records (CDRs), the method includes: evenly distributing the vehicle's CDRs to multiple partitions according to the amount of data.

[0017] In one possible implementation, the step of evenly distributing the call details of the vehicle to multiple partitions based on the amount of data includes: distributing the call details of the same vehicle to the same partition.

[0018] In one possible implementation, the vehicle's call detail record (CDR) is a billing gateway (CG) CDR.

[0019] Secondly, embodiments of this application provide a vehicle positioning device, including one or more functional modules, which are used to perform the vehicle positioning method as described in the first aspect.

[0020] Thirdly, embodiments of this application provide a vehicle positioning system, including:

[0021] A local operating platform for performing the vehicle positioning method as described in the first aspect to locate the vehicle;

[0022] On the network side, a call detail record (CDR) is generated based on the traffic consumed by the vehicle, and the CDR of the vehicle is pushed to the local operation platform.

[0023] Fourthly, embodiments of this application provide a readable storage medium storing a program that, when run on a local operating platform, enables the local operating platform to implement the vehicle positioning method as described in the first aspect.

[0024] Fifthly, embodiments of this application provide a program that, when run on a processor of a local operating platform, causes the local operating platform to execute the vehicle positioning method as described in the first aspect.

[0025] In one possible design, the program in the fifth aspect can be stored wholly or partially on a storage medium packaged with the processor, or it can be stored wholly or partially on a memory not packaged with the processor. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the system architecture provided for an embodiment of this application;

[0027] Figure 2 A flowchart illustrating an embodiment of the vehicle positioning method provided in this application;

[0028] Figure 3 A flowchart illustrating another embodiment of the vehicle positioning method provided in this application;

[0029] Figure 4 This is a schematic diagram of the vehicle positioning device provided in an embodiment of this application. Detailed Implementation

[0030] In this embodiment of the application, unless otherwise stated, the character " / " indicates that the preceding and following objects are in an OR relationship. For example, A / B can represent A or B. "AND / OR" describes the relationship between the associated 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.

[0031] It should be noted that the terms "first" and "second" used in the embodiments of this application are used only for distinguishing descriptive purposes and should not be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated, nor should they be construed as indicating or implying order.

[0032] In the embodiments of this application, "at least one" refers to one or more items, and "more than one" refers to two or more items. Furthermore, "at least one of the following" or similar expressions refer to any combination of these items, which may include any combination of a single item or a plurality of items. For example, at least one of A, B, or C can represent: A, B, C, A and B, A and C, B and C, or A, B, and C. Each of A, B, and C can be an element itself or a set containing one or more elements.

[0033] In this application, terms such as "exemplary," "in some embodiments," and "in another embodiment" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the term "exemplary" is intended to present the concept in a concrete manner.

[0034] In the embodiments of this application, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction, their meanings are consistent. Similarly, in the embodiments of this application, "communication" and "transmission" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction, their meanings are consistent. For example, transmission can include sending and / or receiving, and can be a noun or a verb.

[0035] In the embodiments of this application, the term "equal to" can be used in conjunction with "greater than" to apply to technical solutions employing the condition of "greater than", and can also be used in conjunction with "less than" to apply to technical solutions employing the condition of "less than". It should be noted that when "equal to" is used with "greater than", it cannot be used with "less than"; and when "equal to" is used with "less than", it cannot be used with "greater than".

[0036] In related technologies, vehicle positioning methods may include the following: Global Positioning System (GPS), cellular network base station positioning, Wireless Fidelity (Wi-Fi) location matching, and V2X roadside unit positioning.

[0037] Understandably, the aforementioned vehicle positioning methods each have their advantages in vehicle-to-everything (V2X) and intelligent transportation systems, but they also have certain drawbacks and limitations. GPS positioning is susceptible to environmental interference; for example, in densely built-up cities, GPS signals are easily emitted or blocked by buildings, leading to multipath effects and positioning errors. Furthermore, the Global Navigation Satellite System (GNSS) module in the vehicle needs to operate continuously, resulting in rapid battery drain, especially noticeable in pure electric vehicles. Cellular base station positioning has low accuracy and cannot meet the high-precision requirements of V2X applications. Additionally, vehicles must maintain a connection with mobile operator base stations, and data may be unavailable across operators, affecting positioning consistency. Wi-Fi positioning technology is mainly limited by the distribution of Wi-Fi hotspots and the susceptibility of signals to interference, resulting in suboptimal positioning data. Although V2X roadside unit positioning technology is a crucial cornerstone and development trend for future autonomous driving and intelligent transportation, its current limitations, such as the need for large-scale infrastructure development and low adoption rates, prevent its widespread application.

[0038] Therefore, accurately obtaining the vehicle's geographical location when the vehicle is in an environment with weak or lost GPS signal, such as in tunnels, underground parking lots, under overpasses, or mountainous areas, becomes an urgent problem to be solved.

[0039] To address the aforementioned issues, this application provides a vehicle positioning method that helps improve the positioning accuracy of vehicles.

[0040] Figure 1 This is a schematic diagram of the system architecture provided for an embodiment of this application.

[0041] refer to Figure 1 The system architecture may include a local operation platform 10, a network side 11, and a vehicle 12.

[0042] In this embodiment, vehicle 12 is the consumer of data traffic, and each vehicle 12 may include a vehicle identification number (VIN). For example, the VIN can be represented by a Subscriber Identity Module (SIM) card number. It is understood that the VIN can also be represented in other forms, and this embodiment does not impose any special limitations on it.

[0043] The network side 11 can generate corresponding call detail records (CDRs) based on the traffic consumed by the vehicle 12. These CDRs can be core network charging gateway (CG) CDRs, or they can be other types of CDRs. This application embodiment does not impose any special limitations on this.

[0044] It is understandable that this CG call detail record can be generated by the Serving GPRS Support Node (SGSN) or the Gateway GPRS Support Node (GGSN) of the core network.

[0045] The local operation platform 10 can collect CG call detail records generated by the network side 11 and locate the vehicle based on the relevant information in the CG call detail records.

[0046] Figure 2 A flowchart illustrating an embodiment of the vehicle positioning method provided in this application includes the following steps:

[0047] Step 201: Collect vehicle call detail records.

[0048] Specifically, the vehicle's call detail record (CDR) can be a CG CDR, or it can be other types of CDRs. This application embodiment does not impose any special limitations on this.

[0049] It is understandable that CG call detail records can be billing records generated by the core network data during each data transmission process, such as remote diagnostics, OTA upgrades, real-time navigation, and vehicle location reporting, when the vehicle's terminal (e.g., T-BOX) accesses the cellular network (e.g., 4G / 5G, or future network standards) through the vehicle's SIM card.

[0050] Among them, the vehicle's call detail records can be generated by the SGSN or GGSN of the core network when the vehicle establishes a data connection with the cellular network, switches base stations, or roams, and can be aggregated by the operator's billing system.

[0051] It is understandable that the call detail records (CDRs) of the aforementioned vehicles can be distributed across various data centers or servers, and the local operating platform can collect the CDR data of the vehicles from these various data centers or servers.

[0052] In some alternative embodiments, to improve collection efficiency, the local operations platform can use a high-concurrency, scalable Kafka data transfer middleware to collect vehicle call detail records from various data centers or servers.

[0053] In some optional embodiments, in order to improve the processing efficiency of vehicle call detail records (CDRs), the CDRs of the vehicles can be evenly sent to multiple partitions according to the amount of data. The amount of data received by each partition can be approximately equal. By processing the vehicle CDRs concurrently through multiple partitions, the efficiency of data processing can be improved.

[0054] In some alternative embodiments, all call detail records (CDRs) for the same vehicle can be assigned to the same partition, thereby reducing the performance overhead of cross-partition queries.

[0055] Step 202: Preprocess the call records of the vehicles.

[0056] Specifically, because vehicle call detail records (CDRs) are stored in different formats (such as ASN.1, CSV, JSON, etc.), there are differences in the CDR formats generated by different data sources; and due to factors such as data synchronization mechanisms and network retransmission, the same CDR may be collected repeatedly at different times or at different collection nodes; and there may be problems such as incomplete fields and abnormal data, it is necessary to preprocess the original CDRs of vehicles.

[0057] In some alternative embodiments, preprocessing the vehicle's call detail records (CDRs) may include filtering out illegal data in the CDRs.

[0058] In some alternative embodiments, preprocessing the vehicle's call detail records (CDRs) may include deduplicating the CDRs.

[0059] Understandably, the pre-processed vehicle call details can be stored in a database.

[0060] Step 203: Parse the preprocessed vehicle call detail records to obtain the vehicle's routing area code, core network node location, and access operator address.

[0061] Specifically, the routing area code can be used to characterize the tracking area where the vehicle terminal (e.g., TBOX) is located, mainly for determining the user's location, regional analysis, etc. For example, the routing area code can be represented by the TAC (uli_tac) code.

[0062] Here, `uli` is a field within User Location Information (ULI) that represents the Tracking Area Code (TAC). The TAC is a geographic location identifier assigned by the radio access network to group and manage base stations within a region. Changes in the TAC can be used to determine the vehicle's movement trajectory (e.g., from TAC 1001 to TAC 1002 indicates cross-regional movement). By combining the TAC with the ECI (Cell ID), the approximate area where the vehicle is located can be determined.

[0063] For example, the "uli_tac" field value in the vehicle's call detail record (CDR) can be parsed to obtain the base station ECI code. The CDR database can then be queried to obtain the geographical coordinates of the base station, which can be represented by latitude and longitude. For example, the geographical location of the base station could be (116.4039°N, 39.9151°E).

[0064] The filing database can be a database of the country where the local operating platform is located. For example, if the country where the local operating platform is located is country A, the filing database can be the filing database of country A.

[0065] The location of a core network node can be used to characterize the IP address (or name) of the core network node that provides packet data services to users. This core network node location can be the address of a Serving GPRS Support Node (SGSN).

[0066] Understandably, in the Internet of Vehicles (IoV), it is possible to determine which core network node the vehicle data is connected to, thereby initially determining the vehicle's location; different SGSNs can cover different areas, and the geographical distribution of vehicles can be indirectly analyzed by determining the location of the core network node.

[0067] For example, taking the SGSN as an example, the IPv4 address corresponding to the SGSN in the vehicle's call detail record (CDR) can be resolved. Using this IPv4 address and combining it with the Geographic Information System (GIS) coordinates of the network management system's data center, the location of the core network node can be determined. For instance, the IPv4 address mentioned above can be used to determine the geographical location of the core network node as a data center in a certain location.

[0068] The access operator address can be used to identify the operator code (Visited PLMN Code), which is the identifier of the operator to which the network the vehicle is currently accessing belongs.

[0069] Understandably, determining the access operator's address can help identify whether a vehicle is roaming within or internationally / domestic; and it can also be used to analyze the vehicle's cross-border movement path (e.g., combining time and base station location).

[0070] For example, operator information can be obtained through the operator code in the vehicle's call detail record. For instance, assuming the operator code is 48600, which represents region A in country X, the centroid of region A in country X can be calculated, and this centroid can be used as the access operator address.

[0071] In some optional embodiments, the parsed data can be stored in a database (e.g., a StarRocks cluster database). Storage engine optimization can be achieved using columnar storage and column block encoding techniques, such as dictionary encoding, low-radix numeric fields of APN type, bitmap encoding, boolean fields with roaming representation, and Delta encoding suitable for time-series fields. A core index system is established through prefix indexes, inverted indexes, and bitmap indexes. Ultimately, fast queries by dimensions such as ICCID, IMSI, APN, and geographic location are supported.

[0072] Step 204: Obtain the first weight, the second weight, and the third weight.

[0073] Specifically, the first weight can be used to characterize the weight coefficient of the routing area code.

[0074] The first weight can be determined by the signal strength of the wireless link between the vehicle terminal and the cellular network base station.

[0075] For example, the first weight can be calculated using the following formula:

[0076]

[0077] Where α is the first weight, and signalstrength is the signal strength of the wireless link between the vehicle terminal and the cellular network base station.

[0078] For example, the minimum value of the first weight can be 0.5, and the maximum value of the first weight can be 0.8.

[0079] Understandably, a strong signal means the vehicle is closer to the base station, resulting in higher positioning reliability; a weak signal means the vehicle may be at the cell edge, leading to decreased positioning accuracy. Therefore, in this embodiment, signal strength can be used to add or subtract weights from the routing area code.

[0080] The second weight can be used to characterize the weight coefficient of the core network node position.

[0081] The second weight can be determined by the network load.

[0082] For example, the second weight can be calculated using the following formula:

[0083] β = 0.3 * (1 - network) load );

[0084] Where β is the second weight, network load For network load.

[0085] Understandably, when network load increases, for example, when the network load approaches 1, the value of the second weight approaches 0. In other words, the minimum value of the second weight approaches 0, indicating that the network in this area is congested and the location reliability decreases. When network load decreases, for example, when the network load drops to approach 0, the value of the second weight approaches 0.3. In other words, the maximum value of the second weight approaches 0.3, indicating that the network in this area is unobstructed and the location reliability increases.

[0086] The third weight is the weighting coefficient of the access operator's address.

[0087] For example, the third weight is 0.2 when the vehicle is roaming, or 0.05 when the vehicle is not roaming.

[0088] It is understandable that if the vehicle is in a roaming network, the third weight can have a higher value (0.2) because roaming network information has stronger positioning reference value when crossing national / domain boundaries. If it is in a local network, the third weight can have a lower value (0.05), weakening its effect.

[0089] Step 205: Locate the vehicle based on its routing area code, core network node location, access operator address, and corresponding first weight, second weight, and third weight.

[0090] Specifically, once the vehicle's routing area code, core network node location, and access operator address, along with the corresponding first weight, second weight, and third weight, are obtained, the vehicle can be located based on these information.

[0091] In some alternative embodiments, the vehicle's position can be calculated using the following formula:

[0092] S1 = Routing area code * First weight + Core network node location * Second weight + Access operator address * Third weight.

[0093] S1 is used to characterize the geographical location of the vehicle.

[0094] In some alternative embodiments, the vehicle's position can be calculated using the following formula:

[0095] S2 = Routing area code * First coefficient + Core network node location * Second coefficient + Access operator address * Third coefficient.

[0096] Here, S2 represents the vehicle's geographical location, the first coefficient is the normalized value corresponding to the first weight, the second coefficient is the normalized value corresponding to the second weight, and the third coefficient is the normalized value corresponding to the third weight. It can be understood that by normalizing the first, second, and third weights, their respective normalized values ​​can be obtained; for example, the first coefficient + the second coefficient + the third coefficient = 1.

[0097] Understandably, the local operations platform can parse the call details of multiple vehicles to obtain the geographical location of the corresponding vehicle.

[0098] For example, suppose the local operations platform collects call detail records (CDRs) for multiple vehicles. These CDRs may include CDR 1, CDR 2, and CDR 3. CDR 1 is the CDR for vehicle 1 and may include vehicle 1's identification number; CDR 2 is the CDR for vehicle 2 and may include vehicle 2's identification number; and CDR 3 is the CDR for vehicle 3 and may include vehicle 3's identification number. By parsing CDR 1, the geographical location of vehicle 1 can be obtained; by parsing CDR 2, the geographical location of vehicle 2 can be obtained; and by parsing CDR 3, the geographical location of vehicle 3 can be obtained.

[0099] The above text passed Figure 2 The vehicle positioning method is illustrated in the following example. Figure 3 An example is provided to illustrate the parsing of vehicle call details.

[0100] Figure 3 A flowchart illustrating an embodiment of the vehicle positioning method provided in this application includes the following steps:

[0101] Step 301: Obtain the first information.

[0102] Specifically, the first information can be used to characterize the relevant information of the routing area code in the call detail record (CDR). For example, the field corresponding to the first information in the CDR may be uli_tac.

[0103] Step 302: Based on the first information, query the first filing database to determine whether the first information has been successfully parsed.

[0104] Specifically, the method for determining whether the first information has been successfully parsed may include: querying the first filing database based on the value of the field corresponding to the first information to see if a matching value is found, wherein the first filing database may be the filing database of the country to which the local operating platform belongs.

[0105] If a matching value is found in the first registration database, it can be determined that the first information was successfully parsed, indicating that the vehicle's location is within the country of origin. If no matching value is found in the first registration database, it can be determined that the first information was not successfully parsed, indicating that the vehicle's location is outside the country of origin, or that the value of the field corresponding to the first information may be empty.

[0106] If the first piece of information is successfully parsed, proceed to step 303a.

[0107] If it is determined that the parsing of the first piece of information is unsuccessful, proceed to step 303b.

[0108] Step 303a: Obtain the second information and the third information; determine the routing area code based on the first information; determine the core network node location based on the second information; and determine the access operator address based on the third information.

[0109] Specifically, the second information can be used to characterize information related to the location of the core network node in the call detail record (CDR). For example, taking the SGSN as an example, the field corresponding to the second information in the CDR can be the IPv4 field under the SGSN.

[0110] This third piece of information can be used to characterize information related to the access operator's address in the call detail record (CDR). For example, the field corresponding to this third piece of information in the CDR can be the operator code field (e.g., visit_provider_code).

[0111] Step 303b: Obtain third information.

[0112] Step 304b: Determine whether the value of the field corresponding to the third information corresponds to the first region.

[0113] The first region can be used to represent regions other than the country of origin. For example, if the country of origin of the access operator is country A, the first region can be other regions other than country A.

[0114] If the value of the field corresponding to the third information corresponds to the first region, proceed to step 305b.

[0115] If the value of the field corresponding to the third information does not correspond to the first area, proceed to step 305c.

[0116] Step 305b: Obtain the second information. Within the first area, determine the routing area code based on the first information, determine the core network node location based on the second information, and determine the access operator address based on the third information.

[0117] Specifically, once the first information is obtained, the corresponding routing zone code can be obtained by querying the second filing database within the first area based on the first information.

[0118] The second filing database can be a filing database within the first region. Taking country A as the country where the local operating platform is located, the first region is a region outside of country A. The second filing database can be a filing database outside of country A. For example, the second filing database can be a filing database in country B, or a filing database in country C, or a filing database in country D. This application embodiment does not make any special limitations on this.

[0119] Once the second information is obtained, the location of the corresponding core network node can be found within the first area based on the IPv4 address corresponding to the second information.

[0120] Once the third information is obtained, the corresponding access operator address can be found within the first area based on the third information.

[0121] Step 305c: Obtain the second information.

[0122] Step 306c: Based on the IPv4 address corresponding to the second information, search within the country of the local operating platform to determine whether the second information has been successfully resolved.

[0123] Specifically, if the corresponding core network node location is found, it can be determined that the second information was successfully parsed; if the corresponding core network node location is not found, it can be determined that the second information was not successfully parsed.

[0124] If the second information is successfully parsed within the country of the local operating platform, proceed to step 307c.

[0125] If the second information resolution fails within the country of the local operating platform, proceed to step 307d.

[0126] Step 307c: Determine the routing area code based on the first information, determine the core network node location based on the second information, and determine the access operator address based on the third information.

[0127] Step 307d: Based on the IPv4 address corresponding to the second information, search within the second area to determine whether the second information has been successfully resolved.

[0128] Specifically, the second region is different from the first region. The second region is an administrative region of the country where the local operating platform is located. However, the relevant business can be operated independently in the second region. Taking country A as an example, the second region can be region A of country A. The operator in region A and the operator in country A can be different.

[0129] If the corresponding core network node location is found within the second region, the second information parsing is confirmed to be successful.

[0130] If the corresponding core network node location is not found within the second region, it is determined that the second information parsing was unsuccessful.

[0131] If the second information is successfully parsed within the second region, proceed to step 308e.

[0132] If the second information parsing fails within the second region, proceed to step 308d.

[0133] Step 308d: Output alarm information.

[0134] Specifically, when it is determined that the second information parsing fails, it can be assumed that the core network node location cannot be found, that is, the data is abnormal. In this case, an alarm message can be output, which can be used to indicate that the data is abnormal.

[0135] Step 308e: Within the second area, determine the routing area code based on the first information, determine the core network node location based on the second information, and determine the access operator address based on the third information.

[0136] Figure 4 This is a schematic diagram of the vehicle positioning device provided in the embodiments of this application, such as... Figure 4 As shown, the vehicle positioning device 40 is applied to a local operation platform. The vehicle positioning device 40 includes: a data acquisition module 41, a parsing module 42, an acquisition module 43, and a positioning module 44; wherein,

[0137] Data acquisition module 41 is used to collect call detail records (CDRs) of vehicles;

[0138] The parsing module 42 is used to parse the call detail records of the vehicle to obtain the vehicle's routing area code, core network node location, and access operator address.

[0139] The acquisition module 43 is used to acquire a first weight, a second weight, and a third weight. The first weight is used to characterize the routing area code weight coefficient, the second weight is used to characterize the weight coefficient of the core network node location, and the third weight is used to characterize the weight coefficient of the access operator address.

[0140] The positioning module 44 is used to locate the vehicle based on the routing area code, the core network node location, the access operator address, and the corresponding first weight, second weight, and third weight.

[0141] In one possible implementation, the first weight is determined by the signal strength of the wireless link between the vehicle's onboard terminal and the cellular network base station, the second weight is determined by the network load, and the third weight is determined by the vehicle's roaming status.

[0142] In one possible implementation, the first weight is calculated using the following formula:

[0143]

[0144] Wherein, α is the first weight, and the signal strength The signal strength of the wireless link between the vehicle's onboard terminal and the cellular network base station.

[0145] In one possible implementation, the second weight is calculated using the following formula:

[0146] β = 0.3 * (1 - network) load );

[0147] Wherein, β is the second weight, and the network load For network load.

[0148] In one possible implementation, when the vehicle is in a roaming state, the third weight is a first preset value; when the vehicle is not in a roaming state, the third weight is a second preset value.

[0149] In one possible implementation, the positioning module 44 is specifically used to normalize the first weight, the second weight, and the third weight to obtain a first coefficient, a second coefficient, and a third coefficient, wherein the first coefficient is the normalized value corresponding to the first weight, the second coefficient is the normalized value corresponding to the second weight, and the third coefficient is the normalized value corresponding to the third weight.

[0150] The vehicle is located based on the routing area code, the core network node location, the access operator address, and the corresponding first coefficient, second coefficient, and third coefficient.

[0151] In one possible implementation, the acquisition module 41 is further configured to evenly distribute the vehicle's call details to multiple partitions based on the amount of data.

[0152] In one possible implementation, the acquisition module 41 is also used to assign call detail records (CDRs) of the same vehicle to the same partition.

[0153] In one possible implementation, the vehicle's call detail record (CDR) is a billing gateway (CG) CDR.

[0154] Figure 4 The vehicle positioning device 40 provided in the embodiment can be used to execute the technical solution of the method embodiment shown in this application, and its implementation principle and technical effect can be further referred to the relevant description in the method embodiment.

[0155] It should be understood that the division of the various modules of the vehicle positioning device 40 described above is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented in software via processing element calls, while others are implemented in hardware. For example, the detection module can be a separate processing element, or it can be integrated into a chip in the terminal device. The implementation of other modules is similar. In addition, these modules can be fully or partially integrated together, or they can be implemented independently. During implementation, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0156] For example, these modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more Digital Signal Processors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, these modules can be integrated together as a System-On-a-Chip (SOC).

[0157] In the above embodiments, the processor may include, for example, a CPU, DSP, microcontroller, or digital signal processor, and may also include a GPU, embedded neural network processing unit (NPU), and image signal processor (ISP). The processor may also include necessary hardware accelerators or logic processing hardware circuits, such as an ASIC, or one or more integrated circuits for controlling the execution of the program in this application. Furthermore, the processor may have the function of operating one or more software programs, which may be stored in a storage medium.

[0158] This application also provides a readable storage medium storing a program that, when run on a local operating platform, causes the local operating platform to execute the method provided in the embodiments shown in this application.

[0159] This application also provides a program product, which includes a program that, when run on a local operating platform, causes the local operating platform to execute the method provided in the embodiments shown in this application.

[0160] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, A and B simultaneously, or B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b, and c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0161] Those skilled in the art will recognize that the units and algorithm steps described in the embodiments disclosed herein can be implemented using electronic hardware, computer software, or a combination of electronic hardware and software. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0162] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0163] In the several embodiments provided in this application, any function, if implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0164] The above description is merely a specific embodiment of this application. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application. The protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A vehicle positioning method characterized by, The method is applied to a local operation platform, and comprises the following steps: Collecting a call record of a vehicle; Analyzing the call record of the vehicle to obtain a routing area code, a core network node position and an access operator address of the vehicle; Obtaining a first weight, a second weight and a third weight, wherein the first weight is used to represent a weight coefficient of the routing area code, the second weight is used to represent a weight coefficient of the core network node position, and the third weight is used to represent a weight coefficient of the access operator address; Positioning the vehicle based on the routing area code, the core network node position and the access operator address, and the corresponding first weight, second weight and third weight.

2. The method of claim 1, wherein, The first weight is determined by a signal strength of a wireless link between a vehicle terminal of the vehicle and a cellular network base station, the second weight is determined by a network load, and the third weight is determined by a roaming state of the vehicle.

3. The method of claim 2, wherein, The first weight is obtained by calculation according to the following formula: ； wherein the a is a first weight, the signal strength is a signal strength of a wireless link between a vehicle terminal of the vehicle and a cellular network base station.

4. The method of claim 2, wherein, The second weight is obtained by calculation according to the following formula: ； wherein the β is a second weight, the network load is a network load.

5. The method of claim 2, wherein, When the vehicle is in a roaming state, the third weight is a first preset value, and when the vehicle is not in a roaming state, the third weight is a second preset value.

6. The method according to any one of claims 1 to 5, characterized in that, The positioning of the vehicle based on the routing area code, the core network node position and the access operator address, and the corresponding first weight, second weight and third weight comprises the following steps: Normalizing the first weight, the second weight and the third weight to obtain a first coefficient, a second coefficient and a third coefficient, wherein the first coefficient is a normalized value corresponding to the first weight, the second coefficient is a normalized value corresponding to the second weight, and the third coefficient is a normalized value corresponding to the third weight; Positioning the vehicle based on the routing area code, the core network node position and the access operator address, and the corresponding first coefficient, second coefficient and third coefficient.

7. The method according to any one of claims 1 to 5, characterized in that, After the collecting of the call record of the vehicle, the method comprises the following steps: Uniformly distributing the call record of the vehicle to multiple partitions according to data volume.

8. The method of claim 7, wherein, The uniformly distributing the call record of the vehicle to multiple partitions according to data volume comprises the following steps: Distributing the call record of the same vehicle to the same partition.

9. The method according to any one of claims 1 to 5, characterized in that, The call record of the vehicle is a charging gateway (CG) call record.

10. A vehicle positioning apparatus characterized by comprising: The device comprises: A collecting module configured to collect a call record of a vehicle; An analyzing module configured to analyze the call record of the vehicle to obtain a routing area code, a core network node position and an access operator address of the vehicle; An obtaining module configured to obtain a first weight, a second weight and a third weight, wherein the first weight is used to represent a weight coefficient of the routing area code, the second weight is used to represent a weight coefficient of the core network node position, and the third weight is used to represent a weight coefficient of the access operator address; A positioning module configured to position the vehicle based on the routing area code, the core network node position and the access operator address, and the corresponding first weight, second weight and third weight.

11. A vehicle positioning system, characterized by The device comprises: A local operation platform configured to perform a vehicle positioning method according to any one of claims 1-9 to position the vehicle. On the network side, a bill is generated based on the traffic consumed by the vehicle, and the bill of the vehicle is pushed to the local operation platform.

12. A readable storage medium, characterized by, The readable storage medium stores a program, and when the program runs on the local operation platform, the vehicle positioning method in any one of claims 1-9 is implemented.

Images