Method for controlling a telematics control unit

Abstract

A method for controlling a telematics control unit, which includes obtaining (S11) information on a discontinuity beneficial condition associated with a vehicle to which the telematics control unit is connected. The discontinuity beneficial condition indicates that an extended discontinuous reception mode is beneficial for the telematics control unit connected to the vehicle. Obtaining (S13) a determination of an extended discontinuous reception time for the telematics control unit. Initiating a request for the extended discontinuous reception mode for the telematics control unit, in response to the obtained discontinuity beneficial condition, proposing the determined extended discontinuous reception time. A telematics control unit for performing such a control method is also proposed.

Description

[0001] This application is a divisional application of the Chinese patent application with the invention title "Method for Controlling a Telematics Control Unit" (application number: 201780077065.8, filing date: November 9, 2017). Technical Field

[0002] The proposed technology generally relates to the control of a telematics control unit, and more particularly to a method and apparatus for controlling a sleep mode of a connected telematics control unit of a vehicle using extended discontinuous reception. Background Art

[0003] A cooperative intelligent transport system (C-ITS) is a system that uses information and communication technologies (ICT) to support improved safety and more efficient use of transport infrastructure for transporting goods and people by any mode of transport.

[0004] Intelligent transport system (ITS) services, protocols, and connectivity technical solutions are described in specifications published by standardization bodies such as IEEE, SAE, ETSI, and ISO. In addition to the standards mentioned above, the C-ITS system architecture is also described in detail in research collaborations such as Communication Networks Vehicle Road Global Expansion (CONVERGE), the Nordic model, and in alliances of automotive manufacturers, suppliers, and research organizations such as ERTICO and the Vehicle-to-Vehicle Communication Consortium.

[0005] Discussions are ongoing regarding the connectivity of C-ITS. The discussions are about whether to use the ETSI ITS G5 / IEEE WAVEDSRC technical solution, the cellular 3rd Generation Partnership Project (3GPP) technology, or the new 3GPP-based Long Term Evolution (LTE) Vehicle-to-Everything (V2X) radio technical solution, and what combination to adopt (e.g., a hybrid technical solution).

[0006] C-ITS is based on frequent short-distance communication between different mobile or fixed stations or units to exchange information such as location, speed, environmental conditions, traffic conditions, etc. When many vehicles are present in a restricted area and / or when external conditions are complex and cumbersome, the signaling load becomes very large and congestion problems may occur.

[0007] Vehicles are increasingly being connected to mobile networks. They use a telematics control unit (TCU) located in the vehicle, which is (usually) integrated into the vehicle's electronic system or connected via an external interface such as the on-board diagnostic II (OBD II) interface. They are equipped with a radio for communicating with an application server via a cellular network. The application server is, for example, under the control of the vehicle original equipment manufacturer (OEM) or other third-party service providers. Additionally, the TCU may have a radio for short-range communication (e.g., dedicated short-range communication (DSRC)), or in the future, LTE technology (LTE-V) may be used for short-range communication.

[0008] Sometimes the TCU is also referred to as a telematics module (TEM) or on-board unit (OBU).

[0009] Being integrated or connected to the vehicle's external interface means that the TCU can receive events from the vehicle system, forward them to the OEM, forward information to other vehicles or roadside devices using short-range communication, or forward information to the road traffic management department using the cellular network. Of course, the TCU can also receive information on the short-range radio or from the cellular network and display or forward that information. For example, the vehicle system can detect a wheel that has lost traction and can distribute a road slippery warning as a broadcast message on the short-range radio or send it to a central entity for evaluation. Alternatively, the vehicle can react to the received information. For example, the received message about a slippery road can activate the vehicle's anti-skid system.

[0010] The mobile network has a feature that allows devices to enter an extended sleep mode, extended discontinuous reception (eDRX). The device can suggest the length of the sleep mode, and the current maximum sleep time is 2.9 hours. The eDRX feature is controlled by sending information during the attachment process and the tracking area update process.

[0011] Even though a vehicle is equipped with a high-power battery, there are still several power-consuming systems in the vehicle, such as alarms, computers, etc. For example, before being shipped to customers, the vehicle may also be parked at an airport or other places for a long time, so it is necessary to optimize battery usage. SUMMARY OF THE INVENTION

[0012] One objective is to provide a technology that improves the energy optimization of the telematics control unit.

[0013] According to a first aspect, a method for controlling a telematics control unit is provided. The method obtains information about a discontinuity beneficial condition associated with a vehicle to which the telematics control unit is connected. The discontinuity beneficial condition indicates that an extended discontinuous reception mode is beneficial for the telematics control unit. A determination of an extended discontinuous reception time for the telematics control unit is obtained. In response to the obtained discontinuity beneficial condition, a request for the extended discontinuous reception mode for the telematics control unit is initiated, suggesting the determined extended discontinuous reception time.

[0014] According to a second aspect, a telematics control unit is provided. The telematics control unit is configured to obtain information about a discontinuity beneficial condition associated with a vehicle to which the telematics control unit is connected. The discontinuity beneficial condition indicates that an extended discontinuous reception mode is beneficial for the telematics control unit. The telematics control unit is further configured to obtain a determination of an extended discontinuous reception time for the telematics control unit. The telematics control unit is further configured to, in response to the obtained discontinuity beneficial condition, initiate a request for the extended discontinuous reception mode for the telematics control unit, suggesting the determined extended discontinuous reception time.

[0015] According to a third aspect, a computer program is provided, which includes instructions that, when executed by at least one processor, cause the processor to obtain information about a discontinuity beneficial condition associated with a vehicle to which the telematics control unit is connected. The discontinuity beneficial condition indicates that an extended discontinuous reception mode is beneficial for the telematics control unit. The instructions, when executed by the processor, further cause the processor to obtain a determination of an extended discontinuous reception time for the telematics control unit. The instructions, when executed by at least one processor, further cause the processor to, in response to the obtained discontinuity beneficial condition, initiate a request for the extended discontinuous reception mode for the telematics control unit, suggesting the determined extended discontinuous reception time.

[0016] According to a fourth aspect, a computer program product is provided, which includes a computer-readable medium having stored thereon the computer program according to the third aspect.

[0017] According to a fifth aspect, a carrier is provided, which includes the computer program according to the third aspect, wherein the carrier is one of the following: an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable storage medium.

[0018] According to a fifth aspect, a telematics control unit is provided. The telematics control unit includes a condition obtaining module for obtaining information on a discontinuity beneficial condition associated with a vehicle to which the telematics control unit is connected. The discontinuity beneficial condition indicates that an extended discontinuous reception mode is beneficial for the telematics control unit. The telematics control unit further includes a time determination obtaining module for obtaining a determination of an extended discontinuous reception time for the telematics control unit. The telematics control unit further includes a transmitter for initiating, in response to the obtained discontinuity beneficial condition, a request for the extended discontinuous reception mode for the telematics control unit, suggesting the determined extended discontinuous reception time.

[0019] An advantage of the proposed technology is that it optimizes the battery utilization of the vehicle.

[0020] Other advantages will be understood when reading the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The embodiments and their further objects and advantages can be best understood by referring to the following description in conjunction with the accompanying drawings, in which:

[0022] Figure 1 is a schematic illustration of a C-ITS system;

[0023] Figure 2 is a schematic illustration of an embodiment of sleep time control;

[0024] Figure 3 is a flowchart of an embodiment of a control method;

[0025] Figure 4 is a schematic flowchart showing an embodiment of a method for controlling a TCU;

[0026] Figure 5 is a schematic block diagram of an embodiment of a TCU;

[0027] Figure 6 is a schematic block diagram showing an embodiment of a TCU;

[0028] Figure 7 is a schematic block diagram showing another embodiment of a TCU;

[0029] Figure 8 is a schematic block diagram showing yet another embodiment of a TCU;

[0030] Figure 9 is a schematic diagram showing an example of computer implementation;

[0031] Figure 10 is a schematic block diagram showing an example of a vehicle including a TCU;

[0032] Figure 11 is a schematic diagram showing an example of a TCU used in a cooperative intelligent transportation system;

[0033] Figure 12 is a schematic diagram showing an example of how functions are distributed or partitioned among different network devices;

[0034] Figure 13 is a schematic diagram showing an example of a wireless communication system. DETAILED DESCRIPTION

