Establishing channels between a domain manager and managed nodes

A device associated with a network receives a register request from a managed node connected to the network, where the register request requests registration of the managed node. The device also establishes a command channel, for sending one or more commands, with the managed node based on the register request, and establishes a notification channel, for sending one or more notifications, with the managed node based on the register request.

TECHNICAL FIELD

Embodiments described herein relate generally to communication systems, and, more particularly, to establishing channels between a domain manager and managed nodes in a telecommunication system.

BACKGROUND

A self-organized network (SON) may provide mechanisms for self-configuration, self-discovery, and self-organization. Self-configuration and self-discovery enable network devices (e.g., managed nodes) of the SON to be transparent to ordinary users. Self-organization ensures robustness of the SON during dynamic network topology changes and link breakages. It also ensures optimal and efficient bandwidth utilization.

The SON operational and maintenance (OAM) architecture includes a domain manager and its managed nodes, an enterprise management system (EMS), etc. A managed node represents a radio base station (e.g., of a wireless network), home devices (e.g., Internet routers, television set-top boxes (STBs), etc.), etc.

Current SON OAM architectures have several disadvantages. For example, the EMS needs to track the addresses of all its managed nodes. The tracking may include registering Internet protocol (IP) addresses and/or port numbers associated with the managed nodes in a directory within or without the EMS. The tracking may also include registering managed node name and IP address/port number pairs associated with the managed nodes in a database within or without the EMS. Such tracking becomes a major task when the number of managed nodes increases and when the managed nodes become mobile (e.g., acquire new addresses). Furthermore, when the EMS wishes to provide a command and/or information to all its managed nodes, the EMS sends the command and/or information, via the domain manager, individually to each managed node (e.g., one method invocation per each managed node).

SUMMARY

It is an object of the invention to overcome at least some of the above disadvantages and to establish channels between a domain manager and managed nodes installed in a telecommunication system such that an EMS may send one command and/or information to the domain manager and the domain manager may duplicate the command and/or information and distribute the command and/or information to the managed nodes.

Embodiments described herein may include systems and/or methods that establish channels (e.g., command channels, notification channels, etc.) between a domain manager and its managed nodes so that the domain manager may send commands and/or information to the managed nodes. For example, in one embodiment, the systems and/or methods may include a managed network (e.g., a SON) that includes a domain manager for managing one or more managed nodes and/or links. When a managed node is installed in the managed network, the managed node may register itself with the domain manager. The managed node, via the registration, may identify itself to the domain manager, and may advise the domain manager about the managed node's security related parameters, its presence in the managed network, and the managed node's current operational state (e.g., disabled, enabled, etc.). The registration may also identify the managed node's notification channel address via which the managed node may receive future notifications from the domain manager, and the managed node's command channel address via which the managed node may receive future commands from the domain manager.

In an exemplary embodiment, systems and/or methods described herein may receive register request(s) from managed node(s), and may determine managed node information based on the register request(s). The systems and/or methods may establish command channel(s) with the managed node(s) based on the register request(s), and may simultaneously send a command to the managed node(s) via the command channel(s). The systems and/or methods may also establish notification channel(s) with the managed node(s) for sending notification(s), and may simultaneously send a notification to the managed node(s) via the notification channel(s). The systems and/or methods may further receive cancel registration request(s) from the managed node(s), and may receive registration status request(s) from the managed node(s).

DETAILED DESCRIPTION

Embodiments described herein may include systems and/or methods that establish channels (e.g., command channels and/or notification channels) between a domain manager and managed nodes so that the domain manager may not need to track addresses of the managed nodes and may communicate information to the managed nodes via the established channels.

FIG. 1depicts a diagram of an exemplary network100in which systems and/or methods described herein may be implemented. As illustrated, network100may include a domain manager110and managed nodes120interconnected by a network130. Domain manager110and managed nodes120may connect to network130via wired and/or wireless connections. A single domain manager, three managed nodes, and a single network have been illustrated inFIG. 1for simplicity. In practice, there may be more domain managers, managed nodes, and/or networks. Also, in some instances, a component in network100(e.g., one or more of domain manager110and/or managed nodes120) may perform one or more functions described as being performed by another component or group of components in network100.

Domain manager110may include one or more server entities, or other types of computation or communication devices, that gather, process, search, and/or provide information in a manner described herein. For example, domain manager110may include a computer, a proxy server, a computer system (e.g., an operational and maintenance (OAM) system, a network management system, an enterprise management system, etc.), another type of computation or communication device, a thread or process running on one of these devices, and/or an object executable by one of these devices. In one embodiment, domain manager110may monitor and manage network elements (e.g., managed nodes120), may establish channels with managed nodes120, and may communicate information to managed nodes120via the established channels.

