JP2013106218A - Radio communication device, on-vehicle device and link loss recovery method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a radio communication device, an on-vehicle device and a link loss recovery method, facilitating recovery at a link loss (communication interruption accompanying the change of a radio wave environment, etc.).SOLUTION: A radio communication device performing information communication related to a plurality of applications on a radio communication channel includes: link loss detection means for detecting a link loss on the radio communication channel; application state storage means for storing the states of the plurality of applications before the link loss occurrence; recovery means for recovering the radio communication channel producing the link loss; and application recovery means for recovering the applications. The application recovery means recovers the applications according to the application storage state stored in the application state storage means, after the link loss detection by the link loss detection means and the recovery of the radio communication channel by the recovery means.

Description

  The present invention relates to wireless communication such as Bluetooth (registered trademark), and more particularly to a wireless communication device, an in-vehicle device, and a link loss recovery method that facilitate recovery at the time of link loss (communication interruption due to changes in radio wave environment or the like).

  Conventionally, there is Bluetooth (registered trademark) as a technology for transmitting and receiving data between various devices by wireless communication at a short distance. Bluetooth (registered trademark) is a standard that uses a frequency band of 2.4 GHz, and wireless communication is possible within a range of about 10 meters.

  As an example, a function of performing a hands-free call or audio transfer is realized by connecting a mobile phone and a vehicle-mounted device typified by car navigation using Bluetooth (registered trademark) (see, for example, Patent Document 1).

  In the Bluetooth (registered trademark) standard, functions and behaviors necessary to operate as an application called a profile are defined. For example, a hands-free profile (HFP) for realizing a hands-free function, an audio profile for audio transmission ( A2DP / AVRCP), dial-up network profile (DUN) for realizing data communication by dial-up connection using a telephone line.

  There are cases where a plurality of profiles are simultaneously connected between wireless communication apparatuses and a plurality of application functions are used simultaneously (so-called multi-profile).

  On the other hand, when such a plurality of applications are used simultaneously, it is generally known that there are combinations of those that can be operated simultaneously and those that cannot be operated depending on the nature of the applications. “Simultaneous operation” means, for example, a combination in which both apps A and B can be operated when there are app A and app B. “Simultaneous operation impossible” means, for example, when there is app A and app C This means that only one of the apps can operate at the same time.

  Further, since the communication path is wireless, it is assumed that link loss (disruption of communication due to changes in radio wave environment etc.) occurs.

  When a link loss occurs in the multi-profile operation status, there is a problem that the wireless communication apparatus cannot determine to which state it should be recovered because there is a combination in which the above applications can be operated simultaneously. For this reason, there are apps A and C that cannot be operated simultaneously, and when app A is a currently operating app and app C is a currently paused app, if a link loss occurs, it is activated immediately before There is a problem that even though the application A, which is a new application, can be recovered, it has been started before that, and the application C, which has been suspended immediately before the link loss, cannot be recovered.

  The above problems occur not only in the relationship between the Bluetooth (registered trademark) and the profile, but also in the relationship between the short-range wireless communication device and the function realized by the short-range wireless communication device by communication with the other party. Yes.

JP 2006-148864 A

  The present invention has been made in view of the above problems. That is, it is possible to provide a wireless communication device, an in-vehicle device, and a link loss recovery method that facilitate recovery and improve user convenience when a link loss occurs in the operation status of multiple functions simultaneously (multi-profile). Objective.

  In order to achieve the above object, a wireless communication apparatus according to the present invention comprises a link loss detecting means for detecting a link loss of a wireless communication path in a wireless communication apparatus for communicating information related to a plurality of applications on a wireless communication path, and a link. An application state storage unit that stores the states of a plurality of applications before the loss as an application state, a recovery unit that recovers the wireless communication path that has lost the link, and an application recovery unit that recovers the application. The link loss detection unit detects the link loss and the recovery unit recovers the wireless communication path, and then recovers the application according to the application storage state stored in the application state storage unit.

  According to the present invention, it is possible to provide a wireless communication device and an in-vehicle device that are related to wireless communication such as Bluetooth (registered trademark) and that facilitate recovery at the time of link loss.

1 is a block diagram showing an overall configuration of a wireless communication apparatus according to Embodiment 1 of the present invention. Hierarchical diagram modeling the communication layer structure of the wireless communication device 100 and the opposed wireless communication device 200 Operation flow diagram showing initialization process when starting wireless communication device The figure which shows an example of the application classification management table which concerns on Embodiment 1 of this invention. The figure which shows an example of the combination table of the possibility / impossibility of the coexistence of the application which concerns on Embodiment 1 of this invention. The figure which shows an example of the priority management table which concerns on Embodiment 1 of this invention. Operation flow diagram showing the update operation of the application state management table according to the first embodiment of the present invention. The figure which shows an example of the application state management table which concerns on Embodiment 1 of this invention. Operation flow diagram showing operation when link loss occurs in radio communication apparatus according to Embodiment 1 of the present invention The schematic diagram which shows the whole structure of the vehicle-mounted apparatus 300 and the portable terminal 400 which concern on Embodiment 2 of this invention. Hierarchical diagram of the Bluetooth (registered trademark) protocol stack included in the near field communication unit 101 of the in-vehicle device and the near field communication unit of the portable terminal 400 The figure which shows an example of the application classification management table which concerns on Embodiment 2 of this invention. The figure which shows an example of the combination table of the possibility / impossibility of the coexistence of the application which concerns on Embodiment 2 of this invention. The figure which shows an example of the priority management table which concerns on Embodiment 2 of this invention. The figure which shows an example of the application state management table which concerns on Embodiment 2 of this invention. Operation flow diagram showing operation for restoring each application after link loss of in-vehicle device 300 according to Embodiment 2 of the present invention The figure which shows an example of the application classification management table which concerns on Embodiment 2 (modification 1) of this invention. The figure which shows an example of the combination table of the possibility / impossibility of the coexistence of the application which concerns on Embodiment 2 (modification 1) of this invention. The figure which shows an example of the application state management table which concerns on Embodiment 2 (modification 1) of this invention. Operation flow diagram showing operation for restoring each application after link loss of in-vehicle apparatus 300 according to Embodiment 2 (Modification 1) of the present invention The figure which shows an example of the application classification management table which concerns on Embodiment 2 (modification 2) of this invention. The figure which shows an example of the combination table of the possibility / impossibility of the coexistence of the application which concerns on Embodiment 2 (modification 2) of this invention. The figure which shows an example of the application state management table which concerns on Embodiment 2 (modification 2) of this invention. Operation flow diagram showing an operation of restoring each app after the link loss of in-vehicle device 300 according to Embodiment 2 (Modification 2) of the present invention The figure which shows the table showing the operation | movement after link loss recovery according to the state of each application before link loss. The figure which shows the table showing the operation | movement after link loss recovery according to the state of each application before link loss.

