Method and system for controlling congestion in a private train network

Abstract

The present invention provides a method for controlling congestion in a private train network, the private train network comprising a plurality of roadside units deployed along a railway track and each connected to an application server, each of the plurality of roadside units configured to establish sidelink communication with at least one train based on a wireless network and configured to make independent distributed congestion control decisions, the communication sharing a common sidelink resource pool. The method includes: aggregating congestion control information from a subset of the plurality of roadside units and rail application information by an application server; predicting a congestion status of each of the subset of the plurality of roadside units by the application server based on the aggregated congestion control information and the rail application information; calculating and providing assistance information by the application server to the subset of the plurality of roadside units based on the predicted congestion status; and performing distributed congestion control by the subset of the plurality of roadside units based on the assistance information. The present invention improves congestion control in a private train network.

Description

[Technical Field]

[0001] The present invention relates to a method and system for controlling congestion in a network, and in particular for controlling congestion in a private train network. [Background technology]

[0002] In next-generation railway communication systems, various railway-specific applications are being considered, and train-to-infrastructure (T2I) links and train-to-train (T2T) links are used for packet transmission for these applications. For T2I and T2T communications, various radio access technologies are used, such as Wi-Fi™, Long Term Evolution (LTE)™, 5G, and satellite. Among these technologies, 5G NR V2X-based sidelink communication technology is likely to be one of the very promising candidates for T2I and T2T communications, as it can provide fairly good performance in distributed communication scenarios.

[0003] In distributed scenarios such as 5G NR sidelink communications in Mode 2, a critical issue is congestion control. Congestion control is a mechanism for regulating data packet input to the network and managing shared resources in an efficient and fair manner to avoid congestion collapse. 5G NR V2X Mode 2 can apply a distributed congestion control (DCC) scheme. The standard does not define a specific congestion control algorithm, but rather defines related metrics and possible countermeasures to reduce channel congestion. These metrics are the channel busy ratio (CBR) and channel occupancy ratio (CR), which are referred to as sidelink (SL) CBR and SL CR in Rel. 16. The CBR is the perspective of a specific TX UE with respect to the subchannels occupied in a resource pool in a time window. A subchannel is considered occupied if its measured RSSI exceeds a (pre-configured) threshold. The CR is the perspective of a specific TX UE with respect to the subchannels that this TX UE utilizes or selects in a time window. By definition, the CR reflects, for each TX UE, the amount of resources that this UE has occupied in the shared resource pool. The TX UE uses the measured SL CBR and SL CR to identify whether it needs to change its transmission parameters to reduce the channel load. This is done using a (pre-)configured look-up table containing up to 16 CBR ranges. Each range is bounded by a maximum SL CR (CR) that the TX UE must not exceed. limit ) and linked. CR limit increases as the CBR range decreases. 3GPP (trademark) specifies the CR for each CBR range. limit This standard establishes that the value of is a function of the priority of the transport block (TB) and the absolute rate of the TX UE. limit It specifies that the transmission parameters must be changed at each (re)transmission to evaluate whether the maximum transmission time (TTS) exceeds the threshold.

[0004] The TX UEs can observe the evolution of their CR and the CBR of the shared resource and take action to limit their contribution to the occupancy of the shared resource, thus limiting congestion in a distributed manner.

[0005] Figure 1 shows a system in the field of such a next-generation railway communication network. It includes roadside units (RSUs) deployed in a private train network. Communication between the RSUs and trains is based on NR V2X sidelink mode 2. In this mode, all T2I communications are assumed to share a common sidelink resource pool. For communication data packets to be sent from the RSUs to target trains, each RSU is responsible for congestion control using the DCC mechanism. In addition, private train networks are typically deployed and managed by railway operators aiming to provide dedicated railway applications. For this reason, there is typically an application server that provides each RSU with higher-layer information about the railway application. This application server is a central node connected to each RSU, as shown in Figure 1.

[0006] As mentioned above, in the current technology, railway communication from RSUs to trains in the above-mentioned private train network is based on NR V2X sidelink mode 2 as shown in Figure 1, and congestion control is based on DCC implemented at each RSU. Furthermore, it is assumed that the RSUs in the scenario share the same sidelink resource pool. Therefore, in the DCC scheme, congestion in the sidelink resource pool is controlled in a distributed manner.

[0007] However, from the perspective of a private train network, DCC may not be optimal because it attempts to limit the impact of congestion on each RSU in the shared resource pool. Fairness is achieved by limiting the maximum CR (CR) that each RSU must not exceed. limit) However, from the perspective of the entire system, such a DCC mechanism is suboptimal. This is because in railway communication scenarios, communications are not evenly distributed in both time and space. T2I communications occur only when there is a moving train within the range of the RSU. Therefore, the connection and service traffic of T2I communications can be bursty. That is, there can be a very large amount of traffic for a short period of time, followed by idle periods for the rest of the time. Furthermore, in railway communication scenarios, unlike V2X, the number of trains is relatively small. Therefore, one RSU may be in a nearly congested situation with a very high CR, while another RSU may be completely idle and have no trains to communicate with. In this case, a DCC scheme that independently controls each CR behavior limits the overall system performance. Summary of the Invention

[0008] The present invention addresses these problems in the art and aims to improve overall system performance.