Each of managed nodes120may include any device capable of receiving traffic associated with network100, and capable of being monitored and/or managed by domain manager110. For example, each of managed nodes120may include a computer, a router, a switch, a network interface card (NIC), a hub, a bridge, a gateway, a firewall, an optical add-drop multiplexer (OADM), a cell phone, a radio base station, a television set-top box (STB), some other type of device that processes and/or transfers traffic, another type of computation or communication device, a thread or process running on one of these devices, and/or an object executable by one of these devices. In one embodiment, each of managed nodes120may include a node of a telecommunication network.

The term “traffic,” as used herein, is to be broadly construed to include any information capable of being provided and/or received by network100and/or any component of network100(e.g., managed nodes120), such as information associated with operation, administration, maintenance, provisioning, etc. of telecommunication systems, commands issued by domain manager110, notifications issued by domain manager110, etc.

Network130may include a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), an intranet, the Internet, a Public Land Mobile Network (PLMN), a telephone network, such as the Public Switched Telephone Network (PSTN) or a cellular telephone network, or a combination of networks. In one exemplary embodiment, network130may include a self-organized network (SON), a SON-based telecommunication network, a telecommunication network, etc.

FIG. 2Ais an exemplary diagram of a device that may correspond to domain manager110. As illustrated, domain manager110may include a bus200, processing logic205, a main memory210, a read-only memory (ROM)215, a storage device220, an input device225, an output device230, and/or a communication interface235. Bus200may include a path that permits communication among the components of domain manager110.

Processing logic205may include a processor, microprocessor, or other type of processing logic that may interpret and execute instructions. Main memory210may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processing logic205. ROM215may include a ROM device or another type of static storage device that may store static information and/or instructions for use by processing logic205. Storage device220may include a magnetic and/or optical recording medium and its corresponding drive.

Input device225may include a mechanism that permits an operator to input information to domain manager110, such as a keyboard, a mouse, a pen, a microphone, voice recognition and/or biometric mechanisms, etc. Output device230may include a mechanism that outputs information to the operator, including a display, a printer, a speaker, etc. Communication interface235may include any transceiver-like mechanism that enables domain manager110to communicate with other devices and/or systems. For example, communication interface235may include mechanisms for communicating with another device or system via a network, such as network130.

As described herein, domain manager110may perform certain operations in response to processing logic205executing software instructions contained in a computer-readable medium, such as main memory210. A computer-readable medium may be defined as a physical or logical memory device. The software instructions may be read into main memory210from another computer-readable medium, such as storage device220, or from another device via communication interface235. The software instructions contained in main memory210may cause processing logic205to perform processes described herein. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

AlthoughFIG. 2Ashows exemplary components of domain manager110, in other implementations, domain manager110may contain fewer, different, or additional components than depicted inFIG. 2A. In still other implementations, one or more components of domain manager110may perform one or more tasks described as being performed by one or more other components of domain manager110.

FIG. 2Bis an exemplary diagram of a device that may correspond to one of managed nodes120. As illustrated, managed node120may include processing logic240, memory245, a communication interface250, and/or an antenna assembly255.

Processing logic240may include a processor, microprocessor, an application specific integrated circuit (ASIC), field programmable gate array (FPGA), or the like. Processing logic240may control operation of managed node120and its components.

Memory245may include a random access memory (RAM), a read only memory (ROM), and/or another type of memory to store data and instructions that may be used by processing logic240.

Communication interface250may include any transceiver-like mechanism that enables managed node120to communicate with other devices and/or systems. Communication interface250may include, for example, a transmitter that may convert baseband signals from processing logic240to radio frequency (RF) signals and/or a receiver that may convert RF signals to baseband signals. Alternatively, communication interface250may include a transceiver to perform functions of both a transmitter and a receiver. Communication interface250may connect to antenna assembly255for transmission and/or reception of the RF signals.

Antenna assembly255may include one or more antennas to transmit and/or receive signals (e.g. RF signals) over the air. Antenna assembly255may, for example, receive RF signals from communication interface250and transmit them over the air and receive RF signals over the air and provide them to communication interface250. In one exemplary embodiment, for example, communication interface250may communicate via a network (e.g., network130). Alternatively and/or additionally, antenna assembly255may be omitted and communication interface250may communicate with a network (e.g., network100) via one or more physical links.

