UPnP protocol learning notes-Overview

[What is UPnP technology ?]

 

The UPnP (Universal Plug and Play) technology is an architecture designed to connect Smart appliances, wireless devices, and various types of personal computers over P2P networks. It is designed to be an easy-to-use, flexible, and standard-based connection to families, small businesses, and public places connected to ad-hoc or unmanaged networks. UPnP is a Distributed Open Network Architecture Based on TCP/IP and network technologies. It not only provides control and data transmission between network devices, but also provides seamless network connections.

The UPnP Device architecture (UDA) is not just a simple extension of the plug-and-play peripheral device model, it is designed to provide Zero Configuration, "invisible" network connection, and automatic discovery for different device types of many vendors. This means that the device can automatically join the network, obtain the IP address, broadcast its capabilities, and learn the existence and capabilities of other devices. Finally, the device can automatically leave the network without any unexpected impact.

The UPnP architecture makes full use of network protocols including IP, TCP, UDP, HTTP, XML, and so on. Similar to the Internet, the UPnP protocol is expressed in XML based on the expressive online protocol, and transmission over HTTP. With its proven capabilities, ipprotocol becomes a powerful choice for the UPnP Device architecture. These capabilities include: it spans different physical media, supports multi-vendor interaction, supports the internet, and supports collaboration between numerous home and enterprise intranets. The UPnP architecture is clearly designed to adapt to these different environments. Further, through bridging, UDA is also suitable for running non-IP protocols, these media are often unable to run the IP Protocol due to cost, technology, or system issues.

The "universal" in UPnP is mainly reflected in:

1) do not use a device driver, instead of using a universal protocol;

2) The UPnP network is media-independent;

3) The UPnP Device can be implemented in any programming language on any operating system;

4) The UPnP architecture does not specify or restrict the design of APIs used by applications;

5) operating system vendors can create APIs that meet customers' needs.

 

[UPnP protocol stack]

 

The UPnP Architecture defines two types of devices: controlled devices and control points ). The control device plays the role of the server and responds to the request from the control point. Control Points and control devices can be implemented on various platforms, including PCs and embedded devices. Multiple control devices and control points can be simultaneously operated on the same network terminal.

 

1) IP addressing)

The foundation of UPnP network interconnection is IP Addressing. In an IPv4 environment, each control device or control point must have a DHCP (Dynamic Host Configuration Protocol) client, and find a DHCP server when connecting to the network for the first time. If a DHCP server exists in the network, such as a hosted network, the control device or control point must use the IP address assigned by the DHCP server; if the DHCP server is unavailable, such as an unmanaged network, the control device or control point must use auto IP to obtain the IP address. To put it simply, auto IP defines the control device or control point. If you intelligently select an IP address from the reserved IP address set, and smoothly move it in a hosted or unmanaged network. If the control device or control point can obtain the domain name through the DNS server or DNS forwarding in a DHCP transaction, the control device or control point should use this domain name in subsequent network operations; otherwise, the control device or control point should directly use the IP address.

Some UPnP networks require more complex configurations to adapt to multiple non-overlapping addressing schemes, such as multiple physical networks and multiple logical networks. The control device or control point may have two or more network interfaces, and each network interface may have two or more IP addresses. In this configuration, because different logical networks exist in the same UPnP network, a single control device or control point may be allocated to multiple IP addresses, this causes the control point to repeatedly search for the same control device. In the same UPnP network, control devices or control points with multiple IP addresses are called multi-homed ).

 

2) discovery)

In the UPnP network, after obtaining an IP address, the next step is to find it. However, when the control device is added to the network, the UPnP Discovery Protocol allows the control device to advertise the services it provides to the control point in the network. Similarly, when the control point is added to the network, the UPnP Detection protocol allows the control point to search for control devices of interest in the network. In the above two cases, the basic information exchanged between the device and the control point is a "discover message", which contains some basic information about a service provided by the device or the device, for example, type, identifier, and pointer to detailed information.

 

3) Description)

After the control point discovers the control device, the control point still knows little about the control device. To learn more about the control device and its capabilities, and interact with the control device, the control point needs to obtain the description of the URL pointed to by the control device in the "discover message. The control device may contain other logical control devices, functional units, and services. The UPnP Device description is based on the XML language and contains manufacturer-related manufacturing information, such as model name and number, serial number, manufacturer name, and URL link of manufacturer-related URLs. The description also includes a list of any embedded devices or services, URLs for control, event triggering, and display. For each service, the "Description" includes a list of commands, service response actions, and parameters for each action. The service description also contains a column of variables that model the status of the Service at runtime and describe it through data types, ranges, and event features.

 

