# Wi-Fi/Cellular Coex Channel Avoidance

Stay organized with collections Save and categorize content based on your preferences.

The Wi-Fi/cellular coex channel avoidance feature, introduced in Android 12, identifies and avoids using unsafe Wi-Fi channels in cases where there might be interference from/to cellular channels. This includes interfaces such as STA, SoftAp, Wi-Fi Direct (P2P), Wi-Fi Aware (NAN).

• Information the cellular modem must report to the Android framework
• Algorithms the Wi-Fi framework uses to calculate Wi-Fi channels to be avoided
• Configuration tables that device manufacturers must provide for the Wi-Fi framework
• System APIs, configurations, and HAL APIs related to the channel avoidance feature
• Framework behavior for handling channel avoidance
• Chip vendor behavior for handling channel avoidance
• Implementation details for channel avoidance
• Tests for validating channel avoidance behavior

## Background

For devices with cellular technologies such as LTE, 5G NR, and Licensed Assisted Access (LAA), the cellular channels in use can interfere with the Wi-Fi channel in use. This occurs when the cellular and Wi-Fi channels are within short frequency separation (neighboring channels) or when there is harmonic and intermodulation interference.

This type of interference becomes a problem when one antenna is transmitting and another is receiving at the same time. In this case, the transmitting antenna floods the receiving antenna, impacting its reception quality.

This document refers to the interfering transmitter as the aggressor and the receiver experiencing the interference as the victim. The Wi-Fi channel that is either the aggressor or the victim is referred to as an unsafe channel.

The Wi-Fi/cellular coex channel avoidance feature provides a consistent approach for channel avoidance reducing the need for proprietary code that diverges from the Wi-Fi framework. Additionally, the feature allows device manufacturers to configure, enable and disable, and override the feature.

The feature performs channel avoidance by controlling the Wi-Fi channels. The Wi-Fi channel avoidance scheme can be described as a series of four abstract steps:

1. Modem reports change in cellular frequency
2. Coex avoidance algorithm calculates unsafe Wi-Fi channels
3. Coex avoidance algorithm informs Wi-Fi service
4. Framework or driver performs appropriate Wi-Fi action

Figure 1. Channel avoidance scheme

## Reporting a change in cellular frequency

The telephony service reports the cellular channels currently in use. When the operating cellular frequency changes, the modem reports this information to the telephony service through IRadio::PhysicalChannelConfig. This information includes indications for licensed assisted access (LAA) and carrier aggregation (CA).

From Android 12, the following fields in 1.6 IRadio::PhysicalChannelConfig provide required information for the coex formulas that the modem must populate.

struct PhysicalChannelConfig {
/** Connection status for cell. Valid values are PRIMARY_SERVING and SECONDARY_SERVING */
CellConnectionStatus status;

/** The radio technology for this physical channel */

/** Downlink cell bandwidth, in kHz */

/** Uplink cell bandwidth, in kHz */
}

## Calculating unsafe Wi-Fi channels

When the modem reports a change in cellular frequency, the coex channel algorithm calculates the interference between cellular and Wi-Fi channels and determines what set of Wi-Fi channels are unsafe.

There are multiple types of interference requiring different formulas: neighboring and harmonic/intermodulation. Due to the physical differences in antenna and layout between devices, the patterns of neighboring and harmonic/intermodulation interference for each device are different. To account for this, device manufacturers must provide a lookup table to plug parameters into generic formulas for the two types of interference. These parameters are defined per cell band and are referenced by the bands of the active cell channels.

A maximum power cap can be defined in the lookup table. If a maximum power cap is defined, an unsafe channel transmits with the provided power cap. If there's no power cap, the channel transmits at full power.

In general, the channel avoidance feature uses a best effort approach to avoid unsafe Wi-Fi channels to optimize performance. But in certain cases (for example, because of carrier requirements), it's mandatory for certain interfaces to avoid unsafe channels for certain cellular bands. In such cases, mandatory restrictions are represented as a bitmask containing values for whether to prohibit certain channels such as Wi-Fi Direct (P2P), SoftAp, and Wi-Fi Aware (NAN). While an unsafe channel acts as a recommendation against using that channel for all use cases, mandatory restrictions mark specific use cases for mandatory avoidance.