As described herein, managed node120may perform certain operations in response to processing logic240executing software instructions contained in a computer-readable medium, such as memory245. A computer-readable medium may be defined as a physical or logical memory device. The software instructions may be read into memory245from another computer-readable medium or from another device via communication interface250. The software instructions contained in memory245may cause processing logic240to perform processes described herein. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, embodiments described herein are not limited to any specific combination of hardware circuitry and software.

AlthoughFIG. 2Bshows exemplary components of managed node120, in other embodiments, managed node120may contain fewer, different, or additional components than depicted inFIG. 2B. In still other embodiments, one or more components of managed node120may perform one or more tasks described as being performed by one or more other components of managed node120.

FIG. 3depicts a diagram of an exemplary portion300of network100and exemplary interactions among components of network portion300. As illustrated, network portion300may include domain manager110and one of managed nodes120. Domain manager110and managed node120may include the features described above in connection with, for example,FIG. 1.

As shown inFIG. 3, managed node120may provide a register request310to domain manager110. Domain manager110may receive register request310, may determine information associated with managed node120based on register request310, and may use the information from register request310to perform a registration operation for managed node120. For example, register request310may advise domain manager110that managed node120is connected to the network (e.g., network100) and is prepared to receive command(s) and/or notification(s) from domain manager110. Register request310may include information identifying managed node120to domain manager110, security related information (e.g., authentication information) associated with managed node120, information identifying managed node's120presence in the network, and information associated with an operational state (e.g., disabled, enabled, etc.) of managed node120. Register request310may also identify a notification channel address via which managed node120may receive future notifications from domain manager110, and a command channel address via which managed node120may receive future commands from the domain manager110. In one embodiment, domain manager110may establish a notification channel with managed node120based on the notification channel address identified by register request310. In another embodiment, domain manager110may establish a command channel with managed node120based on the command channel address identified by register request310. Further details of register request310are provided below in connection with, for example,FIG. 4.

Domain manager110may identify, register, establish channels with, etc. managed node120based on register request310. In one embodiment, domain manager110may store (e.g., in storage device220) register request310and its associated information. Domain manager110may provide, based on register request320, a register status operation instruction320to managed node120, and managed node120may receive register status operation instruction320. Register status operation instruction320may include information identifying the registration of managed node120(e.g., by domain manager110), information providing a result (e.g., success, failure, etc.) associated with the registration, etc. Further details of register status operation instruction320are provided below in connection with, for example,FIG. 5.

Domain manager110may provide one or more commands330to managed node120, and managed node120may receive one or more commands330. In one embodiment, domain manager110may provide one or more commands330to managed node120via the command channel established based on register request310(e.g., via the command channel address). One or more commands330may include information instructing managed node120to perform specific functions (e.g., enter into a disabled operational state so that managed node may not transfer traffic).

As further shown inFIG. 3, domain manager110may provide a notify operation instruction340to managed node120, and managed node120may receive notify operation instruction340. In one embodiment, domain manager110may provide notify operation instruction340to managed node120via the notification channel established based on register request310. Notify operation instruction340may include information identifying domain manager110issuing notify operation instruction340, a common message, notification, announcement, and/or instruction broadcast to all (or some group of) registered managed nodes (e.g., managed node120), etc. In one example, notify operation instruction340may include an announcement that a new software version is available for managed node120to download. Such an announcement may include, for example, information associated with an address of a software server, a software module name, a version number, an availability time, etc. In other examples, notify operation instruction340may include an announcement that managed node120should enter a certain operational state, an announcement related to advertisement messages (e.g., if managed node120is a STB), etc. Further details of notify operation instruction340are provided below in connection with, for example,FIG. 6.

Managed node120may provide a cancel request350to domain manager110, and domain manager110may receive cancel request350. Cancel request350may request that domain manager110cancel registration of managed node120. Cancel request350may include information identifying managed node120, information identifying a registration associated with managed node120, etc. Further details of cancel request350are provided below in connection with, for example,FIG. 7. Domain manager110may provide, based on cancel request350, a cancel status operation instruction360to managed node120, and managed node120may receive cancel status operation instruction360. Cancel status operation instruction360may include information providing a result (e.g., success, failure, etc.) of the registration cancellation requested by cancel request350, etc. Further details of cancel status operation instruction360are provided below in connection with, for example,FIG. 8.