Hereinafter, a wireless communication apparatus according to Embodiment 1 of the present invention will be described with reference to the drawings. In each drawing, components not related to the present invention are omitted.
(Embodiment 1)
FIG. 1 is a block diagram showing an overall configuration of radio communication apparatus 100 according to Embodiment 1 of the present invention.

  In FIG. 1, a wireless communication device 100 includes a short-range wireless communication unit 101, a control unit 102, an audio input unit 103, an audio output unit 104, a video input unit 105, a video output unit 106, a data input unit 107, and a data output unit 108. The storage unit 109 is provided.

  The opposing wireless communication device 200 establishes short-range wireless communication with the wireless communication device 100 and communicates information related to a plurality of applications (hereinafter, applications are simply referred to as applications) functions.

  Next, components of the wireless communication device 100 will be described.

  The short-range wireless communication unit 101 includes an antenna, a wireless circuit, a protocol stack, and the like for performing wireless communication, and performs data communication with the opposite wireless communication apparatus 200 by short-range wireless communication. Bluetooth (registered trademark) is used as a wireless standard used in this data communication.

  The control unit 102 controls a CPU (Central Processing Unit) or MPU (Micro Processing Unit) and ROM (Read Only Memory), which controls the overall operation according to the present embodiment such as communication operation and data management operation of the wireless communication apparatus 100. A RAM (Random Access Memory), an I / O bus, and the like.

  The CPU or MPU executes the program stored in the ROM, whereby the functional blocks cooperate with each other, and the processing according to the present embodiment is realized. The CPU or MPU uses the RAM as a work area during execution of the program. In addition, the control unit 102 can connect to the opposed wireless communication device 200 and execute a plurality of applications.

  The voice input unit 103 includes a circuit that processes input voice input from a microphone (not shown). In this case, depending on the application, the input voice can be transmitted from the short-range wireless communication unit 101 and transmitted to the opposite wireless communication apparatus 200.

  The audio output unit 104 includes an amplifier, a circuit, and the like that process output audio in order to output audio to a speaker (not shown). In this case, depending on the application, the output voice can be received from the opposite wireless communication apparatus 200 side via the short-range wireless communication unit 101.

  The video input unit 105 is, for example, an imaging device such as a camera, an external video input terminal, and includes a circuit for inputting an image, video, or an image such as an image.

  The video output unit 106 is, for example, a display device such as a liquid crystal display or an organic EL display, and includes a circuit for drawing an image, a video, or an image such as an image on the display device.

  The data input unit 107 is used to input an operation instruction from the user, and includes a configuration in which a predetermined number of press-type keys are arranged or a touch panel type. An operation by the user is detected, and an operation signal indicating the operation content is output to the control unit 102.

  The data output unit 108 is a means for outputting various data processed by the control unit 102. When outputting various data as video, the data output unit 108 is equivalent to the video output unit 106. On the other hand, when it is desired to store it as simple data without outputting it as a video, it outputs it to the storage unit 109.

  The storage unit 109 is a memory configured to be able to store various data. For example, an application type management table, an application coexistence possible / impossible combination table, a priority management table, an application state management table, data processed by a plurality of applications, and the like are stored.

  It should be noted that not all the components denoted by reference numerals 102 to 108 need to be provided. It is good also as a structure provided only with a one part component. Although the video output unit and the data input unit have been described as separate components, they may be a single device having both functions, such as a touch panel display.

  FIG. 2 is a hierarchical diagram that models the communication layer structures of the wireless communication device 100 and the opposed wireless communication device 200, respectively.

  The first communication layer structure 10 is a structure on the wireless communication device 100 (a hierarchical diagram showing communication layers included in the short-range communication unit 101 of the wireless communication device 100), and the second communication layer structure 20 is a counter wireless communication device 200. Each of the above structures (a hierarchical diagram showing a communication layer provided in the short-range communication unit of the wireless communication apparatus 200) is shown.

  RF (Radio Frequency) is a layer that actually performs wireless communication. Definition of modulation mode for performing communication in the 2.4 GHz band, transmitter characteristics (such as maximum transmission power), receiver characteristics (such as sensitivity), etc. Define

  Base band is a layer in which various processes (link control, packet management, error correction, channel control, etc.) are performed in order to realize wireless communication. It has the role of digitizing the signal from the RF and delivering it to the upper layer. Specify the media access and physical layer procedures between both devices.

  The communication middleware is a layer that supports multiplexing of higher level protocols, segmentation and reconstruction of packets, transmission of service quality information, and the like.

  An app A, an app B, and an app C indicate a plurality of apps that operate on the communication middleware, and the same apps operate in cooperation with each other via a short-range wireless communication path.

  For example, the app A of the first communication layer structure 10 and the app A of the second communication layer structure 20 have their respective roles and exchange and operate various communication data.

  Here, the role is a role in executing various applications such as a data transmission side and a data reception side, and is defined for each application.

  Although FIG. 2 shows three applications as an example, the present invention is not limited to this.

  RF and Base band operate as the short-range wireless communication unit 101, and communication middleware, application A, application B, and application C are realized as programs that operate in the control unit 102. Note that the communication middleware may operate on the short-range wireless communication unit 101.

  Next, an initialization process when the wireless communication apparatus 100 is activated will be described with reference to FIG. FIG. 3 is an operation flowchart showing an initialization process when the wireless communication apparatus is activated.

  First, in S101, an application type management table is created. Next, an application type management table is referred to and an application coexistence possible / impossible combination table is created (S102). Then, the priority management table is set with reference to the application coexistence possible / impossible combination table (S103).

  Next, various tables created in the operation flowchart of FIG. 3 will be described with reference to FIGS.

  FIG. 4 is a diagram illustrating an example of the application type management table. The application type management table is a table showing what input / output is involved for each application. The horizontal axis represents each application, and the vertical axis represents audio output, audio input, video input, video output, data input, data output,... As application types.

  The input / output of the application type management table is not limited to this, and other arbitrary ones can be added.

  The application-type audio output indicates whether the application is accompanied by audio output using the audio output unit 104 of the wireless communication apparatus 100 of FIG. Similarly, the voice input indicates whether the application uses voice input unit 103 and is accompanied by voice input. The video input indicates whether or not the video input unit 105 is an application with video input. The video output indicates whether the application uses video output unit 106 and is accompanied by video output. The data input indicates whether the application uses the data input unit 107 and involves data input. The data output indicates whether the application is accompanied by data output using the data output unit 108.

  That is, the application type and the components 102 to 108 of the wireless communication apparatus 100 in FIG. 1 correspond to each other.