[0035] To better understand the proposed technology, it may be useful to start with a brief overview of the C-ITS system.

[0036] Figure 1 The C-ITS system 1 is schematically shown. The C-ITS system 1 is connected to a communication node 10 and communicates with the core C-ITS system 1 through an internal communication 11 which can be wired and / or wireless. The communication node 10 can also be used to communicate with a vehicle OEM application 5 in a vehicle OEM cloud through the internal communication 11. The infrastructure project 2 is equipped with a roadside unit (RSU) 20 and communicates with the C-ITS system 1 through a backhaul network 12. This backhaul network can be wired and / or wireless. Non-exclusive examples of the public infrastructure project 2 are traffic lights and road signs. The vehicle 4 uses a telematics control unit (TCU) 40 to communicate with different entities in the C-ITS system 1. The TCU 40 can communicate with the RSU via, for example, a vehicle-to-infrastructure (V2I) scheme, communicate with other TCUs 40 via, for example, a vehicle-to-vehicle (V2V) scheme, and communicate with the communication node 10 via, for example, a vehicle-to-network (V2N) scheme. The TCU 40 can also be carried by a pedestrian 3, where a vehicle-to-pedestrian (V2P) scheme can be used.

[0037] Thus, the communication devices among these entities are the RSU 20 or the TCU 40. The TCU 40 can communicate while moving and can be installed in the vehicle 4 or even carried by a pedestrian 3. For a pedestrian, the TCU 40 is typically a smart phone, and in this case there is no direct connection to any "vehicle".

[0038] The telematics control unit (TCU) 40 is typically located in the vehicle 4 and is usually integrated into the vehicle systems and the dashboard. They are equipped with radios, such as 3GPP modems for cellular connectivity. Additionally, the vehicle may be equipped with short-range radio technologies, such as DSRC for short-range communication. In the future, LTE technology may be used for short-range communication. The fact that the TCU 40 is integrated means that, for example, it can receive events from the vehicle systems, display the event on the dashboard, or use short-range communication to forward information to other vehicles 4 or RSU 40 when equipped with short-range radio technology, or forward the information to the road traffic management department using the cellular network connection 54. Of course, the TCU 40 can also receive information over the short-range radio or from the cellular network and display or forward the information. Of course, the TCU can also react to the received information, for example, by instructing the vehicle systems to perform an action. In other words, the TCU 40 is a mobile communication device. The TCU typically has access to the vehicle control systems, such as any global positioning system (GPS) or other positioning systems, such as other global navigation satellite systems (GNSS). The TCU 40 typically includes the functions of a UE.

[0039] The TCU is also typically equipped with a radio for communicating with OEM applications on an application server via the cellular network. The application server is, for example, under the control of the vehicle original equipment manufacturer (OEM) or other third-party service providers. OEM applications, which are typically provided in the OEM cloud in the application server, are applications associated with the vehicle manufacturer. The applications of the application server provide vehicle services to the vehicle via the communication system. Thus, OEM applications are part of the telematics system, which typically provides services such as remote diagnostics of the vehicle, remote support for vehicle-related actions, and services that provide information about traffic, for example, to facilitate smooth or efficient driving. OEM applications typically know the state parameters of the vehicle and other information, such as the vehicle location.

[0040] To improve the utilization rate of the vehicle battery, the TCU can control and select the sleep time based on information from internal automotive systems and external sources.

[0041] An overview of an embodiment of sleep time control is in Figure 2As shown in. In the first stage 15, the TCU 40 and the OEM application 5 in, for example, the vehicle OEM cloud negotiate / share information via the cellular network. This information may include information about the existence of discontinuity beneficial conditions. These conditions will be discussed in further detail below. The communication between the TCU 40 (usually via the modem 41) and the OEM application 5 is preferably carried out via the cellular network, but can also be carried out in any available communication channel as described above. The TCU 40 can also obtain information about the existence of discontinuity beneficial conditions from other sources such as vehicle internal systems. The TCU 40 can also obtain information about the existence of discontinuity beneficial conditions from, for example, C-ITS nodes, positioning satellites, and / or wireless communication networks. The information from the OEM application server, vehicle internal systems, C-ITS nodes, positioning satellites, and / or wireless communication networks can also include discontinuity time impact parameters, based on which a suitable sleep time can be determined, or this information can include such a determined suitable sleep time. This will be discussed further below. Thus, the TCU 40 considers, for example, vehicle information through its own decision or suggestions from external nodes to determine a suitable sleep time.

[0042] In the second stage 16, the TCU 40 preferably uses the tracking area (TA) update request procedure to request a sleep time (eDRX) from the cellular network or at least initiate such a request.

[0043] In the third stage 17, preferably using the tracking area update acceptance procedure, the cellular network responds with an acceptance request. Then, the TCU 40 manages the transition to the eDRX mode.

[0044] Figure 3 A flowchart of an embodiment of the control method is shown.

[0045] In step S1, the TCU obtains a first trigger. In a general sense, the first trigger indicates that the vehicle is no longer in use, for example, parked, and the driver / owner / passenger is no longer in the vehicle or encounters a problem with the current battery voltage that causes the vehicle to enter an energy-saving mode. Therefore, this first trigger indicates the existence of a discontinuity beneficial condition regarding the vehicle. Such discontinuity beneficial conditions can preferably include vehicle inactivity conditions, personnel absence conditions, energy conditions, time conditions, and / or location conditions, and most preferably include vehicle inactivity conditions, personnel absence conditions, energy conditions, and / or time conditions.

[0046] Therefore, the first trigger can be one or a combination of discontinuity beneficial conditions. Examples are given below.

[0047] One type of discontinuity beneficial condition is the vehicle inactivity condition. Examples of such vehicle inactivity conditions can be, for example:

[0048] · The engine of the vehicle is turned off;

[0049] · The ignition device of the vehicle is turned off; and / or

[0050] · The internal system indicates that, in terms of communication with the network, the vehicle will enter an energy-saving mode or a deeper sleep.

[0051] Another type of discontinuity beneficial condition is the personnel absence condition. For example, examples of such a personnel absence condition can be, for example:

[0052] · The vehicle is locked from the outside;

[0053] · The keyless system of the vehicle does not sense a key within range; and / or

[0054] · The seat sensor of the vehicle indicates that no one is sitting in the vehicle or in the driver's seat of the vehicle.

[0055] Yet another type of discontinuity beneficial condition is the energy condition. Examples of such an energy condition can be, for example:

[0056] · Low battery voltage in the vehicle.

[0057] Another type of discontinuity beneficial condition is the time condition. Examples of such a time condition can be, for example:

[0058] · The time within a predetermined range during the day.

[0059] Yet another type of discontinuity beneficial condition is the location condition. Examples of such a location condition can be, for example:

[0060] · The location of the vehicle.

[0061] In a specific embodiment, a hysteresis time is used before the actual start of eDRX. For this purpose, in step S2, timer T 滞后 is started. Thus, in this embodiment, after the expiration of the hysteresis time, the initiation of the request for the extended discontinuous reception mode is executed. When information on the discontinuity beneficial condition is obtained, this hysteresis time starts.

[0062] Timer T 滞后 is used to prevent the vehicle from using eDRX prematurely after trigger 1 has occurred. For example, the driver may have locked the vehicle before all the luggage has been removed.

[0063] In step S4, it is inferred that the hysteresis time has expired, and the process continues to the following steps.

[0064] In another specific embodiment, the method preferably further includes steps of an interruption hysteresis process or a discontinuity process as will be further discussed below, in response to detecting a discontinuity stop condition. The presence of a discontinuity stop condition for the vehicle constitutes a second trigger, as Figure 3 shown in step S3 of

[0065] Generally, the second trigger is an indication to use the vehicle. Thus, the discontinuity stop condition may preferably include vehicle activity conditions, personnel presence conditions, energy conditions, and / or time conditions.

[0066] The second trigger may be one or a combination of the discontinuity stop conditions. Examples are given below.

[0067] One type of discontinuity stop condition is a vehicle activity condition. Examples of such vehicle inactivity conditions may be, for example:

[0068] · The ignition device of the vehicle is activated;

[0069] · The engine of the vehicle is started; and

[0070] · The autonomous driving function of the vehicle is activated.