As further shown inFIG. 3, managed node120may provide a registration status request370to domain manager110, and domain manager110may receive registration status request370. Registration status request370may request registration information (e.g., associated with managed node120) stored in domain manager110(e.g., in storage device220). Registration status request370may include information identifying managed node120, information identifying a registration associated with managed node120, etc. Further details of registration status request370are provided below in connection with, for example,FIG. 9. Domain manager110may provide, based on registration status request370, a registration status operation instruction380to managed node120, and managed node120may receive registration status operation instruction380. Registration status operation instruction380may include information regarding a status (e.g., unknown, active, inactive, etc.) of a registration associated with managed node120, etc. Further details of registration status operation instruction380are provided below in connection with, for example,FIG. 10.

AlthoughFIG. 3shows exemplary components of network portion300, in other embodiments, network portion300may contain fewer, different, or additional components than depicted inFIG. 3. In still other embodiments, one or more components of network portion300may perform one or more tasks described as being performed by one or more other components of network portion300.

FIG. 4illustrates a diagram of exemplary elements of register request310. In one embodiment, register request310may be provided by a managed device (e.g., one of managed nodes120). In another embodiment, register request310may be provided by a managed device (e.g., other managed nodes) other than or in addition to one of managed nodes120. As illustrated, register request310may include a managed node identifier parameter400, a security parameter410, a timer parameter420, an environment parameter430, a command channel address parameter440, a notification channel address parameter450, and/or an other information parameter460.

Managed node identifier parameter400may include information that identifies a managed node (e.g., one of managed nodes120) providing register request310. For example, in one embodiment, managed node identifier parameter400may include identification information (e.g., an address) associated with one of managed nodes120.

Security parameter410may include security information associated with a managed node (e.g., one of managed nodes120) providing register request310. For example, in one embodiment, security parameter410may include authentication information (e.g., a password, an address, etc.) associated with one of managed nodes120.

Timer parameter420may include a value of a timer associated with a managed node (e.g., one of managed nodes120) providing register request310. For example, in one embodiment, the value may be provided in seconds, minutes, hours, etc., and may assume a special infinite value when timer parameter420is absent or equal to zero. When the value goes to zero, domain manager110may consider one of managed nodes120to be disabled, and may terminate a registration associated with one of managed nodes120(e.g., may release resources supporting the registration).

Environment parameter430may include information associated with a security setting, a name and/or version number of a control program, etc. associated with a managed node (e.g., one of managed nodes120) providing register request310.

Command channel address parameter440may include information associated with an address to establish a command channel to a managed node (e.g., one of managed nodes120) providing register request310. In one embodiment, domain manager110may establish the command channel based on command channel address parameter440, and may provide commands, operations, instructions, etc. to the address (e.g., via the command channel).

Notification channel address parameter450may include information associated with an address used to establish a notification channel to a managed node (e.g., one of managed nodes120) providing register request310. In one embodiment, domain manager110may establish the notification channel based on notification channel address parameter450, and may provide notifications to the address (e.g., via the notification channel).

Other information parameter460may include other information (e.g., a manufacturer name, a model type, etc.) associated with a managed node (e.g., one of managed nodes120) providing register request310.

In one exemplary embodiment, register request310may include the following format: register(nodeId, security, timeTick, environment, commandChannelAddress, notifyChannelAddress, otherInfo), where nodeId may correspond to managed node identifier parameter400, security may correspond to security parameter410, timeTick may correspond to timer parameter420, environment may correspond to environment parameter430, commandChannelAddress may correspond to command channel address parameter440, notifyChannelAddress may correspond to notification channel address parameter450, and otherInfo may correspond to other information parameter460.

AlthoughFIG. 4shows exemplary elements of register request310, in other embodiments, register request310may contain fewer, different, or additional elements than depicted inFIG. 4.

FIG. 5depicts a diagram of exemplary elements of register status operation instruction320. In one embodiment, register status operation instruction320may be provided by a managing device (e.g., domain manager110). In another embodiment, register status operation instruction320may be provided by a managing device (e.g., other domain managers) other than or in addition to domain manager110. As illustrated, register status operation instruction320may include a registration identifier parameter500and/or a registration status parameter510.

Registration identifier parameter500may include information that identifies a registration associated with a managed node (e.g., one of managed nodes120) providing register request310. For example, in one embodiment, registration identifier parameter500may include identification information (e.g., one or more names, one or more numbers, etc.) of a registration associated with managed node120. In one exemplary embodiment, registration identifier parameter500may include a specific format (e.g., registrationId).

Registration status parameter510may include information that identifies results (e.g., successful, unsuccessful, etc.) of a registration associated with a managed node (e.g., one of managed nodes120) providing register request310. In one example, the identification information may be created by domain manager110upon receipt of register request310. In one exemplary embodiment, registration status parameter510may include a specific format (e.g., Status).

