JP2009100047A - Mobile communication device and method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To solve the problem that a vehicle hardly performs stable communications using TCP (Transmission Control Protocol) protocol method since the method is not compatible with each access point. <P>SOLUTION: This mobile communication method is for establishing communication between a mobile element and a plurality of communication gateways and between the communication gateways and a center connected to the subject of communication of the mobile element. The mobile element and the communication gateways transmit and receive UDP (User Datagram Protocol) packet data to and from each other and the communication gateways and the center transmit and receive TCP packet data to and from each other. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a mobile communication device and a data transmission / reception system that transmit and receive data between a mobile unit and a communication target via a center connected to the Internet, and in particular, a transfer terminal between the mobile unit and the center. The present invention relates to a mobile communication device and a mobile communication method.

  In recent years, with respect to communications such as the Internet and music download in a mobile body, roaming technology that enables continuous communication, technology using a plurality of terminals such as mobile phones and wireless LAN terminals, the next communication network using movement information and travel information Various techniques for performing stable communication have been developed, such as a technique for performing stable switching by determining.

In the case of the prior art, it is possible to cope with a train that moves at a high speed but has a constant destination, or a person who moves unpredictably but has a low speed. However, since the vehicle is moving at high speed and the destination is not always specified using the navigation device, the destination may not be predicted. For this reason, there is no guarantee that sufficient communication can be performed in the vehicle. This is due to the narrow effective range of currently used communication terminals.
Further, when a vehicle performs communication, a TCP (Transmission Control Protocol) protocol method is used (for example, Patent Document 1). However, since this method is not compatible with each access point (hereinafter referred to as “AP”), stable communication is possible. It is difficult to do.
TCP realizes one-to-one communication in the form of a session, has an error correction function such as retransmission of a lost packet by packet sequence check, and is often used in a scene requiring reliability such as data transfer. Here, the TCP protocol method will be briefly described with reference to FIG. 1. First, a SYN packet 101 indicating a connection request is sent from the connecting side (for example, a vehicle). Next, the connected side (for example, the communication target) sends a SYN-ACK packet 102 in which an ACK packet indicating connection permission and a SYN packet of a connection request are combined. Finally, the ACK packet 103 is also sent from the vehicle side, and the connection is established. Thereafter, data 104 is transmitted and received.

Japanese Patent Laid-Open No. 2002-32276

By the way, each AP has an individual Internet protocol address (hereinafter referred to as “IP address”). IP defines a method for assigning addresses of devices participating in a network and selecting communication paths in a plurality of interconnected networks. IP addresses transmit and receive packets. This is a number for identifying the device.
In the case of the prior art, even when traveling within the communication area of a plurality of APs, each AP has a different IP address, so it is difficult to transmit to a plurality of APs at once, and the AP's IP is known. Otherwise, there was a difficulty that communication was not possible.
The above problem will be described with reference to FIG. Consider a case in which the vehicle 100 transmits data to the server 120 via the center 130 via the AP. When the vehicle 100 is moving, it is assumed that the vehicle 100 is within the communication range of three APs, that is, the first AP 111, the second AP 112, and the third AP 113, as shown in the figure. Here, if the IP of the first AP 111 is A, the IP of the second AP 112 is B, and the IP of the third AP 113 is C, each of the three APs has a different IP. Cannot send data to other APs. In addition, there is a problem that data cannot be transmitted unless the IP of each AP is known before data transmission. The problem is that if the vehicle is moving, it may get out of the coverage area of the specific AP while moving, and knows the IP of the specific AP in advance for data transmission. Even in this case, there is a possibility that data transmission cannot be performed. Furthermore, there is a troublesomeness to check in advance an AP that enters a communication range that changes every moment.