[0071] Another type of discontinuity stop condition is a personnel presence condition. For example, examples of such personnel absence conditions may be, for example:

[0072] · The keyless system indicates that the key is within range;

[0073] · The vehicle is unlocked; and

[0074] · The seat sensor indicates that someone is in the vehicle.

[0075] Another type of discontinuity stop condition is an energy condition (in the case where the vehicle is an electric vehicle). Examples of such energy conditions may be, for example:

[0076] · The electric vehicle is recharged.

[0077] Yet another type of discontinuity stop condition is a time condition. Examples of such time conditions may be, for example:

[0078] · A time within a predetermined range during the day.

[0079] In a specific embodiment, as shown in step S5, before entering eDRX, the vehicle may upload some vehicle data to the application server. The application server is typically an OEM server that provides vehicle services to the vehicle. The vehicle data may be, for example, the battery status of an electric vehicle, etc. In this way, when the vehicle is unreachable in the eDRX mode, the driver can obtain the data from the application server.

[0080] The system calculates the suitable value of timer T eDRX as shown in step S6. This calculation can be done in the vehicle, or in the application server, or in any other external node, and reported to the vehicle. In other words, obtaining the determination of the extended discontinuous reception time includes communicating with the application server that provides vehicle services to the vehicle, the in-vehicle system of the vehicle, the C-ITS node, or receiving information from positioning satellites, for example. The communication can use a wireless communication network, for example, a cellular network.

[0081] T eDRX The calculated value of T, i.e., the extended discontinuous reception time, can depend on data of various parameters, which are represented herein as discontinuous time impact parameters. The discontinuous time impact parameters can be, for example, time and history related parameters, location related parameters, and / or energy related parameters. Examples are given below:

[0082] One type of discontinuous time impact parameter is time and history related parameters. Examples of such time and history related parameters can be, for example:

[0083] · Time of day;

[0084] · Day of the week;

[0085] · Annual season;

[0086] · Patterns from vehicle historical parameter values; and

[0087] · Settings of predefined autonomous driving events of the vehicle.

[0088] Another type of discontinuous time impact parameter is location related parameters. Examples of such location related parameters can be, for example:

[0089] · Location of the vehicle;

[0090] · The vehicle is outside cellular coverage; and

[0091] · The vehicle has lost GPS coverage.

[0092] The location of the vehicle can be used in different ways. For example, the location can be combined with historical parameters to identify locations where the vehicle typically stays for a period of time. Such locations can thus also be useful, for example, to identify locations on a map, such as parked at an airport for a long time.

[0093] Yet another type of discontinuous time impact parameter is energy related parameters. Examples of such energy related parameters can be, for example:

[0094] · The vehicle is an electric vehicle and connected to a charging system; and

[0095] · The temperature at the vehicle location.

[0096] Based on the available discontinuity time impact parameters, different considerations regarding the extended discontinuous reception time T eDRX can be adopted. Certain values of the discontinuity time impact parameters can indicate expected long periods of inactivity, while other values or other discontinuity time impact parameters can indicate expected short periods of inactivity. Combinations of more than one parameter can also provide additional information. Non-exclusive examples can be combinations of location and time, combinations of location and historical information, combinations of temperature and time, etc. Algorithms for determining the appropriate extended discontinuous reception time can be designed in many different ways depending on the available parameters.

[0097] Some non-exclusive examples of considerations for algorithms that can be adopted to determine T eDRX are shown below to provide some understanding of the possibilities given.

[0098] · A larger T eDRX can be given at night. The probability that a driver accesses a connected vehicle at night is low.

[0099] · A smaller T eDRX can be given at low outdoor temperatures. The likelihood that a driver wishes to remotely turn on the heating equipment of a connected vehicle is high. If different types of conditions are combined, the outdoor temperature can be combined with time, for example, near dawn, or additionally based on history, for example, one hour before the vehicle normally starts.

[0100] · Based on historical and location data, T eDRX can be renegotiated at certain times of the day (or a certain day of the week or a certain season of the year). For example, T eDRX can be renegotiated to a smaller value close to when historical and location data indicate that it may be the start or end of a working day.

[0101] · Based on location, a large T eDRX can be given, for example, if the vehicle is parked in a long-term parking lot.

[0102] · Based on a combination of location and historical usage, if the vehicle is parked in a special parking lot, T eDRX can be set, for example, equal to the last parking time or the average parking time.

[0103] · A smaller T eDRX can be given when the vehicle is charging. In this case, the driver may want to remotely check the charging status. Additionally, when the vehicle is connected to the power grid, power consumption is less important.

[0104] Also as shown in step S6, the TCU uses the determined T eDRX to request and manage entry into the eDRX mode.

[0105] Typically, the TCU 40 initiates an eDRX mode request to the cellular network for a requested sleep time (eDRX). Preferably, the TCU uses a Tracking Area (TA) update request procedure. The cellular network responds with an acceptance request, preferably using a Tracking Area Update Accept procedure.

[0106] The TCU 40 then manages the transition of the TCU to the eDRX mode. In the case of loss of cellular coverage, additional power savings can be achieved by turning off the cellular modem, i.e., the idea of not spending power to search for a cell in that location. In this case, the modem part notifies the TCU of the coverage loss, and then the TCU commands the modem to stop scanning for cellular coverage. When the vehicle system notifies the TCU that the vehicle is moving, the TCU instructs the UE modem to continue scanning for cellular coverage.

[0107] If the GPS signal is lost, a similar process can be performed. That is to say, the search for the GPS signal at the current location is paused and resumed when the vehicle moves again.

[0108] In a particular embodiment, preferably there should be information from the TCU to the internal vehicle system indicating that the vehicle system should not expect to be contacted by the server during the sleep time so that the protocols in the vehicle can adapt to this. In other words, uplink (UL) traffic, such as periodic registration, etc., also needs to be stopped or paused. UL traffic attempts can also be rejected or stopped or blocked by the TCU, or by other SW or devices that control the network connection.

[0109] Furthermore, preferably, the OEM application server should be notified that the vehicle will enter the sleep mode and will not initiate contact or be unreachable for a certain period of time, i.e., so that the application can adjust its expectations regarding re-registration, etc.

[0110] In a particular embodiment, the timer T 评估 is preferably used to regularly or intermittently re-evaluate the T eDRX value during the extended discontinuous reception mode. Therefore, in step S7, the T 评估 timer is started. When the T 评估 timer expires, as shown in step S8, the process returns to step S6, where the T eDRX value can be re-evaluated. The conditions for determining the T eDRX may have changed. For example, the temperature may have changed quite significantly, so the T eDRXAnother way of the value may be beneficial. This evaluation possibility may also be enabled, for example, so that re-negotiation can be carried out when the system assumes that the end of the working day is approaching for T eDRX to be re-negotiated. Many other scenarios where re-negotiation of T eDRX may be beneficial are also possible. The parameter T 评估 should be chosen long enough so as not to affect the power consumption to any significant extent, but also short enough so that the changing conditions can be recalculated.

[0111] The parameter T 评估 can also be set differently according to different conditions. As a non-exclusive example, if the seasons of the year are expected to have large temperature fluctuations, for example, the parameter T 评估 can be set shorter in the evening to detect any such temperature fluctuations.

[0112] The presence of the discontinuity stop condition regarding the vehicle constitutes a second trigger, as shown in step S9 of Figure 3 This is similar to the stop of the hysteresis time discussed above.

[0113] If such a second trigger is obtained or if the extended discontinuous reception time expires, the extended discontinuous reception mode is exited in step S10.

[0114] Figure 4 is a schematic flow chart showing an embodiment of a method for controlling a TCU. In step S11, information indicating the condition that the extended discontinuous reception mode would be beneficial to the TCU is obtained. Thus, the condition can be expressed as a discontinuity beneficial condition. The discontinuity beneficial condition is associated with the vehicle to which the TCU is connected. This is generally carried out in cooperation with the vehicle control system. In other words, the step of obtaining the information of the discontinuity beneficial condition preferably includes communicating with the vehicle internal system. These conditions are associated with the expected vehicle inactivity time or the expected shortage of stored power. In other words, the discontinuity beneficial condition preferably includes at least one of the following: vehicle inactivity condition, personnel absence condition, energy condition, and time condition. Non-exclusive examples are the state condition of the engine, the state condition of the vehicle lock, or the absence of any driver. Other examples are given further above.