AlthoughFIG. 5shows exemplary elements of register status operation instruction320, in other embodiments, register status operation instruction320may contain different or additional elements than depicted inFIG. 5.

FIG. 6illustrates a diagram of exemplary elements of notify operation instruction340. In one embodiment, notify operation instruction340may be provided by a managing device (e.g., domain manager110). In another embodiment, notify operation instruction340may be provided by a managing device (e.g., other domain managers) other than or in addition to domain manager110. As illustrated, notify operation instruction340may include a domain manager identifier parameter600and/or a data parameter610.

Domain manager identifier parameter600may include information that identifies a managing device (e.g., domain manager110) providing notify operation instruction340. For example, in one embodiment, domain manager identifier parameter600may include information (e.g., a name, an identification, a number, an address, etc.) identifying domain manager110as the device providing notify operation instruction340.

Data parameter610may include messages, instructions, announcements, etc. provided by a managing device (e.g., domain manager110) providing notify operation instruction340. For example, in one embodiment, data parameter610may include an announcement regarding a new software download (e.g., for managed nodes120), an announcement that managed nodes120should enter a certain operational state, mass advertisement messages, etc.

In one exemplary embodiment, notify operation instruction340may include the following format: notify(dmId, Data), where dmId may correspond to domain manager identifier parameter600, and Data may correspond to data parameter610.

AlthoughFIG. 6shows exemplary elements of notify operation instruction340, in other embodiments, notify operation instruction340may contain fewer, different, or additional elements than depicted inFIG. 6.

FIG. 7depicts a diagram of exemplary elements of cancel request350. In one embodiment, cancel request350may be provided by a managed device (e.g., one of managed nodes120). In another embodiment, cancel request350may be provided by a managed device (e.g., other managed nodes) other than or in addition to one of managed nodes120. As illustrated, cancel request350may include a managed node identifier parameter700and/or a registration identifier parameter710.

Managed node identifier parameter700may include information that identifies a managed node (e.g., one of managed nodes120) providing cancel request350. For example, in one embodiment, managed node identifier parameter700may include identification information (e.g., an address) associated with one of managed nodes120.

Registration identifier parameter710may include information that identifies a registration (e.g., to be canceled) that is associated with a managed node (e.g., one of managed nodes120) providing cancel request350. For example, in one embodiment, registration identifier parameter710may include identification information (e.g., one or more names, one or more numbers, etc.) of a registration associated with managed node120. Managed node120may obtain such identification information from, for example, register status operation instruction320.

In one exemplary embodiment, cancel request350may include the following format: cancel(nodeId, registrationId), where nodeId may correspond to managed node identifier parameter700, and registrationId may correspond to registration identifier parameter710.

AlthoughFIG. 7shows exemplary elements of cancel request350, in other embodiments, cancel request350may contain fewer, different, or additional elements than depicted inFIG. 7.

FIG. 8illustrates a diagram of an exemplary element of cancel status operation instruction360. In one embodiment, cancel status operation instruction360may be provided by a managing device (e.g., domain manager110). In another embodiment, cancel status operation instruction360may be provided by a managing device (e.g., other domain managers) other than or in addition to domain manager110. As illustrated, cancel status operation instruction360may include a cancellation status parameter800.

Cancellation status parameter800may include information that identifies results (e.g., successful, unsuccessful, etc.) of a registration cancellation associated with a managed node (e.g., one of managed nodes120) providing cancel request350. In one exemplary embodiment, cancellation status parameter800may include a specific format (e.g., Status).

AlthoughFIG. 8shows exemplary elements of cancel status operation instruction360, in other embodiments, cancel status operation instruction360may contain different or additional elements than depicted inFIG. 8. For example, cancel status operation instruction360may include a registration identifier that identifies the registration for which a cancellation status is being provided.

FIG. 9depicts a diagram of exemplary elements of registration status request370. In one embodiment, registration status request370may be provided by a managed device (e.g., one of managed nodes120). In another embodiment, registration status request370may be provided by a managed device (e.g., other managed nodes) other than or in addition to one of managed nodes120. As illustrated, registration status request370may include a managed node identifier parameter900and/or a registration identifier parameter910.

Managed node identifier parameter900may include information that identifies a managed node (e.g., one of managed nodes120) providing registration status request370. For example, in one embodiment, managed node identifier parameter900may include identification information (e.g., an address) associated with one of managed nodes120.

