WO2015186884A1 - Common traffic information providing method and apparatus therefor - Google Patents

Abstract

The present invention relates to a method and apparatus for acquiring traffic information and, more particularly, to a method comprising the steps of: acquiring path information from a server; receiving at least one notification message indicating an update of common traffic information from the server; and when a particular condition is satisfied, acquiring common traffic information that has been updated, wherein the path information includes time information to acquire the common traffic information, and the notification message includes update start point information indicating a start point of a section having the updated common traffic information provided therein and update end point information indicating an end point of a section having the updated common traffic information provided therein, and an apparatus therefor.

Description

Method for providing common traffic information and apparatus therefor

The present invention relates to a method for providing traffic information and an apparatus therefor, and more particularly, to a method and an apparatus for providing the common traffic information efficiently.

Conventionally, a navigation terminal uses a method of detecting a current location, that is, a starting point, and receiving a destination of a travel from a user through a connection with a global positioning system (GPS) to calculate a route in the terminal itself. However, with the recent spread of smartphones and improved performance, service methods that provide route information, route-related real-time traffic information and various information from servers that provide traffic information and route information using PNDs (Personal Navigation Devices) in mobile networks are utilized. It is becoming.

In particular, while various types of navigation services are provided, the Open Mobile Alliance (OMA) standardization organization delivers TPEG (Traffic Protocol Expert Group) information in a digital multimedia broadcasting (DMB) network in which information is provided in a conventional broadcasting format. Rather, it is standardizing a dynamic navigation enabler (DynNav) that delivers real-time traffic information to peer-to-peer (P2P) through a mobile communication network or an Internet Protocol (IP) -based network.

An object of the present invention to provide a method and apparatus for transmitting and receiving a signal efficiently in a navigation system.

Another object of the present invention is to provide a method for efficiently providing traffic information to terminals passing through the same section and an apparatus therefor.

Another object of the present invention is to provide a method for efficiently transmitting and receiving updated traffic information and an apparatus therefor.

Technical problems to be achieved in the present invention are not limited to the above technical problems, and other technical problems that are not mentioned will be clearly understood by those skilled in the art from the following description.

In one aspect of the present invention, there is provided a method of obtaining traffic information from a server in a navigation device, the method comprising: obtaining route information from the server; Receiving at least one notification message indicating update of common traffic information from the server; And acquiring updated common traffic information when a specific condition is satisfied, wherein the route information includes time information for obtaining the common traffic information, and the notification message is provided by the updated common traffic information. Update start point information indicating a start point of a section to be updated and update end point information indicating an end point of a section in which the updated common traffic information is provided, wherein the specific condition includes (a) the navigation device providing the update start point information and the information; It may include that it has not yet passed the interval indicated by the update endpoint information, and (b) the current time has become the time indicated by the time information.

In another aspect of the present invention, there is provided a navigation device configured to obtain traffic information, the navigation device comprising a network interface unit (NIU); And a processor coupled to the NIU during operation, the processor obtaining route information from a server through the NIU, and receiving at least one notification message instructing to update common traffic information from the server through the NIU. And when the specific condition is satisfied, the updated common traffic information is obtained through the NIU, wherein the route information includes time information for obtaining the common traffic information, and the notification message includes the updated common traffic information. Update start point information indicating a start point of a section in which information is provided, and update end point information indicating an end point of a section in which the updated common traffic information is provided, wherein the specific condition includes (a) the navigation device providing the update start point; A phrase indicated by the information and the update endpoint information As a not yet passed, (b) it may include the current time is the time at which the time information indicates.

Preferably, the route information may include information indicating the number of common traffic information provided in the route information, information indicating an index of the first segment of a section in which the common traffic information is provided in the route information, and the route information. The apparatus may further include at least one of information indicating an index of the last segment of the section in which the common traffic information is provided and link information about the updated common traffic information.

Preferably, the common traffic information is stored in the server, and the notification message may be generated when the common traffic information is updated and transmitted to the navigation device.

Advantageously, the method further comprises receiving segment information from said server comprising indication information indicating whether performance information describing a traffic condition of a particular section is provided by said common traffic information; If the indication information indicates that the performance information is provided by the common traffic information, the performance information is included in the common traffic information and the performance information is omitted from the segment information, and the performance information is added to the common traffic information. If the indication information indicates that the information is not provided, the performance information may be included in the segment information.

Advantageously, said processor is further configured to receive segment information from said server including indication information indicating whether or not performance information describing a traffic condition of a particular section is provided by said common traffic information via said NIU. When the indication information indicates that the performance information is provided by the common traffic information, the performance information is included in the common traffic information, and the indication information indicates that the performance information is not provided by the common traffic information. If indicated, the performance information may be omitted from the segment information.

Preferably, when the time information is set to a specific value, the time information may instruct the navigation device to immediately obtain the updated common traffic information.

Preferably, the notification message further includes link information for the updated common traffic information, wherein the updated common traffic information may be obtained based on the link information.

Preferably, when two or more notification messages for the same section are received, acquiring the updated common traffic information may include obtaining the most recently updated common traffic information.

Preferably, the common traffic information may indicate traffic information related to a section common to a specific user group.

The above technical solutions are only some of the embodiments of the present invention, and various embodiments reflecting the technical features of the present invention are based on the detailed description of the present invention described below by those skilled in the art. Can be derived and understood.

According to the present invention, a signal can be efficiently transmitted and received in a navigation system.

In addition, according to the present invention, it is possible to efficiently provide common traffic information to terminals passing through the same section.

In addition, according to the present invention, it is possible to efficiently transmit and receive the updated common traffic information.

The effects obtainable in the present invention are not limited to the above-mentioned effects, and other effects not mentioned above may be clearly understood by those skilled in the art from the following description. will be.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are included as part of the detailed description in order to provide a thorough understanding of the present invention, provide an embodiment of the present invention and together with the description, illustrate the technical idea of the present invention.

1 illustrates a navigation device.

2 is a flowchart illustrating an operation of a smart ND.