“◯” in the table of FIG. 4 indicates that input / output is involved, and “x” indicates that it is not accompanied.

  Here, the voice input and the voice output of the application A are “◯”, and the others are “X”. This indicates that the application A is an application with voice input and voice output (for example, an application that realizes a telephone function).

  In addition, the application B represents an application accompanied by audio output (for example, an application that realizes music reproduction).

  In addition, the application C indicates that the application involves video output, data input, and data output (for example, an application that realizes a mail function). Although both video output and data output are marked with ◯, this indicates that data may be output immediately as video, or that data may be stored in memory and used later. The application type management table can be uniquely determined once the application is determined.

  FIG. 5 is a diagram illustrating an example of an application coexistence possible / impossible combination table. The application coexistence possible / impossible combination table is a table indicating combinations of those that can be operated simultaneously (coexistence) and those that cannot be performed depending on the properties (defined in the application type management table) of each application.

  In the table of FIG. 5, “◯” indicates that coexistence is possible, and “x” indicates that coexistence is impossible.

  Here, the app A cannot coexist with the app B and can coexist with the app C. The app B cannot coexist with the app A and can coexist with the app C. The app C can coexist with the app A and can coexist with the app B.

  The reason why the application A and the application B cannot coexist will be described. Application A and application B are both applications that output sound and cannot coexist on the premise that only the sound of one application can be output at the same time.

  The reason why the application A and the application C can coexist is because there is no duplication of the properties of the application, as can be seen from the application type management table.

  FIG. 6 is a diagram illustrating an example of the priority management table. The priority management table defines which applications are preferentially operated in the case of applications that cannot coexist with each other. For example, when the wireless communication device 100 is used in a vehicle, a user uses various applications even while the user is driving, so a voice-based application and an application with high real-time properties are given priority.

  Note that the method for determining the application priority order can be dynamically changed according to the position where the wireless communication device 100 is present.

  When an interrupt is received from an app with high priority with respect to an app that is currently operating, the app that is currently operating is temporarily suspended, and the operation of the app with high priority that has been interrupted is started. On the other hand, interruptions from apps with a lower priority than the current app are not allowed.

  FIG. 6 shows that the app A has a higher priority with respect to the apps A and B that cannot coexist with each other.

  In the case of apps that can coexist (for example, app A and app C), a priority management table is not created.

  The operation flow diagram of FIG. 3 has been described as the initialization processing of the wireless communication apparatus 100. However, the present invention is not limited to this, and the application type management table, the application coexistence possible / impossible combination table, and the priority management table are provided in advance. It may be created, stored in a non-volatile memory, etc., and read at startup.

  Next, the operation of the state management process associated with application activation will be described with reference to FIGS.

  FIG. 7 is an operation flowchart showing an update operation of the application state management table (details will be described in FIG. 8).

  In FIG. 7, it is determined whether or not an application activation request has occurred in step S201.

  When the application activation request has not occurred (S201: No), the process is returned before step S201.

  If an application activation request is generated (S201: Yes), it is determined in step S202 whether there is an already activated application.

  If there is no application already activated (S202: Yes), the application requested to be activated is activated in step 203.

  In step S202, when there is an already activated application (S202: No), the process proceeds to step S205.

  In step S205, it is determined whether the application can coexist with an already activated application.

  The determination in step S205 refers to an application coexistence possible / impossible combination table.

  In the case of an application that can coexist with an already activated application (S205: Yes), the application requested to be activated is activated in step S206.

  On the other hand, if the application cannot coexist with the already running application (S205: No), the process proceeds to step S207.

  In step S207, it is determined whether the application for which the activation request has occurred is an application having a higher priority than the already activated application.

  Here, the determination in step S207 refers to the priority management table.

  If the application for which the activation request has occurred is an application having a higher priority than the already activated application (S207: Yes), the currently activated application is shifted to the standby state in step S208, and there is an activation request. Launch the app.

  On the other hand, when the application for which the activation request has been issued is not an application with a higher priority than the already activated application (S207: No), the process proceeds to step S209. In step S209, the activation request is not accepted and the process ends. In step S204, the application state management table is updated.

  FIG. 8 is a diagram illustrating an example of the application state management table. The application state management table manages the state of each application by any of the currently activated application, the application that is temporarily waiting, and the coexistence application.

  FIG. 8 shows a case where an application A activation request is generated and the application state management table is updated when the application B is activated and the application C coexists. At this time, in the operation flow of FIG. 7, processing is sequentially performed in the path of S201 → S202 → S205 → S207 → S208 → S204.

  Note that the application state management table in FIG. 8 shows an example in which up to two apps can be managed temporarily and up to two coexisting apps can be managed. However, the application status management table is not limited to this. You can increase the number of apps and coexisting apps.

  Next, the operation at the time of occurrence of link loss (communication interruption due to radio wave environment change or the like) of the wireless communication apparatus according to Embodiment 1 of the present invention will be described with reference to FIG.

  FIG. 9 is an operation flowchart showing an operation when a link loss occurs in the radio communication apparatus according to Embodiment 1 of the present invention.

  In FIG. 9, it is determined in step S301 whether a link loss has occurred. The link loss is detected by the short-range wireless communication unit 101.

  If no link loss has occurred (S301: No), the process is returned to before S301. If a link loss has occurred (S301: Yes), the process proceeds to step S302. When a link loss occurs, it can be notified to the user.

  In step S302, a link loss recovery process with the opposite wireless communication apparatus 200 is attempted, and it is determined whether the recovery is successful.

  If the link loss cannot be recovered (S302: No), the process proceeds to step S303.

  In step S303, it is determined whether a predetermined time has elapsed. If the predetermined time has not elapsed (S303: No), the process is returned before step S302.

  On the other hand, if the predetermined time has elapsed (S303: Yes), the process proceeds to step S306.

  In step S306, the application state management table is cleared (the stored state of each application is deleted).

  On the other hand, when the link loss can be recovered (S302: Yes), the process proceeds to step S304. In step S304, the application state management table before link loss is read.

  Next, each application is restored to the state before the link loss according to the read application state management table (S305). At this time, the application that was running before the link loss (application A in the example of FIG. 8) is restored with priority.

The reason why there is a path such as steps S302 → S303 → S306 is that there is a case where the link loss cannot be recovered due to a battery exhaustion or the like when the opposite wireless communication apparatus is driven by a battery.

  As described above, according to the wireless communication apparatus described above, when a link loss occurs in the operation status of multiple functions simultaneously (multi-profile), the wireless communication device is being activated before the link loss according to the application state management table before the link loss. Since the standby application and the coexistence application are properly restored, not only the new application, but also the wireless communication device that improves the user convenience can be provided.

  The configuration described in the above embodiment is merely a specific example and does not limit the technical scope of the present invention. Any configuration can be employed within the scope of the effects of the present application.

In addition, although Bluetooth (registered trademark) has been described as an example of the short-range wireless communication standard, it is also useful for a wireless LAN or the like.
(Embodiment 2)
Hereinafter, an in-vehicle device according to Embodiment 2 of the present invention will be described with reference to the drawings. In each drawing, components not related to the present invention are omitted.

  FIG. 10 is a block diagram showing an overall configuration of in-vehicle apparatus 300 according to Embodiment 2 of the present invention.

  In FIG. 10, the in-vehicle device 300 has the same components as those of the wireless communication device 100 of the first embodiment and is omitted. The description of each component is omitted.

  Furthermore, the in-vehicle device 300 includes a database that stores map information such as data on roads and intersections (not shown), positioning means such as GPS (Global Positioning System), a known route search, guidance guidance program, and the like. While displaying the map on the output unit 106, it is possible to update the display of the vehicle position, superimpose the route on the map, and perform guidance guidance by voice in front of the guidance target intersection.

  The mobile terminal 400 is, for example, a mobile phone possessed by a driver using a vehicle on which the in-vehicle device 300 is mounted, and is brought into the vehicle. Further, a short-range wireless communication path is established with the in-vehicle device 300, and communication related to a plurality of applications (hereinafter, applications are simply referred to as applications) is performed. The short-range wireless communication path is a communication path that conforms to the Bluetooth (registered trademark) standard.

  The in-vehicle device 300 performs short-distance wireless communication with the mobile terminal 400, so that a hands-free call function for making a call with a user connected to the end of the public network 1 and a telephone for transferring the phone book data of the mobile terminal 400 to the in-vehicle device 300. Using the book transfer function, the streaming playback function for streaming playback of audio stored in the mobile terminal 400 with the in-vehicle device 300, and the gateway function of the mobile terminal 400, data communication such as WEB browsing is performed with an external network (public network 1). A data communication (dial-up communication) function and a message communication function for performing message communication with an external network using the gateway function of the portable terminal 400 are provided.

  In executing these functions, a Bluetooth (registered trademark) profile is used (details will be described later), and the in-vehicle device 300 and the portable terminal 400 are configured such that a plurality of profiles can be connected simultaneously.

