JP2010153995A - Packet communication method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a packet communication method capable of securing sufficient reception bands for data of high priority, while permitting various communication states simultaneously. <P>SOLUTION: If a RFCOMM connection by Bluetooth (R) is completed between a local device (30) and a remote device (14) (ST50), an initial credit 7 is informed to the remote device (14). If variation of multi-profile state is detected, a local device (30) packet is transmitted from the remote device (14) until the current credit becomes 0 (ST51-ST61), and standby continues for a standby time and the number of packets is decreased to 1 (ST62-ST65). Thereby, bands relatively assigned to other communication processing can be secured, and priority can be given to communication. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a packet communication method for transmitting and receiving packet data between a plurality of devices.

  2. Description of the Related Art Conventionally, there is known a wireless communication method suitable for data transmission / reception that has continuity such as an audio signal and a video signal and needs to ensure real-time property (see, for example, Patent Document 1). In this prior art, when a communication apparatus performs data communication with another device, when a plurality of devices are detected as communication targets, a device that requires real-time property is distinguished from other devices. In addition, communication with a device that does not require real-time property is established first, and then an audio signal is transmitted to the device that requires real-time property. In the prior art, while data transmission is being performed with a device that requires real-time performance in a communication apparatus, detection of other devices and communication with a device that has already established communication are not performed.

  According to the above-described prior art, for example, while an audio signal or the like is being transmitted from an audio device to a communication device, communication with a mobile phone that is another device is not performed in principle. In this case, for example, communication with the audio device is prioritized until the transmission of the audio signal for one song is completed, so that it is considered that the audio can be reproduced without losing the real time property.

Further, in the prior art, even when priority is given to reproduction and transfer of audio data, for example, when there is an incoming call to the mobile phone, communication with the mobile phone can be executed by interrupt processing. For this reason, normally, priority is given to real-time, and when a situation requiring urgency such as a telephone call occurs, communication can be switched there, so that communication can be executed in a mode according to the user's request. Conceivable.
JP 2006-352799 A

  However, the above prior art gives priority to a device that requires real-time performance, and greatly sacrifices communication with other devices. For this reason, the prior art communication method is not very convenient for the user. For example, even if a user tries to use a plurality of devices at the same time, the prior art technique has the inconvenience that other devices cannot be used until the transmission of data requiring real-time performance is completed.

  However, simply allowing data transmission from multiple devices at the same time would impose pressure on the data reception bandwidth that requires real-time performance, and when playing audio, etc. The quality will be degraded.

  In recent years, with the diversification of products compatible with Bluetooth (registered trademark), cases in which a plurality of devices simultaneously execute different applications in one communication system are increasing. For example, during data access by an application using a dial-up or a serial port, music playback by another audio application may be started, or a voice call by another hands-free application may be started. In such a case, there is an increasing demand for giving priority to the sound quality of audio reproduction and giving priority to the sound quality of voice calls without interrupting any communication.

  Therefore, in view of the above circumstances, the present invention intends to provide a packet communication method capable of ensuring a sufficient reception band for high priority data while allowing various communication states at the same time. is there.

  Solution 1: The present invention is a packet communication method used in a communication system including a local device and a remote device having a function of performing communication using a plurality of communication profiles. Specifically, when the communication between the local device and the remote device is started, the remote device is notified in advance of the number of packets that can be received by the local device, and the data corresponding to the notified number of packets is transmitted from the remote device to the local device. This is a packet communication method for transmitting and receiving a desired amount of packet data while repeating the communication process received by the device. In addition, the packet communication method of the present invention is characterized by the following steps.

(1) Detection process This process determines which communication profile is used for communication processing among a plurality of communication profiles when the local device executes communication processing with any remote device. It is to detect.

  In other words, since the communication profile specifies the communication protocol used by itself, the communication profile used in the communication process is detected to identify the communication state of the communication process. Can do.

(2) Decrease step This step is for another communication that is different from the current one with the same specific remote device or another remote device while the local device is performing communication processing with the specific remote device. When it is detected that another communication process has been executed using the profile, the local device can reduce the number of receivable packets notified to a specific remote device in the currently executing communication process. In the communication processing using the communication profile, the number of packets that can be received by the local device is relatively increased.

  As a result, the bandwidth of the currently executing communication process is relatively narrowed due to the decrease in the number of packets, while the bandwidth that can be allocated to the communication processing using another communication profile can be relatively widened. . For this reason, it is possible to continue the data communication in the communication system in parallel without sacrificing any communication processing while increasing the throughput of the communication processing that is intentionally given priority.

  Solution 2: The packet communication method of Solution 1 may further include the following steps.