3 is a flowchart illustrating the operation of a light weight ND.

4 is a network diagram for explaining the overall IP-based DynNav system.

5 shows a hierarchical structure of TPEG.

6 illustrates an example in which common traffic information is provided.

7 illustrates a flowchart of a method for providing common traffic information in accordance with the present invention.

8 illustrates a block diagram of an apparatus to which the present invention can be applied.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. The detailed description, which will be given below with reference to the accompanying drawings, is intended to explain exemplary embodiments of the present invention and is not intended to represent the only embodiments in which the present invention may be practiced. The following detailed description includes specific details in order to provide a thorough understanding of the present invention. However, one of ordinary skill in the art appreciates that the present invention may be practiced without these specific details.

In some instances, well-known structures and devices may be omitted or shown in block diagram form centering on the core functions of the structures and devices in order to avoid obscuring the concepts of the present invention. In addition, the same components will be described with the same reference numerals throughout the present specification.

On the other hand, it is intended to define the terms used in the present specification.

Application

Application herein refers to the implementation of a set of well-defined but not standardized functions that perform tasks on behalf of a user. An application of a well-defined but not standardized set of functions that performs work on behalf of the user.It may consist of software and / or hardware elements and associated user interfaces.).

Server

In general, in the technical field to which the present invention pertains, a server corresponds to an entity that provides resources to clients in response to requests (An entity that provides resources to Clients in response to requests.).

Client

Generally, in the technical field to which the present invention belongs, a client is a device, user agent, or other entity that acts as a receiver of a service (A device, user agent, or other entity that acts as the receiver of a service.)

DynNav Application

In the present specification, DynNav corresponds to an entity that is responsible for interacting with the DynNav server to obtain optimal route (s), real-time and future traffic information and auxiliary data. a DynNav Server to get optimal route (s), real-time and forecasted traffic information and complimentary data.). Therefore, the DynNav application is mounted on a terminal including a smartphone, a mobile phone, a navigation device, and the like, and accordingly, the DynNav application may be referred to interchangeably with the terminal. In this respect, the DynNav application is a kind of client.

DynNav Server

In this specification, the DynNav server corresponds to an entity that is responsible for providing optimal route (s), real-time and future traffic information and auxiliary data to the application. (An entity that is in charge of providing to the application optimal route (s), real-time and forecasted traffic information, and complimentary data.). In this respect, the DynNav server corresponds to a type of the server.

Location URI

In this specification, a location URI corresponds to a URI that allows a current location of a device to be obtained from a specific location server using a protocol for obtaining a location. using a particular dereferencing protocol.).

Navigation Device (ND)

In the present specification, a navigation device corresponds to an entity that assists a driver to show a correct route to reach a final destination using a Global Navigation Satellite System (GNSS) service. This entity can process real-time and predicted traffic information according to user preferences and dynamically estimate the optimal route (An entity that, using Global Navigation Satellite System (GNSS) service, assists the driver showing correct route to reach the final destination.This entity may process real-time and predicted traffic information and dynamically estimates the optimal route, according to user preferences.)

Lightweight ND

As used herein, lightweight ND means a navigation device that does not have a function for route calculation and requests and receives a route calculated from a server and, if a local map database is not available, for route prediction functions and road shape. A navigation device that accesses to a server for route estimation functionalities and for retrieving roads shape representation, if not available in a local map database.

Smart ND

In the present specification, a smart ND corresponds to a navigation device that can calculate route (s) using a road network database available on the device itself (using a roads). network database available on the device itself.).

Point Of Interest (POI)

In this specification, points of interest describe information about locations such as name, category, unique identifier, or city address (POI describes information about locations such as name, category, unique identifier, or civic address.).

Segment

As a unit to classify roads, in general roads, a continuous road between intersections and intersections is called a segment, and on highways, roads are defined as segments by dividing the roads according to the policy of each highway. In such a segment unit, traffic congestion or passing time may be determined. In this specification, segments are used interchangeably with road segments.

Segment Sequence

Refers to a collection of one or more consecutive segments. If necessary, a segment sequence composed of one segment is also possible. Also, for example, a segment sequence consisting of two or more segments has the end point of the first segment equal to the start point of the second segment.

Polyline

In the present specification, a polyline corresponds to a continuous line used in graphic computing composed of one or more line segments defined by specifying end points of each segment. , defined by specifying the endpoints of each segment).

Route Information

In this specification, the route information corresponds to information about coordinates of segment end points and complimentary data from the defined origin and the destination.

Traffic Information

In this specification, traffic information corresponds to information composed of traffic events and network performance parameters related to an area or a route. In addition, the traffic information may include current or future traffic information, that is, future traffic information.

Traffic Event

In the present specification, a traffic event refers to events related to an area or route imposed or planned by a road network operator (ie road constructions causing road closure) or events occurring outside the control of the network operator (ie accidents). Information regarding events related to an area or a route that are either imposed or planned by the road network operator (ie road works leading to lane closures) or events that occur outside the control of the network operator (ie accidents)).

Network Performance Parameter

In this specification, the network performance parameter corresponds to information regarding the performance or traffic flow (ie, speed, delay and travel time) of each segment present in the area or path (ie information regarding the performances (ie speed, delay and travel time). ) of road segments related to an area or a route.).

Route Information in Full Format

Refers to a form of route information including all segments from a source to a destination. Unless otherwise stated, the path information means the entire path.

Route Information in Summarized Format

It refers to a form of route information that includes only segments selected for the summary of information among all segments from the source to the destination (the manner of selection is not covered in the present invention).

Recently, with the proliferation of smart phones, a navigation service providing a mobile route to a mobile communication terminal has been widely used away from the conventional DMB broadcasting network. In the OMA LOC WG, such a service is called DynNav (Dynamic Navigation).

In the present specification, the navigation device refers to a device capable of performing a route guidance function, and the navigation device is attached to a portable or portable object such as a smartphone, a mobile phone, a mobile device, a laptop, a tablet PC, a smart pad, and the like. Include all possible electronic devices. The navigation apparatus may be referred to as a navigation device.