[0009] In this regard, according to one aspect of the present invention, there is provided a method for controlling congestion in a private train network, the private train network comprising a plurality of roadside units (RSUs) deployed along a railway track, each connected to an application server. Each of the plurality of roadside units (RSUs) is configured to establish sidelink communication with at least one train based on a wireless network, for example based on sidelink communication using a PC5 interface in NR V2X Mode 2, and is configured to make independent distributed congestion control (DCC) decisions. The communications share a common sidelink resource pool. The method includes: aggregating, by an application server, congestion control information from a subset of a plurality of road side units (RSUs) and railway application information in the application server; predicting, by an application server, a congestion status of each of a subset of a plurality of road side units (RSUs) based on the aggregated congestion control information and the railway application information; Calculating and providing, by an application server, aiding information to a subset of a plurality of road side units (RSUs) based on the predicted congestion status; performing distributed congestion control (DCC) by a subset of the plurality of road side units (RSUs) based on the auxiliary information; Includes.

[0010] Unlike conventional solutions, the present invention proposes to creatively use an application server that connects to all RSUs and has all necessary railway application information in the private train network. In such a configuration, the present invention aggregates congestion control-related information from multiple RSUs, takes into account the aggregated congestion control information for each RSU and the railway application information in the application server, predicts future congestion control performance, and provides the RSUs with auxiliary information for adjusting DCC in multiple RSUs, thereby improving congestion control performance in the entire private train network. Therefore, the method according to the present invention improves overall system performance.

[0011] Furthermore, when communication in the wireless network is based on sidelink communication using a PC5 interface in NR V2X Mode 2, the congestion control information is a sidelink channel busy ratio (SL CBR) and / or a sidelink channel occupancy ratio (SL CR).

[0012] Advantageously, the predicted congestion status comprises a prediction of a Sidelink Channel Busy Ratio (SL CBR) and / or a Sidelink Channel Occupancy Ratio (SL CR) of a subset of the plurality of Road Side Units (RSUs).

[0013] Optionally, the sidelink channel occupancy is 1000 slots or 1000 2 μThe sidelink channel busy rate is calculated based on a sliding window containing 100 slots or 100 2 μ is calculated based on a sliding window containing slots, where μ is [Table 1] is a numerological parameter with values in

[0014] Advantageously, the subset of multiple road side units (RSUs) is chosen based on their signal power and / or geographic distance. For example, a train could measure the received signal levels from different RSUs and keep only a limited subset (e.g., the two RSUs with the highest received power). Another possibility is that if the RSUs and the train are equipped with GNSS and can obtain positioning information, the train calculates the distance to each RSU and keeps a limited subset of the closest RSUs.

[0015] Advantageously, railway application information is traffic characteristics of the service flows, such as packet delay budget, packet size, traffic periodicity, guaranteed flow bit rate, maximum flow bit rate, packet error rate and / or priority level, transmitted from the roadside unit (RSU) to at least one train; at least one train position information, such as the train's instantaneous position and / or instantaneous speed; and / or Location-based channel condition fingerprint database. This is upper layer information including:

[0016] Advantageously, the auxiliary information is Transmission parameter changes for a subset of multiple roadside units (RSUs); Congestion parameter changes for a subset of multiple Road Side Units (RSUs), Assisted sidelink dual connectivity, and / or Assisted sidelink unicast link management; Regarding.

[0017] Advantageously, prior to the step of aggregating congestion control information, the method further comprises: selecting a subset of a plurality of road side units (RSUs); Calculating congestion control information by a subset of a plurality of road side units (RSUs) and reporting the congestion control information to an application server; Further includes:

[0018] Advantageously, the aiding information includes a timestamp, and the road side unit (RSU) ignores the aiding information if the timestamp has expired.

[0019] Advantageously, the method further comprises providing the auxiliary information to the at least one train.

[0020] Advantageously, the common sidelink resource pool is a resource pool of sidelink channels in both the time and frequency domain.

[0021] According to another aspect of the invention, there is provided a computer program comprising instructions which, when executed by a computer, cause the computer to carry out the method set out above.

[0022] According to yet another aspect of the present invention, there is provided a system for controlling congestion in a private train network, the private train network comprising a plurality of roadside units deployed along a railroad track, each connected to an application server, each of the plurality of roadside units configured to establish communication with at least one train based on a wireless network and configured to make independent distributed congestion control decisions, the communications sharing a common sidelink resource pool. an aggregation unit for aggregating, by an application server, congestion control information from a subset of the plurality of roadside units and railway application information in the application server; a prediction unit for predicting, by an application server, a congestion status of each of a subset of the plurality of roadside units based on the aggregated congestion control information and the railway application information; a computing unit for computing and providing, by the application server, assistance information to a subset of the plurality of roadside units based on the predicted congestion status; Equipped with A system is provided in which a subset of a plurality of road side units (RSUs) is configured to perform distributed congestion control based on the aiding information.

[0023] Therefore, the present invention relates to a communication infrastructure-to-train (RSU-to-train) system using sidelink communication (e.g., PC5 interface) based on wireless communication technologies such as 5G NR V2X sidelink communication mode 2. Here, each communicating entity (RSU or train) manages its own communication pair in a distributed manner. This means that there is no central node, such as a base station, that manages communication and resource allocation for all RSU-to-train communication pairs. Instead, each pair manages its own communication in a distributed and independent manner. Although the communications are managed in a distributed manner, a very important constraint is that the resources utilized by these communications are shared resources (sidelink resource pool) among all communicating pairs. Each node makes independent communication decisions, and because they operate on shared resources, there is a potential collision problem due to them not being aware of the decisions made by others. In the current technology, a distributed congestion control algorithm has been proposed to reduce this effect. In this scheme, there are two parameters measured by each node: CR and CBR. There are also some pre-set thresholds for DCC decisions. This means that each node continuously evaluates its CR and CBR, compares them with thresholds, and decides what to do to control congestion, e.g., drop a transmission, drop a retransmission, change transmission / retransmission parameters, etc. As mentioned above, traditional DCC methods are inefficient in private train networks. To solve this problem, the present invention proposes a dynamic algorithm for estimating and configuring DCC parameters (thresholds, transmission / retransmission parameters, etc.) by an application server, but still in a distributed manner so that the DCC algorithm can perform better to improve congestion control in private train networks.