(3) Standby process This process is a process in which a local device is performing communication processing with a specific remote device, and another communication different from the current with the same specific remote device or another remote device. When it is detected that another communication process has been executed using the profile, a waiting time is inserted into the currently executed communication process.

  By adding such a process, it is possible to allocate a necessary band for a communication process to be given higher priority in addition to securing a band by the reduction process of (2) above.

  Solution 3: In the solution 2, in the step of inserting a waiting time, the waiting time is inserted before the local device notifies the specific remote device of the number of packets that can be received in the currently executed communication process. Is preferred.

  As described above, in this packet communication method, data cannot be transmitted from the remote device to the local device until the number of packets that can be received from the local device is notified. Therefore, if a waiting time is inserted before the number of packets that can be received from the local device to the remote device is inserted, a delay occurs in the current communication process, so that the priority of another communication process is relatively increased. Can do.

  Solution 4: In the packet communication methods of Solution 1 to 3, in the step of relatively increasing the number of packets, another communication profile is required to have more real-time characteristics than the current communication profile. In some cases, it is preferable to reduce the number of packets in the currently executing communication process.

  With such an aspect, priority is not given simply to the communication process started later, but it is possible to reliably give priority to the communication process with the higher priority in view of the characteristics of the communication profile.

  Solution 5: Alternatively, in the packet communication method of solutions 1 to 3, the step of relatively increasing the number of packets is used when another communication profile receives audio data or voice call data at the local device. Or if it is used when data transfer from the remote device to the local device needs to be completed within a predetermined time It is preferable to reduce the number of packets.

  Similarly, in this case, in addition to being able to reliably give priority to the communication process with the higher priority in view of the characteristics of the communication profile, it is necessary to complete the data transfer within a predetermined time. If communication processing that is intentionally prioritized is started, it can be surely prioritized.

  Solution 6: In the packet communication methods of Solution 1 to 5, communication processing performed between a local device and a remote device is in accordance with credit-based flow control defined by the RFCOMM protocol in a specific short-range wireless communication standard. A procedure for notifying the remote device of the number of packets that can be received by the local device from the local device to the remote device, and a procedure for reducing the credit number at the remote device each time packet data is transmitted from the remote device to the local device. .

  In this case, while the credit amount remains in the remote device, packet data can be transmitted from the remote device to the local device. On the other hand, when the credit amount does not remain, the remote device transfers from the local device to the remote device. Packet data cannot be transmitted.

  For example, when Bluetooth (registered trademark) is used as a specific short-range wireless communication standard, the credit-based flow control defined by the RFCOMM protocol is an essential function. It is possible to realize a packet communication method that is advantageous also from the viewpoint of mutual connectivity between the two.

  As described above, according to the packet communication method of the present invention, it is possible to secure a necessary band for a communication process to be given higher priority while simultaneously executing communication processes using various communication profiles. As a result, it is possible to prevent deterioration of the quality of data communication with real-time characteristics and improve user convenience, or to complete transfer of data that is intentionally prioritized at an early stage.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

[Outline of communication system]
FIG. 1 is a diagram schematically illustrating a configuration example of a communication system 10. The communication system 10 includes, for example, an in-vehicle electrical unit 12 mounted on a car as a local device, and various portable devices 14, 16, and 18 brought into the car as remote devices. Each of the in-vehicle electrical unit 12 and the portable devices 14, 16, and 18 has a wireless communication function that conforms to the Bluetooth (registered trademark) standard. In the following description, Bluetooth (registered trademark) is abbreviated as “BT”.

[In-vehicle electrical unit]
The in-vehicle electrical unit 12 has, for example, a travel route guidance (navigation) function, an audio playback function, a video playback function, a reception function such as a radio and a television, and the like. For this reason, the in-vehicle electrical unit 12 includes a display unit 20 using a liquid crystal display or the like, an operation unit 22 having a push switch, a key switch, a rotary knob, etc. (not shown), a speaker 24 for sound output, Peripheral devices such as a microphone 26 are attached.

  In addition, the in-vehicle electrical unit 12 includes a control unit 28 that controls the peripheral devices, and also includes a BT module 30 in order to exhibit a wireless communication function using BT. The control unit 28 is a microcomputer including a central processing unit such as a CPU, a ROM, and a memory device such as a RAM. Further, the BT module 30 can provide a service (for example, wireless connection) using BT communication with the in-vehicle electrical unit 12 (the control unit 28) as a host.

[Portable equipment]
The portable devices 14, 16, and 18 are electronic devices that can be carried and used by a user, such as a portable music player, a portable information terminal, and a cellular phone. In any case, the BT module (not shown) is also built in the portable devices 14, 16, and 18, and the portable devices 14, 16, and 18 can each exhibit a wireless communication function using the BT by using the BT module. .

[Characteristics of communication system]
The communication system 10 mentioned here has a single in-vehicle electrical unit 12 as its local device, but a plurality of portable devices 14, 16, 18 are used as remote devices to be communicated by the local device. Can be included. Accordingly, the operation of the communication system 10 can include the following two states, for example.