Further, when the response data is out of the service area before returning to the communication gateway (hereinafter referred to as “communication GW”) that has transmitted the request data, the vehicle has moved to the area of the next communication GW. This causes a problem that response data cannot be acquired.
This problem will be described with reference to FIG. When the vehicle 100 is within the range of the first communication GW 121 that is a transfer terminal, the request data is sent to each content server 150 via the vehicle manufacturer center 140 as shown by the solid line in the figure, Consider the case where the response data is returned from each content server 150 to the first communication GW 121 via the car manufacturer center 140 as shown by the dotted line in the figure. At this time, when response data is sent to the first communication GW 121 due to movement, the vehicle 100 may be out of the range of the first communication GW 121. In such a case, even if the vehicle 100 is in the range of the second communication GW 122, there arises a problem that the response data does not reach the vehicle 100 from the first communication GW 121 that has received the response data.
An object of the present invention is to realize a transfer system specialized in a vehicle that solves these problems.

  The mobile communication method of the present invention includes a mobile unit that performs communication between a mobile unit and a plurality of communication gateways, and that performs communication between the communication gateway and a center connected to a communication target of the mobile unit. A communication method is characterized in that UDP packet data is transmitted and received between the mobile unit and the communication gateway, and TCP packet data is transmitted and received between the communication gateway and the center.

  The mobile communication device of the present invention is a mobile communication device that is mounted on a mobile body and has at least a communication function, the data generation means for generating UDP packet data, the mobile body, and the mobile body Data transmission / reception means for transmitting / receiving the UDP packet data to a plurality of communication gateways for transmitting / receiving data to / from a center connectable to a communication target is provided.

  According to the configuration of the present invention, since the wireless side of the communication GW uses a fixed common IP, it is possible to transmit to all the communication GWs in the area with a single transmission, and it is necessary to know (check) the IP of the communication GW. The time required for communication can be reduced. In addition, this reduces the possibility of data transmission failure in the area, and increases the success probability of mobile communication.

  Furthermore, in the present invention, the vehicle that has transmitted the request data additionally updates the response destination on the center side by periodically transmitting specific data until the response data is acquired. The center side always has the latest source IP from the received data. This is possible for a two-stage transfer system using a communication GW and a center.

  Further, when sending response data to the vehicle, not only returning it to the latest (last registered) transmission source, but also sending it to the communication GW around it, more reliable response communication can be performed.

  Hereinafter, a mobile communication device and a mobile communication method according to the present invention will be described with reference to the drawings. However, it should be noted that the technical scope of the present invention is not limited to these embodiments, but extends to the invention described in the claims and equivalents thereof.

In the mobile communication method of the present invention, as shown in FIG. 4, first, the vehicle 1 transmits data to the communication target in the server 4 via the communication GW and the center 3. At this time, as shown in FIG. 4, for example, the request data is transmitted to the first communication GW21, the second communication GW22, and the third communication GW23, which are three communication GWs, for example. Here, all the three communication GWs have the same IP, for example, Q, and the vehicle transmits data using a UDP (User Datagram Protocol) packet. Here, the UDP system is a standard protocol used on the Internet, and unlike TCP, does not perform delivery confirmation and the like, and thus has a feature of low reliability but high transfer efficiency.
The communication GW transmits data to the center, and the center transmits data to a communication target that is a transmission destination that the vehicle originally wants to transmit. A series of processes for transmitting data from the vehicle 1 to the communication target in this way is referred to as “request transmission process”.

  Next, the vehicle 1 needs to confirm that the communication target has received data, but the response is received from the communication GW. Here, since the vehicle 1 is moving, there is a possibility that the vehicle 1 is in a communication area different from that in the request transmission processing stage in this response reception stage. I need to tell you. For this purpose, the vehicle 1 informs the communication GW of the position by periodically transmitting information. This process is called “periodic position transmission process”.

Response data for notifying that the communication target has received data or for returning a response to the vehicle 1 to which the communication target has transmitted data is first transmitted to the center 3 via the server 4, and then The data is transmitted from the center 3 to the communication GW and from the communication GW to the vehicle 1. This series of processing is called “response reception processing”.
Next, the request transmission process, the regular position transmission process, and the response reception process will be described in detail.

First, a configuration of a vehicle as an example of a mobile body that transmits and receives data and a mobile communication method according to the present invention will be described with reference to FIG.
In the mobile communication method according to the present invention, a vehicle communication gateway / access point (hereinafter referred to as “communication GW”) 2 that functions as a vehicle-specific access point having a function of relaying and connecting the vehicle 1 and the Internet network; The center facility 3 and the server 4 installed in the Internet network enable communication specialized for vehicles.
The vehicle configuration of the present invention is shown in FIG. The vehicle 1 includes a communication device 11 and a navigation device 12 that can perform wireless communication. The communication device 11 includes a control unit 13 connected to the navigation device 12, a storage unit 14 that stores data (for example, a vehicle unique ID 18), and a wireless communication terminal 17 connected to the antenna 10 for performing wireless communication. Have. Furthermore, the communication device 11 includes an input unit 15 for inputting data. The control unit 13 includes request packet data generation means 19 for generating request packet data, which will be described later, and position notification packet data generation means 20 for generating position notification packet data. The navigation device 12 includes an output device (for example, a display) 16 for outputting display data and the like. The output device 16 displays image data, audio data, and the like based on output data from the control unit 13 of the communication device 11. I do. The output device 16 may be integrated with the navigation device 12 as shown in FIG. 6, or may be separated from the navigation device. Furthermore, in the present embodiment, the configuration in which the communication device 11 and the navigation device 12 are separated is illustrated, but the communication device 11 and the navigation device 12 may be integrated. Further, a car stereo or the like capable of communication can be used instead of the navigation device.

