Data packet distribution method and device
By using QoS flow identifiers to identify the vehicular network service to which data packets belong in the vehicular network system, the security and network burden issues of the existing IP address-based traffic splitting method are solved, achieving efficient and secure data splitting.
Patent Information
- Application Number
- CN202411996290.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-31
- Publication Date
- 2025-12-23
AI Technical Summary
In existing vehicle-to-everything (V2X) systems, data offloading based on IP addresses suffers from low security and high network load. Furthermore, base stations require significant processing power to identify the IP address of each data packet, which reduces network efficiency.
By identifying the QoS flow identifier of data packets through access network equipment, the vehicle-to-everything (V2X) service to which the data packet belongs can be determined, and traffic can be distributed according to the service characteristics. This avoids identifying the IP address of each data packet and utilizes the redundant computing power of the base station for processing.
It improves the security and efficiency of data offloading, reduces network load, meets the specific needs of different vehicle-to-everything (V2X) services, and reduces the consumption of computing resources.
Smart Images

Figure CN121194253A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of communication, and particularly relates to a data packet shunting method and device. BACKGROUND
[0002] The Internet of Vehicles is a network system in which vehicles are connected through wireless communication technology. The Internet of Vehicles system enables vehicles to wirelessly communicate and exchange information with other vehicles, road infrastructure, pedestrians and the Internet. The Internet of Vehicles cloud control platform in the Internet of Vehicles system can process various Internet of Vehicles services, such as vehicle platooning, sensor sharing, etc. SUMMARY
[0003] The present application aims to at least partly solve one of the problems in the related art.
[0004] To this end, a first object of the present application is to provide a data packet shunting method.
[0005] A second object of the present application is to provide a data packet shunting device.
[0006] A third object of the present application is to provide an electronic device.
[0007] A fourth object of the present application is to provide a computer-readable storage medium.
[0008] A fifth object of the present application is to provide a computer program product.
[0009] To achieve the above objects, a first aspect of the present application provides a data packet shunting method, comprising:
[0010] receiving a data packet sent by a first vehicle, and determining a quality of service (QoS) flow to which the data packet belongs;
[0011] obtaining a QoS identifier corresponding to the QoS flow; wherein the QoS identifier is used to mark data packets of the QoS flow;
[0012] determining an Internet of Vehicles service to which the data packet belongs according to the QoS identifier;
[0013] shunting the data packet according to the Internet of Vehicles service.
[0014] To achieve the above objects, a second aspect of the present application provides a data packet shunting device, comprising:
[0015] a receiving module configured to receive a data packet sent by a first vehicle;
[0016] a first determining module configured to determine a quality of service (QoS) flow to which the data packet belongs;
[0017] The acquisition module is configured to acquire a QoS identifier corresponding to the QoS flow; wherein the QoS identifier is used to mark a data packet of the QoS flow.
[0018] The second determination module is configured to determine, according to the QoS identifier, an Internet of Vehicles service to which the data packet belongs.
[0019] The data shunting module is configured to shunt the data packet according to the Internet of Vehicles service.
[0020] To achieve the above object, a third aspect of the present application provides an electronic device, comprising:
[0021] a processor, and a memory connected with the processor in communication;
[0022] The memory stores computer execution instructions.
[0023] The processor executes the computer execution instructions stored in the memory to implement the method according to the first aspect of the embodiment.
[0024] To achieve the above object, a fourth aspect of the present application provides a computer readable storage medium, wherein the computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by a processor to implement the method according to the first aspect of the embodiment.
[0025] To achieve the above object, a fifth aspect of the present application provides a computer program product, comprising a computer program, wherein the computer program is executed by a processor to implement the method according to the first aspect of the embodiment.
[0026] The data packet shunting method and device, electronic device and storage medium provided by the present application can determine the QoS flow to which the received data packet belongs, identify the QoS identifier corresponding to the QoS flow, determine the Internet of Vehicles service to which the data packet belongs, and then shunt the data packet according to the Internet of Vehicles service to which the data packet belongs. Thus, the data packet is shunted according to the QoS identifier corresponding to the QoS flow to which the data packet belongs, which is highly secure, does not require the access network device to identify the IP address of each data packet, saves computing resources, reduces the network burden, improves the data processing efficiency, and improves the data shunting efficiency while fitting the characteristics of various Internet of Vehicles services.
[0027] Additional aspects and advantages of the present application will be in part apparent and in part pointed out hereinafter. BRIEF DESCRIPTION OF DRAWINGS
[0028] The above and / or additional aspects and advantages of the present application will become apparent and be readily appreciated from the following description, taken in conjunction with the accompanying drawings, in which:
[0029] Figure 1 A flowchart of a data packet shunting method provided by an embodiment of the application;
[0030] Figure 2 A schematic diagram of a networking architecture for vehicle networking based on a Uu interface provided by an embodiment of the application;
[0031] Figure 3 A schematic diagram of establishing a QoS flow provided by an embodiment of the application;
[0032] Figure 4 A data shunting schematic diagram provided by an embodiment of the application;
[0033] Figure 5 A flowchart of another data packet shunting method provided by an embodiment of the application;
[0034] Figure 6 A flowchart of another data packet shunting method provided by an embodiment of the application;
[0035] Figure 7 A schematic diagram of an information interaction flow provided by an embodiment of the application;
[0036] Figure 8 A schematic diagram of a data packet shunting device provided by an embodiment of the application. DETAILED DESCRIPTION
[0037] Embodiments of the application are described in detail below with reference to the accompanying drawings, in which the same or similar notations used throughout the drawings and the specification denote the same or similar elements or elements with the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to explain the application, and cannot be understood as limiting the application.
[0038] The data packet shunting method, device, electronic equipment and storage medium of the embodiments of the application are described below with reference to the accompanying drawings.
[0039] Figure 1 A flowchart of a data packet shunting method provided by an embodiment of the application;
[0040] In some embodiments, vehicle networking can adopt a networking mode of a Uu interface, such as Figure 2In the illustrated Uu interface-based vehicle networking architecture, the on-board terminal (5G On Board Unit, 5G OBU) is connected to the base station through the Uu interface, while the roadside facilities such as cameras and traffic lights are connected to the base station through the Uu air interface via the road side gateway (Road Side Gateway, RSG), and the base station is deployed with a vehicle networking server, such as a vehicle to everything (V2X) server, for providing edge computing power. The OBU is a hardware device installed on a vehicle for implementing V2X communication.
[0041] As shown in Figure 2 The Uu interface-based vehicle networking architecture includes four major parts: terminal, edge, network, and cloud. The terminal can be a vehicle equipped with a 5G OBU. The edge includes RSG, roadside facilities (such as traffic lights and cameras), and a 5G base station. The base station is deployed with a V2X server for local edge computing services. The network is the core network, and the cloud is the V2X cloud control platform, which can be used to handle public network services.
[0042] In some embodiments, the data shunting module can adopt an IP shunting strategy by checking the destination IP address / prefix of the uplink data packet sent by the terminal, using an IP NAT strategy to determine how the data packet is routed, and shunting public network service data and local V2X service data according to different IP addresses.
[0043] However, there may be cases where unauthorized data services are obtained by falsifying IP addresses to deceive the data shunting module, and this shunting method has low security. In addition, the base station needs a large amount of processing power to identify the IP address of each data packet, which will increase the network burden and reduce the overall efficiency of the network.
[0044] To solve this problem, the embodiments of the present application provide a data packet shunting method, which can be applied to a Uu interface-based vehicle networking architecture. The method can be executed by an access network device in a vehicle networking system, such as a base station. As shown in Figure 1 The data packet shunting method includes the following steps:
[0045] Step 101, receiving a data packet sent by a first vehicle and determining the QoS flow to which the data packet belongs.
[0046] In this application, the first vehicle can be any vehicle in the vehicle networking system, and the first vehicle can send data packets to the access network device that establishes a connection. The access network device can receive the first data packet sent by the first vehicle.
[0047] In this application, when a vehicle establishes a connection, the Protocol Data Unit (PDU) session can respond to different services by establishing multiple Quality of Service (QoS) streams.
[0048] For example, each established QoS flow can be assigned a unique QoS Flow Identifier (QFI) when communicating between the vehicle and the network. For example, when the vehicle sends a data packet, this QFI can be included in the header of the data packet, so that the access network device can identify the QoS flow to which the data packet belongs based on the QFI in the data packet.
[0049] To facilitate understanding, the following will be combined with... Figure 3 To explain, Figure 3 This is a schematic diagram illustrating the establishment of a QoS flow according to an embodiment of this application. Figure 3 As shown, when a terminal establishes a connection, the PDU session responds to different services by establishing multiple QoS flows, such as QoSFlow1, QoSFlow2, and other QoS flows. Among these, a dedicated QoSFlow2 and its corresponding radio bearer are established for local V2X service traffic offloading services. QoSFlow2 can be dedicated to local V2X service data flows, while QoSFlow1 and other QoS flows correspond to the same radio bearer. Furthermore, base stations in the radio access network and UPF network elements in the core network can communicate through Next Generation User Plane (NG-U) tunnels.
[0050] Step 102: Obtain the QoS identifier corresponding to the QoS flow.
[0051] In this application, based on different service characteristics, the data packets of each established QoS flow can be classified and marked using QoS identifiers, with data packets belonging to the same QoS flow being marked with the same QoS identifier. For example, if 5G communication is used between the vehicle and the access network equipment, then each QoS flow can be classified and marked using a 5G QoS identifier (5QI).
[0052] For example, the QoS identifier can be a scalar that can label packets of different QoS flows based on different values.
[0053] In the present application, the access network device can obtain the QoS identifier corresponding to the QoS flow from the core network. For example, the User Plane Function (UPF) network element in the core network can define the QoS identifier of the QoS flow, and the UPF can send the defined QoS identifier to the access network device. For example, the access network device can receive a message sent by the UPF network element through the NG-U interface, and the message can carry the QoS identifier of the QoS flow, so that the access network device can obtain the QoS identifier corresponding to the QoS flow from the message.
[0054] In step 103, the vehicle networking service to which the data packet belongs is determined according to the QoS identifier.
[0055] In the present application, the mapping relationship between the QoS identifier and the service can be established in advance and configured to the access network device. Then, the access network device can determine the service corresponding to the QoS identifier by querying the mapping relationship according to the QoS identifier corresponding to the QoS flow to which the data packet belongs, and determine the vehicle networking service corresponding to the QoS identifier as the vehicle networking service to which the data packet belongs. In this way, the vehicle networking service can be identified according to the QoS identifier, and the accuracy of identification is improved.
[0056] For example, different vehicle networking services may have different requirements for latency and data rate, so the mapping relationship between the QoS identifier, the QoS requirement and the service can be established, and the vehicle networking service to which the data packet belongs can be determined according to the corresponding relationship between the QoS identifier and the service in the mapping relationship.
[0057] For example, the QoS identifier is 5QI, and the vehicle networking service to which the data packet belongs can be determined according to the mapping relationship between 5QI and the service. For example, 5QI=50 corresponds to the vehicle platoon, and 5QI=52 corresponds to the cooperative lane change. If the 5QI corresponding to the QoS flow to which the data packet belongs is 50, then the vehicle networking service to which the data packet belongs is the vehicle platoon.
[0058] It should be noted that the values of the above-mentioned 5QI and the corresponding vehicle networking services are only examples and should not be regarded as a limitation of the present application.
[0059] In step 104, the data packet is split according to the vehicle networking service.
[0060] In the present application, different vehicle networking services may have different requirements for latency, so the data packet can be split according to the requirements of the vehicle networking service for latency or real-time performance.
[0061] For example, if the access network device has a vehicle-to-everything (V2X) server deployed within it, and the V2X service has high latency requirements or is based on vehicle location information, then data packets can be offloaded to the local V2X server for processing. This not only reduces latency but also fully utilizes the redundant computing power of the access network device, alleviating network load. Conversely, if the V2X service has low latency requirements and does not require vehicle location information, data packets can be offloaded to the V2X cloud control platform for processing.
[0062] For example, for Figure 2 The Uu interface-based vehicle networking architecture shown allows for low-latency, remotely connected vehicle networking services to be processed by the core network's V2X cloud control platform. For latency-sensitive, location-based vehicle networking services, the OBU and RSG connect to the base station via the Uu interface and are routed to the base station's local V2X Server for processing, thus making full use of the base station's redundant computing power.
[0063] Figure 4 This is a schematic diagram of data splitting provided for an embodiment of this application. Figure 4 In this process, local V2X service data and public network service data sent by the terminal pass through the Physical Layer (PHY), Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCH), and the User Plane Part of GTP (GTP-U) of GPRS, before reaching the data offloading module. Local V2X service data is offloaded to the V2X Server at the base station, while public network service data is offloaded to the UPF network elements in the core network. GPRS stands for General Packet Radio Service. Local V2X service data can refer to V2X service data processed by the V2X Server at the base station. Figure 4 The terminal shown can be a vehicle equipped with an OBU.
[0064] In the embodiments of the present application, by determining the QoS flow to which the received data packet belongs, the QoS identifier corresponding to the QoS flow is identified, the vehicle networking service to which the data packet belongs is determined, and then the data packet is shunted according to the vehicle networking service to which the data packet belongs. Thus, the data packet is shunted according to the QoS identifier corresponding to the QoS flow to which the data packet belongs, which is highly secure, does not require the access network device to identify the IP address of each data packet, saves computing resources, reduces network burden, improves data processing efficiency, and improves the efficiency of data shunting while fitting the characteristics of various vehicle networking services.
[0065] Figure 5 The flowchart of another data packet shunting method provided in the embodiments of the present application is shown.
[0066] As shown in Figure 5 , the data packet shunting method can include the following steps:
[0067] Step 501: receiving a data packet sent by a first vehicle and determining a QoS flow to which the data packet belongs.
[0068] In the present application, step 501 can adopt any implementation manner in the embodiments of the present application, and thus will not be described here.
[0069] Step 502: obtaining a QoS identifier corresponding to the QoS flow.
[0070] In the present application, step 502 can adopt any implementation manner in the embodiments of the present application, and thus will not be described here.
[0071] Step 503: determining a vehicle networking service to which the data packet belongs according to the QoS identifier.
[0072] In the present application, step 503 can adopt any implementation manner in the embodiments of the present application, and thus will not be described here.
[0073] Step 504: determining the type of the vehicle networking service.
[0074] In the present application, for the vehicle networking service based on vehicle location information, additional information such as positioning information of the vehicle and cell identifier can be added in the header of the data packet. For example, the additional information can be added in the variable length field in the header of the data packet.
[0075] The positioning information of the vehicle can be positioning coordinates, such as Global Positioning System (GPS) coordinates, and can be used to calculate the spatial position of the vehicle and the spatial relationship with surrounding objects. For example, the longitude and latitude in the positioning information can be in a sexagesimal time-second format, for example, 121 degrees 36 minutes 37.16 seconds east longitude, and the data size can be 4+4+8=16 bytes, so the data size of the longitude and latitude can each be 16 bytes, and the total size is 32 bytes.
[0076] The cell identifier can be an identifier of a cell in which the vehicle is currently located, and can be used for cell switching during vehicle travel. For example, the data size of the cell identifier can be 2 bytes.
[0077] As can be seen, for the vehicle-to-everything service based on vehicle location information, 34 bytes of additional information, such as vehicle positioning information and cell identifier, can be added in the variable length field in the header of the data packet of the vehicle-to-everything service, which does not exceed the limit of the maximum optional field of 40 bytes.
[0078] In this application, the data packet can be identified to determine whether the data packet carries the positioning information of the first vehicle. For example, the header of the data packet can be parsed to determine whether the header of the data packet carries the positioning information of the first vehicle. The QoS identifier corresponding to the QoS requirement corresponding to the QoS flow to which the data packet belongs can also be obtained, wherein the QoS requirement can include a data rate requirement, a latency requirement, etc. The type of the vehicle-to-everything service to which the data packet belongs can be determined according to whether the data packet carries the positioning information of the vehicle and / or the latency requirement in the QoS requirement. This type of vehicle-to-everything service determination is relatively simple and convenient.
[0079] Because the QoS requirements of different services can be different, for example, a mapping relationship between the QoS identifier, the QoS requirement, and the service can be established in advance, and according to the mapping relationship, the QoS requirement corresponding to the QoS identifier corresponding to the QoS flow to which the data packet belongs can be determined.
[0080] For example, if the data packet carries the first positioning information of the vehicle, it can be determined that the vehicle-to-everything service to which the data packet belongs is a first type of vehicle-to-everything service. The first type of vehicle-to-everything service can be a vehicle-to-everything service based on vehicle location information. That is, if the data packet carries the first positioning information of the vehicle, it can be determined that the vehicle-to-everything service is a vehicle-to-everything service based on vehicle location information.
[0081] For example, if the QoS requirement corresponding to the QoS identifier has a higher latency requirement, such as a required latency less than or equal to a preset threshold, it can be determined that the vehicle networking service to which the data packet belongs is a second type of vehicle networking service. The second type of vehicle networking service can refer to a latency-sensitive vehicle networking service.
[0082] It should be noted that the first type of vehicle networking service and the second type of vehicle networking service can overlap, such as some vehicle networking services based on vehicle location information that have high latency requirements.
[0083] For example, if the data packet does not carry the positioning information of the first vehicle and the QoS requirement has a latency greater than a preset threshold, it can be determined that the vehicle networking service to which the data packet belongs is a third type of vehicle networking service. The third type of vehicle networking service can refer to a vehicle networking service that does not require vehicle location information and has a latency greater than a preset threshold, i.e., a vehicle networking service that does not require vehicle location information and has a relatively low latency requirement.
[0084] At step 505, the data packet is split according to the type of vehicle networking service.
[0085] In this application, if the vehicle networking service to which the data packet belongs is a first type of vehicle networking service or a second type of vehicle networking service, the data packet can be split to a local vehicle networking server for processing by the vehicle networking server. That is, for vehicle networking services based on vehicle location information or latency-sensitive vehicle networking services, their data packets can be split to a local vehicle networking server for processing, which not only reduces latency but also fully utilizes the redundant computing power of the access network equipment.
[0086] If the vehicle networking service to which the data packet belongs is a third type of vehicle networking service, the data packet can be split to a vehicle networking cloud control platform for processing.
[0087] For example, V2X services based on vehicle location information can be split to a V2X server local to the base station for processing, latency-sensitive V2X services can be split to a V2X server local to the base station for processing, and services that do not require vehicle location information and have a low latency requirement can be split to a core network V2X cloud control platform for processing.
[0088] Thus, part of the vehicle networking service can be sunk to the local access network equipment for processing, which not only reduces the load of the core network vehicle networking cloud control platform but also fully utilizes the redundant computing power of the base station, achieving low-latency and fast-response of service data transmission.
[0089] In the present application, the multiple QoS flow mappings formed by different vehicle networking services can be two data radio bearers (DRBs), such as DRB#1 responsible for transmitting uplink and downlink public network services, including processing public network V2X data packets with an interaction UPF; and DRB#2 responsible for transmitting local V2X services, including processing V2X data packets with a local edge V2X server.
[0090] For example, if the vehicle networking service to which the data packet belongs is the first type of vehicle networking service or the second type of vehicle networking service, the data packet can be shunted to the local vehicle networking server through the first data radio bearer corresponding to the QoS flow to which the data packet belongs. For example, if the vehicle networking service to which the data packet belongs is the third type of vehicle networking service, the data packet can be shunted to the vehicle networking cloud control platform through the second data radio bearer corresponding to the QoS flow to which the data packet belongs. In this way, the data packet is transmitted through the corresponding DRB, improving the accuracy of data packet transmission.
[0091] In the embodiments of the present application, the vehicle networking service to which the data packet belongs is determined according to the QoS identifier, the type of the vehicle networking service is determined, and the data packet is shunted according to the type of the vehicle networking service, so that the data packet shunting conforms to the characteristics of the vehicle networking service, improving the accuracy of data shunting.
[0092] Figure 6 The flowchart of another data packet shunting method provided by the embodiments of the present application is shown.
[0093] As shown in Figure 6 The data packet shunting method can include the following steps:
[0094] Step 601, receiving a data packet sent by a first vehicle and determining a QoS flow to which the data packet belongs.
[0095] In the present application, step 601 can adopt any implementation manner in the embodiments of the present application, and therefore will not be repeated here.
[0096] Step 602, obtaining a QoS identifier corresponding to the QoS flow.
[0097] In the present application, step 602 can adopt any implementation manner in the embodiments of the present application, and therefore will not be repeated here.
[0098] Step 603, determining a vehicle networking service to which the data packet belongs according to the QoS identifier.
[0099] In the present application, step 603 can adopt any implementation manner in the embodiments of the present application, and therefore will not be repeated here.
[0100] Step 604, in response to the vehicle networking service being any service in the first service set, the data packet is shunted to the local vehicle networking server.
[0101] Step 605, in response to the vehicle networking service being any service in the second service set, the data packet is shunted to the vehicle networking cloud control platform.
[0102] In this application, the first service set and the second service set can be set, the services in the first service set can be shunted to the local vehicle networking server for processing, and the services in the second service set can be shunted to the vehicle networking cloud control platform for processing. If the data packet received from the first vehicle belongs to the vehicle networking service in the first service set, the data packet can be shunted to the local vehicle networking server. If the data packet received from the first vehicle belongs to the vehicle networking service in the second service set, the data packet can be shunted to the vehicle networking cloud control platform.
[0103] For example, the first service set and the second service set can include the identifiers of the respective services. The identifier of the vehicle networking service to which the data packet belongs can be compared with the identifiers in the first service set. If any identifier in the first service set is consistent with the identifier of the vehicle networking service, the data packet is shunted to the local vehicle networking server. If the identifier of the vehicle networking service to which the data packet belongs is inconsistent with the identifiers in the first service set, the identifier of the vehicle networking service to which the data packet belongs can be compared with the identifiers in the second service set. If any identifier in the second service set is consistent with the identifier of the vehicle networking service, the data packet is shunted to the vehicle networking cloud control platform.
[0104] For example, the data packet received from the first vehicle belongs to the cooperative lane changing, which is a service in the first service set. The data packet is shunted to the local vehicle networking server.
[0105] In the embodiment of the application, the data packet is shunted according to whether the vehicle networking service to which the data packet belongs is a service in the first service set or a service in the second service set, which improves the data shunting efficiency and accuracy.
[0106] In an embodiment of the application, for the first type of vehicle networking service, the data packet is shunted to the vehicle networking server local to the access device, such as V2X Server, for processing by edge computing power. The local vehicle networking server can analyze and process the spatial position relationship of multiple vehicles according to the service demand, and broadcast the processing result through the Uu air interface via the access network device.
[0107] For example, if the vehicle networking service to which the data packet received from the first vehicle belongs is the first type of vehicle networking service, the data packet can carry the positioning information, cell identification information, etc. of the first vehicle, the data packet is shunted to the local vehicle networking server, the local vehicle networking server can process the data packet to determine the spatial position information of the first vehicle, and then send the spatial position information to the second vehicle, so that the second vehicle can perform operations matched with the vehicle networking service.
[0108] For the convenience of understanding the following Figure 7 For the convenience of understanding the following Figure 7 An information interaction process schematic diagram provided by the embodiment of the application is described.
[0109] Figure 7 In the embodiment, the vehicle 1 sends a data packet to the base station through a Uu port, the header structure of the data packet contains GPS information and cell ID information of the vehicle, the base station identifies the 5QI of the data packet after receiving the data packet, and learns from the 5QI of the data packet that the data packet belongs to a V2X service based on vehicle position information, and contains the GPS information and cell ID information of the vehicle. Then, the base station transmits the data packet to the local V2X Server for processing, such as calculating the spatial position information of the vehicle 1, and the V2X Server sends the calculation result to the vehicle 2 through the base station by the Uu port, and the vehicle 2 can perform vehicle formation, cooperative lane changing, obstacle avoidance, etc. using the received spatial position information. Figure 7 The base station shown is a sensing-integrated base station, that is, the sensing capability is superimposed on the basis of cellular communication, and the sensing integration is realized on the base station side.
[0110] In the embodiment of the application, if the vehicle networking service to which the data packet belongs is the first type of vehicle networking service, the header of the data packet carries the positioning information and cell identification information of the first vehicle, the data packet is shunted to the vehicle networking server local to the access network device, the vehicle networking server local to the access network device can process the data packet to determine the spatial position information of the first vehicle, and then send the spatial position information to the second vehicle, thereby realizing information interaction between vehicles and improving the processing efficiency of the vehicle networking service based on vehicle position information.
[0111] In the application, the QoS identifier of the data packet itself maps the QoS requirements of the service, such as the requirements for delay and data rate, etc. The data packet shunting method of the application shunts data according to different 5QIs, and processes the needs of different V2X services in a targeted manner. For example, for services with high delay requirements, the data is preferentially shunted to the local V2X Server for processing, which can effectively reduce the load of the core network UPF while ensuring low delay and fast response. Therefore, the data packet shunting method of the application is more suitable for the characteristics of various V2X services.
[0112] In addition, compared with the IP data shunting method, the QoS identifier of the data packet is faster than the IP address in identifying, can quickly determine the shunting direction, improves the data processing efficiency, and reduces the network burden.
[0113] To achieve the above-mentioned embodiments, the application further provides a data packet shunting device. The data packet shunting device can be applied to an access network device.
[0114] Figure 8 A structural schematic diagram of a data packet shunting device provided by the embodiments of the application.
[0115] As shown in Figure 8 the data packet shunting device 800 includes:
[0116] The receiving module 810 is configured to receive a data packet sent by a first vehicle.
[0117] The first determining module 820 is configured to determine a quality of service (QoS) flow to which the data packet belongs.
[0118] The obtaining module 830 is configured to obtain a QoS identifier corresponding to the QoS flow, wherein the QoS identifier is used to mark the data packet of the QoS flow.
[0119] The second determining module 840 is configured to determine an Internet of Vehicles (IoV) service to which the data packet belongs according to the QoS identifier.
[0120] The data shunting module 850 is configured to shunt the data packet according to the IoV service.
[0121] In a possible implementation manner of the embodiments of the application, the data shunting module 840 is configured to:
[0122] determine a type of the IoV service.
[0123] shunt the data packet according to the type of the IoV service.
[0124] In a possible implementation manner of the embodiments of the application, the data shunting module 850 is configured to:
[0125] in response to the IoV service being a first type of IoV service or a second type of IoV service, shunt the data packet to a local IoV server, wherein the first type of IoV service refers to an IoV service based on vehicle location information, and the second type of IoV service refers to a time delay sensitive IoV service.
[0126] In response to the V2X service being a third type of V2X service, the data packet is shunted to a V2X cloud control platform; the third type of V2X service refers to a V2X service that does not require vehicle location information and has a latency greater than a preset threshold.
[0127] In a possible implementation manner of the embodiment of the application, the data shunting module 850 is configured to:
[0128] In response to the V2X service being a first type of V2X service or a second type of V2X service, the data packet is transmitted to a local V2X server through a first data radio bearer corresponding to the QoS flow; the first type of V2X service refers to a V2X service based on vehicle location information, and the second type of V2X service refers to a latency-sensitive V2X service.
[0129] In response to the V2X service being a third type of V2X service, the data packet is transmitted to a V2X cloud control platform through a second data radio bearer corresponding to the QoS flow; the third type of V2X service refers to a V2X service that does not require vehicle location information and has a latency greater than a preset threshold.
[0130] In a possible implementation manner of the embodiment of the application, the data shunting module 850 is configured to:
[0131] The data packet is identified to determine whether the data packet carries positioning information of the first vehicle;
[0132] The QoS requirement corresponding to the QoS identifier is acquired;
[0133] The type of the V2X service is determined according to whether the data packet carries the positioning information and / or a latency requirement in the QoS requirement.
[0134] In a possible implementation manner of the embodiment of the application, the data shunting module 850 is configured to:
[0135] In response to the V2X service being any service in the first service set, the data packet is shunted to a local V2X server;
[0136] In response to the V2X service being any service in the second service set, the data packet is shunted to a V2X cloud control platform.
[0137] In a possible implementation manner of the embodiment of the application, the second determining module 840 is configured to:
[0138] A mapping relationship between a QoS identifier and a service is acquired;
[0139] According to the QoS identifier, a service corresponding to the QoS identifier is determined by querying the mapping relationship.
[0140] The service corresponding to the QoS identifier is determined as the Internet of Vehicles service to which the data packet belongs.
[0141] In a possible implementation manner of the embodiment of the present application, the Internet of Vehicles service is a first type of Internet of Vehicles service, and the data packet is shunted to a local Internet of Vehicles server. The apparatus can further include:
[0142] The parsing module is configured to process the data packet to determine spatial position information of the first vehicle. The header of the data packet carries positioning information and cell identification information of the first vehicle.
[0143] The sending module is configured to send the spatial position information to a second vehicle, so that the second vehicle performs an operation matched with the Internet of Vehicles service.
[0144] In a possible implementation manner of the embodiment of the present application, the obtaining module 830 is configured to:
[0145] The receiving module is configured to receive a message sent by a user plane function (UPF) network element through a next-generation user plane (NG-U) interface. The message carries a QoS identifier of the QoS flow.
[0146] The obtaining module is configured to obtain the QoS identifier from the message.
[0147] It should be noted that the foregoing explanation and description of the data packet shunting method embodiment are also applicable to the data packet shunting apparatus of the embodiment, which will not be described herein again.
[0148] In the embodiment of the present application, by determining the QoS flow to which the received data packet belongs, the QoS identifier corresponding to the QoS flow is identified, the Internet of Vehicles service to which the data packet belongs is determined, and then the data packet is shunted according to the Internet of Vehicles service to which the data packet belongs. Thus, the data packet is shunted according to the QoS identifier corresponding to the QoS flow to which the data packet belongs. The security is high, the IP address of each data packet does not need to be identified by the access network device, the computing resources are saved, the network burden is reduced, the data processing efficiency is improved, and the data shunting efficiency is improved while fitting the characteristics of various Internet of Vehicles services.
[0149] To implement the foregoing embodiments, the present application further provides an electronic device, including a processor and a memory connected with the processor in communication; the memory stores computer execution instructions; and the processor executes the computer execution instructions stored in the memory to implement the method provided in the foregoing embodiments.
[0150] To achieve the above-mentioned embodiments, the present application further provides a computer readable storage medium, wherein the computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by a processor to implement the method provided by the foregoing embodiments.
[0151] To achieve the above-mentioned embodiments, the present application further provides a computer program product, comprising a computer program, wherein the computer program is executed by a processor to implement the method provided by the foregoing embodiments.
[0152] The collection, storage, use, processing, transmission, provision and disclosure of user personal information involved in the present application comply with relevant laws and regulations and do not violate public order and good customs.
[0153] It should be noted that the personal information from the user should be collected for legal and reasonable purposes, and should not be shared or sold outside these legal uses. In addition, such collection / sharing should be carried out after the user's informed consent is received, including but not limited to informing the user to read the user agreement / user notice before the user uses the function, and signing the agreement / authorization including authorization of relevant user information. In addition, any necessary steps should be taken to protect and ensure access to such personal information data, and to ensure that other people with access to personal information data comply with their privacy policy and processes.
[0154] The present application is expected to provide embodiments in which the user can selectively prevent the use or access of personal information data. That is, the present disclosure is expected to provide hardware and / or software to prevent or block access to such personal information data. Once the personal information data is no longer needed, the risk is minimized by limiting data collection and deleting data. In addition, such personal information is de-identified, if applicable, to protect the privacy of the user.
[0155] In the foregoing embodiment description, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative description of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. In addition, the skilled in the art can combine and combine the different embodiments or examples described in the present specification and the features of the different embodiments or examples, without contradiction.
[0156] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0157] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.
[0158] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.
[0159] It should be understood that parts of the present application can be realized in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be realized as software or firmware stored in a memory and executed by a suitable instruction execution system. As such, if realized in hardware, and in another embodiment, any one or a combination of the following technologies known in the art can be used: discrete logic circuitry having logic gates for implementing logic functions on data signals, application specific integrated circuits having appropriate combinational logic gates, programmable gate arrays (PGA), field programmable gate arrays (FPGA), and the like.
[0160] Those skilled in the art of the present technology can understand that all or part of the steps carried out by the above-mentioned embodiments can be completed by a program instructing the relevant hardware, and the program can be stored in a computer readable storage medium. When the program is executed, it includes one of the steps of the method embodiments or a combination thereof.
[0161] In addition, each functional unit in each embodiment of the present application can be integrated into one processing module, or each unit can exist physically alone, or two or more units can be integrated into one module. The above-mentioned integrated module can be realized in the form of hardware or in the form of a software functional module. When the integrated module is realized in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer readable storage medium.
[0162] The above-mentioned storage medium can be a read-only memory, a magnetic disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it should be understood that the above-mentioned embodiments are exemplary and cannot be understood as limiting the present application, and those skilled in the art can make changes, modifications, replacements and variations to the above-mentioned embodiments within the scope of the present application.
Claims
1. A data packet splitting method, characterized in that, Performed by an access network device, the method includes the following steps: Receive the data packet sent by the first vehicle and determine the Quality of Service (QoS) flow to which the data packet belongs; Obtain the QoS identifier corresponding to the QoS flow; wherein, the QoS identifier is used to mark the data packets of the QoS flow; Based on the QoS identifier, determine the vehicle-to-everything (V2X) service to which the data packet belongs; The data packets are distributed according to the vehicle-to-everything (V2X) service.
2. The method according to claim 1, characterized in that, The step of routing the data packets according to the vehicle-to-everything (V2X) service includes: Determine the type of the vehicle-to-everything (V2X) service; The data packets are divided according to the type of the vehicle-to-everything (V2X) service.
3. The method according to claim 2, characterized in that, The step of routing the data packets according to the type of the vehicle-to-everything (V2X) service includes: In response to the vehicle-to-everything (V2X) service being either a first-type V2X service or a second-type V2X service, the data packet is diverted to the local V2X server; wherein, the first-type V2X service refers to a V2X service based on vehicle location information, and the second-type V2X service refers to a latency-sensitive V2X service; In response to the fact that the vehicle-to-everything (V2X) service is a third type of V2X service, the data packet is diverted to the V2X cloud control platform; wherein, the third type of V2X service refers to a V2X service that does not require vehicle location information and has a latency greater than a preset threshold.
4. The method according to claim 2, characterized in that, The step of routing the data packets according to the type of the vehicle-to-everything (V2X) service includes: In response to the vehicle-to-everything (V2X) service being either a first type of V2X service or a second type of V2X service, the data packet is transmitted to the local V2X server via the first data radio bearer corresponding to the QoS stream; wherein, the first type of V2X service refers to a V2X service based on vehicle location information, and the second type of V2X service refers to a latency-sensitive V2X service. In response to the fact that the vehicle-to-everything (V2X) service is a third type of V2X service, the data packet is transmitted to the V2X cloud control platform through the second data wireless bearer corresponding to the QoS stream; wherein, the third type of V2X service refers to a V2X service that does not require vehicle location information and has a latency greater than a preset threshold.
5. The method according to claim 2, characterized in that, Determining the type of the vehicle-to-everything (V2X) service includes: The data packet is identified to determine whether it carries the location information of the first vehicle. Obtain the QoS requirements corresponding to the QoS identifier; The type of vehicle-to-everything (V2X) service is determined based on whether the data packet carries the location information and / or the latency requirement in the QoS requirements.
6. The method according to claim 1, characterized in that, The step of routing the data packets according to the vehicle-to-everything (V2X) service includes: In response to the fact that the vehicle-to-everything (V2X) service is any one of the services in the first service set, the data packet is diverted to the local V2X server; In response to the fact that the vehicle-to-everything (V2X) service is any service in the second service set, the data packet is diverted to the V2X cloud control platform.
7. The method as described in claim 1, characterized in that, The step of determining the vehicle-to-everything (V2X) service to which the data packet belongs based on the QoS identifier includes: Obtain the mapping relationship between QoS identifiers and services; Based on the QoS identifier, the service corresponding to the QoS identifier is determined by querying the mapping relationship; The service corresponding to the QoS identifier is determined as the vehicle-to-everything (V2X) service to which the data packet belongs.
8. The method according to any one of claims 1-7, characterized in that, The vehicle-to-everything (V2X) service is a type 1 V2X service, the data packets are diverted to a local V2X server, and the method further includes: The data packet is processed to determine the spatial location information of the first vehicle; wherein the header of the data packet carries the positioning information and cell identifier information of the first vehicle; The spatial location information is sent to the second vehicle so that the second vehicle can perform an operation that matches the vehicle-to-everything (V2X) service.
9. The method according to any one of claims 1-7, characterized in that, The step of obtaining the QoS identifier corresponding to the QoS flow includes: Receive a message sent by a User Plane Function (UPF) network element through the Next Generation User Plane (NG-U) interface; wherein the message carries the QoS identifier of the QoS flow; Obtain the QoS identifier from the message.
10. A data packet splitting device, characterized in that, include: The receiving module is used to receive data packets sent by the first vehicle; The first determining module is used to determine the Quality of Service (QoS) flow to which the data packet belongs; An acquisition module is used to acquire the QoS identifier corresponding to the QoS flow; wherein the QoS identifier is used to mark the data packets of the QoS flow; The second determining module is used to determine the vehicle-to-everything (V2X) service to which the data packet belongs based on the QoS identifier; The data splitting module is used to split the data packets according to the vehicle networking service.