KR20060036882A - Telematics service system and its method - Google Patents

Abstract

1. TECHNICAL FIELD OF THE INVENTION

The present invention relates to a telematics service system and a method thereof.

2. The technical problem to be solved by the invention

The present invention provides a wired / wireless interworking function independent of the mobile network to provide a telematics service without using a gateway inside the mobile network, and provides an interface for integrating an external system that requires interworking. The purpose of the present invention is to provide a telematics service system and a method for providing an environment in which a telematics service can be easily developed without knowing the detailed structure of an external system that requires interworking with a network infrastructure.

3. Summary of the Solution of the Invention

The present invention provides a telematics service system comprising: application means for providing a telematics service; Interlocking means for providing an independent wired / wireless interworking function to the mobile network such that the application means can provide a telematics service without using a gateway inside the mobile network; And interfacing means for providing an integrated interface capable of interworking with an external system.

4. Important uses of the invention

The present invention is used in a telematics service system.

Telematics Service, Gateway, Service Integration, Simple Object Access Protocol (SOAP)

Description

Telematics service system and its method             

1 is a configuration diagram of an embodiment of a conventional telematics service system;

2 is a configuration diagram of an embodiment of a telematics system according to the present invention;

3 is a diagram illustrating an example of a difference between a telematics system and a conventional telematics system according to the present invention;

4 is a diagram illustrating an embodiment of a process in which a telematics system according to the present invention interacts with an SMS-based telematics terminal application using an SMS service provided by a wireless communication network;

5 is a diagram illustrating an embodiment of a process of providing a telematics service developed using a gateway framework according to the present invention;

FIG. 6 is a signal flow diagram of an embodiment of a process of controlling congestion on a wireless network using a "Reno TCP" conventionally made for a wireline; FIG.

FIG. 7 is a signal flow diagram of an embodiment of a process for controlling congestion on a wireless network using a "NewReno TCP" developed by complementing a conventional "Reno TCP"; FIG.

8 is an exemplary signal flow diagram illustrating a congestion control process of a wireless TCP processor included in a gateway according to the present invention;

9 is a signal flow diagram of an embodiment of a process of an explicit congestion control by a wireless TCP processor included in a gateway according to the present invention; and

FIG. 10 is a diagram for explaining a process of requesting a rescue request to a 119 emergency rescue service server by using a telematics system according to the present invention.

* Explanation of symbols on the main parts of the drawing

11: telematics terminal 12: wireless communication network

13: telematics system 20: gateway

21: wireless TCP processing unit 22: SMS gateway

23: HTTP processing unit 24: push module

The present invention relates to a telematics service system and a method thereof, and more particularly, to provide a wired / wireless interworking function independent of a mobile network so that a telematics service can be provided without using a gateway inside the mobile network. Telematics service system to provide an environment that can easily develop a telematics service without knowing the detailed structure of the external system that needs to interwork with the infrastructure of the mobile network by providing an interface that can integrate the necessary external system, and It's about how.

Recently, a telematics technology that provides a driver with various services such as automatic accident reporting, emergency service call, and road guidance service by integrating mobile communication technology, satellite positioning technology, map information technology, and vehicle device control technology to a driver through an in-vehicle terminal Development is active. In the future, telematics technology is expected to evolve to provide a more convenient and safe driving environment and provide an environment where all information services used in the office or home can be used without interruption in the car.

In order to evolve the telematics technology, developers who do not know the details of the lower network technology and integrated technology of the mobile network can more easily develop a system that can provide telematics services through various types of terminals and mobile network systems. There is a need for technology that provides an environment.

However, in the past, automakers and mobile carriers cooperated with each other to develop and operate a telematics service system using their own technology, and thus developed in a form dependent on a specific hardware (terminal), an operating system, and a mobile communication network system.

As a result, a terminal that does not have a specific hardware or operating system cannot receive a telematics service. Therefore, since the telematics service developed by investing a lot of development cost, manpower, and time is not provided through various terminals and various mobile communication networks, but through a specific terminal and a specific mobile communication network, a service can be provided to many users. There is a problem that the user is not given the opportunity to select a variety of services, and eventually a variety of quality service development can not be achieved.