Here, when the vehicle communicates with a specific target (communication target) of the Internet network, the vehicle transmits data to the communication GW, the communication GW transfers the data to the center, and the center acquires data from the target and performs communication. A response is returned to the GW, the communication GW communicates by returning a response to the vehicle, communication between the vehicle and the communication GW is performed using UDP packet data, and communication between the communication GW and the center is TCP It is characterized by using packet data.
Further, the communication GW has an IP unique to each communication GW that is different between the side connected to the vehicle and the Internet, and the IP on the vehicle side has an IP common to all the communication GWs.

<Request transmission processing>
Next, the request transmission process will be described with reference to the drawings. 7 and 8 schematically show a series of data processing for transferring data from vehicle → communication GW → center → communication target.

(Vehicle communication processing flow)
First, the communication processing flow of the vehicle will be described using the flowchart of FIG. The communication processing flow is started in S101 of FIG. 9, and the vehicle communication device 11 (see FIG. 6) is activated in S102. Next, in S <b> 103, the vehicle communication device 11 generates request packet data by request packet data generation means 19 (see FIG. 6) in the control unit 13 based on the input data from the input unit 15. As shown in FIG. 7, the request packet data 31 uses UDP and includes a transmission destination IP, a transmission source IP, a UDP header, and a data part. Here, the destination IP is common to a plurality of communication GWs. Further, the data part includes a vehicle unique ID, a transmission destination IP (IP to be communicated) to be originally transmitted, and request data. Here, as shown in FIG. 6, the vehicle unique ID 18 is held in the storage unit 14 in the communication device 11 and sent to the control unit 13.
Next, in S104, it is determined whether or not the vehicle is within the communication GW. If the vehicle is within the communication GW, the request UDP packet data is transmitted by the wireless communication terminal 17 as the data transmission means in S105. Here, as shown in FIG. 8, the plurality of communication GWs within the communication range of the vehicle all have the same common IP, and the request UDP packet data from the vehicle communication device 11 is transmitted to the plurality of communication GWs all at once. Sent.
Since the vehicle receives response data for confirming that the communication target has received the data, the vehicle waits for a response in S106.

(Communication GW processing flow)
Next, the processing flow of the communication GW that has received data from the vehicle as described above will be described. In the communication GW, processing for receiving data from the vehicle and processing for transmitting the received data to the center are performed. A flowchart of the processing flow of the communication GW is shown in FIG. First, the communication GW is activated in S201, and the retained data deletion process described later is performed in S202. Next, in S203, it is determined whether or not data is received from the vehicle. When data is received from the vehicle, vehicle data reception processing is performed in S204.
A vehicle data reception process flow of the communication GW will be described with reference to FIG. First, when vehicle data is received in S301, the data contents are confirmed in S302. This is performed to determine whether the received data is data for sending request data to a communication target or data for periodic position confirmation (periodic transmission) described later. Next, in S303, it is determined whether or not the received data is data for periodic transmission. Here, since it is not periodic transmission, the process proceeds to S314. In S314, it is determined whether or not the notification is a completion notification, which will be described later. In S308, “vehicle unique ID” and “source IP” are acquired from the data. Here, the source IP is a vehicle IP as shown in FIG.

  Next, in S309, it is determined whether there is the same unique ID in the retained data. Here, assuming that data transmitted by the same vehicle having a specific unique ID is received a plurality of times, it is determined whether the data is received first or after the second time. If it is received for the first time, there is no same unique ID in the retained data, so the process proceeds to S311. In S311, “unique ID” and “source IP” are held together with “timer”. As shown in FIG. 7, the timer may record time, or may be a countdown type with a set time of 60 seconds, for example. If the same vehicle receives data transmitted from the second time onward, the same unique ID is present in the retained data in S309, and the process proceeds to S310. In S310, the "timer" possessed corresponding to the vehicle unique ID is updated. That is, when data is received again before the timer setting time becomes 0, the timer setting time is returned to the initial value. Thereby, it can be confirmed whether or not the vehicle is within the communication range of the communication GW. This process is performed in all communication GWs that have received data from the vehicle. Therefore, it can be confirmed which communication GW the vehicle is in.

  In step S312, the received “data” (unique ID, communication target IP, request data) is transferred to the center. As the data to be transferred, TCP packet data 32 is used as shown in FIG. This is because both the transmission source and the transmission destination are fixed, which is desirable for stabilizing the transmission. The TCP packet data 32 includes a transmission destination IP, a transmission source IP, a TCP header, and a data part. Here, the transmission destination is fixed at the center IP. The source IP is a communication GW, but each communication GW uses an individual IP as the Internet side IP. For example, as shown in FIG. 8, each communication GW is different as XXX.Y.ZZ.B, XXX.Y.Z.D, XXX.YY.VV.C. This is for specifying the destination communication GW when returning the response data. The data portion is the same as the UDP packet data received from the vehicle by the communication GW, and includes a vehicle unique ID, a transmission destination IP to be originally transmitted, and request data as shown in FIG. When the data is transmitted to the center, the process proceeds to S313, and the received vehicle data transfer is completed.

