WO2015186884A1 - Procédé pour obtenir des informations courantes sur le trafic et appareil associé - Google Patents

Procédé pour obtenir des informations courantes sur le trafic et appareil associé Download PDF

Info

Publication number
WO2015186884A1
WO2015186884A1 PCT/KR2014/012738 KR2014012738W WO2015186884A1 WO 2015186884 A1 WO2015186884 A1 WO 2015186884A1 KR 2014012738 W KR2014012738 W KR 2014012738W WO 2015186884 A1 WO2015186884 A1 WO 2015186884A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
common traffic
traffic information
route
server
Prior art date
Application number
PCT/KR2014/012738
Other languages
English (en)
Korean (ko)
Inventor
최재혁
안홍범
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Publication of WO2015186884A1 publication Critical patent/WO2015186884A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0968—Systems involving transmission of navigation instructions to the vehicle

Definitions

  • 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.
  • 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.
  • GPS global positioning system
  • 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.
  • OMA Open Mobile Alliance
  • DMB digital multimedia broadcasting
  • DMA digital multimedia broadcasting
  • DMB digital multimedia broadcasting
  • DynNav dynamic navigation enabler
  • IP Internet Protocol
  • 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.
  • a method of obtaining traffic information from a server in a navigation device 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.
  • 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.
  • NIU network interface unit
  • Update start point information indicating a start point of a section in which information is provided
  • update end point information indicating an end point of a section in which the updated common traffic information is provided
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the time information 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.
  • 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.
  • acquiring the updated common traffic information may include obtaining the most recently updated common traffic information.
  • the common traffic information may indicate traffic information related to a section common to a specific user group.
  • a signal can be efficiently transmitted and received in a navigation system.
  • 1 illustrates a navigation device
  • FIG. 2 is a flowchart illustrating an operation of a smart ND.
  • FIG. 3 is a flowchart illustrating the operation of a light weight ND.
  • FIG. 4 is a network diagram for explaining the overall IP-based DynNav system.
  • 5 shows a hierarchical structure of TPEG.
  • FIG 6 illustrates an example in which common traffic information is provided.
  • FIG. 7 illustrates a flowchart of a method for providing common traffic information in accordance with the present invention.
  • FIG. 8 illustrates a block diagram of an apparatus to which the present invention can be applied.
  • 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.).
  • 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.).
  • 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 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.
  • 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.
  • the DynNav application is a kind of client.
  • 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.).
  • the DynNav server corresponds to a type of the server.
  • 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.).
  • 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.
  • GNSS Global Navigation Satellite System
  • This entity may process real-time and predicted traffic information and dynamically estimates the optimal route, according to user preferences.
  • 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.
  • 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.).
  • 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.).
  • a continuous road between intersections and intersections is called a segment
  • roads are defined as segments by dividing the roads according to the policy of each highway.
  • traffic congestion or passing time may be determined.
  • segments are used interchangeably with road segments.
  • 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.
  • 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).
  • the route information corresponds to information about coordinates of segment end points and complimentary data from the defined origin and the destination.
  • traffic information corresponds to information composed of traffic events and network performance parameters related to an area or a route.
  • the traffic information may include current or future traffic information, that is, future traffic information.
  • 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)).
  • 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 including all segments from a source to a destination.
  • path information means the entire path.
  • DynNav Dynamic Navigation
  • 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.
  • 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.
  • 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.
  • 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.
  • a broadcasting network such as DMB
  • IP such as a mobile communication network or Wi-Fi
  • 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.
  • 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.
  • 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.
  • each information format can be defined as an XML Schema Definition (XSD).
  • 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.
  • 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.
  • 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.
  • 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.
  • the performance parameter structure may be referred to as performance information.
  • FIG. 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.
  • Smart ND calculates route based on trip information
  • Smart ND delivers the calculated route to the server, and the server delivers the real-time traffic of the route.
  • Smart ND subscribes service based on route delivered to receive real-time traffic notification service from server.
  • 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.
  • the server may respond with a representation of the generated “trip” resource. In this use case behaviors are equivalent.
  • 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.
  • 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.
  • the application subscribes to a notification service for trips and routes.
  • 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.
  • the application accesses and reads the updated resources.
  • the application decides to calculate a new route using the received resource.
  • 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.
  • the application requests to change the subscription setting to add a notification for the newly subscribed path.
  • 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.
  • the lightweight ND receives a set of paths (including recommended paths) calculated by the server from the server
  • 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.
  • 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.
  • 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.
  • 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.
  • the application removes unnecessary paths previously proposed by the server but not selected by the user.
  • 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:
  • 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.
  • the application 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.
  • 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.
  • 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).
  • 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.
  • the server informs using a Uniform Resource Locator (URL) of updated information.
  • URL Uniform Resource Locator
  • 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.
  • 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.
  • ND navigation device
  • DynNav Server information server
  • Assistance Data assistance data for obtaining the location of the navigation device.
  • 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. ”.
  • 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.
  • the terminal capable of calculating the route itself may selectively receive only real-time traffic information without receiving route guidance data from the server.
  • 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.
  • POI point of interest
  • a navigation application or a terminal is collectively referred to as a terminal to eliminate duplication of expression.
  • terminal “terminal”, “ND”, “Smart ND”, “Lightweight ND” and “navigation application” may all be referred to as “terminal”.
  • TPEG Transport Protocol Experts Group
  • TPEG means a standard protocol for transmitting traffic and travel information through a digital broadcasting network.
  • 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.
  • 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.
  • 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.
  • 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).
  • the traffic information may include traffic event information (eg, Table 5, trafficeEvents) and network performance information (eg, see Table 7).
  • 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.
  • the present invention proposes a method for efficiently providing common traffic information to DynNav applications passing through the same section.
  • common traffic information refers to a common (path) section for a specific user group (eg, at least one navigation device).
  • common traffic information is the opposite of user-specific traffic information.
  • 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.
  • FIG. 6 illustrates an example in which common traffic information is provided.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 7 illustrates a flowchart of a method for providing common traffic information in accordance with the present invention.
  • the same / similarity may be applied to the smart ND.
  • 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.
  • a notification may be used in the same sense as a notification message.
  • the DynNav application 710 may receive (or obtain) route information from the DynNav server 720.
  • the route information may include at least one of the information illustrated in Tables 4 and 5, for example.
  • the route information may include information for providing common traffic information.
  • 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.
  • the DynNav server 720 may indicate whether common traffic information is provided to the DynNav application 710 based on the information.
  • LastComTrafficSegment Information indicating an index of the last segment of the section where common traffic information is provided (eg, lastComTrafficSegment);
  • the route information provides link information (eg, a link element) indicating a route resource including the traffic information.
  • link information eg, a link element
  • 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.
  • Link information about two or more common traffic information (or resources for common traffic information) included in the route information may be provided sequentially.
  • 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.
  • the link information and the address information may be mixed with each other.
  • 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).
  • indication information eg, numCommonTrafficInfo
  • address information or link information
  • Table 8 illustrates the information added / modified in the route information illustrated in Tables 4 and 5 to provide common route information.
  • the DynNav server 720 may provide traffic information to the DynNav application 710.
  • the traffic information may include traffic event information (eg, trafficEvents) and network performance information (eg, see Table 7).
  • step S702 may be performed in step 3 of FIG. 3.
  • 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.
  • address information eg, a URL
  • step S704 may be performed in step 4 of FIG. 3.
  • common traffic information may be changed.
  • 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.
  • a notification event may occur, and a notification message for notifying the occurrence of an event may be generated when the notification event occurs.
  • the common traffic information is updated by the DynNav server 720.
  • the DynNav application 710 may receive (or obtain) at least one notification message instructing to update common traffic information from the DynNav server 720.
  • the notification message received in step S708 may be a notification message generated in step S706.
  • step S708 may be performed in step 9 of FIG. 3.
  • 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.
  • address information eg, URL
  • step S704 may be performed in step 10 of FIG. 3.
  • Common traffic information 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 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 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 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.
  • the common traffic information may include performance information (eg, performance element).
  • the performance information may refer to information describing a traffic condition of a specific road segment or route section.
  • network performance information eg, performanceParameter
  • signaling overhead may occur and burden on the network.
  • indication information eg, comTrafficInfo
  • the indication information may be included as one element in segment information (eg, Table 6).
  • the indication information eg comTrafficInfo
  • 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.
  • the indication information eg, comTrafficInfo
  • the indication information eg, comTrafficInfo
  • segment information eg, performance parameter of Table 6
  • the indication information eg, comTrafficInfo
  • the indication information 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.
  • 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.
  • 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.
  • 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.
  • the DynNav application 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.
  • 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).
  • one or more pieces of common traffic information indicating an acquisition time of each piece of common traffic information may be included in the route information.
  • the common traffic acquisition time information is set to '00: 00 ', it may mean that the DynNav application immediately acquires common traffic information.
  • 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.
  • 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).
  • link information eg, a URL
  • the DynNav application 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).
  • Method 1 described above may be applied to the methods illustrated in FIGS. 2, 3, and / or 7.
  • 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.
  • 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.
  • 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.
  • the DynNav server sends a notification (or a notification message) to the DynNav application to receive the updated common traffic information for the section.
  • the notification includes link information (eg, Link) that can receive updated common traffic information.
  • link information eg, Link
  • 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. .
  • 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.
  • information indicating the start point (eg, comTrafficOrigin) is referred to as update start point information
  • information indicating the end point is referred to as update end point information.
  • the DynNav application may ignore the updated common traffic information.
  • the DynNav application may obtain updated common traffic information. have.
  • the update start point information eg comTrafficOrigin
  • the update end information eg comTrafficEndPoint
  • 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.
  • 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.
  • Method 2 described above may be applied to the methods illustrated in FIGS. 2, 3, and / or 7.
  • the update start point information eg comTrafficOrigin
  • the update end point information eg comTrafficEndPoint
  • 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.
  • 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.
  • update start point information eg, comTrafficOrigin
  • update endpoint information eg, comTrafficEndPoint
  • common traffic acquisition time information eg, comTrafficRetrievalTime
  • 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).
  • 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.
  • the common traffic acquisition time information e.g. comTrafficRetrievalTime
  • the DynNav application may not access the updated common traffic information.
  • the common traffic acquisition time information eg, comTrafficRetrievalTime
  • 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.
  • 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.
  • application specific integrated circuits ASICs
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • the firmware or software when implementing the present invention using 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.
  • 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).
  • the RF unit may be replaced with a network interface unit (NIU).
  • NIU network interface unit
  • 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.
  • 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.
  • 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.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • processors controllers, microcontrollers, microprocessors, and the like.
  • 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.
  • the invention can be used in a navigation device or server.