If every channel of the 2.4GHz or 5GHz band is marked unsafe, the lookup table can define a default 2.4GHz channel or a default 5GHz channel per interfering cell band as the safest choice. These default channels aren't reported as unsafe channels when the rest of the band is reported unsafe.

### Override list

A formulaic approach is limited in cases where interference is heavily bandwidth dependent (and thus channels with larger bandwidth might be unsafe but not channels with smaller bandwidth). In cases, such as with LAA, it's beneficial to skip the calculations and use a specified list of unsafe channels.

To do this, you can specify an override list of unsafe channels in the lookup table for certain entries. An override list in a table entry signifies that the calculation for that particular cell channel is skipped and that the unsafe Wi-Fi channels for the matching cell channel are specified by the override list.

For bandwidth-sensitive cases, you can selectively avoid certain bandwidths by specifying certain channels with certain bandwidths in the override list. This is because each Wi-Fi channel number corresponds to a specified bandwidth.

The override list is represented by a list of channel numbers or pre-defined category keywords for each Wi-Fi band:

2g categories:

• all (entire 2.4GHz band)

5g categories:

• all (entire 5GHz band)
• 20mhz (5GHz 20MHz channels)
• 40mhz (5GHz 40MHz channels)
• 80mhz (5GHz 80MHz channels)
• 160mhz (5GHz 160MHz channels)

### Neighboring channel interference

To determine neighboring channel interference, the coex avoidance algorithm makes sure the distance ΔF between an aggressor and victim channel doesn't go under a specified threshold.

Figure 2. Distance between an aggressor and victim channel

The threshold is determined by the physical configuration of the device and the threshold value provided in the lookup table entry per interfering band. Bands that are considered non-interfering don't have a table entry and unsafe channels don't need to be calculated (this is the majority of the time).

Neighboring interference parameters

• wifiVictimMhz: MHz distance threshold for a Wi-Fi victim (cell uplink)
• cellVictimMhz: MHz distance threshold for a cell victim (cell downlink)

The algorithm behaves as follows for each active cell channel:

1. For the channel's band, tries to find a lookup table entry. If no table entry is found, returns with no unsafe channels for that cell channel.
2. Based on the cellular band, identifies which Wi-Fi band is at risk and which side of the band the interference comes from (for example, lower 2.4GHz channels, higher 2.4GHz channels, lower 5GHz channels).
3. If wifiVictimMhz is present and the cell channel has uplink and

1. If the lower part of the Wi-Fi band is at risk

1. Finds the upper limit of unsafe channels by adding wifiVictimMhz to the cell uplink's highest frequency.
2. Finds the first 20Mhz Wi-Fi channel whose lower edge overlaps the limit.
3. Marks the Wi-Fi channel, every larger bandwidth channel that contains it (for example, 40Mhz, 80Mhz), and every lower channel of the same band as the unsafe channel.
2. If the upper part of the Wi-Fi band is at risk

1. Finds the lower limit of unsafe channels by subtracting wifiVictimMhz to the cell uplink's lowest frequency.
2. Finds the first Wi-Fi channel whose upper edge overlaps the limit.
3. Marks the Wi-Fi channel, every larger channel that contains it (for example, 40Mhz, 80Mhz), and every higher channel of the same band as the unsafe channel.
4. If cellVictimMhz is present and the cell channel has downlink.

1. Performs step 3 using cellVictimMhz as the threshold and compares against cell downlink instead of cell uplink.
5. Applies the table entry's power cap to the calculated unsafe channels.

Figure 3. Unsafe channel calculation for neighboring channel interference

### Harmonic/intermodulation distortion