(Center processing flow)
Next, the processing flow of the center that receives data from the communication GW will be described. The center performs a process of receiving request data from the communication GW and a process of transmitting the request data received to the communication target to the communication target.

  13A and 13B show a flowchart of the center processing flow. First, in S401, the center is activated, and initial setting is performed in S402. If the initial setting has already been completed and data reception is awaited, the process starts from S403. In S404, it is determined whether or not data is received from the communication GW. Since data is received from the communication GW here, the process proceeds to S405. In S405, it is determined whether or not the received data is periodic transmission data. Here, since it is not periodic transmission, the process proceeds to S422. In S422, in order to specify the communication target, the “communication target” IP, that is, the transmission destination IP to be originally transmitted is acquired from the data. Next, in S423, it is determined whether or not it is a completion notification. Here, since it is not a completion notification, the process proceeds to S409. In S409, “vehicle unique ID” and “source IP” are acquired from the received data.

  Next, in S410, it is determined whether there is the same unique ID in the retained data. That is, here, it is assumed that request data is received a plurality of times from the same vehicle. When data is received for the first time, since there is no same unique ID in the retained data, the process proceeds to S419, where “counter” is set to 1, “unique ID”, “source IP”, “ Along with a timer. As will be described later, the counter is used to determine whether or not a response has been made to all of the different request data when received.

  Information holding in this step will be described with reference to FIG. It is assumed that the first data (request packet) is transmitted from the vehicle 1 (vehicle unique ID: vaj2ora5b) to the first communication GW 21 (IP: XXX.Y.ZZ.B) via the route 41 at a certain time. This first data is transferred from the first communication GW 21 to the center, and the center retains the vehicle unique ID, the source IP (communication GW), the timer, and the count with the timer initial setting value set to 60 seconds as shown in Table 401. To do.

  Next, 17 seconds later, the second data (request packet) from the same vehicle 1 (vehicle unique ID: vaj2ora5b) via the route 42 to the second communication GW 22 (IP: XXX.Y.ZZ.D) Is sent. This data is transferred from the second communication GW 22 to the center. In the center, the vehicle unique ID is searched from the list for the second data. Here, the vehicle IDs match with vaj2ora5b. Furthermore, it is received after 17 seconds, and is received within the set time of the timer. As a result, it is determined that the request is the same from the same vehicle. When comparing the source IP, the IP of the first data is XXX.Y.ZZ.B, whereas the IP of the second data is different from XXX.Y.ZZ.D. As shown in the table, information on the source IP and timer is added to the list.

  Further, it is assumed that after the elapse of 21 seconds, the vehicle 1 has transmitted the third data (request packet) via the route 43 to the third communication GW 23 (IP: XXX.YY.V.C). This data is transferred from the third communication GW 23 to the center. The center searches the vehicle unique ID from the list for the third data. Here, the vehicle IDs match with vaj2ora5b. Furthermore, it has been received after 21 seconds and has been received within the set time of the timer. As a result, it is determined that the request is the same from the same vehicle. Comparing the source IP, the IP of the first data is XXX.Y.ZZ.B, the IP of the second data is XXX.Y.ZZ.D, and the IP of the third data is XXX.YY Since it is different from .VC, as shown in Table 403, information on the source IP and timer is added to the list.

  Next, in S420, the received “data” is transferred to the communication target. As shown in FIG. 7, the data is TCP packet data 33, and is composed of a transmission destination (communication target) IP, a transmission source IP (center IP), a TCP header, and request data that are originally desired to be transmitted. Thereafter, in S421, the data reception waiting state is entered.

  In S410, if there is the same unique ID in the retained data, the latest value is acquired in the “timer” corresponding to the unique ID in S411. From this timer value, it is determined in S412 whether or not a certain time has passed. If the predetermined time has not elapsed, it can be determined that the request is from the same vehicle. Therefore, in S415, it is determined whether or not the source IP is held. If the transmission source IP is held, it is determined that the transmission is received from the same communication GW, and the “timer” corresponding to the transmission source is updated in S416. If the transmission source IP is not held, it is determined that the transmission is received from a different communication GW, and in S417, the “transmission source IP” is held together with the “timer”. Thereafter, in S418, a data reception waiting state is entered.

  If a certain period of time has passed in S412, the "counter" held with the unique ID is incremented by 1 in S413, and the "timer" corresponding to the transmission source IP of the unique ID is updated in S414. Next, in S420, as shown in FIG. 8, the received "data" (request packet) is transferred to the communication target. Thereafter, in S421, the data reception waiting state is entered.