The standard for DynNav includes two types of navigation devices and services. First, a complex route calculation is not performed by a navigation application mounted on a smartphone, but is performed by a server providing traffic information and route information, and a corresponding route is transmitted to the smartphone. Second, due to the performance improvement of the smartphone, the route calculation is performed by the application itself mounted on the smartphone or when the navigation terminal equipped with the mobile modem is performing the route calculation, and the server providing the traffic information is transmitted. Instead, when the terminal registers the calculated route to the server, only the real-time traffic information related to the route can be personally provided from the server in IP-based P2P, not in the form of conventional broadcasting.

1 shows a division of a navigation device. The navigation device 110 additionally transmits TPEG-based traffic information transmitted through a broadcasting network such as DMB, 120 additionally transmits traffic information based on IP, such as a mobile communication network or Wi-Fi, and other communication. It can be classified into a standalone form 130 that generates and provides route information by tracking a vehicle's location through a GPS connection without a medium connection.

In addition, the DynNav currently being standardized in the OMA LOC WG belongs to the form 120 for delivering IP-based traffic information in the above classification, more specifically, belongs to the category for delivering in a P2P form, and in DynNav, a navigation device is as follows. It is divided into two.

1. Smart ND 122: A device that can calculate the route by itself and requests only real-time traffic information without receiving route information through the DynNav server.

2. Lightweight ND (121): A device that cannot calculate the route by itself and requests all real-time traffic information including route information through the DynNav server.

In the conventional DynNav system, since the process of requesting and transmitting the corresponding traffic information is delivered based on RESTful, the following route information format is used, and each information format can be defined as an XML Schema Definition (XSD).

1) Trip Structure: As the first terminal, the terminal acquires information such as origin and destination from the user, and transfers the information to the server. The trip structure consists of a subset corresponding to multiple path structures. Tables 1-3 illustrate the trip structure.

Table 1

TABLE 2

TABLE 3

2) Route Structure: The route structure is represented by several segments in a manner that represents the entire route calculated through the trip structure. Tables 4-5 illustrate the path structure.

Table 4

Table 5

3) Segment Structure: It is a structure that represents each segment, and can define not only the length of each segment but also the real-time traffic situation corresponding to the segment based on the expression of (TPEG). Table 6 illustrates the segment structure.

Table 6

4) Performance Parameter Structure: Represents information (or network performance information) about network performance parameters for a single load segment. The performance parameter structure may be included in segment information (eg, see Table 6). Table 7 illustrates the performance parameter structure. For convenience of description, the performance parameter structure may be referred to as performance information.

TABLE 7

2 is a flowchart illustrating the operation of a smart ND in the conventional DynNav system. Since the performance of the terminal itself supports the route calculation, the smart ND calculates its own route based on the trip information defined by the user and transmits the route to the server. Typical functions are as follows.

1. Smart ND calculates route based on trip information

2. Smart ND delivers the calculated route to the server, and the server delivers the real-time traffic of the route.

3. Smart ND subscribes service based on route delivered to receive real-time traffic notification service from server.

The general contents of the flowchart illustrated in FIG. 2 are as follows.

1. The user defines travel parameters and the application sends the parameters to the server. The server replies with the location of the created “trip” resource to the application.

a) The server may respond with a representation of the generated “trip” resource. In this use case behaviors are equivalent.

2. The application uploads the calculated route to resource / {tripId} / routes. The server may respond with a representation of a “route” resource, including links to performance parameters and traffic events.

a) The server may respond with traffic information (performance parameters and traffic events). In this case an additional get operation is needed to retrieve the contents of the resource.

3. The application subscribes to a notification service for trips and routes.

4. Changes in traffic events and / or performance parameters occur for the subscribed path (s); Notification resources are created.

5. The server delivers a notification resource to the application using links to the modified resources, including trips and routes, including updated performance parameters and traffic information.

6. The application accesses and reads the updated resources.

7. The application decides to calculate a new route using the received resource.

8. The application uploads the newly calculated route to resource / {tripId} / routes. The server responds with a representation of a "path" resource, including links to path capabilities and events. This step can be repeated several times until a path is found that satisfies the performance constraint.

9. The application requests to change the subscription setting to add a notification for the newly subscribed path.

3 is a flowchart illustrating the operation of a light weight ND in the conventional DynNav system. Lightweight NDs do not support route calculation because their capacity does not support route calculations, so they must request route information from the server and receive route information from the server. Typical functions are as follows.

-Lightweight ND transfers trip information to server for route calculation

The lightweight ND receives a set of paths (including recommended paths) calculated by the server from the server

A subscription to the lightweight ND to receive real-time traffic notification notifications from the server.

The general contents of the flowchart illustrated in FIG. 3 are as follows.

1. A user of an application defines travel parameters and the application sends the parameters to a server: the server uses a set of suggested routes based on the received parameters using the relevant traffic information. Calculate The server responds to the application with a created “trip” resource containing the path identifiers of the proposed routes.

2. The application accesses the set of paths in a summarized format. This step is repeated for all routes suggested by the server. However, if the length and complexity of the trip is limited or network quality is inadequate, full format path information may be used at this stage. The application may request this if shape information (WGS84 coordinate polyline) for the proposed paths is not available in the navigation device.

3. The user selects one path from the proposed set, and the application accesses full format information for the path selected by the user. The application may request this if shape information (WGS84 coordinate polyline) for the proposed paths is not available in the navigation device. If in step 2 the full format path is obtained, this step is not necessary. The server responds with the selected route information together with the relevant traffic information.

4. The application accesses traffic events associated with the route using links to the provided traffic event resources. Access to the traffic events may be restricted to categories selected by the user.

5. The application removes unnecessary paths previously proposed by the server but not selected by the user.

6. The application requests the server to create a subscription to the notification service for the trip (path (s)). The application is notified by the server about the following events:

a. Update performance parameters for all routes related to the trip and new traffic events (for selected categories)