(1) Multi-connection This communication state is a case where the in-vehicle unit 12 that is a local device simultaneously performs communication (data reception) for a plurality of remote devices (mobile devices 14 to 18). For example, when the mobile devices 14 to 18 each execute an application that performs BT communication, the operation of the communication system 10 is multi-connection.

(2) Multi-profile In this communication state, the in-vehicle unit 12 communicates simultaneously with any one of the portable devices 14 to 18 or with a plurality of portable devices 14 to 18 using a plurality of communication profiles. This is the case. For example, not only a standard voice call function but also a data communication function or a music playback function is attached to the mobile device 18 (mobile phone). In this case, since a plurality of applications can be used simultaneously in one portable device 18, if the communication profile is different for each application, the operation of the communication system 10 becomes a multi-profile.

  Alternatively, even if the mobile devices 14 to 18 are each executing an application that uses a single communication profile, when a different communication profile is used for each of the mobile devices 14 to 18 in the multi-connection state of (1) above, The operation of the communication system 10 is multi-connection and multi-profile.

  In the present embodiment, based on the fact that the operation of the communication system 10 changes to a plurality of communication states (particularly multi-profile) as described above, a communication method that dynamically controls communication processing performed in the communication system 10 is adopted. is doing. Hereinafter, the details of the communication method employed in the present embodiment will be described.

[Configuration example of BT module]
First, an example of a hardware configuration necessary for dynamically controlling communication processing will be described. FIG. 2 is a block diagram schematically showing a hardware configuration example of the BT module 30.

  The BT module 30 includes, for example, a built-in BT antenna 32 and an RF circuit 34, and the BT standard between the BT antenna 32 and the RF circuit 34 with other BT devices (here, portable devices 14 to 18). Wireless communication can be performed.

  The BT module 30 includes a baseband unit 36 and a protocol stack 38. Among these, the baseband unit 36 converts a signal received by the RF circuit 34 into an IF signal, demodulates it, and packet data (reception) Packet). The protocol stack 38 is a stack register having a certain storage capacity, for example, and packet data generated by the baseband unit 36 is sequentially accumulated (stacked) therein. The protocol stack 38 is a FIFO format.

  Further, the packet data for transmission (transmission frame) from the BT module 30 is also sequentially stored in the protocol stack 38, and the packet data for transmission extracted from this is modulated by the baseband unit 36 described above, and RF The signal is transmitted to the portable devices 14 to 18 through the circuit 34 and the BT antenna 32.

  The BT module 30 includes a data transmission processing unit 40 and a data reception processing unit 42, and the transmission packet data is sequentially transferred from the data transmission processing unit 40 to the protocol stack 38. On the other hand, the received packet data stored in the protocol stack 38 is sequentially read out by the data reception processing unit 42.

  The BT module 30 supports a plurality of communication profiles with respect to transmission processing by the data transmission processing unit 40. Specifically, the BT module 30 includes a DUN / SPP data transmission processing unit 46 and another profile data transmission processing unit 50, and the plurality of processing units 46 and 50 cover the multi-profile function. Among these, the DUN / SPP data transmission processing unit 46 performs data transmission processing using a dial-up network profile and a serial port profile. The other profile data transmission processing unit 50 performs data transmission processing using a profile other than those described above.

  Further, regarding the data reception processing, the BT module 30 similarly includes a DUN / SPP data reception processing unit 52 and another profile data reception processing unit 54. Among these, the DUN / SPP data reception processing unit 52 performs data reception processing using a dial-up network profile and a serial port profile. The other profile data reception processing unit 54 performs data reception processing using a profile other than those described above.

[Credit-based flow control]
Regarding the data transmission processing and data reception processing (communication processing) by the multi-profile described above, the BT module 30 uses the credit-based flow control of essential functions defined by the RFCOMM protocol. For this reason, the BT module 30 has a credit transmission processing unit 44. The credit transmission processing unit 44 receives credit (from the local device (vehicle unit 12) to any one of the remote devices (mobile devices 14 to 18). Free credit). An example of credit-based flow control will be described later.

  The BT module 30 has a multi-profile state detection unit 48, and this multi-profile state detection unit 48 detects a change in the state of communication processing by the BT module 30 during the multi-profile operation. Specifically, in addition to the dial-up network profile and serial port profile described above, communication processing has been executed using, for example, an advanced audio distribution profile (A2DP), a hands-free profile (HFP), etc. as another profile. Detecting or detecting that the communication process has ended.

  When the multi-profile state detection unit 48 detects a change in state during the multi-profile operation as described above, the multi-profile state detection unit 48 operates the number of credits transmitted by the credit transmission processing unit 44 and controls communication processing by credit-based flow control. Generate a trigger. An example of a specific control method will be described later.

  In addition, the BT module 30 includes a HOST inter-module control unit 56. The HOST inter-module control unit 56 uses the host 28 as the host (HOST). And control the communication between the BT module 30.

  For example, when the user performs an operation relating to BT communication through the operation unit 22 of the in-vehicle unit 12, an operation signal is transmitted from the host-side control unit 28 to the HOST inter-module control unit 56, and in response thereto, the HOST inter-module control unit 56 controls the operation of the DUN / SPP data transmission processing unit 46 and the other profile data transmission processing unit 50. Further, the HOST inter-module control unit 56 outputs the packet data received by the DUN / SPP data reception processing unit 52 and the other profile data reception processing unit 54 to the control unit 28 on the host side. Thereby, for example, audio data or voice call data received from the portable device 18 by BT communication can be output from the speaker 24 of the in-vehicle unit 12, or voice picked up by the microphone 26 can be transferred to the portable device 18. become.