<Periodical position transmission processing>
The periodic position transmission process is conventionally performed when the vehicle has moved out of the service area before returning to the communication GW that transmitted the request and moved to the next communication GW. There was a problem that it could not be acquired, but this is solved. That is, the vehicle that transmitted the request data periodically updates the response destination on the center side by transmitting specific data periodically until the response data is acquired. The center side always has the latest destination IP from the received data. This system can be realized by a two-stage transfer system using a communication GW and a center.
Next, the periodic position transmission system will be described with reference to FIGS. 14A to 14C show the flow of data of vehicle-> communication GW-> position notification periodic transmission to the center.

(Vehicle communication processing flow)
First, the communication processing flow of the vehicle will be described using a flowchart. FIG. 10 shows a communication processing flow in the vehicle. As shown in FIG. 14A, the periodic notification for location notification is a periodic notification for location notification generated by the communication device 11 in the vehicle 1 using the location notification packet data generation means 20 (see FIG. 6) for the communication GW2. This is done by transmitting a transmission packet. As shown in FIG. 10, when the vehicle 1 has already transmitted the request data in S701 and is waiting for a response, the vehicle 1 determines whether or not a response has been received in S702. It is determined whether or not a certain time has passed. If the predetermined time has not elapsed, in S708, the communication device 11 in the vehicle 1 uses the position notification packet data generation means 20 (see FIG. 6) to generate a position notification periodic transmission packet. Next, in S709, a periodic transmission packet is transmitted. After the transmission, in S710, a response is waited for. The location notification data is transmitted to all the communication GWs using a UDP packet, similarly to the request data. As shown in FIG. 14A, the regular transmission packet 41 is composed of a transmission destination IP, a transmission source IP, a UDP header, and a vehicle unique ID. Here, as shown in FIG. 6, the vehicle unique ID 18 is held in the storage unit 14 in the communication device 11 and sent to the control unit 13.

(Communication GW processing flow)
Next, a processing flow in the communication GW that has received the periodic position notification UDP packet from the vehicle will be described with reference to the flowchart of FIG. When data is received from the vehicle, the process starts from S301, and the content of the received data is confirmed in S302. In S303, it is determined whether or not the transmission is periodic. As can be seen from a comparison of FIGS. 7 and 14A, the request data and the periodical transmission data can be distinguished from each other because the configuration of the data portion is different. In other words, the periodic transmission data does not include the transmission destination IP and the request data that are originally desired to be transmitted. If it is determined in S303 that the transmission is periodic, it is determined in S304 whether there is the same unique ID in the retained data. When the periodic position transmission data is received for the first time, since there is no possession data, the process proceeds to S307, where “unique ID” and “source IP” are retained together with “timer”. If the regular position transmission data has already been received and the second regular position transmission data has been received from the same vehicle, since the same unique ID is present in the possessed data, the process proceeds to S305 and corresponds to the vehicle unique ID. And update the "timer" you have. Next, in S306, the received “data (vehicle unique ID only)” is transferred to the center. Specifically, the data transmitted by the communication GW to the center is a regular transmission packet 42 as shown in FIG. 14B, and includes a transmission destination IP, a transmission source IP, a TCP header, and a vehicle unique ID.

(Center processing flow)
Next, the processing flow of the center that has received the periodic position communication data from the communication GW will be described. FIG. 15 shows a flowchart of the center processing flow. First, in S501, the periodic transmission reception process is started. In S502, “vehicle unique ID” and “source IP” are acquired from the received data. Next, in S503, it is determined whether there is a transmission source IP corresponding to the same unique ID in the retained data. That is, it is determined whether or not a plurality of periodic position transmission data with different communication GWs as transmission sources are received from the same vehicle. If there is a source IP corresponding to the same unique ID in the stored data, the process proceeds to S504, and the “timer” corresponding to the source IP is updated. If there is no source IP, “source IP” is determined in S505. With a “timer”. After that, in S506, the data reception waiting state is entered.