[0115] In a particular embodiment, in step S12, information useful for eDRX time determination is collected. This information typically includes location information, especially related to coverage information, time information such as time of day or day of the week, ambient conditions such as temperature, and collection related to historical use of the eDRX mode or historical use of the vehicle, as described in the previous discussion and examples. Such information can be accessed through different kinds of communication, for example, by interacting with the vehicle control system, positioning process, or obtained from stored data in, for example, an OEM application or other applications with which the TCU can communicate.

[0116] In step S13, a determination of the extended discontinuous reception time for the TCU is obtained.

[0117] In a particular embodiment, this obtaining the determination includes performing the determination, fully or in part, by the TCU. In this alternative, obtaining the determination of the extended discontinuous reception time thus includes receiving data of discontinuity time impact parameters. These discontinuity time impact parameters are received from an application server providing vehicle services to the vehicle, the vehicle's in-vehicle system, a C-ITS node, positioning satellites, and / or a wireless communication network. Then, based on the received data of the discontinuity time impact parameters, the determination of the extended discontinuous reception time is performed. This is preferably combined with the execution of step S12.

[0118] In another particular embodiment, this obtaining the determination includes requesting the determination of the extended discontinuous reception time from an external node, such as to an OEM application or other applications. Obtaining the determination also includes receiving the determination. In other words, in this alternative, the determination of the extended discontinuous reception time includes receiving the determined extended discontinuous reception time from an application server providing vehicle services to the vehicle, the vehicle's in-vehicle system, a C-ITS node, positioning satellites, or a wireless communication network.

[0119] The extended discontinuous reception time should be determined for optimizing the use of the extended discontinuous reception function. The requested time should be an "intelligent" estimate of the expected vehicle inactivity time and / or important communication to / from the vehicle. In most typical cases, a combination of location-related information and the collected historical parameter values can also be combined with time information. When the vehicle is parked outside a lunch restaurant, a suitable extended discontinuous reception time should be shorter than when the vehicle is parked outside a residence at night. By using historical information specific to each vehicle, the regular movement of the vehicle can be tracked and a suitable extended discontinuous reception time can be recommended.

[0120] In a particular embodiment, information about the vehicle that may be useful to the user is provided S14 to, for example, an application server. The application server is typically an OEM server that provides vehicle services to the vehicle. Thus, this information becomes available regardless of any eDRX mode. For example, information from the application server may also be provided to the TCU to assist in transitioning to the eDRX mode.

[0121] Thus, in one embodiment there is a further step S14, in which, before requesting the extended discontinuous reception mode, or at least before implementing such a request, information about the status of the vehicle is exchanged with the application in the application server. The application server is typically an OEM server that provides vehicle services to the vehicle.

[0122] In step S15, a request for the extended discontinuous reception mode for the TCU is made, suggesting the determined extended discontinuous reception time. Such a request is known in the prior art. The request may be initiated by the TCU and executed by the TCU itself or another node. The initiation of the request is in response to the obtained discontinuity beneficial conditions, as further discussed above.

[0123] In step S16, acceptance of the extended discontinuous reception mode is received.

[0124] In step S17, the TCU's transition to the extended discontinuous reception mode is managed. Such management is known in the prior art. The management may include shutting down communication with different communication systems. The management may also include non-communication transmissions, which rely on the communication system to automatically arrange for the suddenly lost TCU. In other words, if the TCU shuts down its communication without notifying the communication system, the communication system can conclude that the TCU has shut down its communication anyway after noticing that the TCU is not providing any signaling.

[0125] In embodiments involving an interruption of the eDRX mode or during the duration of the latency in initiating the process, step S18 may be performed, in which vehicle conditions that require an earlier end to the eDRX mode are obtained. This is typically performed in cooperation with the vehicle control system. These conditions are associated with the expected activities of the vehicle. Non-exclusive examples are the state conditions of the engine, the state conditions of the vehicle locks, or the presence of any driver. Further examples are discussed above in connection with Figure 3 Further examples are discussed further.

[0126] In a particular embodiment, step S19 includes managing the transition out of the eDRX mode. Such management is known in the prior art. The management may include finding an open communication with different communication systems.

[0127] Figure 3 and Figure 4The flowcharts are different views of essentially the same tasks. Thus, there are connections or similarities between different steps. Step S1 and S11 are essentially corresponding steps, and so are steps S5 and S14. Step S6 is a common step for activities involving, for example, S12, S13, S15, S16, and S17. Step S9 and S18 are essentially corresponding steps, and so are steps S10 and S19.

[0128] The proposed technology can be applied to user terminals, which can be wired or wireless devices.

[0129] The non - restrictive terms “Telematics Control Unit (TCU)”, “Telematics Module (TEM)”, “On - Board Unit (OBU)”, “User Equipment (UE)”, “Station (STA)”, and “Wireless Communication Device” used herein can refer to mobile phones, cellular phones, personal digital assistants (PDAs) equipped with radio communication capabilities, smart phones, laptop computers or personal computers (PCs) equipped with internal or external mobile broadband modems, tablet PCs with radio communication capabilities, target devices, device - to - device UEs, machine - type UEs or UEs capable of machine - to - machine communication, iPads, customer - premise equipment (CPEs), laptop - embedded devices (LEEs), laptop - mounted devices (LMEs), universal serial bus (USB) dongles, portable electronic radio communication devices, sensor devices equipped with radio communication capabilities, etc. In particular, the terms “UE”, the term “Station”, and the term “Wireless Communication Device” shall be interpreted as non - restrictive terms that include any type of wireless device that communicates with network nodes in a wireless communication system and / or can directly communicate with another wireless communication device. In other words, a wireless communication device can be any device equipped with circuitry for wireless communication according to any relevant communication standard.

[0130] The term “wired device” used herein can refer to any device configured or ready for a wired connection to a network. In particular, when configured for a wired connection, a wired device can be at least some of the above - mentioned devices with or without radio communication capabilities.

[0131] The non - restrictive term "network node" as used herein can refer to a base station, an access point, network control nodes such as a network controller, a radio network controller, a base station controller, an access controller, etc. In particular, the term "base station" can cover different types of radio base stations, including standardized base stations such as Node B, or evolved Node B (eNB), and macro / micro / pico radio base stations, also known as femto base stations or home base stations, relay nodes, repeaters, radio access points, base transceiver stations (BTS), and even radio control nodes that control one or more remote radio units (RRU), etc.

[0132] Hereinafter, the general non - restrictive term "communication unit" includes network nodes and / or associated wireless devices.

[0133] The term "network device" as used herein can refer to any device located in connection with a communication network, including but not limited to devices in an access network, a core network, and similar network architectures. The term network device can also cover cloud - based network devices.

[0134] It should be understood that the methods and devices described herein can be combined and rearranged in various ways.

[0135] For example, an embodiment can be implemented in hardware, or implemented in software for execution by a suitable processing circuit, or implemented using a combination of hardware and software.

[0136] The steps, functions, processes, modules, and / or blocks described herein can be implemented in hardware using any conventional technology, such as discrete circuit or integrated circuit technology, including general - purpose electronic circuits and special - purpose circuits.

[0137] Alternatively or in addition, at least some of the steps, functions, processes, modules, and / or blocks described herein can be implemented using software such as a computer program for execution by a suitable processing circuit such as one or more processors or processing units.

[0138] Examples of processing circuits include but are not limited to one or more microprocessors, one or more digital signal processors (DSP), one or more central processing units (CPU), video acceleration hardware, and / or any suitable programmable logic circuit, such as one or more field - programmable gate arrays (FPGA), or one or more programmable logic controllers (PLC).

[0139] It should also be understood that the general - purpose processing capabilities of any conventional device or unit implementing the proposed technology can be reused. Existing software can also be reused, for example, by reprogramming existing software or adding new software components.

[0140] According to one aspect of the proposed technology, a TCU is provided, wherein the TCU is configured to obtain information about conditions associated with the vehicle to which the TCU is connected, which indicates that the extended discontinuous reception mode is beneficial for the TCU. The TCU is further configured to obtain a determination of the extended discontinuous reception time for the TCU. The TCU is further configured to request the extended discontinuous reception mode for the TCU, suggesting the determined extended discontinuous reception time. The TCU is further configured to receive acceptance of the extended discontinuous reception mode. The TCU is further configured to manage the TCU's transition to the extended discontinuous reception mode.