[Packet communication method]
Next, an example of the packet communication method used in the communication system 10 of this embodiment will be described.

  FIG. 3 is a flowchart illustrating an example of a procedure of communication processing executed by the BT module 30. This reception process is started after the RFCOMM connection is completed between the in-vehicle unit 12 that is a local device and the mobile devices 14 to 18 that are remote devices in the communication system 10. It should be noted that since a well-known one can be applied to the RFCOMM connection sequence in BT communication, the details thereof are omitted here.

  When the RFCOMM connection is completed, the credit transmission processing unit 44, the DUN / SPP data transmission processing unit 46, the other profile data transmission processing unit 50, and the DUN / SPP data reception processing in the BT module 30 as well as the inter-HOST module control unit 56 described above. The communication processing is executed using components having arithmetic processing functions such as the unit 52 and the other profile data reception processing unit 54.

  In this communication processing, a condition for triggering is given to the multi-profile state detection unit 48 in advance, and the credit transmission processing by the credit transmission processing unit 44 is dynamically operated according to the trigger condition during communication, A reception band during data access by an application using a serial port is allocated to another application. Hereinafter, it demonstrates along the example of a procedure.

  Step S10: In credit-based flow control in the RFCOMM protocol, the BT module 30 first sets the value of the free credit by the credit transmission processing unit 44 to “0”.

  Step S12: Next, the BT module 30 sets the value of the current credit in the mobile devices 14 to 18 as remote devices to the value of the initial credit (for example, “7”) in the local device.

  Step S14: The BT module 30 sets “mode 1” as the communication processing mode.

  Step S16: Next, the BT module 30 confirms the communication state by the multi-profile state detection unit 48 (detection step).

  Step S18: Then, the BT module 30 determines whether or not a condition that triggers in the multi-profile state detection unit 48 is satisfied (whether or not the condition of “condition C” is satisfied) from the above result. For example, it can be determined that the condition of “condition C” is satisfied in the following cases.

[Trigger condition for condition C]
(1) The fact that the multi-profile state detection unit 48 has changed the state of the audio application from “stopped” to “playing” while the audio application is operating concurrently with dial-up or data access using a serial port. If detected. Since real-time processing is required for communication processing during the operation of the audio application, this is set as a trigger condition.

(2) While the hands-free application is operating in parallel with dial-up or data access using the serial port, the multi-profile state detection unit 48 changes the state of the hands-free application from “SLC connected” to “busy”. When it is detected. In this case, since it is necessary to prioritize the sound quality of the HFP call and the reception processing of the HFP control data, this is set as a trigger condition.

(3) While the personal information manager application (OPP, PBAP) is operating simultaneously with dial-up or data access using a serial port, the multi-profile state detection unit 48 changes the status of these applications from “SLC connected” to “ When it is detected that the status has changed to “Acquiring data”. In this case as well, since it is necessary to prioritize the data reception process, this is used as a trigger condition. In addition, it is necessary to prioritize data reception processing during the operation of the personal information manager application (OPP, PBAP). For example, data such as an address book is received from portable devices 16 and 18 such as portable information terminals and cellular phones. In consideration of this, it is necessary to complete the data transfer within a predetermined time (for example, several seconds to several tens of seconds).

  In particular, if the trigger conditions (1) to (3) are not satisfied (step S18: No), the BT module 30 proceeds to step S20.

  Step S20: Since it is currently set to “mode 1” (Yes), the BT module 30 executes step S22 here.

  Step S22: In this case, the BT module 30 executes “RFCOMM data reception and credit transmission processing 1”. When returning from this process, the BT module 30 returns to step S16 and continues to check the communication state by the multi-profile state detection unit 48 (detection step).

  On the other hand, when any of the trigger conditions (1) to (3) is satisfied (step S18: Yes), the BT module 30 proceeds to step S24.

  Step S24: In this case, the BT module 30 executes “RFCOMM data reception and credit transmission processing 2”.

  Step S26: Next, the BT module 30 sets “mode 2” as the communication processing mode. Then, the BT module 30 returns to step S16 and continues to check the communication state by the multi-profile state detection unit 48.

  Until any of the trigger conditions (1) to (3) is not satisfied (step S18: Yes), the BT module 30 proceeds to step S24 and executes “RFCOMM data reception and credit transmission process 2”. (Loop from step S16 to step S26).

  Thereafter, when any of the trigger conditions (1) to (3) is not satisfied (step S18: No), the BT module 30 proceeds to step S20 and confirms the current mode.

  Step S20: Since “mode 2” is set at this time (No), step S28 is executed next.

  Step S28: The BT module 30 executes “RFCOMM data reception and credit transmission correction processing”.

