GB2471347A - Using a control parameter to control the level of communication message congestion in and between nodes in a wireless vehicle to vehicle network. - Google Patents

Using a control parameter to control the level of communication message congestion in and between nodes in a wireless vehicle to vehicle network. Download PDF

Info

Publication number
GB2471347A
GB2471347A GB0916801A GB0916801A GB2471347A GB 2471347 A GB2471347 A GB 2471347A GB 0916801 A GB0916801 A GB 0916801A GB 0916801 A GB0916801 A GB 0916801A GB 2471347 A GB2471347 A GB 2471347A
Authority
GB
United Kingdom
Prior art keywords
congestion
level
control
parameter
communication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
GB0916801A
Other versions
GB0916801D0 (en
Inventor
Hisashi Manabe
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Europe Ltd
Original Assignee
NEC Europe Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Europe Ltd filed Critical NEC Europe Ltd
Publication of GB0916801D0 publication Critical patent/GB0916801D0/en
Publication of GB2471347A publication Critical patent/GB2471347A/en
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/09Arrangements for giving variable traffic instructions
    • G08G1/0962Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096766Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission
    • G08G1/096791Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission where the origin of the information is another vehicle
    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/09Arrangements for giving variable traffic instructions
    • G08G1/0962Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0965Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages responding to signals from another vehicle, e.g. emergency vehicle
    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/09Arrangements for giving variable traffic instructions
    • G08G1/0962Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967Systems involving transmission of highway information, e.g. weather, speed limits
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/11Identifying congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/17Interaction among intermediate nodes, e.g. hop by hop
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0284Traffic management, e.g. flow control or congestion control detecting congestion or overload during communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/10Flow control between communication endpoints
    • H04W28/12Flow control between communication endpoints using signalling between network elements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W52/00Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/04TPC
    • H04W52/30TPC using constraints in the total amount of available transmission power
    • H04W52/34TPC management, i.e. sharing limited amount of power among users or channels or data types, e.g. cell loading
    • H04W52/343TPC management, i.e. sharing limited amount of power among users or channels or data types, e.g. cell loading taking into account loading or congestion level
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/18Self-organising networks, e.g. ad-hoc networks or sensor networks

Abstract

Disclosed is a communication node for communicating with other nodes over a communication channel. The node has means for obtaining the value of a parameter indicative of the congestion state of the channel. The node uses the value of the parameter to determine if the channel is in a high congestion state or a low congestion state. A congestion controller is used to control the congestion by varying a control parameter that affects the congestion state of the channel. The controller, when the channel is in the high congestion state, changes the level of congestion control from a first low to a high level by varying the control parameter in several steps and when the parameter indicates the channel is in the second congestion state, to change the level of congestion control from the high level back to the low level by varying the control parameter in several steps, such that the level of congestion control is changed in an asymmetric manner between the increasing and decreasing control processes.

Description

Communication System The present invention relates to communication networks and devices, and in particular but not exclusively to the provision of wireless access in vehicular environments (WAVE). The invention has particular although not exclusive relevance to so called intelligent transportation system communication networks.
The provision of wireless access in vehicular environments (WAVE) I dedicated short range communications (DSRC) for emerging Intelligent Transportation Systems (ITS) is becoming increasingly important and has many potential applications including, for example: systems for providing vehicles with emergency warnings from other vehicles in the vicinity (e.g. in the case of an emergency stop, accident, breakdown or the like); various collision avoidance applications; automated congestion and other road I parking charging systems; and inter-vehicle co-operative adaptive cruise control.
A frame-work for wireless communications required to support ITS is provided for by IEEE 802.11 p, which is an amendment to the IEEE 802.11 standard which sets out a number of enhancements to the standard aimed at supporting data communications between high-speed vehicles and between the vehicles and the roadside infrastructure in the associated ITS band (e.g. 5.9 GHz in the US and -5.8 GHz in Japan, and Europe).
In ITS, vehicle-to-vehicle communication will use a carrier sense multiple access protocol with collision avoidance (CSMAICA) which is a Media Access Control (MAC) protocol in which a communication node checks for the presence or absence of communication traffic on the communication channel, and transmits its data if the channel is free or delays transmission if the channel is busy. Accordingly, as more vehicles use the same communication channel, the channel becomes congested and this can result an inherent increase in the delay before a node can access the channel for transmission. Thus, congestion can represent a serious issue for vehicle-to-vehicle communication, especially for the transmissions of time-sensitive information such as safety' related information including, for example, emergency
I
alerts. In such examples, longer access delay times are highly undesirable and, ideally, should be prevented.
In order to cater for the expected large-scale provision of vehicle-to-vehicle communication capabilities in future vehicles, therefore, these communication congestion issues need to be addressed. Current proposals for addressing these issues, however, are based on flawed assumptions and as a result fail to address the congestion issues adequately. For example, current proposals assume that if a vehicle based communication node detects signal (communication) congestion in the channel it will reduce the rate at which it transmits its messages and/or reduce transmission power and that all other vehicle based communication nodes in the vicinity (and contributing to the signal congestion) will also detect the signal congestion and, accordingly, will also reduce their transmission rates and/or power, thereby reducing the signal congestion in the communications channel. However, there are situations in which this assumption does not hold and, accordingly, vehicle based communication nodes may remain in a congested state because of communications from other nodes in the vicinity which have failed to detect the signal congestion.
Accordingly, preferred embodiments of the present invention aim to provide methods and apparatus which overcome or at least alleviate the above issues.
According to one aspect of the present invention there is provided a communication node for communicating with at least one further communication node of a communication network over a communication channel, the communication node comprising: means for determining a congestion level in the communication channel; means for generating, in dependence on said determined congestion level, a signal for requesting initiation of a congestion control procedure; and means for transmitting said signal for requesting initiation of a congestion control procedure to said at least one further communication node.
The communication node may comprise means for initiating a congestion control procedure which may be operable to initiate a first congestion control procedure in dependence on said determined congestion level. The means for initiating a congestion control procedure may be operable to initiate the first congestion control procedure after said signal for requesting initiation of a congestion control procedure has been sent to said at least one further communication node.
The communication node may comprise means for receiving a signal for requesting initiation of a congestion control procedure from a further communication node, and the means for initiating a congestion control procedure may be operable to initiate a second congestion control procedure in response to receipt of said signal from said further communication node.
According to another aspect of the present invention there is provided a communication node for communicating with at least one further communication node over a communication channel, the communication node comprising: means for receiving a signal requesting initiation of a congestion control procedure from a further communication node; and means for initiating, in response to receipt of said signal, a congestion control procedure.
The communication node may comprise means for determining a congestion level in the communication channel, may comprise means for generating, in dependence on said determined congestion level, a signal for requesting initiation of a congestion control procedure; and may comprise means for transmitting said signal for requesting initiation of a congestion control procedure to at least one further communication node. The means for initiating a congestion control procedure may be further operable to initiate the congestion control procedure in dependence on said determined congestion level.
According to another aspect of the present invention there is provided a system (e.g. an intelligent transport system (ITS)) comprising first and second communication nodes each operable for communication over a communication channel, the first communication node comprising: means for determining a congestion level in the communication channel; means for generating, in dependence on said determined congestion level, a signal for requesting initiation of a congestion control procedure; and means for transmitting said signal for requesting initiation of a congestion control procedure to said second communication node; and the second communication node comprising: means for receiving said signal requesting initiation of a congestion control procedure from said first communications node; and means for initiating, in response to receipt of said signal, a congestion control procedure.
The (or each) congestion control procedure may comprise modifying at least one of a transmission power, an interval between transmitted signals, and/or the size of transmitted data packets.
According to another aspect of the present invention there is provided a method performed by a communication node of a communication network which communication node is operable for communication with at least one further communication node over a communication channel, the method comprising: determining a congestion level in the communication channel; generating, in dependence on said determined congestion level, a signal for requesting initiation of a congestion control procedure; and transmitting said signal for requesting initiation of a congestion control procedure to at least one further communication node of said communication network.
The method may further comprise initiating a congestion control procedure in dependence on said determined congestion level.
According to another aspect of the present invention there is provided a method performed by a communication node of a communication network which communication node is operable for communication with at least one further communication node over a communication channel, the method comprising: receiving a signal requesting initiation of a congestion control procedure from the further communication node; and initiating, in response to receipt of said signal, a congestion control procedure.
The communication node may comprise a means for identifying a preferred/optimum congestion control level. The preferred/optimum congestion control level may represent a preferred level of congestion control to be applied either by the communication node identifying the preferred/optimum congestion control level or the further communication node. Accordingly, the congestion control request may comprise information identifying the preferred/optimum congestion control level.
The (or each) congestion control procedure may comprise a procedure for reducing the contribution of the communication unit to (signal) congestion. For example, the congestion control procedure may comprise modifying at least one of a transmission power (e.g. decreasing transmission power for reducing congestion), an interval between transmitted signals (e.g. increasing the interval for reducing congestion), and the size of transmitted data packets (e.g. reducing the packet size for reducing congestion).
The first and second congestion control procedures may use the same or a different procedure for reducing the contribution of the communication unit to (signal) congestion.
The congestion control procedure may be initiated in dependence on the determined congestion level (for example, when the determined congestion level or a parameter indicative of the congestion level indicates a congested situation -possibly by exceeding a predetermined threshold). The congestion control procedure may also be initiated in response to receipt of a signal from a further communication node requesting the initiation.
The congestion control procedure may be initiated in dependence on a reduction in the determined congestion level (and possibly a predetermined criteria or plurality of criteria). In this case, the (or each) congestion control procedure may be operable to reduce an existing level of congestion control, for example by modifying at least one of a transmission power (e.g. increasing transmission power), an interval between transmitted signals (e.g. decreasing the interval), and the size of transmitted data packets (e.g. increasing the packet size).
Communication between units may be via a shared frequency resource but use signals separated in time. Communication between units may use a shared time resource with signals separated in frequency. Communication between units may use signals separated in both frequency and time.
The communication network may form an (or part of an) intelligent transport system (ITS).
This application also describes a second invention, which is the subject of GB0910810.1, the contents of which are incorporated herein by reference.
According to this second invention there is provided a communication node for communicating with at least one further communication node of a communication network over a communication channel, the communication node comprising: means for determining a congestion level in the communication channel; means for generating, in dependence on said determined congestion level, a signal for requesting initiation of a congestion control procedure; and means for transmitting said signal for requesting initiation of a congestion control procedure to said at least one further communication node. This second invention may be provided separately from the invention claimed in this case or it may be provided in combination with the invention claimed in this case.
Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings in which: Figure 1 is a simplified illustration of a vehicle based communication network; Figure 2 schematically illustrates the main components of a vehicle based communication unit forming part of the network shown in Figure 1; Figure 3 is a flow diagram illustrating operation of an exemplary implementation of the vehicle based communication unit of Figure 2; Figures 4a to 4e are sequential time interval diagrams illustrating the benefits of a preferred implementation of the vehicle based communication unit of Figure 2; Figures 5(a) and 5(b) are generalised control diagrams illustrating different methods for controlling parameters of interest in a generic system; Figure 6 schematically illustrates the main components of a congestion reduction control module for the communication unit of Figure 2; Figure 7(a) is a flow diagram illustrating operation of an exemplary implementation of the congestion reduction control module of Figure 6; Figure 7(b) is a flow diagram illustrating operation of another exemplary implementation of the congestion reduction control module of Figure 6; Figure 8 is a control diagram for the method of managing the congestion control level illustrated by the flow chart of Figure 7(a) or 7(b); Figures 9(a) to 9(j) are control diagrams each illustrating a different time point or period during operation according to the method of Figure 7 in a first scenario; and Figures 10(a) and 10(b) are control diagrams each illustrating a different time point or period during operation according to the method of Figure 7 in a second scenario.
Overview Figure 1, is a simplified illustration of a vehicle based communication network generally at 2. The vehicle based network 2 comprises an ad-hoc' network including a plurality of vehicles 4-1 to 4-8 (generally 4') each provided with a respective communication unit 6-1 to 6-8 (generally 6'), and a plurality of road-side' communication units 8-1, 8-2 (generally 8') forming part of a wider communication infrastructure (not shown).
The communication units 6, 8 are configured for wireless communication with one another (including vehicle-to-vehicle V2V', vehicle-to-infrastructure V21', and infrastructure-to-vehicle 12V' communication) using a short/medium range communication protocol suitable for supporting intelligent transportation system (ITS) applications. The communication units may, for example, be operable to communicate with one another using a medium access control (MAC) protocol, for example a contention based multiple access mechanism such as a carrier sense multiple access protocol with collision avoidance (CSMNCA). The protocol may, for example, comprise a protocol which is compatible with the so called Dedicated Short Range Communications (DSRC) and/or Wireless Access in a Vehicular Environment (WAVE) related standards (for example the IEEE 802.11 standard as amended by IEEE 802.llp).
The vehicle based communication units 6 employ a method of congestion control in which a congestion control request signal is transmitted by a communication node 6 of one vehicle (when signal congestion is detected by that communication unit 6), to the communication units 6 of other vehicles, just prior to initiation of a congestion control procedure aimed at reducing its contribution to signal congestion. The communication units 6 of the other vehicles that receive the congestion control request activate their own congestion control procedure aimed at reducing their contribution to signal congestion. In this way improvements in congestion control are achieved at times when efficient congestion control is particularly critical.
Vehicle Based Communication Units Figure 2 schematically illustrates the main components of the vehicle based communication unit 6 shown in Figure 1.
As shown, the communication unit comprises receiver circuitry 20 and transmitter circuitry 22 respectively operable to receive signals from and to transmit signals to other vehicle based or road-side communication units 6, 8 via one or more antennae 24. As shown, the vehicle based communication unit 6 also includes an intelligent transport system (ITS) management processor 26 which is operable to control operation of the vehicle based communication unit 6 including, for example, operation of the receiver and transmitter circuitry 20, 22, interaction with a user via suitable input/output units 28 (e.g. loudspeaker, display, user control pad or the like), and the acquisition of vehicle information, via a corresponding sensor and navigation system interface 29, from vehicle mounted sensors and a vehicle based navigation system such as a global navigation satellite system (GNSS). For example, the interface 29 of the communication unit 6 may interface with an automotive navigation terminal (e.g. a GNSS) either directly or indirectly via an in-vehicle Local Area Network (LAN) and may obtain from it current position, speed, direction and acceleration information for the vehicle. The interface 29 may also receive inputs from other vehicle mounted sensors that provide similar or other vehicle related information. The management processor 26 operates in accordance with software instructions stored within memory 30, which software instructions comprise, amongst other things, an operating system 31.
The vehicle based communication unit 6 also includes, amongst other things, a received signal analysis module 32, a transmitter power control module 34, a congestion status analysis module 36, a congestion reduction control module 38, and a signal generation module 40.
The received signal analysis module 32 is operable to process signals received from the other communication units 6, 8, to analyse the contents of the signals, and to initiate appropriate responses to receipt of the signal when required. The transmitter power control module 34 is operable to control the power used by the transmitter to transmit signals to other communication units 6, 8 and, accordingly, to control the effective range of the transmitted signals. The congestion status analysis module 36 is operable to monitor the usage of the communication channel (or channels) used for vehicle-to-vehicle, vehicle-to-infrastructure and/or infrastructu re-to-vehicle communications, and to identify a communication congestion level within the channel (or channels). The congestion reduction control module 38 is operable to initiate congestion reduction procedures, to enforce (increase) or moderate (decrease) a level of congestion control being applied, or to initiate termination of a congestion control procedure in dependence upon the congestion level within the channel (or channels) as identified by the congestion status analysis module 36. The signal generation module 40 is operable to generate signals for communication to other communication units 6, 8. The signals generated typically carry, for example: regular messages carrying vehicle related information such as stored identification information (e.g. vehicle ID), and information acquired from the GNSS via the sensor and navigation system interface 29; alert messages for alerting or warning other users to a potentially hazardous situation (e.g. a vehicle breakdown); and other such messages.
In one embodiment, for example an on-board unit (OBU) for Safety-ITS will identify the location of the vehicle in which it is installed by GNSS and then broadcast the self-location-information (e.g. latitude, longitude, altitude) by embedding the location information into a signal (often referred to as a beacon) as one of the parameters of the signal. The broadcasting of this location information allows other vehicles that receive the signal to determine the location of the vehicle that broadcast the signal.
Similarly, location information for other vehicles nearby is obtained from beacon messages received from those other vehicles. Accordingly, in operation, when congestion is detected by the congestion status analysis module 36, the congestion reduction control module 38 initiates generation of the congestion control request signal by the signal generation module 40 for broadcast by the transmitter circuitry 22, just prior to initiation of the congestion control procedure. In response to receiving the congestion control request, the congestion reduction control module 38 in the communication unit 6 of each other vehicle 4 activates a corresponding congestion control procedure for that vehicle.
In this example, the congestion control procedure typically comprises a procedure for reducing the contribution of the communication unit 6 to signal congestion by reducing the transmission power as controlled by the transmission power control module 34 (thereby reducing the range of the transmitted signals and decreasing the number of vehicles that will receive the transmitted signals). In other examples, the congestion control procedure may comprise increasing the interval between transmitted signals (thereby reducing the number of signals transmitted per unit time), and/or reducing the size of the transmitted data packets (thereby reducing the amount of data transmitted per unit time).
It will be appreciated that some or all of the functionality of the various modules of the vehicle based communication unit 6 may be provided by dedicated hardware circuits and/or that some or all of the functionality may be provided by the management processor 26 operating in accordance with software instructions, stored within memory 30 and arranged to provide the corresponding functionality.
Signal Congestion Reduction Figure 3 is a flow diagram illustrating operation of an exemplary implementation of a vehicle based communication unit 6 to assist a reduction in communications congestion (e.g. when several communication units 6 are within range of one another).
As described above, the congestion status analysis module 36 is operable to monitor congestion on communications channel(s) to determine a communication congestion level within a channel (or channels) over which signals are being transmitted and/or received. In accordance with this embodiment, the congestion status analysis module 36 measures parameters indicative of the level of congestion as shown at step Sb in Figure 3. In this implementation, the congestion status analysis module 36 is operable to determine a communication congestion level based on measurements of a channel usage parameter.
Furthermore, the congestion status analysis module 36 is operable to provide an indication of the prevailing signal congestion conditions (for example, based on a comparison of the congestion level, or a congestion parameter, with one or more predetermined thresholds stored in memory 30) to the congestion reduction control module 38.
The congestion reduction control module 38 is operable to monitor the prevailing conditions indicated by the congestion status analysis module 36 to determine, at step S12, when the channel is under congestion.
Conditions Indicative of Congestion at Step S12 In the event that the communication channel is deemed to be under congestion, the congestion status analysis module 36 notifies the congestion reduction control module 38 to initiate a congestion reduction procedure.
The congestion reduction control module 38 is operable, on identifying that the communication channel is under congestion, to determine an appropriate congestion control level for other vehicle based communication units 6 within range of the transmitter 22 of the communication unit 6 which identified the congested status (step S14). The congestion control level is indicative of the extent to which congestion control should preferably be applied by other vehicle based communication units 6 in the vicinity. The congestion reduction control module 38 is further operable to notify the signal generation module 40 of the determined congestion control level, thereby to initiate generation and transmission of a congestion control request.
As shown at step S16, the signal generation module 40 is operable, on receipt of information identifying the required congestion control level, to generate the congestion control request, including an indication of the required congestion control level, and to initiate broadcast, by the transmitter circuitry 22, of the congestion control request to other vehicle based communication units 6 in the vicinity.
Prior to enforcing (increasing) an existing level of congestion control (or initiating congestion control) as described previously, the unit 6 ensures that any existing congestion control can be stepped-up (increased/reinforced). Accordingly, the congestion reduction control module 38 is further operable, at step S19, to determine if the current level of congestion control for its own' vehicle 4 (i.e. the vehicle 4 in which the unit 6 that has detected the congestion is installed) has reached (or exceeded) a maximum level (for example, by reference to a maximum congestion control' flag or by comparison with a maximum congestion control level stored in memory 30). If the existing level of congestion control has reached (or exceeded) the maximum level, then the congestion reduction control module 38 simply returns to congestion monitoring (step S10) without a further reinforcement in the level of congestion control employed.
In the event that the existing level of congestion control has not reached (or exceeded) the maximum level, the congestion reduction control module 38 is operable to determine an appropriate (increased) congestion control level for its own vehicle 4 (step S20) and to initiate a reinforcement in the level of congestion control accordingly (step S22) by stepping up the level of congestion control applied, towards the maximum congestion control level for the unit 6. The determined congestion control level is dependent on an optimum congestion control level (e.g. the congestion control level determined at step S14) and the maximum congestion control level for the unit 6.
As described above, there are a number of different ways in which the congestion reduction control module 38 may be operable to implement the reinforcement of the congestion control. In the present embodiment, for example as described above, the congestion reduction control module 38 is operable to reinforce the level of congestion control by initiating a reduction in transmitter power by the transmitter power control module 34 (referred to as transmitter power control (TPC)').
Accordingly, the range of the transmitter is decreased and hence any communication units 6 which, as a result of the power reduction, become located outside the new range will receive fewer signals (less communications traffic) thereby reducing the signal congestion on those other communication units 6.
In another embodiment, as mentioned above, the congestion reduction control module 38 is operable to initiate an increase in the interval between the signals generated by the signal generation module 40 (referred to as signal interval control (SIC)') for transmission by the transmitter circuitry 22. Accordingly, the number of signals sent by the transmitter per unit time, and received by other communication units 6, 8 within range, is decreased thereby reducing signal traffic and hence congestion for the other communication units 6, 8.
In another embodiment, as mentioned above, the congestion reduction control module 38 is operable to initiate a reduction in the size of message packets generated by the signal generation module 40 (referred to as message size control (MSC)') for transmission by the transmitter circuitry 22. Accordingly, the amount of data sent by the transmitter per unit time, and received by other communication units 6, 8 within range, is decreased thereby reducing congestion for the other communication units 6, 8.
After the congestion reduction control level has been increased the congestion reduction communication unit 6 then returns to congestion monitoring as described with reference to step Sb.
Conditions not Indicative of Congestion at Step S12 In the event that the conditions do not indicate the communication channel to be congested at step S12, the congestion status analysis module 36 is operable, at step S24, to monitor for receipt of an indication from the signal analysis module 32, that a congestion control request has been received from another vehicle based communication unit 6. It will be appreciated that, although shown sequentially, this monitoring may be carried out substantially in parallel with congestion monitoring rather than after a specific determination that the communication channel is deemed not to be congested.
The congestion status analysis module 36 is operable, in the event that a congestion control request has been received from another vehicle based communication unit 6, to initiate a request based congestion control procedure which essentially follows steps S19 to S22 as described above and will not, therefore, be described again.
As described previously, there are number of different ways in which the congestion reduction control module 38 may be operable to implement the increase in congestion control including, for example TPC, SIC or MSC. The method employed for congestion reduction may be dependent on the contents of the congestion control request message, which may be configured to include an explicit (or implicit) indication of a preferred type of congestion reduction.
After the congestion reduction control level has been increased the congestion reduction control module 38 then returns to congestion monitoring (step Sb).
The congestion reduction control module 38 is operable, in the event that a congestion control request has not been received from another vehicle based communication unit 6, to determine if its own communication unit 6 is currently subject to a level of congestion control (step S26). If it is not, then the control module 38 returns to the monitoring step SlO described above.
Otherwise, the congestion reduction control module 38 is operable to monitor the prevailing congestion conditions indicated by the congestion status analysis module 36 to determine whether or not the level of congestion control to which the communication unit 6 is subject, may be moderated based on a predetermined set of criteria (step S28).
In this embodiment, the predetermined set of criteria for reducing (moderating) congestion control are set to ensure that oscillation between different levels of congestion control (e.g. between increasing and decreasing congestion control) is avoided. The criteria may include, for example, a requirement that the prevailing congestion level has been stable for a predetermined length of time, before allowing the level of congestion control to be moderated. The criteria of S28 may alternatively or additionally include criteria based on the number of vehicle based communication units 6 in the vicinity. For example, if the number of vehicles in the vicinity is 30 when congestion is indicated at S12, the criteria of step S28 may be met when the number of vehicle based communication units 6 drops to 25 (thereby avoiding oscillation resulting from a smaller change in the number of vehicle based communication units 6 in the vicinity).
In the event that the criteria for reducing congestion control have been met, the congestion reduction control module 38 is operable to determine an appropriate (reduced) congestion control level for its own vehicle 4 (step S30) and to initiate a moderation in the level of congestion control accordingly (step S18) by stepping down the level of congestion control applied, towards no congestion control for its own unit 6.
There are a number of different ways in which the congestion reduction control module 38 may be operable to implement the moderation in congestion control. In the present embodiment, for example, the congestion reduction control module 38 is operable to moderate the level of congestion control by initiating an increase in transmitter power by the transmitter power control module 34 (TPC). Accordingly, the range of the transmitter is increased and hence any communication units 6 which, as a result of the power increase, become located within the new range will begin to receive signals from the communication unit 6 once again.
In another embodiment, the congestion reduction control module 38 is operable to initiate a decrease in the interval between the signals generated by the signal generation module 40 (SIC) for transmission by the transmitter circuitry 22.
Accordingly, the number of signals received from the communication unit 6, by other communication units 6, 8 within range, is increased once again.
In another embodiment, the congestion reduction control module 38 is operable to initiate an increase in the size of the message packets generated by the signal generation module 40 (MSC) for transmission by the transmitter circuitry 22.
Accordingly, the amount of data received from the communication unit 6, by other communication units 6, 8 within range, is increased once again.
It will be appreciated that the congestion reduction control module 38 may be operable to implement any suitable mechanism for moderating the level of congestion control applied and may use any appropriate combination of such mechanisms (at different times or substantially simultaneously) to optimise the level of congestion control. It will be further appreciated that moderating the congestion control level may comprise removing all congestion control to which the communication unit 6 was previously subject.
Exemplary mechanisms for managing the level of congestion control applied in different situations are described in more detail below with reference to Figures 5(a) to 10(b).
After the congestion reduction control level has been moderated in this way, or in the event that the criteria for reducing congestion control have not been met at step S28, the communication unit 6 returns to congestion monitoring substantially as described with reference to step Sb.
Benefits and Advantages Some of the benefits I advantages of the various embodiments are illustrated in Figures 4(a) to 4(e). Figures 4(a) to 4(c) comprise a set of sequential time interval diagrams illustrating operation of an exemplary intelligent transport system in which only some of the technical features described for the communication units are implemented. Figures 4(a), 4(d) and 4(e), on the other hand, illustrate operation of an intelligent transport system in which the vehicle communication units comprise the features of at least one of the embodiments described.
Figure 4(a) -Time Point I In Figure 4(a) the systems are shown in an initial state (or first time point) in which there are seven vehicles (Vi to V7) at different distances relative to one another (as illustrated by arrow A') and each having an associated vehicle communication unit 6 (not shown). Each vehicle communication unit 6 has a respective transmitter range represented by arrows BI' to B7' which is a function of transmitter power. The vertical line (CI to C7) through each vehicle (VI to V7) may be visualised as a virtual antenna' for that vehicle indicating the capability of the corresponding communication unit to receive messages from other vehicles (VI to V7) in dependence on their transmitter range (BI to B7).
In Figures 4(a) to 4(e), a circle at the intersection between a range arrow (BI to B7) for the communication unit 6 of a first vehicle (VI to V7) and a vertical line (CI to C7) through (or virtual antenna' for) a second vehicle (VI to V7) is indicative of the second vehicle's communication unit being able to receive messages from the first vehicle's communication unit.
As seen in Figure 4(a), for example: vehicle VI is capable of receiving messages from just one other vehicle (vehicle V2); vehicle V2 is capable of receiving messages from four other vehicles (VI, V3, V4 and V5); vehicle V3 is capable of receiving messages from four other vehicles (V2, V4, V5 and V6); vehicle V4 is capable of receiving messages from four other vehicles (V2, V3, V5 and V6); vehicle V5 is capable of receiving messages from four other vehicles (V2, V3, V4 and V6); vehicle V6 is capable of receiving messages from four other vehicles (V3, V4, V5 and V7); and vehicle V7 is capable of receiving messages from just one other vehicle (V6).
The number of communication units from which a particular vehicle may receive messages (and shown at the top of the corresponding vertical line (CI to C7)) is indicative of channel usage for the associated communication unit 6 with higher numbers indicating a greater chance of channel congestion. In the illustrated systems of Figures 4(a) to 4(e), for ease of explanation, it is assumed that the channel becomes congested when the number of communication units from which a particular vehicle may receive messages reaches five. It will be appreciated, however, that in practical applications the number of communication units communicating using a particular channel before congestion occurs may be much larger, for example thirty or more units 6, depending on how the communication channel is being used, the nature of messages being sent, etc. Figure 4(b) -Time Point 2 -exemplary ITS Figure 4(b) shows the situation at a second time point for the exemplary intelligent transport system.
In Figures 4(a) to 4(e) vehicles V2 to V7 are moving at substantially the same speed whilst vehicle VI (shown with diagonal hatching) is moving faster. Accordingly, as shown in Figure 4(b) at the second (later) time point, vehicle VI is closer to the other vehicles (vehicles V2 to V7) and, accordingly, the communication units 6 of vehicle V3 and vehicle V4 are now within transmitter range Bi as illustrated by the solid black circles on vertical lines C2 and C3.
As seen in Figure 4(b), therefore: vehicle VI is now capable of receiving messages from three other vehicles (V2, V3, V4); vehicle V2 is still capable of receiving messages from four other vehicles (VI, V3, V4 and V5); vehicle V3 is now capable of receiving messages from five other vehicles (VI, V2, V4, V5 and V6); vehicle V4 is also now capable of receiving messages from five other vehicles (VI, V2, V3, V5 and V6); vehicle V5 is capable of receiving messages from four other vehicles (V2, V3, V4 and V6); vehicle V6 is still capable of receiving messages from four other vehicles (V3, V4, V5 and V7); and vehicle V7 is still capable of receiving messages from just one other vehicle (V6).
Accordingly, vehicles V3 and V4 are now capable of receiving messages from five other vehicles and, for illustrative purposes, are therefore assumed to be subject to congestion.
Unlike, the communication units 6 described above the communication units 6 of the exemplary intelligent transport system are not configured to carry out step S16 in Figure 3 in which a congestion control request is generated and transmitted to other communication units 6 in the vicinity, or step S24 in which a congestion control request is received from other communication units 6 (e.g. based on the assumption that all vehicles contributing to congestion will be able to accurately detect the onset of congestion). Thus, on detection of the congestion which occurs at time point 2, the communication units 6 of vehicles V3 and V4 initiate their own congestion reduction control procedures only (nominally to reduce their own contribution to any congestion).
Figure 4(c) -Time Point 3 -exemplary ITS Figure 4(c) shows the situation at a third time point after the communication units 6 of vehicles V3 and V4 have initiated their own congestion reduction control procedures. As seen in Figure 4(c), the communication unit 6 of each of vehicles V3 and V4 (horizontally and vertically hatched) has reduced its transmitter power and, accordingly, vehicles VI, V2 and V6 are no longer within range (as illustrated by the dotted circles).
As seen in Figure 4(c), therefore: vehicle VI is once again capable of receiving messages from just one other vehicle (V2); vehicle V2 is now capable of receiving messages from just two other vehicles (VI and V5); vehicle V3 is still capable of receiving messages from five other vehicles (VI, V2, V4, V5 and V6); vehicle V4 is also still capable of receiving messages from the five other vehicles (VI, V2, V3, V5 and V6); vehicle V5 is still capable of receiving messages from four other vehicles (V2, V3, V4 and V6); vehicle V6 is now capable of receiving messages from just two other vehicles (V5 and V7); and vehicle V7 is still capable of receiving messages from just one other vehicle (V6).
However, at time point 2, most of the communication units 6 contributing to the congestion seen by the communication units 6 of vehicles V3 and V4 (those of vehicles VI, V2, V5, V6) are not under congestion and so have not taken any action to reduce congestion. Accordingly, the communication units 6 of vehicles V3 and V4 remain under congestion at time point 3. Furthermore, the action taken by the communication units 6 of vehicles V3 and V4 has reduced signal traffic to the communication units of vehicles VI, V2 and V6. Hence, congestion control action by the communication units of vehicles VI, V2 and V6, which might otherwise help to alleviate congestion for the communication units 6 of vehicles V3 and V4, becomes less likely.
Thus, after the congestion is detected, the action of one vehicle based communication unit 6 to activate congestion reduction control (TPC, SIC and/or MSC) for the vehicle 4 in which it is located does not resolve the local congestion.
More specifically, the assumption that all other vehicle based communication units 6 nearby will detect the congestion using the same standardised procedures, and take appropriate congestion reduction action (TPC, SIC and/or MSC), thereby to decrease radio channel usage, does not hold.
As illustrated, a communication unit 6 for a vehicle 4 located at an edge of a region of road traffic congestion may not detect the congestion because the threshold for such detection is not reached. Thus, the radio channel usage causing congestion is not resolved despite the congestion reduction control for the vehicle experiencing the congestion being activated. This issue is compounded because the approach of vehicles to a region of road traffic congestion (where vehicle to vehicle collisions are more likely) is one of the most important situations in which road-safety ITS applications need to work correctly. However, in systems based on the exemplary ITS, such applications may not work effectively because the radio channel usage is high at the edge of road traffic congestion with associated increases in channel access delay. This means the vehicle-to-vehicle communication is delayed, and safety-related information, such as vehicle-location information, sent over the communication channel will be obsolete by the time the information is received.
Figure 4(d) -Time Point 2 -embodiment ITS Figure 4(d) shows the situation at the second time point for the intelligent transport system according to an embodiment, that comprises the vehicle based communication units 6 as described previously.
As described previously, in Figures 4(a) to 4(e) vehicles V2 to V7 are moving at substantially the same speed whilst vehicle VI (shown with diagonal hatching) is moving faster. Accordingly, as shown in Figure 4(d) at the second time point, vehicle VI is closer to the other vehicles (vehicles V2 to V7) and, accordingly, the communication units 6 of vehicle V3 and vehicle V4 are now within transmitter range BI as illustrated by the solid black circles on vertical lines C2 and C3.
As seen in Figure 4(d), therefore: vehicle VI is now capable of receiving messages from three other vehicles (V2, V3, V4); vehicle V2 is still capable of receiving messages from four other vehicles (VI, V3, V4 and V5); vehicle V3 is now capable of receiving messages from five other vehicles (VI, V2, V4, V5 and V6); vehicle V4 is also now capable of receiving messages from five other vehicles (VI, V2, V3, V5 and V6); vehicle V5 is capable of receiving messages from four other vehicles (V2, V3, V4 and V6); vehicle V6 is still capable of receiving messages from four other vehicles (V3, V4, V5 and V7); and vehicle V7 is still capable of receiving messages from just one other vehicle (V6).
Accordingly, vehicles V3 and V4 are now capable of receiving messages from five other vehicles and, for illustrative purposes, are therefore assumed to be subject to congestion.
Unlike the communication units 6 of the exemplary ITS, however, the communication units 6 of the embodiment are configured to carry out step S16 in Figure 3 in which a congestion control request is generated and transmitted to other communication units 6 in the vicinity (when congestion is detected), and step S24 in which a congestion control request is received from another communication unit 6. Thus, on detection of the congestion which occurs at time point 2, the communication units 6 of vehicles V3 and V4 generate and broadcast a congestion control request to other vehicles in the vicinity in addition to initiating their own congestion reduction control procedures.
Accordingly, on receipt of the congestion control request, the communication units 6 of vehicles VI, V2, V5 and V6 (circled) also initiate a congestion reduction control procedure (in addition to vehicles V3 and V4) in accordance with the procedures shown in Figure 3.
Figure 4(e) -Time Point 3 -embodiment ITS Figure 4(e) shows the situation after the communication units 6 of vehicles VI to V6 have initiated their congestion reduction control procedures at the third time point. As seen in Figure 4(e), the communication unit 6 of each of vehicles VI to V6 has reduced its transmitter power and, accordingly, the communication units 6 (of vehicles VI to V7) are no longer within range of the same number of other communication units.
As seen in Figure 4(e), for example: vehicle VI is now capable of receiving messages from just one other vehicle (V2); vehicle V2 is now capable of receiving messages from just two other vehicles (VI and V5); vehicle V3 is capable of receiving messages from just three other vehicles (V2, V4 and V5); vehicle V4 is capable of receiving messages from just two other vehicles (V3 and V5); vehicle V5 is capable of receiving messages from just two other vehicles (V3 and V4); vehicle V6 is capable of receiving messages from just one other vehicle (V7); and vehicle V7 is not capable of receiving messages from any other vehicle shown.
Accordingly, the communication units 6 of vehicles V3 and V4 are no longer subject to congestion because of the significant reduction in signal traffic.
It can be seen, therefore, that sending the congestion control request can advantageously allow other communication units 6 in the vicinity to take proactive steps to reduce congestion on behalf of the affected units. Furthermore, sending the congestion control request can advantageously allow signal traffic to be significantly reduced to the benefit of other communication units 6 (which may not be experiencing congestion) proactively before congestion occurs. These advantages can also potentially provide the additional advantage of ensuring that emergency vehicle-to-vehicle messages (and other road-safety related messages) continue to be successfully communicated to other vehicles in the immediate vicinity with less chance of congestion induced failure. This is particularly important because communication congestion is more likely to occur when road traffic congestion is at its highest and therefore when hazardous situations are more likely to occur.
Managing the Congestion Control Level Figures 5(a) and 5(b) -Overview of two control mechanisms Figures 5(a) and 5(b) are control diagrams illustrating, in overview, a comparison of two different methods for controlling parameters of interest in a generic system, such as an ITS system. Figures 5(a) and 5(b) are generalised, for the purposes of clarity.
Figure 5(a) illustrates an example of what is termed a symmetric' control method whilst Figure 5(b) illustrates an example of what is termed an asymmetric' control method.
The control diagrams of Figures 5(a) and 5(b) illustrate the relationship between a controllable parameter and an observable parameter upon which decisions on how the controllable parameter should be adjusted may be based. In the case of the ITS system the controllable parameter may be the transmitter power (TPC), signal rate (SIC) or message size (MSC) and the observable parameter may be a parameter indicative of the signal congestion level such as number of vehicles from which ITS signals are being received or a channel usage parameter.
Initially, the controllable parameter starts at an ordinary (in this case maximum) level L3' and the observable parameter is somewhere below an upper threshold indicated by c' on the horizontal axis. When the observable parameter reaches (or exceeds) the upper threshold c' action is taken to reduce the controllable parameter by an amount F' to a lower level L2' in what is referred to in Figures 5(a) and 5(b) as a forward' step. The reduction to L2' results in an associated reduction (as illustrated by the dashed arrow Fl') in the observable parameter to an intermediate level indicated by b' (which may vary in dependence on, for example, road traffic or other local conditions/factors).
At this stage, the observable parameter may decrease further over time. As seen in Figures 5(a) and 5(b), if the observable parameter decreases to a lower threshold a' action is taken to increase the controllable parameter once again in what is referred to as a backward' step.
In the case of symmetric control (Figure 5(a)) the controllable parameter is increased by an amount B' which is substantially equal to the amount F' by which it was reduced in forward step Fl' (dashed arrow B1'). However, even with carefully selected thresholds, the backward step BI' can result in an increase in the observable parameter to a level which is close to or even exceeds the upper threshold c'. In such a case another forward step Fl' may follow rapidly after the backward step BI' resulting in undesirable oscillation.
In the case of asymmetric control (Figure 5(b)), however, when the observable parameter drops to (or below) a', the controllable parameter is initially increased by a smaller amount B* which is less than the amount F' by which it was reduced in forward step Fl' (dashed arrow BI-I'). Only when the observable parameter drops to (or below) lower threshold a' once again is the controllable parameter increased by a further increment (dashed arrow BI-2') towards the ordinary level. Accordingly, the controllable parameter is increased incrementally in a plurality of smaller steps (dashed arrows BI-I', BI-2' and BI-3') thereby reducing the risk of oscillation between forward and backward steps.
As shown in Figures 5(a) and 5(b), after the initial forward step Fl', the observable parameter may increase (rather than decrease) and may again reach (or exceed) upper threshold c'. In this case the controllable parameter is reduced further to an even lower level LI' in a second forward step (dashed arrow F2'). In this example the magnitude of the reduction in the second forward step F2' is smaller than in the first forward step Fl' although this need not be the case -it may be larger or it may be the same.
If the observable parameter then decreases to the lower threshold a' action is taken to increase the controllable parameter. In the case of symmetric control (Figure 5(a)) the controllable parameter is increased by an amount which is substantially equal to the amount by which it was reduced in forward step F2' (dashed arrow B2') thereby taking it back to level L2', before being further increased to level L3' as described previously. In the case of asymmetric control (Figure 5(b)), however, the controllable parameter is increased incrementally back to level L2' in a plurality of smaller steps (dashed arrows B2-l' and B2-2') in a similar manner to steps BI -I', Bl-2', and BI - 3' described previously. The controllable parameter may then be increased from level L2' to level L3' generally as described previously (e.g. in incremental steps Bl-l', Bl-2', and Bl-3').
Accordingly, whilst the symmetric approach would seem to offer the benefit of a quicker return of the controllable parameter to its ordinary level than the asymmetric approach, such a control mechanism can lead to undesirable oscillation. The asymmetric approach reduces the risk of oscillation and provides additional flexibility to tune the control mechanism by modification of the respective step sizes and the thresholds.
An implementation of a congestion control level management method for an ITS, which advantageously utilises an asymmetric control mechanism, will now be described in more detail with reference to Figures 6 to 10(b).
Figure 6 -Congestion Reduction Control Module Figure 6 schematically illustrates the main component modules of a congestion reduction control module 38 for implementing an asymmetric congestion control level management method (as illustrated in Figure 5(b)).
As shown, the congestion reduction control module 38 comprises a main module controller 60 for controlling operation of the congestion reduction control module 38 The congestion reduction control module 38 is also provided with an input level analysis sub-module 64, an output level generation sub-module 66, and a threshold management sub-module 68. The input level analysis sub-module 64 is operable to receive inputs I' from the congestion status analysis module 36 which inputs I' are indicative of the current level of signal congestion being experienced by the communication unit 6. In operation, the input level analysis sub-module 64 analyses the received inputs I' to determine the prevailing signal congestion level and compares the determined level with a plurality of congestion control thresholds stored in memory 30. The results of the comparisons are used by the module controller 60 for the purposes of managing the level of congestion control implemented by the congestion reduction control module 38. The output level generation sub-module 66 is operable for setting, resetting, and/or modifying the level of congestion control implemented by the congestion reduction control module 38 under the control of the module controller 60. The threshold management sub- module 68 is operable for managing the stored thresholds to allow them to be fine-tuned' such that the mechanism used for managing the congestion control level can be adapted easily, for example to take account of different traffic scenarios (e.g. urban driving / freeway driving / rural driving).
In this embodiment the inputs I' comprise parameters which represent the number of vehicles in the vicinity, and from which ITS signals are being received on the communication channel(s) used by the communication unit 6 of which the congestion reduction control module 38 forms a part. It will be appreciated, however, that the inputs may comprise one or more other parameters as described elsewhere.
In operation to manage the congestion control level, the congestion reduction control module 38 of this embodiment enforces or reinforces congestion control, when the inputs I' indicate that the number of vehicles from which ITS signals are being received has exceeded a pre-defined enforcement' threshold (e.g. the upper threshold c' shown in figure 5(b)), by reducing the transmitter power as described previously for TPC. After congestion control has been implemented the congestion reduction control module 38 maintains congestion control at the same level whilst continuing to monitor the number of vehicles from which ITS signals are being received. If the number of vehicles once again rises above (or does not drop below) the enforcement threshold, then the congestion reduction control module 38 further enforces congestion control by reducing transmitter power further (subject to any maximum reduction). If the number of vehicles from which ITS signals are being received drops below a pre-defined moderation' threshold (e.g. the lower threshold a' shown in figure 5(b)), then the congestion reduction control module 38 moderates congestion control by increasing transmitter power subject to an ordinary' (in this case maximum) transmitter power level.
In this embodiment, to reduce the risk of repeated oscillation between enforcement and moderation of congestion control the amount by which the congestion reduction control module 38 reduces transmitter power during each enforcement step is greater than the amount by which the congestion reduction control module 38 increases transmitter power during each moderation step.
In another embodiment the congestion control level is enforced or moderated by increasing or decreasing the interval between transmitted signals (SIC) respectively.
In such an embodiment it will be appreciated that the controllable parameter may be thought of as the rate with which signals are transmitted which decreases as the interval between transmitted signals increases. In yet another embodiment the congestion control level is enforced or moderated by decreasing or increasing the size of transmitted messages respectively (MSC). In the case of SIC, for example, the amount by which the signal interval is increased during an enforcement step is greater than the amount by which the signal interval is decreased during a moderation step. In the case of MSC, the amount by which the message size is reduced during an enforcement step is greater than the amount by which the signal interval is increased during a moderation step.
In other embodiments, the inputs I' may alternatively or additionally comprise a channel usage parameter as described previously and the thresholds used for congestion control level management, and the intermediate level, would be adapted accordingly. For example, the threshold a' would represent a lower channel usage threshold, the intermediate level b' would be an intermediate channel usage level, and the threshold c' would represent an upper channel usage threshold limit.
Figures 7(a) and (b) -Operation of the Congestion Reduction Control Module Figures 7(a) and (b) are flow diagrams each illustrating, in more detail, a different possible method of operation of the congestion reduction control module 38 of Figure 6 to manage the level of congestion control.
As explained above, the congestion status analysis module 36 monitors congestion on the communications channel(s) to determine a communication congestion level within the channel (or channels) over which signals are being transmitted and/or received. In accordance with this, the congestion status analysis module 36 measures the parameters indicative of the level of congestion and passes the associated inputs I' to the congestion reduction control module 38 for receipt, analysis, and monitoring by the input analysis sub-module 64 at step S61 in Figure 7(a).
The congestion reduction control module 38 monitors the prevailing conditions indicated by the congestion status analysis module 36 (steps S61 and S62) and continues to do so as long as the number of vehicles from which ITS signals are received (representing the prevailing signal congestion level) is determined, at step S62, to remain between the enforcement threshold c' and the moderation threshold a'.
When the number of vehicles from which ITS signals are received is determined, at step S62, to exceed the pre-determined threshold c' (the above mentioned enforcement threshold), the congestion reduction control module 38 determines that congestion control should preferably be enforced (or reinforced) and follows the leftmost (enforcement) branch shown in Figure 7(a). In this embodiment, however, prior to any enforcement of congestion control, the congestion reduction control module 38 checks, at step S68, that the level of congestion control applied has not reached a maximum level (in this case by checking if the transmitter power level has dropped to or below a pre-determined minimum level). If the maximum congestion control limit has been reached, then the congestion reduction control module 38 returns to monitoring steps S61 and S62. Otherwise congestion control is enforced by reducing the transmitter power (TPC), at step S64, by a predetermined amount NTX1'. In other embodiments the level of congestion control being applied is enforced by increasing the signal interval (SIC) or reducing the message size (MSC). After enforcement of congestion control in step S64 the congestion reduction control module 38 in this exemplary method returns to steps S61 and S62 to continue monitoring the prevailing congestion conditions.
When the number of vehicles from which ITS signals are received is determined, at step S62, to have dropped below the pre-determined moderation threshold a' (e.g. as a result of a congestion control request sent by the communication unit 6 to other communication units 6, at step S16 in Figure 3) the congestion reduction control module 38 determines that the level of congestion control should be moderated unless no congestion control is currently in operation (e.g. the transmitter power is at its ordinary level). Accordingly, the congestion reduction control module 38 follows the rightmost (moderation) branch shown in Figure 7(a). In this embodiment, prior to any action to moderate the level of congestion control, the congestion reduction control module 38 checks, at step S78 that (in this embodiment) the transmitter power level is not at (or exceeding) its ordinary level. If there is no congestion control currently in operation (the transmitter power is at its ordinary or maximum level) the congestion reduction control module 38 simply returns to monitoring steps S61 and S62. Otherwise congestion control is moderated by increasing the transmitter power (TPC), at step S72, by a predetermined amount nTx which is less than NTX1. After moderation of congestion control at step S72 the congestion reduction control module 38 in this exemplary method returns to steps S61 and S62 to continue monitoring the prevailing congestion conditions.
Thus, after each enforcement step (step S64) or moderation step (step S72) the congestion reduction control module 38 returns to monitoring the prevailing congestion conditions (steps S61 and S62) as described above. Accordingly, if after an earlier enforcement/moderation step the number of vehicles from which ITS signals are received is again found, at step S62, either to drop below the moderation threshold a', or to rise above the enforcement threshold c' then the congestion reduction control module 38 respectively moderates or enforces congestion control (subject to reaching any moderation or enforcement limit at step S78 or S68 respectively). The congestion control reduction module 38 monitors the level of congestion control being applied (e.g. the transmitter power level) after each iteration, thereby allowing the size of each enforcement and moderation step to be adjusted (if required) in dependence on the existing level of congestion control. This provides additional flexibility to tune the system for different applications and/or traffic scenarios. If, for example, the number of vehicles from which ITS signals are received is found to exceed the enforcement threshold c' a second time in succession, the congestion reduction control module 38 determines that a previous enforcement step has already occurred and therefore when repeating step S64 enforces the congestion control level by a second amount NTX2', which may be smaller or larger than NTX1 but greater than nTX. In this embodiment, as an example, the moderation amount n-T-X is substantially equal to one third of the first enforcement amount NTX1 and one half the second enforcement amount NTX2. However, the ratio of the moderation amount to either of the enforcement amounts may be any suitable value. It will be appreciated that the congestion reduction control module 38 could alternatively or additionally monitor the number and/or size of the moderation and/or enforcement steps applied to keep track of the congestion control level being applied at any particular point in time.
Accordingly, in the method of Figure 7(a) the communication unit 6 employs an asymmetric control method similar to that shown in Figure 5(b) for managing the congestion control level. This advantageously reduces the risk of undesirable oscillation between the transmitter power reduction steps and the transmitter power incremental steps used to manage signal congestion in the wider ITS.
Figure 7(b)illustrates an alternative control method that can be used to perform asymmetric congestion control. As shown, in step S31, the input analysis sub-module 64 monitors and analyses the inputs I' received from the congestion status analysis module 36 that are indicative of the level of congestion.
The congestion reduction control module 38 monitors the prevailing conditions indicated by the congestion status analysis module 36 (steps S31 and S32). When the number of vehicles from which ITS signals are received (representing the prevailing signal congestion level) exceeds a pre-determined threshold c' (the above mentioned enforcement threshold), the congestion reduction control module 38 determines that congestion control should be enforced (or reinforced). In this embodiment congestion control is enforced by reducing the transmitter power (TPC), at step S34, by a predetermined amount NTx1'. In other embodiments the level of congestion control being applied is enforced by increasing the signal interval (SIC) or reducing the message size (MSC).
After enforcement or reinforcement of congestion control in step 34, the congestion reduction control module 38 continues to monitor the prevailing congestion conditions (in steps S36, S38 and S40). If, at step S38, the number of vehicles from which ITS signals are received is found to be below the enforcement threshold c' the congestion reduction control module 38 continues to step S40. If, on the other hand, at step S38, the number of vehicles from which ITS signals are received is again found to exceed the enforcement threshold c' the congestion reduction control module 38 returns to step S34 to further enforce the congestion control level by a second amount NTX2' (subject to any limit on the enforcement level as described previously).
At step S40, the congestion reduction control module 38 determines if the number of vehicles from which ITS signals are received has dropped below another pre-determined threshold a' (the above described moderation threshold) which, in this embodiment, is set sufficiently below the enforcement threshold c' to ensure that the risk of oscillation is negligible. When the number of vehicles from which ITS signals are received is found to have dropped below the moderation threshold a' (e.g. as a result of a congestion control request sent by the communication unit 6 to other communication units 6, at step S16 in Figure 3) the congestion reduction control module 38 determines that the level of congestion control should be moderated. In this embodiment congestion control is moderated by increasing the transmitter power (TPC), at step S42, by a predetermined amount n-T-X which is less than the enforcement amount NTX1 or NTX2. In this embodiment, as an example, the moderation amount n-T-X is substantially equal to one third of the first enforcement amount NTX1 and one half the second enforcement amount NTX2. However, the ratio of the moderation amount to either of the enforcement amounts may be any suitable value.
After the initial moderation step S42 the congestion reduction control module 38 continues to monitor the prevailing congestion conditions (steps S44 and S46) until the number of vehicles from which ITS signals are received is found, at step S46, to drop below the moderation threshold a' again. When the number of vehicles from which ITS signals are received drops below the moderation threshold a' at step S42 the congestion reduction control module 38 determines, at step S48, if the ordinary (predetermined level at no congestion status) transmitter power level has been reached. If the ordinary transmitter power level has not been reached the congestion reduction control module 38 returns to step S42 and the transmitter power is again increased by the predetermined amount nTx. If the ordinary transmitter power level has been reached then the congestion reduction control module 38 returns to the start of the management process and the congestion monitoring of steps S31 and S32 resumes.
Accordingly, in the method of Figure 7(b) the communication unit 6 employs an asymmetric control method similar to that shown in Figure 5(b) for managing the congestion control level. This advantageously reduces the risk of undesirable oscillation between the transmitter power reduction steps and the transmitter power incremental steps used to manage signal congestion in the wider ITS.
The method of congestion control illustrated in Figure 7(b) is only suitable for systems where it will not be necessary to change from a congestion control moderation step to a congestion control enforcement step before the backward recovery process has returned to the ordinary level (illustrated in Figure 5). In particular, during the backward recovery process of Figure 7(b), the system will be performing congestion control moderation through steps S42 to S48 and there is no check to see if the level of congestion exceeds the enforcement threshold c'. In many systems this will not cause any problems, as it will be very unlikely that during the backward recovery process, congestion control will have to be enforced.
However, in systems where this can happen the method illustrated in Figure 7(a) should be used instead, as it checks the level of congestion against both a' and c' after a previous change has been made.
Congestion Control Level Management -Other Alternatives/Modifications Whilst in the above embodiments the moderation amount n--)( was described as being substantially equal to one third of the first enforcement amount NTX1 and one half the second enforcement amount NTX2, it will be appreciated that any suitable values may be selected for the enforcement and moderation steps in dependence on the nature of the parameter being controlled and the requirements of the implementation. For example, enforcement amount NTX1 may be equal to enforcement amount NTX2 and/or the moderation amount n-T-X may be approximately equal to a quarter, a fifth, or even a smaller fraction of either enforcement amount.
Further, the ratio(s) between either (or both) enforcement amounts and the moderation amount need not be an integer although use of an integer can be beneficial in certain applications. In other embodiments the moderation amount n-rx may be equal to one of the enforcement amounts (e.g. the second enforcement amount NTX2) but less than another enforcement amount (e.g. NTX1). nTx may also vary for each moderation step, for example to decrease as the ordinary (maximum) level is approached. It will be further appreciated that there may be any suitable numbers of enforcement steps and moderation steps with at least one of the moderation steps being smaller than at least one of the enforcement steps, thereby rendering the method asymmetric. Generally the number of moderation steps will exceed the number of enforcement steps, thereby rendering the method asymmetric.
Figures 8 to 10(b) -Illustrative Examples Figures 8 to 10(b) are control diagrams, similar to those of Figures 5(a) and 5(b) illustrating the method of managing the congestion control level described with reference to the flow chart of Figure 7(a) or 7(b). As described above, the controllable parameter in this implementation is the transmitter power although as shown in Figure 8 in the case of SIC the controllable parameter may be the signal rate (i.e. inverse of signal interval). The observable parameter in this implementation is the number of vehicles from which ITS signals are being received although as shown in Figure 8 the observable parameter may be a channel usage parameter (or any other parameter indicative of signal congestion). Indeed, in some embodiments, both the number of vehicles and the channel usage may be used as observable parameters for congestion control.
Figure 8 shows a control diagram illustrating the method of Figure 7(a) in overview.
As seen in Figure 8 the ITS starts with the transmitter power at an ordinary (in this case maximum) level (corresponding to steps S31 and S32 in Figure 7(a) or steps S61 and S62 in Figure 7(b)). When the number of vehicles from which ITS signals are received reaches (or exceeds) the enforcement threshold c' (e.g. at step S32 or S38 in Figure 7(a) or step S62 in Figure 7(b)) the congestion reduction control module 38 causes a forward' step in which transmitter power is reduced (by NTX1 in the case of S32 or a first iteration of S62 and by NTX2 in the case of S38 or a second iteration of S62). When the number of vehicles from which ITS signals are received drops below the moderation threshold a' (e.g. at step S40 or S46 in Figure 7(a) or step S62 in Figure 7(b)) the congestion reduction control module 38 causes a backward' step in which transmitter power is increased (by nTx) unless the ordinary transmitter power has been reached (e.g. at step S48 in Figure 7(a) or step S78 in Figure 7(b)).
As shown by the multiple dashed arrows shown for each backward step in Figure 8 the communication unit 6 cannot determine, with any degree of certainty, how signal congestion will reduce after the backward step (for example as a result of backward steps taken by other communication units 6, as a general result of the movement of vehicles in the area, and/or as a result of other factors). Accordingly, after the backward step there is uncertainty as to whether there will be zero, one, two, or any other number (n) of additional vehicles contributing to signalling (and hence possible congestion) in the channel. In part, it is the potential adverse effects of this uncertainty (e.g. oscillation between forward and backward steps) which the use of asymmetric control can be used to alleviate.
Figures 9(a) to 9(j) each illustrate a different time point or period during operation according to the method of Figure 7(a) or 7(b) in a first scenario.
As shown in Figures 9(a) the communication unit 6 to which the figure relates starts in an uncongested situation in which the number of vehicles transmitting ITS signals over the channel varies (as indicated by the position of the star) but remains relatively low below a conceptual pre-congestion' level. In this example, the pre-congestion' level is at the intermediate level b' (mentioned above) for ease of explanation. As the number of vehicles increases, the communication unit 6 enters a pre-congestion' situation, as illustrated in Figure 9(b), in which the number of vehicles transmitting ITS signals over the channel lies between the level b' and the enforcement threshold c'. In this situation the congestion reduction control module 38 is operating between steps S31 and S32 in Figure 7(a) or between steps S61 and S62 in Figure 7(b).
Figure 9(c) illustrates the situation immediately after the congestion reduction control module 38 determines, at step S32 or step S62, that the number of vehicles from which it is receiving ITS signals has exceeded the enforcement threshold c' and accordingly that congestion control is required. The congestion reduction control module 38 initiates a reduction in transmitter power (by NTX1 at step S34 or step S64) as indicated by the dashed arrow (subject to any limit e.g. at step S68). This reduction, and corresponding reductions at other communication units 6, result in a reduction in the number of vehicles from which the ITS signals are being received to an intermediate level b' (which may vary as mentioned above). The communication unit 6 to which Figures 9(a) to 9(j) relate is then in an uncongested situation as shown in Figure 9(d) in which the number of vehicles transmitting ITS signals over the channel varies (in this scenario) between level b' and the moderation threshold a' (as indicated by the position of the star).
Figure 9(e) illustrates the situation immediately after the congestion reduction control module 38 determines, at step S40 or a further iteration of step S62, that the number of vehicles from which it is receiving ITS signals has dropped below the moderation threshold a' and accordingly that moderation in congestion control level is required.
The congestion reduction control module 38 initiates an increase in transmitter power (by n-T-X at step S42) as indicated by the dashed arrows (0 to n). As described previously, prior to the increase in transmitter power (at step S42 or step S72), the number of vehicles from which ITS signals will be received, after the increase in transmitter power, is unknown (as indicated by the presence of multiple arrows). In this example, as indicated by the position of the star, after the increase in transmitter power there is one additional vehicle from which ITS signals are being received.
As shown in Figure 9(f), in this example, after the increase in transmitter power at step S42 or step S72, the transmitter power is maintained while the number of vehicles from which signals are being received remains above the moderation threshold a' (with the congestion reduction control module 38 operating between steps S44 and S46 in Figure 7(a) or between steps S61 and S62 in Figure 7(b)).
When the number of vehicles drops below the moderation threshold a' again, as shown in Figures 9(g), the congestion reduction control module 38 initiates a further (second) increase in transmitter power (by n-T-X at step S42 or step S72) as indicated by the dashed arrows. However, as shown in Figure 9(h), in this example the transmitter power is still not returned to the ordinary level. Instead the transmitter power is maintained at a level which is lower than its maximum whilst the number of vehicles from which signals are being received remains above the moderation threshold a'. Only when the number of vehicles drops below the moderation threshold for a third time (in this example), as shown in Figure 9(i), does the congestion reduction control module 38 initiate a yet further (third) increase in transmitter power (by nTXat step S42 or step S72) which, in this example, takes the transmitter power back to its ordinary level.
Accordingly, the congestion reduction control module returns to its initial monitoring state of steps S31 and S32 (in the case of Figure 7(a)) or S61 and S62 (in the case of Figure 7(b)). Hence, as shown in Figure 9(j), after the yet further (third) increase in transmitter power, the communication unit 6 is effectively back in the original state of Figure 9(a).
In this example the enforcement threshold c' is set at 30 vehicles whilst the moderation threshold is set at 20 vehicles and, accordingly, the intermediate pre-congestion level b' is in the region of 25 vehicles. It will be appreciated, however, that any suitable threshold values may be selected.
Figures 10(a) and 10(b) each illustrate a different time point or period during operation according to the method of Figure 7(a) or 7(b) in a second scenario. In this second scenario the first stages are essentially the same as those shown for the first scenario in Figures 9(a) to 9(c). However, unlike the first scenario, after the initial reduction in transmitter power at step S34 or step S64 the number of vehicles from which signals are being received increases (rather than decreases) until the enforcement threshold c' is reached once again as shown in Figure 10(a).
Accordingly, as shown in Figure 10(a), the congestion reduction control module 38 determines, at step S38 or a second iteration of step S62, that the number of vehicles from which it is receiving ITS signals has once again exceeded the enforcement threshold c' and initiates a further reduction in transmitter power (by NTX2 -either at step S34 or in a second iteration of step S64).
As shown in Figure 10(b), in this second scenario, after the second reduction in transmitter power the communication unit 6 maintains the same low transmitter power until the number of vehicles is determined (at step S46 or S62) to have fallen back to the moderation threshold a'. After the number of vehicles falls below the moderation threshold a', the transmitter power is increased iteratively each time the number of vehicles is determined (at step S46 or S62) to fall below the threshold a', whilst the transmitter power is determined to remain below the ordinary level (at step S48 or step S78).
When the congestion reduction control module 38 detects the return of transmitter power to the ordinary level the congestion reduction control module 38 returns to the initial monitoring state of steps S31 and S32 (in Figure 7(a)) or steps S61 and S62 (in Figure 7(b)) which is essentially the same as the original state shown in Figure 9(a).
Accordingly, the communication unit 6, and the method of managing the congestion control level used by it (as illustrated in Figures 6 to 10(b)) reduces the risk of undesirable oscillation between the transmitter power reduction steps and the transmitter power incremental steps used to manage signal congestion in the wider ITS.
Modifications and Alternatives A number of detailed embodiments have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above embodiments whilst still benefiting from the inventions embodied therein.
In the above embodiments, a vehicle based telecommunications network was described. As those skilled in the art will appreciate, the signalling techniques described in the present application can be employed in other communications systems. Furthermore the vehicle based and road-side communication units may comprise any suitable communication nodes or devices, for example, dedicated vehicle communication units, mobile telephones, personal digital assistants, laptop computers, etc. In the embodiments described above, the vehicle based communication units each include transceiver circuitry. Typically this circuitry will be formed by dedicated hardware circuits. However, in some embodiments, part of the transceiver circuitry may be implemented as software run by the corresponding controller.
In the above embodiments, a number of hardware and/or software modules were described. As those skilled in the art will appreciate, where all or part of the module's functionality is provided in software, the software may be provided in compiled or un-compiled form and may be supplied to the communication units as a signal over a computer network, or on a recording medium. Whilst, part or all the functionality performed by the modules may be performed using one or more dedicated hardware circuits, the use of software modules is preferred as it facilitates the updating of the communication units in order to update their functionalities.
In the above embodiments the congestion status analysis module is described as being operable to determine a communication congestion level based on measurements of a channel usage parameter. The measurements may assess, for example, how many messages or how much data is being transmitted on the channel within in a predetermined period of time. Such measurements may be carried out at layer 2 (e.g. in MAC layer). It will be appreciated that the congestion status analysis module may alternatively or additionally determine a communication congestion level based on an assessment of the number of different vehicle based (and possibly road-side) communication units from which signals are being received.
Such measurements may, for example, be carried out at layer 3 (Network layer).
It will be appreciated, however, that the measurements may alternatively or additionally include other measurements from which a congestion level may be derived, for example measurements of the number of received signals having certain characteristics (e.g. as extracted I detected by the received signal analysis module 32).
It will be further appreciated that the congestion reduction control module 38 may be operable to implement any suitable congestion reduction mechanism and may use any appropriate combination of such mechanisms (at different times or substantially simultaneously) to optimise congestion reduction control. For example, the congestion reduction control module 38 may be operable to initiate a different mechanism (or combination of mechanisms) in response to a congestion reduction request than in response to a change in the prevailing congestion conditions. The congestion reduction control module 38 may also be operable to initiate a different mechanism when another mechanism has already been used (or has been used to a maximum permitted level). Furthermore, the congestion reduction control module 38 may be operable to initiate generation and transmission of a congestion control request requesting implementation of a different mechanism respectively to different vehicles. For example, a request for one mechanism may be sent to vehicles ahead of, and a request for a different mechanism sent to those vehicles behind, the vehicle making the request. Similarly, a request for one mechanism (e.g. TPC) may be sent to vehicles beyond a certain distance away and a request for a different mechanism (e.g. SIC and/or MSC) may be sent to vehicles which are closer.
Operation of the communication units has been described sequentially with reference to a flow diagram (Figure 3) for the purposes of clarity. It will be appreciated, however, that many of the steps need not run sequentially but may run in parallel with other steps.
It will be appreciated that although the sequential time interval diagrams (Figures 4(a) to 4(e)) illustrate the benefits of embodiments of the invention in which TPC is used to manage congestion levels, the same benefits follow for other implementations, for example in which SIC and/or MSC are used. In the case of SIC, for example, the length of arrows may be considered conceptually to represent the interval between signals but with longer arrows representing shorter intervals and vice versa.
The congestion control request may include information identifying the geographical position of the vehicle making the request, as acquired by the vehicle's GNSS. The antenna for the GPS may or may not be different from that of the communication unit. Location information may be broadcast to other nearby vehicles via vehicle to vehicle communication or infrastructure to vehicle communication. Similarly, geographical location information for other vehicles may be received with the congestion request in step S24 Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

Claims (14)

  1. Claims 1. A communication node for communicating with at least one further communication node over a communication channel, the communication node comprising: means for obtaining an observable parameter indicative of a congestion state of the communication channel; means for determining if the communication channel is in a first congestion state or a second congestion state from said observable parameter; and a congestion controller for performing congestion control by varying a control parameter that affects the congestion state of the communication channel; wherein said congestion controller: i) is operable in a forward process, when said observable parameter indicates said channel is in said first congestion state, to change a level of congestion control applied from a first level to a second level by varying said control parameter in one or more steps; and ii) is operable in a backward process, when said observable parameter indicates said channel is in said second congestion state, to change the level of congestion control applied from said second level back to said first level by varying said control parameter in two or more steps, such that the level of congestion control is changed in an asymmetric manner between said forward and backward processes.
  2. 2. A communication node according to claim I wherein said congestion controller is operable to: change the level of congestion control applied, in at least one step of said forward process, by varying the control parameter by a first amount; and to change the level of congestion control applied, in at least one step of said backward process, by varying the control parameter by a second amount; wherein said second amount is less than said first amount whereby the level of congestion control is changed in said asymmetric manner between said forward and backward processes.
  3. 3. A communication node according to claim I or 2 wherein said congestion controller is operable: to vary the control parameter in a first number of steps in said forward process; and to vary the control parameter in a second number of steps in said backward process; wherein said second number of steps is greater than said first number of steps whereby the level of congestion control is changed in said asymmetric manner between said forward and backward processes.
  4. 4. A communication node according to any preceding claim wherein said forward process is a process in which said level of congestion control is increased and wherein said backward process is a process in which said level of congestion control is decreased.
  5. 5. A communication node according to any preceding claim wherein the first level of congestion control is a level in which no congestion control is applied and in which said control parameter is at a normal operational value.
  6. 6. A communication node according to any preceding claim wherein the second level of congestion control is a level in which a maximum level of congestion control is applied and in which said control parameter is at a pre-defined limit.
  7. 7. A communication node according to any preceding claim wherein said control parameter represents at least one of a transmitter power, a signal interval, and a message size.
  8. 8. A communication node according to claim 7 wherein said control parameter represents a transmitter power and said pre-defined limit is a maximum transmitter power.
  9. 9. A communication node according to claim 7 wherein said control parameter represents a signal interval (or signal rate) and said pre-defined limit is a minimum signal interval (or maximum signal rate).
  10. 10. A communication node according to any preceding claim wherein the observable parameter represents at least one of a number of vehicles from which signals are being received and a channel usage parameter.
  11. 11. A communication node according to any preceding claim wherein the determining means is operable to determine the congestion state of the communication channel by comparison of the observable parameter with at least one threshold.
  12. 12. A communication node according to any preceding claim 11 wherein the determining means is operable to determine the communication channel to be in the first congestion state by comparison of the observable parameter with a first threshold, and to determine the communication channel to be in the second congestion state by comparison of the observable parameter with a second threshold.
  13. 13. A communication node according to any preceding claim 12 wherein the determining means is operable to determine the congestion state of the communication channel to be the first congestion state if the observable parameter exceeds (or equals) the first threshold, and to be the second congestion state if the observable parameter is less than (or equals) the second threshold.
  14. 14. A method performed by a communication node capable of communicating with at least one further communication node over a communication channel, the communication node comprising: obtaining an observable parameter that is indicative of a congestion state of the communication channel; determining, from said observable parameter, if the communication channel is in a first congestion state or a second congestion state; and performing congestion control by varying a control parameter that affects the congestion state of the communication channel; wherein congestion control comprises: i) when said observable parameter indicates said channel is in said first congestion state, changing a level of congestion control applied, in a forward process, from a first level to a second level by varying said control parameter in one or more steps; and ii) when said observable parameter indicates said channel is in said second congestion state, changing the level of congestion control applied, in a backward process, from said second level back to said first level by varying said control parameter in two or more steps, such that the level of congestion control is changed in an asymmetric manner between said forward and backward processes.
GB0916801A 2009-06-23 2009-09-24 Using a control parameter to control the level of communication message congestion in and between nodes in a wireless vehicle to vehicle network. Withdrawn GB2471347A (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB0910810A GB2471287A (en) 2009-06-23 2009-06-23 Communication message congestion control for the nodes of an intelligent transport system.

Publications (2)

Publication Number Publication Date
GB0916801D0 GB0916801D0 (en) 2009-11-04
GB2471347A true GB2471347A (en) 2010-12-29

Family

ID=40972625

Family Applications (2)

Application Number Title Priority Date Filing Date
GB0910810A Withdrawn GB2471287A (en) 2009-06-23 2009-06-23 Communication message congestion control for the nodes of an intelligent transport system.
GB0916801A Withdrawn GB2471347A (en) 2009-06-23 2009-09-24 Using a control parameter to control the level of communication message congestion in and between nodes in a wireless vehicle to vehicle network.

Family Applications Before (1)

Application Number Title Priority Date Filing Date
GB0910810A Withdrawn GB2471287A (en) 2009-06-23 2009-06-23 Communication message congestion control for the nodes of an intelligent transport system.

Country Status (1)

Country Link
GB (2) GB2471287A (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017123500A1 (en) * 2016-01-12 2017-07-20 Qualcomm Incorporated Lte based v2x communication qos and congestion mitigation
CN107079265A (en) * 2015-03-04 2017-08-18 华为技术有限公司 A kind of communication means and relevant device
US11177893B2 (en) 2016-12-21 2021-11-16 Telefonaktiebolaget Lm Ericsson (Publ) ITS status indication

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ITTO20120787A1 (en) * 2012-09-12 2014-03-13 Dell Informazione E Delle Telecomunicazioni METHOD AND SYSTEM FOR CHECKING THE CONGESTION IN WIRELESS TELECOMMUNICATIONS NETWORKS
CN107734544B (en) * 2016-08-11 2021-05-07 上海诺基亚贝尔股份有限公司 Method and apparatus for congestion control
GB2583726B (en) * 2019-05-03 2022-03-02 Samsung Electronics Co Ltd Network and control thereof
WO2023051914A1 (en) * 2021-09-30 2023-04-06 Huawei Technologies Co., Ltd. Method and device for controlling interference among autonomous wireless communication links

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6038218A (en) * 1995-08-30 2000-03-14 Fujitsu Limited Congestion control in signalling network of common channel signalling system
US20050124369A1 (en) * 2003-12-03 2005-06-09 Attar Rashid A. Overload detection in a wireless communication system
US20080056125A1 (en) * 2006-09-06 2008-03-06 Nokia Corporation Congestion control in a wireless network
EP1906693A2 (en) * 2006-09-29 2008-04-02 NTT DoCoMo, Inc. Communication control method, radio base station and radio control station
WO2009075097A1 (en) * 2007-12-12 2009-06-18 Panasonic Corporation Data transmission/reception system, terminal, relay device, and data transmission method

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6615137B2 (en) * 2001-06-26 2003-09-02 Medius, Inc. Method and apparatus for transferring information between vehicles
US6721632B2 (en) * 2002-02-05 2004-04-13 International Business Machines Corporation Wireless exchange between vehicle-borne communications systems
WO2006065896A2 (en) * 2004-12-17 2006-06-22 Meshnetworks, Inc. System and method for controlling congestion in multihopping wireless networks
US7433773B2 (en) * 2005-10-11 2008-10-07 Nissan Technical Center North America, Inc. Vehicle on-board unit
KR100715677B1 (en) * 2005-12-02 2007-05-09 한국전자통신연구원 Congestion control access gateway system and method for congestion control in congestion control access gateway system
TWI459754B (en) * 2007-01-12 2014-11-01 Koninkl Philips Electronics Nv Method of congestion management in a wireless mesh network

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6038218A (en) * 1995-08-30 2000-03-14 Fujitsu Limited Congestion control in signalling network of common channel signalling system
US20050124369A1 (en) * 2003-12-03 2005-06-09 Attar Rashid A. Overload detection in a wireless communication system
US20080056125A1 (en) * 2006-09-06 2008-03-06 Nokia Corporation Congestion control in a wireless network
EP1906693A2 (en) * 2006-09-29 2008-04-02 NTT DoCoMo, Inc. Communication control method, radio base station and radio control station
WO2009075097A1 (en) * 2007-12-12 2009-06-18 Panasonic Corporation Data transmission/reception system, terminal, relay device, and data transmission method
EP2109339A1 (en) * 2007-12-12 2009-10-14 Panasonic Corporation Data transmission/reception system, terminal, relay device, and data transmission method

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107079265A (en) * 2015-03-04 2017-08-18 华为技术有限公司 A kind of communication means and relevant device
EP3253085A4 (en) * 2015-03-04 2017-12-27 Huawei Technologies Co., Ltd. Communication method and related device
WO2017123500A1 (en) * 2016-01-12 2017-07-20 Qualcomm Incorporated Lte based v2x communication qos and congestion mitigation
US10992589B2 (en) 2016-01-12 2021-04-27 Qualcomm Incorporated LTE based V2X communication QOS and congestion mitigation
US11177893B2 (en) 2016-12-21 2021-11-16 Telefonaktiebolaget Lm Ericsson (Publ) ITS status indication

Also Published As

Publication number Publication date
GB0910810D0 (en) 2009-08-05
GB2471287A (en) 2010-12-29
GB0916801D0 (en) 2009-11-04

Similar Documents

Publication Publication Date Title
TWI751974B (en) Safety event message transmission timing in dedicated short-range communication (dsrc)
JP7223153B2 (en) Methods for predicting channel load
US9521575B2 (en) Congestion control device and method for inter-vehicle communication
GB2471347A (en) Using a control parameter to control the level of communication message congestion in and between nodes in a wireless vehicle to vehicle network.
US10147322B2 (en) Safety-compliant multiple occupancy of a channel in intelligent transportation systems
EP2400808A1 (en) Method and system for broadcast message transmission in mobile systems
US11622230B2 (en) Method and apparatus for motion-based vehicle ranging
US20190029002A1 (en) Intelligent vehicle-based communication mangement
EP3354048B1 (en) Speed dependent transmission format for vehicular or d2d transmission
US10657820B2 (en) Sensor data sharing management
US20140092735A1 (en) Apparatus and method for controlling congestion in vehicular communication
CN112243597A (en) Resource allocation scheme for vehicle-to-vehicle (V2V) communication
JP2012205116A (en) On-vehicle communication device and vehicle-to-vehicle communication method
KR102211787B1 (en) Method and apparatus for evading resource collision in mobile communication system
CN105915463A (en) Congestion control method and apparatus thereof
EP4167209A1 (en) Cooperative intelligent transport system and method with cpm generation control based on significance index and information significance level
EP4167611A1 (en) Cooperative intelligent transport system and method with cpm significance index for redundancy mitigation
CN115119165A (en) Method, apparatus, and readable storage medium for controlling power for V2X communication
WO2021209156A1 (en) Apparatus, method and computer program for stable and safe vehicle platooning operations
CN115696256A (en) Internet of vehicles message self-adaptive sending method, device, equipment and storage medium

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)