[0141] Figure 5 FIG. 4 is a schematic block diagram of an embodiment of TCU 40. TCU 40 includes a modem 41, which in turn has a transmitter 42 and a receiver 43 for wireless communication with different networks via an antenna 47. A vehicle status section 45 is in communication with the main vehicle control section. The vehicle status section 45 is configured to obtain information about conditions associated with the vehicle to which the TCU is connected, which indicates that the eDRX mode is beneficial for the TCU. TCU 40 may be implemented as a separate unit or may be implemented as an integrated part of a vehicle control system. An eDRX manager 44 is connected to the modem 41 and the vehicle status section 45 and is configured to request the eDRX mode, receive acceptance of the eDRX mode, and manage the TCU's transition to the eDRX mode. In a particular embodiment, the eDRX manager 44 may at least partially participate in the determination of the eDRX mode time for the TCU. The eDRX manager 44 optionally includes a clock 48 to track the time of the eDRX mode.

[0142] In one embodiment, the TCU is preferably configured to be operable to cooperate with a cooperative intelligent transportation system. The TCU is configured to obtain information about discontinuous reception beneficial conditions associated with the vehicle to which the TCU is connected. The discontinuous reception beneficial conditions indicate that the extended discontinuous reception mode is beneficial for the TCU. The TCU is further configured to obtain a determination of the extended discontinuous reception time for the TCU. The TCU is further configured to, in response to the obtained discontinuous reception beneficial conditions, initiate a request for the extended discontinuous reception mode for the TCU, suggesting the determined extended discontinuous reception time.

[0143] Figure 6FIG. 0 is a schematic block diagram showing an example of a processor-memory implemented TCU 40 according to an embodiment. In this particular example, TCU 40 includes a processor 110 and a memory 120, and the memory 120 includes instructions executable by the processor 110. Thereby, the processor is operable to obtain information about conditions associated with a vehicle to which the TCU is connected, which indicates that an extended discontinuous reception mode is beneficial for the TCU. The processor is also operable to obtain a determination of an extended discontinuous reception time for the TCU.

[0144] In one embodiment, the processor is also operable to initiate a request for the extended discontinuous reception mode.

[0145] In one embodiment, the processor is also operable to request an extended discontinuous reception mode for the TCU, suggesting the determined extended discontinuous reception time.

[0146] In another embodiment, the processor is also operable to receive an acceptance of the extended discontinuous reception mode. The processor is also operable to manage the TCU's transition to the extended discontinuous reception mode.

[0147] TCU 40 may also include a communication circuit 130. The communication circuit 130 may include functions for wired and / or wireless communication with other devices and / or network nodes in a network. In a particular example, the communication circuit 130 may be based on a radio circuit for communicating with one or more other nodes, including transmitting and / or receiving information. The communication circuit 130 may be interconnected with the processor 110 and / or the memory 120. By way of example, the communication circuit 130 may include any one of the following: a receiver, a transmitter, a transceiver, an input / output (I / O) circuit, an input port, and / or an output port.

[0148] In different embodiments, the TCU may include a communication circuit configured to perform at least one of the following:

[0149] Communicate with in-vehicle systems;

[0150] Communicate with at least one of an application server providing vehicle services to the vehicle, the vehicle's in-vehicle systems, and C-ITS nodes, receive information from positioning satellites, and use a wireless communication network;

[0151] Receive the determined extended discontinuous reception time from one of an in-vehicle system, a C-ITS node, a positioning satellite, and a wireless communication network;

[0152] Receive data of discontinuity time impact parameters from at least one of an application server providing vehicle services to the vehicle, the vehicle's in-vehicle systems, C-ITS nodes, positioning satellites, and a wireless communication network;

[0153] Receiving acceptance of an extended discontinuous reception mode; and

[0154] Exchanging information regarding the status of the vehicle with an application server that provides vehicle services to the vehicle.

[0155] Figure 7 FIG. 8 is a schematic block diagram showing another example of the TCU 40 implemented based on a hardware circuit according to an embodiment. Specific examples of suitable hardware (HW) circuits include one or more appropriately configured or possibly reconfigurable electronic circuits, such as application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other hardware logic, such as a circuit based on discrete logic gates and / or flip-flops, interconnected to perform a dedicated function associated with suitable registers (REG) and / or memory units (MEM).

[0156] Figure 8 FIG. 9 is a schematic block diagram showing yet another example of the TCU 40, which is based on a combination of processors 310-1, 310-2 and hardware circuits 330-1, 330-2 connected to a suitable memory unit 320. The apparatus 300 includes one or more processors 310-1, 310-2, a memory 320 including storage for software and data, and one or more units of hardware circuits 330-1, 330-2 such as ASICs and / or FPGAs. Thus, the overall functionality is split between programming software (SW) for execution on one or more processors 310-1, 310-2 and one or more pre-configured or possibly reconfigurable hardware circuits 330-1, 330-2 such as ASICs and / or FPGAs. The actual hardware-software split may be determined by the system designer based on multiple factors including processing speed, implementation cost, and other requirements.

[0157] Alternatively or in addition, at least some of the steps, functions, processes, modules, and / or blocks described herein may be implemented in software such as a computer program to be executed by a suitable processing circuit such as one or more processors or processing units.

[0158] Thus, when executed by one or more processors, the flowcharts shown herein may be regarded as computer flowcharts. The corresponding apparatus may be defined as a group of functional modules, where each step executed by the processor corresponds to a functional module. In this case, the functional module is implemented as a computer program running on the processor.

[0159] Examples of processing circuitry include, but are not limited to, one or more microprocessors, one or more digital signal processors (DSPs), one or more central processing units (CPUs), video acceleration hardware, and / or any suitable programmable logic circuitry, such as one or more field programmable gate arrays (FPGAs), or one or more programmable logic controllers (PLCs).

[0160] It should also be understood that the general processing capabilities of any conventional device or unit implementing the proposed technology can be reused. Existing software can also be reused, for example, by reprogramming existing software or adding new software components.

[0161] Figure 9 FIG. is a schematic diagram showing an example of a computer implementation 40 according to an embodiment. In this particular example, at least some of the steps, functions, processes, modules, and / or blocks described herein are implemented by computer programs 425, 435 that are loaded into a memory 420 to be executed by a processing circuitry including one or more processors 410. The processor 410 and the memory 420 are interconnected with each other to enable normal software execution. Optional input / output devices 440 can also be interconnected with the processor 410 and / or the memory 420 to enable the input and / or output of relevant data such as input parameters and / or result output parameters.

[0162] In a general sense, the term "processor" should be construed as any system or device capable of executing program code or computer program instructions to perform a specific processing, determination, or computational task.

[0163] Thus, the processing circuitry including one or more processors 410 is configured to perform well-defined processing tasks when executing the computer program 425, such as those described herein.

[0164] The processing circuitry is not dedicated to only performing the above steps, functions, processes, and / or blocks, but can also perform other tasks.

[0165] In a particular embodiment, the computer programs 425, 435 include instructions that, when executed by at least one processor 410, cause the processor 410 to: obtain information about conditions associated with a vehicle to which the TCU is connected, which indicates that an extended discontinuous reception mode is beneficial for the TCU; obtain a determination of an extended discontinuous reception time for the TCU; request an extended discontinuous reception mode for the TCU, suggesting the determined extended discontinuous reception time; receive acceptance of the extended discontinuous reception mode; and manage the TCU to transition to the extended discontinuous reception mode.

[0166] In a particular embodiment, a computer program comprises instructions which, when executed by at least one processor, cause the processor to: obtain information about conditions associated with a vehicle to which the TCU is connected, which indicates that an extended discontinuous reception mode is beneficial for the TCU; obtain a determination of an extended discontinuous reception time for the TCU; request an extended discontinuous reception mode for the TCU, suggesting the determined extended discontinuous reception time; receive acceptance of the extended discontinuous reception mode; and manage the TCU to transition to the extended discontinuous reception mode.

[0167] The proposed technique also provides a carrier comprising a computer program, wherein the carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable storage medium.

