从M2M管理平台端，我们向远程设备发送一个读取(read)操作，目的是(the intent to)从该设备上的固件资源读取值。（顺便说一下，如果我们想重启远程设备，我们会从管理平台向设备发送一个执行操作(execute)。）因此，在LWM2M逻辑操作层，我们可以读取M2M设备上的资源，向资源中写入(write)一个新值，在设备中创建(create)一个全新的对象实例，对某个资源执行(execute)一个操作并做其他真正有用的事情。
读取操作（其语义是读取某些资源（如固件版本或温度）的值）以及该资源的地址（其URI）然后映射到CoAP协议的GET方法。资源标识符是类似/{Object ID}/{Object Instance ID}/{resource ID}的路径名。
例如.“mega short”路径/3/0/3表示对象设备的对象ID为“3”，该对象只有一个实例（用“0”表示没有被克隆的M2M设备），资源“固件版本”的标识恰好为“3”（在其对象内）。
因此，在CoAP协议级别，GET method请求被发送到M2M设备，并且响应被从设备发送到M2M服务器：例如，响应代码2.05后跟一些内容（即资源“固件版本”的值，例如版本1.1.8）。
因此，实际上CoAP GET方法可以与httpget请求相媲美。CoAP GET方法作为可确认的请求（期望某种确认以确保可靠的传输）发送。在HTTP中，响应内容将作为HTTP 200 OK消息的一部分发送，而在CoAP中，它可以作为响应代码为2.05的确认消息的一部分发送。（响应内容有点像猪背向确认消息，其中后者是确认可确认请求的主要原因）。
因此，CoAP被用作类似于HTTP的传输协议
因此，设备资源上的LWM2M操作（如获取固件版本或重新启动设备）映射到REST样式的资源表示请求和响应，这些请求和响应作为CoAP消息的一部分提供。
如前所述，CoAP本身有两层：使用方法代码和响应代码的请求/响应层，在其下面是一个包含消息的消息层。所有关于消息、方法代码和响应代码的信息都放在任何有效负载之前的单个CoAP消息头中。URI和有效负载内容类型作为CoAP选项携带（选项类似于HTTP头字段）。然后全部通过UDP。
回顾一下LWM2M的level，我们会看到如下情况：
LWM2M客户端<--将逻辑操作读取到资源固件版本--LWM2M服务器
看看CoAP协议级别，我们会看到如下内容：
LWM2M服务器端CoAP客户端请求：
CON+GET coap://M2M设备的IPv4地址/3/0/3
CON代表可确认的消息。
LWM2M客户端CoAP服务器响应：
ACK，2.05内容，ct=文本/普通，有效载荷：“1.1.8”
ACK表示确认消息，ct表示内容类型。
到目前为止，您可能注意到了术语client和server的微妙用法。
在lwm2m层，区分客户端和服务器，
在coap层，客户端和服务端的角色是相对的，在不同的请求和响应中不断变化。
在管理应用层，LWM2M客户端位于M2M设备、终端或模块上，LWM2M服务器位于M2M管理平台的一侧。
在CoAP级别，您可以在M2M设备和M2M平台上找到CoAP客户机，对于CoAP源服务器也是如此。
在上面的“读取固件版本”示例中，M2M设备管理服务器将CoAP GET请求作为CoAP客户端提交，而M2M的终端设备 将GET请求的响应作为CoAP源服务器提交。