Referring to Figure 1 will be described in more detail with respect to the configuration of the conventional telematics service system.

1 is a diagram illustrating an embodiment of a conventional telematics service system.

As shown in FIG. 1, the conventional telematics service system includes a telematics terminal 11 equipped with a client application such as Hyper Text Transfer Protocol (HTTP), Transmission Control Protocol / Internet Protocol (TCP / IP), a wireless protocol, and the like. Billing / authentication server, short messaging service server, wireless communication network 12 including WAP gateway, billing / authentication server of wireless communication network 12, short messaging service server, and location acquisition server connected via internet, e-mail server , A telematics system 13 for providing a telematics service in conjunction with a map service server, a traffic information providing server, a 119 rescue service server, and the like.

As described above, the conventional telematics service system is developed in conjunction with an authentication / billing server in a wireless communication network as shown in FIG. 1 and uses a gateway (WAP 2.0 gateway) that performs a wired / wireless network interworking function in a transport layer. Service was provided. That is, the telematics system 13 provides a telematics service to the telematics terminal 11 in the vehicle by using a lower transmission protocol such as TCP / IP and HTTP through the WAP gateway in the wireless communication network 12. At this time, the telematics system 13 may be configured to provide various services to the telematics terminal 11 located in the vehicle, such as a location acquisition server, a 119 rescue service server, a traffic information providing server, and the like. They are interconnected using the transport protocol.

At this time, the server applications at the top of the telematics system 13 use the transmission protocol such as TCP / IP or HTTP or a short messaging service (SMS) to call the telematics terminal 11 with an emergency call, trouble report, In order to provide various services such as a real-time road guidance service, a link channel must be established in advance using a CDMA modem or a wireless LAN adapter.

For example, the emergency call service, which is one of the services provided by the telematics system 13, receives a service request message from the telematics terminal 11, grasps the contents included in the service request message, and then relates to an associated external server, that is, 119. The emergency service is requested by transmitting the location information of the vehicle equipped with the telematics terminal 11 to the rescue service server. In this case, in addition to emergency service request, the vehicle may request towing service of the vehicle, or may request additional towing and car rental service by sending location data of the broken car to the telematics terminal of the car center and the car rental service center. As such, the telematics system 13 must interwork with related servers through an external server interworking component according to a service provided.

However, the conventional telematics system is developed by using an authentication / billing system in a wireless communication network, as shown in FIG. 1, and provides a service using a WAP gateway that performs a wired / wireless network interworking function in a transport layer. have. That is, since a service is developed and provided in a form dependent on a specific wireless communication network, a service provider cannot provide a service through different wireless communication networks. In order for a service provider to provide service through another wireless communication network, a service-dependent part of the wireless communication network must be re-developed and the service can be provided only by changing the WAP gateway of the wireless communication network.

As such, the conventional telematics system has a problem in that a service provider cannot service a developed service through a different wireless communication network and cannot provide a telematics service without using a gateway included in the wireless communication network.

In addition, in order to provide various telematics services, an external service system such as a location acquisition server, a 119 rescue service server, a traffic information providing server, and the like should be interlocked. However, these external service systems are developed and operated with different technologies, and in particular, since they do not provide a standardized interface, much effort is required to integrate them.

Therefore, there is an urgent need to develop an environment in which a telematics service system can be developed independently of specific hardware, an operating system, and a wireless communication network of a telematics terminal, and a telematics infrastructure system providing such an environment.

The present invention has been proposed to solve the above problems, and provides an independent wired / wireless interworking function to provide a telematics service without using a gateway inside the mobile network, and requires interworking. Telematics service system and method for providing an environment that can easily develop telematics service without knowing detailed structure of external system that needs interworking with infrastructure of mobile network by providing interface that can integrate external system The purpose is to provide.

Other objects and advantages of the present invention can be understood by the following description, and will be more clearly understood by the embodiments of the present invention. In addition, it will be readily appreciated that the objects and advantages of the present invention may be realized by the means and combinations thereof indicated in the claims.

An apparatus of the present invention for achieving the above object is a telematics service system, comprising: application means for providing a telematics service; Interlocking means for providing an independent wired / wireless interworking function to the mobile network such that the application means can provide a telematics service without using a gateway inside the mobile network; And interfacing means for providing an integrated interface capable of interworking with an external system.