[RFCOMM data reception and credit transmission processing 1]
FIG. 4 is a flowchart showing an example of the procedure of “RFCOMM data reception and credit transmission process 1” executed in step S22. Hereinafter, this process will be described.

Step S40: The BT module 30 starts receiving RFCOMM data.
Step S42: The BT module 30 increments the value of the free credit by “1”. As a result, one previous free credit value is added.

  Step S44: Next, the BT module 30 decrements the value of the current credit in the mobile devices 14 to 18 as remote devices by “1”. As a result, one previous current credit value is subtracted.

  Step S46: Here, the BT module 30 determines whether or not “condition A” is satisfied as a condition. “Condition A” may have the following contents, for example.

Current credit ≤ Th1 and free credit ≥ Th2
However, the initial credit of the local device = Th1 + Th2. In the above example, since the value of the initial credit is “7”, Th1 = 1 and Th2 = 6 are set here.

  In particular, when the condition of “condition A” is not satisfied (step S46: No), the BT module 30 returns to step S40 and repeats reception of RFCOMM data. Then, when the value of the free credit is incremented (step S42) and the value of the current credit is decremented instead (step S44), the BT module 30 determines again whether the condition of “condition A” is satisfied.

  Thus, the BT module 30 repeats the reception of RFCOMM data until the value of the current credit becomes Th1 = “1” or less and the value of the free credit becomes Th2 = “6” or more. Therefore, the remote device can transmit packet data to the local device until the current credit given by the initial credit value does not remain.

  Thereafter, when the value of the current credit is equal to or less than Th1 and the value of the free credit is equal to or greater than Th2, the condition of “condition A” is satisfied (step S46: Yes), so the BT module 30 next executes step S48. Execute.

  Step S48: Here, the BT module 30 transmits “free credit A” as a credit to the remote device. The “free credit A” at this time is equal to the current “free credit”. Therefore, in the above example, “6” is transmitted.

Step S50: Next, the BT module 30 resets the value of the free credit to “0”.
Step S52: The BT module 30 adds “free credit A” = “6” to the current credit value = “1” and updates the current credit value to “7”.

  As described above, in the “RFCOMM data reception and credit transmission process 1”, the communication process is performed while repeating the above procedure.

[Communication processing sequence]
FIG. 5 is a sequence diagram showing a flow of communication processing by “RFCOMM data reception and credit transmission processing 1”. In FIG. 5, the left column shows processing by the local device (BT module 30), and the right column shows processing by the remote device (for example, the portable device 18). In the following description, these are simply referred to as a local device and a remote device, respectively.

  ST1: At the initial stage of the sequence, the RFCOMM connection is completed between the local device and the remote device.

ST2: The free credit value of the local device is set to “0”.
ST3: In the remote device, the value of the current credit is set to the initial credit value of the local device = “7”. This value specifies the number of packets that can be received by the local device. In credit-based flow control defined by the RFCOMM protocol, frame transmission (transmission of packet data) is possible until the current credit value becomes “0” in the remote device.

  ST4: For this reason, the remote device transmits packet data to the local device.

ST5: When receiving the RFCOMM data, the local device increments the value of the free credit to “1”.
ST6: On the other hand, the remote device decrements the value of the current credit from “7” to “6”.

  ST7: Since the current credit still remains, the remote device transmits packet data to the local device.

ST8: When receiving the RFCOMM data, the local device increments the free credit value to “2”.
ST9: On the other hand, the remote device decrements the value of the current credit to “5”.

  ST10: Since the current credit still remains, the remote device transmits packet data to the local device.

ST11: The above process is repeated, and the free credit value of the local device is incremented to “6”.
ST12: At this time, the remote device has been decremented until the value of the current credit is “1”.

ST13: Since the condition of the above “condition A” is satisfied, the local device transmits “free credit A” to the remote device.
ST14: The local device resets the value of the free credit to “0”.

  ST15: The remote device adds “free credit A” to the current credit and updates the value of the current credit to “7”.

  ST16: Since the condition of “condition A” is not satisfied and the current credit remains, the remote device can transmit packet data to the local device.

ST17: When receiving the RFCOMM data, the local device increments the value of the free credit to “1”.
ST18: On the other hand, the remote device decrements the value of the current credit from “7” to “6”.

  ST19: Since the current credit still remains, the remote device transmits packet data to the local device.

ST20: When receiving the RFCOMM data, the local device increments the value of the free credit to “2”.
ST21: On the other hand, the remote device decrements the value of the current credit to “5”.

  ST22: Since the current credit still remains, the remote device transmits packet data to the local device.