FIG. 11 is a hierarchical diagram in which the communication layer structure of the in-vehicle device 300 is modeled. Although the communication layer having the same configuration as the third communication layer structure 30 (a hierarchical diagram of the Bluetooth (registered trademark) protocol stack provided in the short-range wireless communication unit 101 of the in-vehicle device 300) exists in the mobile terminal 400, FIG. Is omitted.

  In FIG. 11, RF (Radio Frequency) is a layer that actually performs wireless communication. The modulation mode definition for performing communication in the 2.4 GHz band, transmitter characteristics (maximum transmission power, etc.), and receiver characteristics ( Sensitivity etc.).

  Base band is a layer in which various processes (link control, packet management, error correction, channel control, etc.) are performed in order to realize wireless communication. It has the role of digitizing the signal from the RF and delivering it to the upper layer. Defines media access and physical layer procedures between Bluetooth® devices.

  LMP (Link Manager Protocol) is used to control and negotiate all aspects of Bluetooth (registered trademark) connection (connection, authentication, encryption, power saving control, etc.) between two devices.

  The HCI (Host Controller Interface) provides a command interface to the baseband controller and the link manager, and provides an interface for accessing configuration parameters.

  L2CAP (Logical Link Control and Adaptation Protocol) supports multiplexing of higher level protocols, packet segmentation and reconstruction, and transmission of quality of service information.

  RFCOMM is used to set up a serial cable and emulate an RS-232C serial port.

  OBEX (Object Exchange) is a communication protocol that two devices can use for exchanging objects, and is defined so that various data and commands can be exchanged.

  AVDTP (Audio / Video Distribution Transport Protocol) defines an A / V stream negotiation procedure, a confirmation procedure, and a transmission procedure.

  AVCTP (Audio / Video Control Transport Protocol) defines a transport mechanism for exchanging control messages of A / V devices.

  GAVDP (General Audio / Video Distribution Profile) functions as the basis of A2DP, and is used to distribute a video stream and an audio stream.

  A2DP (Advanced Audio Distribution Profile) is used to stream stereo quality audio from a media source to a media sink. The in-vehicle device 300 behaves as a sink. The portable terminal 400 behaves as a source.

  AVRCP (Audio / Video Remote Control Profile) is used for remote control of audio streaming. The in-vehicle device 300 behaves as a controller. The portable terminal 400 behaves as a target.

  OPP (Object Push Profile) is a profile for object transmission and is used for transferring telephone directory data. The in-vehicle device 300 behaves as a server. The portable terminal 400 behaves as a client.

  PBAP (Phone Book Access Profile) is used for transferring telephone book data and outgoing / incoming call history data. The in-vehicle device 300 behaves as a client. The portable terminal 400 behaves as a server.

  Note that any profile of either OPP or PBAP can be used for telephone directory transfer.

  MAP (Message Access Profile) is used for exchanging message information. The in-vehicle device 300 behaves as a client. The portable terminal 400 behaves as a server.

  HFP (Hands Free Profile) is used to realize a hands-free call function. The in-vehicle device 300 behaves as hands-free. The portable terminal 400 behaves as an audio gateway.

  DUN (Dial-Up Networking Profile) is used to access the Internet and other dial-up services. The in-vehicle device 300 behaves as a data terminal. The portable terminal 400 behaves as a gateway.

  SDP (Service Discovery Protocol) is used to search what services the in-vehicle device 300 and the portable terminal 400 support each other.

  GAP (Generic Access Profile) defines a method for establishing a baseband link between Bluetooth (registered trademark) compatible devices.

  The AVP application is an application that realizes a streaming playback function for streaming playback of audio stored in the mobile terminal 400 by the in-vehicle device 300.

  The PBAP application is an application that realizes a telephone directory transfer function for acquiring telephone directory data of the mobile terminal 400 from the in-vehicle device 300.

  The OPP application is an application that realizes a telephone directory transfer function for transmitting telephone directory data from the mobile terminal 400 to the in-vehicle device 300.

  The MAP application is an application that implements a message communication function that uses the gateway function of the mobile terminal 400 to perform message communication with an external network.

  The HFP application is an application for realizing a hands-free call function for calling a user connected to the end of the public network 1.

  The DUN application is an application that implements a data communication (dial-up communication) function that uses the gateway function of the mobile terminal 400 to perform data communication such as WEB browsing with an external network.

  The management application is an application for pairing with the mobile terminal 400 to perform device registration, or searching for a Bluetooth (registered trademark) counterpart device existing around the in-vehicle apparatus 300 and acquiring service information of the counterpart device. is there.

  The management application is a basic application of all applications, and is always activated.