Meanwhile, the method of the present invention provides a telematics service method, comprising: an interworking step of interworking a wired / wireless network independently of a mobile network without using a gateway in a mobile network according to a service providing request from a telematics terminal; A telematics service providing step of providing a telematics service by interworking with the wired and wireless network; And an external system interworking step of providing a telematics service by interworking with an external system using an integrated interface provided in a framework form.

The above objects, features and advantages will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, whereby those skilled in the art may easily implement the technical idea of the present invention. There will be. In addition, in describing the present invention, when it is determined that the detailed description of the known technology related to the present invention may unnecessarily obscure the gist of the present invention, the detailed description thereof will be omitted. Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

2 is a configuration diagram of an embodiment of a telematics system according to the present invention.

As shown in FIG. 2, the telematics system according to the present invention includes a gateway 20 for providing an independent wired / wireless interworking function to a mobile network so as to provide a telematics service without using a gateway inside the mobile network. ), A gateway framework 30 for providing an interface for integrating external systems that require interworking, and an application 40 for providing a telematics service, so that new services can be easily developed.

The gateway 20 performs a wired / wireless interworking function in a transport layer, and provides a wireless transmission control protocol for providing a telematics service without using a WAP 2.0 gateway, which is a wired / wireless interworking gateway provided by a wireless communication network. The SMS 21 and the HTTP (HyperText Transfer Protocol) for sending and receiving messages to the processor 21 and the SMS-based applications can send and receive messages. It includes a wireless HTTP processor 23 for supporting the push and push module 24 for applications that provide a push (PUSH) type of service.

The wireless TCP processing unit 21 is a wired / wireless interworking WAP in a wireless communication network for use in a mixed environment of “Taho TCP”, “Reno TCP”, “NewReno TCP” or a wired / wireless section that has been previously developed for use in a wired network. It provides a different transport control mechanism than the 2.0 gateway.

The existing "Taho TCP", "Reno TCP", and "NewReno TCP" transmits one segment at the beginning, and then receives two segments after receiving an acknowledgment (ACK) from the receiver. When two acknowledgments are received from the receiver, four segments are sent again.

As such, existing "Taho TCP", "Reno TCP", and "NewReno TCP" rapidly access the available bandwidth of the network while exponentially increasing the number of segments to be transmitted. As a result, the existing TCP doubles the amount of transmission (CWND: Congestion Window Size) at every round trip time. This is called slow start.

In general, the maximum value of CWND at slow start is the product of the bandwidth of the network (Bandwith) and the round trip time, and the ad window size (AdWin) that the receiver informs the sender of the current buffer size. : Decide small value among Advertized Window. At this time, the maximum size of the ad window size AdWin is 64 Kbytes.

On the other hand, in the existing "Taho TCP", "Reno TCP", and "NewReno TCP", slow start is used only when the first connection and timeout occur. At this time, when the transmission amount CWND is increased and the predetermined slow start threshold (SSTHRESH: Slow Start THRESHold) is reached, the mode is switched to congestion avoidance mode. In congestion avoidance mode, each acknowledgment (ACK) is increased by half of the current transmission, increasing linearly by one segment within approximately one round trip time. Eventually, it adapts to the state of the network while fully utilizing the available bandwidth of the network.

As shown in FIGS. 6 and 7 during the transmission of the segments, if a fixed number (for example, three or more) duplicate ACKs are received, the previously transmitted segments may be damaged by network congestion. The segment of the sequence number described in the duplicate ACK is retransmitted even before the timeout time calculated based on the round trip time (RTT) is considered to be lost. This is called fast retransmission. In this case, the mode is switched to the congestion avoidance mode described above without performing slow start. This is called fast recovery. The advantage of fast retransmission is that the delay time can be reduced by immediately retransmitting the lost segment without waiting for a timeout, and the amount of transmission (number of segments (CWND)) does not have to be halved. . However, when the value of the transmission amount CWND is small and the acknowledgment ACK is not received enough to perform fast retransmission, the retransmission is performed by retransmission timeout.