ST23: When receiving the RFCOMM data, the local device increments the value of the free credit to “3”.
ST24: On the other hand, the remote device decrements the value of the current credit to “4”.

  Thereafter, the communication processing sequence is executed in a similar manner until a desired amount of data transfer is completed. During the execution of “RFCOMM data reception and credit transmission process 1” in FIG. 4, the BT module 30 generates a timer interrupt, for example, and confirms whether or not a desired amount of data transfer has been completed. If the data transfer is completed in any interrupt cycle, the BT module 30 exits the “RFCOMM data reception and credit transmission process 1” and returns to the communication process of FIG.

  The communication processing sequence described above is the content before the trigger condition is satisfied in the multi-profile state detection unit 48. When the trigger condition is satisfied, the following processing is executed.

[RFCOMM data reception and credit transmission processing 2]
FIG. 6 is a flowchart showing a procedure example of the “RFCOMM data reception and credit transmission process 2” executed in step S24. Hereinafter, this process will be described.

  Step S60: The BT module 30 inserts a standby time (for example, 500 msec) during a communication process related to dial-up or serial port data access and waits (standby step).

Step S62: When the standby time elapses, the BT module 30 starts receiving RFCOMM data.
Step S64: The BT module 30 increments the value of the free credit by “1”. As a result, one previous free credit value is added.

  Step S66: Next, the BT module 30 decrements the value of the current credit in the mobile devices 14 to 18 as remote devices by “1”. As a result, one previous current credit value is subtracted.

  Step S68: Here, the BT module 30 determines whether or not “condition B” is satisfied as a condition. “Condition B” here may have the following contents, for example.

Current credit ≤ Th3 and free credit ≥ Th4
However, Th3 is smaller than Th1, and Th4 is smaller than Th2. Here, for example, Th3 = 0 and Th4 = 1.

  In particular, when the condition of “condition B” is not satisfied (step S68: No), the BT module 30 returns to step S60 and waits for the standby time, and then proceeds to step S62 to repeat reception of RFCOMM data. Then, when the value of the free credit is incremented (step S64) and the value of the current credit is decremented instead (step S66), the BT module 30 determines again whether or not the condition “condition B” is satisfied.

  As described above, the BT module 30 repeats the RFCOMM data reception until the current credit value becomes Th3 = “0” or less and the free credit value becomes Th4 = “1” or more. Therefore, the remote device can transmit packet data to the local device until the current credit given by the initial credit value does not remain.

  Thereafter, when the value of the current credit is equal to or less than Th3 (= 0) and the value of the free credit is equal to or greater than Th4 (= 1), the condition of “condition B” is satisfied (step S68: Yes). The BT module 30 next executes step S70.

  Step S70: Here, the BT module 30 transmits “free credit B” as a credit to the remote device. “Free credit B” at this time is equivalent to Th4 = “1”. Therefore, “1” is transmitted in the above example.

Step S72: Next, the BT module 30 resets the value of the free credit to “0”.
Step S74: The BT module 30 adds “free credit B” = “1” to the current credit value = “0” and updates the current credit value to “1”.

  Next, when the BT module 30 receives the RFCOMM data in step S62, the free credit value becomes “1” in step S64, but the current credit value becomes “0” in one reception of the RFCOMM data in step S66. Become. For this reason, the remote device cannot transmit packet data to the local device, and returns to step S60 through steps S70 to S74. In step S60, the standby time is waited, and the next RFCOMM data is received.

  As described above, in the “RFCOMM data reception and credit transmission process 2”, the communication process is performed while repeating the above procedure. During this time, the current credit value is only “1” at the maximum, so that the local device receives it. The number of possible packets is reduced (decreasing process). In addition, since the standby time is inserted every time RFCOMM data reception is performed, the time required for communication processing is delayed accordingly (standby step).

[Communication processing sequence]
FIG. 7 is a sequence diagram showing a flow of communication processing by “RFCOMM data reception and credit transmission processing 2”.

  ST50: At the beginning of the sequence, the RFCOMM connection is completed between the local device and the remote device.

ST51: The free credit value of the local device is set to “0”.
ST52: In the remote device, the value of the current credit is set to the initial credit value of the local device = “7”. This value specifies the number of packets that can be received from the local device in the same manner as described above.

  ST53: The remote device transmits packet data to the local device.

ST54: When receiving the RFCOMM data, the local device increments the value of the free credit to “1”.
ST55: On the other hand, the remote device decrements the value of the current credit from “7” to “6”.

  ST56: Since the current credit still remains, the remote device transmits packet data to the local device.

ST57: When receiving RFCOMM data, the local device increments the value of the free credit to “2”.
ST58: On the other hand, the remote device decrements the value of the current credit to “5”.

  ST59: Since the current credit still remains, the remote device transmits packet data to the local device.