b. Proposal of alternative routes due to traffic problems depending on the routes to be used

c. Updated destination and / or route to the third party if the destination of the trip is a third party's location and the third party's location has changed. In order to enable notification of this information, the application must request a tracking procedure of the third party's location by the server in the subscription of the notification.

7. Departure or bypass the path the vehicle is using (on which the application is mounted); The application modifies the source parameter of the trip resource. The server recognizes that the current location does not belong to the route being used and calculates a new route using the new origin. The server responds with an identifier of the new route and deletes the old route (and identifier). If the modified origin parameter belongs to the previous route, the server uses this information to delete the segment already traveled from the route.

Step 7 may be performed if the vehicle has been detoured or departed from the route and if the vehicle has moved a certain distance from a previously reported point and / or if the vehicle has entered a segment that the server has requested to upload the current location. Occurs.

8. The server delivers a notification resource to the application using links to modified resources, including trips and routes, including the updated traffic information (traffic events and performance parameters).

8. The application accesses the new proposed route along with performance parameters and traffic events. Since the application subscribed to the notification service for the trip resource, the subscription will cover the new proposal path.

9. If traffic events, severe congestion, and / or location change of the third party on the proposed routes are detected by the server, the server informs using a Uniform Resource Locator (URL) of updated information.

10. The notification accesses update information for the route being used, new related traffic events and the proposed alternative route, and the notification is included because the subscription of the notification service includes all routes associated with the trip. It extends to the proposed alternative route. If the third party's location has changed, the application accesses the changed third party's location and / or the updated route resource as a destination.

4 is a network diagram illustrating an overall IP-based DynNav system, which is a navigation system of the present invention. As shown in FIG. 4, the navigation system of the present invention is a navigation device (ND) capable of accessing a mobile communication network, a mobile communication network for wireless transmission and reception, a traffic information collection device, traffic information, and a route to provide traffic information. It may include a information server (DynNav Server) and a location server for generating and delivering assistance data (Assistance Data) for obtaining the location of the navigation device.

For the sake of simplicity, the traffic information providing server or the DynNav server is referred to herein as a "server", and the navigation device is a "terminal", "ND" or "Smart ND" or "Lightweight ND according to the capability of each terminal. ”.

In the present invention, the terminal (which can be divided into two terminal types as mentioned above) can be connected to an IP network such as a mobile communication network or Wi-Fi as shown in the drawing, and has a navigation application for route guidance. The application may connect to a server and receive route guidance data and real-time traffic information to guide the route. Meanwhile, although not separately illustrated in the drawing, the terminal capable of calculating the route itself may selectively receive only real-time traffic information without receiving route guidance data from the server.

Here, the real-time traffic information means additional information associated with traffic such as optimal route information, real-time and predicted traffic information, point of interest (POI) and weather calculated by the DynNav server and delivered to the terminal. In addition, a navigation application or a terminal is collectively referred to as a terminal to eliminate duplication of expression. Thus, in this specification, "terminal", "ND", "Smart ND", "Lightweight ND" and "navigation application" may all be referred to as "terminal".

The real-time traffic information mentioned above can be expressed through the Transport Protocol Experts Group (TPEG), which is being promoted by ISO standardization bodies. Here, TPEG means a standard protocol for transmitting traffic and travel information through a digital broadcasting network. As shown in FIG. 4, the hierarchical structure of the TPEG corresponds to the network layer (third layer) to the application layer (seventh layer) of the ISO / OSI Layer model. The network layer defines TPEG frame synchronization and routing. In the packetization layer of layers 4, 5 and 6, the components of each application are merged into one stream, and each message specification corresponds to the application layer 7 layer. . In DynNav, real-time traffic information may be provided to the terminal according to the real-time traffic information expression method of the TPEG, and a separate expression method may be used.

On the other hand, in DynNav, the DynNav server generates and provides traffic information to the DynNav application for the route (eg for Lightweight ND) or the route calculated by the DynNav application (eg for Smart ND). For example, the traffic information may include traffic event information (eg, Table 5, trafficeEvents) and network performance information (eg, see Table 7). Because DynNav provides DynNav applications with user-specific traffic information, the DynNav server must create and manage traffic-related resources for each DynNav application's route request. Therefore, as more DynNav applications request services from the DynNav server, more resources are generated and more resources in the DynNav server may be used.

Traffic information provides the same information for each DynNav application for the same section. Therefore, rather than generating the same information (resources) for each DynNav application for the same section, it is possible to reduce the resource usage of the DynNav server by generating only one information (resource) and allowing the required DynNav application to reuse it.

Accordingly, the present invention proposes a method for efficiently providing common traffic information to DynNav applications passing through the same section.

Common traffic information

In this specification, common traffic information refers to a common (path) section for a specific user group (eg, at least one navigation device). Thus, common traffic information is the opposite of user-specific traffic information. For example, the common traffic information may be provided to users who are in a route section common to a specific user group or users who are going to pass the route section.

6 illustrates an example in which common traffic information is provided. In FIG. 6, the paths of users A, B, and C are shown, and it is assumed that the users A, B, and C all pass a path of 1 to 2 sections.

