archive-org.com » ORG » X » XPDR.ORG

Total: 20

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Control Layer — XPDR.ORG
    devices that are used to determine what and when certain activities should happen It is designed such as to need to initiate connections as rarely as possible by proactively instructing devices on its various activities during scheduled device initiated control sessions During these proactive device check ins and on the occasionally required server initiated control command the controller transfers Individual object attribute puts Counter resets Configuration object changes On demand data upload commands Action commands such as drop connection or device reset Data templates that define specific sets of data to be grouped for transport up or down Formats of data items Device subsystem responsible for maintaining the items and the interfaces used to obtain store them Version numbers that allow for continued interoperability even if not all devices have the same template version Profiles that contain proactive commands for the agent Scheduled reporting to the collectors of data defined by specified templates Triggered reporting based on simple threshold and event rules of data defined by specified templates Available download files such as firmware application code and configuration files along with optional rules for determining when the device should download them Files can be downloaded using HTTP FTP or other protocols from non managed servers or from the controller Binary files streamed and compressed using the Fabric Layer s L4Z compression Configuration files Firmware code Application code Resource files for applications Staged files for access by other devices on the local network e g vendor specific firmware configuration files Technically all data transports from the controllers are initiated by the device On demand connections are requested via connection requests sent to the device by the Fabric Layer protocol either directly or via NAT ports held open by STUN requests the controller maintains its own STUN server or when absolutely required

    Original URL path: http://www.xpdr.org/control-layer (2016-04-28)
    Open archived version from archive


  • Self-Healing Layer — XPDR.ORG
    tailored version of the same essential rules engine as on the server component but paired down for the scale and requirements of the smaller scope in which it operates Bidirectional Local Monitoring Probe Provides internal status information upon request by approved local devices and polls local devices on its own list of buddy devices for status information The information is consumed by the rules engine to both to aid other devices in their own self management but also to gain insight into the local network overall so as to further guide its actions A health status indicator maintained by the rules engine records the current overall health state of the device on a scale from 1 to 100 The Control Layer will have rules defined as to when this status is reported to the back office and what additional information is communicated when it does Unit Under Test Agent An optional component that works with the physical device test environment of the server component to provide a maximally realistic test environment for testing authored rules There are many ways these components can work together to ensure a healthy network and happy users but here are a few examples The health status indicator will typically be parsed into symbolic status Red Light Yellow Light Green Light The Control Layer may be instructed to report A Green Light status once every eight hours along with certain routine operating information traffic and error statistics for instance A Yellow Light status as soon as it occurs and every hour until it returns to Green A Red Light status as soon as it occurs and every ten minutes until it returns to a healthier level Devices in a local network monitor each other s traffic statistics and optionally intentionally throttle their own traffic generation in

    Original URL path: http://www.xpdr.org/self-healing-layer (2016-04-28)
    Open archived version from archive

  • Analytics Layer — XPDR.ORG
    the user experience An RF engineer probably knows at least theoretically but with thousands of such values being reported on a regular basis it is nearly impossible to manually develop a health model for all circumstances that the various statistics convey That is where the Analytics Layer comes in With access to both the values from networked devices and customer feedback automated speed test results customer surveys calls to customer support etc it is possible to draw conclusions by correlating source data with results data to draw conclusions that can be used to improve the self healing process as well as to improve customer education and customer support procedures Besides improving the customer experience all of the same data can be used to produce sophisticated business intelligence knowledge that can be used to determine ways to improve profitability on existing business lines identify opportunities for other service tiers or business lines and collect information on the key benefits that users find particularly valuable so that promotional efforts can focus on those benefits To facilitate this level of analysis the Analytics Layer specifies that collected data should be stored in big data NoSQL datastores e g Cassandra Mongo HBase and processed

    Original URL path: http://www.xpdr.org/analytics-layer (2016-04-28)
    Open archived version from archive

  • Escalation Layer — XPDR.ORG
    this problem once and for all by ensuring that problems are escalated transferred and collaboratively resolved by all parties that are involved in the user experience A simple knowledge base is loaded with directives on the routing of customer problems through responsible vendors network service provider device manufacturer application vendor etc Tickets can be manually re routed based on evaluation by each vendor s support tiers And when necessary audited

    Original URL path: http://www.xpdr.org/escalation-layer (2016-04-28)
    Open archived version from archive



  •