ST60: The above processing is repeated, and the free credit value of the local device is incremented to “7”.
ST61: At this time, the remote device has been decremented until the value of the current credit is “0”. Therefore, the remote device cannot transmit packet data any more.

ST62: Here, the local device waits for the set standby time.
ST63: Since the condition of “condition B” is satisfied, the local device transmits “free credit B” to the remote device.
ST64: The local device resets the value of the free credit to “0”.

  ST65: The remote device adds “free credit B” to the current credit and updates the value of the current credit to “1”.

  ST66: Since the condition of “condition B” is not satisfied and the current credit remains, the remote device can transmit packet data to the local device.

ST67: When receiving the RFCOMM data, the local device increments the value of the free credit to “1”.
ST68: On the other hand, the remote device decrements the value of the current credit from “1” to “0”. As a result, the remote device can no longer transmit packet data.

ST69: Here, the local device waits for the set waiting time.
ST70: Since the condition of “condition B” is satisfied, the local device transmits “free credit B” to the remote device.

ST71: The local device resets the value of the free credit to “0”.
ST72: The remote device adds “free credit B” to the current credit and updates the value of the current credit to “1”. As a result, the remote device can transmit data for one packet.

  Thereafter, the communication processing sequence is executed in a similar manner until a desired amount of data transfer is completed. During the execution of “RFCOMM data reception and credit transmission process 2” in FIG. 6, the BT module 30 generates a timer interrupt, for example, and confirms whether or not a desired amount of data transfer has been completed. If the data transfer is completed in any interrupt cycle, the BT module 30 exits the “RFCOMM data reception and credit transmission process 2” and returns to the communication process of FIG.

  However, during the execution of “RFCOMM data reception and credit transmission process 2”, a standby time is inserted for each reception of RFCOMM data, so that a relatively long time is allocated to a communication process using a different communication profile. Become. In addition, since the number of packets that can be received by one RFCOMM data is decreased, the number of packets is relatively increased for communication processing using another communication profile (not shown in particular), and the data reception band is widened accordingly. Will be.

[RFCOMM data reception and credit transmission correction processing]
Next, FIG. 8 is a flowchart showing an example of the procedure of “RFCOMM data reception and credit transmission correction processing”. This process is executed when this condition is not satisfied after the trigger condition of “condition C” is satisfied in the communication process of FIG. 3.

Step S80: Again, the BT module 30 performs RFCOMM data reception.
Step S82: The BT module 30 increments the value of the free credit by “1”. As a result, one previous free credit value is added.

  Step S84: Next, the BT module 30 decrements the value of the current credit at the remote device by “1”.

  Step S86: Here, the BT module 30 determines whether or not “condition D” is satisfied as a condition. “Condition D” may have the following content, for example.

  Current credit = “0”

  In particular, when the condition of “condition D” (that is, current credit = 0) is not satisfied (step S86: No), the BT module 30 returns to step S80 and repeats reception of RFCOMM data. Then, when the value of the free credit is incremented (step S82) and the value of the current credit is decremented instead (step S84), the BT module 30 determines again whether or not the condition “condition D” is satisfied.

  Thus, the BT module 30 repeats the RFCOMM data reception until the current credit value becomes “0”. Therefore, the remote device can transmit packet data to the local device until the current credit given by the initial credit value does not remain.

  Thereafter, when the value of the current credit becomes “0”, the condition of “condition D” is satisfied (step S86: Yes), so the BT module 30 next executes step S88.

  Step S88: Here, the BT module 30 transmits “free credit D” as a credit to the remote device. The “free credit D” at this time is equal to the initial credit of the local device. Therefore, “7” is transmitted in the above example.

Step S90: Next, the BT module 30 resets the value of the free credit to “0”.
Step S92: The BT module 30 adds “free credit D” = “7” to the current credit value = “0” and updates the current credit value to “7”.

  Step S94: The BT module 30 sets “mode 1” and returns to the communication process of FIG.

  Thereafter, since “mode 1” is set, “RFCOMM data reception and credit transmission processing 1” is performed until the next trigger condition is satisfied (step S18: No, step S20: Yes in FIG. 3). Will be executed.

  As described above, in the present embodiment, a trigger condition is given to the multi-profile state detection unit 48, and “RFCOMM data reception and credit transmission processing 1” and “RFCOMM data reception and credit transmission processing” are performed each time the communication state changes. By dynamically switching to “2”, it becomes possible to allocate a reception band during data access by an application using dial-up or a serial port to another application.

  Further, when the multi-profile state detection unit 48 detects that the state of the audio application has changed from “playing” to “stopped” during the execution of “RFCOMM data reception and credit transmission process 2”, or “RFCOMM When the multi-profile state detection unit 48 detects that the state of the hands-free application has changed from “busy” to “SLC connected” during the execution of “data reception and credit transmission process 2”, the “correction process” of FIG. ”To switch to“ RFCOMM data reception and credit transmission processing 1 ”, giving priority to data reception throughput as much as possible.