4) Control)

After obtaining the description of the control device, the control point can send actions to the service of the device. This is achieved by sending the correct "Control Message" to the control URL of the service (provided in the device description. The control message is also expressed based on the XML protocol and transmitted using the Simple Object Access Protocol. Similar to a function call, the service returns a response message to an action. You can describe the effect of an action by describing the variable of the Service running status.

 

5) event triggering)

The UPnP service description contains a list of service response actions and a list of variables that are displayed during service running. When these variables change, the service will publish updates. The control point can subscribe to and receive these messages. The Service publishes updates by sending event messages. The event message contains the names of one or more state variables and the current values of these variables. Event messages are also expressed in XML. When the control point is subscribed for the first time, a special initialization event message is sent. The message contains the names and values of all event variables and allows the subscriber to initialize the service status mode. To support multiple control points, event triggering is designed to notify all control points of the effects of any action. Therefore, all subscribers receive all event messages. The subscriber receives an event message for all event variables that have changed. This event message is sent regardless of the status variable if it has changed (because it responds to an action or because of service model status changes ).

 

6) Representation)

If the control device provides a URL for display, the control point can display the page content in the browser through the URL. Based on the page capabilities, you can control the device and view the device status. The degree to which each item is completed depends on the display page and the specific capabilities of the device.

 

[Abbreviation]

 

[Terminology]

1) Action: The command interface exposed by the Service. Action has one or more input and output parameters and can return values;

2) argument: the parameter of action, which can be an input parameter or an output parameter;

3) control point: Used to get the description of device and service, send actions to services, pull status variables from service, and receive events from services;

4) device: a logical device, as a container, can be nested with other logical devices, and its own existence can be advertised to the network;

5) device Description: The formal definition of the logical device. It is described in UPnP template language based on XML syntax. The description is provided by the UPnP vendor. information such as the vendor name, model name, model number, serial number, control, event, and displayed URL is filled in the UPnP Device template;

6) device type: the standard device type is shown as follows: urn: Schemas-UPnP-org: device: the unique identifier assigned by the UPnP Forum Working Committee. The relationship between the device type and the UPnP Device template is one-to-one. The UPnP vendor can specify the additional device type, which is defined as urn: domain-name: device: the unique identifier assigned by the vendor, specifically, domain-name is the vendor's domain name;

7) event: the notification sent when the state variable exposed by the service changes;

8) Gena: General eventnotification architecture;

9) Publisher: the source of the event message, a typical device service;

10) root device: no logical device is nested in any other logical device, that is, the top-level logical device;

11) Service: logical function unit, minimum control unit. Service exposes actions and uses state variables to model the status of physical devices;

12) Service Description: The formal definition of the logical service. It is described in the UPnP template language based on the XML syntax. The UPnP vendor fills in the specified information in the UPnP service template;

13) service type: standard service type: urn: Schemas-UPnP-org: Service: Unique identifier assigned by the UPnP Forum Working Committee: version number of the integer type. The service type and UPnP service template are one-to-one relationships. The UPnP vendor can specify additional services. The definition is as follows: urn: domain-name: Service: Unique identifier assigned by the vendor: version number, specifically, domain-name is the manufacturer's domain name;

14) soap: Simple Object Access Protocol, an XML-based Remote Call mechanism that sends commands over HTTP and receives returned values;

15) SSDP: simple device Discovery protocol. It uses UDP-based HTTP multicast variants to implement multicast discovery and search;

16) state variable: a section of the physical service model, which is exposed by the Service. state variable has a name, data type, optional default value, and optional constant value, in addition, an event can be triggered when its value changes;

17) Subscriber: the receiver of the event message, a typical control point;

18) UPnP Device template: A device template that includes the device type, embedded devices, and services. Based on the XML syntax and inherited from the UPnP Device mode, which is defined by the UPnP Forum Working Committee and has a one-to-one relationship with the standard device type;

19) UPnP service template: a service template that contains the action name, parameters required by the action, statevariables, and the properties of these state variable. Based on the XML syntax and inherited from the UPnP Device mode, which is defined by the UPnP Forum Working Committee. There is a one-to-one relationship with standard service types;

20) UPnP Device Schema: defines the elements and attributes used in the UPnP Device and service template. It inherits the XML Schema Based on the XML syntax and is defined by the UPnP Device architecture;

21) Vendor Domain Name: The domain name provided by the vendor, owned by the vendor, and must be registered at the ICANN-certified Registrar to ensure uniqueness. The manufacturer must ensure that the registered domain name is updated immediately. The length of the Domain Name of the manufacturer must be compatible with the domain name used in UDA.