[0168] As an example, software or computer programs 425, 435 may be implemented as computer program products, which are typically carried or stored on computer-readable media 420, 430, particularly non-volatile media. The computer-readable media may include one or more removable or non-removable memory devices, including but not limited to read-only memory (ROM), random access memory (RAM), compact disc (CD), digital versatile disc (DVD), Blu-ray disc, universal serial bus (USB) memory, hard disk drive (HDD) storage devices, flash memory, magnetic tape, or any other conventional memory device. Thus, the computer program may be loaded into the operating memory of a computer or equivalent processing device for execution by processing circuitry therein.

[0169] Figure 10 is a schematic block diagram showing an example of a vehicle 4 including a TCU 40 according to any embodiment.

[0170] According to one aspect, a network device comprising a TCU 40 as described herein is provided.

[0171] The network device may be any suitable network device in a wireless communication system or a network device associated with a wireless communication system. By way of example, the network device may be a suitable network node such as a base station or an access point. However, the network device may alternatively be a cloud-implemented network device.

[0172] According to another aspect, a communication unit in a wireless communication system is provided, wherein the communication unit comprises a TCU 40 as described herein. The communication unit may be any suitable communication unit in a wireless communication system. As an example, the communication unit may be a wireless communication device such as a UE, an STA, or a similar end-user device.

[0173] When executed by one or more processors, the flowcharts shown herein can be regarded as computer flowcharts. The corresponding apparatus can be defined as a group of functional modules, where each step executed by the processor corresponds to a functional module. In this case, the functional modules are implemented as computer programs running on the processor.

[0174] Therefore, the computer programs residing in the memory can be organized into appropriate functional modules, which are configured to perform at least a part of the steps and / or tasks described herein when executed by the processor.

[0175] Figure 11 FIG. is a schematic diagram showing an example of a TCU 40, which is preferably used in cooperation with an OEM application and a cellular network. The TCU 40 includes a vehicle condition module 500, which is used to obtain information about the conditions associated with the vehicle to which the TCU is connected, and which indicates that the extended discontinuous reception mode is beneficial for the TCU. The TCU 40 also includes an eDRX time determination module 510, which is used to obtain a determination of the extended discontinuous reception time for the TCU. The TCU 40 also includes a transmitter 520, which is used to initiate a request for the extended discontinuous reception mode for the TCU, suggesting the determined extended discontinuous reception time. The TCU 40 preferably also includes a receiver 530, which is used to receive an acceptance of the extended discontinuous reception mode. The TCU 40 preferably also includes an eDRX management module 540, which is used to manage the transfer of the TCU to the extended discontinuous reception mode.

[0176] In one embodiment, the TCU includes a condition acquisition module, which is used to obtain information about the discontinuity conditions associated with the vehicle to which the TCU is connected. The discontinuity beneficial condition indicates that the extended discontinuous reception mode is beneficial for the TCU. The TCU also includes a time determination acquisition module, which is used to obtain a determination of the extended discontinuous reception time for the TCU. The TCU also includes an initiator, which is used to initiate a request for the extended discontinuous reception mode for the TCU, suggesting the determined extended discontinuous reception time, in response to the obtained discontinuity beneficial condition.

[0177] Alternatively, it can be implemented mainly through hardware modules, or alternatively through software Figure 11 for the modules in, with appropriate interconnections between the relevant modules. Specific examples include one or more appropriately configured digital signal processors and other known electronic circuits, for example, discrete logic gates with the aforementioned interconnections to perform dedicated functions, and / or application specific integrated circuits (ASICs). Other examples of available hardware include input / output (I / O) circuits and / or circuits for receiving and / or transmitting signals. The scope of software and hardware is only a matter of implementation choice.

[0178] It has become increasingly popular to provide computing services (hardware and / or software) in network devices such as network nodes and / or servers, where resources are delivered as services over the network to remote locations. For example, this means that functions as described herein can be distributed or relocated to one or more separate physical nodes or servers. Functions can be relocated or distributed to one or more physical machines and / or virtual machines that act jointly, and these physical machines and / or virtual machines can be located in separate physical nodes, i.e., in the so-called cloud. This is sometimes also referred to as cloud computing, which is a model for enabling ubiquitous, on-demand network access to a pool of configurable computing resources such as networks, servers, storage devices, applications, and general-purpose or custom services.

[0179] Virtualization in different forms is useful in this context, including one or more of the following:

[0180] Integrating network functions into virtualization software running on custom or general-purpose hardware. This is sometimes referred to as network function virtualization.

[0181] Co-locating one or more application stacks including an operating system that run on separate hardware onto a single hardware platform. This is sometimes referred to as system virtualization or platform virtualization.

[0182] Co-locating hardware and / or software resources with the aim of increasing system resource utilization using some advanced domain-level scheduling and coordination techniques. This is sometimes referred to as resource virtualization, or centralized and coordinated resource pooling.

[0183] Although it is generally desirable to centralize functions in a so-called general data center, in practice it may be beneficial to distribute functions over different parts of the network in other scenarios.

[0184] Figure 12 It is a schematic diagram showing an example of how functions are distributed or split between different network devices in general. In this example, there are at least two separate but interconnected network devices ND1 and ND2, which have reference numerals 610 and 620 respectively, and may have different functions or parts of the same function split between network device 610 and network device 620. There may be an additional network device such as ND3, which has reference numeral 630 and is part of such a distributed implementation. Network devices 610 - 630 can be part of the same wireless communication system, or one or more of these network devices can be so-called cloud-based network devices located outside the wireless communication system.

[0185] Figure 13FIG. is a schematic diagram showing an example of a wireless communication system including an access network 710 and / or a core network 720 and / or an operation and support system (OSS) 730 that cooperate with one or more cloud-based network devices. Functions related to the access network 710 and / or the core network 720 and / or the OSS system 730 can be implemented at least in part for execution in a cloud-based network device 740, with appropriate information transfer between the cloud-based network device and relevant network nodes and / or communication units in the access network and / or the core network and / or the OSS system.

[0186] A network device (ND) can generally be regarded as an electronic device communicatively connected to other electronic devices in a network.

[0187] For example, a network device can be implemented using hardware, software, or a combination thereof. For instance, a network device can be a dedicated network device or a general-purpose network device, or a hybrid thereof.

[0188] A dedicated network device can use custom processing circuitry and a proprietary operating system (OS) to execute software to provide one or more features or functions disclosed herein.

[0189] A general-purpose network device can use general off-the-shelf (COTS) processors and a standard OS to execute software configured to provide one or more features or functions disclosed herein.

[0190] For example, a dedicated network device can include hardware that includes processing or computing resources, typically including a set of one or more processors and physical network interfaces (NIs) sometimes referred to as physical ports, and a non-transitory machine-readable storage medium on which software is stored. The physical NI can be regarded as the hardware in the network device through which network connections are made, e.g., wirelessly through a wireless network interface controller (WNIC), or by plugging a cable into a physical port connected to a network interface controller (NIC). During operation, the software can be executed by the hardware to instantiate a set of one or more software instances. Each of the software instances and the hardware portion that executes the software instance can form a separate virtual network unit.

[0191] As another example, a general network device may include, for example, hardware that includes a set of one or more processors, typically COTS processors, a network interface controller (NIC), and a non-transitory machine-readable storage medium on which software is stored. During operation, the processors execute the software to instantiate one or more sets of one or more applications. While one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization—for example, represented by a virtualization layer and software containers. For example, one such alternative embodiment implements operating system-level virtualization, in which case the virtualization layer represents the kernel of the operating system (or a shim executing on top of the underlying operating system), which allows the creation of multiple software containers, each of which can be used to execute one of a set of applications. In an exemplary embodiment, each software container (also referred to as a virtualization engine, virtual private server, or jail) is a user-space instance (typically a virtual memory space). These user-space instances can be separated from each other and from the kernel space in which the operating system executes, and a set of applications running in a given user space cannot access the memory of other processes unless explicitly permitted. Another such alternative embodiment implements full virtualization, in which case: 1) the virtualization layer represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or the hypervisor executes on top of the host operating system; 2) each software container represents a form of tightly isolated software container referred to as a virtual machine executed by the hypervisor and may include a guest operating system.

[0192] A hypervisor is software / hardware responsible for creating and managing various virtualization instances and, in some cases, for creating and managing the actual physical hardware. The hypervisor manages the underlying resources and presents them as virtualization instances. A single processor virtualized by the hypervisor to be presented may actually include multiple separate processors. From the perspective of the operating system, the virtualization instances appear as actual hardware components.