For harmonic/intermodulation distortion, the coex engine calculates the range of the harmonic/intermodulation signal and evaluates the percent overlap it has with a potential victim channel. If the overlap exceeds an overlap threshold, the algorithm considers this an unsafe situation. The calculation of the percent overlap of the harmonic/intermodulation distortion on a victim channel is performed with the following equation:

$$overlap = \frac{min(distortion_{high}, victim_{high}) - max(distortion_{low}, victim_{low})}{victim_{bandwidth}}$$

In the harmonic distortion case, the algorithm considers the harmonic distortion of a cell uplink channel victimizing Wi-Fi channels. It then substitutes the distortion high and distortion low with the harmonic values based on the cell uplink frequencies and a harmonic degree $N$.

$$harmonic_{high} = N * uplink_{high}$$
$$harmonic_{low} = N * uplink_{low}$$

Figure 4. Unsafe channel calculation for harmonic distortion

In the intermodulation case, the algorithm considers the intermodulation distortion of the cell uplink and the Wi-Fi channel victimizing the cell downlink channel. It then substitutes the distortion high and distortion low with the intermodulation values based on the cell uplink frequencies, Wi-Fi frequencies, and the two intermodulation coefficients $M$, $N$.

$$intermod_{high} = |M*wifi_{high} + N*uplink_{high}|$$
$$intermod_{low} = |M*wifi_{low} + N*uplink_{low}|$$

Figure 5. Unsafe channel calculation for intermodulation distortion

You can specify $M$, $N$ and overlap values in the lookup table per interfering cell band. If there is no interference for a band, then the values are omitted from the table for that band entry. Two sets of these values for the Wi-Fi 2.4GHz and 5GHz bands can be independently defined.

Similar to the neighboring interference algorithm, the algorithm reuses the same power cap value defined per interfering cell band.

The algorithm behaves as follows for each active cell channel:

1. For the cell channel's band, it tries to find a lookup table entry. If no table entry is found, returns with no unsafe channels for this channel.
2. Finds the unsafe 2.4GHz channels from harmonics if parameters are defined.

1. Finds the harmonic degree N for 2.4GHz.
2. Calculates the harmonic high frequency and the harmonic low frequency based on N and the cell uplink.
3. Finds the first 20MHz Wi-Fi channel that is within the lower bound of the harmonic coming from below.
4. Calculates the overlap of the harmonic over the Wi-Fi channel and marks the channel as unsafe if the overlap exceeds the 2.4GHz Wi-Fi overlap threshold.
5. Finds the first 20MHz Wi-Fi channel that is within the upper bound of the harmonic coming from above.
6. Calculates the overlap of the harmonic over the Wi-Fi channel and marks the channel as unsafe if the overlap exceeds the 2.4GHz Wi-Fi overlap threshold.
7. Marks every 20MHz channel in between as an unsafe channel.
3. Finds the unsafe 5GHz channels from harmonics if parameters are defined.

1. Finds the harmonic degree N for 5GHz. If N is 0, skips to step 5.
2. Calculates the harmonic high frequency and the harmonic low frequency based on N and the cell uplink.
3. Finds unsafe 20Mhz channels.

1. Finds the first 20MHz Wi-Fi channel that is within the lower bound of the harmonic coming from below.
2. Calculates the overlap of the harmonic over the Wi-Fi channel and marks the channel as unsafe if the overlap exceeds the 2.4GHz Wi-Fi overlap threshold.
3. Finds the first 20MHz Wi-Fi channel that is within the upper bound of the harmonic coming from above.
4. Calculates the overlap of the harmonic over the Wi-Fi channel and marks the channel as unsafe if the overlap exceeds the 2.4GHz Wi-Fi overlap threshold.
5. Marks every 20MHz channel in between as an unsafe channel with the specified power cap.
4. Finds unsafe 40MHz, 80MHz, 160MHz channels