Registration identifier parameter910may include information that identifies a registration (e.g., whose status is sought) that is associated with a managed node (e.g., one of managed nodes120) providing registration status request370. For example, in one embodiment, registration identifier parameter910may include identification information (e.g., one or more names, one or more numbers, etc.) of a registration associated with managed node120.

In one exemplary embodiment, registration status request370may include the following format: getRegistrationStatus(nodeId, registrationId), where nodeId may correspond to managed node identifier parameter900, and registrationId may correspond to registration identifier parameter910.

AlthoughFIG. 9shows exemplary elements of registration status request370, in other embodiments, registration status request370may contain fewer, different, or additional elements than depicted inFIG. 9.

FIG. 10illustrates a diagram of an exemplary element of registration status operation instruction380. In one embodiment, registration status operation instruction380may be provided by a managing device (e.g., domain manager110). In another embodiment, registration status operation instruction380may be provided by a managing device (e.g., other domain managers) other than or in addition to domain manager110. As illustrated, registration status operation instruction380may include a registration status parameter1000.

Registration status parameter1000may include information that identifies a status (e.g., unknown, active, inactive, etc.) of a registration associated with a managed node (e.g., one of managed nodes120) providing registration status request370. In one exemplary embodiment, registration status parameter100may include a specific format (e.g., Status).

AlthoughFIG. 10shows exemplary elements of registration status operation instruction380, in other embodiments, registration status operation instruction380may contain different or additional elements than depicted inFIG. 10. For example, registration status operation instruction380may include a registration identifier that identifies the registration for which a status is being provided.

FIGS. 11-16depict flow charts of an exemplary process1100for establishing channels between domain manager110and managed nodes120according to embodiments described herein. In one embodiment, process1100may be performed by hardware and/or software components of domain manager110. In other embodiments, process1100may be performed by hardware and/or software components of domain manager110in combination with hardware and/or software components of another device or group of devices (e.g., communicating with domain manager110).

As illustrated inFIG. 11, process1100may begin with receipt of register request(s) from managed node(s) (block1110), and determination of managed node information based on the register request(s) (block1120). For example, in embodiments described above in connection withFIG. 3, domain manager110may receive register request310, and may determine information associated with managed node120based on register request310. In one example, register request310may advise domain manager110that managed node120is connected to the network and is prepared to receive command(s) and/or notification(s) from domain manager110. Register request310may include information identifying managed node120to domain manager110, security related information associated with managed node120, information identifying managed node's120presence in the network, and information associated with an operational state of managed node120. Domain manager110may store information associated with register request310(e.g., in a database provided in storage device220).

Returning toFIG. 11, command channel(s) for sending command(s) may be established with the managed node(s) based on the register request(s) (block1130), and a command may be simultaneously sent to the managed node(s) via the command channel(s) (block1140). For example, in embodiments described above in connection withFIG. 3, domain manager110may receive register request310that may identify a command channel address via which domain manager110may establish a command channel to managed node120for sending commands. Domain manager110may provide one or more commands330to managed node120via the command channel established based on register request310(e.g., via the command channel address). One or more commands330may include information instructing managed node120to perform specific functions (e.g., enter into a disabled operational state so that managed node may not transfer traffic). In one example, domain manager110may simultaneously provide one or more commands all (or some group of) managed nodes120via the command channels established between domain manager110and managed nodes120.

As further shown inFIG. 11, notification channel(s) for sending notification(s) may be established based on the register request(s) (block1150), and a notification may be simultaneously sent to the managed node(s) via the notification channel(s) (block1160). For example, in embodiments described above in connection withFIG. 3, domain manager110may receive register request310that may identify a notification channel address via which domain manager110may establish a notification channel to managed node120for sending notifications. Domain manager110may provide one or more notifications (e.g., notify operation instruction340) to managed node120via the notification channel established based on register request310(e.g., via the notification channel address). Notify operation instruction340may include information identifying domain manager110issuing notify operation instruction340, a common message, notification, announcement, and/or instruction broadcast to all (or some group of) registered managed nodes (e.g., managed node120), etc. In one example, domain manager110may simultaneously provide one or more notifications to all (or some group of) managed nodes120via the notification channels established between domain manager110and managed nodes120.

Returning toFIG. 11, cancel registration request(s) may be received from the managed node(s) (block1170), and/or registration status request(s) may be received from the managed node(s) (block1180). For example, in embodiments described above in connection withFIG. 3, managed node120may provide cancel request350to domain manager110, and domain manager110may receive cancel request350. Cancel request350may request that domain manager110cancel registration of managed node120. Managed node120may provide registration status request370to domain manager110, and domain manager110may receive registration status request370. Registration status request370may request registration information (e.g., associated with managed node120) stored in domain manager110(e.g., in storage device220).