Landscapes

  • Engineering & Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Navigation (AREA)

Abstract

L'invention concerne un procédé et un appareil pour obtenir des informations sur le trafic, et plus particulièrement, une méthode consistant en : l'acquisition des informations sur les chemins à partir d'un serveur ; la réception d'au moins un message de notification indiquant une mise à jour d'informations courantes sur le trafic à partir du serveur ; et quand une condition particulière est remplie, l'obtention des informations courantes sur le trafic qui ont été mises à jour, les informations sur les chemins comprenant les informations sur le temps d'obtention des informations courantes sur le trafic, et le message de notification comprenant des informations sur le point de départ de la mise à jour indiquant un point de départ d'une section disposant des informations courantes sur le trafic mises à jour fournies et des informations sur le point d'arrivée de la mise à jour indiquant un point d'arrivée d'une section disposant des informations courantes sur le trafic mises à jour fournies, et un appareil associé.
PCT/KR2014/012738 2014-06-03 2014-12-23 Procédé pour obtenir des informations courantes sur le trafic et appareil associé WO2015186884A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201462007368P 2014-06-03 2014-06-03
US62/007,368 2014-06-03
US201462015526P 2014-06-23 2014-06-23
US62/015,526 2014-06-23

Publications (1)

Publication Number Publication Date
WO2015186884A1 true WO2015186884A1 (fr) 2015-12-10