FIG. 6 is a signal flow diagram illustrating an example of a process of controlling congestion on a wireless network using a "Reno TCP" which is conventionally made for wired transmission. The transmission side transmits twelve data segments. Assuming that it is lost, the process of retransmission is shown.

"Reno TCP" receives a normal acknowledgment (ACK) when the sender transmits twelve segments and then the receiver receives a normal acknowledgment (ACK). If some of them are lost, a "Reno TCP" receives a duplicate acknowledgment. At this time, if three or more duplicate ACKs are received, congestion occurs in the network and it is determined that a packet is lost. Thus, the transmission speed (amount) (Cwnd: congestion window size) is reduced to about half (13/2 + 3) and the second segment lost is retransmitted. Each time another acknowledgment (ACK) arrives, the transmission amount (Cwnd) is increased by one. When the second duplicated ACK is received three times, the third segment is retransmitted. And if the retransmission timeout time has elapsed and a duplicate acknowledgment is not received for the fourth segment lost during transmission, the sender reduces the transmission rate (congestion window size: Cwnd) to 1 and retransmits the fourth segment again. do.

FIG. 7 is a signal flow diagram illustrating an example of a process of controlling congestion over the air by using a "NewReno TCP" developed by complementing the conventional "Reno TCP." Is different from

That is, if the sender receives three duplicate ACKs for the second segment, it retransmits the second segment, and receives only one response (ACK) to successfully receive the second segment and transmit the third segment. Resend the third segment. It expects an acknowledgment (ACK) to transmit the 13th segment from the receiver, but because it did not receive it, it is determined that another packet is lost in the middle and retransmits immediately after receiving an acknowledgment (ACK) to transmit the third segment. The existing "RenoTCP" retransmitted only when three duplicate ACKs were received.

On the other hand, the transmission control protocol (TCP) used in the conventional wired network has been improved in order to reduce the cause of packet loss occurring during transmission to the network congestion and to reduce the packet loss caused by congestion. Effective use of Transmission Control Protocol (TCP) in wireless networks with high packet loss has emerged as an important issue. In other words, when using "Reno TCP", which is intended to be used on a wired line, in a wireless section with high error rate, the transmission speed drops rapidly and TCP / IP-based applications cannot serve properly.

On the other hand, the wireless TCP processing unit 21 included in the gateway according to the present invention can recover packet loss occurring in a wireless environment much faster than the conventional transmission control protocol (TCP). As described above, in order to recover when three packets are lost in the related art, the sender reduced the transmission rate in half and recovered through three retransmissions. In contrast, the wireless TCP processing unit 21 according to the present invention can quickly recover by simultaneously retransmitting three packets without reducing the transmission speed (size of Cwnd), as shown in FIG. Can increase. In particular, the wireless TCP processing unit 21 may exhibit high transmission efficiency in a wireless environment where a lot of packet loss occurs or in an environment in which wired and wireless sections are mixed.

8 is a signal flow diagram of an embodiment of a process of congestion control by the wireless TCP processing unit 21 included in the gateway according to the present invention.

First, if 12 segments are transmitted from the sender (TCP level), and three of them are lost, the receiver (TCP level) sends the response (ACK) number of the last transmitted segment and the serial number of the currently received segment. (sequence number) and the serial number of the next segment to be transmitted are transmitted to the sender.

The sender then compares the first and second segment numbers when it receives three duplicate acknowledgments and finds out that an empty segment is missing during transmission.

Then, the transmitting side immediately transmits three missing segments to the receiving side. This means that retransmissions are much faster than "Reno TCP" and "NewReno TCP" described earlier, which results in much faster transfer rates.

In addition, the wireless TCP processing unit 21 may provide explicit transmission control to prevent the overall transmission speed of the transmitting and receiving end from dropping. That is, the general transmission control protocol (TCP) is congested in the network when a timeout occurs because an acknowledgment packet does not arrive at the transmitting end for a predetermined time or when a duplicate acknowledgment is received, which means the loss of a data packet. Suppose this happened. Therefore, the sender performs slow start and congestion avoidance, which reduces the size of the congestion window and slowly increases the transmission speed, to mitigate network congestion and reduce packet loss.