[0024] Other features and advantages of the present invention will become apparent from the following description, taken in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0025] [Figure 1]FIG. 1 illustrates a private train network with an application server connected to an RSU. [Figure 2] 3 is a flowchart illustrating an exemplary method for coordinated, distributed congestion control with application server assistance in accordance with the present invention. [Figure 3] FIG. 1 illustrates a 1000 slot sliding window for CR calculation. [Figure 4] FIG. 10 is a diagram showing a CR prediction at time t+Δt. [Figure 5A] FIG. 1 illustrates a first example of generating auxiliary information, where an application server provides auxiliary information for modifying transmission parameters of future services / traffic. [Figure 5B] FIG. 1 illustrates a first example of generating auxiliary information, where an application server provides auxiliary information for modifying transmission parameters of future services / traffic. [Figure 5C] FIG. 1 illustrates a first example of generating auxiliary information, where an application server provides auxiliary information for modifying transmission parameters of future services / traffic. [Figure 6A] FIG. 10 illustrates a second example of generating auxiliary information, where the application server provides auxiliary information for modifying congestion parameters of future services / traffic. [Figure 6B] FIG. 10 illustrates a second example of generating auxiliary information, where the application server provides auxiliary information for modifying congestion parameters of future services / traffic. [Figure 6C] FIG. 10 illustrates a second example of generating auxiliary information, where the application server provides auxiliary information for modifying congestion parameters of future services / traffic. [Figure 7A] FIG. 10 illustrates a third example of generating auxiliary information, in which the application server provides the auxiliary information for maintaining a dual connection. [Figure 7B]FIG. 10 illustrates a third example of generating auxiliary information, in which the application server provides the auxiliary information for maintaining a dual connection. [Figure 8A] FIG. 10 illustrates a fourth example of generating auxiliary information, in which the application server provides the auxiliary information for selecting and establishing a unicast sidelink. [Figure 8B] FIG. 10 illustrates a fourth example of generating auxiliary information, in which the application server provides the auxiliary information for selecting and establishing a unicast sidelink. DETAILED DESCRIPTION OF THE INVENTION

[0026] 1 illustrates an exemplary configuration of a private train network comprising multiple roadside units (RSUs) deployed along railway tracks T1, T2, and T3, each connected to an application server (AS). Each of the multiple roadside units (RSUs) is configured to establish sidelink communication with at least one train based on a wireless network, and is configured to make independent distributed congestion control (DCC) decisions, with the communication sharing a common sidelink resource pool.

[0027] In this embodiment, communication in the wireless network is based on sidelink communication using the PC5 interface in NR V2X Mode 2, in which all nodes (RSUs, trains) communicate in a distributed manner without the involvement of the base station.

[0028] Furthermore, the application server AS is configured to provide / collect train application data. The application server AS also has higher layer information about the train application, such as the application's traffic characteristics (payload, periodicity, whether the traffic is bursty, etc.), the traffic's QoS (priority, packet delay budget, average / peak data rate, packet error rate), the train's instantaneous location, and the train's instantaneous speed. In this invention, the application server only aggregates (sends / receives) application data, but is not a node that controls the communication between the application server and the train. Therefore, it should be noted that the application server AS is not a central node (like a base station) that controls the communication.

[0029] In addition, an application server AS is deployed where train applications reside. There are typically three basic categories of train applications: critical, performance, and business applications. Examples of critical communication applications are automatic train control, automatic train operation, and automatic train protection. Examples of performance communication applications are voice communication for operational purposes, CCTV communication services for surveillance cameras, and train connectivity. Examples of business communication applications are onboard WiFi and wireless internet for passengers on the platform.

[0030] Furthermore, the sidelink (channel) resource pool exists in both the time and frequency domains for D2D (train-to-infrastructure) communications. When a transmitting node (e.g., an RSU) wants to communicate with a receiving node (e.g., a train), it needs to find a sidelink channel (e.g., a resource grid in frequency and time) to use for communication. The resource pool includes all available sidelink channels. In an NR V2X sidelink mode 2-based communication scheme, each transmitting node performs transmission in a distributed manner, i.e., without a central node for resource allocation. Therefore, each transmitting node must check each sidelink channel (each resource grid) to see if this sidelink channel is available (unoccupied) and, if so, select / reserve it for communication. Since each transmitting node does this, a collision occurs if two transmitting nodes happen to obtain the same sidelink resource. Another phenomenon is that in the absence of congestion control, for example, a transmitter is dumping too many packets at a certain point in time, taking up almost all sidelink channel resources, which causes later arriving high priority packets to be unable to transmit due to no available sidelink channels. Yet another example is one transmitting node taking up too many resources, leaving very few for other transmitters.

[0031] As mentioned above, DCC is used for congestion control in NR V2X Mode 2-based sidelink communications. DCC can limit the impact of congestion at each node and provide congestion level convergence in the system. However, this is a distributed approach, and each node makes independent DCC decisions, so it cannot optimize overall system performance by itself.

[0032] Based on the above network configuration, the present invention further proposes a private train network with an application server AS that connects to all RSUs and is aware of railway application information (train location, movement prediction...), thus coordinating the DCC in each RSU and providing auxiliary information to each RSU for DCC improvement.

[0033] In particular, the present invention proposes cooperative DCC with application server assistance for private train networks, which includes congestion control information aggregation in the application server, application server congestion prediction for each RSU based on the aggregated congestion control information and railway application information per RSU, and provision of assistance information by the application server to the RSUs for DCC improvement.