The update and addition of data in this step will be further described with reference to FIG. 14C. First, the first response holding data reference table 501 shows processing for updating a timer. That is, in a state in which the periodic position transmission data having the same vehicle unique ID is received from three communication GWs and three transmission source IPs are held, the third communication GW (IP: XXX.YY. When the periodic position notification data is newly received from VC) when the timer time is 52 seconds, the timer is updated to the initial setting time of 60 seconds.
Next, a process of deleting the transmission destination IP from the response holding data reference table when new periodic position notification data is not received within a predetermined time will be described. In other words, if the periodic position notification data is not newly received within the set timer time, it is known that the communication GW has fallen out of the communication range, and there is no need to return response data. Assuming that 32 seconds have elapsed from the response holding data reference table 501 in FIG. 14C, the timer time is 0 for the second data whose source IP is XXX.Y.ZZ.D in the table 502. . Thus, regarding the communication GW whose timer time has become 0, the data is deleted and excluded from the transmission destination of the response data. In this way, when response data is transmitted, the communication GW that is out of the communication range can be deleted, wasteful transmission processing can be eliminated, and response data transmission processing can be made more efficient.

  Next, processing for adding to the response holding data reference table for the communication GW that has newly received the periodic position notification data will be described. In FIG. 14C, the case where the vehicle moves out of the range of a certain communication GW and then enters a range of another communication GW (IP: XXD.Y.V.A) will be examined. The communication GW that has newly entered the communication range retains the transmission source IP and the vehicle unique ID together with the timer (see S307 in FIG. 12). The communication GW transmits this to the center, and the center adds data with the source IP as XXD.Y.V.A to the response holding data reference table 503, and sets the timer setting time to 60 seconds. In this way, when there is a periodic transmission from a communication GW having a transmission source IP different from the transmission source IP of the communication GW that has already been held, the vehicle is newly placed in the area within the response holding data reference table. By recording the entered communication GW, the latest communication GW in which the vehicle is in the communication range can be grasped, and response data can be reliably returned to the moving vehicle. Furthermore, although there are a plurality of communication GWs whose timers are not 0, by having a plurality of communication GWs for transmitting response data, not only the communication GW closest to the vehicle but also a plurality of communication around it. Response data can also be transmitted from the GW, and the probability that the moving vehicle receives the response data can be increased.

<Response reception process>
Next, data processing when response reception processing is performed will be described. FIGS. 16A and 16B show an outline of a series of processes in which a communication target that has received data transmits response data from the communication target → center → communication GW → vehicle. The data processing procedure in the center and communication GW will be described using a flowchart.

(Response processing at the center)
FIG. 18 shows a flowchart of the response processing flow in the center. In step S601, center response processing is started. In step S602, it is confirmed that response data has been received from a communication target that has received data from the vehicle. As shown in FIG. 16B, the response data is TCP packet data 51, and includes a transmission destination IP (center IP), a transmission source IP, a TCP header, and response data. The data includes a vehicle unique ID and response data.

Next, in S603, all transmission source IPs corresponding to the unique ID of the vehicle that returns a response are acquired. For example, as shown in FIG. 17, referring to the response holding data reference table 601, the vehicle unique ID is vaj2ora5b, and the transmission source IP is XXX.Y.ZZ.B, XXX.YY.VC, XXD.YVA. For the three or more communication GWs, the timer is not 0 and data is stored.
Next, in step S604, the acquired transmission source IP (IP of the communication GW) is used as a transmission destination, and “vehicle unique ID” and “response data” are added and transmitted. That is, as shown in FIG. 17, response transmission is performed for all of the three communication GWs held. The data transmitted from the center to the communication GW is TCP packet data 52, which includes a transmission destination IP (IP of the communication GW), a transmission source IP, a TCP header, and a data portion. The data portion includes a vehicle unique ID and response data. included. Thereafter, the center enters a data reception waiting state.

(Response reception processing in communication GW)
Since the communication GW receives the response data from the center, the processing flow starts from S205 in FIG. When the communication GW receives response data from the center, the “vehicle unique ID” is acquired from the data and compared with the data held. In S207, it is determined whether or not the received unique ID is possessed. If it is held, in S208, the corresponding transmission source IP (vehicle IP) is set as the transmission destination, and the response data in the reception data is transmitted to the vehicle. If not, the received data is discarded in S209.
That is, as shown in FIG. 16A, the communication GW searches the correspondence table between the vehicle unique ID and the transmission destination IP already held by the communication GW from the received unique ID, and retrieves the response destination vehicle from the unique ID. . As shown in FIG. 16A, the vehicle IP found in the search is set as the destination IP, the source IP, the UDP header, and the response data are added to form the UDP packet data 53. Each communication GW is as shown in FIG. Send data to the vehicle. If the received unique ID is not held, it is determined that the vehicle has already moved out of the communication GW, so the received data is discarded in S209.

