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".
  • XPDR.ORG
    Layer Fabric Layer Control Layer Self Healing Layer Analytics Layer Escalation Layer Participate Contact News Home About What Is XPDR XPDR Reference Architecture Local Layer Fabric Layer Control Layer Self

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


  • About — XPDR.ORG
    vendor s proprietary software Going forward XPDR a non profit membership organization will first make available RefractN s ground breaking device management software that improves network performance by as much as 50 times over strategies based on SNMP or TR 069 This software will be released to member organizations under the Apache 2 0 License for free allowing a low risk path for broadband service providers and others to begin enhancing their device management infrastructure This software will have all of the functionality of the RefractN Device Collection Suite and the Device Mentoring Suite as available in RefractN s commercial version of these products and consumers of the software will be able to avail themselves of RefractN s implementation support integration and even cloud based services while benefiting from the ability to take advantage of features improvements made by fellow community members or their own development staff More importantly through XPDR RefractN and an outside of team of industry thought leaders will guide the development of the XPDR End to End Device Management Reference Architecture a comprehensive strategy for integrating the management and support systems of broadband providers consumer device manufacturers and internet application vendors in a way that provides

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

  • What Is XPDR? — XPDR.ORG
    of The Internet of Things The world is changing Soon everything will have an IP address The jokes in the early naughts about an internet toaster are no longer far fetched The number of applications is huge and growing The number of devices will grow into the hundreds of millions many behind NAT gateways They will be everything from dumb door ajar sensors to very smart gaming systems They will be produced and supported by a variety of vendors The number of companies in the value chain for these services is large and may grow How does one go about trying to provide a seamless end user support experience Worse yet how does one go about trying to manage the range of technologies involved proactively so as to resolve problems before users even notice them XPDR tackles this problem by dividing the problem into layers much as the International Standards Organization did in the late 80s when it released its Open Systems Interconnect reference model that defined the 7 network layers that have been the basis for networking language in the decades sense These layers recognize that there are different scopes of the problem depending on whether you are talking

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

  • XPDR Reference Architecture — XPDR.ORG
    in the decades since As influential as the OSI reference model was it is worth noting that almost no one uses any of the protocols that were developed by those committees to implement that model but the model itself stood the test of time because it accurately predicted the various problem domains that a diverse set of networking technologies would have to navigate and allowed different vendor to tailor their specific solutions to those needs while still interoperating with the technologies other vendors provided at other levels This is the goal of the XPDR reference model It s founding member RefractN has developed specific technologies and protocols minor extensions really of existing industry standards to address current problems dealing with efficient transport of management information and enabling self healing capabilities within intelligent devices But the problem is much broader than simply transporting data and as powerful the idea is to empower devices to take charge of their own health under the tutelage of a hands off central server there are still problems to solve at other layers There may be better solutions at the layers that RefractN has proposed So in the best spirit of OSI s seven layer model we propose the XPDR Reference Model and its own layers each designed to address the specific realms they are defined to cover Several of the layers run end to end across the network from the back office to the local network The Local Layer Covers communications with devices in the home branch office or remote site The Fabric Layer Provides high efficiency low latency reliable communication of a variety of kinds of data with security scalability and complete failover support The Control Layer Responsible for data integrity across the network ensuring that upstream data is reliably delivered to the right

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

  • Local Layer — XPDR.ORG
    to be functioning optimally to provide the best user experience The local layer provides an interface between those disparate local environments and the various other components in the architecture that can use their health data to improve the user experience It manages applications and devices in the following areas Home automation and security Video set top boxes game systems Oil and gas instrumentation Remote medical devices And many others The

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

  • Fabric Layer — XPDR.ORG
    TR 069 is based on SOAP a heavy weight human readable format that is network inefficient because of its text encoding and as much as 90 overhead in headers IPDR is binary encoded and has very low protocol overhead SNMP is oriented towards transmitting a single data item at a time Though there are mechanisms to collect more than one data element at a time they require a complete transmission of the requested items at the time of the request IPDR uses templates to define sets of data to be transmitted in bulk and it is only necessary to transmit a single request for all data in a template Both TR 069 and SNMP are server driven While TR 069 allows for scheduled exports of a single set of data IPDR supports periodic transmission of a variety of templates of data XPDR goes above and beyond IPDR which is primarily focused on transferring large quantities of bulk data for multiple devices and provides even more efficiency and capability XPDR separates template negotiation from data transmission IPDR requires that a template describing the data to be transmitted be negotiated on each transmission XPDR negotiates templates out of band ahead of time so that data transfers are immediate without the extra overhead of negotiating templates that rarely change Data encoding goes beyond the standard XDR and recognizes that many data fields are the same from one transmission to another and de dups those data fields so that they don t have to be transmitted repeatedly XPDR s data encoding improves upon XDR again by performing ASN 1 type encoding of numeric values ensuring that they are as short as possible regardless of type declaration The RefractN XPDR implementation supports automatic device exports based on triggers defined in profiles passed down along with

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

  • 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



  •