As described above, the existing DynNav provides only user-specific traffic information. Therefore, in the example of FIG. 6, the DynNav server generates and provides traffic information for the route of 1 to 2 sections to the users A, B, and C, respectively. However, in the case of providing common traffic information according to the present invention, the DynNav server provides a user-specific traffic information as in the conventional route other than the section 610 for providing common traffic information to the user (eg, In the case of user A, a common traffic information section may be provided to a plurality of users (eg, A, B, and C) by generating a single resource. In this specification, the common traffic information section refers to a section in which common traffic information is provided (eg, 610). In this way, the method of providing common traffic information may be more effective when applied to a route section such as a highway having a long route length and a few intersections, rather than a general road having a short route length.

The common traffic information may include traffic event information (eg, trafficEvents) and network performance information (eg, see Table 7) of a route section where common traffic information is provided. The common traffic information may be delivered to the user who is in the common traffic information section or the user who passes the corresponding section. Since the common traffic information includes current traffic information, the DynNav server updates the common traffic information at specific time periods to maintain the real-time quality of the common traffic information, or in case of sudden accident or traffic flow suddenly becomes worse. Update traffic information and notify the user.

7 illustrates a flowchart of a method for providing common traffic information in accordance with the present invention. In the example of FIG. 7, although described based on the Lightweight ND, the same / similarity may be applied to the smart ND. In addition, although each step of FIG. 7 is described in terms of the DynNav application or the DynNav server, a corresponding operation may be executed in the DynNav server or the DynNav application. In addition, in this specification, a notification may be used in the same sense as a notification message.

Referring to FIG. 7, in step S702, the DynNav application 710 may receive (or obtain) route information from the DynNav server 720. As described above, the route information may include at least one of the information illustrated in Tables 4 and 5, for example. Alternatively or additionally, according to the present invention, the route information may include information for providing common traffic information. For example, the route information according to the present invention may include at least one of the following information separately or additionally to the information illustrated in Tables 4 and 5.

Information indicating the number of common traffic information provided in the route information (eg numCommonTrafficInfo). When the information indicates 0, this may mean that common traffic information is not provided. When the information indicates a value greater than 0, it may mean that common traffic information is provided. Therefore, the DynNav server 720 may indicate whether common traffic information is provided to the DynNav application 710 based on the information.

Information indicating an index of the first segment of a section where common traffic information is provided (eg, firstComTrafficSegment)

Information indicating an index of the last segment of the section where common traffic information is provided (eg, lastComTrafficSegment);

In addition, as illustrated in Table 5, the route information provides link information (eg, a link element) indicating a route resource including the traffic information. As illustrated in Table 5, the existing route information selectively supports up to two link information, whereas there may be many sections in which common traffic information is provided depending on the situation. Therefore, at least two link information for resources for common traffic information need to be supported to support common traffic information. In the present invention, it is proposed to extend the number of link information supported in the path information to two or more. Link information about two or more common traffic information (or resources for common traffic information) included in the route information may be provided sequentially. For example, the link information may be provided as address information (eg, a Uniform Resource Locator (URL)) and the address information may be specified by the DynNav server 720. The DynNav application 710 may obtain common traffic information through address information (eg, a URL) designated by the DynNav server 720. In the present specification, the link information and the address information may be mixed with each other.

Therefore, the route information provided to the DynNav application 710 in step S702 includes indication information (eg, numCommonTrafficInfo) indicating whether common traffic information is provided and address information (or link information) for obtaining common traffic information ( Yes, URL).

Table 8 illustrates the information added / modified in the route information illustrated in Tables 4 and 5 to provide common route information.

Table 8

In operation S702, the DynNav server 720 may provide traffic information to the DynNav application 710. For example, the traffic information may include traffic event information (eg, trafficEvents) and network performance information (eg, see Table 7).

For example, in the case of the lightweight ND, step S702 may be performed in step 3 of FIG. 3.

In operation S704, the DynNav application 710 may acquire common traffic information according to the information obtained in operation S702. For example, when the information obtained in step S702 indicates that common traffic information is provided, the DynNav application 710 may access common traffic information through address information (eg, a URL) designated by the DynNav server 720. Can be. Accessing the DynNav application to common traffic information may mean that the DynNav application connects to the DynNav server to receive (or obtain) common traffic information.

For example, in the case of the light weight ND, step S704 may be performed in step 4 of FIG. 3.

In operation S706, common traffic information may be changed. For example, the common traffic information may be updated every specific period to maintain the real time of the traffic information, or the common traffic information may be changed when the situation of the common traffic information section changes with time. In this case, a notification event may occur, and a notification message for notifying the occurrence of an event may be generated when the notification event occurs. In addition, the common traffic information is updated by the DynNav server 720.

In operation S708, the DynNav application 710 may receive (or obtain) at least one notification message instructing to update common traffic information from the DynNav server 720. For example, the notification message received in step S708 may be a notification message generated in step S706. For example, for the lightweight ND, step S708 may be performed in step 9 of FIG. 3.

In operation S710, the DynNav application 710 may receive (or obtain) updated common traffic information by using the address information (eg, URL) that has already been obtained in operation S702. For example, in the case of the light weight ND, step S704 may be performed in step 10 of FIG. 3.

Common traffic information according to the present invention may include the following information. ISO TS 24530-2 and 24530-3 are incorporated herein by reference in their entirety. The common traffic information may represent real time traffic information associated with a specific route section.

Start point information (eg, originPoint): indicates the start of a section where common traffic information is provided and may be encoded according to a Location_Point structure defined in ISO TS 24530-2.

Endpoint information (eg, endPoint): indicates the end of a section in which common traffic information is provided and may be encoded according to a Location_Point structure defined in ISO TS 24530-2.

-Midpoint information (eg midwayPoint): used to uniquely identify a section in which common traffic information is provided, and may be encoded according to a Location_Point structure defined in ISO TS 24530-2.

Time (eg, time): indicates a reference time of a validity interval for common traffic information.

Delay (e.g., delay): This indicates an estimated delay value in a section in which common traffic information is provided and is expressed in minutes with respect to a regular traveling time. The estimated delay value may be real time information or may be a predicted value. General travel time can be obtained from segment information (eg regularTravellingTime in Table 6).

Speed (eg, speed): This indicates an estimated speed in a section in which common traffic information is provided and may be expressed as a second speed (eg, meter per second). The estimated speed may be real time information or may be a predicted value.

Performance (e.g., performance): indicates traffic conditions in a section in which common traffic information is provided, and may be encoded according to the RTM34 table definition of ISO TS 24530-3. This value may be real-time information or may be a predicted value.

Table 9 illustrates the structure of common traffic information according to the present invention.

Table 9

As described above, the common traffic information according to the present invention may include performance information (eg, performance element). In this specification, the performance information may refer to information describing a traffic condition of a specific road segment or route section. In this case, since performance information (eg, performance element) included in the common traffic information may overlap with network performance information (eg, performanceParameter) illustrated in Tables 6 and 7, signaling overhead may occur and burden on the network. Can give Accordingly, as an embodiment of the present invention, indication information (eg, comTrafficInfo) indicating whether network performance is included in common traffic information or segment information (eg, performanceParameter of Table 6) may be set. The indication information (eg comTrafficInfo) may be included as one element in segment information (eg, Table 6). For example, if the indication information (eg comTrafficInfo) has a specific value (eg TRUE), the network performance for the common traffic information section is provided by the common traffic information, and the network performance information (eg, Table 6 and Tables). 7 performanceParameter) is not provided. Alternatively, if the indication information (eg, comTrafficInfo) has a specific value (eg, FALSE), network performance for the common traffic information section is provided by segment information (eg, performance parameter of Table 6). As another example, the indication information (eg, comTrafficInfo) may be included in an information structure other than segment information. Table 10 illustrates indication information (eg, comTrafficInfo) indicating whether network performance is provided by common traffic information.