However, since the wireless network has a higher error rate than the wired network, packet loss due to bit error is frequent. Therefore, if the existing transmission control protocol (TCP) is applied to the wireless network as it is, packet loss is unnecessarily lowered according to the assumption that congestion has occurred in the network. If packet loss occurs repeatedly, the transmission rate does not increase and remains low. As a result, the bandwidth of the link is wasted and overall network performance is degraded.

On the other hand, applications of telematics terminals and telematics server applications that provide services to the applications on the Internet establish a message transmission channel and exchange messages using a transport control protocol (TCP). The environment in which the telematics service is provided is an environment in which a wireless environment such as a wireless communication network and a wired network such as the existing Internet are mixed. In such an environment, if a message is exchanged using the existing transmission control protocol (TCP), an efficient service cannot be provided due to a serious reduction in data transmission.

In other words, if a conventional transmission control protocol (TCP) is used for a telematics system that provides services in a mixed environment of wired and wireless networks, it is determined that packet loss occurring at the link level of the wireless network is caused by congestion. By performing unnecessary congestion control, there is a problem that the throughput is reduced, and thus TCP / IP applications cannot properly provide services. The wireless TCP processing unit 21 according to the present invention additionally provides a function to handle data loss and transmission delay that may occur due to handoff in a link layer of a wireless network in order to solve these problems.

1) Set the window size large.

The wireless TCP processing unit 21 according to the present invention calculates the window size as a bandwidth * delay time in order to maximize performance, but the advertisement window on the receiving side and the congestion window on the transmitting side. window) is set to the maximum available window size.

For example, if the bandwidth of Ethernet LAN is 10Mbps and the round trip time (Delay) is 3ms, 12BDP is 3750 Bytes. When the recipient's ad window size is 3450 Bytes, the maximum window size available is 3450 bytes, the recipient's ad window size.

2) If the window size is 64KB or larger, use the window scale option.

For example, if the bandwidth of a T3 telephone line is 45Mbps and the delay is 60ms, the BDP is 337,500 bytes (337.5KB). At this time, the window size is 337.5KB, so the window size can be set to 64KB or more using the window scale option.

In addition, the wireless TCP processor 21 according to the present invention supports a round trip time measurement (RTTM) function.

The existing Transmission Control Protocol (TCP) collects one delay time (RTT) sample per window and uses it to determine the retransmission timeout. However, when the window size is large, the delay time (RTT) value does not reflect the actual delay time. "RFC1324" requires frequent measurement of delay time (RTT) for window sizes containing eight or more segments. Whenever possible, the accurate delay time (RTT) should be measured to determine the retransmission timeout time. If not, retransmission timeout occurs unnecessarily, and the transmission speed is drastically reduced due to the change to the slow start mode.

3) Set the initial window size to the size of two or more segments.

The existing Transmission Control Protocol (TCP) sets the initial window size to one segment size. As described above, when receiving an acknowledgment (ACK) by transmitting the first one segment, the two segments are transmitted, and in the same manner, the capacity of the network is increased while doubling the transmission amount. At this time, in order to increase the transmission speed faster, two segments are transmitted from the beginning.

4) It provides Path MTU discovery mechanism.

In the path between the sending TCP and the receiving TCP, there is a network with various kinds of transmission speeds. Their networks have different message transfer units. The mechanism for finding the size of a transmission unit to prevent fragmentation of a message on a path having different message transmission units is called a path message transmission unit (Path MTU) discovery mechanism.

Transmission Control Protocol (TCP) sets the default message transmission unit (MTU) value as the maximum segment size (MSS) from the beginning, improving transmission efficiency rather than avoiding fragmentation during transmission, but if fragmentation occurs during transmission, route message transmission. Use a Path MTU discovery mechanism to reduce the maximum segment size (MSS) so that fragmentation does not occur.

5) Explicit Congestion Notification is provided.

Explicit Congestion Notification (ECN) is a mechanism by which a router explicitly notifies a sender of congestion when congestion is expected in the network. When the sender's TCP receives an explicit congestion notification (ECN) message from the router, it reduces the data rate to reduce network congestion. Explicit Congestion Notification (ECN) allows you to distinguish between data loss caused by network congestion and simple segment loss due to errors, thereby improving the performance of Transmission Control Protocol (TCP) by reducing the use of unnecessary congestion control algorithms. . An explicit congestion notification process will be described in more detail with reference to FIG. 9.

