ISO/IEC 29341-16-11:2011 情報技術— UPnPデバイスアーキテクチャ—パート16-11：低電力デバイス制御プロトコル—低電力サービス | ページ 4

2.1 サービスタイプ

次のサービス タイプは、このテンプレートに準拠するサービスを識別します。

2.2.1 派生データ型

この句は、特別な構文を使用して UPnP 文字列データ型として表されるいくつかの派生データ型を定義します。

2.2.1.1 UPnP 引数としての XML ドキュメント

UPnP Low Power サービスは、XML ドキュメントを UPnP アクションの引数として使用します。含まれる UPnP データ型は文字列です。これにより、文字列の内容に制限がかかります。整形式の XML ドキュメントを表す必要があります。

UPnP 低電力デバイスで使用される XML スキーマは、 http://www.upnp.org/schemas/ にあるそれぞれのファイルで定義されています。

XML ドキュメントでは、実装は適切な名前空間への明示的な参照を使用する場合があります。最後に、XML ドキュメントは、UPnP™ V1.0 アーキテクチャ 0 に準拠し、SOAP 要求または応答メッセージに埋め込む前に、通常の XML ルール [XML10] を使用してエスケープする必要があります。 XML エスケープ ルールは、上記の参考資料から要約されています。

• • (<) 文字は (&lt;) としてエンコードされます。
• • (>) 文字は (>) としてエンコードされます。
• • (&) 文字は (&amp;) としてエンコードされます。
• • ("") 文字は (&quot;) としてエンコードされます。
• • (') 文字は (') としてエンコードされます。

2.5.1 GetPowerManagementInfo()

デバイスは、アクションが受信されたインターフェイスの電力管理関連情報 (たとえば、ベアラー固有のウェイクアップ メカニズム、ネットワーク インターフェイス情報、ベンダー定義の情報、非ベアラー固有のウェイクアップ メカニズムなど) を提供します。

2.5.1.1 引数

2.5.1.2 状態への依存性 (存在する場合)

なし。これらは静的な機能です。

2.5.3.1 引数

2.6.1 アクションと操作の説明

UPnP 低電力デバイスは、GetPowerManagementInfo, () アクションを通じて静的な電源管理関連情報を公開します。この情報には、ベアラ タイプ、ウェイクアップ パターン、AdditionalBearerInfo (MAC アドレス、BTH アドレスなど)、NonBearerWakeupMetho, サポートされている電力状態、および PowerSupplyStatus などのベアラ固有のウェイクアップ方法が含まれます。

低電力デバイスは、wakeup() アクションを受信すると、スリープ状態 (つまり、トランスペアレント状態またはディープ スリープ オンライン状態) からアクティブ状態に移行します。 GoToSleep() アクションは、低電力対応コントロール ポイントがデバイスに一定期間スリープ状態のいずれかに入るように要求するメカニズムを提供します。入力スリープ状態とスリープ期間は、低電力対応制御ポイントによって提案されます。デバイスは推奨値を実装している場合と実装していない場合があります。移行先の電源状態と、選択したスリープ期間を返します。

低電力デバイスは、その電力状態を変更するたびに、SSDP メッセージ内の SSDP 拡張ヘッダーを介してこの電力状態の遷移を通知する必要があります。