(Response reception processing flow in the vehicle)
Whether or not the vehicle has received a response is determined in S702 of FIG. 10, and if a response is received, a completion notification packet is transmitted in S703.

<Completion notification process>
When the vehicle receives the response data, it is necessary to notify the center of the result and notify that the response processing has been completed. Therefore, when the response data is received, the vehicle transmits a completion notification to the center via the communication GW. Here, the completion notification process will be described.

(Vehicle completion notification process)
As shown in the lower part of FIG. 16A, the completion notification data that the vehicle transmits to the center via the communication GW is UDP packet data 61, and includes a transmission destination IP (communication GW common IP), a transmission source IP, and a UDP. Consists of header and completion notification data. The completion notification data includes a vehicle unique ID, a transmission destination IP (center IP) to be originally transmitted, and a determination ID. Here, the determination ID is an ID (response data determination ID) for identifying the response data, such as the upper few bits of the response data. By sending the completion notification data in the UDP packet format, it can be transmitted to all the communication GWs all at once in a short time.

(Completion notification process in communication GW)
The communication GW that has received the completion notification data from the vehicle transfers it to the center. At this time, the UDP packet system is changed to the TCP packet system and transmitted. By transmitting by the TCP packet method, it can be transmitted to the center reliably.
The completion notification data transmitted to the center by the communication GW is TCP packet data 62, as shown in FIG. 16B, and includes a transmission destination IP (center IP), a transmission source IP, a TCP header, and completion notification data. The completion notification data is the same as the data part that the vehicle transmits to the communication GW.

(Completion notification processing at the center)
If the center receives data from the communication GW while waiting for reception in S403 in the processing flow of FIG. 13A, the center proceeds from S404 to S405, and determines whether or not the transmission is periodic. Here, since it is not regular transmission, it progresses to S422. In S422, the “communication target” IP is acquired from the data. The communication target is a transmission destination originally desired to be transmitted, and the communication target is the center in the completion notification process. Next, as shown in FIG. 13B, in S423, it is determined whether or not the received data is a completion notification. As shown in FIG. 16B, this determination is made as a completion notification if the original transmission destination in the data is the center IP. If it is a completion notification, the process proceeds to S424, and a completion notification process is performed.

  Next, the completion notification process performed at the center will be described with reference to the process flow of FIG. Completion notification reception processing starts from S801. In S802, a “determination ID” is acquired from the data. As described above, the determination ID is included in the completion notification data as shown in FIG. 12B and is used to determine the response data. This response data determination ID only needs to be identifiable when a plurality of response data exists, such as response data upper few bits. Next, in S803, it is determined whether or not the “determination ID” received within a certain time. That is, it is assumed that the completion notification data is transmitted from the vehicle to a plurality of communication GWs. In this case, the completion notification received within a certain time from the time when the completion notification data is first received is used as a base point. The data can be considered that the same vehicle has transmitted completion notification data for the same response data.

  If it is within the predetermined time, the process proceeds to S804, and the second and subsequent completion notification data are discarded. By discarding, even when a plurality of completion notification data is received for one response data, it can be counted only once. By associating a certain response data with the corresponding completion notification data, It is possible to avoid counting repeatedly.

  If it is not within the predetermined time in S803, the process proceeds to S805, and “vehicle unique ID” is acquired from the data. The acquired vehicle unique ID can identify from which vehicle the completion notification is issued, and even when the completion notification is simultaneously received from a plurality of vehicles, the completion processing can be appropriately performed. Next, in S806, the value of the “counter” held together with the unique ID is decremented by one. That is, when one response completion data is received, it is possible to confirm that completion notification has been made for all data waiting for completion notification by reducing the count of the data held by one. For example, if the vehicle sends n request data and the center sends n response data, the count is “n” and the count is decremented by 1 each time one completion notification data is received. By doing so, it is possible to grasp the reception status of the completion notification from the count number.

Next, in S807, it is determined whether or not the value of the “counter” is zero. If it is 0, in S808, all the data held together with the counter of 0 is deleted. That is, a counter value of 0 means that completion notification processing has been performed for all response data. Thereafter, in S810, data reception is awaited.
If the value of the “counter” is not 0 in S807, the determination ID is stored in S809. Thereafter, in S810, data reception is awaited.

  In the above embodiments, the vehicle has been described as an example of the moving body. However, the present invention is not limited to this, and can be applied to other moving bodies that move at high speed, such as airplanes and helicopters, where the moving destination is not determined. It is.

  In the present embodiment, the data processing from one vehicle has been described. However, the present invention can also be applied to a case where a plurality of vehicles transmit and receive data simultaneously.