9 is a signal flow diagram of an embodiment of a process for explicit congestion control by a wireless TCP processor included in a gateway according to the present invention.

First, a negotiation for explicit congestion control is started at the sending side (TCP level) with the receiving side (TCP level). At this time, the transmitting side checks whether the receiving side can perform explicit congestion control.

After the explicit congestion control is completed, if the RED (Random Error Detection) router in the intermediate node detects the initial congestion while both sides are transmitting and receiving data, the receiver informs the receiver of the congestion. Notify that it has occurred.

Then, the transmitting side transmits the segment to the receiving side while reducing the congestion window size (the number of segments to be transmitted) to 1 and gradually increasing the transmission speed. This can prevent the degradation of the overall transmission rate due to unnecessarily repeated retransmissions by reducing the transmission rate in advance before congestion occurs.

However, in order to use this explicit congestion notification (ECN) function, all routers on a TCP connection path must support Dynamic Queue Management (DQM) such as Random Early Detection (RED). do.

Meanwhile, the telematics server application and the client application of the telematics terminal on the Internet may exchange short messages using a short messaging service (SMS) provided by a wireless network.

That is, as shown in FIG. 4, the telematics system on the Internet transmits and receives a short message using a short message peer-to-peer (SMPP) protocol and a short message service server in a wireless network to transmit and receive a short message with the telematics terminal. do.

The SMS gateway 22 transmits a message to a telematics terminal through a short message service server in a wireless network or receives a short message transmitted by a telematics terminal through a short message service server. At this time, the TCP port number of the SMS-based telematics server application and the port number of the short message service server should be determined in consultation with the wireless network.

On the other hand, there are two types of telematics services: a push type and a pull type. Pull type refers to a form in which a server provides a service according to a client's request, and a push type refers to a form in which a server unilaterally provides a service to a client. In the present invention, the push module 24 is a module required to implement such a push type service, and transmits a short message according to the telephone number and service name of the telematics terminal designated by the server. At this time, the telematics terminal receiving the short message operates the corresponding service, opens a socket channel to the telematics service server, and receives the service.

Referring to Figure 3 will be described in more detail the difference between the telematics system according to the present invention and the conventional telematics system.

3 is a diagram illustrating an example of a difference between a telematics system and a conventional telematics system according to the present invention.

As shown in FIG. 3, the conventional general telematics system has interoperated with TCP / IP-based server-client applications using a wired / wireless interworking gateway (WAP 2.0 gateway) of a wireless communication network.

In contrast, the telematics system according to the present invention does not use a wired / wireless interworking gateway (WAP 2.0 gateway) of a wireless communication network as shown in FIG. As described above, the wired / wireless interworking gateway (WAP 2.0 gateway) according to the present invention divides the wired section and the wireless section, and the wireless section transmits and controls the transmission using wireless TCP according to the characteristics of the wireless link. Control transmission using.

At this time, the characteristics of the radio link include limited bandwidth, high error rate, and temporary handoff. In particular, a feature of the wired / wireless interworking gateway (WAP 2.0 gateway) according to the present invention is that an error in the wireless section does not affect the wired section. That is, the wired / wireless interworking gateway retransmits the lost packet when the packet being transmitted is lost due to limited bandwidth, high error rate, and temporary disconnection in the wireless section, thereby preventing the packet loss in the wireless section from spreading to the wired section. Do not use TCP in wired section for unnecessary congestion control. As a result, an error in the wireless section prevents the transmission speed of the entire wired / wireless section from dropping.

In addition, the wired / wireless interworking gateway (WAP 2.0 gateway) according to the present invention, as shown in Figure 5, provides an environment that can provide services through a number of mobile networks without undergoing an optimization process once developed telematics services. 5 is a diagram illustrating an embodiment of a process of providing a telematics service developed using the gateway framework 30 according to the present invention.

The existing telematics service is developed using a wired / wireless interworking gateway and a billing authentication system provided by a specific mobile carrier. Therefore, in order for a service provider to provide a service in a different network, the interface part of the mobile network must be changed and developed. It was. In contrast, the telematics service developed by using the gateway framework 30 according to the present invention is an application program interface provided by the gateway framework 30 even though the process is not optimized for each mobile network as shown in FIG. 5. (API) service is available to all mobile networks.