Table 10

How to Reduce Notification Messages (Method 1)

A resource of common traffic information stores current traffic information. Therefore, after a certain time, the DynNav server needs to update the traffic information stored in the resource of common traffic information to provide the traffic information for that time. Since the common traffic information is provided to a plurality of users, when the traffic information is updated, it is necessary to send a notification (or a notification message) to notify all users using the common traffic information of the update. This can cause a large amount of network usage on the DynNav server at any given time.

Accordingly, the present invention proposes a method of reducing a notification (or a notification message) that a DynNav server sends to a DynNav application. More specifically, when the common traffic information is updated over time, a method of reducing a notification (or a notification message) that the DynNav server sends to the DynNav application is proposed.

The common traffic information indicates current traffic information of the corresponding section. For this reason, traffic information is updated after a certain time in order to maintain real-time traffic information. The DynNav server already knows when the traffic information for that segment is updated. In addition, the DynNav server may determine when the DynNav application passes a section in which common traffic information is provided, based on the path information of the DynNav application.

Therefore, in the present invention, when the DynNav server provides common traffic information to the DynNav application, it is proposed that the DynNav application notifies when to access and acquire the common traffic information. For example, when the DynNav server provides one or more common traffic information to the DynNav application, the DynNav server adds time information (e.g. comTrafficRetrievalTime) when the DynNav application will access and obtain each common traffic information. To provide. The DynNav application receiving the time information according to the present invention may receive the corresponding common traffic information at a designated time and reflect it on the route. Therefore, according to the present invention, not only the number of notification (or notification message) transmissions can be reduced, but also the waste of network resources can be reduced. In the present specification, time information according to the present invention may be referred to as common traffic retrieval time information (eg, comTrafficRetrievalTime).

The common traffic acquisition time information may be included in the route information (for example, see Table 4). When one or more pieces of common traffic information are provided, one or more pieces of common traffic acquisition time information indicating an acquisition time of each piece of common traffic information may be included in the route information. In addition, when the common traffic acquisition time information is set to '00: 00 ', it may mean that the DynNav application immediately acquires common traffic information. Alternatively, if the common traffic acquisition time information is not included in the route information, it may mean that the DynNav application immediately acquires common traffic information.

As an example, assume that the DynNav server provides three common traffic information when providing a route to the DynNav application. The DynNav server may provide link information (eg, a URL) capable of receiving respective common traffic information and common traffic acquisition time information for each common traffic information together with the route information. For example, if three pieces of common traffic acquisition time information are first (currently 12:00), secondly, 13:00, and thirdly 15:00, the DynNav application will first be able to Common traffic information may be obtained by accessing an address indicated by link information (eg, a URL) of the traffic information. During the course of the route, at 13:00 o'clock the second link information (e.g. URL) is accessed to obtain the corresponding common traffic information, and at 15:00 o'clock the third link information (e.g. The common traffic information can be obtained by accessing the address indicated by the URL).

As another example, when the DynNav application receives a notification (or a notification message) and the time that the common traffic acquisition time information for the segment does not reach, the DynNav application is updated after the time indicated by the common traffic acquisition time information. Access to common traffic information. As another example, if the DynNav application does not reach the time indicated by the common traffic acquisition time information when it receives the notification (or notification message), the DynNav application is most recently after the time indicated by the common traffic acquisition time information. Only updated common traffic information can be accessed.

Table 11 illustrates common traffic acquisition time information in accordance with the present invention. Common traffic acquisition time information according to the present invention may be added to route information (eg, Table 4 or Table 5).

Table 11

Method 1 described above may be applied to the methods illustrated in FIGS. 2, 3, and / or 7. For example, the common traffic acquisition time information according to the present invention may be included in route information provided to the DynNav application 710 in S702. The DynNav application 710 may acquire common traffic information or updated common traffic information based on common traffic acquisition time information according to the method 1 described above in step S704 or S710. As another example, in the case of the smart ND, in step 2 of FIG. 2, the application 210 may post the route information to the server 220, and the server 220 generates a route resource and then obtains common traffic according to the present invention. Time information can be set in the generated route resource. The application 210 may obtain common traffic acquisition time information by obtaining route information set in the route resource.

How to reduce the number of server accesses (Method 2)

As described above, the common traffic information may be updated to maintain real time after a certain time, or may be updated when an accident or the like occurs in a corresponding section or when the traffic situation suddenly worsens. When the common traffic information is updated, the DynNav server sends a notification (or a notification message) to the DynNav application to receive the updated common traffic information for the section.