Process block1110may include the process blocks depicted inFIG. 12. As illustrated inFIG. 12, process block1110may include one or more of receiving managed node identifier parameter(s) via the register request(s) (block1200), receiving security parameter(s) via the register request(s) (block1210), and/or receiving timer parameter(s) via the register request(s) (block1220). For example, in embodiments described above in connection withFIG. 4, register request310may be received by domain manager110, and may include managed node identifier parameter400, security parameter410, and/or timer parameter420. Managed node identifier parameter400may include identification information (e.g., an address) associated with one of managed nodes120. Security parameter410may include authentication information (e.g., a password, an address, etc.) associated with one of managed nodes120. Timer parameter420may include a value of a timer associated with a managed node (e.g., one of managed nodes120) providing register request310.

As further shown inFIG. 12, process block1110may include one or more of receiving environment parameter(s) via the register request(s) (block1230), receiving command channel address parameter(s) via the register request(s) (block1240), and/or receiving notification channel address parameter(s) via the register request(s) (block1250). For example, in embodiments described above in connection withFIG. 4, register request310may be received by domain manager110, and may include environment parameter430, command channel address parameter440, and/or a notification channel address parameter450. Environment parameter430may include information associated with a security setting, a name and/or version number of a control program, etc. associated with one of managed nodes120. Command channel address parameter440may include information associated with an address used to establish a command channel to a one of managed nodes120. Notification channel address parameter450may include information associated with an address used to establish a notification channel to one of managed nodes120.

Process block1130/1150may include the process blocks depicted inFIG. 13. As illustrated inFIG. 13, process block1130/1150may include establishing the command channel(s) based on command channel address parameter(s) provided in the register request(s) (block1300), and establishing the notification channel(s) based on notification channel address parameter(s) provided in the register request(s) (block1310). For example, in embodiments described above in connection withFIG. 4, register request310may be received by domain manager110, and may include command channel address parameter440and/or a notification channel address parameter450. Command channel address parameter440may include information associated with an address used to establish a command channel to one of managed nodes120. In one example, domain manager110may establish the command channel based on command channel address parameter440. Notification channel address parameter450may include information associated with an address used to establish a notification channel to one of managed nodes120. In one example, domain manager110may establish the notification channel based on notification channel address parameter450.

Process block1160may include the process blocks depicted inFIG. 14. As illustrated inFIG. 14, process block1160may include providing domain manager identifier parameter(s), via the notification(s), to the managed node(s) (block1400), and providing message(s) and/or instruction(s), via the notification(s), to the managed node(s) (block1410). For example, in embodiments described above in connection withFIG. 6, domain manager110may provide, to managed node120, notify operation instruction340that may include domain manager identifier parameter600and/or data parameter610. Domain manager identifier parameter600may include information that identifies a managing device (e.g., domain manager110) providing notify operation instruction340. Data parameter610may include messages, instructions, announcements, etc. provided by a managing device (e.g., domain manager110) providing notify operation instruction340. In one example, data parameter610may include an announcement regarding a new software download (e.g., for managed nodes120), an announcement that managed nodes120should enter a certain operational state, mass advertisement messages, etc.

Process block1170may include the process blocks depicted inFIG. 15. As illustrated inFIG. 15, process block1170may include receiving managed node identifier parameter(s) via the cancel registration request(s) (block1500), receiving registration identifier parameter(s) via the cancel registration request(s) (block1510), canceling registration(s), based on the parameter(s), of the managed node(s) providing the cancel registration request(s) (block1520), and providing a cancel status (block1530). For example, in embodiments described above in connection withFIGS. 7 and 8, domain manager110may receive, from managed node120, cancel request350that may include managed node identifier parameter700and/or registration identifier parameter710. Managed node identifier parameter700may include information that identifies one of managed nodes120providing cancel request350. Registration identifier parameter710may include information that identifies a registration (e.g., to be canceled) that is associated with one of managed nodes120providing cancel request350. In one example, domain manager110may cancel a registration (e.g., identified by registration identifier parameter710) associated with one of managed devices120(e.g., identified by managed node identifier700) providing cancel request350. Domain manager110may provide cancel status operation instruction360(e.g., include information that identifies results, such as successful, unsuccessful, etc. of a registration cancellation) to a managed node (e.g., one of managed nodes120) providing cancel request350.

