1.引用ZigBee聯盟的說法
Profile: a collection of device descriptions, which together form a cooperative
application. （配置文件：共同促成交互式應用的多種設備描述項的集合。）
ZigBee devices describe themselves using descriptor data structures. The actual data
contained in these descriptors is defined in the individual device descriptions.
There are five descriptors: node, node power, simple, complex and user.（ZigBee
設備以描述項數據結構刻畫自己，包含在這些描述項內部的具體數據定義在該設備描述項中。
有5種描述項：節點，節點電源，簡化，複雜和用戶。）
2.我們的觀點
Profile是對邏輯設備及其接口的描述集合，是面向某個應用類別的公約、準則。
Descriptor是爲分佈式應用提供的描述項，多種描述項共同組成描述集合Profile。它
根據應用必須處理的數據包和必須執行的操作來描述分佈式應用。
總之，配置文件使得ZigBee 設備可以互操作。ZigBee 聯盟已經定義了很多標準的配置
文件，比如遠程控制開關配置文件和光傳感器配置文件等。任何遵循某一標準配置文件的節
點都可以與其他實現相同配置文件的節點進行互操作。
【相關問答】
Guest：
我看協議上說一個溫度計節點和一個爐子節點構成一個profile啊！所以我覺得實現一定功
能的幾個節點的集合就是一個profile？
ZigBee會友：
幾個節點的集合和profile不是在一個層面上說的。profile是面向某個應用，解決一系列事
務的公約，是對邏輯設備及其接口關係的描述集合。任何遵循這一描述集合的節點之間都可
以交互工作（只要雙方可以通信）。例如：依據加熱應用的條例規定，一個節點上的溫度調
節器可以和另一個節點上的加熱爐交互工作。
Guest：
device description、device profile和profile有什麼區別啊？！
ZigBee會友：
description 是理論性描述集合profile中的具體事項，device profile是profile對具體
device的有關規定和描述項，目前profile中有5種描述項。
Guest：
那麼對於zigbee的通訊來說，就需要有兩個不同類型的endpoint來相互通訊？endpoint的類
型取決於Profile？
ZigBee會友：
Profile規定了接點的類型和接口關係，endpoint當然是取決於具體應用中開發人員自己的
配置，只不過要交互工作，必須遵循Profile的相關規定而已。
Guest：
profile是一個更大一點的概念，是不是有人所說的“應用框架”？也就是說在這個框架中
定義設備類型 設備之間的控制管理接口等等？
ZigBee會友：
嗯，只要明確其中的含義，當然也可以用你自己的說法，目前相關說法還有“側面”、“概
貌”等。
Guest：
endpoint根據cluster進行綁定，進而構成profile？一個網絡有多個profile，難道只需要
一個profile identifier？
ZigBee會友：
profile 是“公約”、“準則”、“法律條款”。profile identifier即profileID就是對
應條款的識別序號，就像：民法、刑法、野生動物保護法……
Guest：
這樣理解可以吧：profiles 理解爲聯合國憲章條款，cluster 是伊朗核問題，attribute
就是談判， cluster是在遵守profile的情況下制定的？
ZigBee會友：
profiles 是面向具體應用的公約準則，cluster 此應用涉及到的事務關係，attribute
就是某事務可以預料的各種情況。
Guest：
請問，在zdo、profile、af之間的各種關如何？我弄不明白啊？
ZigBee會友：
zdo是ZigBee設備對象，屬於特殊的Endpoint（特製自己）；profile面向某個應用的公約或
準則，包括5種描述項；AF是應用層偵。
Guest：
但是我看zdo中定義的功能在device profile中都定義啦，你們分析了microchip的協議了
吧？我覺得挺難理解的，各個層次間的文件定義覺得很難……
ZigBee會友：
profile是法律條款，zdo是邏輯工作實體（自己）；profile中的多種描述項是條例、是圖
紙，zdo是具體實現。
Guest：
我想問問，配置文件到底是什麼？協議中好像說是設備描述符和簇描述符和服務類型
（KVP或MSG）。難道profile是設備描述符和簇描述符和服務類型（KVP或MSG）的集合？
ZigBee會友：
Profile也可以翻譯成配置文件，實質上大家公認的在某個方面應用的公共準則（對邏
輯設備及其接口的描述集合）。
Guest：
那Profile是如何劃分的, 根據實際location 還是app的相關性分得？
ZigBee會友：
根據應用相關性。
cluster是不是指一個應用？事務是service 是嗎 ，比如 KVP service 類型, 是吧？
ZigBee會友：
cluster是“事務”，是特性的集合（或者說屬性的集合）；Attribute是“事務”的具
體情況，比如節點的開或關。
Guest：
啊, 好像明白一點，原來總是把它和 multicast 往一起混，就亂了。謝謝！
ZigBee會友：
總之profile是面向應用的公約或準則；具體包括多種事務關係；每種事務關係又分多
種情況。
ENDPOINT
很多資料將其翻譯爲“端點”，我們不如也這麼叫。不過問題的關鍵不是它如何稱呼，而是如何認識它。我們來研究這樣一個事實：outman在看我的帖子的同時他又使用QQ和別人聊天。假設他的電腦IP地址爲192.168.1.2。那麼當他的QQ好友向他發送了一句話的時候，這個信息裏面包含了目的IP地址，所以通過TCP/TP協議可以到達outman的電腦。但是問題隨之而來。當outman電腦上的操作系統接收到此條信息時，它將把這個信息交給瀏覽器（我們剛纔說了，他在看帖子，所以肯定開着瀏覽器）呢，還是交給QQ？操作系統通過怎麼樣的方法作出裁決呢？顯然，只通過IP地址是沒有辦法決定的，所以這條消息除了包含IP地址以外，還要告訴目的機，這條消息應該交由哪個應用程序來處理。於是端口（Port）的概念產生了。操作系統爲應用程序提供了很多端口，消息由IP地址到達操作系統，再由端口找到處理消息的應用程序。同樣的道理，在ZigBee的應用程序框架裏（結構圖請看《深入淺出Z-Stack 2006 OSAL多任務資源分配機制》）包含了最多240個應用程序對象，每個應用程序對象在OSAL中對應了一個任務，當網絡層接收到信息以後如何決定將此信息傳遞給哪個任務呢？ENDPOINT決定了傳遞方向，於是我們可以說ENDPOINT的作用與TCP/IP協議中的端口的作用是一樣的。
【綜述】
1.引用ZigBee聯盟的說法
Cluster: is a container for one or more attributes. (一個或更多屬性的集合)
Attribute: a data entity which represents a physical quantity or state.（反映物
理特性或狀態的一個數據實體）
2.我們的觀點
Cluster是邏輯設備之間的事務關係，Attribute則是某種事務關係的具體特例；也就是說
Cluster定性，Attribute定量。
【相關問答】
Guest：
請問，attribute這個詞怎麼理解？ 溫度 等等？
ZigBee會友：
在溫度這個cluster裏面，attribute就是具體的溫度值。“屬性”attribute是“事務”
cluster裏面分的具體情況，就像C語言的swich ，case 語句裏的用法。
Guest：
請問“事務”又是個什麼概念？是不是就是一個事件？我理解cluster是屬性的集合？
ZigBee會友：
cluster的確是屬性的集合，和一般提到的事件不一樣，在網絡理解爲事務關係更貼切，
Endpoint之間依據“事務關係”（cluster）通訊。
Guest：
一個endpoint對應一個application？比如一個switch對應“開關”這個application？
ZigBee會友：
你的這種提法不規範，一個endpoint是一個邏輯設備，可以包含多個Cluster，每個
Cluster包含不同的屬性（開、關是“燈控制” Cluster對應不同情況的attribute）。
Guest：
這樣理解可以吧：profiles 理解爲聯合國憲章條款，cluster 是伊朗核問題，attribute
就是談判， cluster是在遵守profile的情況下制定的？
ZigBee會友：
profiles 是面向具體應用的公約準則，cluster 此應用涉及到的事務關係，attribute
就是某事務可以預料的各種情況。
Guest：
問一個問題：規定240個endpoint是指一個node上還是整個cluster呢，也就是說一個
cluster最多允許有240個endpoint還是240*240個endpoint呢？
ZigBee會友：
協議中的說法指一個node。 endpoint、node、cluster是三個概念 ：node是物理設備，
endpoint是邏輯工作端，cluster是大家通訊的事務關係（屬性的集合）。另外，網絡拓撲
結構中提到的cluster是集羣樹，包括家長（parent）及其子女(child)。
Guest：
我想問問，配置文件到底是什麼？協議中好像說是設備描述符和簇描述符和服務類型
（KVP或MSG）。難道profile是設備描述符和簇描述符和服務類型（KVP或MSG）的集合？
ZigBee會友：
Profile也可以翻譯成配置文件，實質上大家公認的在某個方面應用的公共準則（對邏
輯設備及其接口的描述集合）。
Guest：
那Profile是如何劃分的, 根據實際location 還是app的相關性分得？
ZigBee會友：
根據應用相關性。
Guest：
cluster是不是指一個應用？事務是service 是嗎 ，比如 KVP service 類型, 是吧？
把它和 multicast 往一起混，就亂了。謝謝！
ZigBee會友：
總之profile是面向應用的公約或準則；具體包括多種事務關係；每種事務關係又分多
種情況。
Guest：
協議上的nwk_addr_req（） 標註是cluser ID0x00,後面還有如clusterID 0x01的，
clusterID不是應該是不固定嗎？！
ZigBee會友：
clusterID和cluster一一對應，不同的cluster當然用不同的clusterID 。
Guest：
哦！可能我對cluster的理解有問題！我覺得cluster就是在綁定時產生的，所以
clusterID應該是隨機的。爲什麼協議裏primitive也會有clusterID呢？！而且不同的
primitive有不同的 固定的clusterID呢？！
ZigBee會友：
primitive是一個廣泛意義上的名次，泛指行爲和操作，primitive和clusterID沒有必
然的對應關係。
Guest：
ClusterID＝0x21 Bind_req(SrcAddress,SrcenEp,clusterID,DstAddress,DstenEp )
那ClusterID＝0x21什麼意思！？
ZigBee會友：
就是約定好的某事務對應的事務號，雙方以此建立對應關係（邦定關係）。比如端設備
一的開關控制端設備三的燈，五個參數對應關係：（端設備一SrcAddress,開關SrcenEp,燈
控制clusterID, 端設備三DstAddress,燈DstenEp）。現在理解嗎？
Guest：
這我理解！那個cluserID＝0x21，我不清楚！爲什麼是固定的！
ZigBee會友：
cluserID＝0x21表示“燈控制”燈控制這個cluser
cluserID＝0x20表示“電流”這個cluser
Guest：
我對cluser的理解正確嗎！？就是在綁定的時候，產生的！？ 那難道每個primitive都
有一個clusterID？
ZigBee會友：
當然了每個邦定都圍繞着一個cluser ，邦定三個要素：source、cluser、dest
Guest：
我就是不明白，爲什麼把primitive跟cluster扯上關係？
ZigBee會友：
primitive就是“原語”，和cluster沒有必然的聯繫，就是某種行爲的說法，描述邏輯
設備之間的操作和行爲時偶然和某個cluster扯上關係，在描述設備內部工作實體之間的操
作和行爲時就沒有了。