In addition, by using a SOAP function provided by the gateway framework 30, it is possible to easily interwork with an external server that provides an emergency rescue service.

On the other hand, as mentioned earlier, attempting to develop a new telematics service requires integration with a service system that provides various related services. In this case, when the service system to be integrated provides a standard interface, it is relatively easy to integrate, but conventionally, a general service system is developed independently of each other. Developing a new telematics service required a lot of effort and time.

In the present invention, a new telematics service can be easily used by using a gateway framework 30 that provides an interface using XML (Extensible Markup Language) messages in order to flexibly integrate with a service system that provides a related service when developing a telematics service. To develop.

That is, the gateway framework 30 provides an interface for integrating external systems that require interworking when developing a telematics service. That is, in general, the telematics service should integrate external service systems such as a location acquisition server, a 119 rescue service server, a traffic information providing server, etc., but it is difficult for a service developer to integrate them. Accordingly, the gateway framework provides an environment in which a service can be easily developed by providing a basic framework including an interface with an external service system.

The gateway framework 30 includes a related system interworking component and a SOAP interworking component for providing application protocol interfaces (APIs) of the related service system.

The related system interworking component provides application protocol interfaces (APIs) of the related service system, so that telematics service developers can write code using the services provided by the server without knowing the location (IP address) of the related service server. . In addition, the related system interworking component provides application protocol interfaces (APIs) that can call and use methods of classes in a remote system in the local system.

The SOAP interworking component provides flexible system integration based on XML. Simple Object Access Protocol (SOAP) is a protocol for exchanging structural information expressed in XML in a distributed environment. It was created at the World Wide Web Conference (W3C). SOAP provides XML-based loose coupling by providing the ability to access objects on remote systems.

That is, as shown in FIG. 10, the SOAP interworking component may be implemented as a SOAP client accessing a service provided by a 119 server implemented as a SOAP server, a traffic information server, or the like. Therefore, a telematics service developer can call and use a service provided by a related system by a SOAP client call.

FIG. 10 is a diagram for explaining a process of requesting a rescue request to a 119 emergency rescue service server by using a telematics system according to the present invention.

As a representative telematics service currently provided, an emergency rescue service program of a vehicle terminal receives vehicle status information from a vehicle control / monitoring system when a crash occurs while a vehicle is driving, and a GPS (Geographic Positioning System) in the vehicle is received. After receiving the current position information (longitude / latitude coordinate information) of the vehicle from the receiver, there is a service that can request the emergency rescue by transmitting the transmitted vehicle state information and vehicle position information to the telematics system through a wireless communication network.

That is, the telematics system automatically delivers the location information of the accident vehicle to the 119 rescue system, the police accident report reception center, and the vehicle towing center in response to an emergency rescue request from the vehicle terminal, thereby promptly rescue the driver and passengers. At this time, the telematics system according to the present invention uses an interface (SOAP client and server) provided by the gateway framework 30 to interact with service servers such as a 119 rescue system, a police accident report reception center, and a vehicle towing center. do.

As described above, the method of the present invention may be implemented as a program and stored in a recording medium (CD-ROM, RAM, ROM, floppy disk, hard disk, magneto-optical disk, etc.) in a computer-readable form. Since this process can be easily implemented by those skilled in the art will not be described in more detail.

The present invention described above is capable of various substitutions, modifications, and changes without departing from the technical spirit of the present invention for those skilled in the art to which the present invention pertains. It is not limited by the drawings.

The present invention as described above, provides an independent wired and wireless interworking function to the mobile network to provide a telematics service without using a gateway in the mobile network, and to integrate an external system that requires interworking By providing it, it is possible to provide an environment in which various and quality telematics services can be easily developed without knowing the detailed structure of an external system that requires interworking with the infrastructure of the mobile network.

Claims (17)