[0034] Detailed steps of an exemplary method for controlling congestion in a private train network according to the present invention are shown in FIG. 2 and described below.

[0035] Optionally, in step S1, a subset of multiple roadside unit RSUs is selected, where the subset of RSUs is RSUs that will coordinate their DCC measurements. The condition for selecting the subset of RSUs can be based on, for example, received signal power. For example, a train can measure received signal levels from different RSUs and only keep a limited subset (e.g., two RSUs with the largest received power). Another condition can be geographical distance. If the RSUs and the train are equipped with GNSS and can obtain positioning information, the train can calculate the distance to each RSU and keep a limited subset of the nearest RSUs. Note that the subset of roadside unit RSUs can be predetermined according to the above-mentioned condition or other preset rules, and this is not a required step in the present invention.

[0036] In a next step S2, a subset of the plurality of roadside units RSUs calculates and reports a sidelink (SL) channel busy rate CBR and a SL channel occupancy rate CR.

[0037] In particular, these two metrics SL CBR and SL CR are used for DCC in 5G NR V2X Mode 2 for sidelink communications. In NR V2X, SL CBR is set to 100 slots (any numerology) or 100 2 slots by (pre)configuration per resource pool. μ is the number of busy (energy > threshold) subchannels in the resource pool in a time window of 10 slots, where μ is the SCS configuration factor. CR is the number of 1000 slots (arbitrary numerology) or 1000 2 slots by (pre)configuration per resource pool. μ is the number of subchannels that the TX UE will use or select in a time window of 10 slots, where μ is the SCS configuration factor. The TX UE uses the measured SL CBR and SL CR to determine whether it must change its transmission parameters to reduce the channel load. This is done using a (pre-)configured lookup table containing up to 16 CBR ranges or configured by higher layer parameters (sl-CBR-RangeConfigList, sl-CR-Limit). Each range is bounded by a maximum SL CR (CR) that the UE must not exceed. limit Using the CBR observed by the TX UE and a lookup table of CBR ranges, the TX UE determines the CR that the TX UE must not exceed. limit and further ensures the following constraint for any priority value k if the UE transmits a PSSCH in slot n:

number

[0038] It is up to the UE implementation how to meet the above constraints, including dropping transmissions in slot n. The TX UE must ensure that the SL CR is equal to or greater than the CR. limit If the SL CR is exceeded, the TX UE must change its transmission parameters. The objective is to reduce the SL CR and control the channel load created by the TX UE.

[0039] In a next step S3, the application server receives the current SL CR and SL CBR from each of a subset of the plurality of road side units RSUs periodically or on demand.

[0040] It is noted that the present invention differs from conventional centralized congestion control schemes in the art, where a central node aggregates the CRs of all nodes in the network and makes congestion control decisions for all nodes.

[0041] On the contrary, in the present invention, only a subset of RSUs, rather than all RSUs, need to send their CRs and CBRs to the application server, which means that the cooperative DCC is local in the sense that the application server only needs to aggregate a few RSUs, which are a subset of all RSUs in the network.

[0042] In addition, in centralized congestion control in the art, it is a central node that controls the channel load and requests that each RSU report its measured CBR periodically or on-demand. The performance of the algorithm depends on the accuracy of the feedback of the CBR reports per RSU. This means that decisions made at the central node are more accurate if they are based on the reported CBR per RSU, which well reflects the instantaneous CBR of each RSU. In this case, frequent signaling of CBR reports from each RSU is required, and the backhaul between the RSU and the central node should be good enough to support such frequent reporting.

[0043] However, in the present invention, we configure well for limited backhaul between the RSU and the application server. The periodicity of (CBR, CR) reports can be adjusted according to the backhaul constraints, and the application server only coordinates DCC with the reporting RSU.

[0044] Furthermore, congestion control according to the present invention is always based on DCC, which means that it is always the individual RSU that makes the DCC decision. The application server simply provides the RSU with RSU aiding information that it considers useful for the corresponding RSU. In the present invention, it is up to the RSU to decide whether to take the aiding information into account for its own DCC procedure (explained in the following steps). For example, the RSU can simply ignore the aiding information from the application server if it finds that the aiding information is calculated based on out-of-date reports and is therefore not very relevant to the current situation at the RSU.

[0045] Furthermore, in step S3, in addition to receiving CR and CBR from the subset of RSUs, the application server AS further retrieves train application related information including traffic characteristics of service flows, train location information, and a location-based channel condition fingerprint database.

[0046] Based on the aggregated congestion control information and the railway application information, in a next step S4 the application server AS predicts the congestion status of each of the subsets at a future time.

[0047] In particular, in this step S4, after considering a particular sidelink unicast link configuration, for the RSUs that apply this configuration, the application server predicts the CR and CBR of the RSUs that apply this configuration.

[0048] For SL CR prediction, as mentioned above, the SL CR calculation is based on a sliding window. For ease of explanation, the CR is calculated using a sliding window of 1000 slots, as shown in Figure 3.

[0049] When the application server AS receives a CR report from an RSU, it can predict the CR of this RSU at a future time by taking into account the received CR and the railway application information in the application server. Assume that an application receives a CR report from an RSU at time t and wants to predict the CR of this RSU in the slot at time t+Δt. Figure 4 shows the CR prediction in the application server of an RSU at time t+Δt.

[0050] Since CR is calculated using a sliding window, the channel occupancy rate during [t+Δt-999,t] does not change. To predict CR at time t+Δt, we use the following two methods: i) the channel occupancy rate during the past time [t-999,t+Δt-999]

number

number

number

[0051]

number

number

[0052]

number

number

