3 files changed, 201 insertions, 2 deletions
diff --git a/en/devices/tech/connect/carrier-wifi.md b/en/devices/tech/connect/carrier-wifi.md
index 9e96c391..b07e7748 100644
--- a/en/devices/tech/connect/carrier-wifi.md
+++ b/en/devices/tech/connect/carrier-wifi.md
@@ -34,7 +34,7 @@ Wi-Fi.
 
 ### Manufacturers
 
-In the carrier config manager,  configure the following parameters for each
+In the carrier config manager, configure the following parameters for each
 carrier:
 
 +  [`KEY_CARRIER_WIFI_STRING_ARRAY`](https://android.googlesource.com/platform/frameworks/base/+/master/telephony/java/android/telephony/CarrierConfigManager.java#1606){: .external}:
diff --git a/en/devices/tech/connect/tethering-offload.md b/en/devices/tech/connect/tethering-offload.md
new file mode 100644
index 00000000..8b420335
--- /dev/null
+++ b/en/devices/tech/connect/tethering-offload.md
@@ -0,0 +1,103 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+<!--
+  Copyright 2018 The Android Open Source Project
+
+  Licensed under the Apache License, Version 2.0 (the "License");
+  you may not use this file except in compliance with the License.
+  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+-->
+
+# Tethering Hardware Offload
+
+Tethering offload enables devices to save power and improve performance by
+offloading the tethering traffic (over USB, Wi-Fi) to the hardware. The
+tethering traffic is offloaded by providing a direct path between the modem and
+the peripherals, bypassing the application processor.
+
+## Specifications
+
+Starting in Android 8.1, devices can use tethering offload to
+offload IPv4, IPv6, or IPv4+IPv6 forwarding to the hardware.
+
+The offload feature does not need to offload all packets. The framework is
+capable of handling any packet in software. Control packets are typically
+processed in software. Because IPv4 ports are shared between tethered traffic
+and device traffic, IPv4 session setup/teardown packets (e.g., SYN/SYN+ACK, FIN)
+must be processed in software so the kernel can construct the flow state.
+The framework provides the control plane and state machines. It also provides
+the hardware with information on upstream and downstream interfaces/prefixes.
+
+For IPv4, the hardware allows IPv4 network address translation (NAT) session
+setup packets to reach the CPU. The kernel creates NAT entries, and the HAL
+implementation observes the entries from the framework-provided file descriptors
+and handles these flows in hardware. This means the HAL implementation does not
+require `CAP_NET_*` because the HAL gets opened `NF_NETLINK_CONNTRACK` sockets
+from the framework. Periodically, the hardware sends NAT state updates for
+currently active flows to the framework, which refreshes the corresponding
+kernel connection tracking state entries.
+
+For IPv6, the framework programs a list of IPv6 destination prefixes to which
+traffic must not be offloaded. All other tethered packets can be offloaded.
+
+For data usage accounting, `NetworkStatsService` data usage polls causes the
+framework to request traffic stats from hardware. The framework also
+communicates data usage limits to the hardware via the HAL.
+
+## Hardware requirements
+
+To implement tethering offload, your hardware must be capable of forwarding IP
+packets between the modem and Wi-Fi/USB without sending the traffic through the
+main processor.
+
+## Implementation
+
+To enable the tethering offload feature, you must implement the two following
+both a config HAL (`IOffloadConfig`) and a control HAL (`IOffloadControl`).
+
+### Config HAL: `IOffloadConfig`
+
+The
+[`IOffloadConfig`](/reference/hidl/android/hardware/tetheroffload/config/1.0/IOffloadConfig)
+HAL starts the tethering offload implementation. The framework provides the HAL
+implementation with pre-connected `NF_NETLINK_CONNTRACK` sockets that the
+implementation can use to observe the IPv4 flows. Only forwarded flows must be
+accelerated.
+
+### Control HAL: `IOffloadControl`
+
+The
+[`IOffloadControl`](/reference/hidl/android/hardware/tetheroffload/control/1.0/IOffloadControl)
+HAL controls the offload implementation. The following methods must be
+implemented:
+
++   Start/stop offload hardware: Use `initOffload/stopOffload` and exempt local
+    IP addresses or other networks from offload with `setLocalPrefixes`.
++   Set upstream interface, IPv4 address, and IPv6 gateways: Use
+    `setUpstreamParameters` and configure downstream IP address ranges with
+    `addDownstream/removeDownstream`.
++   Data usage accounting: Use `getForwardedStats/setDataLimit`.
+
+Your vendor HAL must also send callbacks via the `ITetheringOffloadCallback`
+interface, which informs the framework of:
+
++   Asynchronous events such as offload being started and stopped
+    (OffloadCallbackEvent)
++   NAT timeout updates, which must be sent periodically to indicate that a
+    specific IPv4 flow contains traffic and must not be closed by the kernel
+
+## Validation
+
+To validate your implementation of tethering offload, use manual or automated
+testing to verify tethering and Wi-Fi hotspot work as expected. The
+[Vendor Test Suite (VTS)](/compatibility/vts/)
+contains tests for the tethering offload HALs.
diff --git a/en/devices/tech/connect/wifi-passpoint.md b/en/devices/tech/connect/wifi-passpoint.md
index f75a5adc..4ee96591 100644
--- a/en/devices/tech/connect/wifi-passpoint.md
+++ b/en/devices/tech/connect/wifi-passpoint.md
@@ -152,7 +152,7 @@ The following sub-tree nodes are used under `Credential`:
     relax the IMSI matching to prefix only. For example, the IMSI string 123\*
     matches any SIM card with an IMSI starting with 123.
 
-# Example Profile OMA-DM XML
+## Example Profile OMA-DM XML
 
 ```xml
 <MgmtTree xmlns="syncml:dmddf1.2">
@@ -214,3 +214,99 @@ The following sub-tree nodes are used under `Credential`:
   </Node>
 </MgmtTree>
 ```
+
+## Auth advisory
+
+Devices running Android 8.0 or higher with a Passpoint R1 EAP-SIM, EAP-AKA,
+or EAP-AKA' profile will fail to auto-connect to the Passpoint network. This
+issue affects users, carriers, and services by reducing the Wi-Fi offload.
+
+
+<table>
+  <tr>
+   <th><strong>Segment</strong>
+   </th>
+   <th><strong>Impact</strong>
+   </th>
+   <th><strong>Size of impact</strong>
+   </th>
+  </tr>
+  <tr>
+   <td>Carriers and Passpoint service providers
+   </td>
+   <td>Increased load on cellular network.
+   </td>
+   <td>Any carrier using Passpoint R1.
+   </td>
+  </tr>
+  <tr>
+   <td>Users
+   </td>
+   <td>Missed opportunity to auto-connect to Carrier Wi-Fi access points
+    (APs), resulting in higher data costs.
+   </td>
+   <td>Any user with a device that runs on a carrier network supporting
+    Passpoint R1.
+   </td>
+  </tr>
+</table>
+
+### Cause of failure
+
+Passpoint specifies a mechanism to match an advertised (ANQP) service provider
+to a profile installed on the device. The following matching rules for
+EAP-SIM, EAP-AKA, and EAP-AKA' are a partial set of rules focusing on the
+EAP-SIM/AKA/AKA' failures:
+
+
+```
+If the FQDN (Fully Qualified Domain Name) matches
+    then the service is a Home Service Provider.
+Else: If the PLMN ID (3GPP Network) matches
+    then the service is a Roaming Service Provider.
+```
+
+The second criteria was modified in Android 8.0:
+
+```
+Else: If the PLMN ID (3GPP Network) matches AND the NAI Realm matches
+    then the service is a Roaming Service Provider.
+```
+
+This modified criteria meant the system observed no match for previously
+working service providers, so Passpoint devices did not auto-connect.
+
+
+### Workarounds
+
+To work around the issue of the modified matching criteria, carriers and
+service providers need to add the `NAI Realm` to the information published by
+the Passpoint AP.
+
+The recommended solution is for network service providers to implement a
+network-side workaround for the fastest time to deployment. A device-side
+workaround depends on OEMs picking up a changelist (CL) from the Android Open
+Source Project (AOSP) and then updating devices in the field.
+
+
+#### Network fix for Carriers and Passpoint service providers
+
+The network-side workaround requires reconfiguring the network to add the `NAI
+Realm` ANQP element as specified below. The Passpoint specifications do not
+require the `NAI Realm` ANQP element, but the addition of this property
+complies with the Passpoint specifications, so spec-compliant client
+implementations should not break.
+
+1.  Add the `NAI Realm` ANQP element.
+1.  Set the `NAI Realm` sub-field to match the `Realm` of the profile
+    installed on the device.
+
+####  Device/AOSP fix for OEMs
+
+To implement a device-side workaround, OEMs need to pick the patch CL [aosp/718508](https://android-review.googlesource.com/c/platform/frameworks/opt/net/wifi/+/718508).
+This patch can be applied on top of the following releases:
+
++   Android 8.x
++   Android 9
+
+Once the patch is picked up, OEMs need to update devices in the field.