Meanwhile, the notification (or notification message) includes link information (eg, Link) that can receive updated common traffic information. However, since the notification (or notification message) does not include information indicating which section the updated common traffic information is for the common traffic information, the DynNav application receives the updated common traffic information even when the notification (or notification message) is received. Does not know which section is the common traffic information. Therefore, the DynNav application may access the corresponding common traffic information using the received link information to obtain data, and then confirm that the common traffic information is common traffic information of a section. If the DynNav application has already passed the common traffic information section, or is a section to be advanced later, the obtained traffic information may be meaningless and may be discarded. Thus, the DynNav application may waste network resources to obtain meaningless information. In this situation, when the DynNav server sends a notification (or a notification message) indicating that there is updated common traffic information, information for notifying which section of the common traffic information has update information may be added to reduce network resource usage. .

Accordingly, in the present invention, the information indicating the start point of the section in which the update of the common traffic information occurred (for example, comTrafficOrigin) and / or the information indicating the end point of the section in which the update of the common traffic information occurred (for example, comTrafficEndPoint) is notified (or Suggest a message in the notification message). The DynNav application may determine whether to access the DynNav server to obtain updated common traffic information based on the information indicating the start point (eg comTrafficOrigin) and / or the information indicating the end point (eg comTrafficEndPoint). have. For convenience of description, information indicating the start point (eg, comTrafficOrigin) is referred to as update start point information, and information indicating the end point (eg, comTrafficEndPoint) is referred to as update end point information. For example, if the DynNav application has already passed the section indicated by the update start point information (eg comTrafficOrigin) and the update end information (eg comTrafficEndPoint), the DynNav application may ignore the updated common traffic information. As another example, if the DynNav application passes through or is going to pass the segment indicated by the update start point information (eg comTrafficOrigin) and the update end information (eg comTrafficEndPoint), the DynNav application may obtain updated common traffic information. have.

The update start point information and the update end point information according to the present invention may be included in, for example, a notification (or a notification message) received by the DynNav application in step S708 of FIG. 7. Table 12 illustrates the structure of a notification (or notification message) according to the present invention. In the example of Table 12, the notification (or notification message) may include link information (eg, link), and the DynNav application obtains updated common traffic information using the address information (eg, URL) specified in the link information. can do.

Table 12

Method 2 described above may be applied to the methods illustrated in FIGS. 2, 3, and / or 7. For example, the update start point information (eg comTrafficOrigin) and the update end point information (eg comTrafficEndPoint) according to the present invention may be included in the notification message received by the DynNav application 710 in step S708. The DynNav application 710 may acquire common traffic information based on the updated common traffic acquisition time information according to the method 2 described above in operation S710.

Method 1 and method 2 described above can be implemented in combination. The DynNav application may operate based on both update start point information (eg, comTrafficOrigin), update endpoint information (eg, comTrafficEndPoint), and common traffic acquisition time information (eg, comTrafficRetrievalTime) according to the present invention. For example, when the DynNav application receives a notification (or a notification message), it can access the updated common traffic information if a specific condition is satisfied. Specific conditions may include the following conditions.

The DynNav application has not already passed the interval indicated by the update start point information and the update end point information indicated by the notification (or a notification message).

The current time should be the time indicated by the common traffic acquisition time information (eg comTrafficRetrievalTime).

If a plurality of notifications (or notification messages) are received before the time indicated by the common traffic acquisition time information (e.g. comTrafficRetrievalTime), the DynNav application will only access the most recently updated common traffic information if the specified conditions are met. Can be. Access to the common traffic information by the DynNav application may mean that the DynNav application connects to the DynNav server to obtain common traffic information.

As another example, if the DynNav application has already passed the period indicated by the update start point information and the update end point information, the received notification (or notification message) may be ignored. Thus, even after the current time reaches a time indicated by the common traffic acquisition time information (eg, comTrafficRetrievalTime), the DynNav application may not access the updated common traffic information.

8 illustrates a block diagram of an apparatus to which the present invention can be applied. In the present invention, the DynNav application and the DynNav server may operate as the transmitter 10 or the receiver 20, respectively.

The transmitter 10 and the receiver 20 are radio frequency (RF) units 13 and 23 capable of transmitting or receiving radio signals carrying information and / or data, signals, messages, and the like, and in a wireless communication system. It is operatively connected with components such as the memory (12, 22), the RF unit (13, 23) and the memory (12, 22) for storing a variety of information related to communication, by controlling the component The apparatus comprises processors 11 and 21, respectively, configured to control the memory 12 and 22 and / or the RF units 13 and 23 to perform at least one of the embodiments of the invention described above.

The memories 12 and 22 may store programs for processing and control of the processors 11 and 21, and may store information input / output. The memories 12 and 22 may be utilized as buffers. In addition, the memories 12 and 22 may be used to store resources including various setting information and data.

The processors 11 and 21 typically control the overall operation of the various modules in the transmitter or receiver. In particular, the processors 11 and 21 may perform various control functions for carrying out the present invention. The processors 11 and 21 may also be called controllers, microcontrollers, microprocessors, microcomputers, or the like. The processors 11 and 21 may be implemented by hardware or firmware, software, or a combination thereof. When implementing the present invention using hardware, application specific integrated circuits (ASICs) or digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays) may be provided in the processors 11 and 21. Meanwhile, when implementing the present invention using firmware or software, the firmware or software may be configured to include a module, a procedure, or a function for performing the functions or operations of the present invention, and configured to perform the present invention. The firmware or software may be provided in the processors 11 and 21 or stored in the memory 12 and 22 to be driven by the processors 11 and 21.

The processor 11 of the transmission apparatus 10 is predetermined from the processor 11 or a scheduler connected to the processor 11 and has a predetermined encoding and modulation on a signal and / or data to be transmitted to the outside. After performing the transmission to the RF unit 13. The signal processing of the receiver 20 is the reverse of the signal processing of the transmitter 10. Under the control of the processor 21, the RF unit 23 of the receiving device 20 receives a radio signal transmitted by the transmitting device 10. The processor 21 may decode and demodulate a radio signal received through a reception antenna to restore data originally transmitted by the transmission apparatus 10.