• •低電力デバイスがアクティブ状態になると、PowerState がアクティブに設定された SSDP アライブ メッセージを送信します。低電力デバイスには、キープアライブ メッセージでアクティブに設定された PowerState オプション ヘッダーが含まれています。
• •低電力デバイスがトランスペアレント状態に移行すると、PowerState がトランスペアレントに設定された SSDP アライブ メッセージが送信され、低電力デバイスがトランスペアレント状態の場合は、PowerState がトランスペアレントに設定された定期的な SSDP アナウンスも送信されます。
• •低電力デバイスがディープ スリープ オンラインまたはディープ スリープ オフライン状態に移行すると、デバイスの対応する電源状態 (つまり、PowerState がディープ スリープ オンラインまたはディープ スリープ オフラインに設定) を含む SSDP byebye メッセージを送信します。
• •デバイスが切断、オンラインのディープ スリープ、またはオフラインのディープ スリープからよりアクティブな状態に移行する場合、最初にアクティブな状態に移行する必要があります。非アクティブな状態に段階的に移行することができます (例: アクティブからトランスペアレント スリープ、トランスペアレント スリープからオンライン ディープ スリープ、オンライン ディープ スリープからオフライン ディープ スリープ、またはオフラインからディープ スリープ)デバイスは、非アクティブ状態に移行するときに状態をバイパスすることもあります。
• •デバイスがどの状態からでも切断状態に移行するときは、低電力拡張ヘッダーなしで byebye メッセージを送信する必要があります。

M-Search を受信すると、アクティブ状態またはトランスペアレント状態の低電力デバイスは、デバイスの対応する PowerState で応答します。低電力デバイスがディープ スリープ オンライン状態にある場合、低電力デバイスは wakeup() アクションにのみ応答します。

デバイスがアクティブまたはトランスペアレント状態にある場合、デバイスは通常の SSDP アライブ メッセージを送信し、デバイス アーキテクチャで定義されているすべての検索に応答します。デバイスがディープ スリープ オンライン状態にある場合、アクティブ状態に移行する前にキープアライブ メッセージは送信されません。ディープ スリープ オフライン状態では、デバイスは通信できず、帯域外の方法でのみウェイクアップできます。デバイスは、低電力 SSDP 拡張ヘッダーでアドバタイズされたスリープ期間が終了する前にウェイクアップし、プロキシまたはコントロール ポイントを使用して UPnP 状態を更新する必要があります。

2 Service Modeling Definitions

2.2 State Variables

Reader Note: For first-time reader, it may be more insightful to read the actiondefinition (follow link to Table 3) before reading the state variable definitions.

The"regular" state variables represent some actual, persistent state of the device's service.

The A_ARG_TYPE state variables are associated with temporary values only valid for the duration of the action. These state variables are used in arguments that do not directly relate to a specific state variable.

2.2.2 BatteryLow

This variable is used to indicate when battery charge is low. The type of this variable is Boolean and vendors may select desired charge level to set this variable to true state or to false state, respectively..

This is an optional variable of Boolean type. The Default value is"0" indicating that battery charge is not low.

2.2.3 ExternalPowerSupplySource

This variable indicates whether external or internal power source is in use. This is intended for eventing changes on power supply status.

This is an optional variable of ui1 type. Values are 1 for AC power, and 0 for internal power source

2.2.4 WakeupMethod

This variable includes the wake up methods supported by the device for the specific bearer on which the action was received. This is required variable of type of XML document

This variable is described by schema identified by"urn: schema-upnp-org:lp:wakeupmethod"; and it is located at: http://www.upnp.org/schemas/lp/WakeupMethod.xsd . The elements are:

• • BearerWakeupMethod: Unique element per wake up method
  • • IanaTechnologyType is an integer that indicates media interface type, such as 802.3 (value=6) or 802.11 (value=71). The allowed integer values for this parameter are specified in the IANA reference ifType-MIB < http://www.iana.org/assignments/ianaiftype-mib >.
  • • WakeUpPattern has to be transmitted to wake up the device as specified by the specific Wakeup method. The type is string and it is dependent on the system used and exact format is not defined by UPnP forum.
  • • AdditionalBearerInfo allows vendors to add MAC address of the device. This is a string format, but it should follow the address type defined by the bearer. For instance, 802 address types are used in 802 network. A vendor may also add additional information in string format, for instance, the name of the interface (e.g.MAC address, BTH Address).

• • NonBearerWakeupMethod includes two string type elements (e.g. Infrared remote control):

  • • BearerType is enumerated list that can be extended with new bearers. Currently two methods have been defined:"NFC", and"Infrared"
  • • VendorNonBearerInfo is of type string defining the vendor of this bearer