[0193] A virtual machine is a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine, and while some systems provide para-virtualization that allows the operating system or application to be aware of the presence of virtualization for optimization purposes, applications generally do not know that they are running on a virtual machine rather than on a "bare metal" host electronic device.

[0194] The instantiation of one or more sets of one or more implemented applications, along with the virtualization layer and software containers, is collectively referred to as a software instance. Each set of applications, the corresponding implemented software container, and the hardware portion that executes them (the hardware dedicated to that execution and / or the time slice of hardware temporarily shared by the software container) form separate virtual network units.

[0195] A virtual network unit can perform functions similar to those of a virtual network element (VNE). This hardware virtualization is sometimes referred to as network function virtualization (NFV). Thus, NFV can be used to consolidate many network device types onto industrial standard high-volume server hardware, physical switches, and physical storage devices that can be located in a data center, ND, and customer premise equipment (CPE). However, different embodiments can implement one or more software containers differently. For example, while embodiments illustrate each software container corresponding to a VNE, alternative embodiments can implement this correspondence or mapping between software containers and VNEs at a finer granularity level. It should be understood that the techniques described herein with reference to the correspondence between software containers and VNEs also apply to embodiments using this finer granularity level.

[0196] According to yet another embodiment, a hybrid network device is provided that includes both a customized processing circuit / proprietary OS and a COTS processor / standard OS in a card or circuit board within the network device, such as within the network device ND. In certain embodiments of such a hybrid network device, a platform VM, such as a virtual machine (VM) that implements the functions of a dedicated network device, can provide para-virtualization for the hardware present in the hybrid network device.

[0197] The embodiments described above are given only as examples, and it should be understood that the proposed techniques are not limited thereto. Those skilled in the art will understand that various modifications, combinations, and changes can be made to the embodiments without departing from the scope of the invention defined by the appended claims. In particular, where technically feasible, different partial solutions in different embodiments can be combined in other configurations.

[0198] Acronyms

[0199] 3GPP Third Generation Partnership Project

[0200] ASIC Application Specific Integrated Circuit

[0201] BTS Base Transceiver Station

[0202] CD Compact Disc

[0203] C-ITS Cooperative Intelligent Transport System

[0204] CONVERGE Communication Networks Vehicle Road Global Expansion

[0205] COTS Commercial Off-The-Shelf

[0206] CPE Customer Premise Equipment

[0207] CPU Central Processing Unit

[0208] DSP Digital Signal Processor

[0209] DSRC Dedicated Short Range Communication

[0210] DVD Digital Versatile Disc

[0211] eDRX Extended Discontinuous Reception

[0212] eNB Evolved Node B

[0213] FPGA Field Programmable Gate Array

[0214] GNSS Global Navigation Satellite System

[0215] GPS Global Positioning System

[0216] HDD Hard Disk Drive

[0217] HW Hardware

[0218] ICT Information and Communication Technology

[0219] I / O Input / Output

[0220] ITS Intelligent Transport System

[0221] LEE Laptop Embedded Equipment

[0222] LME Laptop Mounted Equipment

[0223] LTE Long Term Evolution

[0224] MEM Memory Unit

[0225] ND Network Device

[0226] NFV Network Function Virtualization

[0227] NI Network Interface

[0228] NIC Network Interface Controller

[0229] OBD II On-Board Diagnostic II

[0230] OBU On-Board Unit

[0231] OEM Original Equipment Manufacturer

[0232] OS Operating System

[0233] OSS Operation and Support System

[0234] PC Personal Computer

[0235] PDA Personal Digital Assistant

[0236] PLC Programmable Logic Controller

[0237] RAM Random Access Memory

[0238] REG Register

[0239] ROM Read-Only Memory

[0240] RRU Remote Radio Unit

[0241] RSU Road Side Unit

[0242] STA Station

[0243] SW Software

[0244] TA Tracking Area

[0245] TCU Telematics Control Unit

[0246] TEM Telematics Module

[0247] UE User Equipment

[0248] UL Uplink

[0249] USB Universal Serial Bus

[0250] V2I Vehicle-to-Infrastructure

[0251] V2N Vehicle-to-Network

[0252] V2P Vehicle-to-Pedestrian

[0253] V2V Vehicle-to-Vehicle

[0254] V2X Vehicle-to-Everything

[0255] VM Virtual Machine

[0256] VMM Virtual Machine Monitor

[0257] VNE Virtual Network Element

[0258] WNIC Wireless Network Interface Controller

Claims

1. A vehicle, comprising a processor and a memory, the memory storing instructions executable by the processor, whereby the vehicle is operable to: Obtain information on a discontinuity beneficial condition associated with the vehicle, The discontinuity beneficial condition indicating that an extended discontinuous reception mode is beneficial for the telematics control unit; Obtain a determination of an extended discontinuous reception time for the telematics control unit; and In response to the obtained discontinuity beneficial condition, initiate a request for an extended discontinuous reception mode for the telematics control unit, suggesting the determined extended discontinuous reception time.

2. The vehicle according to claim 1, wherein, The vehicle includes a vehicle control system and the telematics control unit.

3. The vehicle according to claim 1, wherein, The vehicle is operable to obtain the information on the discontinuity beneficial condition by: communicating with an in-vehicle system.

4. The vehicle according to claim 1, wherein, The discontinuity beneficial condition includes at least one of the following: a vehicle inactivity condition, a person absence condition, an energy condition, a time condition, and a location condition.

5. The vehicle according to claim 4, wherein, The vehicle inactivity condition includes at least one of the following: The engine of the vehicle is turned off; The ignition of the vehicle is turned off; and The in-vehicle system indicates that the vehicle will enter an energy-saving mode or a deeper sleep in terms of communication with the network; And / or Wherein, the person absence condition includes at least one of the following: The vehicle is locked from the outside; The vehicle's keyless system does not sense a key within range; The vehicle's seat sensor indicates that no one is sitting in the vehicle or the driver's seat of the vehicle; and / or Wherein, the energy condition includes: an indication of a low battery voltage in the vehicle; and / or Wherein, the time condition includes: a time within a predetermined range during the day; and / or Wherein, the location condition includes: the location of the vehicle.

6. The vehicle according to claim 1, wherein, The vehicle is further operable to: execute the initiation of the request for the extended discontinuous reception mode after a hysteresis time has expired, the hysteresis time starting from when the information on the discontinuity beneficial condition is obtained.

7. The vehicle according to claim 1, wherein, The vehicle is operable to obtain the determination of the extended discontinuous reception time by: Communicating with at least one of the following: an application server providing vehicle services to the vehicle, the vehicle's in-vehicle system, a cooperative intelligent transportation system node; Receiving information from positioning satellites; and Using a wireless communication network.

8. The vehicle according to claim 7, wherein, The vehicle is operable to obtain the determination of the extended discontinuous reception time by: receiving the determined extended discontinuous reception time.

9. The vehicle according to claim 8, wherein, The determination of the extended discontinuous reception time is based on data of discontinuity time impact parameters.

10. The vehicle according to claim 7, wherein, The vehicle is operable to obtain the determination of the extended discontinuous reception time by: Receiving data of discontinuity time impact parameters from at least one of the following: the application server providing vehicle services to the vehicle, the vehicle's in-vehicle system, the cooperative intelligent transportation system node, the positioning satellites, and the wireless communication network; And Based on the data of the received discontinuous time impact parameter, the determination of the extended discontinuous reception time is performed.

11. The vehicle according to claim 9, wherein, The discontinuous time impact parameter includes at least one of the following: a time and history related parameter, a location related parameter, and an energy related parameter.

12. The vehicle according to claim 11, wherein, The time and history related parameter includes at least one of the following: Time of day; Day of the week; Annual season; Pattern of historical parameter values from the vehicle; and Settings of a predetermined autonomous driving event of the vehicle; and / or Wherein, the location related parameter includes at least one of the following: Location of the vehicle; The vehicle is outside cellular coverage; and The vehicle has no GPS coverage; and / or Wherein, the energy related parameter includes at least one of the following: The vehicle is an electric vehicle and is connected to a charging system; and Temperature at the location of the vehicle.

