2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
테더링 하드웨어 오프로드
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
테더링 오프로드로 테더링 트래픽을 USB, Wi-Fi를 통해 하드웨어에 오프로드하여 기기에서 전력을 절약하고 성능을 개선할 수 있습니다. 테더링 트래픽은 모뎀과 주변기기 사이에 앱 프로세서를 우회하는 직접 경로를 제공하여 오프로드됩니다.
사양
Android 8.1부터 기기에서 테더링 오프로드를 사용하여 IPv4, IPv6 또는 IPv4+IPv6 전달을 하드웨어에 오프로드할 수 있습니다.
오프로드 기능은 모든 패킷을 오프로드할 필요가 없습니다. 프레임워크는 소프트웨어의 모든 패킷을 처리할 수 있습니다. 제어 패킷은 일반적으로 소프트웨어에서 처리됩니다. IPv4 포트는 테더링된 트래픽과 기기 트래픽 간에 공유되므로 IPv4 세션 설정/해제 패킷(예: SYN/SYN+ACK, FIN)이 소프트웨어에서 처리되어 커널이 흐름 상태를 구성할 수 있어야 합니다. 프레임워크는 제어판과 상태 시스템을 제공합니다. 하드웨어에 업스트림 및 다운스트림 인터페이스/프리픽스에 관한 정보도 제공합니다.
IPv4의 경우 하드웨어를 통해 IPv4 네트워크 주소 변환(NAT) 세션 설정 패킷이 CPU에 도달할 수 있습니다. 커널은 NAT 항목을 만들고 HAL 구현은 프레임워크에서 제공한 파일 설명자의 항목을 관찰하며 하드웨어에서 이러한 흐름을 처리합니다. 즉, HAL 구현에는 CAP_NET_*이 필요하지 않습니다. HAL이 열린 NF_NETLINK_CONNTRACK 소켓을 프레임워크에서 가져오기 때문입니다. 주기적으로 하드웨어는 현재 활성 흐름의 NAT 상태 업데이트를 프레임워크에 전송하여 상응하는 커널 연결 추적 상태 항목을 새로고침합니다.
IPv6의 경우 프레임워크는 트래픽을 오프로드해서는 안 되는 IPv6 대상 프리픽스 목록을 프로그래밍합니다. 다른 모든 테더링된 패킷은 오프로드할 수 있습니다.
데이터 사용량 계산의 경우 NetworkStatsService 데이터 사용량 설문조사로 인해 프레임워크가 하드웨어에서 트래픽 통계를 요청합니다. 프레임워크는 HAL을 통해 데이터 사용량 한도도 하드웨어에 전달합니다.
하드웨어 요구사항
테더링 오프로드를 구현하려면 하드웨어가 기본 프로세서를 통해 트래픽을 전송하지 않고도 모뎀과 Wi-Fi/USB 간에 IP 패킷을 전달할 수 있어야 합니다.
구현
테더링 오프로드 기능을 사용 설정하려면 구성 HAL(IOffloadConfig)과 제어 HAL(IOffloadControl)을 모두 구현해야 합니다.
구성 HAL: IOffloadConfig
IOffloadConfig HAL은 테더링 오프로드 구현을 시작합니다. 프레임워크는 구현에서 IPv4 흐름을 관찰하는 데 사용할 수 있는 사전 연결된 NF_NETLINK_CONNTRACK 소켓을 HAL 구현에 제공합니다. 전달된 흐름만 가속화해야 합니다.
제어 HAL: IOffloadControl
IOffloadControl HAL은 오프로드 구현을 제어합니다. 다음 메서드가 구현되어야 합니다.
- 오프로드 하드웨어 시작/중지:
initOffload/stopOffload를 사용하며 setLocalPrefixes로 로컬 IP 주소 또는 다른 네트워크를 오프로드에서 제외합니다.
- 업스트림 인터페이스, IPv4 주소 및 IPv6 게이트웨이 설정:
setUpstreamParameters를 사용하며 addDownstream/removeDownstream으로 다운스트림 IP 주소 범위를 구성합니다.
- 데이터 사용량 계산:
getForwardedStats/setDataLimit를 사용합니다.
공급업체 HAL은 ITetheringOffloadCallback 인터페이스를 통해 콜백도 전송하여 프레임워크에 다음을 알립니다.
- 오프로드 시작 및 중지와 같은 비동기 이벤트(OffloadCallbackEvent)
- 주기적으로 전송되어 특정 IPv4 흐름이 트래픽을 포함하고 커널에 의해 종료되어서는 안 된다고 표시해야 하는 NAT 시간 제한 업데이트
유효성 검사
테더링 오프로드 구현을 검증하려면 수동 또는 자동 테스트를 사용하여 테더링 및 Wi-Fi 핫스팟이 예상대로 작동하는지 확인합니다. 공급업체 테스트 도구 모음(VTS)에는 테더링 오프로드 HAL 테스트가 포함되어 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-03-26(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-03-26(UTC)"],[],[],null,["# Tethering hardware offload\n\nTethering offload enables devices to save power and improve performance by\noffloading the tethering traffic (over USB, Wi-Fi) to the hardware. The\ntethering traffic is offloaded by providing a direct path between the modem and\nthe peripherals, bypassing the app processor.\n\nSpecifications\n--------------\n\nStarting in Android 8.1, devices can use tethering offload to\noffload IPv4, IPv6, or IPv4+IPv6 forwarding to the hardware.\n\nThe offload feature doesn't need to offload all packets. The framework is\ncapable of handling any packet in software. Control packets are typically\nprocessed in software. Because IPv4 ports are shared between tethered traffic\nand device traffic, IPv4 session setup/teardown packets (for\nexample, SYN/SYN+ACK, FIN) must be processed in software so the kernel can\nconstruct the flow state. The framework provides the control plane and state\nmachines. It also provides the hardware with information on upstream and\ndownstream interfaces/prefixes.\n\nFor IPv4, the hardware allows IPv4 network address translation (NAT) session\nsetup packets to reach the CPU. The kernel creates NAT entries, and the HAL\nimplementation observes the entries from the framework-provided file descriptors\nand handles these flows in hardware. This means the HAL implementation doesn't\nrequire `CAP_NET_*` because the HAL gets opened `NF_NETLINK_CONNTRACK` sockets\nfrom the framework. Periodically, the hardware sends NAT state updates for\ncurrently active flows to the framework, which refreshes the corresponding\nkernel connection tracking state entries.\n\nFor IPv6, the framework programs a list of IPv6 destination prefixes to which\ntraffic must not be offloaded. All other tethered packets can be offloaded.\n\nFor data usage accounting, `NetworkStatsService` data usage polls causes the\nframework to request traffic stats from hardware. The framework also\ncommunicates data usage limits to the hardware via the HAL.\n\nHardware requirements\n---------------------\n\nTo implement tethering offload, your hardware must be capable of forwarding IP\npackets between the modem and Wi-Fi/USB without sending the traffic through the\nmain processor.\n\nImplementation\n--------------\n\nTo enable the tethering offload feature, you must implement the two following\nboth a config HAL (`IOffloadConfig`) and a control HAL (`IOffloadControl`).\n\n### Config HAL: IOffloadConfig\n\nThe\n[`IOffloadConfig`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/tetheroffload/config/1.0/IOffloadConfig.hal)\nHAL starts the tethering offload implementation. The framework provides the HAL\nimplementation with pre-connected `NF_NETLINK_CONNTRACK` sockets that the\nimplementation can use to observe the IPv4 flows. Only forwarded flows must be\naccelerated.\n\n### Control HAL: IOffloadControl\n\nThe\n[`IOffloadControl`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/tetheroffload/control/1.0/IOffloadControl.hal)\nHAL controls the offload implementation. The following methods must be\nimplemented:\n\n- Start/stop offload hardware: Use `initOffload/stopOffload` and exempt local IP addresses or other networks from offload with `setLocalPrefixes`.\n- Set upstream interface, IPv4 address, and IPv6 gateways: Use `setUpstreamParameters` and configure downstream IP address ranges with `addDownstream/removeDownstream`.\n- Data usage accounting: Use `getForwardedStats/setDataLimit`.\n\nYour vendor HAL must also send callbacks through the `ITetheringOffloadCallback`\ninterface, which informs the framework of:\n\n- Asynchronous events such as offload being started and stopped (OffloadCallbackEvent)\n- 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\n\nValidation\n----------\n\nTo validate your implementation of tethering offload, use manual or automated\ntesting to verify tethering and Wi-Fi hotspot work as expected. The\n[Vendor Test Suite (VTS)](/docs/core/tests/vts)\ncontains tests for the tethering offload HALs."]]