In the telematics service system, Application means for providing a telematics service; Interlocking means for providing an independent wired / wireless interworking function to the mobile network such that the application means can provide a telematics service without using a gateway inside the mobile network; And Interfacing means for providing an integrated interface that can interoperate with external systems Telematics service system comprising a. The method of claim 1, The interlocking means, Telematics service system characterized in that for performing a function of transmitting a short message to a telematics terminal or a short message transmitted by a telematics terminal using a short messaging service (SMS) provided by a mobile network. The method of claim 1, The interlocking means, A telematics service system, characterized in that it further performs a function to support the sending and receiving of messages using the HyperText Transfer Protocol (HTTP). The method of claim 1, The interlocking means, Telematics service system characterized in that it further performs a function of supporting an application that provides a push (PUSH) service. The method according to any one of claims 1 to 4, The interlocking means, In order to provide the telematics service without using a gateway inside the mobile network, the application means provides an independent wired / wireless interworking function to the mobile network. Telematics service system, characterized in that to recover quickly by simultaneously retransmitting lost packets without reducing the size. The method according to any one of claims 1 to 4, The interlocking means, Calculate the window size as Bandwidth * Delay, but set the minimum value of the Advertisement window on the receiving side and the congestion window on the sending side to the maximum available window size. Telematics service system. The method according to any one of claims 1 to 4, The interlocking means, A telematics service system that allows a window size to be set above a preset value using a window scale option and determines a retransmission timeout time using a Round Trip Time Measurement (RTTM) function. The method according to any one of claims 1 to 4, The interlocking means, By setting the default message transmission unit (MTU) value as the maximum segment size (MSS), it improves transmission efficiency rather than avoiding fragmentation during transmission.If fragmentation occurs during transmission, the path message transmission unit (Path MTU) discovery mechanism is used. A telematics service system characterized by reducing the maximum segment size (MSS) so that fragmentation does not occur. The method according to any one of claims 1 to 4, The interlocking means, Telematics service system characterized in that the congestion status is explicitly informed from the router (ECN: Explicit Congestion Notification) to reduce the data transmission rate as the congestion situation is expected in the network. The method according to any one of claims 1 to 4, The interfacing means, Means for providing application protocol interfaces (APIs) of the associated service system; And Means for providing XML-based loose coupling using the Simple Object Access Protocol (SOAP) Telematics service system comprising a. In the telematics service method, An interworking step of interworking a wired / wireless network independently of a mobile network without using a gateway inside the mobile network according to a service providing request from a telematics terminal; A telematics service providing step of providing a telematics service by interworking with the wired and wireless network; And Interworking with external systems that provide telematics services by interworking with external systems using an integrated interface provided in the form of a framework Telematics service method comprising a. The method of claim 11, The interworking step, In response to a service request from a telematics terminal, the wired / wireless network is interworked independently of the mobile network without using a gateway inside the mobile network. Telematics service method characterized in that the congestion control by simultaneously retransmitting lost packets without. The method of claim 12, Congestion control process according to packet loss, Transmitting to the sender an acknowledgment (ACK) number of a segment received last, a sequence number of a segment currently received, and a serial number of a segment to be transmitted next; Recognizing that a segment of an empty serial number is lost during transmission upon receiving a duplicate acknowledgment (ACK) at the transmitting side; And Transmitting the lost segment to the receiving side without reducing the transmission speed at the transmitting side; Telematics service method comprising a. The method according to any one of claims 11 to 13, The interworking step, Calculate the window size as Bandwidth * Delay, but set the minimum value of the Advertisement window on the receiving side and the congestion window on the sending side to the maximum available window size. Telematics service method. The method according to any one of claims 11 to 13, The interworking step, A method of providing a telematics service using a window scale option to allow a window size to be set above a preset value and determining a retransmission timeout time using a round trip time measurement (RTTM) function. The method according to any one of claims 11 to 13, The interworking step, By setting the default message transmission unit (MTU) value as the maximum segment size (MSS), it improves transmission efficiency rather than avoiding fragmentation during transmission.If fragmentation occurs during transmission, the path message transmission unit (Path MTU) discovery mechanism is used. Telematics service method characterized by reducing the maximum segment size (MSS) so that fragmentation does not occur. The method according to any one of claims 11 to 13, The interworking step, A method of telematics service, characterized by reducing a data transmission rate by an explicit congestion notification (ECN) from a router as a congestion situation is expected in a network.

Images