Conventionally, a navigation terminal detects its current location, that is, an origin of a trip through a Global Positioning System (GPS) connection, receives information about a destination of the trip from a user, and internally calculates a route based on the origin and the destination. Along with the recent proliferation and increased performance of smartphones, services have become popular, in which a traffic and route information providing server provides route information, real-time traffic information related to routes, and other various information to Personal Navigation Devices (PNDs) over a mobile communication network.
Particularly in the situation where various navigation services are available, the Open Mobile Alliance (OMA) standardization organization is working on standardization of Dynamic Navigation Enabler (DynNav) that provides real-time traffic information by Peer to Peer (P2P) communication through an Internet Protocol (IP)-based network of a mobile communication network or a wireless network, rather than Traffic Protocol Expert Group (TPEG) information is transmitted over a Digital Multimedia Broadcasting (DMB) network that provides information in a broadcast signal. The standard considers a navigation terminal and a service type largely in two ways for a smartphone.
First, a traffic and route information providing server performs complex route computation, instead of a navigation application loaded in a smartphone, and indicates a calculated route to the smartphone. Second, owing to the improved performance of a smartphone, an application loaded in the smartphone performs or a navigation terminal equipped with a mobile communication modem performs route computation. In this case, the traffic and route information providing server does not provide route information. Rather, once the terminal registers a calculated route to the server, the terminal can receive from the server only real-time traffic information related to the registered route in a customized manner by IP-based P2P communication, not in a conventional broadcast signal.
FIG. 1 illustrates Navigation Device (ND) types. NDs may be classified into a type 110 that additionally provides TPEG-based traffic information transmitted through a broadcasting network such as a DMB network, a type 120 that additionally provides traffic information in an IP-based manner, for example, over a mobile communication network or a Wireless Fidelity (Wi-Fi) network, and a standalone type 130 that tracks the location of a vehicle through a GPS connection without connecting to other communication media, generates route information, and provides the route information.
DynNav under standardization in the OMA LOC WG belongs to the type 120 that provides IP-based traffic information, specifically by P2P communication. The following two types of NDs are defined in DynNav.
Smart ND: a device that can calculate a route on its own and thus requests only real-time traffic information to a DynNav server without receiving route information from the DynNav server.
Lightweight ND: a device that cannot calculate a route on its own and thus requests all real-time traffic information including route information to a DynNav server.
Since traffic information is requested and provided in a RESTful-based manner in a conventional DynNav system, the following route information formats are used and each information format can be defined by XML Schema Definition (XSD).
1) Trip Structure: a terminal initially acquires basic information such as an origin and a destination from a user, for route setting, and provides the acquired information to a server. The trip structure includes subsets corresponding to a plurality of route structures.
TABLE 1ElementTypeOptionalDescriptionoriginWGS84Location_PointYesLocation information about an originrepresented by WGS84 (Location_Pointstructure is defined in tpeg-locML [TTI LOC].At least one element originWGS84 ororiginAddress MUST be specified.)originAddressCivic LocationYesLocation information about the originFormatrepresented as a civic location (Civic LocationFormat is defined by IETF [RFC 5139]. Atleast one element originWGS84 ororiginAddress MUST be specified.)destinationWGS84Location_PointYesLocation information about a destinationrepresented by WGS84 (Location Pointstructure is defined in tpeg-locML [TTI LOC].At least one element destinationWGS84 ordestinationAddress MUST be specified.)destinationAddressCivic AddressYesLocation information about the destinationFormatrepresented as a civic location (Civic LocationFormat is defined by IETF [RFC 5139]. Atleast one element destinationWGS84 ordestinationAddress MUST be specified.)waypointsLocation_PointYesLocation information about a way point[0 . . . unbounded](represented by WGS84)(Location_Pointstructure is defined in tpeg-locML [TTILOC].)startingTimexsd:dateTimeYesStarting time of navigation service (if a servicestarting time is specified, the trip is a plannedtrip. If a service starting time is not specified,a current time is the service starting time).(starting time of the planned trip. If notpresent, current time is assumed.)tollRoadxsd:booleanYesIt indicates whether passing through a toll roadis allowed. (If true or not present, a toll road isallowed.)vehicleTypeVehicle_InfoYesInformation about a used vehicle(Vehicle_Info structure is defined in tpeg-rtmML [TTI RTM].)calculateRoutexsd:booleanYesIt indicates whether the server provides acalculated route. (If false or not present,the server should not propose routes.)linkcommon:LinkYesLin information about routes defined in the[0 . . . unbounded]trip. (Links to routes related to the trip.Attribute “rel” must be set to “Route”.)resourceURLxsd:anyURIYesSelf-referring URL information (Self-referringURL. SHALL NOT be included in POSTrequests, MUST be included in responses toany HTTP method that returns an entity body,and in PUT requests.)
2) Route Structure: a route structure is expressed as a plurality of segments as a way to represent total routes calculated using the trip structure.
TABLE 2ElementTypeOptionalDescriptiontravellingTimexsd:floatYesTotal travelling time (in minutes) for the routedistancexsd:floatYesTotal distance (in Km) of the routeoriginLocation_PointNoOrigin of the route (represented by WGS84)(Location_Point structure is defined in tpeg-locML [TTI LOC].)segmentSegmentNoSequence of road segments that form the route[1 . . . unbounded]trafficEventsCategorizedEventYesInformation about links accessing trafficListReferenceinformation resources (List of traffic events as[0 . . . unbounded]defined in tpeg-rtmML [TTI RTM], groupedinto categories.)linkcommon:LinkYesReference to the route for which it is proposedas alternative. Attribute “rel” must be set to“Route”.resourceURLxsd:anyURIYesSelf-referring URL. SHALL NOT be includedin POST requests, MUST be included inresponses to any HTTP method that returns anentity body, and in PUT requests.)
3) Segment Structure: it is a structure that represents each segment. The segment structure may define a real-time traffic state corresponding to the segment as well as the length of the segment, in TPEG.
TABLE 3ElementTypeOptionalDescriptionendPointLocation_PointNoLocation information about the end point of eachsegment (represented by WGS84)(Location_Pointstructure as defined in tpeg-locML [TTI LOC]. Thestarting point of the segment should be assumedequal to the ending point of the previous segment (orthe trip origin for the first segment))midwayPointLocation_PointYesLocation_Point structure as defined in tpeg-locML[0 . . . unbounded][TTI LOC].linkNamexsd:stringYesName of the road that the segment belongs todistancexsd:floatYesLength of the segment in kmtravellingTimexsd:floatYesEstimated average time to cover the segmentexpressed in minutes. It includes regular travellingtime and delay.delayxsd:floatYesEstimated delay along the segment expressed inminutes.speedxsd:floatYesEstimated average speed along the segmentexpressed in m/s.performancexsd:stringYesInformation about traffic state (levels may be definedto indicate delay, congestion, and severe congestion).(Description of traffic conditions along the segment.This field should be encoded according to tpegrtmML definition [TTI RTM].)
FIG. 2 is a diagram illustrating a signal flow for an operation of a lightweight ND in a conventional DynNav system. Because the lightweight ND does not support route calculation in view of its capability, the lightweight ND should request route information to a server and receive the route information from the server. The lightweight ND has the following main functionality.
1. The lightweight ND transmits trip information to the server, for use in route calculation at the server.
2. The lightweight ND receives information about a set of routes (including a recommended route) calculated by the server from the server.
3. The lightweight ND subscribes to a notification service to receive real-time traffic information from the server.
The signal flow illustrated in FIG. 2 contains the followings, on the whole.
1. The user defines journey parameters, and the application sends the parameters to the server; the server calculates a set of proposed routes based on the received parameters with related traffic information. The server replies with the location of the created “trip” resource to the application.
a) The server may reply with a representation of created “trip” resource, which contains resources identifiers of the proposed routes. In this case, message 2 is no longer required.
2. The application uses the trip resource to access trip's information which contains resources identifiers of the proposed routes.
3. The application uses the Route Identifier to access information describing each single proposed route with links to traffic events and performance parameters.
4. The application accesses then to traffic events related to the route, using links to traffic event resources provided in the route structure.
5. The user selects a route among the set of routes for which he is interested in receiving updated performance parameters and traffic events, and alternative routes when available.
6. The application requests to the server to create a subscription to notification service for the trip and route(s). The application is notified by the server of the following events:                New performance parameters and changes in traffic events, notification resource will include links to already existing routes resources.        Proposal of alternative routes due to traffic problems along the proposed routes; the notification resource will include the link to trip resource.        
7. Traffic events and/or changes of performance parameters occur on the subscribed route(s): a notification resource is created.
8. The server delivers the notification resources to the application with links to modified resources, including the trip and the route with the updated traffic information (traffic events and performance parameters).
9. The application accesses the updated resources. The resources should be reflected in appropriate way.
10. The application request to modify the subscription setting adding notification for the new route. Just in case, the updated resource is an alternative route in step 9.
FIG. 3 is a diagram illustrating a signal flow for an operation of a smart ND in the conventional DynNav system. Because the smart ND supports route calculation in view of its capability, the smart ND calculates a route on its own based on trip information defined by a user and transmits information about the calculated route to a server. The smart ND has the following main functionality.
1. The smart ND calculates a route based on trip information.
2. The smart ND transmits information about the calculated route to the server and the server notifies the smart ND of a real-time traffic state.
3. The smart ND subscribes to a notification service based on the transmitted route information in order to receive real-time traffic information from the server.
The signal flow illustrated in FIG. 3 contains the followings on the whole.
1. The user defines journey parameters and the application sends parameters to the server. The server replies with the location of the created “trip” resources to the application.
a) The server may replay with a representation of created “trip” resource. In this use case behaviors are equivalent.
2. The application uploads the calculated route under the resource/{tripId}/routes. The server replies with a representation of the “route” resource, which contains performance parameters and links to traffic events.
a) The server may reply with the traffic information (performance parameters and traffic events). In this case an additional get operation is needed to retrieve content of resource.
3. The application subscribes to notification service for the trip and route.
4. Traffic events and/or changes of performance parameters occur on the subscribed route(s); a notification resource is created.
5. The server delivers the notification resource to the application with links to the modified resources, including the trip and the route with updated performance parameters and traffic information.
6. The application accesses to the updated resources and read the resources.
7. The application decides to calculate a new route with the received resources.
8. The application uploads the new calculated route under the resource/{tripId}/routes. The server replies with a representation of the “route” resources, which contains route performances and links to vents. This step may be repeated many times until a route that satisfies performance constrains is found.
9. The application requests to modify the subscription setting adding notification for the newly subscribed route.
The lightweight ND and smart ND of the conventional DynNav system described with reference to FIGS. 2 and 3 have several problems. Thereamong, in the present specification, the problems of the smart ND will be described.
A) Problems upon route retransmission
A smart ND calculates and transmits a first route to a server and subscribes to a notification service based on the route. Through this service, the smart ND may receive real-time traffic modification information of the route transmitted and managed by the server. If real-time traffic information is modified, the server delivers the information to a terminal via the notification service.
In the related art, the terminal receives the notification service, recalculates the route based on the modified route and transmits the whole route to the server based on the route recalculated by the terminal. At this time, the server checks the modified route and delivers real-time traffic information (generally including an estimated passage time of a segment) of the whole route as a response. After the terminal receives the response, if the calculated result is lower than previous route performance (route performance is changed according to implementation and service type), the smart ND recalculates another route and transmits the recalculated route to the server as a response. As a result, the above process is repeated in order to obtain a route with high route performance.
a) However, when this process is repeated, although the whole route may not actually be modified, the recalculated whole route should always be delivered from the terminal to the server. Transmitting the overlapping route data from the terminal to the server may cause unnecessary resource waste in both the terminal and the server. This will now be described in greater detail.
FIG. 4 shows operation of a smart ND according to the related art.
A terminal delivers navigation service request values (an origin, a destination, route type preference, etc.) of a user to a server to request current traffic information between the origin and the destination before route search (S401). The server receives the request of the terminal in S401 and provides traffic information, e.g., a traffic event and network performance parameters, based on the origin and the destination requested by the terminal. At this time, since a route is not accurately known, the server restrictively provides traffic information (S402). The terminal calculates a route based on the received traffic information and delivers and registers the route to and with the server in order to receive real-time traffic information (S403). The terminal starts a navigation service based on the traffic information (S405). If traffic flow of the route registered with the server (accidents or congestions on the route) is not changed, the traffic flow of the registered route is checked while step S405 is repeatedly performed. When change in traffic flow of the registered route is detected, the following steps are performed.
The server recognizes change in traffic flow and describes the change (S406). Change in traffic flow (that is, the traffic event and/or network performance parameters) is individually defined as resources. If the server recognizes change in traffic flow, the server allocates resources for the traffic flow and notifies the terminal of the resources (S407). The terminal recalculates a route based on real-time traffic information (S408). The terminal delivers the researched (recalculated) route to the server (S409). Then, the terminal may receive the real-time traffic information corresponding to the researched route from the server (S404).
In operation related to FIG. 4, in delivery of the traffic information according to change in traffic flow, recalculation of the route based on the delivered traffic information and upload of the recalculated route via S406 to S409, if the route transmitted from the terminal to the server partially overlaps with an existing route, unnecessary data transmission/reception may be performed.
B) In addition, a process of searching for a new route having better performance (having a shorter route passage time) than an existing route is infinitely repeated. For example, if estimated passage times of routes newly calculated by the terminal are greater than the estimated passage time of the route already registered with the server, S408 and S409 of the above-described process may be continuously repeated. This stops the navigation service or reduces service quality or user experience index.