The above-described apps operate in cooperation with the same apps of the mobile terminal 400 via the short-range wireless communication path.

  For example, the HFP application of the third communication layer structure 30 and the HFP application of the mobile terminal 400 have their respective roles and operate by exchanging various types of communication data.

  In this figure, seven applications are shown as an example, but the present invention is not limited to this. Another application can be added in accordance with a Bluetooth (registered trademark) profile defined elsewhere.

  RF, Base band, LMP, and HCI operate as the short-range wireless communication unit 101, and L2CAP and higher are realized as programs that operate in the control unit 102. In addition, you may make it operate | move on the near field communication part 101 from L2CAP to each profile hierarchy.

  Next, the initialization process at the time of starting the in-vehicle device 300 is the same as that of the first embodiment described with reference to FIG.

  Here, FIG. 12 to FIG. 12 show examples of an application type management table, an application coexistence possible / impossible combination table, and a priority management table when the three profiles of the HFP application, the AVP application, and the DUN application operate in a multi-profile. 14 will be described.

  FIG. 12 is a diagram illustrating an example of an application type management table in a case where three profiles of an HFP application, an AVP application, and a DUN application operate with a multi-profile. The application type management table is a table showing what input / output is involved for each application. The horizontal axis represents each application, and the vertical axis represents audio output, audio input, video input, video output, data input, data output,... As application types.

  “◯” in the table of FIG. 12 is accompanied by input / output. "X" represents not accompanied.

  Here, in the HFP application, the voice input and the voice output are indicated by “◯”, and the others are indicated by “X”. This indicates that the HFP application is an application that realizes a telephone function, and is an application that involves voice input and voice output.

  In addition, only the audio output of the AVP application is ◯. This indicates that the AVP application is an application with audio output that realizes an audio streaming reproduction function.

  The DUN application represents an application that involves video output, data input, and data output. Both video output and data output are marked with ○, but this means that data may be output as video immediately (displayed in a browser etc.), or data may be stored in memory and used later. Show. The DUN application can be replaced with the PAN application.

  Here, it is assumed that the DUN application is connected to the Internet and displayed on a browser. The application type management table can be uniquely determined once the application is determined.

  FIG. 13 is a diagram illustrating an example of an application coexistence possible / impossible combination table.

  The application coexistence possible / impossible combination table is a table indicating combinations of those that can be operated simultaneously (coexistence) and those that cannot be performed depending on the properties (defined in the application type management table) of each application.

  In the table of FIG. 13, “◯” indicates that coexistence is possible, and “x” indicates that coexistence is not possible.

  Here, the HFP application cannot coexist with the AVP application and can coexist with the DUN application. The AVP application cannot coexist with the HFP application and can coexist with the DUN application. The DUN application can coexist with the HFP application and can coexist with the AVP application.

  The reason why the HFP application and the AVP application cannot coexist will be described. This is an application accompanied by audio output for both the HFP application and the AVP application, and cannot coexist on the premise that only the sound of one application can be output at the same time.

  The reason why the HFP application and the DUN application can coexist is that there is no duplication of the properties of the application, as can be seen from the application type management table.

  FIG. 14 is a diagram illustrating an example of a priority management table. The priority management table defines which applications are preferentially operated when the applications cannot coexist with each other.

  When an interrupt is received from an app with high priority with respect to an app that is currently operating, the app that is currently operating is temporarily suspended, and the operation of the app with high priority that has been interrupted is started. On the other hand, interruptions from apps with a lower priority than the current app are not allowed.

  FIG. 14 shows that the HFP application has a higher priority regarding the HFP application and the AVP application that cannot coexist with each other. The HFP application is given priority because it is a highly real-time application that involves two-way voice communication such as a hands-free call compared to the AVP application.

  In the case of apps that can coexist (for example, a combination of an HFP app and a DUN app), a priority management table is not created.

  Next, the operation of the state management process associated with the activation of the application is the same as in FIG.

  FIG. 15 is a diagram illustrating an example of the application state management table updated in step S204 of the operation flowchart of FIG.

  The application state management table manages the state of each application by any of the currently activated application, the application that is temporarily waiting, and the coexistence application.

  FIG. 15 shows an application state management table in which an activation request for an HFP application (for example, a hands-free incoming call) occurs when the AVP application is activated (during audio streaming playback) and the DUN application coexists (during data communication). Shows the case where is updated.

  At this time, when an incoming call is accepted by the HFP application, the telephone is in a call state, the AVP application is in a paused state, and the DUN application is in a data communication state. In the operation flow of FIG. 7, processing is performed sequentially in the path of S201 → S202 → S205 → S207 → S208 → S204.

  Here, the management application is a basic application of all applications and is activated. The management application is not included in the application state management table of FIG.

  Note that the application state management table of FIG. 15 shows an example in which up to two apps that are temporarily on standby and two coexisting apps can be managed. However, the application status management table is not limited to this, and as the number of apps increases, You can increase the number of apps and coexisting apps.

  Next, the operation when a link loss occurs in the wireless communication apparatus according to Embodiment 2 of the present invention is the same as in FIG.

  Here, the operation of restoring each application in step S305 in the operation flow diagram of FIG. 9 will be described in more detail with reference to FIG.

  FIG. 16 is an operation flowchart showing an operation of restoring each application after the link loss of the in-vehicle device 300. It is assumed that the application state management table before link loss is in the state shown in FIG.

  In FIG. 16, in step S401, the hands-free (HFP application) is restored to the service level (SLC) connection state.

  Next, it is determined whether the call state is continued on the mobile terminal side (step S402). Whether the call state is continued is determined by a status notified from the portable terminal 400 or a response command to the inquiry from the in-vehicle device 300 to the portable terminal 400.

  If the call state is not continued on the mobile terminal side (S402: No), the process proceeds to step S404.

  When the call state is continued on the mobile terminal side (S402: Yes), the hands-free state is restored to the call state.

  In step S404, the audio streaming (AVP application) is restored to the service connection state.

  Next, it is determined whether the pause state of audio streaming is continued on the mobile terminal side (step S405). Whether or not the pause state is continued is determined by a status notified from the portable terminal 400 or a response command to the inquiry from the in-vehicle device 300 to the portable terminal 400.

  If the pause state of audio streaming is not continued on the mobile terminal side (S405: No), the process proceeds to step S407.

  When the pause state of audio streaming is continued on the mobile terminal side (S405: Yes), the audio streaming (AVP application) is restored to the pause state.

  In step S407, the data communication (DUN application) is restored to the service connection state.

  Next, it is determined whether the coexistence state of data communication is continued on the mobile terminal side (step S408). Whether the coexistence state is continued is determined by a status notified from the mobile terminal 400 or a response command to the inquiry from the in-vehicle device 300 to the mobile terminal 400.

  When the coexistence state of data communication is not continued on the mobile terminal side (S408: No), the process is terminated.

  When the coexistence state of data communication is continued on the portable terminal side (S408: Yes), the data communication (DUN application) is restored to the coexistence state (continuation data during WEB browsing is received, and the WEB page is displayed. ).

  As a result, when a link loss occurs during multi-profile operation (HFP application / AVP application / DUN application), it is possible to properly restore the state before the link loss according to the application state management table before the link loss. The convenience for the user can be improved.

  In addition, after the recovery process according to the operation flow of FIG. 16, when the hands-free call changes from the call state to the call end state, the audio streaming sound is changed from the pause state to the reproduction state and the data communication state is maintained.

Further, the case where the three profiles of the HFP application, the AVP application, and the DUN application operate in a multi-profile has been described, but the same can be applied to a multi-profile operation (HFP application / AVP application). At this time, there is no app corresponding to the coexistence app 1 in the app status management table shown in FIG. And the process of S407-S409 of FIG. 16 is omitted.
(Modification 1)
A first modification of the second embodiment of the present invention will be described with reference to FIGS.

  First, an example of an application type management table and an application coexistence possible / impossible combination table when the three profiles of the HFP application, the AVP application, and the PBAP application operate in a multi-profile will be described with reference to FIGS. .

  The priority management table is the same as that shown in FIG.

  FIG. 17 is a diagram illustrating an example of an application type management table in a case where the three profiles of the HFP application, the AVP application, and the PBAP application operate in a multi-profile.

  The PBAP application indicates that the application involves video output, data input, and data output. Video output and data output are marked with ○, but this may output phone book data as video immediately (for example, phone book list display), and store phone book data in memory for later use It shows that there are things to do.

  FIG. 18 is a diagram illustrating an example of an application coexistence possible / impossible combination table.

  Here, the HFP application cannot coexist with the AVP application and can coexist with the PBAP application. The AVP application cannot coexist with the HFP application and can coexist with the PBAP application. The PBAP application can coexist with the HFP application and can coexist with the AVP application.

  The reason why the HFP application and the AVP application cannot coexist is that both the HFP application and the AVP application are accompanied by sound output, and at the same time, it is impossible to coexist on the premise that only sound of one application can be output.