2.2.5 PowerSupplyStatus

This required variable is described by schema identified by"urn: schema-upnporg:lp:powersupplystatus" ; and it is located at http://www.upnp.org/schemas/lp/PowerSupplyStatus.xsd . It includes the following fields:

• • ExternalPowerSupply
  • • ExternalPowerSupplySource is of type string including vendor defined information for external power source, for instance," mains"
  • • IsConnected is of type Boolean and values used are"1" indicating connected state, 0 for unconnected state

• • InternalPowerSupply

  • • The remaining power status in terms of percentage (value range 0-100)
  • • The remaining time that battery lasts (The value should be in format of PxxDTyyHzzM ここで, xx is days (0-99) , yy is hours (0-24), and zz is minutes (0-60). See details from 0

2.2.6 SleepPeriod

This required variable includes duration that the device is going to be in sleep state. The type of this variable is ui4.

2.2.7 PowerState

This required variable provides the power state information of the device. This variable is used in"GoToSleep" action. Low power aware Control Point can define the sleeping PowerState that the device should transition to. Since the sleeping device can have three sleeping power states, i.e., Transparent, Deep Sleep Online, Deep Sleep Offline, PowerState=1 is used to define Transparent state, PowerState=2 defines Deep Sleep Online, and PowerState=4 stands for Deep Sleep Offline. The type of this variable is string and service description document must have updated list of supported powerstates in allowedvaluelist attribute. The device can transition into only one of the power states, therefore a combination of power states is not allowed. See states description from Table 1.

2.2.8 Low power SSDP extensions

The low power device has to include a set of new SSDP headers to communicate the power state changes.

2.3 Eventing and Moderation

UPnP low power device provides two evented variables (Table 5) that can be used to advertise current power source status. BatteryLow is intended for battery powered device to send warning messages to control points stating that the device is operating on a low battery. The ExternalPowerSupplySource is intended to send events when the device's power is switched between main power (AC) and battery power (DC). Vendors may tune event rates from maximum to 1 event per minute if so desired.

2.4 Generic LP-aware control point recommendations

Control points may cache power management information of all low power devices in the network. Especially, if the LP-aware control point vendor does not want to rely on the presence of Basic power management proxies.

If Basic Power Management Proxy is present, LP-aware control point should fetch the list of sleeping devices from the proxy during the discovery process.

If a low power aware control point can perform out-of-band wake-up provided by the device, the control point should wake the low power device directly.

If no caching proxies are available in the network, LP-aware control point should stay active to maintain list of sleeping devices.

LP-aware Control point must support low power SSDP extension headers. .

If a low power device does not respond to M-Search or UPnP action, the control point should assume that device is in disconnected state. However, the device may be in deep sleep offline state and the LP-aware control point may try to wake up the device several times. After several unsuccessful wake up attempts, the LP-aware control point should assume that device is not available and the UPnP Low Power device should be considered to be in the disconnected state.

If a low power device is in deep sleep online or deep sleep offline state, the control point should not remove it from cache before the low power device's sleep period has expired. If wakeup command fails, then control point should consider device disconnected (some additional wait time should be added). This is necessary as a low power device in deep sleep online or deep sleep offline does not send SSDP keep alive messages.

2.5 Actions

Table 6 presents actions that are later presented in detail followed by detailed information about actions, including short descriptions of the actions, the effects of the actions on state variables, and error codes defined by the actions.

2.5.1.3 Effect on State (if any)

None.

2.5.1.4 Control point requirements

This action is used to retrieve information from the device. The control point may cache Wake-up information for later use. This information can be used to wake up device in deep sleep states in the case when Basic Power Management Proxy is not present. Naturally, devices in active or transparent states with standard keep alive messaging may be kept in cache.

2.5.1.5 Errors

Refer to UPnP Device architecture for common error codes.

2.5.2 Wakeup()

The device will provide a control action to wake up the device when it is transparent or deep sleep online state.

2.5.2.1 Dependency on State (if any)

This action can be used only in online modes

2.5.2.2 Effect on State (if any)

The power state changes after the device responds to the wake up action. When wake up action is received, the device transitions to the Active state. The sleep period should be set to 0.

2.5.2.3 Control point requirements

Control point must verify new power state of a device after wake up action. The Device has the sole control of internal power states and may not change its power state. Verification may happen either from device advertisement or directly through GetPowerManagementInfo() action.

Control point should not engage new power management action until the new state is advertised.

When a device transitions to active state, the sleep period should not be used.

2.5.2.4 Errors

Device may refuse to change into active mode. In this case it returns error 707

2.5.3 GoToSleep()

The device will provide a control action to go into sleep mode when the action is received. This action provides a recommendation to the device to go into sleep mode (i.e. Transparent, deep sleep online or offline)

2.5.3.2 Dependency on State (if any)

2.5.3.3 Effect on State (if any)

The power state changes when the device responds to the action with the recommended power state change.

2.5.3.4 Control point requirements

Figure 1 presents allowed state transitions for a low power device. A low power device retains in allowed state transitions and may decline to transition to some state either by violating transitions defined in figure one or due internal reasons

Control point should gracefully handle situation when certain power state or transition is not implemented.

2.5.3.5 Errors

Refer to UPnP Device architecture for common error codes.

2.6 Theory of Operation

The Low Power Device Control Protocol provides actions for control points to query and manage low-power devices. The device must implement the required SSDP low power extension headers and should conform to the low power state machine, described in Figure 3, when transitioning between power states.

2.6.2 Low power state behavior

A low power device exhibits state behavior to UPnP network by advertising its low power states. Device vendors may implement internal behavior in various ways and decide how the low power states are actually implemented. Regardless of implementation specific variations, the implementations must follow responsiveness requirements given in this specification. The low power device state transitions is presented in Figure 1. Notice that in Figure 1 some of the transitions are caused by an internal action of the device and these transitions cannot be invoked by the control points or other external entities. The following state specific behavior is required:

• • Active: In the Active state the UPnP Low Power device is on the network and is visible to other UPnP devices in the network. The device in Active state responds to M-search requests. The device in Active state sends out regular SSDP: Alive messages.
• • Transparent: In the Transparent state the UPnP Low Power device is in online and visible to other UPnP Low Power devices. The device in Transparent state responds to M-search requests and can be woken up to the Active state by invoking the Wakeup() control action. The device in Transparent state sends out regular SSDP: Alive messages.
• • Deep Sleep Online: A device in Deep Sleep Online is on the network but will not respond to any UPnP control actions except for the Wakeup() control action because the UPnP stack in Deep Sleep Online is partially online. A device in Deep Sleep Online will not respond to an M-search request and will not send any SSDP: Alive messages. A device in this state can be woken up by invoking the Wakeup() control action.
• • Deep Sleep Offline: A device in Deep Sleep Offline will not be on the network and thus will not be visible to other devices on the network. A device in Deep Sleep Offline will not respond to an M-search request and will not send any SSDP: Alive messages. A device in this state can be woken up by out of band bearer dependent wake up mechanisms.
• • Disconnect: A device in Disconnect state is shutdown or is in the OFF state. A device in this state can be woken using vendor defined methods.

Figure below shows a transition diagram for the various sleep states and the triggers that cause state transitions.

The transitions are explained in the following table. In the last column, internal triggers are the triggers generated by a sleeping device, such as a device's decision to switch to power save mode, to leave the network or to wake up after a timeout value. Conversely, external triggers are the triggers generated by Low Power Aware Control Points or Basic Power Management Proxies, such as a request for the device to enter a sleep mode or to wake up. In addition, the case of network failures is not included as a trigger because it is a generic problem for all the power states. In ActiveorTransparent sleep state, an unexpected disconnection can be detected by the absence of periodic advertisements. In deep sleep state, Control Points can infer that an unexpected disconnection occurred from an overdue sleep period timeout or when a control point fails to wake the Low Power device.