[0053] If the RSU still maintains communication with the train, and if the traffic dedicated to the train is periodic (NR V2X Mode 2 semi-persistent scheduling), it is assumed that the transmission from the RSU to the train during [t, t+Δt] will select and utilize the same number of subchannels as it had during [t-999, t+Δt-999]. In this case,

number

number

[0054] If the RSU still maintains communication with the train and the traffic is aperiodic (NR V2X Mode 2 dynamic scheduling), the traffic characteristics can be used to separately estimate the number of subchannels selected or utilized between the RSU and the train during each [t-999, t+Δt-999] ([t, t+Δt]). The previous subchannel occupancy should be subtracted and added to the [t, t+Δt] channel occupancy afterwards. Thus, the impact of the train maintaining communication with the RSU at a future time Δt is calculated.

[0055] If the RSU no longer maintains communication with the train due to a radio link failure, i.e., the radio conditions between the RSU and the moving train are below a certain threshold and the link is disconnected (two modes are possible: the application server can anticipate RLF using the train location and a location-based channel condition fingerprint database, or the application server is notified by the train or the RSU that detects RLF via an RLF fingerprint), the traffic characteristics can be used to estimate the number of subchannels selected or utilized between the RSU and the train during [t-999, t+Δt-999], which should be subtracted from the channel occupancy in the CR prediction because these do not occur during [t, t+Δt].

[0056] According to the railway application information in the application server AS, if an RSU potentially has a new arriving train to serve during [t, t+Δt], such an event can be predicted using the train location information and the location-based channel condition fingerprint database. The traffic characteristics of the arriving train can be used to estimate the subchannel occupancy of the RSU serving the train, which should be added to the channel occupancy in the CR prediction during [t, t+Δt].

[0057] For SL CBR prediction, since the CBR is calculated as the number of busy (energy > threshold) subchannels in the resource pool within the time window perceived by each RSU, the mobility of each train and the channel resource selection of each sidelink communication in the duration [t, t + Δt] both have an impact on the CBR measured at each RSU, which makes CBR prediction somewhat difficult. However, it is still possible to perform such prediction using at least one of the following three methods: 1. Extrapolate the measured CBR at each RSU using the history of periodic reports available at the application server. 2. Because train tracks are scheduled in advance, they are likely to repeat over time (train traffic timetable), and a fingerprint database of each RSU's measured CBR at time can be built in the application server using previous reports. The CBR measured at a future time t+Δt can be estimated by searching for similar situations in the history in the fingerprint database. 3. Assuming that the private train network is an isolated system, i.e., there is no interference from other systems, the application server can use the channel occupancy predictions of all RSUs, the location information of fixed RSUs and the location of each train at time t+Δt, and the location-based channel condition fingerprint database to predict the channel selection and utilization of each RSU at future time t+Δt as described above, and the measured CBR of each RSU can be estimated at the application server.

[0058] Once the application server AS has made CR and CBR predictions for a subset of RSUs, it can use these global views of the entire system to generate auxiliary information for the RSUs to improve the DCC procedure in step S5. The auxiliary information can have various forms, and some examples are given below.

[0059] {Example I of auxiliary information, application server-assisted transmission parameter change} The aiding information can be a suggestion for the nearly congested RSU to change its transmission parameters so that it can serve the newly arriving train. In a particular embodiment as shown in FIGS. 5A-5C, an application server AS coordinates two RSUs, namely, RSU1 and RSU2. The application server AS has aggregated CR and CBR information of each RSU at time t and predicts the CR, CBR of RSU1 and RSU2 at time t+Δt. The application has estimated that a moving train will have a radio link failure in the RSU1-to-train link at time t+Δt, and RSU2 will take over and transmit to the train.

[0060] Based on the CR and CBR predictions of RSU2 at time t+Δt, the application server notes that RSU2 is slightly congested and may not be able to serve future trains if no changes are made to its transmission parameters. Therefore, to enable RSU2 to serve future trains, the application server sends auxiliary information to RSU2 before time t+Δt and suggests using a higher modulation and coding scheme (MCS) for the current transmission. This leads to a lower CR at the RSU at time t+Δt when the train arrives. In this way, the RSU can transmit to the train.

[0061] For example, as shown in FIG. 5A, at time T=t, RSU1 communicates with train 1, and RSU2 communicates with train 2 and train 3. RSU1 and RSU2 calculate their own SL CR and SL CBR at time T=t and feed them back to the Train App server.

[0062] The train application server AS can predict that train 1 will communicate with RSU 2 at a future time T=t+Δt. This prediction can be based on (1) instantaneous train 1 location information, train speed information, and distance-based RSU selection criteria, or (2) instantaneous train 1 location information, train speed information, a location-based channel condition fingerprint database, and received power-based RSU selection criteria.

[0063] The train application server AS can predict the SL CR and SL CBR at time T=t+Δt for RSU 2. The prediction is based on the traffic characteristics of the communication flows of RSU 2 to trains 1, 2, and 3, the location information of trains 1, 2, and 3, and the location-based channel condition fingerprint database.

[0064] Using the predicted SL CR and SL CBR at time T=t+Δt for RSU2, the Train App server finds that RSU2 cannot serve three trains with the current configuration of communication flows from RSU2 to trains 1, 2, and 3. With such a configuration, the SL CR at T=t+Δt is equal to the CR at RSU2. limit This is simple because it exceeds

[0065] In the next step, as shown in Figure 5B, at time T = t + t', the train application server AS will send auxiliary information to the RSUs, for example, suggesting that RSU2 use a higher modulation and coding scheme (MCS) in its current transmissions with train 2 and train 3. In this way, if RSU2 applies the proposed configuration, the congestion level at RSU2 will decrease and it will be able to serve all three trains at time T = t + Δt.