Process block1180may include the process blocks depicted inFIG. 16. As illustrated inFIG. 16, process block1180may include receiving managed node identifier parameter(s) via the registration status request(s) (block1600), receiving registration identifier parameter(s) via the registration status request(s) (block1610), and providing registration status, based on the parameter(s), of the managed node(s) providing the registration status request(s) (block1620). For example, in embodiments described above in connection withFIG. 9, domain manager110may receive, from managed node120, registration status request370that may include managed node identifier parameter900and/or registration identifier parameter910. Managed node identifier parameter900may include information that identifies one of managed nodes120providing registration status request370. Registration identifier parameter910may include information that identifies a registration (e.g., whose status is sought) that is associated with one of managed nodes120providing registration status request370. In one example, domain manager110may provide a status of a registration (e.g., identified by registration identifier parameter910) associated with one of managed devices120(e.g., identified by managed node identifier900) providing registration status request370.

FIG. 17depicts a flow chart of an exemplary process1700for establishing channels between domain manager110and managed nodes120according to embodiments described herein. In one embodiment, process1700may be performed by hardware and/or software components of managed node120. In other embodiments, process1700may be performed by hardware and/or software components of managed node120in combination with hardware and/or software components of another device or group of devices (e.g., communicating with managed node120).

As illustrated inFIG. 17, process1700may begin with providing a register request to a domain manager (block1710), and receiving one or more commands from the domain manager via a command channel established with the domain manager based on the register request (block1720). For example, in embodiments described above in connection withFIG. 3, managed node120may provide register request310to domain manager120(e.g., when managed node120is installed in network100and initiated, automatically, etc.). Register request310may advise domain manager110that managed node120is connected to the network and is prepared to receive command(s) and/or notification(s) from domain manager110. Register request310may identify a command channel address via which managed node120may receive future commands from the domain manager110. Domain manager110may establish a command channel with managed node120based on the command channel address identified by register request310. Domain manager110may provide one or more commands330to managed node120via the command channel established based on register request310(e.g., via the command channel address).

As further shown inFIG. 17, one or more notifications may be received from the domain manager via a notification channel established with the domain manager based on the register request (block1730). For example, in embodiments described above in connection withFIG. 3, managed node120may provide, to domain manager, register request310that may identify a notification channel address via which managed node120may receive future notifications from domain manager110. Domain manager110may establish a notification channel with managed node120based on the notification channel address identified by register request310. Domain manager110may provide one or more notifications (e.g., notify operation instruction340) to managed node120via the notification channel established based on register request310(e.g., via the notification channel address).

Returning toFIG. 17, a cancel registration request may be provided to the domain manager (block1740), a registration status request may be provided to the domain manager (block1750), and/or registration status may be received from the domain manager based on the registration status request (block1760). For example, in embodiments described above in connection withFIG. 3, managed node120may provide cancel request350to domain manager110(e.g., automatically when managed node120is to be disabled, in response to an event, when a user wished to disable managed node120, etc.). Cancel request350may request that domain manager110cancel registration of managed node120. Managed node120may provide registration status request370to domain manager110(e.g., periodically, automatically, when a user of managed node wishes to determine registration status, in response to an event, etc.). Registration status request370may request registration information (e.g., associated with managed node120) stored in domain manager110(e.g., in storage device220). Domain manager110may provide, based on registration status request370, registration status operation instruction380to managed node120, and managed node120may receive registration status operation instruction380. Registration status operation instruction380may include information regarding a status (e.g., unknown, active, inactive, etc.) of a registration associated with managed node120, etc.

Embodiments described herein may include systems and/or methods that establish channels (e.g., command channels and/or notification channels) between a domain manager and managed nodes so that the domain manager may not need to track addresses of the managed nodes and may communicate information to the managed nodes via the established channels.

Embodiments described herein may provide a variety of advantages. For example, embodiments described herein may eliminate the need for the domain manager to keep track of the addresses of the managed nodes, and may provide for rapid dissemination of information (e.g., notifications, announcements, advertisements, commands, etc.) from the domain manager to a large number of managed nodes via the established channels (e.g., command channels and/or notification channels).

The foregoing description of embodiments provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while series of blocks have been described with regard toFIGS. 11-17, the order of the blocks may be modified in other embodiments. Further, non-dependent blocks may be performed in parallel.

Further, certain portions of the invention may be implemented as “logic” that performs one or more functions. The logic may include hardware, such as an application specific integrated circuit, a field programmable gate array, a processor, or a microprocessor, or a combination of hardware and software.