1.. _bt_mesh_proxy:
2
3Proxy
4#####
5
6The Proxy feature allows legacy devices like phones to access the Bluetooth Mesh network through
7GATT. The Proxy feature is only compiled in if the :kconfig:option:`CONFIG_BT_MESH_GATT_PROXY`
8option is set. The Proxy feature state is controlled by the :ref:`bluetooth_mesh_models_cfg_srv`,
9and the initial value can be set with :c:member:`bt_mesh_cfg_srv.gatt_proxy`.
10
11Nodes with the Proxy feature enabled can advertise with Network Identity and Node Identity,
12which is controlled by the :ref:`bluetooth_mesh_models_cfg_cli`.
13
14The GATT Proxy state indicates if the Proxy feature is supported.
15
16Private Proxy
17*************
18
19A node supporting the Proxy feature and the :ref:`bluetooth_mesh_models_priv_beacon_srv` model can
20advertise with Private Network Identity and Private Node Identity types, which is controlled by the
21:ref:`bluetooth_mesh_models_priv_beacon_cli`. By advertising with this set of identification types,
22the node allows the legacy device to connect to the network over GATT while maintaining the
23privacy of the network.
24
25The Private GATT Proxy state indicates whether the Private Proxy functionality is supported.
26
27Proxy Solicitation
28******************
29
30In the case where both GATT Proxy and Private GATT Proxy states are disabled on a node, a legacy
31device cannot connect to it. A node supporting the :ref:`bluetooth_mesh_od_srv` may however be
32solicited to advertise connectable advertising events without enabling the Private GATT Proxy state.
33To solicit the node, the legacy device can send a Solicitation PDU by calling the
34:func:`bt_mesh_proxy_solicit` function.  To enable this feature, the device must to be compiled with
35the :kconfig:option:`CONFIG_BT_MESH_PROXY_SOLICITATION` option set.
36
37Solicitation PDUs are non-mesh, non-connectable, undirected advertising messages containing Proxy
38Solicitation UUID, encrypted with the network key of the subnet that the legacy device wants to
39connect to. The PDU contains the source address of the legacy device and a sequence number. The
40sequence number is maintained by the legacy device and is incremented for every new Solicitation PDU
41sent.
42
43Each node supporting the Solicitation PDU reception holds its own Solicitation Replay Protection
44List (SRPL).  The SRPL protects the solicitation mechanism from replay attacks by storing
45solicitation sequence number (SSEQ) and solicitation source (SSRC) pairs of valid Solicitation PDUs
46processed by the node. The delay between updating the SRPL and storing the change to the persistent
47storage is defined by :kconfig:option:`CONFIG_BT_MESH_RPL_STORE_TIMEOUT`.
48
49The Solicitation PDU RPL Configuration models, :ref:`bluetooth_mesh_srpl_cli` and
50:ref:`bluetooth_mesh_srpl_srv`, provide the functionality of saving and clearing SRPL entries.  A
51node that supports the Solicitation PDU RPL Configuration Client model can clear a section of the
52SRPL on the target by calling the :func:`bt_mesh_sol_pdu_rpl_clear` function.  Communication between
53the Solicitation PDU RPL Configuration Client and Server is encrypted using the application key,
54therefore, the Solicitation PDU RPL Configuration Client can be instantiated on any device in the
55network.
56
57When the node receives the Solicitation PDU and successfully authenticates it, it will start
58advertising connectable advertisements with the Private Network Identity type. The duration of the
59advertisement can be configured by the On-Demand Private Proxy Client model.
60
61API reference
62*************
63
64.. doxygengroup:: bt_mesh_proxy
65