The reason why the HFP application and the PBAP application can coexist is that there is no duplication of the properties of the application, as can be seen from the application type management table.

  Next, the operation of the state management process associated with the activation of the application is the same as in FIG.

  FIG. 19 is a diagram illustrating an example of the application state management table updated in step S204 in the operation flowchart of FIG.

  The application state management table manages the state of each application by any of the currently activated application, the application that is temporarily waiting, and the coexistence application.

  Also, FIG. 19 shows that when an AVP application is being activated (during audio streaming playback) and a PBAP application is coexisting (during phone book transfer), an HFP application activation request (for example, hands-free incoming call) is generated, and application state management is performed. It shows the case where the table is updated.

  At this time, when an incoming call is accepted by the HFP application, the telephone is in a talking state, the AVP application is in a paused state, and the PBAP application is in a telephone book transfer state. In the operation flow of FIG. 7, processing is performed sequentially in the path of S201 → S202 → S205 → S207 → S208 → S204.

  Note that the application state management table in FIG. 19 shows an example in which up to two apps can be managed temporarily and up to two coexisting apps can be managed. However, the application status management table is not limited to this. You can increase the number of apps and coexisting apps.

  Next, the operation at the time of occurrence of a link loss of the in-vehicle device according to the second embodiment (modification 1) of the present invention is the same as that in FIG. 9 described in the first embodiment, and the description thereof is omitted.

  Here, the operation of restoring each application in step S305 in the operation flow diagram of FIG. 9 will be described in more detail with reference to FIG.

  FIG. 20 is an operation flow diagram illustrating an operation for restoring each application after the link loss of the in-vehicle device 300.

  Assume that the application state management table before the link loss is as shown in FIG.

  In FIG. 20, the operations from step S401 to step S406 are the same as those in FIG.

  In step S501, the telephone directory transfer (PBAP application) is restored to the service connection state.

  Next, it is determined whether the coexistence state of the phone book transfer is continued on the portable terminal side (step S502). Whether the coexistence state is continued is determined by a status notified from the mobile terminal 400 or a response command to the inquiry from the in-vehicle device 300 to the mobile terminal 400.

  If the coexistence state of the phone book transfer is not continued on the mobile terminal side (S502: No), the process is terminated. In this case, it is necessary to transfer the phone book data from the beginning again.

When the coexistence state of the phone book transfer is continued on the portable terminal side (S502: Yes), the phone book transfer (PBAP application) is restored to the coexistence state, and the phone book data is transferred from the continuation.

  As a result, when a link loss occurs during multi-profile operation (HFP application / AVP application / PBAP application), it is possible to appropriately restore the state before the link loss according to the application state management table before the link loss. The convenience for the user can be improved.

In addition, after the restoration process according to the operation flow of FIG. 20, when a hands-free call changes from the call state to the call end state, the audio streaming sound is changed from the paused state to the reproduction state and the telephone directory transfer state is maintained.
(Modification 2)
A second modification of the second embodiment of the present invention will be described with reference to FIGS.

  First, an example of an application type management table and an application coexistence possible / impossible combination table when the three profiles of the HFP application, the AVP application, and the MAP application operate in a multi-profile will be described with reference to FIGS. .

  The priority management table is the same as that shown in FIG.

  FIG. 21 is a diagram illustrating an example of an application type management table in a case where three profiles of an HFP application, an AVP application, and a MAP application operate with a multi-profile.

  The MAP application indicates that the application involves video output, data input, and data output. Video output and data output are marked with ○, but this may output message data as video immediately (for example, message list or message body display), and store message data in memory for later use It shows that sometimes. Here, message data refers to SMS, E-Mail, and the like.

  FIG. 22 is a diagram illustrating an example of an application coexistence possible / impossible combination table.

  Here, the HFP application cannot coexist with the AVP application and can coexist with the MAP application. The AVP application cannot coexist with the HFP application and can coexist with the MAP application application. The MAP application can coexist with the HFP application and can coexist with the AVP application.

  The reason why the HFP application and the AVP application cannot coexist will be described. Both the HFP application and the AVP application are applications accompanied by audio output, and cannot coexist on the premise that only the sound of one application can be output at the same time.

  The reason why the HFP application and the MAP application can coexist is that there is no duplication of the properties of the application, as can be seen from the application type management table.

  Next, the operation of the state management process associated with the activation of the application is the same as in FIG.

  FIG. 23 is a diagram illustrating an example of the application state management table updated in step S204 in the operation flowchart of FIG.

  The application state management table manages the state of each application by any of the currently activated application, the application that is temporarily waiting, and the coexistence application.

  FIG. 23 shows an application status management table in which an activation request for an HFP application (for example, a hands-free incoming call) occurs when the AVP application is activated (during audio streaming playback) and the MAP application is coexisting (message transfer). Shows the case where is updated.

  At this time, when an incoming call is accepted by the HFP application, the telephone is in a talking state, the AVP application is in a paused state, and the MAP application is in a message transfer state. In the operation flow of FIG. 7, processing is performed sequentially in the path of S201 → S202 → S205 → S207 → S208 → S204.

  The application state management table in FIG. 23 shows an example in which up to two apps can be managed temporarily and up to two coexisting apps can be managed. However, the application status management table is not limited to this. You can increase the number of apps and coexisting apps.

  Next, the operation at the time of occurrence of a link loss of the in-vehicle device according to Embodiment 2 (Modification 2) of the present invention is the same as that in FIG.

  Here, the operation of restoring each application in step S305 in the operation flow diagram of FIG. 9 will be described in more detail with reference to FIG.

  FIG. 24 is an operation flowchart showing an operation for restoring each application after the link loss of the in-vehicle device 300.

  It is assumed that the application state management table before link loss is in the state shown in FIG.

  In FIG. 24, the operations from step S401 to step S406 are the same as those in FIG.

  In step S601, the message transfer (MAP application) is restored to the service connection state.

  Next, it is determined whether the message transfer coexistence state is continued on the portable terminal side (step S602). Whether the coexistence state is continued is determined by a status notified from the mobile terminal 400 or a response command to the inquiry from the in-vehicle device 300 to the mobile terminal 400.

  When the message transfer coexistence state is not continued on the mobile terminal side (S602: No), the process is terminated. In this case, it is necessary to transfer the message data from the beginning again.

  When the message transfer coexistence state is continued on the mobile terminal side (S502: Yes), the message transfer (MAP application) is restored to the coexistence state, and the message data is transferred from the continuation.

  As a result, when a link loss occurs during multi-profile operation (HFP application / AVP application / MAP application), the state before the link loss can be appropriately restored according to the application state management table before the link loss, and the user The convenience for the user can be improved.

  In addition, after the recovery process according to the operation flow of FIG. 24, when the hands-free call changes from the call state to the end state, the audio streaming sound is changed from the pause state to the reproduction state and the message transfer state is maintained.

  As described above, according to the on-vehicle apparatus described above, when a link loss occurs in the operation state of multi-function simultaneous operation (multi-profile), it was activated before the link loss according to the application state management table before the link loss. Since not only apps but also standby apps and coexisting apps are properly restored, an in-vehicle device that enhances user convenience can be provided.

  In addition, although the point-to-point multi-profile in which the in-vehicle device 300 and the mobile terminal 400 are connected in a one-to-one manner has been described with reference to FIG. The same applies to point-to-multipoint multi-profiles.

  In the above description, HFP application / AVP application / DUN application, HFP application / AVP application / PBAP application, HFP application / AVP application / MAP application are described as examples of combinations of multi-profile operations. 25, and other combinations as shown in FIG.

  FIG. 25 shows a table No. indicating the operation after link loss recovery according to the state of each application before link loss. 1.

  FIG. 26 shows a table No. indicating the operation after link loss recovery according to the state of each application before link loss. 2 (continuation from No. 1).

  Also, not only the combination of three profiles, but also the combination of four profiles, for example, the link loss when connecting HFP application, AVP application, DUN application, PBAP application at the same time and operating simultaneously Applicable to.

  Further, the running state of the vehicle can be determined by a running state detection means (for example, a vehicle speed sensor) (not shown), and the recovery control from the link loss can be performed more finely.

  Further, it may be notified to the user by voice or the like by distinguishing whether or not the state before the link loss restoration has been properly restored. Thereby, it is possible to determine whether or not the user has returned to the normal state before the link loss without moving the line of sight to the in-vehicle display while driving.

  In addition, although Bluetooth (registered trademark) has been described as an example of the short-range wireless communication standard, it is also useful for a wireless LAN or the like.

  The configuration described in the above embodiment is merely a specific example and does not limit the technical scope of the present invention. Any configuration can be employed within the scope of the effects of the present application.

  In the above description, the link loss detection means corresponds to software that operates in the short-range wireless communication unit 101 (for example, Bluetooth (registered trademark) module) and the control unit 102 (for example, CPU), and the short-range wireless communication unit The Bluetooth (registered trademark) module 101 detects a link loss and notifies the CPU as the control unit 102.

  The application state storage means corresponds to the storage unit 109 (memory or the like) and stores the application state management table shown in FIG.

  The recovery means corresponds to software operating on the CPU as the short-range wireless communication unit 101 and the control unit 102, and recovers the wireless communication path after detecting a link loss.

  The application restoration means corresponds to software operating on the CPU as the short-range wireless communication unit 101 and the control unit 102, and restores each application before the link loss.

  The connection means corresponds to software operating on the short-range communication unit 101 (for example, Bluetooth (registered trademark) module) and the control unit 102 (for example, CPU).

  The control means corresponds to software that operates on a control unit 102 (for example, CPU) that controls the short-range wireless communication unit 101.

  As described above, the wireless communication device of the present invention is a wireless communication device that communicates information related to a plurality of applications on a wireless communication path, and a link loss detection unit that detects a link loss of the wireless communication path, An application state storage unit that stores the states of a plurality of applications as an application state, a recovery unit that recovers a wireless communication path that has lost a link, and an application recovery unit that recovers an application, the application recovery unit including the link The loss detection unit detects link loss and the recovery unit recovers the wireless communication path, and then recovers the application according to the application storage state stored in the application state storage unit.

  With this configuration, even when a plurality of applications are operating before the link loss, the application can be recovered according to the application storage state stored in the application state storage unit.

  Further, in the wireless communication device of the present invention, the application state stored in the application state storage means is whether the application is currently activated immediately before the link loss, whether it is temporarily waiting, and coexists with the currently activated application. It is characterized by including whether it is in the coexistence which can operate | move.

  As a result, each application can be properly restored to the state before the link loss, and not only the application that is running immediately before the link loss, but also the application that was coexisting temporarily during standby can be restored reliably. . In addition, when the currently activated application is terminated, the temporarily waiting application can be activated next, and a phenomenon that the state becomes strange due to a link loss can be avoided.

  Furthermore, the wireless communication apparatus of the present invention is characterized in that the application state is cleared when the wireless communication path after the link loss cannot be recovered within a predetermined time by the recovery means.

  As a result, when the opposite wireless communication device is driven by a battery and the link loss cannot be recovered forever due to battery exhaustion, etc., the application state is cleared, so the wireless communication device stores the application state forever. You do n’t have to. Further, after a link loss due to a battery exhaustion, when the connection is established with the opposite wireless communication apparatus after the battery is charged, it is possible to avoid the wireless communication apparatus from acting strangely.

