TWI482525B - 分散式應用平台系統及其傳輸訊息的服務品質控制方法 - Google Patents

分散式應用平台系統及其傳輸訊息的服務品質控制方法 Download PDF

Info

Publication number
TWI482525B
TWI482525B TW101122432A TW101122432A TWI482525B TW I482525 B TWI482525 B TW I482525B TW 101122432 A TW101122432 A TW 101122432A TW 101122432 A TW101122432 A TW 101122432A TW I482525 B TWI482525 B TW I482525B
Authority
TW
Taiwan
Prior art keywords
message
service quality
data connection
interface module
application
Prior art date
Application number
TW101122432A
Other languages
English (en)
Other versions
TW201338612A (zh
Inventor
Yung Shun Huang
Yuan Fa Lee
Original Assignee
Ind Tech Res Inst
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ind Tech Res Inst filed Critical Ind Tech Res Inst
Priority to TW101122432A priority Critical patent/TWI482525B/zh
Priority to US13/658,823 priority patent/US20130235795A1/en
Publication of TW201338612A publication Critical patent/TW201338612A/zh
Application granted granted Critical
Publication of TWI482525B publication Critical patent/TWI482525B/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/16Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18Negotiating wireless communication parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • AHUMAN NECESSITIES
    • A61MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61BDIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B5/00Measuring for diagnostic purposes; Identification of persons
    • A61B5/0002Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network
    • A61B5/0015Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network characterised by features of the telemetry system
    • A61B5/0022Monitoring a patient using a global network, e.g. telephone networks, internet
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/63ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/565Conversion or adaptation of application format or content
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08Protocols for interworking; Protocol conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Description

分散式應用平台系統及其傳輸訊息的服務品質控制方法
本揭露是有關於一種分散式應用平台系統及其傳輸訊息的服務品質控制方法。
康體佳健康聯盟(Continua Health Alliance)目前制定Continua應用程式主機設備(Application Hosting Device,AHD)與藍牙健康設備概廓個人健康裝置(Bluetooth Health Device Profile Personal Health Device,BT HDP PHD)之間的個人區域網路介面(Personal Area Network Interface,PAN IF)的短距離連接技術,以及與Zigbee醫療保健(Health Care,HC)的PHD之間的感測區域網路介面(Sensor-LAN IF)的較長距離連接技術。
然而,目前通過認證的Continua PHD絕大部分均使用BT HDP的通信協定標準,但由於其與傳統Continua AHD連接的距離太短,將來勢必影響應用範圍。假若Continua BT HDP PHD可以像Zigbee HC PHD一樣可以透過Zigbee網路與遠端的Continua AHD連接及傳送生理量測訊號,或許可以解決上述問題。
一般而言,使用不同的通信協定的網路設備之間是不能彼此進行通訊的,而克服此問題的常用手法是在這些使用不同的通信協定的網路設備之間設置閘道器,並透過閘道器來進行不同的通信協定間的封包的轉換。如何實現 Continua AHD經由具有較長傳輸距離的無線網路連接到位於遠端之多個BT HDP的通信協定標準的BT HDP PHD,將會是本領域未來須發展的方向。
根據本揭露的一實施例,本揭露提供一種分散式應用平台系統,包括應用主機、無線感測網路以及閘道器。應用主機包括個人健康管理軟體模組、第一應用程式介面模組與第一協定通訊模組。其中,第一應用程式介面模組包括個人網路應用程式介面的第一部份功能。閘道器連接於應用主機與至少一終端個人健康裝置。閘道器包括第二應用程式介面模組、第二協定通訊模組與第三協定通訊模組。另外,第二應用程式介面模組包括個人網路應用程式介面的第二部份功能。無線感測網路、第一與第二協定通訊模組皆支援第一通信協定,而第三協定通訊模組支援第二通信協定。此外,所述第一與第二應用程式介面模組合作達成個人網路應用程式介面的所有預設功能,且該所有預設功能為該第一部份功能與該第二部份功能之組合,且至少一終端個人健康裝置藉由閘道器連接至應用主機。該應用主機傳送訊息到該無線感測網路或該閘道器傳送訊息到該無線感測網路時經由設定該訊息的傳輸優先權等級及正面應答模式設定值的服務品質參數,來執行該訊息的傳送服務品質控制機制。
根據本揭露的另一實施例,本揭露提供一種傳輸訊息 的服務品質控制方法,適用於包括應用主機、無線感測網路與閘道器的分散式應用平台系統。所述傳輸訊息的服務品質控制方法包括下列步驟:應用主機經由無線感測網路以及閘道器,發送一訊息到至少一終端個人健康裝置,其中應用主機與閘道器皆支援第一通信協定,至少一終端個人健康裝置藉由閘道器連接至應用主機,且與閘道器皆支援第二通信協定;至少一終端個人健康裝置經由閘道器以及無線感測網路,發送另一訊息到應用主機;以及當應用主機傳送訊息到無線感測網路或該閘道器傳送一訊息到無線感測網路時,應用主機或閘道器經由設定該訊息的傳輸優先權等級及正面應答模式設定值的服務品質參數,來執行該訊息的傳送服務品質控制機制。
為讓本揭露之上述特徵能更明顯易懂,下文特舉實施例,並配合所附圖式作詳細說明如下。
現在將在下文參看繪示本揭露的部分而非全部實施例的隨附圖式更充分地描述本揭露的部分實施例。實際上,本揭露案的各種實施例可採用許多不同形式來體現,且不應被解釋為限於本揭露中闡明的實施例;相反地,此等實施例僅提供使得本揭露內容將滿足可適用的合法要求。全篇中同樣的參考數字代表同樣的元件。
現有技術轉送不同通訊協定的網路封包的閘道器沒有考量不同通訊協定具有不同的服務品質(Quality of Service,QoS)的控制機制,例如支援不同通訊協定的通訊網路可能對於命令訊息、警告/通知訊息或生理訊號傳送/回覆訊息有不同的傳送延遲(delay)或網路封包丟失率(packet loss rate)。因此,在不同的通訊協定之間進行轉換的現有技術的閘道器不適合用來傳送具有服務品質要求的生理量測訊號或命令/警告等訊息。
請參照圖1A,圖1A是根據本揭露之一實施例所繪示的一種分散式應用平台系統的功能方塊圖。此分散式應用平台系統100包括應用主機AHD、無線感測網路120以及閘道器GW。應用主機AHD可以負責此分散式應用平台系統100中的後端伺服系統的連接,且同時負責分散式應用平台系統100中的前端生理量測數據的蒐集。應用主機AHD包括個人健康管理軟體模組112、第一應用程式介面模組API1與第一協定通訊模組ST1。其中,個人健康管理軟體模組112可以具有ISO/IEEE 11073個人健康裝置(Personal Health Device,PHD)管理者(manager)端的應用概廓(Application Profile)通信協定的功能,第一應用程式介面模組API1包括一個人網路應用程式介面(personal area network interface)的部份功能。
閘道器GW包括第二應用程式介面模組API2、第二協定通訊模組ST2與第三協定通訊模組ST3。閘道器GW利用第二協定通訊模組ST2經由無線感測網路120連接於應用主機AHD,並經由第三協定通訊模組ST3連接到至少一終端個人健康裝置PHD。所述無線感測網路120、第 一協定通訊模組ST1與第二協定通訊模組ST2皆支援第一通信協定,而第三協定通訊模組ST3支援第二通信協定。第一通信協定例如為ZigBee/IEEE 802.15.4標準規範的無線通訊協定,但本揭露的可實施方式不限定於此。所述另一通訊協定可以為其他有線通訊或無線通訊協定。
設置於應用主機AHD的所述第一應用程式介面模組API1與設置於閘道器GW的第二應用程式介面模組API2合作達成原本個人網路應用程式介面的所有預設功能,所述個人網路應用程式介面的所有預設功能包含將個人健康管理軟體模組112直接置放於第三協定通訊模組ST3上層時,個人健康管理軟體模組112與第三協定通訊模組ST3間的所有預設界面功能,且所述至少一終端個人健康裝置PHD可以藉由閘道器GW連接至應用主機AHD。換言之,第一應用程式介面模組API1與第二應用程式介面模組API2是將原本不支援第一通信協定的Continua應用醫療裝置(AHD)主機上的個人網路應用程式介面分割,分別設置到應用主機AHD與閘道器GW,使得一或多個終端個人健康裝置PHD,可以經由閘道器GW,並進一步透過無線感測網路120,將終端個人健康裝置PHD的訊號、生理量測訊號、或命令/警告等訊息送到應用主機AHD。從另一角度來看,第一應用程式介面模組API1經由第一協定通訊模組ST1將個人健康管理軟體模組112的至少一界面訊息傳送到無線感測網路120時,以及第二應用程式介面模組API2經由第二協定通訊模組ST2將第三協定通訊模組 ST3的至少一界面訊息傳送到無線感測網路120時,具有傳送服務品質控制機制。舉例說明,所述傳送服務品質控制機制是以<傳輸優先權等級、正面應答模式>的服務品質屬性作為基礎。
在本揭露的可實施方式中,應用主機AHD可以是例如個人電腦、工作站、主機電腦,或其他型式的電子裝置或處理器,但本揭露的可實施方式不限定於此。在本揭露的可實施方式中,應用主機AHD可以是放置在醫院、病房、住家、療養院、診所等場所,並且是可以用於管理一個或多個終端個人健康裝置的資訊的伺服器。終端個人健康裝置PHD可以是血糖計、血壓計、血脂計、血氧濃度計、心電圖生理訊號量測裝置、電子體溫計等電子醫療裝置,但本揭露的可實施方式可不限定於此。
閘道器GW可以是例如手機、平板電腦、個人數位助理(Personal Digital Assistant,PDA)、筆記型電腦、智慧型行動電話、手持智慧型裝置等行動式電子裝置,也可以是個人電腦、工作站或是其他型式的固定式電子裝置,但本揭露的可實施方式可不限定於此。
閘道器GW與至少一終端個人健康裝置PHD連接的所述另一通訊介面支援第二通信協定。上述第二通信協定可以是例如藍牙健康設備概廓(Bluetooth Health Device Profile,BT HDP)通信協定的無線連線方式或是通用串列匯流排個人健康設備類別(Universal Serial Bus Personal Healthcare Device Class,USB PHDC),但本揭露的可實施 方式可不限定於此。
在本揭露的一實施例中,應用主機AHD可以利用第一協定通訊模組ST1,經由無線感測網路120與閘道器GW中的第二協定通訊模組ST2進行通信。再者,第一應用程式介面模組API1可以用來接收在通信協定堆疊中,位於第一應用程式介面模組API1之上層的個人健康管理軟體模組112所產生的第一訊息,並將第一訊息轉換為支援第一通信協定的一第二訊息。另外,第一應用程式介面模組API1經由第一協定通訊模組ST1以及無線感測網路120發送第二訊息至第二協定通訊模組ST2。此外,第一協定通訊模組ST1在一通信協定堆疊中位於第一應用程式介面模組API1的下層。
位於第一應用程式介面模組API1之上層的個人健康管理軟體模組112包括例如:IEEE 11073 PHD協定堆疊(stack),以及在IEEE 11073 PHD協定堆疊之上的Continua AHD應用程式。第一協定通訊模組ST1在所述通信協定堆疊中是位於第一應用程式介面模組API1的下層。第一協定通訊模組ST1可以包括例如IEEE 802.15.4實體層(PHY)、在IEEE 802.15.4實體層之上的IEEE 802.15.4媒體存取層(MAC),以及在IEEE 802.15.4媒體存取層之上的ZigBee通信協定堆疊。
相類似地,閘道器GW可以包括第二應用程式介面模組API2、第二協定通訊模組及第三協定通訊模組。第二協定通訊模組ST2可以包括例如IEEE 802.15.4實體層 (PHY)、在IEEE 802.15.4實體層之上的IEEE 802.15.4媒體存取層(MAC),以及在IEEE 802.15.4媒體存取層之上的ZigBee通信協定堆疊。閘道器GW利用第二協定通訊模組ST2,經由無線感測網路120與應用主機AHD的第一協定通訊模組ST1進行通信。再者,第二應用程式介面模組API2用來接收在相同裝置的一通信協定堆疊中位於第二應用程式介面模組API2之下層的第二協定通訊模組ST2傳遞的第二訊息,並轉換第二訊息為支援第二通信協定的第三訊息。另外,第二應用程式介面模組API2經由在一通信協定堆疊中位於第二應用程式介面模組API2之下層的第三協定通訊模組ST3,發送第三訊息到一或多個終端個人健康裝置(例如,圖1A中的終端個人健康裝置PHD)。
在本揭露之一實施例中,閘道器GW可以利用第二協定通訊模組ST2與應用主機AHD中的第一協定通訊模組ST1進行通信。另一方面,閘道器GW利用第三協定通訊模組ST3接收多個終端個人健康裝置的其中之一(例如,終端個人健康裝置PHD)發送的一第四訊息,終端個人健康裝置PHD可以支援第二通信協定,因此第四訊息支援第二通信協定。再者,閘道器GW的第二應用程式介面模組API2將第四訊息轉換為支援第一通信協定的第五訊息,並經由第二協定通訊模組ST2以及無線感測網路120發送第五訊息到第一協定通訊模組ST1。然後,應用主機AHD的第一應用程式介面API1模組經由第一協定通訊模組ST1接收第五訊息。第一應用程式介面模組API1將第一 協定通訊模組ST1從無線感測網路120接收的第五訊息轉換為第六訊息。另外,第一應用程式介面模組API1傳遞第六訊息至個人健康管理軟體模組112,由個人健康管理軟體模組112進行後續的訊息處理動作。
在其他實施例中,應用主機AHD中的個人健康管理軟體模組112所支援的訊息格式可以是與終端個人健康裝置PHD所支援的應用概廓層(Application Profile)的之訊息格式相同。因此,當應用主機AHD中的個人健康管理軟體模組112想要與終端個人健康裝置PHD進行通信時,第一應用程式介面模組API1必須先將由個人健康管理軟體模組112所傳遞的第一訊息,轉換成可以由第一協定通訊模組ST1傳送的第一通信協定格式的第二訊息,然後才能將已轉換格式的第二訊息由第一協定通訊模組ST1傳送至閘道器GW中的第二協定通訊模組ST2,並由第二協定通訊模組第二應用程式介面模組API2進行後續處理,將第二訊息轉換為可以由第三協定通訊模組ST3傳送的第二通信協定格式的第三訊息,經由第三協定通訊模組ST3與終端個人健康裝置PHD之間的通訊介面,發送第三訊息至終端個人健康裝置PHD。
反之,當第一協定通訊模組ST1由無線感測網路120接收到具有第一通信協定格式的第五訊息時,第一應用程式介面模組API1會將此第五訊息轉換為個人健康管理軟體模組112支援的訊息格式,並將已轉換訊息格式的第六訊息向上傳送至個人健康管理軟體模組112,以進行後續 處理。
圖1B是根據本揭露之一實施例所繪示的分散式應用平台系統的協定堆疊的示意圖。圖1B的左側為原始應用主機AHD通訊協定堆疊10,個人健康管理軟體模組112提供個人健康管理軟體模組應用程式介面113給下層第三協定通訊模組ST3使用,亦即第三協定通訊模組ST3可透過個人健康管理軟體模組應用程式介面113傳送訊息給個人健康管理軟體模組112。第三協定通訊模組ST3提供第三協定通訊模組應用程式介面114給上層個人健康管理軟體模組112使用,亦即個人健康管理軟體模組112可透過第三協定通訊模組應用程式介面114傳送訊息給第三協定通訊模組ST3,個人健康管理軟體模組應用程式介面及第三協定通訊模組應用程式介面組合成為個人網路應用程式介面。圖1B的右側為由原始應用主機AHD變更而形成的分散式應用平台系統。在右側的分散式應用平台系統中,應用主機AHD可以包括應用主機AHD通訊協定堆疊11,且閘道器GW包括閘道器GW通訊協定堆疊12。應用主機AHD的第一應用程式介面模組API1包括個人網路應用程式介面的第一部份功能,具備虛擬第三協定通訊模組應用程式介面116,可以提供與第三協定通訊模組應用程式介面114相同之應用程式介面給上層個人健康管理軟體模組112使用;閘道器GW的第二應用程式介面模組API2包括個人網路應用程式介面的第二部份功能,具備虛擬個人健康管理軟體模組應用程式介面118,可以提供與個人健康 管理軟體模組應用程式介面113相同之應用程式介面給第三協定通訊模組ST3使用。另外,第一應用程式介面模組API1與第二應用程式介面模組API2合作達成個人網路應用程式介面的所有預設功能,且個人網路應用程式介面的所有預設功能為前述第一部份功能與前述第二部份功能的組合。前述第一部份功能表示第一應用程式介面模組API1提供給個人健康管理軟體模組112使用之虛擬第三協定通訊模組應用程式介面116,其效果與第三協定通訊模組應用程式介面114相同。前述第二部份功能表示第二應用程式介面模組API2提供給第三協定通訊模組ST3使用之虛擬個人健康管理軟體應用程式介面118,其效果與個人健康管理軟體模組應用程式介面113相同。也就是說,透過虛擬第三協定通訊模組應用程式介面116以及虛擬個人健康管理軟體應用程式介面118之設計,使得一或多個終端個人健康裝置可以經由閘道器GW或者透過無線感測網路120,將終端個人健康裝置的訊號、生理量測訊號、或命令/警告等訊息送到應用主機AHD。另一方面,第一應用程式介面模組API1與第二應用程式介面模組API2在分別透過第一、第二協定通訊模組ST1、ST2傳送訊息到無線感測網路120時,具有傳送服務品質控制之功能。
請參照圖2,圖2是根據本揭露之一實施例所繪示的訊息200的訊息欄位示意圖。在本實施例中,訊息200可以是第一通信協定所支援的網路封包承載(payload)的格式。訊息200可以包括服務品質屬性欄位210以及訊息資 料欄位220,服務品質屬性欄位包含時間延遲屬性及可靠度屬性,<可靠度、延遲>服務品質屬性欄位可由解析訊息內容而得到,同時依據表二<可靠度、延遲>服務品質屬性可以對應到<傳輸優先權等級、傳輸模式、正面應答模式>服務品質參數,但本揭露的可實施方式不限定於此。此外,服務品質屬性欄位210可以用來標明訊息200的服務品質屬性,而訊息資料欄位220則可以用來存放訊息200的訊息內容。訊息200對應的傳輸優先權等級代表與其他訊息相較之下該訊息被傳送的一優先次序,且該正面應答模式設定值指示接收該訊息的一通訊裝置是否需要回傳一正面應答封包。
在第一應用程式介面模組API1將第一訊息轉換為第二訊息的過程中,第一應用程式介面模組API1會根據(表二)第二欄位(連線訊息種類欄)的訊息分類,依該第二訊息的內容來判斷訊息種類,決定將第二訊息傳送到無線感測網路120的<可靠度、延遲>服務品質屬性,以及該<可靠度、延遲>服務品質屬性對應的<傳輸優先權等級、競爭/非競爭傳輸模式、正面應答模式>服務品質參數,並依據這些服務品質參數單獨或配合第一協定通訊模組ST1的服務品質控制功能來執行所述傳送服務品質控制機制。應用主機AHD依照服務品質參數來控制訊息傳遞的功能可以由第一應用程式介面模組API1及第一協定通訊模組ST1合作完成。
所述第一通信協定的傳輸模式包括一競爭模式與一 保證時槽模式。當第一應用程式介面模組API1設置發送第二訊息時採用競爭模式時,第一應用程式介面模組更根據所述的可靠度服務品質屬性判斷是否採用該正面應答模式。
第二應用程式介面模組API2會根據(表二)第二欄位(連線訊息種類欄)的訊息分類,依該訊息的內容來判斷訊息種類,並決定將第五訊息傳送到無線感測網路120的<可靠度、延遲>服務品質屬性,以及該<可靠度、延遲>服務品質屬性對應的<傳輸優先權等級、競爭/非競爭傳輸模式、正面應答模式>服務品質參數,並依據這些服務品質參數單獨或配合第二協定通訊模組ST2的服務品質功能來執行所述傳送服務品質控制機制。閘道器GW依照服務品質參數來控制訊息傳遞之功能可以由第二應用程式介面模組API2及第二協定通訊模組ST2合作完成。
當第二應用程式介面模組API2設置發送第五訊息時採用競爭模式時,第二應用程式介面模組API2更根據所述的可靠度服務品質屬性判斷是否採用正面應答模式。
在一實施例中,可以由第一應用程式介面模組API1同時進行在第一通信協定與第二通信協定之間轉換的封包切割與重組。然而,本揭露可實施方式不限定於上述,在另一實施例中,可以由第二應用程式介面模組API2同時進行在第一通信協定與第二通信協定之間轉換的封包切割與重組。
當第一應用程式介面模組API1接收到個人健康管理 軟體模組傳來的第一訊息時,第一應用程式介面模組API1將會判斷該訊息之服務品質屬性,並根據此服務品質屬性來轉換第一訊息為訊息200格式的第二訊息乘載,依據服務品質屬性選擇設置發送第二訊息時所採用的傳輸優先權等級、是否需要正向回覆以及第一通信協定的傳輸模式等服務品質參數,並執行服務品質控制機制經由第一協定通訊模組ST1發送第二訊息至無線感測網路120。第二應用程式介面模組API2藉由第二協定通訊模組ST2接收到第二訊息後,可依據訊息200格式第二訊息乘載的服務品質屬性來決定後續處理之優先順序。若第一協定通訊模組ST1無提供服務品質控制的功能,則第一應用程式介面模組API1可獨立完成服務品質控制功能。若第一協定通訊模組ST1有提供服務品質控制的功能,則第一應用程式介面模組API1可以將部分或全部的服務品質控制功能利用第一協定通訊模組ST1的功能來完成。
相類似地,當第二應用程式介面模組API2接收到第三協定通訊模組傳來的第四訊息時,第二應用程式介面模組API2將會判斷該訊息的服務品質屬性,根據此服務品質屬性來轉換第五訊息為訊息200格式格式的第五訊息乘載,再根據此服務品質屬性來選擇設置發送第五訊息時所採用的傳輸優先權等級、是否需要正向回覆以及第一通信協定的傳輸模式等服務品質參數,最後將訊息200作為第五訊息的乘載,並執行服務品質控制機制經由第二協定通訊模組ST2發送第五訊息至無線感測網路120。第一應用 程式介面模組API1藉由第一協定通訊模組ST1接收到第五訊息後,可以訊息200格式第五訊息乘載的服務品質屬性來決定後續處理的優先順序。若第二協定通訊模組ST2無提供服務品質控制的功能,則第二應用程式介面模組API2可獨立完成服務品質控制功能。若第二協定通訊模組ST2有提供服務品質控制的功能,則第二應用程式介面模組API2可以將部分或全部的服務品質控制功能利用第二協定通訊模組ST2的功能來完成。
訊息200可以由閘道器GW用來遞送由終端個人健康裝置PHD所產生的訊息到應用主機AHD,所述終端個人健康裝置PHD產生的訊息例如為:量測報告訊息、量測歷史紀錄訊息、生理警報訊息、裝置警報訊息、量測參數(例如血壓、血脂、血糖、血氧濃度、心跳率、體溫等)訊息、事件訊息(event report)、通知訊息(notification)、要求訊息(request)、回應訊息(response)、裝置控制回應訊息(status)及可視波形(例如心電圖)訊息等。
舉例說明,當閘道器GW發送至應用主機AHD的訊息200是終端個人健康裝置PHD所產生的量測數據訊息(例如,血壓、血糖及血脂等量測參數訊息)時,對於此量測數據訊息的接收者而言,接收者對此量測數據訊息所能忍受的延遲程度一般而言是較高的。也就是說,所述量測數據訊息可以不須即時地傳送至接收者端,所以其傳輸優先權等級可以設定為相對較低的等級。此量測數據訊息的正確性(可靠度)的要求則必須是較高的。例如,當終端個 人健康裝置PHD是電子體溫計時,若使用者的實際體溫(例如攝氏38.5度)與此電子體溫計所收集到的使用者體溫的量測數據訊息(例如攝氏37.5度)出現誤差,此量測報告訊息所呈現的資訊則有可能是錯誤的(例如是否出現發燒現象),並可能導致醫護人員在生理狀態診斷上的誤判。因此,對於量測數據訊息所選擇的第一通信協定的訊息傳輸方式可以是高可靠度且高延遲的,但此處僅是舉例說明,其訊息傳輸方式的設定仍可以根據不同的實施方式或訊息200的服務品質屬性,作相對應的調整。
在本揭露之一實施例中,第一通信協定的傳輸模式可以包括競爭(contention)模式與保證時槽模式(guranteed time slot)。保證時槽模式在ZigBee通信協定中又可稱為非競爭期間(contention free period)。
應用主機AHD的第一應用程式介面模組API1發送第二訊息時採用的服務品質參數是根據其所設定的傳輸優先權等級來競爭存取無線感測網路的權利。相類似地,閘道器GW之第二應用程式介面模組API2發送第五訊息時採用的服務品質參數是根據其所設定的傳輸優先權等級來競爭存取無線感測網路的權利。所述具有不同傳輸優先權等級的訊息可以在應用主機AHD上的第一應用程式介面模組API1以不同的緩衝器(buffer)來分別進行儲存,而在每個緩衝器中所儲存的多個訊息的傳輸優先權等級是相同的。同樣地,在閘道器GW上的第二應用程式介面模組API2也可以用不同的緩衝器來儲存具有不同傳輸優先權 等級的訊息。
舉例而言,假設在應用主機AHD上的第一應用程式介面模組API1(或閘道器GW上的第二應用程式介面模組API2)具有三個緩衝器A、B及C,其可以分別用來儲存一個或多個傳輸優先權等級a、b及c的訊息,而其傳輸優先權的等級可以是:傳輸優先權等級a高於傳輸優先權等級b且傳輸優先權等級b高於傳輸優先權等級c。舉例而言,所有被設定為傳輸優先權等級a的訊息都會被存放在緩衝器A中,而所有被設定為傳輸優先權等級b的訊息都會被存放在緩衝器B中,存放在緩衝器C中的訊息則皆為傳輸優先權等級c的訊息。
所以,若緩衝器A、B及C之其中兩個以上的緩衝器(例如緩衝器A及C)同時出現傳送訊息的要求,則其中具有較高傳輸優先權等級(例如傳輸優先權等級a)的訊息將優先地被傳送,而具有較低傳輸優先權等級(例如傳輸優先權等級c)的訊息將在之後再次地競爭存取無線感測網路120的權利。也就是說,具有較低傳輸優先權等級(例如傳輸優先權等級c)的訊息必須等到具有較高傳輸優先權等級(例如傳輸優先權等級a)的訊息全部傳送完畢時,才有可能競爭到存取無線感測網路120的權利。
另外,當應用主機AHD中的第一應用程式介面模組API1設置發送第二訊息時,第一應用程式介面模組API1可以根據所述訊息的服務品質屬性中的可靠度屬性判斷是否採用正面應答模式。相類似地,當閘道器GW中的第二 應用程式介面模組API2設置發送第五訊息時採用競爭模式時,第二應用程式介面模組API2也可以根據所述訊息的服務品質屬性中的可靠度屬性判斷是否採用正面應答模式。
舉例而言,若正面應答模式在競爭模式中被採用,則當第一應用程式介面模組API1成功地將訊息傳送至閘道器GW中的第二應用程式介面模組API2時,閘道器GW可以回傳正面應答訊息至應用主機AHD,用以告知應用主機AHD所述訊息已成功地被接收。所以,當應用主機AHD沒有接收到閘道器GW所回傳的正面應答訊息時,此代表上述訊息並沒有成功地傳送至閘道器GW,則第一應用程式介面模組API1可以在預設時間內,重新傳送所述訊息。另一方面,當正面應答模式在競爭模式中沒有被採用時,則無論所述訊息是否成功地被閘道器GW所接收,閘道器GW都不會回傳正面應答訊息至應用主機AHD。
相類似地,若閘道器GW所傳送的訊息被設定為採用正面應答模式時,則閘道器GW同樣可以經由是否接收到由應用主機AHD所回傳的正面應答訊息來判斷所傳送的訊息是否成功地被應用主機AHD所接收。
而第二應用程式介面模組API2可以用來接收在通信協定堆疊中位於第二應用程式介面模組API2之下層的第二協定通訊模組ST2傳遞的第二訊息,並經由第二協定通訊模組ST2發送第五訊息至第一協定通訊模組ST1。所述第五訊息的內容可以包含量測報告訊息、量測歷史紀錄訊 息、生理警報訊息、裝置警報訊息、量測參數(例如血壓、血脂、血糖、血氧濃度、心跳率、體溫等)訊息、事件訊息、通知訊息、要求訊息、回應訊息、裝置控制回應訊息及可視波形(例如心電圖)訊息等,但本揭露可實施方式不限於此。
第一應用程式介面模組API1以及第二應用程式介面模組API2可以分別用來將第一通信協定以及第二通信協定的網路封包進行相對應的轉換。然而,由於上述第一通信協定與第二通信協定的所支援的網路封包的有效承載(effective payload)可能是不同的,此時則必須對需進行轉換的網路封包進行切割(segmentation)或是重組(re-assembly)的動作,使得轉換後的網路封包可以符合其通信協定所支援的有效承載。若是第一通信協定有提供網路封包切割重組的功能,則第一應用程式介面模組API1可以使用第一通信協定來達成網路封包切割重組的處理。若是第二通信協定有提供網路封包切割重組的功能,則第二應用程式介面模組API2可以使用第二通信協定來達成網路封包切割重組的處理。
請參照圖3,圖3是根據本揭露之一實施例所繪示的網路封包切割的示意圖。在本實施例中,網路封包乘載M00可以是訊息200的網路封包乘載格式,假設第一應用程式介面模組API1或第二應用程式介面模組API2需要經由第一協定通訊模組ST1或第二協定通訊模組ST2傳送之訊息200網路封包乘載的長度大於第一通信協定所支援的 應用程式層的網路封包有效承載的長度(例如,96位元組),則當第一應用程式介面模組API1或第二應用程式介面模組API2在將訊息200網路封包乘載轉換成第一通信協定所支援的網路封包乘載時,必需將訊息200網路封包乘載進行切割,以符合第一通信協定所支援的網路封包的有效承載量。如圖3中所繪示,網路封包乘載M00的長度假設為值256個位元組,第一通信協定為Zigbee通信協定標準,其支援的應用程式層有效承載為96個位元組。
當第一應用程式介面模組API1以及第二應用程式介面模組API2在將網路封包乘載M00轉換成第一通信協定所支援的網路封包乘載時,可以將此網路封包乘載M00切割成三個子封包乘載X、Y及Z,並附加上有關於網路封包重組的資訊,使得經過切割產生的網路封包乘載在接收端重組時能正確無誤地被重組,以還原到原本的資料內容。以下將利用一簡化例子進行說明。
請再次參照圖3,假設訊息200網路封包乘載的長度為256位元組,子封包乘載X、Y及Z在分別附加例如為訊息編號欄位、切割數量欄位、切割編號欄位及切割長度欄位等相關於網路封包的切割與重組的訊息之後,可以分別組成第一通信協定所支援的網路封包乘載M01、M02及M03。上述網路封包乘載M01、M02及M03中的訊息編號欄位、切割數量欄位、切割編號欄位及切割長度欄位的內容值可以用以下表1中所設定的方式來呈現,而這四個欄位的大小皆假設為1個位元組,再加上子封包乘載的長度 (最大為96個位元組),即可組成第一通信協定所支援的網路封包乘載長度(最大為1×4+92=96個位元)。在其他實施例中,這些欄位的長度以及內容值的設定方式還可以利用不同的方式來呈現,也可以更附加其他的欄位資訊來更明確地紀錄網路封包乘載切割與重組的資訊。
請同時參照圖3與表1,假設第一應用程式介面模組API1或第二應用程式介面模組API2設置網路封包乘載M00的編號是15,則表1中的網路封包乘載M01、M02及M03中的訊息編號欄位的內容值則皆設定為15,用來標示網路封包乘載M01、M02及M03中的子封包乘載X、Y及Z是由編號為15的網路封包乘載M00所切割而成。 表1中的切割數量欄位可以是根據網路封包乘載M00被切割的等份來設定,而在本例中,由於網路封包乘載M00是假設為切割成3個子封包乘載X、Y及Z,所以網路封包乘載M01、M02及M03中的切割數量欄位的內容值可以相對應地設定為3(亦即被切割成3等份)。表1中的切割編號欄位則可以是根據網路封包乘載M01、M02及M03中的子封包乘載X、Y及Z在網路封包乘載M00中的順序(例如在網路封包乘載M00中的從網路封包乘載開端到網路封包乘載結尾的順序)來設定,並可以用來標明子封包乘載X、Y及Z應該以何種順序來重組為網路封包乘載M00。表1中的切割長度欄位的內容值則可以根據網路封包乘載乘載M01、M02及M03中的子封包乘載X、Y及Z的封包長度來設定,其值分別為92、92、72。
在本揭露的一實施例中,第一應用程式介面模組API1進行將第二訊息傳送到無線感測網路的封包切割及由無線感測網路接收第五訊息的重組功能。第二應用程式介面模組API2進行將第五訊息傳送到無線感測網路的封包切割及由無線感測網路接收第二訊息的重組功能。若第一通訊協定模組ST1及第二通訊協定模組ST2有提供封包切割重組功能,則第一應用程式介面模組API1及第二應用程式介面模組API2則不用提供封包切割重組功能,而可直接使用第一通訊協定模組ST1及第二通訊協定模組ST2的封包切割重組功能。
請參照圖4,圖4是根據本揭露之一實施例所繪示的 封包重組的示意圖。假設網路封包乘載M01、M02及M03中的訊息編號欄位、切割數量欄位、切割編號欄位及切割長度欄位的內容值分別是根據表1中的內容來設定,則第一應用程式介面模組API1或是第二應用程式介面模組API2在接收到網路封包乘載M01、M02及M03之後即可以根據表1中關於網路封包乘載M01、M02及M03的各欄位分別所提供的內容值來將網路封包乘載M01、M02及M03中的子封包乘載X、Y及Z進行擷取而重組成封包乘載M00。
請參照圖5,圖5是根據本揭露之一實施例所繪示的分散式應用平台系統的功能方塊圖。如圖5中所繪示,在分散式應用平台系統500中,閘道器GW可以經由有線通訊介面或無線通訊介面同時與多個終端個人健康裝置PHD1~PHDK連接,其中K為大於1的正整數。所述有線通訊介面例如為USB PHDC介面,而無線通訊介面例如為BT HDP無線通訊介面。
假設應用主機AHD(例如可統一管理終端個人健康裝置PHD1~PHDK的資訊的伺服器)是放置於例如醫療建築的客廳內,終端個人健康裝置PHD1~PHDK(例如血壓計、血糖計等)假設是放置於醫療建築的其他房間內,而閘道器GW例如放置於醫療建築的其他房間內、客廳內及走道上。此外,應用主機AHD與終端個人健康裝置PHD1~PHDK設置的樓層可以不同於所述客廳的樓層。
當第一通信協定是Zigbee/802.15.4通信協定標準,而 第二通信協定是藍牙健康設備概廓通信協定標準時,則位於住家中,僅支援藍牙通信協定標準的終端個人健康裝置PHD1~PHDK想要與位於遠距離處(小於等於Zigbee通信協定標準的傳輸距離,但大於藍牙通信協定標準的傳輸距離)的醫院的應用主機AHD進行通信時,終端個人健康裝置PHD1~PHDK可以先透過藍牙通信協定標準與閘道器GW進行通信,再經由閘道器GW以Zigbee通信協定標準與遠距離處的應用主機AHD進行通信。如此一來,終端個人健康裝置PHD1~PHDK即可以透過閘道器GW所支援的Zigbee/802.15.4通信協定標準而獲得較長的傳輸距離。也就是說,透過閘道器GW的轉換,僅支援藍牙通信協定標準的終端個人健康裝置PHD1~PHDK可以經由閘道器GW所支援的Zigbee/802.15.4通信協定標準的網路來將訊息發送至遠距離的應用主機AHD。反之,應用主機AHD也可以經由支援的Zigbee/802.15.4通信協定標準的無線感測網路以及閘道器GW,發送裝置設定指令(set)訊息、裝置取得指令(get)訊息、要求訊息、回應訊息或裝置控制功能(control action)訊息到僅支援藍牙通信協定標準的終端個人健康裝置PHD1~PHDK。
表2的第一欄位及第二欄位是康體佳指引(Continua Guideline)制定出的6種服務品質屬性(QoS bin)及訊息種類的對應表,表2中的訊息種類因Continua Guideline對<佳、低>服務品質屬性的訊息種類尚未定義,因此只包含5種訊息種類。在本實施例中,表2的第三欄位是與第一欄位相對應的傳輸優先權等級、傳輸模式以及正面應答模式等服務品質參數設計值。應用主機AHD的第一應用程式介面模組API1、閘道器GW的第二應用程式介面模組API2可透過第三協定通訊模組ST3的非資料連線及資料連線與個人健康設備PHD1~PHDK間傳遞訊息。第三協定通訊模組ST3為傳輸層通訊模組,因此其非資料連線傳遞的訊息為傳輸層(Transport Layer)之命令相關訊息(例如BT HDP及USB PHDC之命令相關訊息),該訊息的服務品質屬性可設定為默認設定值(defualt value),並歸類為<最佳、中等>服務品質屬性的訊息種類。第三協定通訊模組的資料連線傳遞的訊息為個人健康管理模組相關訊息,其訊息內容包含資料連線識別碼及應用概廓(Application Profile)層訊息乘載(例如IEEE 11073 PHD訊息乘載),由解析資料連線識別碼及資料連線訊息乘載可再將該訊息區分為表2的五種訊息種類。當第二訊息或第五訊息被判斷為非資料連線訊息時,其服務品質控制參數可以默認設定值來設定,當第二訊息或第五訊息被判斷為資料連線訊息時,則可由解析資料連線識別碼及資料連線訊息乘載並配合採用服務品質映射表(QoS mapping table)方法來設定其服務品質控 制參數。在本實施例中,訊息的可靠度可以分為三種(最佳(best)、較佳(better)及佳(good)),而延遲則可以分為四種(非常高(very high)、高(high)、中等(medium)及低(low))。
雖然上述三種可靠度(reliability)及四種延遲(latency)可以組合出12種服務品質屬性,但根據康體佳指引(Continua Guideline)之內容僅有6種服務品質被採用,其<可靠度.延遲>屬性對分別可以是<最佳.非常高>、<最佳.高>、<最佳.中等>、<較佳.中等>、<佳.中等>以及<佳.低>等六種。
表二中<可靠度.延遲>服務品質屬性與<傳輸優先權等級.傳輸模式.正面應答模式>服務品質控制參數的對應關係如表二的第一欄位與第三欄位所示。延遲服務品質屬性主要是對應到傳輸優先權等級參數,可靠度則是對應到傳輸模式及正面應答模式參數,因大部分的無線感測網路不支援非競爭模式,所以表二中只選用競爭模式,並將可靠度為最佳的服務品質屬性對應到非競爭模式及採用正面應答模式。表二中傳送血壓/血糖/血氧等量測參數的服務品質屬性為<較佳.中等>,但因實務上不希望血壓/血糖/血氧等量測數據有傳輸遺失,因此實質提升其可靠度為最佳,將其服務品質控制參數設定為採用正面應答模式。
對於此六種服務品質屬性的訊息,在本實施例中,對應到<傳輸優先權等級/傳輸模式/採用ACK>之六種服務品質參數設定可以分別設置為<低/競爭模式/採用ACK>、<中/競爭模式/採用ACK>、<高/競爭模式/採用ACK>、<高 /競爭模式/採用ACK>、<非常高/競爭模式/不採用ACK>、<最高/競爭模式/不採用ACK>。設定的傳輸優先權等級由低至高可以有五種,例如分別為低(low)、中(medium)、高(high)、非常高(very high)及最高(highest)。這五種傳輸優先權等級的訊息可以在應用主機AHD的第一應用程式介面模組API1(或閘道器GW之第二應用程式介面模組API2)上分別以五個不同的緩衝器來儲存,而這些緩衝器在競爭模式中傳送資料的優先順序由高至低分別為最高、非常高、高、中、低。各種不同的連線訊息種類可以根據其可靠度及延遲的要求而進行相對應的服務品質屬性歸類。
要傳送到無線感測網路的第二訊息及第五訊息,可先區分為非資料連線訊息或資料連線訊息,非資料連線訊息為傳輸層(例如BT HDP層)命令相關訊息,可設定此類訊息為默認預設訊息種類,其服務品質屬性為<最佳.中等>,在非資料連線訊息中,可以得知所有資料連線的資訊(含資料連線識別碼、建立/致能/除能/中斷等狀態及服務品質屬性等),並利用此資訊將已建立的資料連線資訊記錄到服務品質映射表(QoS mapping table)。資料連線訊息為應用概廓層(例如IEEE 11073 PHD層)訊息,資料連線訊息內容包含資料連線識別碼及應用概廓層資料乘載等,又可再區分為如表2的各種服務品質屬性。
假若第二通信協定是USB PHDC通信協定,此即終端個人健康裝置PHD與第三協定通訊模組ST3之間的通訊介面為支援USB PHDC通信協定。第一應用程式介面模 組API1可由第一訊息、第二訊息及第五訊息的訊息內容觀察到USB管路(pipe)相關的資訊,並藉以判斷是否有新的資料連線(USB pipe連線)被建立,並在服務品質映射表(QoS mapping table)中建立相對應的pipe連線服務品質紀錄。USB PHDC定義的6種pipe連線的服務品質屬性直接對應到康體佳指引定義的6種服務品質屬性,其對應關係請參照下表3。舉例而言,[非常高.最佳]是對應於<最佳.非常高>;[高.最佳]是對應於<最佳.高>,而其餘[延遲.可靠度]與<可靠度.延遲>的對應關係可參照表3來依此類推。因為USB PHDC定義的6種pipe連線服務品質屬性直接對應到康體佳指引定義的6種服務品質屬性,因此當pipe連線建立後,若有在該資料連線傳送的訊息,可單由解析資料連線識別碼及查詢服務品質映射表(QoS mapping table)來設定該資料連線訊息的服務品質控制參數的方法。
再者,假若第二通信協定是BT HDP通信協定,此即終端個人健康裝置PHD與第三協定通訊模組ST3之間的通訊介面為藍芽健康設備概廓(Bluetooth Health Device Profile,BT HDP)通信協定。第一應用程式介面模組API1可由第二訊息、第四訊息及第五訊息的訊息內容觀察到MDL(Medical Data Link)資料連線相關的資訊,並藉以判斷是否有新的藍芽資料連線(BT MDL連線)被建立,並在服務品質映射表(QoS mapping table)中建立相對應之MDL連線服務品質紀錄。由於目前BT HDP的標準中BT MDL連線只有區分為可靠的(reliable)訊息與串流(streaming)兩種服務品質,因此在本揭露的可實施方式中,無法直接對應到康體佳指引定義的6種服務品質屬性,因此若要執行完整的服務品質控制,則除了根據MDL資料連線識別碼外,還必需解析資料連線訊息乘載(即IEEE 11073 PHD訊息內容)來進一步判斷訊息種類,並根據表二設定訊息種類對應之其服務品質控制參數。另一種簡易的服務品質控制方法是,雖然可靠性MDL資料連線可以對應到<最佳、非常高>、<最佳、高>、<最佳、中等>、<較佳、中等>四種服務品質屬性,但只選擇對應到最嚴格要求的<最佳、中等>服務品質屬性,雖然串流性MDL資料連線可以對應到<佳、中等>、<佳、低>兩種服務品質屬性,但只選擇對應到最嚴格要求的<佳、低>服務品質屬性。
在本實施例中,第一應用程式介面模組API1可以由第二訊息的內容判斷該訊息為非資料連線訊息(例如控制/命令訊息及其回覆訊息)或資料連線訊息兩種,並在將第一訊息轉換成第二訊息的過程中加入服務品質屬性到第二訊息。第一應用程式介面模組API1對於非資料連線的第二訊息可以利用默認預設值(default value)來設定服務品質屬性及服務品質控制參數。對於資料連線的第二訊息可以查詢一服務品質映射表(QoS mapping table)的資料連線服務品質紀錄來設定服務品質屬性及服務品質控制參數。第一應用程式介面模組API1建立可以依據第五訊息、第一訊息及第二訊息的內容判斷得知有新的資料連線被建立,並得知該資料連線的連線識別碼、設備種類、設備位址及服務品質屬性等資訊,並在服務品質映射表中建立該資料連線的紀錄。經由第一應用程式介面模組API1的服務品質 映射表,可以對要傳送的屬於資料連線的第二訊息,在無線感測網路120上進行相對應的服務品質傳送控制。
舉例說明,當出現新的終端個人健康裝置(未繪示)與閘道器GW建立新的資料連線時(例如增加了一個血壓計的資料連線),閘道器GW可以利用第二協定通訊模組ST2發送第五訊息(此處為資料連線建立及致能訊息)至應用主機AHD中的第一協定通訊模組ST1,進而通知第一應用程式介面模組API1此時出現新建的終端個人健康裝置(例如血壓計)與閘道器GW間的資料連線。當第一應用程式介面模組API1判斷第五訊息為用來通知應用主機AHD成功建立新的資料連線時,第一應用程式介面模組API1即在其服務品質映射表中創建關於一筆新的終端個人健康裝置的資料連線記錄,並根據所述新的資料連線的服務品質屬性,來設定該資料連線的傳輸優先權等級、傳輸模式以及正面應答模式設定值。
舉例而言,假若由終端個人健康裝置PHD透過已建立的資料連線發送訊息至閘道器GW,則閘道器GW的第二應用程式介面模組API2可以根據該資料連線識別碼查詢服務品質映射表而得到該資料連線之服務品質控制參數。
所述服務品質映射表還可以利用下列表5的方式來呈現,一般而言表5中第三欄位之設備位址可以省略。以第一應用程式介面模組API1模組為例,表5顯示第一應用程式介面模組API1模組經由持續的觀察第一訊息、第二 訊息及第五訊息,得知資料連線的建立/致能/除能/中斷等情形,並將結果紀錄於服務品質映射表(QoS mapping table)中,由服務品質映射表得知目前有三個資料連線被建立。
舉例說明,在表5中,第一條資料連線屬於BT HDP資料連線,該連線的藍芽PHD位址為#1_BT_ADDR,連線識別碼為#1_MDL_ID為致能狀態,對應的服務品質參數為<高傳輸優先權等級、競爭模式、採用正面應答模式>,由服務品質控制參數可以推論得知原來的BT HDP資料連線為可靠性資料連線,因此實施例採用簡易服務品質控制方法,不對IEEE 11073 PHD資料乘載做進一步解析。所以可以直接採用<高傳輸優先權等級、競爭模式、採用正面應答模式>服務品質控制參數。
舉例說明,在表5中,第二條資料連線屬於BT HDP資料連線,該連線的藍芽PHD位址為#2_BT_ADDR,連線識別碼為#2_MDL_ID,對應的服務品質參數為<高傳輸優先權等級、競爭模式、不採用正面應答模式>,由服務品質控制參數可以推論得知原來的BT HDP資料連線為串流性資料連線,因此實施例採用簡易服務品質控制方法,不對IEEE 11073 PHD資料乘載做進一步解析,所以可以直接採用<高傳輸優先權等級、競爭模式、不採用正面應答模式>服務品質控制參數。
舉例說明,在表5中,第三條資料連線屬於BT HDP資料連線,該連線的藍芽PHD位址為#3_BT_ADDR,連線識別碼為#3_MDL_ID為不致能(disable)狀態表示該資料 連線為連線除能狀態(一般的情形為該個人健康設備的該資料連線的資料已傳送全部完畢),對應的品質服務參數為高傳輸優先權等級、競爭模式及採用正面應答模式。
請同時參照圖5及表5,當第一應用程式介面模組API1判斷由第一協定堆疊模組ST1所接收的第五訊息為通知資料連線#1_MDL_ID已成功建立連線且該連線為致能狀態的回覆訊息時,第一應用程式介面模組API1在所述服務品質映射表中建立並致能(enable)該資料連線的對應連線記錄。在其他實施例中,第一應用程式介面模組API1也可以經由判斷第一訊息或第二訊息的訊息內容來進行上述處理程序。舉例而言,當終端個人健康裝置(位址#1_BT_ADDR)閘道器GW間的資料連線(#1_MDL_ID)已成功建立連線且為致能狀態時,閘道器GW可以利用第二協定堆疊模組ST2發送第五訊息(例如,通知訊息)至應用主機AHD的第一協定堆疊模組ST1,來通知第一應用程式介面模組API1。而第一應用程式介面模組API1在判斷第五訊息為通知資料連線已成功建立並進入致能狀態(或作連線致能狀態)時,即在所述服務品質映射表(表5)中建立並致能資料連線(#1_MDL_ID)的對應連線記錄。
當第一應用程式介面模組API1判斷由第一協定通訊模組ST1所接收的第五訊息為通知資料連線已除能的訊息時,第一應用程式介面模組API1可以在所述服務品質映射表中不致能資料連線的對應連線記錄。在其他實施例中,第一應用程式介面模組API1也可以經由判斷第一訊息或第二訊息的訊息內容來進行上述處理程序。舉例而言,當終端個人健康裝置(位址為#3_BT_ADDR)與閘道器GW之間的資料連線#3_MDL_ID已進入連線除能狀態時,閘道器GW可以利用第二協定通訊模組ST2發送第五訊息(通知訊息)至應用主機AHD中的第一協定通訊模組 ST1,用以通知第一應用程式介面模組API1。
當第一應用程式介面模組API1判斷此第五訊息為通知資料連線#3_MDL_ID已進入連線除能狀態時,第一應用程式介面模組API1在所述服務品質映射表(表5)中不致能#3_MDL_ID資料連線的對應連線記錄。在其他實施例中,第一應用程式介面模組API1也可以經由判斷第一訊息或第二訊息的訊息內容來進行上述處理程序。
當第一應用程式介面模組API1判斷第五訊息為通知已成功中斷一資料連線的控制訊息時,第一應用程式介面模組API1在所述服務品質映射表中刪除資料連線的對應連線記錄。在其他實施例中,第一應用程式介面模組API1也可以經由判斷第一訊息或第二訊息的訊息內容來進行上述處理程序。舉例而言,當與閘道器GW連接的一終端個人健康裝置PHDK與閘道器GW的資料連線關係被中斷時,閘道器GW也可以利用第二協定通訊模組ST2發送第五訊息(通知訊息)至應用主機AHD中的第一協定通訊模組ST1,來通知第一應用程式介面模組API1。
在其他實施例中,表5中的各個欄位的內容亦可以根據分散式應用平台系統500的應用範疇而有各種不同的呈現及設定方式。
當應用主機AHD的第一應用程式介面模組API1判斷需要發送非資料通道訊息(非IEEE 11073 PHD訊息)到無線感測網路120時,第一應用程式介面模組API1可以不查詢所述服務品質映射表而直接以默認預設值來設置控制 訊息的傳輸優先權等級、競爭/非競爭傳輸模式與正面應答模式設定值。也就是說,當第一應用程式介面模組API1經由第一協定通訊模組ST1發送非資料通道訊息時,由於非資料通道訊息的傳輸優先權等級、競爭/非競爭傳輸模式及正面應答模式皆已固定預設為例如高傳輸優先權等級、競爭傳輸模式以及採用正面應答模式的方式,但本揭露可實施方式不限定於此。於是,在傳送控制訊息時即不需查詢所述服務品質映射表而直接根據預設方式而對其傳輸優先權等級、競爭/非競爭傳輸模式以及正面應答模式的設定值進行設置。
在本揭露的一實施例中,閘道器GW的第二應用程式介面模組API2也可以包括一服務品質映射表,此服務品質映射表可以是與位於第一應用程式介面模組API1的服務品質映射表具有相同的內容(例如表5)。第二應用程式介面模組API2可以由第五訊息的內容判斷該訊息為非資料連線訊息(例如BT HDP控制/命令訊息及其回覆訊息)或資料連線訊息(例如IEEE 11073 PHD訊息)兩種,並在將第四訊息轉換成第五訊息的過程中加入服務品質屬性到第五訊息。第二應用程式介面模組API2對於非資料連線訊息的服務品質控制參數,可以利用默認預設的方式來設定。對於處理資料連線的服務品質控制參數,則可以根據服務品質映射表(QoS mapping table)的資料連線服務品質紀錄來執行。第二應用程式介面模組API2可以依據接收到的第四訊息、第五訊息及第二訊息的內容判斷得知有新的資料 連線被建立及該連線的品質服務屬性,並在服務品質映射表中建立該連線的服務品質紀錄。當第二應用程式介面模組API2判斷需要發送一資料連線訊息(message)到第一應用程式介面模組API1時,第二應用程式介面模組API2將先查詢此訊息在所述服務品質映射表中對應於該資料連線的對應連線記錄,並根據此對應連線記錄來設置發送此訊息到第一應用程式介面模組API1的傳輸優先權等級、競爭/非競爭傳輸模式與正面應答模式設定值。
舉例說明,當第二應用程式介面模組API2經由第三協定通訊模組ST3從一終端個人健康裝置PHD接收的第四訊息為傳輸層(例如BT HDP或USB PHDC層)的命令回覆訊息(Response report),因此第二應用程式介面模組API2判斷要發送非資料連線訊息到第一應用程式介面模組API1時,第二應用程式介面模組API2可以不查詢所述服務品質映射表而直接使用默認預設值來設置非資料連線訊息的傳輸優先權等級、競爭/非競爭傳輸模式與正面應答模式的設定值。
此外,當終端個人健康裝置PHD1~PHDK的其中之一想要將自身所量測到的生理數據訊息(例如血壓值、血糖值或體溫數據等)經由閘道器GW轉送至應用主機AHD時,第二應用程式介面模組API2在處理此資料連線訊息的傳送時,會進行查詢自身的服務品質映射表的操作。具體而言,假若終端個人健康裝置PHD1量測到一個生理數據訊息(例如血壓值)並且經由已建立的資料連線發送至應用主 機AHD時,第二應用程式介面模組API2在將此生理數據訊息轉送至應用主機AHD之前,會先在自身的服務品質映射表中查詢此生理數據訊息的資料連線服務品質記錄,並且根據此記錄(例如傳輸優先權等級的設定、是否使用競爭模式以及正面應答訊息模式等)來對所述生理數據訊息進行服務品質控制,並發送訊息至應用主機AHD。
更清楚說明為,假若第二應用程式介面模組API2判斷經由第三協定通訊模組ST3從一終端個人健康裝置PHD接收的第四訊息為通知成功建立一新的資料連線時,第二應用程式介面模組API2在其服務品質映射表中創建一連線記錄。在其他實施例中,第二應用程式介面模組API2也可以經由判斷第二訊息或第五訊息的訊息內容來進行上述處理程序。因為該訊息為非資料連線訊息,因此第二應用程式介面模組API2根據默認預設值來設定該訊息的服務品質屬性及與服務品質屬性對應的一傳輸優先權等級、一傳輸模式與一正面應答模式設定值,並轉換第四訊息為第五訊息,且經由第二協定通訊模組ST2以及無線感測網路120發送第五訊息到應用主機AHD。
當第二應用程式介面模組API2接收經由第三協定通訊模組ST3接收的第四訊息為通知一資料連線已成功進入一連線致能狀態時,第二應用程式介面模組API2在其服務品質映射表中致能此資料連線的一對應連線記錄。在其他實施例中二應用程式介面模組API2也可以經由判斷第二訊息或第五訊息的訊息內容來進行上述處理程序。然 後,第二應用程式介面模組API2轉換第四訊息為第五訊息,且經由第二協定通訊模組ST2以及無線感測網路120發送第五訊息到應用主機AHD。
當第二應用程式介面模組API2判斷經由第三協定通訊模組ST3接收的第四訊息為通知一資料連線已進入一連線除能狀態時,第二應用程式介面模組API2在其服務品質映射表中除能此資料連線的對應連線記錄。在其他實施例中二應用程式介面模組API2也可以經由判斷第二訊息或第五訊息的訊息內容來進行上述處理程序。然後,第二應用程式介面模組API2轉換第四訊息為第五訊息,且經由第二協定通訊模組ST2以及無線感測網路120發送第五訊息到應用主機AHD。
當第二應用程式介面模組API2判斷經由第三協定通訊模組ST3接收的第四訊息為通知應用主機AHD已成功中斷一資料連線時,第二應用程式介面模組API2在其服務品質映射表中刪除此資料連線的對應連線記錄。在其他實施例中二應用程式介面模組API2也可以經由判斷第二訊息或第五訊息的訊息內容來進行上述處理程序。然後,第二應用程式介面模組API2轉換第四訊息為第五訊息,且經由第二協定通訊模組ST2以及無線感測網路120發送第五訊息到應用主機AHD。
圖6是根據本揭露的另一實施例所繪示的傳輸訊息的服務品質控制方法的流程圖,所述傳輸訊息的服務品質控制方法可以應用於第一應用程式介面模組API1及第二應 用程式介面模組API2。
以下為第一應用程式介面模組API1處理傳輸訊息的服務品質控制流程說明,請同時參照圖1A及圖6,在步驟601中,應用主機AHD的第一應用程式介面模組API1可能接收到由上層個人健康管理軟體模組112傳送過來的第一訊息(設備內模組間傳送的訊息是由被呼叫的函式(function)及其參數組成的),或由第一協定通訊模組ST1傳送過來的第五訊息,或由內部產生一個新的第二訊息時(為了回應第一訊息/第五訊息而產生或轉換的第二訊息),第一訊息及第五訊息並不需要傳送到無線感測網路120,將在步驟602及步驟603做後續處理,但是第二訊息必需被傳送到無線感測網路120。因此,當判斷需要傳送訊息到無線感測網路120時,在步驟601後執行步驟為604。
在步驟602及步驟603中,再判斷第一訊息或第五訊息的訊息內容是否與資料連線建立/致能/除能/中斷相關,其中,若是,則根據該訊息內容來新增/致能/不致能/刪除服務品質映射表中該連線的服務品質紀錄;若否,則所述傳輸訊息的服務品質控制方法到此結束。
在步驟604中,進一步判斷該第二訊息是屬於資料連線訊息(例如BT HDP MDL資料連線)或者是非資料連線訊息(例如傳輸層的命令訊息或其回覆訊息)。在步驟605中,該訊息已由之前步驟確認為非資料連線訊息,再進一步判斷該訊息是否包含資料連線建立/致能/除能/中斷之相關內容。在步驟607中,將根據該訊息內容新增/致能/不致能/ 刪除服務品質映射表中該連線之服務品質紀錄。
在步驟608中,由於前述步驟604已確認該訊息為非資料連線訊息,因此應用主機AHD的第一應用程式介面模組API1將不查表而根據默認預設值設定該訊息的傳送服務品質參數。在步驟606中,由於前述步驟604已確認該訊息為資料連線訊息,因此將查詢服務品質映射表而設定該訊息的傳送服務品質參數。
在步驟609中,由於前述步驟601已確認訊息必需傳送到無線感測網路120,因此應用主機AHD的第一應用程式介面模組API1將根據第一協定通訊模組ST1是否具有提供傳送服務品質功能而做不同處理。在步驟610中,由於前述步驟609已確認第一協定通訊模組ST1不提供傳送服務品質功能,因此第一應用程式介面模組API1可以用不同的傳輸緩衝器及正面應答模式組合的機制來完成<傳輸優先權等級/競爭或非競爭傳輸模式/正面應答模式>的傳輸服務品質控制。
在步驟611中,由於前述步驟609已確認第一協定通訊模組有提供傳送服務品質功能,例如:有些加強版的802.15.4 MAC模組利用802.15.4 MAC標準在媒介存取控制層標頭(MAC header)保留的三個位元(bit)來提供8種不同的傳輸服務,並可對這8種不同傳輸服務分別設定不同的重傳次數控制。另外,在Zigbee 2007版本後有提供應用程式支援子層正面應答(Application Support Sublayer Acknowledgement,APS ACK)機制。因此,第一應用程式 介面模組API1可以決定如何搭配第一協定通訊模組ST1提供的傳送服務品質功能,以取得有效能的控制方式。在步驟612中,第一應用程式介面模組API1將搭配使用第一協定通訊模組ST1提供的傳送服務品質功能,來達成第二訊息的傳輸服務品質控制。在步驟610或步驟612後,所述傳輸訊息的服務品質控制方法結束。
以下為第二應用程式介面模組API2處理傳輸訊息的服務品質控制流程說明。請同時參照圖1A及圖6,在步驟601中,閘道器GW的第二應用程式介面模組API2可能接收到由第二協定通訊模組ST2傳送過來的第二訊息,或由第三協定通訊模組ST3傳送過來的第四訊息,或由內部產生一個新的第五訊息時(為了回應第二訊息/第四訊息而產生或轉換的第五訊息五)。第二訊息及第四訊息並不需要被傳送到無線感測網路120,將在步驟602及步驟603做後續處理,而第五訊息必需傳送到無線感測網路120,因此當判斷需要傳送訊息到無線感測網路120時,在步驟601後執行步驟為604。
在步驟602及步驟603中,進一步判斷第二訊息或第四訊息的訊息內容是否與資料連線建立/致能/除能/中斷相關,其中,若是,則根據該訊息內容來新增/致能/不致能/刪除服務品質映射表中該連線的服務品質紀錄;若否,則所述傳輸訊息的服務品質控制方法到此結束。
在步驟604中,進一步判斷該第五訊息是屬於資料連線訊息(例如傳送生理資料回覆訊息等)或者是非資料連線 訊息(例如傳輸層的命令訊息或其回覆訊息)。在步驟605中,該訊息已由前述步驟604確認為非資料連線訊息,再進一步判斷該訊息是否包含資料連線建立/致能/除能/中斷的相關內容。
在步驟607中,將根據該訊息內容來新增/致能/不致能/刪除服務品質映射表中該連線的服務品質紀錄。在步驟608中,由於前述步驟604已確認該訊息為非資料連線訊息,因此閘道器GW的第二應用程式介面模組API2將不查表而根據默認預設值來設定該訊息的傳送服務品質參數。在步驟606中,由於前述步驟604已確認該訊息為資料連線訊息,因此將查詢服務品質映射表而設定該訊息的傳送服務品質參數。
在步驟609中,由於前述步驟601已確認訊息必需被傳送到無線感測網路120,因此第二應用程式介面模組API2將根據第二協定通訊模組ST2是否有提供傳送服務品質功能而做不同處理。在步驟610中,由於前述步驟609已確認第二協定通訊模組ST2沒有提供傳送服務品質功能,因此第二應用程式介面模組API2可以用不同的傳輸緩衝器及正面應答模式組合的機制來完成<傳輸優先權等級/競爭或非競爭傳輸模式/正面應答模式>的傳輸服務品質控制。
在步驟611中,由於前述步驟609已確認第二協定通訊模組ST2有提供傳送服務品質功能,例如有些加強版的802.15.4 MAC模組利用802.15.4 MAC標準在MAC header保留的三個bit來提供8種不同的傳輸服務,並可用這8種不同傳輸模式分別設定重傳次數參數的控制。另外,在Zigbee 2007版本後有提供應用程式支援子層正面應答(Application Support Sublayer Acknowledgement,APS ACK)機制。因此,第二應用程式介面模組API1可以決定如何搭配第二協定通訊模組ST2提供的傳送服務品質功能,以取得有效能之控制方式。在步驟612中,第二應用程式介面模組API1將搭配使用第二協定通訊模組ST2提供的傳送服務品質功能,來達成第五訊息的傳輸服務品質控制。
雖然本揭露已以實施例揭露如上,然其並非用以限定本揭露,任何所屬技術領域中具有通常知識者,在不脫離本揭露之精神和範圍內,當可作些許之更動與潤飾,故本揭露之保護範圍當視後附之申請專利範圍所界定者為準。
100、500‧‧‧分散式應用平台系統
AHD‧‧‧應用主機
GW‧‧‧閘道器
API1‧‧‧第一應用程式介面模組
API2‧‧‧第二應用程式介面模組
ST1‧‧‧第一協定通訊模組
ST2‧‧‧第二協定通訊模組
ST3‧‧‧第三協定通訊模組
112‧‧‧個人健康管理軟體模組
120‧‧‧無線感測網路
10‧‧‧原始應用主機AHD通訊協定堆疊
11‧‧‧應用主機AHD通訊協定堆疊
112‧‧‧個人健康管理軟體模組
113‧‧‧個人健康管理軟體模組應用程式介面
114‧‧‧第三協定通訊模組應用程式介面
116‧‧‧虛擬第三協定通訊模組應用程式介面
118‧‧‧虛擬個人健康管理軟體模組應用程式介面
12‧‧‧閘道器GW通訊協定堆疊
PHD、PHD1~PHDK‧‧‧個人健康裝置
200‧‧‧訊息
210‧‧‧服務品質屬性欄位
220‧‧‧訊息資料欄位
M00~M03‧‧‧網路封包乘載
X、Y、Z‧‧‧子封包乘載
601~612‧‧‧步驟
圖1A是根據本揭露之一實施例所繪示的分散式應用平台系統的功能方塊圖。
圖1B是根據本揭露之一實施例所繪示的分散式應用平台系統的協定堆疊的示意圖。
圖2是根據本揭露之一實施例所繪示的訊息的訊息欄位示意圖。
圖3是根據本揭露之一實施例所繪示的封包切割的示意圖。
圖4是根據本揭露之一實施例所繪示的封包重組的示意圖。
圖5是根據本揭露之另一實施例所繪示的分散式應用平台系統的功能方塊圖。
圖6是根據本揭露之一實施例所繪示的傳輸訊息的服務品質控制方法的流程圖。
100‧‧‧分散式應用平台系統
AHD‧‧‧應用主機
GW‧‧‧閘道器
API1‧‧‧第一應用程式介面模組
API2‧‧‧第二應用程式介面模組
ST1‧‧‧第一協定通訊模組
ST2‧‧‧第二協定通訊模組
ST3‧‧‧第三協定通訊模組
112‧‧‧個人健康管理軟體模組
120‧‧‧無線感測網路
PHD‧‧‧個人健康裝置

Claims (30)

  1. 一種分散式應用平台系統,包括:一應用主機,包括一個人健康管理軟體模組、一第一應用程式介面模組與一第一協定通訊模組,其中,該第一應用程式介面模組包括一個人網路應用程式介面的第一部分功能;一無線感測網路;一閘道器,連接於該應用主機與至少一終端個人健康裝置,該閘道器包括一第二應用程式介面模組、一第二協定通訊模組與一第三協定通訊模組;該第二應用程式介面模組包括一個人網路應用程式介面的第二部份功能;該無線感測網路、該第一與該第二協定通訊模組皆支援一第一通信協定;該第三協定通訊模組支援一第二通信協定,該第一與該第二應用程式介面模組合作達成該個人網路應用程式介面的所有預設功能,且該所有預設功能為該第一部份功能與該第二部份功能之組合;該至少一終端個人健康裝置藉由該閘道器連接至該應用主機;以及該應用主機傳送訊息到該無線感測網路或該閘道器傳送訊息到該無線感測網路時經由設定該訊息的傳輸優先權等級及正面應答模式設定值的服務品質參數,來執行該訊息的傳送服務品質控制機制。
  2. 如申請專利範圍第1項所述的分散式應用平台系統,其中該第一應用程式介面模組藉由該第一協定通訊模組傳送訊息到該無線感測網路時,經由設定該訊息的傳輸優先權等級及正面應答模式設定值的服務品質參數,來執行該訊息的傳送服務品質控制機制。
  3. 如申請專利範圍第1項所述的分散式應用平台系統,其中該第二應用程式介面模組藉由該第二協定通訊模組傳送訊息到該無線感測網路時,經由設定該訊息的傳輸優先權等級及正面應答模式設定值的服務品質參數,來執行該訊息的傳送服務品質控制機制。
  4. 如申請專利範圍第1項所述的分散式應用平台系統,其中該訊息的該傳輸優先權等級代表與其他訊息相較之下該訊息被傳送的一優先次序,且該正面應答模式設定值指示接收該訊息的一通訊裝置是否需要回傳一正面應答封包。
  5. 如申請專利範圍第2項所述的分散式應用平台系統,其中:該應用主機利用該第一協定通訊模組,經由該無線感測網路與該閘道器的該第二協定通訊模組進行通信;以及該第一應用程式介面模組用來接收在一通信協定堆疊中位於該第一應用程式介面模組之上層的該個人健康管理軟體模組產生的一第一訊息,該第一應用程式介面模組將該第一訊息轉換為支援該第一通信協定的一第二訊息,並經由該第一協定通訊模組以及該無線感測網路發送該第 二訊息至該第二協定通訊模組,其中該第一協定通訊模組在該通信協定堆疊中位於該第一應用程式介面模組的下層。
  6. 如申請專利範圍第5項所述的分散式應用平台系統,其中:該閘道器利用該第二協定通訊模組,經由該無線感測網路與該應用主機的該第一協定通訊模組進行通信;以及該第二應用程式介面模組用來接收在一通信協定堆疊中位於該第二應用程式介面模組之下層的該第二協定通訊模組傳遞的該第二訊息,並轉換該第二訊息為支援該第二通信協定的一第三訊息,且經由在一通信協定堆疊中位於該第二應用程式介面模組之下層的該第三協定通訊模組,發送該第三訊息到該至少一終端個人健康裝置的其中之一。
  7. 如申請專利範圍第3項所述的分散式應用平台系統,其中:該閘道器利用該第三協定通訊模組接收該至少一終端個人健康裝置的其中之一發送的一第四訊息,該第四訊息支援該第二通信協定,該第二應用程式介面模組將該第四訊息轉換為支援該第一通信協定的一第五訊息,並經由該第二協定通訊模組以及該無線感測網路發送該第五訊息到該第一協定通訊模組。
  8. 如申請專利範圍第7項所述的分散式應用平台系統,其中: 該第一應用程式介面模組接收由該第一協定通訊模組從該無線感測網路接收的該第五訊息,並轉換該第五訊息為一第六訊息且傳遞該第六訊息至該個人健康管理軟體模組。
  9. 如申請專利範圍第5項所述的分散式應用平台系統,其中:在該第一應用程式介面模組將該第一訊息轉換為該第二訊息的過程中,該第一應用程式介面模組先決定將第二訊息傳送到該無線感測網路的服務品質屬性,根據該服務品質屬性對應的傳輸優先權等級服務品質參數、競爭/非競爭傳輸模式服務品質參數、正面應答模式服務品質參數,並依據該些服務品質參數單獨或配合該第一協定通訊模組的服務品質控制功能來執行該傳送服務品質控制機制,其中該服務品質屬性包括可靠度參數及延遲參數。
  10. 如申請專利範圍第9項所述的分散式應用平台系統,其中該第一協定通訊模組的傳輸模式包括一競爭模式與一保證時槽模式。
  11. 如申請專利範圍第10項所述的分散式應用平台系統,其中:當該第一應用程式介面模組設置發送該第二訊息時採用該競爭模式時,該第一應用程式介面模組更根據該可靠度服務品質屬性判斷是否採用該正面應答模式。
  12. 如申請專利範圍第7項所述的分散式應用平台系統,其中: 在該第二應用程式介面模組將該第四訊息轉換為該第五訊息的過程中,該第二應用程式介面模組先決定將該第五訊息傳送到該無線感測網路的服務品質屬性,及該服務品質屬性對應的傳輸優先權等級服務品質參數、競爭/非競爭傳輸模式服務品質參數、正面應答模式服務品質參數,並依據該些服務品質參數單獨或配合該第二協定通訊模組的服務品質功能來執行該傳送服務品質控制機制,其中該服務品質屬性包括可靠度參數及延遲參數。
  13. 如申請專利範圍第12項所述的分散式應用平台系統,其中該第二協定通信模組的傳輸模式包括一競爭模式與一保證時槽模式。
  14. 如申請專利範圍第13項所述的分散式應用平台系統,其中:當該第二應用程式介面模組設置發送該第五訊息時採用該競爭模式時,該第二應用程式介面模組更根據該可靠度服務品質屬性判斷是否採用該正面應答模式。
  15. 如申請專利範圍第1項所述的分散式應用平台系統,其中:該第一應用程式介面模組同時進行在該第一通信協定與該第二通信協定之間轉換的封包切割與重組。
  16. 如申請專利範圍第1項所述的分散式應用平台系統,其中:該第二應用程式介面模組同時進行在該第一通信協定與該第二通信協定之間轉換的封包切割與重組。
  17. 如申請專利範圍第5或第8項所述的分散式應用平台系統,其中:該第一應用程式介面模組還包括一服務品質映射表,其中:當該第一應用程式介面模組由該第一訊息、該第二訊息或該第五訊息的內容,判斷該已成功建立一新的資料連線時,該第一應用程式介面模組在該服務品質映射表中創建一資料連線記錄,並根據該新的資料連線的一服務品質屬性,來設定該資料連線的一傳輸優先權等級、一競爭/非競爭傳輸模式與一正面應答模式設定值;以及當該第一應用程式介面模組由該第一訊息、該第二訊息或該第五訊息的內容,判斷已成功中斷一資料連線時,該第一應用程式介面模組在該服務品質映射表中刪除該資料連線的一對應連線記錄。
  18. 如申請專利範圍第6或第7項所述的分散式應用平台系統,其中:該第二應用程式介面模組還包括一服務品質映射表,其中:當該第二應用程式介面模組由該第四訊息、該第五訊息或該第二訊息的內容,判斷成功建立一新的資料連線時,該第二應用程式介面模組在該服務品質映射表中創建一資料連線記錄,並根據該新的資料連線的一服務品質屬性,來設定該資料連線的一傳輸優先權等級與一正面應答模式設定值;以及 當該第二應用程式介面模組由該第四訊息或該第五訊息或該第二訊息的內容,判斷已成功中斷一資料連線時,該第二應用程式介面模組在該服務品質映射表中刪除該資料連線的該對應連線記錄。
  19. 如申請專利範圍第17項所述的分散式應用平台系統,其中:當該第一應用程式介面模組判斷需要發送一非資料連線訊息到該無線感測網路時,該第一應用程式介面模組不查詢該服務品質映射表,直接設置該非資料連線訊息的一傳輸優先權等級、一競爭/非競爭傳輸模式與一正面應答模式設定值;以及當該第一應用程式介面模組判斷需要發送一資料連線訊息到該無線感測網路時,先查詢該資料連線訊息在該服務品質映射表中的一對應資料連線的一對應資料連線記錄,並根據該對應連線記錄來設置發送該資料連線訊息到該無線感測網路的一傳輸優先權等級、一競爭/非競爭傳輸模式與一正面應答模式設定值。
  20. 如申請專利範圍第18項所述的分散式應用平台系統,其中:當該第二應用程式介面模組判斷需要發送一非資料連線訊息到該無線感測網路時,該第二應用程式介面模組不查詢該服務品質映射表,直接設置該非資料連線訊息的一傳輸優先權等級、一競爭/非競爭傳輸模式與一正面應答模式設定值;以及 當該第二應用程式介面模組判斷需要發送一資料連線訊息到該無線感測網路時,先查詢該資料連線訊息在該服務品質映射表中的一對應資料連線的一對應資料連線記錄,並根據該對應連線記錄來設置發送該資料連線訊息到該無線感測網路的一傳輸優先權等級、一競爭/非競爭傳輸模式與一正面應答模式設定值。
  21. 一種傳輸訊息的服務品質控制方法,適用於包括一應用主機、一無線感測網路與一閘道器的分散式應用平台系統,所述傳輸訊息的服務品質控制方法包括:該應用主機經由該無線感測網路以及該閘道器,發送訊息到至少一終端個人健康裝置,其中該應用主機與該閘道器皆支援一第一通信協定,至少一終端個人健康裝置藉由該閘道器連接至該應用主機,且與該閘道器皆支援一第二通信協定;該至少一終端個人健康裝置經由該閘道器以及該無線感測網路,發送訊息到該應用主機;以及當該應用主機傳送訊息到該無線感測網路及該閘道器傳送一訊息到該無線感測網路時,該應用主機或該閘道器經由設定該訊息的傳輸優先權等級及正面應答模式設定值的服務品質參數,來執行該訊息的傳送服務品質控制機制。
  22. 如申請專利範圍第21項所述的傳輸訊息的服務品質控制方法,其中該訊息的該傳輸優先權等級代表與其他訊息相較之下該訊息被傳送的一優先次序,且該正面應 答模式設定值指示接收該訊息的一通訊裝置是否需要回傳一正面應答封包。
  23. 如申請專利範圍第22項所述的傳輸訊息的服務品質控制方法,其中在經由設定該訊息的傳輸優先權等級及正面應答模式設定值的服務品質參數的步驟之前,所述方法更包括:該應用主機或該閘道器根據將要發送的訊息的一服務品質屬性,選擇設定發送該將要發送的訊息到該無線感測網路時採用的一傳輸優先權等級、該第一通信協定的傳輸模式及正面應答模式。
  24. 如申請專利範圍第23項所述的傳輸訊息的服務品質控制方法,其中該第一通信協定的傳輸模式包括一競爭模式與一保證時槽模式。
  25. 如申請專利範圍第24項所述的傳輸訊息的服務品質控制方法,更包括:當該閘道器由已接收到或將要傳送的訊息內容中判斷已成功建立一新的資料連線時,該閘道器在一服務品質映射表中創建一資料連線記錄,並根據該新的資料連線的一服務品質屬性,來設定一資料連線的一傳輸優先權等級、一競爭/非競爭傳輸模式與一正面應答模式設定值;當該閘道器由已接收到或將要傳送的訊息內容中判斷要通知該應用主機一資料連線已成功進入一連線致能狀態時,該閘道器在該服務品質映射表中致能該資料連線的一對應連線記錄; 當該閘道器判斷要通知該應用主機一資料連線已進入一連線除能狀態時,該閘道器在該服務品質映射表中不致能該資料連線的該對應連線記錄;以及當該閘道器判斷要通知該應用主機已成功中斷一資料連線時,該閘道器在該服務品質映射表中刪除該資料連線的該對應連線記錄。
  26. 如申請專利範圍第24項所述的傳輸訊息的服務品質控制方法,更包括:當該應用主機由已接收到或將要傳送的訊息內容中判斷已成功建立一新的資料連線時,該應用主機在一服務品質映射表中創建一資料連線記錄,並根據該新的資料連線的一服務品質屬性,來設定一資料連線的一傳輸優先權等級、一競爭/非競爭傳輸模式與一正面應答模式設定值;當該應用主機判斷要通知該閘道器一資料連線已成功進入一連線致能狀態時,該應用主機在該服務品質映射表中致能該資料連線的一對應連線記錄;當該應用主機判斷要通知該閘道器一資料連線已進入一連線除能狀態時,該應用主機在該服務品質映射表中不致能該資料連線的該對應連線記錄;以及當該應用主機判斷要通知該閘道器已成功中斷一資料連線時,該應用主機在該服務品質映射表中刪除該資料連線的該對應連線記錄。
  27. 如申請專利範圍第25項所述的傳輸訊息的服務品質控制方法,更包括:當該閘道器判斷需要發送一非資料連線訊息到該無 線通信網路時,該該閘道器不查詢該服務品質映射表,直接設置該非資料連線訊息的一傳輸優先權等級、一競爭/非競爭傳輸模式與一正面應答模式設定值。
  28. 如申請專利範圍第26項所述的傳輸訊息的服務品質控制方法,更包括:當該應用主機判斷需要發送一非資料連線訊息到該無線感測網路時,該應用主機不查詢該服務品質映射表,直接設置該非資料連線訊息的一傳輸優先權等級、一競爭/非競爭傳輸模式與一正面應答模式設定值。
  29. 如申請專利範圍第25項所述的傳輸訊息的服務品質控制方法,更包括:當該閘道器接收該個人健康裝置的資料連線訊息時,該閘道器先查詢該資料連線訊息在該服務品質映射表中的一對應資料連線的一對應資料連線記錄,並根據該對應連線記錄來設置發送該資料連線訊息到該無線感測網路的一傳輸優先權等級、一競爭/非競爭傳輸模式與一正面應答模式設定值。
  30. 如申請專利範圍第26項所述的傳輸訊息的服務品質控制方法,更包括:當該應用主機要傳送屬於資料連線的一資料連線訊息到該無線感測網路時,該應用主機先查詢該資料連線訊息在該服務品質映射表中的一對應資料連線的一對應資料連線記錄,並根據該對應連線記錄來設置發送該資料連線訊息到該無線感測網路的一傳輸優先權等級、一競爭/非競爭傳輸模式與一正面應答模式設定值。
TW101122432A 2012-03-06 2012-06-22 分散式應用平台系統及其傳輸訊息的服務品質控制方法 TWI482525B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
TW101122432A TWI482525B (zh) 2012-03-06 2012-06-22 分散式應用平台系統及其傳輸訊息的服務品質控制方法
US13/658,823 US20130235795A1 (en) 2012-03-06 2012-10-24 Distributed application system and method for controlling quality of service in data transmission thereof

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
TW101107503 2012-03-06
TW101122432A TWI482525B (zh) 2012-03-06 2012-06-22 分散式應用平台系統及其傳輸訊息的服務品質控制方法

Publications (2)

Publication Number Publication Date
TW201338612A TW201338612A (zh) 2013-09-16
TWI482525B true TWI482525B (zh) 2015-04-21

Family

ID=49114074

Family Applications (1)

Application Number Title Priority Date Filing Date
TW101122432A TWI482525B (zh) 2012-03-06 2012-06-22 分散式應用平台系統及其傳輸訊息的服務品質控制方法

Country Status (2)

Country Link
US (1) US20130235795A1 (zh)
TW (1) TWI482525B (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9253247B2 (en) * 2012-11-21 2016-02-02 Signove Tecnologia S/A Transcoding of communication with personal health devices
US9525586B2 (en) * 2013-03-15 2016-12-20 Intel Corporation QoS based binary translation and application streaming
CN104684029B (zh) * 2013-12-02 2019-01-01 中国移动通信集团公司 一种服务质量QoS控制方法及设备
TWI511495B (zh) * 2013-12-09 2015-12-01 Inst Information Industry 用於感測器網路之資料整合裝置
US10019304B2 (en) * 2016-01-06 2018-07-10 Nicira, Inc. Providing an application interface programming exception in an upper management layer
CN112671657A (zh) * 2016-02-04 2021-04-16 华为技术有限公司 业务数据的传输方法和装置
US10594828B2 (en) 2016-04-19 2020-03-17 International Business Machines Corporation Delivery of incremental sensor data over optimized channel
TWI659359B (zh) * 2018-04-27 2019-05-11 慧榮科技股份有限公司 控制儲存裝置之方法
EP4106290A1 (en) * 2021-06-17 2022-12-21 Deutsche Telekom AG A method for operating a distributed application

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999004685A1 (en) * 1997-07-25 1999-02-04 Vaeaenaenen Mikko A personal health status alarm method
US20100179832A1 (en) * 2007-06-07 2010-07-15 Koninklijke Philips Electronics N.V. A reputation system for providing a measure of reliability on health data
US20100295684A1 (en) * 2009-05-21 2010-11-25 Silverplus, Inc. Personal health management device
US20120033807A1 (en) * 2009-04-10 2012-02-09 Koninklijke Philips Electronics N.V. Device and user authentication

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7068632B1 (en) * 2000-07-14 2006-06-27 At&T Corp. RSVP/SBM based up-stream session setup, modification, and teardown for QOS-driven wireless LANs
DE602004002086T2 (de) * 2004-02-27 2007-04-12 Mitsubishi Denki K.K. Verfahren und Apparat zur gemeinsamen dynamischen Verwaltung von Fensterlängen von mehreren ARQ-Datenverbindungen
CN101430753B (zh) * 2007-11-08 2011-01-19 中兴通讯股份有限公司 一种射频识别系统中标签防碰撞方法
KR101289944B1 (ko) * 2008-12-12 2013-07-26 엘지전자 주식회사 초고처리율 무선랜 시스템에서 채널 추정 방법 및 이를 위한 장치
US8405502B2 (en) * 2009-06-10 2013-03-26 Qualcomm Incorporated Identification and connectivity gateway wristband for hospital and medical applications
US20120253847A1 (en) * 2011-03-31 2012-10-04 General Electric Company Health information telecommunications system and method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999004685A1 (en) * 1997-07-25 1999-02-04 Vaeaenaenen Mikko A personal health status alarm method
US20100179832A1 (en) * 2007-06-07 2010-07-15 Koninklijke Philips Electronics N.V. A reputation system for providing a measure of reliability on health data
US20120033807A1 (en) * 2009-04-10 2012-02-09 Koninklijke Philips Electronics N.V. Device and user authentication
US20100295684A1 (en) * 2009-05-21 2010-11-25 Silverplus, Inc. Personal health management device

Also Published As

Publication number Publication date
TW201338612A (zh) 2013-09-16
US20130235795A1 (en) 2013-09-12

Similar Documents

Publication Publication Date Title
TWI482525B (zh) 分散式應用平台系統及其傳輸訊息的服務品質控制方法
US9912446B2 (en) Device, method and computer readable medium for communication on a ZigBee network
US10348635B2 (en) Data transmission method and device
US8456997B2 (en) Wireless communication systems for medical data
TWI423714B (zh) 無線感測器網路之改進技術(二)
EP2226002B1 (en) Improvements to body area networks
WO2022095863A1 (zh) 一种用于输变电设备物联网的微功率无线接入方法与装置
US8704656B2 (en) Improvements to body area networks
CN104582561B (zh) 用于医学体域网的协调器切换方法
JP2010518891A (ja) 個人健康空間における医療デバイス・データ流通のための適応的フレームワーク
CN102082773B (zh) 一种基于反应堆保护系统列间安全通讯网络协议的通信方法
TW201015907A (en) Method of handling response failure for a bluetooth communication system and slave device for controlling the same
WO2011150758A1 (zh) 机器类通信设备能力的上报、获取方法及装置
CN103929490A (zh) 一种体域网系统的数据传输方法
WO2022007658A1 (zh) 缓存配置方法和交换设备
CN113194501A (zh) 基于ZigBee的医疗监控系统及网络拥塞控制方法
CN102043397A (zh) 一种楼宇自动控制系统的网络通讯方法
Shi-Lin et al. Development of Physiological Parameters Gateway for Medical IOT Ward
Thongpithoonrat et al. Networking and plug-and-play of bedside medical instruments
CN110247742A (zh) 一种通信方法、接入热点设备和终端设备
CN104888308A (zh) 输液监测系统及其中基于轮询优化的数据传输方法
CN219627748U (zh) 一体化电源系统报文转发装置
EP2226958A1 (en) Wireless sensor networks with data reception acknowledgement
JP5572248B2 (ja) 無線端末および無線通信方法
KR101399339B1 (ko) 호 전달 시스템 및 그 방법

Legal Events

Date Code Title Description
MM4A Annulment or lapse of patent due to non-payment of fees