[0066] RSU2 accepts and applies the MCS configuration parameters from the Train App server, and the SL CR at RSU2 begins to improve.

[0067] Therefore, as shown in FIG. 5C, at time T=t+Δt, apart from the previously existing communications between RSU2 and trains 2 and 3, RSU2 additionally starts communicating with train 1.

[0068] With the current MCS configuration parameters, RSU2 can determine whether it is able to achieve the desired MCS without congestion (SL CR at the current time T=t+Δt is equal to the CR at RSU2). limit It is found that it is possible to serve all three trains (not to exceed 100km).

[0069] {Auxiliary Information Example II. Application Server-Assisted Congestion Parameter Modification} The auxiliary information may also be a suggestion for the RSU to modify its own congestion parameters, such as sl-CR-Limit, to improve the congestion status of the RSU. In a particular embodiment as shown in Figure 6, an application server AS coordinates two RSUs. The application server has aggregated CR and CBR information for each RSU at time t and predicts the CR and CBR of RSU1 and RSU2 at time t+Δt.

[0070] Based on the CR and CBR predictions of RSU1 and RSU2 at time t+Δt, the application server notes that RSU2 is likely to be congested because it will be communicating with many upcoming trains, and that RSU1 will be idle without communication. Therefore, to enable RSU2 to serve the upcoming trains, the application server sends auxiliary information to RSU2 before time t+Δt to adjust its congestion parameter CR, CBR, for example, using the upper layer configuration parameter sl-CR-Limit. limit This allows RSU2 to select and use more channels for future trains at time t+Δ with limited impact on RSU1 because RSU1 has no (or limited) transmission load.

[0071] For example, as shown in FIG. 6A, first, both CRs in RSU1 and RSU2 limitis configured to be, for example, 0.0008 when CBR>0.8 to achieve a certain fairness between RSU1 and RSU2.

[0072] At time T=t, RSU1 is in communication with three trains, namely, train 1, train 2, and train 3. RSU2 is in idle state. RSU1 calculates its own SL CR and SL CBR at time T=t and feeds them back to the train application server AS.

[0073] The train application server AS can predict that RSU2 will communicate with all three trains at a future time T=t+Δt, during which RSU1 is idle. This prediction can be based on (1) instantaneous train location information, train speed information, and distance-based RSU selection criteria, or (2) instantaneous train location information, train speed information, a location-based channel condition fingerprint database, and received power-based RSU selection criteria.

[0074] The train application server assumes that RSU1 is idle while RSU2 is flooded with multiple flows for communicating with multiple trains. Therefore, the initial equal CRs of RSU1 and RSU2 at time T=t are used. limit It can be seen that the configuration is not optimal for a future time T=t+t'. For example, limit Set the configuration as 0.0014 and CR in RSU1 limit It may be better to set the configuration as 0.0002, which allows the RSU2 to select and utilize more channels for future trains.

[0075] Next, as shown in FIG. 6B , at time T=t+t′, the train application server AS adjusts the CR of RSU1 and RSU2 using the upper layer parameter SL-CR-Limit at time T=t+Δt. limit Recommend congestion control parameters to RSU1 and RSU2 to change

[0076] Therefore, at time T = t + Δt, as shown in FIG. 6C, RSU2 applies the configuration parameters from the train application server AS, and then can select and utilize more channels for communication with trains 1, 2, and 3.

[0077] {Example III of auxiliary information, side-link dual connection assisted by the application server} A third exemplary piece of auxiliary information is a proposal for the RSU to establish an auxiliary unicast link to the train and transmit to the train via this new side-link. In a particular embodiment as shown in FIG. 7, the application server AS coordinates two RSUs. The application server has the aggregated CR and CBR of each RSU at time t and can predict the CR and CBR of RSU1 and RSU2 for all future time points in [t, t + Δt] considering different multiple transmission configurations. In other words, the application server can predict the CR and CBR performance of both RSU1 and RSU at any time t < t' < t + Δt. Using one example of a communication configuration, RSU1 communicates with the train during [t, t'], in another configuration, RSU2 communicates with the train during [t, t'], or in yet another configuration, both RSU1 and RSU2 communicate with the train during [t, t'].

[0078] Based on the predictions associated with different communication configurations, the application server can recommend a transmission configuration if, for example, communication with the train and the corresponding transmission duration is preferred for RSU1 or RSU2 or a dual connection.

[0079] For example, as shown in FIG. 7A, at time T = t, RSU1 is communicating with train 1, and RSU1 and RSU2 calculate their SL CR and SL CBR at time T = t and will feedback to the train application server AS.

[0080] The train application server AS at the future time T = tswitch It can be predicted that train 1 will communicate with RSU 2 at time t1. This prediction can be based on (1) instantaneous train 1 location information, train speed information, and distance-based RSU selection criteria, or (2) instantaneous train 1 location information, train speed information, a location-based channel condition fingerprint database, and received power-based RSU selection criteria.

[0081] The train application server AS determines whether the side link between RSU1 and train 1 is released and whether the side link between RSU2 and train 1 is established. switch occurs at [t, t+Δt], it is possible to predict how the SL CR and SL CBR will evolve during [t, t+Δt] for both RSU1 and RSU2. This prediction is based on the traffic characteristics of the communication flow, the location information, and the location-based channel condition fingerprint database.

[0082] The train application server AS can also predict how the SL CR and SL CBR will evolve during [t, t+Δt] for both RSU1 and RSU2 when dual connections (RSU1 to train 1 and RSU2 to train 1) occur during the dual connection window [t1, t2]. This prediction is based on the traffic characteristics of the communication flow, location information, and the location-based channel condition fingerprint database.