The RF units 13, 23 have one or more antennas. The antenna transmits a signal processed by the RF units 13 and 23 to the outside under the control of the processors 11 and 21, or receives a radio signal from the outside to receive the RF unit 13. , 23). In FIG. 8, although the transmitter and the receiver are respectively communicated through the RF unit, it is also possible for the transmitter and the receiver to communicate through a wired network. In this case, the RF unit may be replaced with a network interface unit (NIU).

The embodiments described above are the components and features of the present invention are combined in a predetermined form. Each component or feature is to be considered optional unless stated otherwise. Each component or feature may be embodied in a form that is not combined with other components or features. It is also possible to combine some of the components and / or features to form an embodiment of the invention. The order of the operations described in the embodiments of the present invention may be changed. Some components or features of one embodiment may be included in another embodiment or may be replaced with corresponding components or features of another embodiment. It is obvious that the claims may be combined to form an embodiment by combining claims that do not have an explicit citation relationship in the claims or as new claims by post-application correction.

Certain operations described in this document as being performed by the server may in some cases be performed by their upper nodes. That is, it is obvious that various operations performed for communication with the terminal in a network including a plurality of network nodes including a server may be performed by the server or other network nodes other than the server. The server may be replaced by terms such as a fixed station, a Node B, an eNode B (eNB), an access point, and the like. In addition, the terminal may be replaced with terms such as a user equipment (UE), a mobile station (MS), a mobile subscriber station (MSS), and the like.

Embodiments according to the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof. In the case of a hardware implementation, an embodiment of the present invention may include one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, and the like.

In the case of an implementation by firmware or software, the present invention may be implemented by software code or instructions including a form of a module, procedure, function, etc. that performs the functions or operations described above. The software code or instructions may be stored in a computer readable medium and driven by the processor and may perform operations according to the present invention when driven by the processor. The computer readable medium may be located inside or outside the processor or remotely connected to the processor through a network, and may exchange data with the processor.

It will be apparent to those skilled in the art that the present invention may be embodied in other specific forms without departing from the spirit of the invention. Accordingly, the above detailed description should not be construed as limiting in all aspects and should be considered as illustrative. The scope of the invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the invention are included in the scope of the invention.

The invention can be used in a navigation device or server.

Claims (15)

1. In the method for obtaining traffic information from a server in the navigation device,

   Obtaining route information from the server;

   Receiving at least one notification message indicating update of common traffic information from the server; And

   If the specific conditions are met, obtaining the updated common traffic information,

   The route information includes time information for obtaining the common traffic information.

   The notification message includes update start point information indicating a start point of a section in which the updated common traffic information is provided and update end point information indicating an end point of a section in which the updated common traffic information is provided,

   The above specific conditions

   (a) the navigation device has not yet passed the interval indicated by the update start point information and the update end point information,

   (b) the current time is the time indicated by the time information

   Including, method.
2. The method of claim 1,

   The route information includes information indicating the number of common traffic information provided in the route information, information indicating an index of the first segment of a section in which the common traffic information is provided in the route information, and common traffic information in the route information. And at least one of information indicating an index of the last segment of the provided section and link information for the updated common traffic information.
3. The method of claim 1,

   The common traffic information is stored in the server, and the notification message is generated when the common traffic information is updated and sent to the navigation device.
4. The method of claim 1,

   Receiving segment information from the server, the segment information including indication information indicating whether performance information describing a traffic condition of a specific section is provided by the common traffic information;

   If the indication information indicates that the performance information is provided by the common traffic information, the performance information is included in the common traffic information and the performance information is omitted from the segment information,

   If the indication information indicates that the performance information is not provided by the common traffic information, the performance information is included in the segment information.
5. The method of claim 1,

   If the time information is set to a specific value, the time information instructs the navigation device to immediately obtain the updated common traffic information.
6. The method of claim 1,

   The notification message further includes link information for the updated common traffic information, wherein the updated common traffic information is obtained based on the link information.
7. The method of claim 1,

   If more than one notification message for the same section is received, obtaining the updated common traffic information comprises obtaining the most recently updated common traffic information.
8. The method of claim 1,

   The common traffic information indicates traffic information related to a section common to a particular user group.
9. A navigation device configured to obtain traffic information, the navigation device comprising:

   The navigation device is

   A network interface unit (NIU); And

   A processor coupled to the NIU in operation, wherein the processor

   Obtaining route information from the server through the NIU,

   Receive at least one notification message instructing to update common traffic information from the server via the NIU,

   If the specific condition is satisfied, the updated common traffic information is configured through the NIU,

   The route information includes time information for obtaining the common traffic information.

   The notification message includes update start point information indicating a start point of a section in which the updated common traffic information is provided and update end point information indicating an end point of a section in which the updated common traffic information is provided,

   The above specific conditions

   (a) the navigation device has not yet passed the interval indicated by the update start point information and the update end point information,

   (b) the current time is the time indicated by the time information

   Including, a navigation device.
10. The method of claim 9,

    The route information includes information indicating the number of common traffic information provided in the route information, information indicating an index of the first segment of a section in which the common traffic information is provided in the route information, and common traffic information in the route information. And at least one of information indicating an index of the last segment of the provided section, and link information about the updated common traffic information.
11. The method of claim 9,

    The common traffic information is stored in the server, and the notification message is generated when the common traffic information is updated and transmitted to the navigation device.
12. The method of claim 9,

    The processor is further configured to receive segment information from the server including indication information indicating whether performance information describing a traffic condition of a specific section is provided by the common traffic information through the NIU,

    If the indication information indicates that the performance information is provided by the common traffic information, the performance information is included in the common traffic information and the performance information is omitted from the segment information,

    If the indication information indicates that the performance information is not provided by the common traffic information, the performance information is included in the segment information.
13. The method of claim 9,

    If the time information is set to a specific value, the time information instructs the navigation device to immediately obtain the updated common traffic information.
14. The method of claim 9,

    The notification message further includes link information for the updated common traffic information, wherein the updated common traffic information is obtained based on the link information.
15. The method of claim 9,

    And when more than one notification message for the same section is received, acquiring the updated common traffic information comprises acquiring the most recently updated common traffic information.

Images