The in-vehicle device of the present invention simultaneously connects a hands-free call protocol for realizing a hands-free call between the own device and the portable terminal and an audio protocol for transferring audio streaming sound from the portable terminal to the own device. Connecting means to
Control means for controlling connection, disconnection, and restoration of a communication protocol between the connection means and the portable terminal, and the control means includes a hands-free call protocol and audio between the connection means and the portable terminal. If a link loss occurs when the audio streaming audio is paused and the hands-free call is in progress when the protocol is connected at the same time, the link is restored to the state immediately before the link loss and the audio when the hands-free call ends. The streaming audio is transited from a pause state to a reproduction state.

  By having this configuration, when a link loss occurs during multi-profile operation (HFP application / AVP application), it is possible to properly restore the state before the link loss according to the application state management table before the link loss, Since each application is restored without performing unnecessary operations for the user, convenience can be improved. In particular, when the user is driving, it can contribute to safe driving.

  An in-vehicle device according to the present invention includes a hands-free call protocol for realizing a hands-free call between the own device and the portable terminal, an audio protocol for transferring audio streaming sound from the portable terminal to the own device, and the portable terminal. A connection means for simultaneously connecting a dial-up communication protocol for realizing data communication with an external network using the gateway function of the communication, and connection, disconnection, and restoration of the communication protocol between the connection means and the portable terminal Control means for controlling, wherein the control means simultaneously connects a hands-free call protocol, an audio protocol and a dial-up communication protocol between the connection means and the portable terminal, and the audio streaming audio is in a paused state and a hands Free is a call state and dial-up communication pro If a link loss occurs when the link is in the data communication state, the state immediately before the link loss is restored, and when the hands-free call ends, the audio streaming sound is changed from the paused state to the playback state, and data communication is performed. The state is maintained.

  By having this configuration, when a link loss occurs during multi-profile operation (HFP application / AVP application / DUN application), the state before the link loss is properly restored according to the application state management table before the link loss. It is possible to improve the convenience because each application is restored without performing an operation unnecessary for the user. In particular, when the user is driving, it can contribute to safe driving.

  The in-vehicle device of the present invention includes a hands-free call protocol for realizing a hands-free call between the own device and a portable terminal, and an audio protocol for realizing a function of transferring audio streaming sound from the portable terminal to the in-vehicle device. And a connection means for simultaneously connecting a telephone directory transfer protocol for downloading telephone directory data in the mobile terminal, and a control for controlling connection, disconnection, and restoration of the communication protocol between the connection means and the mobile terminal Means for simultaneously connecting a hands-free call protocol, an audio protocol, and a telephone directory transfer protocol between the connection means and the portable terminal, the audio streaming audio is in a paused state, and a hands-free call is made. Status and the phonebook transfer protocol is in the phonebook data transfer status When link loss occurs, it is restored to the state immediately before the link loss, and when the hands-free call ends, the audio streaming sound is changed from the paused state to the playback state, and the phone book transfer state is maintained. And

  By having this configuration, when a link loss occurs during multi-profile operation (HFP application / AVP application / PBAP application), the state before the link loss is properly restored according to the application state management table before the link loss. It is possible to improve the convenience because each application is restored without performing an operation unnecessary for the user. In particular, when the user is driving, it can contribute to safe driving.