[0083] For all possible values of the dual connection window [t1, t2] configuration, there are cases where there is no dual connection (T=t switch , t1, t2]), the train application server AS compares their performances of congestion (i.e., how the SL CR and SL CBR will evolve for both RSU1 and RSU2 when a specific dual connection window [t1, t2] is applied), and selects one optimal configuration for congestion evolution in RSU1 and RSU2, e.g., [t1 * ,t2 * ].

[0084] [t1 * ,t2 * , between them, as shown in FIG. 7B, the train application server AS transmits auxiliary information to RSU1 and RSU2, triggering the establishment of a sidelink dual connection between RSU1 - Train 1 and RSU2 - Train 2.

[0085] {Example IV of auxiliary information, sidelink unicast link management and congestion balancing assisted by the application server} The fourth exemplary auxiliary information is a recommendation to the RSU indicating that it should establish a unicast link with the train and perform sidelink communication, or a recommendation to the train indicating that it is better to establish the next sidelink with a specific RSU. In a specific embodiment as shown in FIGS. 8A and 8B, the application server coordinates three RSUs. The application server has the aggregated CR and CBR information of each RSU at time t, and predicts the CR and CBR of RSU1, RSU2, and RSU3 at time t + Δt. A train receiving a packet from RUS1 will have a wireless link failure at time t < t RLF <t + Δt, and potentially receive communication from either RSU2 or RSU3 after the link failure. Using the CR and CBR predicted for RSU2 and RSU3 at time t + Δt, the application server can infer which of RSU2 and RSU3 should be selected for communication with the train. Before the train exits the range of RSU1, this auxiliary information can be transmitted to the train via RSU1, telling the train to establish a unicast link with RSU3. Auxiliary information to initiate the establishment of a unicast link with the train can also be addressed to RSU3.

[0086] For example, as shown in FIGS. 8A and 8B, RSU1, RSU2, and RSU3 calculate their SL CR and SL CBR at time T = t and will feedback to the train application server AS.

[0087] For any given configuration π of unicast sidelink management, e.g., if RSU1 is in [t,t a ], and RSU3 communicates with train 1 during [t a ,t b ], and RSU2 communicates with train 1 during [t b For a configuration communicating with train 1 during [t, t+Δt], the train application server can predict how the SL CR and SL CBR will evolve during [t, t+Δt] for all RSU1, RSU2, and RSU3 that apply the above-mentioned configuration π. This prediction is based on the traffic characteristics of the communication flows, location information, and a location-based channel condition fingerprint database.

[0088] As shown in Figure 8B, the train application server AS can use a utility function f to select and establish unicast sidelinks between the RSUs and the train. One example of a utility function at the application server is the following congestion balancing metric, which minimizes the maximum channel occupancy at all RSUs:

number

[0089] Another example congestion balancing metric that minimizes the overall channel occupancy for all coordinated RSUs is:

number

[0090] The illustrative examples and scenarios described above can be extended to more complex cases where multiple RSUs and multiple trains are presented. In this particular embodiment, the application server has aggregated CR and CBR information for each RSU at time t, and knows that there are unicast link failures and new unicast link establishments during [t, t+Δt] due to train mobility, and the application can predict the CR, CBR of each RSU at time t+tΔ given the specific new unicast link establishment configuration. Then, the application server calculates the utility function

number

number

number

[0091] Therefore, in a next step S6, the calculated auxiliary information is provided by the application server AS to the RSU or train in question.

[0092] Then, in step S7, a subset of the RSUs performs DCC using the aiding information. Additionally, if the timestamp indicates that the aiding information is out of date, the RSUs will again calculate and report the CR and CBR, and the previous steps will be repeated. Alternatively, the previous steps can be repeated based on an external trigger, such as train mobility or periodic updates.

[0093] In view of the above, the present invention proposes a method for predicting distributed congestion control (DCC) performance and providing auxiliary information to improve overall system performance.

[0094] In addition, the present invention also proposes a system for controlling congestion in a private train network, the private train network comprising a plurality of roadside units (RSUs) deployed along a railway track, each connected to an application server, each of the plurality of roadside units (RSUs) configured to establish communication with at least one train based on a wireless network and configured to make independent DCC decisions, and the communication shares a common sidelink resource pool. an aggregation unit for aggregating congestion control information from a subset of the plurality of roadside units (RSUs) and railway application information from an application server; a prediction unit for predicting, by an application server, a congestion status of each of a subset of the plurality of road side units (RSUs) based on the aggregated congestion control information and the railway application information; a computing unit for computing and providing, by an application server, assistance information to a subset of the plurality of road side units (RSUs) based on a predicted congestion status; Equipped with A subset of the plurality of roadside units RSUs is configured to perform DCC based on the aiding information.

[0095] In particular, the following characteristics are configured in this system according to the invention: Multiple roadside units (RSUs) perform distributed congestion control (DCC) based on this information. The application server periodically receives CR and CBR information from a subset of the roadside units (RSUs), which make their own DCC decisions. The application server predicts the CR, CBR of each node by anticipating potential mobility and sidelink association strategies using periodic CR and CBR information from a subset of roadside units, traffic characteristics of service flows transmitted from RSUs to trains, location and traffic / service information of each node, and a location-based channel condition fingerprint database. According to the application server's predictions, the application server provides auxiliary information to each of the subset of roadside units so that the DCC can be optimized by taking into account the global insight from the application server. Each of the subsets of roadside units will receive the aiding information and make the final DCC decision.

[0096] Also, as will be known to those skilled in the art, the above-described examples according to the present invention can be implemented in many ways, such as, for example, as program instructions for execution by a processor, software modules, microcode, a computer program product on a computer-readable medium, logic circuits, application specific integrated circuits, firmware, etc. Embodiments of the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment containing both hardware and software elements. In a preferred embodiment, the present invention is implemented in software, which software includes, but is not limited to, firmware, resident software, microcode, etc.

[0097] Furthermore, embodiments of the present invention may take the form of a computer program product accessible from a computer-usable or computer-readable storage medium providing program code for use by or in connection with a computer, processing device, or any instruction execution system. As used herein, a computer-usable or computer-readable storage medium may be any apparatus that can contain, store, communicate, or deliver a program for use by or in connection with an instruction execution system, apparatus, or device. The medium may be an electronic, magnetic, optical, or semiconductor system (or apparatus or device). Examples of computer-readable storage media include, but are not limited to, semiconductor or solid-state memory, magnetic tape, removable computer diskettes, RAM, read-only memory (ROM), rigid magnetic disks, optical disks, etc. Current examples of optical disks include compact disc read-only memory (CD-ROM), compact disc read / write (CD-R / W), and DVD.

[0098] The embodiments described herein above are illustrative of the present invention. Various modifications can be made to the embodiments without departing from the scope of the invention which arises from the appended claims.

Claims

1. 1. A method for controlling congestion in a private train network, the private train network comprising a plurality of roadside units (ROSUs) deployed along a railway track, each connected to an application server, each ROSU configured to establish sidelink communication with at least one train based on a wireless network and configured to make independent distributed congestion control decisions, the sidelink communication sharing a common sidelink resource pool, the sidelink communication in the wireless network based on NR V2X Mode 2 sidelink communication using a PC5 interface, the method comprising: aggregating, by the application server, congestion control information from the subset of the plurality of roadside units and rail application information within the application server; predicting, by the application server, a congestion status of each of the subset of the plurality of roadside units based on the aggregated congestion control information and railway application information, wherein the predicted congestion status comprises a prediction of a sidelink channel busy rate and / or a sidelink channel occupancy rate of the subset of the plurality of roadside units; calculating and providing, by the application server, assistance information to a subset of the plurality of roadside units based on the predicted congestion status; performing, by a subset of the plurality of roadside units, a distributed congestion control based on the aiding information; Including, The auxiliary information is modifying transmission parameters for a subset of the plurality of roadside units; changing congestion parameters for a subset of the plurality of roadside units; Assisted sidelink dual connectivity, and / or Assisted sidelink unicast link management; Regarding Prior to aggregating the congestion control information, the method further comprises: selecting a subset of the plurality of roadside units; calculating the congestion control information by a subset of the plurality of roadside units and reporting the congestion control information to the application server; The method further comprises:

2. 2. The method of claim 1, wherein the congestion control information is a sidelink channel busy rate and / or a sidelink channel occupancy rate.

3. The sidelink channel occupancy is 1000 slots or 1000.2 μ the sidelink channel busy rate is calculated based on a sliding window containing 100 slots or 100.2 μ is calculated based on a sliding window containing slots, where μ is 【Table 1】 3. The method of claim 2, wherein the parameter is a numerology parameter having a value in

4. The method of claim 1 , wherein the subset of roadside units is selected based on their signal power and / or geographical distance.

5. The railway application information traffic characteristics of service flows transmitted from the roadside unit to the at least one train; position information of the at least one train; and / or a location-based channel condition fingerprint database; The method of claim 1 , wherein the higher layer information includes:

6. The method of claim 5 , wherein the traffic characteristics include a packet delay budget, a packet size, a traffic periodicity, a guaranteed flow bit rate, a maximum flow bit rate, a packet error rate, and / or a priority level.

7. The method of claim 5 , wherein the position information comprises an instantaneous position and / or an instantaneous velocity of the at least one train.

8. The method according to any one of claims 1 to 7, wherein the auxiliary information includes a timestamp, and the roadside device ignores the auxiliary information if the timestamp has expired.

9. The method of any one of claims 1 to 7, further comprising providing said auxiliary information to said at least one train.

10. 8. The method according to claim 1, wherein the common sidelink resource pool is a resource pool of sidelink channels in both the time and frequency domain.

11. A computer program comprising instructions that, when executed by a computer, cause the computer to carry out the method of claim 1.

12. 1. A system for controlling congestion in a private train network, the private train network comprising a plurality of roadside units deployed along a railway track, each roadside unit connected to an application server, each roadside unit configured to establish communication with at least one train based on a wireless network and configured to make independent distributed congestion control decisions, the communication sharing a common sidelink resource pool, the communication in the wireless network based on sidelink communication using a PC5 interface in NR V2X Mode 2, the system comprising: an aggregation unit configured to aggregate, by the application server, congestion control information from the subset of the plurality of roadside units and railway application information in the application server; a prediction unit configured to predict, by the application server, a congestion status of each of the subset of roadside units based on the aggregated congestion control information and railway application information, wherein the predicted congestion status comprises a prediction of a sidelink channel busy rate and / or a sidelink channel occupancy rate of the subset of roadside units; and a computing unit configured to compute and provide, by the application server, assistance information to a subset of the plurality of roadside units based on a predicted congestion status; Equipped with a subset of the plurality of roadside units configured to perform distributed congestion control based on the auxiliary information; The auxiliary information is modifying transmission parameters for a subset of the plurality of roadside units; changing congestion parameters for a subset of the plurality of roadside units; Assisted sidelink dual connectivity, and / or Assisted sidelink unicast link management; Regarding Prior to aggregating the congestion control information, the system: selecting a subset of the plurality of roadside units; calculating the congestion control information by a subset of the plurality of roadside units and reporting the congestion control information to the application server; A system that further

Images