13. The vehicle according to claim 1, wherein, The vehicle is further operable to: during the extended discontinuous reception mode, re-evaluate the extended discontinuous reception time.

14. The vehicle according to claim 1, wherein, The vehicle is further operable to: receive acceptance of the extended discontinuous reception mode; and Manage the transfer of the telematics control unit to the extended discontinuous reception mode.

15. The vehicle according to claim 1, wherein, The vehicle is further operable to: in response to detecting a discontinuity stop condition, interrupt the hysteresis or discontinuity process.

16. The vehicle according to claim 15, wherein, The discontinuity stop condition includes at least one of the following: a vehicle activity condition, a person presence condition, an energy condition, and a time condition.

17. The vehicle according to claim 16, wherein, The vehicle activity condition includes at least one of the following: The ignition device of the vehicle is started; The engine of the vehicle is started; The autonomous driving function of the vehicle is activated; and / or Wherein, the person presence condition includes at least one of the following: The keyless system of the vehicle indicates that the key is within range; The vehicle is unlocked; and The seat sensor of the vehicle indicates that someone is in the vehicle; and / or Wherein, in the case where the vehicle is an electric vehicle, the energy condition includes: an indication that the electric vehicle is being recharged; and / or Wherein, the time condition includes: a time within a predetermined range during the day.

18. The vehicle according to claim 1, wherein, The vehicle is further operable to: Notify the application server providing vehicle services to the vehicle that the vehicle will enter the sleep mode; and / or Before the step of requesting the extended discontinuous reception mode, exchange information about the status of the vehicle with the application server providing vehicle services to the vehicle.

19. The vehicle according to claim 3, wherein, The vehicle is further operable to: provide information from the telematics control unit to the vehicle internal system indicating that the vehicle system should not be expected to be contacted during the duration of the extended discontinuous reception time.

20. The vehicle according to any one of claims 3, 7, 8, 10, 13, 18, and 19, wherein The vehicle further includes a communication circuit, which is operable to perform at least one of the following: The communication with the vehicle internal system; The communication with at least one of the following: the vehicle internal system of the vehicle, a cooperative intelligent transportation system node, a positioning satellite, and a wireless communication network; Receive the determined extended discontinuous reception time from one of the following: an application server providing vehicle services to the vehicle, the vehicle's in-vehicle system, the cooperative intelligent transportation system node, the positioning satellite, and the wireless communication network; Receive data of a discontinuity time impact parameter from one of the following: the application server providing vehicle services to the vehicle, the vehicle's in-vehicle system, the cooperative intelligent transportation system node, the positioning satellite, and the wireless communication network; Receive the acceptance of the extended discontinuous reception mode; Notify the application server providing vehicle services to the vehicle that the vehicle will enter the sleep mode; Exchange information about the status of the vehicle with the application server providing vehicle services to the vehicle; Provide, from the telematics control unit to the in-vehicle system, information indicating that the vehicle system should not expect to be contacted during the duration of the extended discontinuous reception time; And Initiate the request for the extended discontinuous reception mode.

21. A method for controlling a vehicle, wherein, The method includes the following steps: Obtain information on a discontinuity beneficial condition associated with the vehicle, The discontinuity beneficial condition indicating that the extended discontinuous reception mode is beneficial for the telematics control unit; Obtain a determination of the extended discontinuous reception time for the telematics control unit; and In response to the obtained discontinuity beneficial condition, initiate a request for the extended discontinuous reception mode for the telematics control unit, suggesting the determined extended discontinuous reception time.

22. The method according to claim 21, wherein, The vehicle includes a vehicle control system and the telematics control unit.

23. The method according to claim 21, wherein The step of obtaining the information on the discontinuity beneficial condition includes: communicating with the in-vehicle system.

24. The method according to claim 21, wherein The discontinuity beneficial condition includes at least one of the following: a vehicle inactivity condition, a person absence condition, an energy condition, a time condition, and a location condition.

25. The method according to claim 24, wherein The vehicle inactivity condition includes at least one of the following: The engine of the vehicle is turned off; The ignition of the vehicle is turned off; and An in-vehicle system indication indicating that the vehicle will enter an energy-saving mode or a deeper sleep in terms of communication with the network; And / or Wherein, the person absence condition includes at least one of the following: The vehicle is locked from the outside; The vehicle's keyless system does not sense a key within range; and The vehicle's seat sensor indicates that no one is sitting in the vehicle or the driver's seat of the vehicle; and / or Wherein, the energy condition includes: an indication of low battery voltage in the vehicle; and / or Wherein, the time condition includes: a time within a predetermined range during the day; and / or Wherein, the location condition includes: the location of the vehicle.

26. The method according to claim 21, wherein, The step of initiating the request for the extended discontinuous reception mode is executed after a lag time expires, the lag time starting from when the information on the discontinuity beneficial condition is obtained.

27. The method according to claim 21, wherein, The step of obtaining the determination of the extended discontinuous reception time includes: Communicate with at least one of: an application server providing vehicle services to the vehicle, an in-vehicle system of the vehicle, and a cooperative intelligent transportation system node; Receive information from positioning satellites; and Use a wireless communication network.

28. The method according to claim 27, wherein, The step of obtaining the determined extended discontinuous reception time includes: receiving the determined extended discontinuous reception time.

29. The method according to claim 28, wherein The determination of the extended discontinuous reception time is based on data of discontinuity time impact parameters.

30. The method according to claim 27, wherein The step of obtaining the determined extended discontinuous reception time includes: Receiving data of discontinuity time impact parameters from at least one of: the application server providing vehicle services to the vehicle, the in-vehicle system of the vehicle, the cooperative intelligent transportation system node, the positioning satellites, and the wireless communication network; and Based on the received data of discontinuity time impact parameters, performing the determination of the extended discontinuous reception time.

31. The method according to claim 29, wherein, The discontinuity time impact parameters include at least one of: time and history related parameters, location related parameters, and energy related parameters.

32. The method according to claim 31, wherein, The time and history related parameters include at least one of: Time of day; Day of the week; Annual season; Pattern of historical parameter values from the vehicle; and Settings of predetermined autonomous driving events of the vehicle; and / or Wherein, the location related parameters include at least one of: Location of the vehicle; The vehicle is outside cellular coverage; and The vehicle has no GPS coverage; and / or Wherein, the energy related parameters include at least one of: The vehicle is an electric vehicle and is connected to a charging system; and Temperature at the location of the vehicle.

33. The method according to claim 21, further comprising the step of: During the extended discontinuous reception mode, re-evaluating the extended discontinuous reception time.

34. The method according to claim 21, further comprising the step of: Receiving acceptance of the extended discontinuous reception mode; And Managing the transfer of the telematics control unit to the extended discontinuous reception mode.

35. The method according to claim 21, further comprising the step of: In response to detecting a discontinuity stop condition, interrupting the hysteresis or discontinuity process.

36. The method according to claim 35, wherein The discontinuity stop conditions include at least one of: vehicle activity conditions, personnel presence conditions, energy conditions, and time conditions.

37. The method according to claim 36, wherein, The vehicle activity conditions include at least one of: The ignition device of the vehicle is started; The engine of the vehicle is started; The autonomous driving function of the vehicle is activated; and / or Wherein, the personnel presence conditions include at least one of: The keyless system of the vehicle indicates that the key is within range; The vehicle is unlocked; and The seat sensor of the vehicle indicates that someone is in the vehicle; and / or Wherein, in the case where the vehicle is an electric vehicle, the energy condition includes: an indication that the electric vehicle is being recharged; and / or Wherein, the time condition includes: time within a predetermined range during the day.

38. The method according to any one of claims 21 to 37 further comprises the following steps: notifying an application server providing vehicle services to the vehicle that the vehicle will enter a sleep mode; and / or exchanging information about the status of the vehicle with an application server providing vehicle services to the vehicle before the step of requesting an extended discontinuous reception mode.

39. The method according to claim 23 further comprises the following steps: Providing information from the telematics control unit to the vehicle internal system indicating that the vehicle system should not expect to be contacted during the duration of the extended discontinuous reception time.

40. A computer-readable storage medium having program code stored thereon to be executed by at least one processor of a vehicle, whereby execution of the program code causes the vehicle to be adapted to perform corresponding operations according to the method of any one of claims 21 to 39.

Images