1. Repeats step 3a but with 40MHz, 80MHz, 160MHz.
2. Instead of calculating the overlaps of the channels on the harmonic edge, reuses the calculated overlaps from the smaller constituent channels (for example, if two 20Mhz channels make a 40Mhz channel and have 30% and 90% overlap, then the average is 60% overlap for the 40Mhz channel).
4. Finds the unsafe 2.4GHz channels from intermodulation if parameters are defined.

1. Finds the intermodulation coefficients N, M for 2.4GHz.
2. For each 2.4GHz Wi-Fi channel:

1. Calculates the intermodulation low frequency and intermodulation high frequency based on N, M, cell uplink, and Wi-Fi channel.
2. Calculates the overlap of the intermodulation over cell downlink and marks the channel as unsafe if the overlap exceeds the 2.4GHz cell overlap threshold.
5. Finds the unsafe 5GHz channels from intermodulation if parameters are defined.

1. Repeats step 4 using the 5GHz Wi-Fi channels and 5GHz cell overlap threshold.
6. Applies the table entry's power cap to the calculated unsafe channels.

### Final result

After both sets of unsafe channels from neighboring and harmonic interference are calculated, the final set is calculated by taking the union of both sets (and selecting the lower power cap if there are collisions), and removing the default channels from the set if there are no mandatory restrictions applied.

The algorithm behaves as follows:

1. If every 2.4GHz Wi-Fi channel is marked as an unsafe channel, removes the default 2.4GHz Wi-Fi channel from the set.
2. If every 5GHz Wi-Fi channel is marked as an unsafe channel, removes the default 5GHz Wi-Fi channel from the set.
3. Returns the final set of unsafe channels.

### Lookup table format

The lookup tables are represented in an XML file located in the overlayable config string config_wifiCoexTableFilepath, and is defined by the following XSD.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
version="1.0">

<xsd:element name="table">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="entry" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:element name="entry">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="rat" type="ratType"/>
<xsd:element name="band" type="xsd:int"/>
<xsd:element name="powerCapDbm" type="xsd:int" minOccurs="0"/>
<xsd:choice>
<xsd:element ref="params"/>
<xsd:element ref="override"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:simpleType name="ratType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="LTE"/>
<xsd:enumeration value="NR"/>
</xsd:restriction>
</xsd:simpleType>

<!-- Define coex algorithm parameters -->
<xsd:element name="params">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="neighborThresholds" minOccurs="0"/>
<xsd:element name="harmonicParams2g" type="harmonicParams" minOccurs="0"/>
<xsd:element name="harmonicParams5g" type="harmonicParams" minOccurs="0"/>
<xsd:element name="intermodParams2g" type="intermodParams" minOccurs="0"/>
<xsd:element name="intermodParams5g" type="intermodParams" minOccurs="0"/>
<xsd:element ref="defaultChannels" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:element name="neighborThresholds">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="wifiVictimMhz" type="xsd:int" minOccurs="0"/>
<xsd:element name="cellVictimMhz" type="xsd:int" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:complexType name="harmonicParams">
<xsd:sequence>
<xsd:element name="N" type="xsd:int"/>
<xsd:element name="overlap" type="xsd:int"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="intermodParams">
<xsd:sequence>
<xsd:element name="N" type="xsd:int"/>
<xsd:element name="M" type="xsd:int"/>
<xsd:element name="overlap" type="xsd:int"/>
</xsd:sequence>
</xsd:complexType>

<xsd:element name="defaultChannels">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="default2g" type="xsd:int" minOccurs="0"/>
<xsd:element name="default5g" type="xsd:int" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<!-- Define algorithm override lists -->
<xsd:element name="override">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="override2g" minOccurs="0"/>
<xsd:element ref="override5g" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:element name="override2g">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="category" type="overrideCategory2g" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="channel" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:element name="override5g">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="category" type="overrideCategory5g" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="channel" type="xsd:int" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:simpleType name="overrideCategory2g">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="all"/>
</xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="overrideCategory5g">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="all"/>
<xsd:enumeration value="20Mhz"/>
<xsd:enumeration value="40Mhz"/>
<xsd:enumeration value="80Mhz"/>
<xsd:enumeration value="160Mhz"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>