[Usefulness in the product market]
Particularly in recent user scenarios of BT communication, improvement of operation and quality by multi-connection and multi-profile is required from the product market. Depending on the individual profiles (applications), there are roughly divided into elements that require strict real-time performance and sound quality, such as voice calls and audio transmission, and elements of best-effort data communication such as dial-up (DUN / SPP). However, in order to allow these to coexist as much as possible, control of the transmission / reception bandwidth is an issue.

  In the communication method of this embodiment, the former is in a call or audio playback state while an element for which real-time property and quality are required and an element for best effort data communication are being executed in parallel. If detected, the number of credits, the transmission conditions, and the transmission method can be adaptively changed with respect to the latter element, thereby limiting the number of receivable packets, and as a result, the reception band is relatively set with respect to the latter element. On the contrary, it has the effect of improving the former real-time property and sound quality as much as possible.

  Further, when the end of communication or the state of audio stop is detected in the former communication, the reception bandwidth can be increased as much as possible by returning to the original communication processing, and the data reception throughput can be ensured.

  The present invention can be implemented with various modifications without being limited to the above-described embodiments. The configuration of the BT module 30 described in the embodiment is merely an example of functional block elements, and these functions may be covered by resources of a microcomputer (CPU), and each function may be realized by an application.

  In the embodiment, audio data, voice call data, and the like are given as an example for giving priority to communication processing. However, the communication method of the present invention can also be applied when transferring video data.

1 is a diagram schematically illustrating a configuration example of a communication system. It is a block diagram which shows roughly the hardware structural example of BT module. 5 is a flowchart illustrating an exemplary procedure of communication processing executed by the BT module 30. It is a flowchart which shows the example of a procedure of "RFCOMM data reception and credit transmission process 1". It is a sequence diagram which shows the flow of the communication process by "RFCOMM data reception and credit transmission process 1". It is a flowchart which shows the example of a procedure of "RFCOMM data reception and credit transmission process 2". It is a sequence diagram which shows the flow of the communication process by "RFCOMM data reception and credit transmission process 2". It is a flowchart which shows the example of a procedure of "RFCOMM data reception and a credit transmission correction process."

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Communication system 12 Car unit 14, 16, 18 Portable apparatus 30 BT module 44 Credit transmission process part 46 DUN / SPP data transmission process part 48 Multi-profile state detection part 50 Other profile data transmission process part 52 DUN / SPP data reception process part 54 Other Profile Data Reception Processing Unit

Claims (6)

In a communication system composed of a local device and a remote device having a function of communicating using a plurality of communication profiles, the number of packets that can be received in advance by the local device at the start of communication between the local device and the remote device is stored in the remote device. In the packet communication method of transmitting and receiving a desired amount of packet data while repeating the communication process of transmitting and receiving data for the notified number of packets from the remote device to the local device and receiving at the local device,
When the local device executes the communication processing with any remote device, detecting which communication profile is used to perform the communication processing among a plurality of communication profiles;
While the local device is performing the communication process with a specific remote device, another communication profile with a different communication profile that is different from the current one with the same specific remote device or another remote device is used. When it is detected that a process has been executed, another communication profile is used by reducing the number of receivable packets that the local device notifies to the specific remote device in the currently executing communication process. And a step of relatively increasing the number of packets that can be received by the local device during the communication process. The packet communication method according to claim 1,
While the local device is performing the communication process with a specific remote device, another communication profile with a different communication profile that is different from the current one with the same specific remote device or another remote device is used. A packet communication method further comprising a step of inserting a waiting time into the currently executed communication process when it is detected that the process has been executed. The packet communication method according to claim 2,
In the step of inserting the waiting time,
A packet communication method, wherein a waiting time is inserted before a local device notifies the specific remote device of the number of receivable packets in the communication process currently being executed. In the packet communication method according to any one of claims 1 to 3,
In the step of relatively increasing the number of packets,
A packet communication method characterized by reducing the number of packets in the currently executed communication process when another communication profile requires more real-time characteristics than the current communication profile. . In the packet communication method according to any one of claims 1 to 3,
In the step of relatively increasing the number of packets,
Another communication profile is used when receiving audio data or voice call data at the local device, or when it is necessary to complete the data transfer from the remote device to the local device within a predetermined time A packet communication method characterized by reducing the number of packets in the currently executed communication process if any of them is used. In the packet communication method according to any one of claims 1 to 5,
The communication process includes
In accordance with credit-based flow control defined by the RFCOMM protocol in a specific short-range wireless communication standard, a procedure for notifying the remote device from the local device as the number of packets that the local device can receive;
Reducing the number of credits at the remote device each time packet data is sent from the remote device to the local device,
While the credit amount remains in the remote device, packet data can be transmitted from the remote device to the local device. On the other hand, when the credit amount does not remain, the packet from the remote device to the remote device is transmitted from the remote device. A packet communication method, wherein data transmission is disabled.

Images