Family

ID=54766933

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2014/012738 WO2015186884A1 (fr) 2014-06-03 2014-12-23 Procédé pour obtenir des informations courantes sur le trafic et appareil associé

Country Status (1)

Country Link
WO (1) WO2015186884A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040028377A (ko) * 2002-09-30 2004-04-03 현대자동차주식회사 차량용 네비게이션 시스템의 경로 탐색 제어장치 및 방법
KR20070092574A (ko) * 2006-03-09 2007-09-13 삼성전자주식회사 경로 정보 애플리케이션을 제공하는 장치 및 방법
KR20090055680A (ko) * 2007-11-29 2009-06-03 주식회사 현대오토넷 위치정보 공유를 이용한 공통 경로 탐색 시스템 및 방법
US20100279673A1 (en) * 2009-05-01 2010-11-04 Apple Inc. Remotely Locating and Commanding a Mobile Device
JP2011238144A (ja) * 2010-05-13 2011-11-24 Hitachi Ltd 交通情報取得システム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040028377A (ko) * 2002-09-30 2004-04-03 현대자동차주식회사 차량용 네비게이션 시스템의 경로 탐색 제어장치 및 방법
KR20070092574A (ko) * 2006-03-09 2007-09-13 삼성전자주식회사 경로 정보 애플리케이션을 제공하는 장치 및 방법
KR20090055680A (ko) * 2007-11-29 2009-06-03 주식회사 현대오토넷 위치정보 공유를 이용한 공통 경로 탐색 시스템 및 방법
US20100279673A1 (en) * 2009-05-01 2010-11-04 Apple Inc. Remotely Locating and Commanding a Mobile Device
JP2011238144A (ja) * 2010-05-13 2011-11-24 Hitachi Ltd 交通情報取得システム