#### Example XML table

The following is an example XML lookup table:

<table>
<!-- Entry using algorithm parameters -->
<entry>
<rat>LTE</rat>
<band>40</band>
<powerCapDbm>50</powerCapDbm>
<params>
<neighborThresholds>
<wifiVictimMhz>25</wifiVictimMhz>
<cellVictimMhz>40</cellVictimMhz>
</neighborThresholds>

<harmonicParams2g>
<N>3</N>
<overlap>50</overlap>
</harmonicParams2g>

<harmonicParams5g>
<N>3</N>
<overlap>50</overlap>
</harmonicParams5g>

<intermodParams2g>
<N>-2</N>
<M>1</M>
<overlap>75</overlap>
</intermodParams2g>

<intermodParams5g>
<N>-2</N>
<M>1</M>
<overlap>75</overlap>
</intermodParams5g>

<defaultChannels>
<default2g>6</default2g>
<default5g>36</default5g>
</defaultChannels>
</params>
</entry>
<!-- Entry using the override list -->
<entry>
<rat>LTE</rat>
<band>41</band>
<powerCapDbm>50</powerCapDbm>
<override>
<override2g>
<channel>6</channel>
<channel>11</channel>
...
</override2g>
<override5g>
<category>40Mhz</category>
<channel>34</channel>
...
</override5g>
</override>
</entry>
</table>

### Carrier aggregation

For carrier aggregation (CA), the harmonic/intermodulation ranges for each uplink/downlink might not produce enough overlap to cause interference independently, but might produce enough overlap when combined. The algorithm considers each harmonic/intermodulation range independently and takes the union of the returned unsafe channels. For the intermodulation case, this means assessing the intermodulation range of every UL onto every DL.

The algorithm makes no distinction between PCELL/PSCELL/SCELLs and treats them as equal.

License Assisted Access (LAA) is identified as band #46. The algorithm treats this band similar to other bands. In this case, the full 5Ghz channels can be set as an override list in the lookup table.

Depending on carrier requirements, the channel avoidance algorithm sets mandatory restrictions on SoftAP and Wi-Fi Direct (P2P) for the entire 5GHz Wi-Fi band. For the algorithm to handle this use case, the carrier config value restrict_5g_softap_wifi_direct_for_laa must be defined. If the cell channel is on LAA and restrict_5g_softap_wifi_direct_for_laa is true, the algorithm returns the set of unsafe channels with the entire 5Ghz band and sets the mandatory restriction flags for SoftAP and Wi-Fi Direct (P2P).

## Informing Wi-Fi service

After the coex channel algorithm has calculated the unsafe channels, to provide your system apps with the unsafe channels and their restrictions, use the following @SystemApi data structure defined in the Android framework.

public final class CoexUnsafeChannel {
public static final int POWER_CAP_NONE
public @WifiAnnotations.WifiBandBasic int getBand();
public int getChannel();
// Returns the specified power cap in dBm, or POWER_CAP_NONE if not specified.
public int getPowerCapDbm();
}

Use the following WifiManager @SystemApi methods and callback to enable the apps to get updated values when the unsafe channels change.

public static final int COEX_RESTRICTION_WIFI_DIRECT;
public static final int COEX_RESTRICTION_SOFTAP;
public static final int COEX_RESTRICTION_WIFI_AWARE;

// Register a CoexCallback to listen on onCoexUnsafeChannelsChanged callbacks. The callback will be called whenever the unsafe channels change, as well as immediately after registering to get the current values.
public void registerCoexCallback(Executor executor, CoexCallback callback);
public void unregisterCoexCallback(CoexCallback callback);

public abstract static class CoexCallback {
//Gets called whenever getCoexUnsafeChannels()/getCoexRestrictions() have updated values
public void onCoexUnsafeChannelsChanged(List<CoexUnsafeChannels> unsafeChannels, int restrictions);
}

## Performing Wi-Fi action

