從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源服務器提交。