diff --git a/_images/rmcat.png b/_images/rmcat.png index 86c2bf6..9b6a9ae 100644 Binary files a/_images/rmcat.png and b/_images/rmcat.png differ diff --git a/_sources/environments/congestion_control.md.txt b/_sources/environments/congestion_control.md.txt index 481b6ba..62f9f78 100644 --- a/_sources/environments/congestion_control.md.txt +++ b/_sources/environments/congestion_control.md.txt @@ -16,7 +16,7 @@ congestion_control/rmcat :link: cards-rmcat :link-type: ref -In this environment, the agent performs periodic actions to control the sending rate of a real-time traffic RMCAT (NADA) flow. +In this environment, the agent performs periodic actions to adjust the sending rate of a real-time traffic flow using RTP Media Congestion Avoidance Techniques (RMCAT). ::: :::: diff --git a/_sources/environments/congestion_control/rmcat.md.txt b/_sources/environments/congestion_control/rmcat.md.txt index f9a0d31..5650d82 100644 --- a/_sources/environments/congestion_control/rmcat.md.txt +++ b/_sources/environments/congestion_control/rmcat.md.txt @@ -5,14 +5,15 @@ title: RMCAT # RMCAT ```{figure} rmcat.png --- -width: 50% +width: 100% --- ``` [config.json]: https://github.com/IntelLabs/networkgym/blob/main/network_gym_client/envs/rmcat/config.json The RMCAT environment is part of the congestion control environments and provides general information about the environment. -In this environment, the agent performs periodic actions to control the sending rate of a real-time traffic RMCAT (NADA) flow. +In this environment, the agent performs periodic actions to adjust the sending rate of a real-time traffic flow using RTP Media Congestion Avoidance Techniques (RMCAT). +This environment is based on the GitHub Repo: [cisco/ns3-rmcat](https://github.com/cisco/ns3-rmcat). | | | | ----- | ---- | @@ -23,7 +24,7 @@ In this environment, the agent performs periodic actions to control the sending ## Description -The RMCAT environment represents a congestion control problem for real-time traffic. The goal of congestion control is to strategically controls sending rate, aiming to achieve high throughput, low latency and low loss. +The RMCAT environment represents a congestion control problem for real-time traffic. The goal of congestion control is to strategically control the sending rate, aiming to achieve high throughput, low latency, and low loss. If no action is given to the environment, RMCAT uses [NADA](https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-nada-05) as its default algorithm. ## Prerequisite @@ -31,27 +32,9 @@ Ensure that you have access to the NetworkGym Server on [vLab](https://registrat ## Observation Space -The observation is an `ndarray` with shape `(3,)` representing three features. The first feature is `rtt`, representing the round trip time. The second feature is `xcurr`, represeting the congestion level. The third feature is the received throughput `rrate`. +The observation is an `ndarray` with shape `(3,)` representing three features selected from the available measurements for this environment. -| Feature | Observation | Min | Max | -| ----- | ---- | ----- | ---- | -| 0 | rtt (ms) | 0.0 | Inf | -| 1 | xcurr | 0.0 | 500.0 | -| 2 | rrate (bps) | 0.0 | Inf| - -## Action Space -The action space is a `ndarray` with shape `(1,)` representing the sending rate of rmcat flow. The min value is 150000 and max value is 1500000. - - -## Reward - -TODO - -## Custom Observation Space and Reward -1. Edit the "subscribed_network_stats" in the [config.json] to include only the necessary measurements required for computing observations and rewards. This minimizes the transmission of 'unused' data and reduces overhead. -To subscribe to a specific measurement, add its `source`::`name` combination to the "subscribed_network_stats" list. For example, appending `rmcat::rtt` to the list would enable receiving measurements with the name `rtt` from the source `rmcat`. - -:::{dropdown} Click to view a demo of all measurements for this environment. +:::{dropdown} Click to view available measurements for this environment. Refer to [Working with Measurements](../../tutorials/working_with_measurements.md) for further elaboration of the following measurements. @@ -72,6 +55,25 @@ Refer to [Working with Measurements](../../tutorials/working_with_measurements.m ::: +The first feature is `rtt`, representing the round trip time. The second feature is `xcurr`, represeting the congestion level. The third feature is the received throughput `rrate`. + +| Feature | Observation | Min | Max | +| ----- | ---- | ----- | ---- | +| 0 | rtt (ms) | 0.0 | Inf | +| 1 | xcurr | 0.0 | 500.0 | +| 2 | rrate (bps) | 0.0 | Inf| + +## Action Space +The action space is a `ndarray` with shape `(1,)` representing the sending rate of rmcat flow. The min value is 150000 and max value is 1500000. + + +## Reward + +Not implemented yet. + +## Customize Observation Space and Reward + +1. Edit the "subscribed_network_stats" in the [config.json] to include only the necessary measurements required for computing observations and rewards. This minimizes the transmission of 'unused' data and reduces overhead. To subscribe to a specific measurement, add its `source`::`name` combination to the "subscribed_network_stats" list. For example, appending `rmcat::rtt` to the list would enable receiving measurements with the name `rtt` from the source `rmcat`. ```{eval-rst} 2. Customize Observation Space in the :meth:`network_gym_client.envs.rmcat.Adapter.get_observation` function. 3. Customize Reward in the :meth:`network_gym_client.envs.rmcat.Adapter.get_reward` function. diff --git a/_sources/environments/mx_network_slicing/cellular_network_slicing.md.txt b/_sources/environments/mx_network_slicing/cellular_network_slicing.md.txt index 732c103..9bbaef3 100644 --- a/_sources/environments/mx_network_slicing/cellular_network_slicing.md.txt +++ b/_sources/environments/mx_network_slicing/cellular_network_slicing.md.txt @@ -33,53 +33,9 @@ Ensure that you have access to the NetworkGym Server on [vLab](https://registrat ## Observation Space -The observation space is represented by a multidimensional array (`ndarray`) with a shape of `(5, N)`, where each of the `N` slices contains five distinct features: -1. **Total Throughput**: This measures the total data rate for each slice in Mbps, ranging from `0` to `Inf`. -2. **Resource Block Usage Rate**: It represents the fraction of resource blocks utilized by each slice, expressed as a percentage in the range of `[0, 1]`, with the sum across all slices equal to 1. -3. **Average Delay Violation Rate**: Initially measured user-wise and then averaged for each slice, this rate indicates the average proportion of delay violations, expressed as a percentage in the range of `[0, 1]`. -4. **Maximum Delay**: This records the maximum delay experienced by a slice at a specific moment, expressed in milliseconds and ranging from `0` to `Inf`. -5. **Average Delay**: It computes the average delay experienced by a slice, expressed in milliseconds and ranging from `0` to `Inf`. - -| Feature | Observation | Min | Max | -| --- | --- | --- | --- | -| 0 | Total Throughput per slice (mbps) | 0.0 | Inf | -| 1 | Resource Block Usage Rate per slice | 0.0 | 1.0 | -| 2 | Average Delay Violation Rate per slice | 0.0 | 1.0 | -| 3 | Maximum Delay per slice (ms) | 0.0 | Inf | -| 4 | Average Delay per slice (ms) | 0.0 | Inf | - - -## Action Space - -The action space is an `ndarray` with a shape of `(N,)`, indicating the allocation of resource blocks to `N` slices. It is important to note that the sum of the actions in this allocation should not exceed one. In case the sum surpasses one, the actions will be appropriately scaled down using the softmax function to ensure adherence to the constraint. This can be expressed mathematically as follows: -```{eval-rst} -if :math:`\sum_{i=1}^{N}a_i > 1, \quad a_i = \frac{e^{a_i}}{\sum_{j}e^{a_j}}.` -``` - -| Num | Action | Min | Max | -| --- | --- | --- | --- | -| 0 | Prioritized Rb allocated to slice 0 | 0.0 | 1.0 | -| 1 | Prioritized Rb allocated to slice 1 | 0.0 | 1.0 | -| ... | | | | -| N | Prioritized Rb allocated to slice N | 0.0 | 1.0 | - -## Reward - -The reward function in our system takes into account three factors: throughput, delay violation rate, and resource cost. It is formulated as follows: - -```{eval-rst} -:math:`R(t) = \sum_{i = 1}^N \left( \frac{{\text{throughput}_i}}{{\text{load}_i}} - \lambda \cdot \text{delay_violation_rate}_i - \gamma \cdot \text{rb_usage_rate}_i \right)` -``` - -```{eval-rst} -In this formulation, we can adjust the emphasis given to the delay violation rate and the resource block usage rate using the parameters (:math:`\lambda`) and (:math:`\gamma`) respectively. By default, (:math:`\lambda=1.5`) and (:math:`\gamma = 0.5`), which prioritize delay considerations. -``` - -## Custom Observation Space and Reward -1. Edit the "subscribed_network_stats" in the [config.json] to include only the necessary measurements required for computing observations and rewards. This minimizes the transmission of 'unused' data and reduces overhead. -To subscribe to a specific measurement, add its `source`::`name` combination to the "subscribed_network_stats" list. For example, appending `gma::wifi::dl::traffic_ratio` to the list would enable receiving measurements with the name `wifi::dl::traffic_ratio` from the source `gma`. +The observation space is represented by a multidimensional array (`ndarray`) with a shape of `(5, N)`, where each of the `N` slices contains five distinct features selected from the available measurements for this environment: -:::{dropdown} Click to view a demo of all measurements for this environment. +:::{dropdown} Click to view available measurements for this environment. Refer to [Working with Measurements](../../tutorials/working_with_measurements.md) for further elaboration of the following measurements. @@ -129,6 +85,50 @@ Refer to [Working with Measurements](../../tutorials/working_with_measurements.m ::: +1. **Total Throughput**: This measures the total data rate for each slice in Mbps, ranging from `0` to `Inf`. +2. **Resource Block Usage Rate**: It represents the fraction of resource blocks utilized by each slice, expressed as a percentage in the range of `[0, 1]`, with the sum across all slices equal to 1. +3. **Average Delay Violation Rate**: Initially measured user-wise and then averaged for each slice, this rate indicates the average proportion of delay violations, expressed as a percentage in the range of `[0, 1]`. +4. **Maximum Delay**: This records the maximum delay experienced by a slice at a specific moment, expressed in milliseconds and ranging from `0` to `Inf`. +5. **Average Delay**: It computes the average delay experienced by a slice, expressed in milliseconds and ranging from `0` to `Inf`. + +| Feature | Observation | Min | Max | +| --- | --- | --- | --- | +| 0 | Total Throughput per slice (mbps) | 0.0 | Inf | +| 1 | Resource Block Usage Rate per slice | 0.0 | 1.0 | +| 2 | Average Delay Violation Rate per slice | 0.0 | 1.0 | +| 3 | Maximum Delay per slice (ms) | 0.0 | Inf | +| 4 | Average Delay per slice (ms) | 0.0 | Inf | + + +## Action Space + +The action space is an `ndarray` with a shape of `(N,)`, indicating the allocation of resource blocks to `N` slices. It is important to note that the sum of the actions in this allocation should not exceed one. In case the sum surpasses one, the actions will be appropriately scaled down using the softmax function to ensure adherence to the constraint. This can be expressed mathematically as follows: +```{eval-rst} +if :math:`\sum_{i=1}^{N}a_i > 1, \quad a_i = \frac{e^{a_i}}{\sum_{j}e^{a_j}}.` +``` + +| Num | Action | Min | Max | +| --- | --- | --- | --- | +| 0 | Prioritized Rb allocated to slice 0 | 0.0 | 1.0 | +| 1 | Prioritized Rb allocated to slice 1 | 0.0 | 1.0 | +| ... | | | | +| N | Prioritized Rb allocated to slice N | 0.0 | 1.0 | + +## Reward + +The reward function in our system takes into account three factors: throughput, delay violation rate, and resource cost. It is formulated as follows: + +```{eval-rst} +:math:`R(t) = \sum_{i = 1}^N \left( \frac{{\text{throughput}_i}}{{\text{load}_i}} - \lambda \cdot \text{delay_violation_rate}_i - \gamma \cdot \text{rb_usage_rate}_i \right)` +``` + +```{eval-rst} +In this formulation, we can adjust the emphasis given to the delay violation rate and the resource block usage rate using the parameters (:math:`\lambda`) and (:math:`\gamma`) respectively. By default, (:math:`\lambda=1.5`) and (:math:`\gamma = 0.5`), which prioritize delay considerations. +``` + +## Custom Observation Space and Reward +1. Edit the "subscribed_network_stats" in the [config.json] to include only the necessary measurements required for computing observations and rewards. This minimizes the transmission of 'unused' data and reduces overhead. +To subscribe to a specific measurement, add its `source`::`name` combination to the "subscribed_network_stats" list. For example, appending `gma::lte::dl::rate` to the list would enable receiving measurements with the name `lte::dl::rate` from the source `gma`. ```{eval-rst} 2. Customize Observation Space in the :meth:`network_gym_client.envs.network_slicing.Adapter.get_observation` function. 3. Customize Reward in the :meth:`network_gym_client.envs.network_slicing.Adapter.get_reward` function. diff --git a/_sources/environments/mx_traffic_management/mx_qos_traffic_steering.md.txt b/_sources/environments/mx_traffic_management/mx_qos_traffic_steering.md.txt index 2690c41..4e5c8cf 100644 --- a/_sources/environments/mx_traffic_management/mx_qos_traffic_steering.md.txt +++ b/_sources/environments/mx_traffic_management/mx_qos_traffic_steering.md.txt @@ -45,33 +45,9 @@ Ensure that you have access to the NetworkGym Server on [vLab](https://registrat ## Observation Space -The observation is an `ndarray` with shape `(3,N,)` representing three features for N users. The first feature is MAX LTE rate, representing the user's estimation of channel capacity (e.g., the max rate if the user utilizes all resources). The second feature is the Max Wi-Fi rate, and the third feature is the received throughput, combining both links. +The observation is an `ndarray` with shape `(3,N,)` representing three features for N users selected from the available measurement for this environment. -| Feature | Observation | Min | Max | -| ----- | ---- | ----- | ---- | -| 0 | MAX LTE rate (mbps) | 0.0 | Inf | -| 1 | MAX Wi-Fi rate (mbps) | 0.0 | Inf | -| 2 | throughput (mbps) | 0.0 | Inf| - -## Action Space - -The action is a `ndarray` with shape `(N,)` which can take values {0, 1} indicating the link to transmit data. N is the number of users. -- 0: Steer traffic over Cellular -- 1: Steer traffic over Wi-Fi - -## Reward - -```{eval-rst} - -We computes the number of Quality of Service (QoS) users over Wi-Fi as reward function :meth:`network_gym_client.envs.qos_steer.Adapter.calculate_wifi_qos_user_num`. Given that Cellular already implements an admission control mechanism to support the maximum number of QoS users, maximizing the QoS users over Wi-Fi also leads to the maximization of the total number of users in the network that meet the QoS requirements. In essence, optimizing the QoS users over Wi-Fi indirectly ensures the best possible overall network performance with the desired QoS levels for all users. - -``` - -## Custom Observation Space and Reward -1. Edit the "subscribed_network_stats" in the [config.json] to include only the necessary measurements required for computing observations and rewards. This minimizes the transmission of 'unused' data and reduces overhead. -To subscribe to a specific measurement, add its `source`::`name` combination to the "subscribed_network_stats" list. For example, appending `gma::wifi::dl::traffic_ratio` to the list would enable receiving measurements with the name `wifi::dl::traffic_ratio` from the source `gma`. - -:::{dropdown} Click to view a demo of all measurements for this environment. +:::{dropdown} Click to view available measurements for this environment. Refer to [Working with Measurements](../../tutorials/working_with_measurements.md) for further elaboration of the following measurements. @@ -138,6 +114,31 @@ Refer to [Working with Measurements](../../tutorials/working_with_measurements.m ::: +The first feature is MAX LTE rate, representing the user's estimation of channel capacity (e.g., the max rate if the user utilizes all resources). The second feature is the Max Wi-Fi rate, and the third feature is the received throughput, combining both links. + +| Feature | Observation | Min | Max | +| ----- | ---- | ----- | ---- | +| 0 | MAX LTE rate (mbps) | 0.0 | Inf | +| 1 | MAX Wi-Fi rate (mbps) | 0.0 | Inf | +| 2 | throughput (mbps) | 0.0 | Inf| + +## Action Space + +The action is a `ndarray` with shape `(N,)` which can take values {0, 1} indicating the link to transmit data. N is the number of users. +- 0: Steer traffic over Cellular +- 1: Steer traffic over Wi-Fi + +## Reward + +```{eval-rst} + +We computes the number of Quality of Service (QoS) users over Wi-Fi as reward function :meth:`network_gym_client.envs.qos_steer.Adapter.calculate_wifi_qos_user_num`. Given that Cellular already implements an admission control mechanism to support the maximum number of QoS users, maximizing the QoS users over Wi-Fi also leads to the maximization of the total number of users in the network that meet the QoS requirements. In essence, optimizing the QoS users over Wi-Fi indirectly ensures the best possible overall network performance with the desired QoS levels for all users. + +``` + +## Custom Observation Space and Reward +1. Edit the "subscribed_network_stats" in the [config.json] to include only the necessary measurements required for computing observations and rewards. This minimizes the transmission of 'unused' data and reduces overhead. +To subscribe to a specific measurement, add its `source`::`name` combination to the "subscribed_network_stats" list. For example, appending `gma::wifi::dl::traffic_ratio` to the list would enable receiving measurements with the name `wifi::dl::traffic_ratio` from the source `gma`. ```{eval-rst} 2. Customize Observation Space in the :meth:`network_gym_client.envs.qos_steer.Adapter.get_observation` function. 3. Customize Reward in the :meth:`network_gym_client.envs.qos_steer.Adapter.get_reward` function. diff --git a/_sources/environments/mx_traffic_management/mx_traffic_splitting.md.txt b/_sources/environments/mx_traffic_management/mx_traffic_splitting.md.txt index 64c0728..2593268 100644 --- a/_sources/environments/mx_traffic_management/mx_traffic_splitting.md.txt +++ b/_sources/environments/mx_traffic_management/mx_traffic_splitting.md.txt @@ -32,41 +32,9 @@ Ensure that you have access to the NetworkGym Server on [vLab](https://registrat ## Observation Space -The observation is an `ndarray` with shape `(3,N,)` representing three features for N users. The first feature is MAX LTE rate, representing the user's estimation of channel capacity (e.g., the max rate if the user utilizes all resources). The second feature is the Max Wi-Fi rate, and the third feature is the received throughput, combining both links. +The observation is an `ndarray` with shape `(3,N,)` representing three features for N users selected from the available measurements for this environment. -| Feature | Observation | Min | Max | -| ----- | ---- | ----- | ---- | -| 0 | MAX LTE rate (mbps) | 0.0 | Inf | -| 1 | MAX Wi-Fi rate (mbps) | 0.0 | Inf | -| 2 | throughput (mbps) | 0.0 | Inf| - -## Action Space -The action space is a `ndarray` with shape `(N,)` representing the traffic ratio over Wi-Fi for N users. The traffic ratio over Cellular equals (1.0 - action). - -| Num | Action | Min | Max | -| ----- | ---- | ----- | ---- | -| 0 | Wi-Fi traffic ratio for user 0 | 0.0 | 1.0 | -| 1 | Wi-Fi traffic ratio for user 1| 0.0 | 1.0 | -| ... | | | | -| N-1 | Wi-Fi traffic ratio for user N-1| 0.0 | 1.0 | - -## Transition Dynamics -Given an action (Wi-Fi split ratio for user i: R[i]), transmitter i follows the following transition dynamics: -- transmit R[i] traffic over Wi-Fi link. -- transmit (1-R[i]) traffic over LTE link. - -## Reward - -```{eval-rst} -We compute a utility function :math:`f = 0.5 \times log(throughput)-0.5 \times log(OWD)` using the reward function :meth:`network_gym_client.envs.nqos_split.Adapter.netowrk_util`, where OWD is the one-way delay. -The goal of the utility function is to maximize the throughput and minimizing delay. -``` - -## Custom Observation Space and Reward -1. Edit the "subscribed_network_stats" in the [config.json] to include only the necessary measurements required for computing observations and rewards. This minimizes the transmission of 'unused' data and reduces overhead. -To subscribe to a specific measurement, add its `source`::`name` combination to the "subscribed_network_stats" list. For example, appending `gma::wifi::dl::traffic_ratio` to the list would enable receiving measurements with the name `wifi::dl::traffic_ratio` from the source `gma`. - -:::{dropdown} Click to view a demo of all measurements for this environment. +:::{dropdown} Click to view available measurements for this environment. Refer to [Working with Measurements](../../tutorials/working_with_measurements.md) for further elaboration of the following measurements. @@ -133,6 +101,39 @@ Refer to [Working with Measurements](../../tutorials/working_with_measurements.m ::: +The first feature is MAX LTE rate, representing the user's estimation of channel capacity (e.g., the max rate if the user utilizes all resources). The second feature is the Max Wi-Fi rate, and the third feature is the received throughput, combining both links. + +| Feature | Observation | Min | Max | +| ----- | ---- | ----- | ---- | +| 0 | MAX LTE rate (mbps) | 0.0 | Inf | +| 1 | MAX Wi-Fi rate (mbps) | 0.0 | Inf | +| 2 | throughput (mbps) | 0.0 | Inf| + +## Action Space +The action space is a `ndarray` with shape `(N,)` representing the traffic ratio over Wi-Fi for N users. The traffic ratio over Cellular equals (1.0 - action). + +| Num | Action | Min | Max | +| ----- | ---- | ----- | ---- | +| 0 | Wi-Fi traffic ratio for user 0 | 0.0 | 1.0 | +| 1 | Wi-Fi traffic ratio for user 1| 0.0 | 1.0 | +| ... | | | | +| N-1 | Wi-Fi traffic ratio for user N-1| 0.0 | 1.0 | + +## Transition Dynamics +Given an action (Wi-Fi split ratio for user i: R[i]), transmitter i follows the following transition dynamics: +- transmit R[i] traffic over Wi-Fi link. +- transmit (1-R[i]) traffic over LTE link. + +## Reward + +```{eval-rst} +We compute a utility function :math:`f = 0.5 \times log(throughput)-0.5 \times log(OWD)` using the reward function :meth:`network_gym_client.envs.nqos_split.Adapter.netowrk_util`, where OWD is the one-way delay. +The goal of the utility function is to maximize the throughput and minimizing delay. +``` + +## Custom Observation Space and Reward +1. Edit the "subscribed_network_stats" in the [config.json] to include only the necessary measurements required for computing observations and rewards. This minimizes the transmission of 'unused' data and reduces overhead. +To subscribe to a specific measurement, add its `source`::`name` combination to the "subscribed_network_stats" list. For example, appending `gma::wifi::dl::traffic_ratio` to the list would enable receiving measurements with the name `wifi::dl::traffic_ratio` from the source `gma`. ```{eval-rst} 2. Customize Observation Space in the :meth:`network_gym_client.envs.nqos_split.Adapter.get_observation` function. 3. Customize Reward in the :meth:`network_gym_client.envs.nqos_split.Adapter.get_reward` function. diff --git a/environments/congestion_control.html b/environments/congestion_control.html index 6362d3d..df6cd61 100644 --- a/environments/congestion_control.html +++ b/environments/congestion_control.html @@ -264,7 +264,7 @@
In this environment, the agent performs periodic actions to control the sending rate of a real-time traffic RMCAT (NADA) flow.
+In this environment, the agent performs periodic actions to adjust the sending rate of a real-time traffic flow using RTP Media Congestion Avoidance Techniques (RMCAT).
diff --git a/environments/congestion_control/rmcat.html b/environments/congestion_control/rmcat.html index 1304488..394ccb6 100644 --- a/environments/congestion_control/rmcat.html +++ b/environments/congestion_control/rmcat.html @@ -255,10 +255,11 @@The RMCAT environment is part of the congestion control environments and provides general information about the environment. -In this environment, the agent performs periodic actions to control the sending rate of a real-time traffic RMCAT (NADA) flow.
+In this environment, the agent performs periodic actions to adjust the sending rate of a real-time traffic flow using RTP Media Congestion Avoidance Techniques (RMCAT). +This environment is based on the GitHub Repo: cisco/ns3-rmcat.