When the Wi-Fi service receives information about the set of unsafe channels, it performs the appropriate action to ensure that those channels are avoided. This section describes the behavior of the Wi-Fi service in different scenarios.

### Informing the driver

Because the driver has a major role in performing channel avoidance, it's essential to convey the unsafe channels to the driver and firmware. To do this, use the 1.5::IWifiChip HAL API.

setCoexUnsafeChannels(vec<CoexUnsafeChannel> unsafeChannels,
bitfield<IfaceType> restrictions);

### SoftAP

SoftAP is the main use case for unsafe channel avoidance. The following section outlines the key SoftAp scenarios where channel avoidance can be applied with ACS. The scenarios describe the behavior of the channel avoidance algorithm and the driver or firmware.

#### Starting SoftAP with ACS enabled (no SoftAP is up yet)

1. If channels are unsafe and there is a SoftAP restriction

1. The framework removes unsafe channels from the ACS list.
2. If the list is empty, the framework stops SoftAP.
2. If channels are unsafe and there are no restrictions

1. The vendor driver/firmware gives priority to the safe channels over the unsafe channels.

#### SoftAP is up with ACS enabled and unsafe channels are updated

1. If the SoftAP channel is unsafe and there's a SoftAP restriction

1. The framework updates the ACS list by removing the unsafe channels.
2. If the list is empty, the framework closes SoftAP.
2. If the SoftAP channel is unsafe and there are no restrictions

1. No action is taken by the framework. The vendor driver/firmware handles avoiding the unsafe channels or applying the power cap if avoidance isn't feasible.

### Wi-Fi Direct (P2P)

1. If there are unsafe channels with Wi-Fi Direct (P2P) restrictions.

1. The framework requests wpa_supplicant to avoid the unsafe channels using the HAL method ISupplicantP2pIface::setDisallowedFrequencies().
2. If there are unsafe channels without restrictions.

1. The vendor driver/firmware applies the power cap if an unsafe channel without Wi-Fi Direct (P2P) restriction is used.

### Wi-Fi Aware (NAN)

The framework isn't involved in channel selection for Wi-Fi Aware (NAN) and no framework action is taken. The vendor driver/firmware is responsible for Wi-Fi Aware (NAN) channel avoidance.

## Disabling the algorithm

If you want to disable the default algorithm implementation and pass your own list of unsafe channels for avoidance, configure the overlay config_wifiDefaultCoexAlgorithmEnabled. If the overlay is set to false, the default algorithm is disabled. You can then use your own out-of-band proprietary algorithm to generate a list of unsafe channels to plumb to the framework using the following system API.

public void setCoexUnsafeChannels(Set<CoexUnsafeChannel> coexUnsafeChannels,
int coexRestrictions);

## Validating the implementation

To validate your implementation of the Wi-Fi/cellular coex channel avoidance feature, use the following tests.

### CTS tests

• WifiManagerTest.java

• testCoexMethodsShouldFailNoPermission()
• testListenOnCoexUnsafeChannels()

### ACTS tests

• WifiManagerTest.py

• test_set_get_coex_unsafe_channels()

### VTS tests

• wifi_chip_hidl_test.cpp

• TEST_P(WifiChipHidlTest, setCoexUnsafeChannels)
[{ "type": "thumb-down", "id": "missingTheInformationINeed", "label":"Missing the information I need" },{ "type": "thumb-down", "id": "tooComplicatedTooManySteps", "label":"Too complicated / too many steps" },{ "type": "thumb-down", "id": "outOfDate", "label":"Out of date" },{ "type": "thumb-down", "id": "samplesCodeIssue", "label":"Samples / code issue" },{ "type": "thumb-down", "id": "otherDown", "label":"Other" }]
[{ "type": "thumb-up", "id": "easyToUnderstand", "label":"Easy to understand" },{ "type": "thumb-up", "id": "solvedMyProblem", "label":"Solved my problem" },{ "type": "thumb-up", "id": "otherUp", "label":"Other" }]