Similar Documents

Publication Publication Date Title
WO2011021899A2 (fr) Procédé et dispositif pour générer, gérer et partager un chemin mobile
WO2014146514A1 (fr) Procédé, dispositif et système de positionnement associant gps, wi-fi et station de base
WO2018151487A1 (fr) Dispositif destiné à réaliser une communication dans un système de communication sans fil et procédé associé
WO2019117614A1 (fr) Système et procédé pour tester une route à chaussée à conduite automatisée coopérative à application v2x et voiture connectée
EP1237389B1 (fr) Procédé et système permettant d'éviter de mise à jour de localisation de terminal mobile dans un train et un système d'offrir des informations de localisation
WO2015046960A1 (fr) Procédé de délivrance d'un message de notification dans un système m2m et dispositifs associés
WO2020075942A1 (fr) Procédé de prédiction d'informations de circulation routière, appareil et programme informatique
JP6105747B2 (ja) 経路計算方法、経路獲得方法またはこのための装置
WO2016182256A1 (fr) Dispositif et procédé d'attribution de ressources pour un service de véhicule
WO2016129957A1 (fr) Procédés et appareils de traitement de contexte d'équipement utilisateur d'un équipement utilisateur
EP3391678A1 (fr) Procédé et appareil pour transmettre un message entre un véhicule et tout (v2x)
WO2015178574A1 (fr) Système de fourniture d'informations et procédé associé
WO2018030868A1 (fr) Procédé de communication v2x et terminal
US9749930B2 (en) Method for delivering optimum path including plurality of passage places and apparatus therefor
WO2017213291A1 (fr) Système de données de navire intégrées et navire le comprenant
WO2013094865A1 (fr) Procédé de calcul de trajets, procédé d'obtention de trajets ainsi que terminal pour celui-ci
JP5666669B2 (ja) 交通量の変化を感知して経路を探索する通信型ナビゲーションシステム
WO2020046034A1 (fr) Procédé et appareil d'utilisation de données mobiles de sim logicielle
WO2020138516A1 (fr) Dispositif de communication, procédé de commande associé, et système de communication le comprenant
WO2014109616A1 (fr) Procédé de transfert d'itinéraire et dispositif associé
WO2019107782A1 (fr) Système, serveur et procédé de fourniture d'informations
WO2020149714A1 (fr) Procédé de division de message cpm utilisant un tri d'états d'objet
WO2020231117A1 (fr) Procédé et appareil pour obtenir et gérer des informations de localisation d'un terminal mobile dans un système informatique en périphérie
WO2014084595A1 (fr) Procédé et équipement pour avertir un terminal dans un relais mobile
WO2021182935A1 (fr) Procédé et dispositif pour générer une carte de chemin d'usagers de la route vulnérables (vru) associée à un chemin de déplacement d'usagers vru par un serveur logiciel v2x dans un système de communication sans fil prenant en charge une liaison latérale

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14893748

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14893748

Country of ref document: EP

Kind code of ref document: A1