The in-vehicle device of the present invention includes a hands-free call protocol for realizing a hands-free call between the own device and a portable terminal, and an audio protocol for realizing a function of transferring audio streaming sound from the portable terminal to the in-vehicle device. A connection means for simultaneously connecting a message transfer protocol for downloading message data in the portable terminal, and a control means for controlling connection, disconnection, and recovery of the communication protocol between the connection means and the portable terminal; The control means simultaneously connects a hands-free call protocol, an audio protocol, and a message transfer protocol between the connection means and the portable terminal, the audio streaming voice is in a paused state, the hands-free is in a call state, and a message. The transfer protocol is message data When a link loss occurs in the transfer state, the state immediately before the link loss is restored, and when the hands-free call ends, the audio streaming sound is changed from the paused state to the playback state and the message transfer state is changed. It is characterized by maintaining.

  By having this configuration, when a link loss occurs during multi-profile operation (HFP application / AVP application / MAP application), the state before the link loss is properly restored according to the application state management table before the link loss. It is possible to improve the convenience because each application is restored without performing an operation unnecessary for the user. In particular, when the user is driving, it can contribute to safe driving.

  The link loss recovery method of the present invention is a link loss recovery method for a wireless communication apparatus that communicates information related to a plurality of applications on a wireless communication path. A link loss detection step, an application state storage step for storing the states of a plurality of applications before the link loss, a recovery step for recovering a wireless communication path after the link loss detection means detects a link loss, and the recovery step Then, after the wireless communication path is restored at, an application restoration step for restoring the application according to the application storage state stored at the application state storage step is executed.

  With this configuration, even if a plurality of applications are activated before link loss, the application can be recovered according to the application storage state stored in the application state storage unit.

The wireless communication device of the present invention is useful as a hands-free device mounted in a vehicle, a car navigation device, a car multimedia terminal, a mobile phone, a mobile terminal such as a PHS, or the like.

DESCRIPTION OF SYMBOLS 1 Public network 10 1st communication layer structure 20 2nd communication layer structure 30 3rd communication layer structure 100 Wireless communication apparatus 101 Short-range wireless communication part 102 Control part 103 Audio | voice input part 104 Audio | voice output part 105 Image | video input part 106 Video output unit 107 Data input unit 108 Data output unit 109 Storage unit 200 Opposing wireless communication device 300 In-vehicle device 400 Portable terminal

Claims (8)

In a wireless communication device that communicates information related to multiple applications on a wireless communication path,
A link loss detection means for detecting a link loss of a wireless communication path;
Application state storage means for storing the states of a plurality of applications before link loss as application states;
A recovery means for recovering the link loss wireless communication path;
With application recovery means to recover the application,
The application recovery means recovers an application according to the application storage state stored in the application state storage means after the link loss detection means detects a link loss and the recovery means recovers the wireless communication path. A wireless communication device.   The app status stored by the app status storage means is whether the app is currently active immediately before the link loss, whether it is temporarily waiting, whether it is coexisting with the currently active app The wireless communication apparatus according to claim 1, further comprising:   The wireless communication apparatus according to claim 1 or 2, wherein when the wireless communication path cannot be recovered within a predetermined time by the recovery means, the recovery means clears the application state. A connection means for simultaneously connecting a hands-free call protocol for realizing a hands-free call between the own device and the portable terminal and an audio protocol for transferring audio streaming audio from the portable terminal to the own device;
Control means for controlling connection, disconnection, and recovery of a communication protocol between the connection means and the mobile terminal;
The control means simultaneously connects a hands-free call protocol and an audio protocol between the connection means and the mobile terminal, and a link loss occurs when audio streaming audio is paused and hands-free is in a call state. In this case, the vehicle-mounted device is configured to restore the state immediately before the link loss and to change the audio streaming sound from the paused state to the playback state when the hands-free call is finished. Uses a hands-free call protocol for realizing a hands-free call between the local device and the mobile device, an audio protocol for transferring audio streaming audio from the mobile device to the local device, and the gateway function of the mobile device. A connection means for simultaneously connecting the network and a dial-up communication protocol for realizing data communication;
Control means for controlling connection, disconnection, and recovery of a communication protocol between the connection means and the mobile terminal;
The control means simultaneously connects a hands-free call protocol, an audio protocol, and a dial-up communication protocol between the connection means and the portable terminal, and audio streaming voice is in a paused state, hands-free is in a call state, and dial-up communication. If a link loss occurs when the protocol is in the data communication state, the state immediately before the link loss is restored, and at the end of the hands-free call, the audio streaming sound is changed from the paused state to the playback state, and data communication An in-vehicle device characterized by maintaining a state. Hands-free call protocol for realizing hands-free call between own device and portable terminal, audio protocol for realizing function of transferring audio streaming sound from portable terminal to in-vehicle device, and telephone in portable terminal Connection means for simultaneously connecting a phone book transfer protocol for downloading book data;
Control means for controlling connection, disconnection, and recovery of a communication protocol between the connection means and the mobile terminal;
The control means simultaneously connects a hands-free call protocol, an audio protocol, and a telephone directory transfer protocol between the connection means and the portable terminal, the audio streaming voice is in a paused state, the hands-free state is in a telephone state, and the telephone directory is transferred. If a link loss occurs when the protocol is in the phone book data transfer state, the state immediately before the link loss is restored, and when the hands-free call ends, the audio streaming sound is changed from the paused state to the playback state. A vehicle-mounted device that maintains a telephone directory transfer state. Hands-free call protocol for realizing hands-free call between own device and portable terminal, audio protocol for realizing function of transferring audio streaming sound from portable terminal to in-vehicle device, and message in portable terminal A connection means for simultaneously connecting a message transfer protocol for downloading data;
Control means for controlling connection, disconnection, and recovery of a communication protocol between the connection means and the mobile terminal;
The control means simultaneously connects a hands-free call protocol, an audio protocol, and a message transfer protocol between the connection means and the portable terminal, audio streaming audio is in a paused state, hands-free is in a call state, and a message transfer protocol is If a link loss occurs in the message data transfer state, the state immediately before the link loss is restored, and when the hands-free call ends, the audio streaming sound is changed from the paused state to the playback state and the message is transferred. An in-vehicle device characterized by maintaining a state. In a link loss recovery method for a wireless communication device that performs communication of information related to multiple applications on a wireless communication path,
In the control unit of the wireless device,
A link loss detection step for detecting a link loss of a wireless communication path;
An application state storage step for storing a plurality of application states before link loss;
After the link loss detection means detects a link loss, a recovery step for recovering the wireless communication path;
After restoring the wireless communication path in the restoration step, an application restoration step for restoring the application according to the application storage state stored in the application state storage step;
The link loss recovery method characterized by performing this.