An outline of a communication method using TCP will be described. The request transmission in the conventional vehicle communication is shown. It is the schematic of the problem of the conventional vehicle communication. The outline | summary of the request transmission in the vehicle-specific transfer system of this invention is shown. The structure of the communication system of this invention is shown. It is explanatory drawing of the vehicle structure of this invention. The Example of data communication in the request transmission process of this invention is shown. The Example of data communication in the request transmission process of this invention is shown. The communication processing flow in the vehicle of this invention is shown. The communication processing flow in the vehicle of this invention is shown. The processing flow in communication GW of the present invention is shown. The vehicle data reception processing flow in the communication GW of this invention is shown. The processing flow in the center of this invention is shown. The processing flow in the center of this invention is shown. The Example of data communication in the regular position transmission process of this invention is shown. The Example of data communication in the regular position transmission process of this invention is shown. The Example of data communication in the regular position transmission process of this invention is shown. The flow of regular transmission reception processing in the center of the present invention is shown. The Example of data communication in the response reception process of this invention is shown. The Example of data communication in the response reception process of this invention is shown. The Example of data communication in the response reception process of this invention is shown. The center response processing flow in the center of this invention is shown. 3 shows a completion communication reception flow of the present invention.

Explanation of symbols

1 vehicle 3 center 4 server 10 antenna 11 communication device 12 navigation device 13 control unit 14 storage unit 15 input unit 16 output device 17 wireless communication terminal 18 vehicle unique ID
19 Request packet data generation means 20 Location notification packet data generation means 21 First communication GW
22 Second communication GW
23 Third communication GW
31 UDP packet data including request data transmitted from the vehicle to the communication GW 32 TCP packet data including request data transmitted from the communication GW to the center 33 TCP packet data including request data transmitted from the center to the communication target 41 Vehicle UDP packet data including periodic transmission data transmitted from the communication GW to the communication GW 42 TCP packet data including periodic transmission data transmitted from the communication GW to the center 51 TCP packet data including response data transmitted from the communication target to the center 52 Center TCP packet data including response data transmitted to the communication GW 53 UDP packet data including response data transmitted to the vehicle by the communication GW 61 UDP packet data including completion notification data transmitted from the vehicle to the communication GW 62 Communication GW TCP packet data including completion notification data sent to the center Vehicle 111 first 1AP
112 Second AP
113 3rd AP
120 server 121 first communication GW
122 Second communication GW
130 Center 140 Car manufacturer center 150 Each content server 501 Response holding data reference table 502 Response holding data reference table 503 Response holding data reference table 601 Response holding data reference table

Claims (6)

While communicating between a mobile unit and multiple communication gateways,
A mobile communication method for performing communication between the communication gateway and a center connected to a communication target of the mobile,
Send and receive UDP packet data between the mobile and the communication gateway,
A mobile communication method, wherein TCP packet data is transmitted and received between the communication gateway and the center. The UDP packet data has an IP common to a plurality of the communication gateways as a destination Internet protocol (IP),
The mobile communication method according to claim 1, wherein the TCP packet data has a unique IP for a plurality of the communication gateways as a source IP. Transmitting the mobile unit unique ID unique to the mobile unit and the request data addressed to the communication target to the center via the communication gateway;
Periodically transmitting periodic location transmission data including the mobile unit unique ID;
The center possesses the periodic location transmission data together with the IP of the communication gateway through which the periodic location transmission data was transmitted,
The center deletes the periodic position transmission data when the center does not receive the periodic position transmission data including the same mobile unit unique ID and the same communication gateway IP within a predetermined time. 3. The mobile communication method according to 1 or 2. The center receives response data for the request data from a communication target of the mobile;
Transmitting the mobile unit unique ID and the response data with the communication gateway IP in the periodic location transmission data held by the center as a destination IP;
The communication gateway that has received the response data has a step of transmitting the response data with the mobile IP corresponding to the mobile unique ID as a transmission destination,
The mobile receives and holds initial response data for the request data;
4. The mobile communication method according to claim 3, wherein second and subsequent response data for the request data is discarded. A mobile communication device mounted on a mobile body and having at least a communication function,
Data generation means for generating UDP packet data;
And a data transmission / reception means for transmitting / receiving the UDP packet data to / from a plurality of communication gateways for transmitting / receiving data between the mobile body and a center connectable to a communication target of the mobile body. Body communication device. The mobile communication device includes data generation means for generating request data addressed to the communication target;
Data transmission means for transmitting the request data;
Data generating means for generating periodic position transmission data including a mobile unit unique ID unique to the mobile unit;
6. The mobile communication apparatus according to claim 5, further comprising data transmission means for periodically transmitting the periodic position transmission data to the center via the communication gateway.

Images